ИИ-агенты, использующие инструменты, больше не читают из одного извлеченного фрагмента текста. С помощью Model Context Protocol (MCP) агент может вызвать поисковый инструмент, изучить структурированную запись пациента или учетной записи, сделать запрос к базе данных, извлечь метаданные, а затем объединить все это в один ответ. Это делает привычный вопрос о достоверности фактов сложнее, чем кажется на первый взгляд. Большинство систем, созданных для проверки ответов ИИ, от RAGAS faithfulness до специализированных верификаторов, таких как MiniCheck, AlignScore и SummaC, задаются вопросом, подтверждается ли утверждение имеющимися доказательствами после того, как эти доказательства были объединены. В своем обычном виде они не говорят нам, какой именно вывод инструмента MCP поддерживает каждое утверждение и является ли это источником, указанным в ответе.
Наша последняя статья, ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents (прочтите ее на Hugging Face или на arXiv в то же время), устраняет этот пробел. Режим сбоя, который нас интересует, мы называем смешением междоменных источников: утверждение, которое истинно где-то в доказательной базе, но приписано не тому источнику. Верификатор, не учитывающий источники, может пропустить его, поскольку сам факт действительно существует в базе. Верификатор с учетом источников не должен этого делать.
Проблема: подтверждено где-то — не значит подтверждено правильным источником
Представьте себе агента службы поддержки, который отвечает: «Согласно учетной записи, этот план включает 30-дневный период возврата средств». Период возврата средств может быть совершенно реальным, но он указан в документе с политикой, а не в учетной записи, на которую ссылается ответ. Объедините их вместе, и утверждение покажется обоснованным. Держите их раздельно, и атрибуция окажется неверной, а в условиях конфиденциальности данных неверная атрибуция может быть столь же опасна, как и неверный факт. Тот же шаблон проявляется у клинического агента, где данные о конкретном пациенте, полученные из инструмента истории болезни, становятся вводящими в заблуждение в тот момент, когда ответ преподносит их как выводы из медицинской литературы.
Утверждение может поддерживаться одним источником MCP, в то время как ответ приписывает его другому. Оценка без учета источников видит поддержку в объединенных доказательствах и пропускает ее; ProvenanceGuard отдельно проверяет, совпадает ли поддерживающий источник с тем, который указан или подразумевается в ответе. Источник: Рисунок 1 из статьи.
Именно поэтому оценки достоверности, какими бы полезными они ни были, недостаточны для агентов MCP. Ответ несет в себе provenance (происхождение), иногда явно («согласно учетной записи»), а иногда неявно. ProvenanceGuard сохраняет эту связь между утверждением и источником доступной для проверки.
Что делает ProvenanceGuard
ProvenanceGuard — это уровень погенерационной верификации, который располагается поверх черного ящика MCP-агента. Он запускается после того, как агент выдает ответ, и никогда не объединяет доказательства в один анонимный контекст. Вместо этого он проносит идентификатор источника через весь конвейер. Он считывает захваченный след MCP, включая результаты работы инструментов и их идентификаторы источников, без дообучения агента. Затем он выполняет пять последовательных действий: разбивает ответ на конкретные утверждения, находит наиболее релевантный источник для каждого из них, проверяет, действительно ли этот источник поддерживает его, сравнивает источник с тем, который назван или подразумевается в ответе, и, наконец, выдает как вердикт по источнику для каждого утверждения, так и общее решение на уровне ответа — разрешить или заблокировать.
Процесс проверки. Идентификация источника сохраняется на этапах декомпозиции, маршрутизации, оценки поддержки, проверки атрибуции и восстановления, а не объединяется в пул. Заблокированные ответы могут проходить восстановление в стиле RARR и повторную проверку. Источник: Рисунок 2 из статьи.
Некоторые из проектных решений заслуживают упоминания. Для экспериментов в нашей статье мы использовали локальные модели, чтобы записанные следы можно было обрабатывать в контролируемой автономной среде: MiniLM помогает найти релевантный источник, модель верификации DeBERTa NLI проверяет, поддерживает ли этот источник утверждение, а локальная языковая модель помогает разбить ответы на утверждения. Верификатор также внимательно проверяет буквальные значения: число, дата или идентификатор, отсутствующие в источнике, не могут пройти проверку только потому, что предложение звучит правдоподобно. Калиброванный этап принятия решений объединяет эти сигналы. Если ответ заблокирован, шаг восстановления в стиле RARR может попытаться выполнить исправление на основе источников или безопасный резервный вариант, который затем снова проверяет верификатор.
Упомянутые модели — это стенд, который мы оценивали, а не требование ProvenanceGuard. Те же шаги утверждения, источника и принятия решений могут быть адаптированы для размещенных моделей, если команда предпочитает облачные сервисы; новая настройка потребует собственного тестирования и калибровки. Наши опубликованные результаты получены на основе локальной конфигурации. Ее консервативная политика принятия решений подходит для проверки конфиденциальных данных, где правильный выбор источника важнее максимально быстрого получения ответа.
Результаты
Мы протестировали ProvenanceGuard на ответах медицинского агента, который использовал записи пациентов, научные статьи и другие инструменты. Это дало нам 281 реальный след для изучения. Медицина является полезным тестом, поскольку факт из карты пациента и факт из общих исследований не могут рассматриваться как один и тот же источник. Метод также может применяться в других областях, когда агент ведет учет результатов работы своих инструментов и идентификаторов источников. Для основного теста эксперты-люди проверили 361 утверждение из 40 ответов, исключенных из данных, использованных для разработки системы.
Самый прямой результат таков: эксперты заявили, что 139 утверждений не должны проходить, и ProvenanceGuard поймал 138 из них. Он пропустил одно. Он также задержал 67 утверждений, которые эксперты посчитали подтвержденными, отправив их на рассмотрение или исправление. Это отражает протестированные нами осторожные настройки: система предпочитает перепроверить некоторые подтвержденные утверждения, чем пропустить неподтвержденные. Для утверждений с идентифицируемым источником в этом тесте она также правильно выбирала источник примерно в 86% случаев.
Мы запустили четыре других средства проверки поддержки для тех же утверждений. ProvenanceGuard набрал наибольшее количество баллов по метрике статьи, оценивающей, насколько хорошо система улавливает утверждения, которые должны быть заблокированы, избегая при этом ненужных блокировок. Другие средства проверки в этом сравнении не сообщали нам, какой вывод инструмента поддерживал каждое утверждение. ProvenanceGuard записывает эту связь, поэтому рецензент может видеть проверенный для каждого утверждения источник и вынесенное им решение.
Метрики бинарной поддержки для того же отложенного пакета утверждений. ProvenanceGuard соответствует или превосходит базовые показатели без учета источников по блокировке, одновременно создавая вердикты по источникам для каждого утверждения. Источник: аннотация статьи и Таблица III.
Проверка утверждений при внешне похожих источниках
В отдельном, более сложном тесте с несколькими похожими источниками ProvenanceGuard набрал 0,846 F1 для определения того, какие утверждения следует заблокировать, но правильно определил точный источник в 50,3% утверждений. Различение похожих источников остается важной областью для улучшения.
Мы также провели контролируемый тест, сосредоточенный на неверной атрибуции: мы изменили названный источник в 50 случаях, оставив подтверждающие доказательства неизменными. ProvenanceGuard поймал все 50 замен. Это показывает, что он может обнаруживать явную ошибку источника, в то время как более сложный тест демонстрирует трудность выбора среди множества правдоподобных источников.
Восстановление заблокированных ответов
Блокировка полезна только в том случае, если с заблокированным ответом можно что-то сделать. Подключенный к циклу исправления в стиле RARR, запуск по полному трассировочному следу разрешил все 173 заблокированных ответа, хотя 144 из них завершились резервным текстом, а не существенной переработкой — это система выбирает отказ от неподтверждаемого ответа вместо генерации выдуманного. На реконструированных тестовых трассировках из нескольких источников свежий цикл исправления разрешил все 59 изначально заблокированных ответов всего с двумя финальными резервными вариантами. В качестве автономного шлюза накладные расходы невелики: примерно полсекунды на один ответ на заявленной локальной конфигурации, при этом сами вызовы NLI и маршрутизации занимают десятки миллисекунд.
Почему это подходит Multiverse Computing
По мере того как агенты переходят от RAG на основе одного фрагмента к настройкам MCP со множеством инструментов, вопрос о том, из какого именно источника взят факт, перестает быть сноской и становится частью того, что означает достоверность. ProvenanceGuard делает эту связь с источником видимой для каждого утверждения. Для Multiverse Computing это означает способ проверки существующих агентов с сохранением конфиденциальных трассировок в контролируемой среде при необходимости. Медицинское исследование — лишь один из вариантов использования; тот же подход можно адаптировать везде, где трассировка агента сохраняет его инструменты и источники.
Эта адаптация уже заметна в NVIDIA NVFlow, где был добавлен необязательный этап проверки обоснованности для финансового агента. Он проверяет готовые ответы по выдержкам из SEC, полученным агентом, и сохраняет отдельные решения без изменения исходного процесса развертывания или обучающих данных. Вклад NVFlow использует подход ProvenanceGuard к проверке с учетом источников; упомянутый выше цикл исправления относится к более широкой исследовательской системе.
ProvenanceGuard также presented as a poster at the Agentic AI Summit 2026 at UC Berkeley.
Хотите узнать все технические детали, включая маршрутизацию и выводы NLI, абляционные исследования калибровки, срезы стресс-тестирования для множества источников и полные таблицы результатов? Прочитайте полную статью на Hugging Face или свяжитесь с нашей командой, чтобы обсудить применение проверки с учетом источников к вашим собственным агентам.
