Агент с MCP-инструментами собирает данные из нескольких источников и легко выдаёт правдоподобный ответ. Факт в системе действительно есть, но в другой записи, не в той, на которую агент указал. Обычные проверки достоверности видят факт в общем пуле и ставят зелёную отметку. Источник при этом не сходится.
Команда Multiverse Computing называет это перекрёстным смешением источников (cross-source conflation): утверждение верно где-то в собранных данных, но приписано не тому источнику. В блоге Hugging Face они описывают случай поддержки. Агент говорит «согласно карточке аккаунта, возврат 30 дней», хотя окно возврата описано в политике, а не в карточке. Пул фактов подтверждает утверждение, источник нет. Для медицинского агента та же ошибка опаснее: деталь из истории пациента, поданная как вывод из литературы.
Что такое проверка с учётом источника
В системе ProvenanceGuard после ответа агента работает отдельный слой. Он читает трассу вызовов MCP вместе с идентификаторами источников и делает пять шагов по каждому ответу. Он разбивает ответ на конкретные утверждения, для каждого находит релевантный источник, проверяет, подтверждает ли он утверждение, сверяет источник с тем, который назван в ответе явно или подразумевается, и выносит вердикт по каждому утверждению плюс общее решение «пропустить или заблокировать».
Главное отличие от обычных чекеров: идентификатор источника не теряется и не сливается в общий контекст. Связь «утверждение и конкретный вывод MCP-инструмента» остаётся видимой. Если ответ заблокирован, в дело вступает цикл исправления в стиле RARR: она пробует переписать ответ с опорой на правильный источник или отдаёт безопасный запасной ответ, и проверка прогоняется снова.
Почему это работает
- Оценки достоверности (RAGAS, MiniCheck, AlignScore, SummaC) смотрят на пул доказательств целиком. Они не отвечают на вопрос «тем ли источником подтверждено». Слой с учётом источника закрывает именно эту дыру.
- Числа из источника проверяются буквально: число, дата или идентификатор, которых нет в названном источнике, не проходят только потому, что предложение звучит правдоподобно.
- Политика решения откалибрована в сторону осторожности: лучше отправить ответ на вторую проверку, чем пропустить неверную атрибуцию. Это подходит для мест, где цена ошибки высока.
В эксперименте на 281 реальной трассе медицинского агента эксперты пометили 361 утверждение из 40 ответов. Из 139 утверждений, которые не должны были пройти, ProvenanceGuard заблокировал 138. На 50 контрольных кейсах с подменой источника поймал все 50. По общему F1 для блокировки (0.802) он обошёл MiniCheck (0.783), RAGAS Faithfulness (0.758), AlignScore (0.662) и SummaC-ZS (0.436), при этом только он выдаёт вердикт по каждому утверждению с указанием источника.
Как применить
- Сохраняйте трассу вызовов MCP с идентификаторами источников. Без привязки «утверждение и конкретный tool output» системе нечего сверять.
- Перед развёртыванием прогоните оценки с явным разделением: «подтверждено любым источником из пула» против «подтверждено тем источником, который назван в ответе». Это два разных этапа перед выпуском, и второй ловит перекрёстное смешение источников.
- Добавьте шаг декомпозиции ответа на атомарные утверждения и отдельный NLI-проверщик (проверка следования: следует ли утверждение из источника) для каждого утверждения с привязкой к ID источника.
- Сверяйте названный в ответе источник с фактически подтверждающим. Расхождение блокирует ответ или отправляет его на цикл исправления, а не оставляет «зелёным».
- Проверяйте числа, даты и идентификаторы буквально по тексту источника. Правдоподобная формулировка без точного совпадения не считается подтверждением.
- На пайплайне с похожими источниками заложите второй взгляд: в тесте Multiverse Computing при схожих источниках точный выбор падал только в 50% случаев, и в этих сценариях безопасный запасной ответ предпочтительнее уверенного ответа.