Да установим правилния източник, а не само факта: проверка с отчитане на източника за MCP агенти

Агентите с LLM, които използват инструменти, вече не четат от един-единствен извлечен откъс. Чрез Model Context Protocol (MCP) един агент може да извика инструмент за търсене, да прегледа структуриран запис за пациент или акаунт, да направи заявка към база данни и да извлече метаданни, след което да вплете всичко това в един отговор. Това прави обичайния въпрос за фактическата достоверност по-сложен, отколкото изглежда. Повечето системи, създадени за проверка на отговори от LLM — от достоверността на RAGAS до детайлни проверяващи инструменти като MiniCheck, AlignScore и SummaC — питат дали дадено твърдение е подкрепено от наличните доказателства, след като тези доказателства са обединени. В обичайния си вид те не ни казват кой изход от MCP инструмент подкрепя всяко твърдение или дали това е източникът, който отговорът посочва.

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

Проблемът: това да е подкрепено някъде не е същото като да е подкрепено от правилния източник

Представете си агент за обслужване на клиенти, който отговаря: „Според записа на акаунта този план включва 30-дневен срок за възстановяване на сумата.“ Срокът за възстановяване може да е напълно реален, но да е посочен в документ с правила, а не в записа на акаунта, към който се позовава отговорът. Ако обединим двата източника, твърдението изглежда подкрепено. Ако ги запазим отделно, приписването е грешно, а в чувствителна по отношение на данните среда грешното приписване може да е също толкова вредно, колкото и грешният факт. Същият модел се проявява и при клиничен агент, когато специфичен за пациента детайл за медикамент, взет от инструмент с историята на пациента, стане подвеждащ в момента, в който отговорът го представи като заключение от медицинската литература.

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

Ето защо оценките за достоверност, колкото и полезни да са, не са достатъчни за 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 засече и петдесетте подмени. Това показва, че може да открива явна грешка в източника, докато по-трудният тест показва предизвикателството при избора между множество правдоподобни източници.

Поправяне на блокирани отговори

Блокирането е полезно само ако има какво да се направи с блокирания отговор. Свързано с цикъла за поправка в стил 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

Още от този автор