Проверка не просто фактов, а их источника: как ProvenanceGuard защищает агентов от кросс-источнической конфлюкции

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

Развитие языковых моделей (LLM) привело от простых систем генерации текста к сложным агентам, способным взаимодействовать с внешним миром через инструменты. Протокол Model Context Protocol (MCP) позволяет этим агентам не просто искать информацию, но и обращаться к структурированным записям, базам данных и метаданным. Однако, по мере роста возможностей агентов растет и сложность контроля их достоверности.

Команда Multiverse Computing, представленная на блоге Hugging Face, опубликовала исследование, описывающее метод ProvenanceGuard.该系统 решает фундаментальную проблему мультиинструментальных агентов: разницу между тем, что факт верен где-то в доступных данных, и тем, что он правильно атрибутирован конкретному источнику, который назвал агент в своем ответе.

Проблема: факт есть, а источник неверен

В классических системах верификации, таких как RAGAS или MiniCheck, часто используется подход "пулинга" данных. Агент выполняет несколько запросов, а система проверки сканирует объединенный набор ответов на наличие подтверждения для каждого утверждения в финальном тексте агента. Если факт действительно содержится в одном из документов, система помечает ответ как достоверный (faithful).

Однако этот подход игнорирует кросс-источническую конфлюкцию (cross-source conflation). Это ситуация, когда агент использует данные из одного инструмента (например, выписку со счета пациента), но ошибочно формулирует свой ответ, утверждая, что опирается на другой источник (например, медицинские исследования). Для системы, работающей с объединенным контекстом, такой ответ выглядит валидным. Для пользователя же это может быть критической ошибкой, особенно в чувствительных доменах, таких как здравоохранение или финансы, где источник информации определяет ценность и легитимность данных.

*«Факт существует в супе, но цитирование ошибочно»* — так можно описать ситуацию, которую ловит ProvenanceGuard, но пропускает традиционные верификаторы.

Как работает ProvenanceGuard

Метод ProvenanceGuard действует как слой пост-генерационной проверки. Он не меняет работу самого агента, а анализирует сохраненный след (trace) взаимодействия, включая идентификаторы инструментов, которые тот использовал.

Система работает по следующей последовательности шагов: 1. Декомпозиция ответа: Финальный текст агента разбивается на отдельные утверждения (claims). 2. Поиск релевантного источника: Для каждого утверждения используется модель (например, на базе MiniLM) для поиска наиболее вероятного инструмента, содержащего эту информацию. 3. Проверка поддержки: С помощью модели NLI (Natural Language Inference, например, DeBERTa) проверяется, действительно ли найденный источник подтверждает конкретное утверждение, а не просто содержит похожие слова. 4. Сверка атрибуции: Система сверяет найденный источник с тем, какой источник явно или неявно назвал сам агент в ответе. 5. Вердикт: Выносится решение о допустимости ответа или отдельных утверждений на основе сопоставления этих данных.

Важной особенностью является то, что идентичность источника сохраняется на всем пути обработки. Если агент называет источник А, но факты подтверждаются только в источнике Б, система это фиксирует. Это позволяет не только блокировать заведомо ложные аттрибуции, но и, при необходимости, инициировать цикл восстановления (репар), где агент может пересмотреть свой ответ с учетом правильного источника.

Результаты исследования

Исследование было проведено на базе медицинских агентов, работавших с записями пациентов и научными статьями. Такой выбор обусловлен тем, что данные из истории болезни и из медицинских статей имеют разную природу и не должны взаимозаменяться при цитировании.

В тестировании участвовали эксперты-люди, которые проверяли 361 утверждение из 40 ответов. Основная цель эксперимента — выявить случаи, которые должны были быть отклонены. * Эксперты сочли 139 утверждений недопустимыми. ProvenanceGuard корректно выявил 138 из них. * Система также отклонила 67 утверждений, которые эксперты сочли допустимыми. Авторы отмечают, что это консервативный настрой, предпочитающий перепроверке пропуск ошибки. * При проверке идентификации конкретного источника система демонстрировала точность около 86%.

Сравнив ProvenanceGuard с другими методами (MiniCheck, RAGAS, AlignScore, SummaC), команда Multiverse Computing показала, что новый метод превосходит их по способности обнаруживать именно ошибочную атрибуцию источника, не просто находя фактическое подтверждение где-то в наборе данных.

Практическое значение и будущее

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

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

Для разработчиков агентов это означает необходимость менять парадигму оценки: понятие "grounded" (основанность) должно трактоваться не как "существует факт в каком-либо ответе инструмента", а как "факт подтвержден именно тем инструментом, который назван в ответе". Это повышает доверие к автоматизированным системам, делая их пригодными для задач, где цена ошибки в атрибуции данных крайне высока.