Гайды

Проверка источника, а не факта: source-aware верификация для MCP-агентов

Разбираем ProvenanceGuard: проверку ответов MCP-агентов с привязкой к источнику, заявленные результаты авторов и ограничения подхода.

Редакция НейроДвижа. Проверено 29 сентября 2026.

AI-иллюстрация: Кот-космонавт на розовой планете

Редакционная иллюстрация создана с помощью ИИ. Это вымышленная сцена, а не результат тестирования инструмента.

Что это

Инструментальные LLM-агенты, работающие через Model Context Protocol (MCP), вызывают поиск, читают структурированные записи, обращаются к базе и метаданным, а затем собирают всё это в один ответ. Проверки вроде RAGAS faithfulness, MiniCheck, AlignScore и SummaC оценивают, подтверждается ли утверждение объединённым пулом доказательств, но не показывают, какой именно вывод инструмента его подтверждает.

ProvenanceGuard — слой пост-генерационной проверки поверх «чёрного ящика» MCP-агента. Он читает сохранённую трассу с выводами инструментов и их ID, не переобучая агента, и последовательно: разбивает ответ на утверждения, находит самый релевантный источник для каждого, проверяет подтверждение, сверяет источник с тем, который ответ называет или подразумевает, и выдаёт вердикт по каждому утверждению плюс общее решение allow или block.

Главный сбой, на который нацелена работа, авторы называют cross-source conflation: утверждение верно где-то в доказательствах, но приписано не тому источнику. Реальное условие возврата может быть упомянуто в политике, а ответ ссылается на запись аккаунта — при объединении источников такая ошибка выглядит как подтверждённый факт.

Кому это полезно

Подход рассчитан на команды, где ответ агента должен быть привязан к конкретному источнику: поддержка клиентов, клинические сценарии, финансовые агенты. Авторы тестировали систему на ответах медицинского агента, который использовал записи пациентов, исследовательские статьи и другие инструменты.

Метод применим и в других областях, если агент сохраняет запись выводов инструментов и ID источников. В статье отдельно упомянут NVIDIA NVFlow, где для финансового агента добавлен опциональный этап проверки обоснованности: он сверяет готовые ответы с извлечёнными фрагментами SEC и сохраняет решения отдельно, не меняя исходный прогон.

Только ProvenanceGuard среди сравнённых чекеров сообщает, какой вывод инструмента подтверждает каждое утверждение, и фиксирует эту связь для ревьюера.

Что показали тесты авторов

В основном тесте эксперты проверили 361 утверждение из 40 ответов, отложенных от данных разработки. Эксперты отметили 139 утверждений как недопустимые, и ProvenanceGuard отловил 138 из них. Ещё 67 утверждений, которые эксперты сочли подтверждёнными, система отправила на проверку или ремонт — это следствие осторожной настройки.

Для утверждений с определимым источником правильный источник был выбран примерно в 86% случаев. В отдельном контролируемом тесте авторы подменили названный источник в 50 случаях, сохранив доказательства, и система поймала все 50 подмен.

Заблокированные ответы можно отправить в RARR-подобный ремонт и проверить заново. В прогоне по полной трассе так были разрешены все 173 заблокированных ответа, но 144 из них закончились fallback-текстом, а не содержательной переработкой.

Как проверить на своей задаче (совет редакции)

Сначала убедитесь, что трасса агента действительно хранит выводы инструментов и их идентификаторы — без этого source-aware проверка невозможна в принципе. Затем соберите отложенный набор ответов и разметьте утверждения людьми, как это сделано в работе.

Имеет смысл отдельно смоделировать ошибку атрибуции: подмените названный источник, не трогая доказательства. Добавьте к метрике блокировки отдельную метрику «правильный источник выбран» и заранее решите, что делать с заблокированными ответами: в исследовании ремонт часто заканчивался fallback-текстом, то есть отказом отвечать, а не переписыванием.

Ограничения

Названные модели — MiniLM для поиска релевантного источника, DeBERTa для NLI-проверки и локальная языковая модель для разбиения на утверждения — это конфигурация проведённого эксперимента, а не требование метода. Для хостинговых или облачных моделей потребуются собственное тестирование и калибровка.

При похожих источниках точное определение источника удалось лишь в 50,3% случаев: авторы называют это важной областью для улучшения. Кроме того, осторожная политика решений повышает нагрузку на ревью, а приведённые результаты получены именно на локальной конфигурации.