Правильный источник, а не только факт: верификация с учетом источника для MCP-агентов

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

Наша последняя статья, ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents (пока её можно прочитать на Hugging Face или на arXiv), посвящена этому пробелу. Нас интересует тип ошибки, который мы называем смешением источников: утверждение истинно где-то в наборе свидетельств, но приписывается неправильному источнику. Проверяющий без учёта источников может пропустить такую ошибку, поскольку факт действительно присутствует в общем наборе. Проверяющий с учётом источников не должен этого делать.

Проблема: подтверждение где-то не равно подтверждению правильным источником

Рассмотрим агента службы поддержки, который отвечает: «Согласно записи аккаунта, этот тариф включает 30-дневный период возврата средств». Период возврата может быть вполне реальным, но указанным в документе с политикой, а не в записи аккаунта, на которую ссылается ответ. Если объединить эти два источника, утверждение выглядит подтверждённым. Если сохранить их раздельно, атрибуция окажется неверной, а в условиях работы с чувствительными данными неправильная атрибуция может быть столь же опасной, как и неправильный факт. Та же схема проявляется в клиническом агенте: специфичная для пациента информация о лекарствах, взятая из инструмента истории болезни, становится вводящей в заблуждение, как только ответ представляет её как вывод медицинской литературы.

Утверждение может подтверждаться одним источником MCP, тогда как ответ приписывает его другому. Оценка без учёта источников видит подтверждение в объединённых свидетельствах и пропускает утверждение; ProvenanceGuard отдельно проверяет, совпадает ли подтверждающий источник с тем, который указан или подразумевается в ответе. Источник: рисунок 1 статьи.

Именно поэтому оценок faithfulness, какими бы полезными они ни были, недостаточно для MCP-агентов. Ответ содержит сведения о происхождении, иногда явно («согласно записи аккаунта»), а иногда неявно. 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 получил F1 0.846 при принятии решения о том, какие утверждения блокировать, но правильно определил точный источник лишь для 50,3% утверждений. Различение похожих источников остаётся важным направлением для улучшения.

Мы также провели контролируемый тест, посвящённый неправильной атрибуции: в 50 случаях мы изменили названный источник, оставив подтверждающие свидетельства без изменений. ProvenanceGuard выявил все 50 подмен. Это показывает, что система способна обнаруживать явную ошибку в источнике, тогда как более сложный тест демонстрирует трудность выбора среди множества правдоподобных источников.

Исправление заблокированных ответов

Блокировка полезна только в том случае, если с заблокированным ответом можно что-то сделать. При подключении к циклу исправления в стиле RARR полный прогон по трейсу разрешил все 173 заблокированных ответа, хотя 144 из них завершились резервным текстом, а не содержательной переработкой: система предпочла избежать непроверяемого ответа, а не выдумывать его. На восстановленных многосоставных тестовых трейсах новый запуск исправления разрешил все 59 изначально заблокированных ответов, завершившись лишь двумя резервными вариантами. В качестве автономного шлюза система создаёт умеренные накладные расходы — примерно полсекунды на ответ в представленной локальной конфигурации, причём сами вызовы NLI и маршрутизации занимают десятки миллисекунд.

Почему это подходит Multiverse Computing

По мере перехода агентов от RAG с одним фрагментом к MCP-конфигурациям с несколькими инструментами вопрос о том, из какого именно источника происходит факт, перестаёт быть примечанием и становится частью самого понятия фактической точности. ProvenanceGuard делает эту связь с источником видимой для каждого утверждения. Для Multiverse Computing это означает возможность проверять существующих агентов, сохраняя при необходимости чувствительные трейсы в контролируемой среде. Медицинское исследование — лишь один пример применения; тот же подход можно адаптировать везде, где трейс агента сохраняет информацию о его инструментах и источниках.

Такая адаптация уже видна в NVIDIA NVFlow, где был добавлен опциональный этап проверки обоснованности для финансового агента. Он проверяет готовые ответы по фрагментам SEC, полученным агентом, и сохраняет отдельные решения, не меняя исходный процесс развёртывания или обучающие данные. Вклад в NVFlow использует подход ProvenanceGuard к проверке с учётом источников; рассмотренный выше цикл исправления относится к более широкой исследовательской системе.

ProvenanceGuard также был представлен в виде постера на Agentic AI Summit 2026 в Калифорнийском университете в Беркли.

Хотите узнать все технические подробности, включая выводы для маршрутизации и NLI, абляционные исследования калибровки, стресс-тесты с несколькими источниками и полные таблицы результатов? Прочитайте полную статью на Hugging Face или свяжитесь с нашей командой, чтобы обсудить применение проверки с учётом источников к вашим собственным агентам.

Модели, упомянутые в этой статье 2

Другие материалы этого автора