Правильне джерело, а не лише факт: перевірка з урахуванням джерела для MCP-агентів

Агенти на основі LLM, які використовують інструменти, більше не читають один отриманий фрагмент. Завдяки Model Context Protocol (MCP) агент може викликати інструмент пошуку, переглядати структурований запис про пацієнта або обліковий запис, робити запити до бази даних і отримувати метадані, а потім поєднувати все це в одну відповідь. Це робить звичне питання фактичної точності складнішим, ніж здається. Більшість систем, створених для перевірки відповідей LLM — від faithfulness у RAGAS до детальних перевіряльників на кшталт MiniCheck, AlignScore і SummaC — запитують, чи підтверджується твердження наявними доказами після об'єднання цих доказів. У типовому вигляді вони не повідомляють, який саме результат інструмента MCP підтверджує кожне твердження, і чи є це джерелом, названим у відповіді.

Наша остання стаття, ProvenanceGuard: верифікація фактичності з урахуванням джерел для LLM-агентів на основі MCP (ознайомтеся з нею на 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 в UC Berkeley.

Хочете дізнатися всі технічні подробиці, зокрема виведення для маршрутизації та NLI, абляційні дослідження калібрування, стрес-тести з кількома джерелами та повні таблиці результатів? Ознайомтеся з повною статтею на Hugging Face або зв'яжіться з нашою командою, щоб обговорити застосування верифікації з урахуванням джерел до власних агентів.

Моделі, згадані в цій статті 2

Більше від цього автора