Une architecture contre l’accumulation des hallucinations dans les graphes d’agents

La solution instinctive consiste à ajouter un autre agent critique. C’est précisément ainsi que l’illusion s’amplifie au lieu d’être corrigée.

Si vous avez déjà mis en production un chatbot RAG à un seul agent, vous reconnaissez déjà l’échec : le modèle répond à quelque chose que les documents consultés n’ont jamais mentionné, et il présente cette fabrication avec le même ton de certitude qu’il utilise lorsque la citation est authentique.

Dans une chaîne de traitement multi-agents, cette même défaillance est amplifiée, car on ne traite plus la sortie d’un seul modèle — on a affaire à un réseau entier de modèles. Un planificateur conçoit une sous-objectif. Un chercheur invente une source pour le soutenir. Un analyste extrait un chiffre de cette source inventée. Un rédacteur transforme ce chiffre en une recommandation. Un agent chargé d’appeler des outils exécute ensuite cette recommandation sur votre système de facturation. À chaque transfert, il existe une possibilité pour une supposition d’être présentée comme un fait vérifié.

Les équipes qui développent des systèmes multi-agents de type LangGraph pour des cas d’usage juridiques, financiers et opérationnels se heurtent à un schéma récurrent. Le problème n’est pas que le modèle sous-jacent manque d’intelligence, mais plutôt que le flux de travail lui-même ne dispose d’aucun contrat épistémique. Rien dans le graphe ne force aucun agent à révéler d’où provient une affirmation, quels éléments de preuve pourraient la réfuter, ou ce qui devrait se passer en l’absence de tels éléments. Ainsi, le système fait ce que les modèles linguistiques font toujours en cas de lacune : il génère quelque chose de plausible pour combler cette lacune.

Voici l’architecture à privilégier lorsque la sortie peut transférer de l’argent, influencer une démarche juridique ou arriver dans la boîte de réception d’un client. Il ne s’agit pas d’un tutoriel rapide, et si vous espérez trouver un seul package à installer pour rendre vos agents fiables, vous ne le trouverez pas ici.

Le problème cumulatif pour lequel personne ne prévoit de budget

Chaque appel à un LLM individuel présente un taux de base d’affirmations non étayées — appelons-le p. Lorsque l’on enchaîne cinq étapes d’agents, et que chaque étape peut introduire ou amplifier des affirmations non étayées, le taux d’erreur effectif n’est plus p. Il devient le produit de probabilités conditionnelles, aggravé par un second problème propre aux graphes multi-agents : le transfert d’autorité entre agents.

L’agent B considère la sortie de l’agent A comme un fait établi simplement parce qu’elle est livrée sous forme d’objet JSON structuré portant une étiquette telle que research_findings. Le schéma est validé, les types de champs sont corrects. Or le contenu réel est inventé. Le fait d’être validé par le schéma ne signifie pas pour autant que l’information est vraie, mais la plupart des équipes se contentent d’imposer cette validation.

Trois modèles de défaillance spécifiques apparaissent plus fréquemment dans les déploiements réels que la plupart des documents ne le reconnaissent :

1. Appels à des outils fictifs. Le modèle émet une invocation de fonction qui semble syntaxiquement correcte — quelque chose comme search_matters(client_id=…) — mais vise un outil qui n’existe pas, ou fournit des arguments qui échoueraient si le schéma de l’outil était réellement appliqué. Les couches d’orchestration qui forcent silencieusement l’utilisation de types incompatibles, ou qui permettent au modèle de réessayer avec des arguments légèrement reformulés, entraînent en fait le système à ignorer les lacunes dans les données plutôt qu’à les mettre en évidence.
2. Lavage de données entre agents. Le chercheur se contente d’affirmer « selon le fichier correspondant ». L’analyste qui travaille par la suite n’ouvre jamais vraiment ce fichier. Le rédacteur cite ensuite l’analyste comme source. Lorsqu’un humain examine le résumé final, l’indication initiale a complètement disparu. C’est précisément ainsi qu’une affirmation incertaine se transforme en fait affirmé avec assurance, pouvant donner lieu à une facturation.

Vérifier le théâtre. Les équipes répondent souvent en ajoutant un agent « critique » ou de « vérification » dont la seule tâche est de détecter les hallucinations. Le problème, c’est que ce vérificateur est lui-même un LLM, conditionné par le même contexte — souvent issu de la même famille de modèles — et récompensé implicitement, grâce à la conception de votre demande, pour être conciliant et utile. Un vérificateur optimisé pour être utile aura tendance à confirmer plutôt qu’à remettre en question. Un vérificateur véritablement indépendant a besoin d’une source d’information distincte, d’une fonction objective différente, ainsi que d’un mécanisme de refus moins coûteux qu’un simple accord. Très peu d’architectures offrent réellement cela.

La génération augmentée par récupération ne vous sauve pas de cela. La récupération ne fournit qu’un contexte préalable. Si l’agent de planification n’a jamais formulé la bonne requête, ou si le processus de segmentation a divisé un paragraphe qui aurait pu réfuter l’affirmation en deux embeddings distincts, l’agent chercheur récupérera malgré tout quelque chose qui sonne fluide et est thématiquement proche. Être proche de la bonne réponse n’est pas identique à en être logiquement déduit.

Ce que « ancré » doit signifier, sinon cela ne signifie rien

« Ancré » ne devrait pas être une description vague du style ou du ton. Une affirmation au sein d’un système multi-agents ne peut être considérée comme ancrée que si toutes ces conditions sont remplies :

1. La prétention possède un type explicite. Elle est étiquetée comme une Assertion, une Conjecture, une Citation ou une ActionIntent. Mélanger ces catégories dans un seul champ de texte non typé est précisément ce qui fait échouer les traçabilités.
2. Chaque Assertion renvoie à un enregistrement de provenance — un passage extrait, une sortie d’outil ou un fait fourni directement par un humain. Ce lien est un hash de contenu, jamais une URL inventée par le modèle de son propre chef.
3. Une vérification déterministe, non basée sur un LLM, a confirmé que l’enregistrement de provenance mentionné existe réellement quelque part dans le registre de l’exécution. Vérifier l’existence est peu coûteux ; vérifier la conséquence en déduit n’est pas le cas. Ces deux vérifications sont nécessaires, et dans cet ordre précis.

Lorsqu’une vérification échoue, le système s’abstient ou demande des précisions. Il ne réécrit pas silencieusement la requête tant que sa formulation n’est pas suffisamment convaincante pour être acceptée.

Une architecture incapable de refuser une réponse est incapable d’être fiablement honnête. La génération constitue par défaut le chemin de moindre résistance ; l’abstention doit être intégrée explicitement comme un état de premier ordre dans le graphe — et il doit être plus simple d’y parvenir que de simplement réessayer avec une autre demande.

Telle est l’idée de base. Tout le reste relève de l’ingénierie nécessaire pour que ces quatre règles soient respectées une fois que LangGraph, les appels vers des outils réels et un chef de produit exigeant que la démonstration produise toujours une réponse sont mis en œuvre.

Le plan de contrôle, pas la demande

Traitez vos agents comme un environnement d’exécution non fiable et enveloppez-les dans un plan de contrôle. Ce plan se compose de six composants. En omettant l’un d’eux, les autres fonctionnent progressivement de manière dégradée.

1. Bus d’outils typés

Chaque outil dispose d’un schéma JSON versionné pour les entrées et les sorties, stocké dans un registre que le modèle n’a pas le droit de modifier. Le modèle peut proposer une requête, mais un validateur déterministe doit l’accepter ou la rejeter avant que quoi que ce soit ne se produise. Aucune coercition de type, aucune correspondance « suffisamment bonne » entre une valeur d’enum et ce que le modèle a généré. Si la requête est invalide, elle revient au planificateur sous forme d’erreur structurée — jamais sous forme de réprimande verbale.

Cela semble être une exigence évidente, pourtant c’est justement ce que la plupart des démonstrations de CrewAI ou AutoGen omettent, car aucune démonstration ne rencontre jamais d’outil qui écrit réellement dans un registre permanent.

Pour tout outil ayant des conséquences irréversibles — envoyer quelque chose, écrire un fichier, déployer ou mettre à jour un système de registre — le mécanisme de communication doit exiger un contrôle double : un ClaimSet ayant déjà été vérifié, ainsi que soit une approbation humaine, soit une autorisation explicite définie par la politique. Selon cette conception, l’agent opérateur n’a jamais de accès direct à ces outils.

2. Registre de citations en écriture seule

Chaque résultat de recherche, chaque sortie d’outil, chaque fait fourni par un humain est enregistré dans un stockage en écriture seule, indexé par run_id et un hash de contenu. Les agents ne sont pas autorisés à simplement « mémoriser » une source dans leur propre espace de travail — ils doivent au contraire citer les IDs du registre.

Si un agent écrivain génère une phrase sans identifiant de registre associé, cette phrase n’est absolument pas une affirmation. Il s’agit de texte non étiqueté, et il ne devrait jamais être autorisé à passer par une porte de schéma. C’est sans doute la solution la plus efficace que l’on puisse appliquer à un graphe d’agents existant : cesser de permettre à du texte libre de forme de quitter le système sous prétexte d’être des données.

Le hachage est également important ici. Un modèle peut citer doc:matter-4421#p3 tout en citant incorrectement ce qui est réellement écrit à la page 3. Le registre doit stocker le texte exact — ou au moins un pointeur vers un stock d’objets immuables — afin que le vérificateur compare ces octets précis, et non ce dont se souvient le modèle.

3. Porte de schéma (non-LLM)

Au préalable de tout transfert d’un artefact vers l’agent suivant — qu’il s’agisse d’un résumé de recherche, d’une figure calculée ou d’une action suggérée — celui-ci doit passer une validation selon un schéma qui comprend :

• un tableau claims[], dont chaque élément contient des valeurs pour type, text, ledger_ids[] ainsi qu’une valeur confidence qui sera calibrée ultérieurement, au lieu d’être simplement déclarée comme « élevée » par le modèle
• un tableau open_questions[] que le planificateur doit soit résoudre, soit transmettre explicitement à un niveau supérieur
• un tableau action_intents[] qui fait référence à un outil nommé, et non à un paragraphe vague suggérant « nous devrions probablement... »

Cette étape doit être implémentée avec du code ordinaire — Pydantic, JSON Schema, une politique CEL ou Rego, selon votre choix. Il ne doit pas s’agir d’un LLM. Si vous y mettez un modèle de langage, vous n’avez fait qu’installer à nouveau le mécanisme critic-agent à un niveau inférieur.

4. Vérificateur de prétentions avec un ensemble d’informations différent

C’est ici que réside le véritable coût. Prenez chaque Assertion et divisez-la en ses plus petites parties vérifiables, de sorte que chaque partie désigne un sujet, une relation ou une propriété, ainsi qu’un point ou une période dans le temps. Pour chacune de ces parties, obtenez les preuves correspondantes uniquement à partir du registre, jamais à partir d’une recherche en ligne en temps réel et jamais à partir des paramètres du modèle lui-même.

Ensuite, effectuez une vérification d’entaillement : le segment obtenu soutient-il la proposition, la contredit-il, ou ne dit-il rien à son sujet ? Vous pouvez mettre en œuvre cette vérification avec un petit modèle NLI, un décodeur restreint qui ne peut copier que depuis le segment, ou un réviseur humain. Ce que vous ne pouvez pas faire, c’est confier cette tâche au même grand modèle de chat, en utilisant le même prompt système, et lui demander si l’affirmation « semble correcte ».

Lorsqu’une demande est rejetée, personne ne modifie discrètement son formulation pour la faire accepter lors de la prochaine tentative. Elle revient alors sous la forme Unsupported{proposition, missing_evidence}, et il incombe au planificateur de trouver davantage de preuves, plutôt que de reformuler le problème pour l’éviter.

Cette étape permet également de détecter un échec plus subtil : remplacer une affirmation vague et non falsifiable par une autre qui semble seulement rigoureuse. Dire qu’une facture semble surestimée n’est pas en soi une affirmation vérifiable. Ce n’est qu’en la liant à un montant précis — en indiquant l’élément de la facture, le plafond contractuel dépassé, le montant excédentaire par rapport à ce plafond, ainsi que les écritures comptables qui étayent ces éléments — qu’on la transforme en quelque chose que le vérificateur peut réellement confirmer ou rejeter. Un schéma qui accepte la première forme, plus vague, se retrouvera à valider le ton plutôt que les faits.

5. Évaluer l’ensemble sur des traces concrètes, pas sur des impressions

Il vous faut un ensemble de référence congelé : des entrées, des captures d’écran du registre, les affirmations que l’on pourrait attendre ainsi que les abstentions prévues. Chaque modification apportée au graphe — une édition d’instruction, un changement de modèle, un autre outil de segmentation, un nouvel outil — est évaluée selon les critères suivants :

• Fidélité : quelle fraction des affirmations générées est réellement impliquée par le registre
• Couverture : quelle fraction des affirmations attendues a réellement été produite par le graphe, étant donné que rester silencieux peut lui aussi constituer une défaillance
• Précision des abstentions : lorsque le système refuse de répondre, cette refus est-elle réellement justifiée
• Hygiène des effets secondaires : zéro appel d’outil irréversible exécuté sans autorisation valide

Si une baisse de deux points en termes de fidélité ne peut pas empêcher un déploiement, vous n’avez pas de plan de contrôle — vous disposez simplement d’un tableau de bord qui donne une impression rassurante.

Quoi que vous fassiez, ne créez pas cet ensemble d’évaluation à partir des sorties passées du modèle lui-même. Cela revient simplement à encoder le schéma actuel d’hallucination comme vérité absolue. Les traces de référence doivent provenir des documents sources sous-jacents et du système d’enregistrement réel, puis le graphe doit être exécuté indépendamment sur ceux-ci. Cette méthode est plus lente, mais c’est la seule version de cette métrique qui ait réellement un sens.

6. HITL sur le bord irréversible

Un évaluateur humain n’est pas là pour rendre les agents plus intelligents. Son rôle est de se trouver précisément au moment où le système s’apprête à envoyer un e-mail, à enregistrer un document ou à modifier une entrée. L’interface d’évaluation doit afficher l’ensemble des affirmations, les périodes de registre pertinentes ainsi que la requête d’outil en attente — et non un mur d’historique de conversation. Si quelqu’un doit faire du reverse engineering pour comprendre pourquoi l’agent a cru à un fait donné, la conception a déjà échoué dans sa mission.

Pour les processus à fort débit — l’examen des factures en est un bon exemple — l’analyse par un humain doit être effectuée de manière aléatoire et déclenchée uniquement en cas d’exceptions, plutôt que d’être appliquée à tout. Le système doit approuver automatiquement lorsque toutes les affirmations sont pleinement confirmées et que la variation financière se situe dans une fourchette acceptable. Tout le reste est marqué, et seules les prétentions non étayées sont mises en évidence, pas l’ensemble du document.

Un aperçu du contrat, pas de sa mise en œuvre

C’est à peu près à quoi devrait ressembler l’objet transmis entre les agents. La logique d’orchestration, la pile de vérification NLI, la couche de stockage du registre comptable ainsi que le composant qui émet les autorisations sont délibérément omis — ils sont spécifiques à la mise en œuvre et relèvent du code de production, pas d’un article de blog.

{
  "run_id": "run_7f3c",
  "from_agent": "analyst",
  "claims": [
    {
      "id": "c_19",
      "type": "Assertion",
      "text": "Line item 14 exceeds the engagement-letter hourly cap.",
      "propositions": [
        {
          "id": "p_19a",
          "pred": "exceeds_cap",
          "args": {"line_id": "14", "cap_source": "engagement_letter"},
          "ledger_ids": ["led_aa12", "led_bb90"],
          "entailment": null
        }
      ]
    }
  ],
  "open_questions": [],
  "action_intents": [
    {
      "tool": "flag_invoice_line",
      "args": {"invoice_id": "INV-4421", "line_id": "14"},
      "requires_grant": true,
      "depends_on": ["c_19"]
    }
  ]
}

Remarquez ce qui manque : il n’y a pas de champ summary que l’agent suivant puisse citer directement. Ce sont précisément les résumés où les qualifications et les réserves disparaissent. Si un agent ultérieur a besoin de texte narratif, il doit le construire entièrement à partir d’affirmations vérifiées, et tant qu’un humain ne l’a pas approuvé comme texte destiné au client, il est étiqueté Conjecture.

Remarquez également que entailment est défini sur null. L’agent qui a rédigé l’affirmation n’a pas le droit de remplir ce champ lui-même — seul le vérificateur peut le faire. Permettre à un agent d’évaluer ses propres affirmations, c’est comme laisser une entreprise mener sa propre audit de conformité en prétendant qu’il s’agit d’une surveillance indépendante.

Pourquoi « il suffit d’ajouter des citations » échoue encore

La mesure de sécurité frauduleuse la plus courante consiste en des sorties qui semblent seulement citées. Le modèle ajoute un [1] ou un [2], parfois en indiquant même un fragment réel récupéré. Ensuite, on ouvre ce fragment pour découvrir qu’il ne soutient pas réellement l’affirmation avancée.

Une citation à elle seule ne prouve rien. Une preuve réelle ressemble à ceci : cette portion spécifique de texte, cet ensemble exact de bytes, associé à une proposition précise, portant une étiquette d’implication logique, régie par une politique explicite définissant ce qui se passe lorsque cette étiquette est neutral. Sans toute cette chaîne, une « citation » n’est qu’un choix de mise en forme déguisé en preuve.

La deuxième mesure de sécurité frauduleuse consiste à mettre la température à 0. Cela ne rend pas les sorties plus fidèles à la réalité — cela ne fait que rendre une réponse fausse cohérente. Une hallucination stable réussira toujours les tests de capture d’écran. Elle ne survivra pas à un registre correctement tenu.

Quel en est le coût, honnêtement

Mettre en marche un pipeline de démonstration avec LangGraph ne prend que quelques jours. En revanche, développer le plan de contrôle sous-jacent — un registre d’outils, un livre de citations, des filtres de schéma, un vérificateur basé sur l’NLI, des évaluations de référence, une révision humaine pour chaque chemin permettant d’écrire des données, ainsi que des journaux suffisamment détaillés pour être compris par un avocat — c’est ce qui distingue un prototype fonctionnel d’un système fiable pour prendre des décisions commerciales réelles.

Il n’existe pas de chiffre unique qui s’applique à tous les cas. Le coût réel dépend du nombre d’outils qui provoquent des effets secondaires, du fait que votre source de vérité soit déjà structurée et consultable, ainsi que du coût réel d’une affirmation non étayée dans votre domaine spécifique. La facturation juridique et la production de rapports financiers se situent à l’extrémité du spectre où les coûts sont élevés et les enjeux importants. Un outil de brainstorming conçu à partir d’un essaim d’agents se trouve à l’opposé, et obliger cet outil à gérer autant d’infrastructures serait excessif.

La première question à se poser n’est pas de savoir sur quel framework construire — c’est plutôt de déterminer où se situe votre propre flux de travail dans ce spectre.

Si c’est bien le problème que vous rencontrez

Ce type de plane de contrôle est particulièrement important pour les équipes qui ne peuvent pas accepter une réponse qui semble convaincante mais est fausse : le travail juridique, la finance et les opérations à forte charge documentaire en général. Cela implique des graphes d’agents construits avec des outils comme LangGraph, des pipelines de récupération qui sont réellement évalués plutôt que supposés fonctionner, ainsi que des systèmes d’extraction capables de résister à un audit.

Si votre propre graphique fonctionne de manière convaincante lors d’une démonstration mais commence à produire des affirmations fausses une fois en production, ce problème est presque toujours dû à l’un des six composants abordés ici — et déterminer lequel, ainsi que savoir s’il vaut la peine d’investir du temps en ingénierie pour le corriger, constitue le véritable point de départ pour définir les travaux à effectuer.

Lectures complémentaires

• Concevoir des graphes d’agents IA résilients : tentatives répétées, solutions de secours et GraphRAG — Découvrez comment créer des workflows d’agents IA tolérants aux pannes en utilisant des branches de défaillance explicites, une logique de tentatives répétées, LangGraph, ainsi que les cas où GraphRAG surpasse le RAG classique ou les boucles d’agent.
• Ce que la construction d’un agent en 10 minutes révèle sur l’architecture vraie — Analyse pourquoi des outils de création rapide d’agents comme TrueForge peuvent cacher des décisions architecturales auxquelles les frameworks manuels tels que Deep Agents vous obligent à faire face.