Un fait peut être exact et pourtant attribué à la mauvaise source. C’est le piège que ProvenanceGuard, présenté par une équipe de Multiverse Computing sur Hugging Face, cherche à repérer chez les agents qui utilisent plusieurs outils via MCP. Voici comment il fonctionne, ce que ses tests montrent et ce que l’article laisse ouvert.
En bref
- Il vérifie, après la réponse, que chaque affirmation vient de la source citée
- Sur 361 affirmations relues par des experts, il en a repéré 138 sur 139 à bloquer
- Il fournit un verdict par affirmation, avec la source examinée
- Entre sources très proches, il identifie la bonne source dans 50,3 % des cas
- Les réponses bloquées peuvent être réparées puis revérifiées
Un fait vrai, mais attribué à la mauvaise source
Un agent MCP (du nom du Model Context Protocol) peut appeler plusieurs outils : une recherche, un dossier patient ou client, une base de données. Il mélange ensuite le tout dans une seule réponse. Les vérificateurs habituels, comme RAGAS faithfulness, MiniCheck, AlignScore ou SummaC, se demandent si une affirmation est soutenue par l’ensemble des éléments réunis. Dans leur forme usuelle, ils n’indiquent pas quelle sortie d’outil la soutient, ni si c’est la source que la réponse nomme.
Les auteurs appellent cross-source conflation le cas où une affirmation est vraie quelque part dans les éléments, mais attribuée à une autre source. Un vérificateur qui ignore les sources peut la laisser passer, puisque le fait existe bien dans l’ensemble.
Un exemple concret
L’article prend un agent de support client qui répond : « D’après le dossier du compte, ce forfait inclut un délai de remboursement de 30 jours. » Ce délai peut être réel, mais écrit dans un document de politique commerciale et non dans le dossier cité. Une fois les deux sources mélangées, l’affirmation semble soutenue ; séparées, l’attribution est fausse.
Les auteurs ajoutent que, dans un cadre sensible, une mauvaise attribution peut être aussi dommageable qu’un fait faux. Ils citent un agent clinique : un détail de traitement propre à un patient devient trompeur dès que la réponse le présente comme un résultat de la littérature médicale.
Comment fonctionne ProvenanceGuard
ProvenanceGuard est une couche de vérification placée après la génération, au-dessus d’un agent considéré comme une boîte noire. Il lit la trace MCP capturée, avec les sorties d’outils et leurs identifiants de source, sans réentraîner l’agent. L’identité de la source est conservée à chaque étape au lieu d’être fondue dans un contexte anonyme.
Pour les expériences, des modèles locaux ont été utilisés afin de traiter les traces hors ligne. Les auteurs précisent que ces modèles sont la configuration évaluée, pas une obligation : elle peut être adaptée à des modèles hébergés, mais demanderait ses propres tests et son propre calibrage.
- Découper la réponse en affirmations précises
- Trouver la source la plus pertinente pour chacune
- Vérifier que cette source soutient l’affirmation
- Comparer cette source à celle que la réponse nomme ou suggère
- Rendre un verdict par affirmation et une décision globale : autoriser ou bloquer
Les modèles utilisés dans l’étude
MiniLM aide à trouver la source pertinente, un modèle DeBERTa de type NLI (qui juge si un texte en soutient un autre) vérifie le soutien, et un modèle de langage local aide à découper les réponses. Le vérificateur contrôle aussi les valeurs littérales : un nombre, une date ou un identifiant absent de la source ne passe pas, même si la phrase paraît plausible.
Une étape de décision calibrée combine ces signaux. Si la réponse est bloquée, une étape de réparation de type RARR peut proposer une révision fondée sur la source, ou un texte de repli prudent, que le vérificateur contrôle de nouveau.
Les résultats chiffrés
Le test porte sur 281 traces réelles d’un agent médical utilisant dossiers patients, articles de recherche et autres outils. Pour l’évaluation principale, des experts ont relu 361 affirmations issues de 40 réponses tenues à l’écart des données de développement. Ils jugeaient que 139 ne devaient pas passer ; ProvenanceGuard en a bloqué 138. Il a aussi retenu 67 affirmations que les experts jugeaient soutenues, envoyées en relecture ou réparation : un réglage prudent. Pour les affirmations à source identifiable, il a choisi la bonne source environ 86 % du temps.
Sur le F1 de rejet (une mesure qui combine blocages justes et blocages inutiles), il obtient 0,802, contre 0,783 pour MiniCheck, 0,758 pour RAGAS Faithfulness, 0,662 pour AlignScore et 0,436 pour SummaC-ZS. Seul ProvenanceGuard indique la source reliée à chaque affirmation.
Dans un test où 50 noms de source ont été remplacés en laissant les preuves intactes, les 50 permutations ont été repérées.
- 361 affirmations relues, 139 à bloquer, 138 bloquées
- 67 affirmations soutenues retenues pour relecture ou réparation
- 0,802 de F1 de rejet pour ProvenanceGuard
- 50 permutations de source sur 50 détectées
Quand les sources se ressemblent, et la réparation
Dans un test plus difficile avec plusieurs sources similaires, ProvenanceGuard atteint 0,846 de F1 pour décider quoi bloquer, mais n’identifie la source exacte que dans 50,3 % des cas. Les auteurs reconnaissent que distinguer des sources proches reste un point à améliorer.
Côté réparation, la boucle de type RARR a traité les 173 réponses bloquées de l’essai sur traces complètes, dont 144 se sont terminées par un texte de repli plutôt qu’une vraie réécriture. Sur des traces multi-sources reconstruites, les 59 réponses bloquées ont été résolues avec seulement deux replis. Le surcoût est d’environ une demi-seconde par réponse dans la configuration locale testée.
Ce que l’article ne tranche pas
Une lectrice ou un lecteur dans les commentaires demande une comparaison avec un second modèle de langage utilisé comme juge. L’auteur répond que l’article n’en rapporte pas, et qu’une telle étude serait utile pour mesurer précision, latence et coût. Les résultats viennent d’un agent médical ; l’approche est présentée comme adaptable à d’autres domaines si la trace conserve outils et sources.
Les auteurs mentionnent une reprise de l’approche dans NVIDIA NVFlow, pour un agent financier, et une présentation en poster à l’Agentic AI Summit 2026 à UC Berkeley.
Questions fréquentes
Que signifie « fondé » pour ProvenanceGuard ?
Une affirmation est fondée si elle est soutenue par la source que la réponse nomme ou suggère. La trouver ailleurs dans les sorties d’outils ne suffit pas, comme l’explique l’auteur dans les commentaires.
Faut-il réentraîner l’agent pour l’utiliser ?
Non. ProvenanceGuard s’applique après la génération, sur la trace MCP capturée, et traite l’agent comme une boîte noire.
Que se passe-t-il quand une réponse est bloquée ?
Une étape de réparation de type RARR peut tenter une révision fondée sur la source ou un texte de repli prudent, qui est ensuite revérifié. Dans l’essai sur traces complètes, 144 des 173 réponses bloquées se sont terminées par un repli.
Peut-on l’utiliser avec des modèles hébergés dans le cloud ?
Les auteurs indiquent que les étapes peuvent être adaptées à des modèles hébergés, mais qu’une nouvelle configuration demanderait ses propres tests et son calibrage. Leurs résultats viennent de la configuration locale.
À retenir
ProvenanceGuard conserve l’identité des sources de bout en bout et fournit un verdict par affirmation : il a repéré 138 des 139 affirmations à bloquer dans le test principal, sur des traces d’agent médical. Il identifie moins bien la source exacte quand plusieurs sources se ressemblent (50,3 %), et l’article ne compare pas la méthode à un second modèle utilisé comme juge.
