В эпоху, когда большие языковые модели (LLM) эволюционировали из простых генераторов текста в сложных автономных агентов, парадигма работы с данными претерпела радикальные изменения. Раньше, когда мы говорили о проверке фактов в системах RAG (Retrieval-Augmented Generation), речь шла о сравнении ответа модели с одним или несколькими извлеченными текстовыми фрагментами. Однако сегодня, благодаря таким протоколам, как Model Context Protocol (MCP), агенты больше не ограничиваются чтением из единого пула документов. Они способны вызывать инструменты поиска, проверять структурированные записи пациентов или учетных записей, запрашивать базы данных и извлекать метаданные, а затем сплетать всю эту разнородную информацию в единый ответ.
Это делает вопрос фактологической достоверности гораздо более тонким и сложным, чем может показаться на первый взгляд. Большинство существующих систем проверки ответов LLM, от RAGAS Faithfulness до более детализированных проверщиков, таких как MiniCheck, AlignScore и SummaC, задают один главный вопрос: поддерживается ли утверждение имеющимися доказательствами, когда эти доказательства объединены в один контекст? В своей обычной форме они не сообщают нам, какой именно вывод инструмента MCP поддерживает каждое конкретное утверждение, и, что еще важнее, совпадает ли этот источник с тем, на который ссылается ответ.
Именно этот пробел заполняет наша новая работа — ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents. Мы фокусируемся на специфическом режиме отказа, который называем «конфлюэнцией источников» (cross-source conflation). Это ситуация, когда утверждение истинно где-то в доступных доказательствах, но приписано неверному источнику. Проверщик, не учитывающий источник, может пропустить такую ошибку, так как факт действительно существует в пуле данных. Проверщик, aware (осведомленный) об источнике, должен это исправить.
01Проблема: «Поддержано где-то» ≠ «Поддержано правильным источником»
Рассмотрим типичный сценарий с агентом технической поддержки, который отвечает клиенту: «Согласно записи об учетной записи, этот план включает 30-дневное окно возврата средств». Само окно возврата может быть абсолютно реальным и существующим, но эта информация может быть изложена в документе с политикой компании, а не в записи об учетной записи, на которую ссылается ответ. Если объединить эти два источника вместе, утверждение будет выглядеть поддерживаемым. Если же держать их раздельными, то атрибуция будет неверной.
В среде, чувствительной к данным, неверная атрибуция может быть столь же разрушительной, как и неверный факт. Та же самая закономерность проявляется в клинических агентах: если деталь о лекарстве, специфичная для пациента, взятая из инструмента истории болезни, представлена в ответе как вывод из медицинской литературы, это становится вводящим в заблуждение. Утверждение может быть поддержано одним источником MCP, в то время как ответ приписывает его другому. Проверка, не учитывающая источник, видит поддержку в объединенных доказательствах и пропускает её; ProvenanceGuard же отдельно проверяет, совпадает ли поддерживающий источник с тем, который назван или подразумевается в ответе.
Именно поэтому показателей верности (faithfulness), какими бы полезными они ни были, недостаточно для агентов MCP. Ответ несет в себе происхождение (provenance), иногда явно («согласно записи об учетной записи»), а иногда и неявно. ProvenanceGuard сохраняет эту связь между утверждением и источником доступной для инспекции на протяжении всего процесса.
02Как работает ProvenanceGuard
ProvenanceGuard — это слой постгенерационной верификации, который работает поверх «черного ящика» MCP-агента. Он запускается после того, как агент сгенерировал ответ, и никогда не сводит доказательства к одному анонимному контексту. Вместо этого он сохраняет идентичность источника на протяжении всего конвейера обработки. Он читает захваченный трассировочный журнал MCP, включая выводы инструментов и их идентификаторы источников, без необходимости переобучения самого агента.
Процесс верификации состоит из пяти последовательных шагов:
- Декомпозиция: Ответ разбивается на конкретные утверждения.
- Маршрутизация: Для каждого утверждения находится наиболее релевантный источник.
- Проверка поддержки: Проверяется, действительно ли этот источник поддерживает утверждение.
- Проверка атрибуции: Источник сравнивается с тем, который назван или подразумевается в ответе.
- Принятие решения: Выдается вердикт по каждому утверждению (источник/ложь) и глобальное решение разрешить или заблокировать весь ответ.
Несколько архитектурных решений заслуживают особого внимания. В экспериментах, описанных в нашей статье, мы использовали локальные модели, чтобы захваченные трассы могли обрабатываться в контролируемой офлайн-среде. Для поиска релевантного источника используется MiniLM, модель верификатора DeBERTa NLI (Natural Language Inference) проверяет, поддерживает ли источник утверждение, а локальная языковая модель помогает разбивать ответы на утверждения. Верификатор также тщательно проверяет буквальные значения: число, дата или идентификатор, отсутствующие в источнике, не могут пройти проверку только потому, что предложение звучит правдоподобно.
Калиброванный шаг принятия решения объединяет эти сигналы. Если ответ заблокирован, шаг ремонта в стиле RARR (Retrieval-Augmented Reasoning and Repair) может попытаться выполнить исправление, основанное на источнике, или предложить безопасный вариант ответа, который затем снова проверяется верификатором.
03Результаты тестирования
Мы протестировали ProvenanceGuard на ответах медицинского агента, который использовал записи пациентов, научные статьи и другие инструменты. Это дало нам 281 реальный трассировочный журнал для изучения. Медицина является полезным тестовым полигоном, потому что факт из записи пациента и факт из общих исследований не могут рассматриваться как источник одного типа. Метод также может быть использован в других областях, где агент ведет запись своих выводов инструментов и идентификаторов источников.
Для основного теста эксперты-люди проверили 361 утверждение из 40 ответов, выделенных из данных, использованных для разработки системы. Наиболее прямой результат таков: эксперты заявили, что 139 утверждений не должны были пройти проверку, и ProvenanceGuard выявил 138 из них. Одно утверждение было пропущено. Система также отправила на проверку или ремонт 67 утверждений, которые эксперты сочли поддерживаемыми. Это отражает осторожный режим, в котором мы тестировали систему: она предпочитает второй взгляд по некоторым поддерживаемым утверждениям, чем пропуск неподдерживаемых.
Для утверждений с идентифицируемым источником система правильно выбрала источник примерно в 86% случаев в этом тесте. Мы запустили четыре других проверщика поддержки на тех же утверждениях. ProvenageGuard показал наивысший балл по мере того, насколько хорошо система блокирует утверждения, которые следует заблокировать, избегая при этом ненужных блокировок. Другие проверщики в этом сравнении не сообщали нам, какой вывод инструмента поддерживает каждое утверждение.
В отдельном, более сложном тесте с несколькими похожими источниками ProvenageGuard показал F1-меру 0,846 для решения о блокировке утверждений, но правильно определил точный источник только в 50,3% случаев. Различение похожих источников остается важной областью для улучшения. Мы также провели контролируемый тест, сфокусированный на неверной атрибуции: мы изменили названный источник в 50 случаях, оставив поддерживающие доказательства нетронутыми. ProvenageGuard выявил все 50 подмен. Это показывает, что он может обнаруживать очевидные ошибки источника, в то время как более сложный тест демонстрирует проблему выбора среди многих правдоподобных источников.
04Ремонт заблокированных ответов
Блокировка полезна только в том случае, если есть что делать с заблокированным ответом. Подключенный к циклу ремонта в стиле RARR, полный запуск трассы разрешил все 173 заблокированных ответа, хотя 144 из них завершились текстом резервного варианта, а не существенным переписыванием. Это выбор системы избегать unverifiable (неподтверждаемого) ответа, а не фабриковать его. На реконструированных многоисточниковых тестовых трассах свежий запуск ремонта разрешил все 59 изначально заблокированных ответов с лишь двумя терминальными резервными вариантами.
В качестве офлайн-шлюза накладные расходы невелики: примерно полсекунды на ответ в указанной локальной конфигурации, при этом сами вызовы NLI и маршрутизации занимают десятки миллисекунд. Это делает ProvenageGuard практически применимым в реальных сценариях, где задержка должна быть минимальной, но надежность критически важна.
05Почему это важно для Multiverse Computing и индустрии
По мере того как агенты переходят от одиночного RAG к многоинструментальным настройкам MCP, вопрос о том, откуда на самом деле взят факт, перестает быть второстепенной деталью и становится частью самого определения фактологичности. ProvenageGuard делает эту связь источника видимой утверждение за утверждением. Для Multiverse Computing это означает способ проверки существующих агентов, сохраняя чувствительные трассы в контролируемой среде, когда это необходимо. Медицинское исследование является одним из вариантов использования; тот же подход может быть адаптирован везде, где трассировка агента сохраняет его инструменты и источники.
Эта адаптация уже видна в NVIDIA NVFlow, который добавил необязательный этап проверки заземления для своего финансового агента. Он проверяет готовые ответы против цитат SEC, которые извлек агент, и сохраняет отдельные решения, не изменяя оригинальный запуск или обучающие данные. Вклад NVFlow использует подход проверки, осведомленной об источнике, от ProvenageGuard; цикл ремонта, обсуждаемый выше, принадлежит более широкой исследовательской системе.
06Что это значит на практике
Для разработчиков и инженеров, работающих с LLM-агентами, внедрение таких систем, как ProvenageGuard, означает переход от «черного ящика» к прозрачной, аудируемой системе принятия решений. Вместо того чтобы полагаться на то, что модель «в целом права», вы получаете детализированный отчет о том, почему каждое утверждение в ответе считается верным или ложным, и какой именно источник был использован для этого решения.
Это особенно критично в регулируемых отраслях, таких как финансы и здравоохранение, где ответственность за информацию имеет юридические последствия. Ошибка в атрибуции может привести к тому, что пациент получит информацию из общего исследования, представленную как его личная медицинская карта, или инвестор примет решение на основе устаревших данных, представленных как актуальные. ProvenageGuard не просто проверяет факт; он проверяет контекст и происхождение факта, обеспечивая более высокий уровень доверия к автономным системам.
Хотя система требует дополнительных вычислительных ресурсов для постобработки, накладные расходы остаются приемлемыми для большинства приложений реального времени. А возможность автоматического ремонта ответов через цикл RARR добавляет еще один уровень устойчивости, позволяя системе исправлять ошибки без вмешательства человека, если это возможно, или безопасно отказываться от ответа, если это необходимо.
Мы представляли ProvenageGuard в виде постера на Agentic AI Summit 2026 в UC Berkeley. Если вам нужны полные технические детали, включая выводы маршрутизации и NLI, калибровочные абляции, стресс-слайсы с несколькими источниками и полные таблицы результатов, читайте полную статью на Hugging Face или свяжитесь с нашей командой, чтобы обсудить применение проверки, осведомленной об источнике, для ваших собственных агентов.
Будущее AI-агентов — это не только в их способности действовать, но и в способности объяснять, откуда они взяли информацию. ProvenageGuard закладывает фундамент для этой прозрачности, делая проверку фактов не просто вопросом «да/нет», а вопросом «кто сказал?».
Источник: Hugging Face ↗