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

Редакционная иллюстрация создана с помощью ИИ. Это вымышленная сцена, а не результат тестирования инструмента.
Что это
Инструментальные 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% случаев: авторы называют это важной областью для улучшения. Кроме того, осторожная политика решений повышает нагрузку на ревью, а приведённые результаты получены именно на локальной конфигурации.