4 techniques pour éliminer les hallucinations des agents IA — Graph-RAG, sélection sémantique d'outils, garde-fous neurosymboliques

AWS a documenté quatre manières spécifiques dont les agents produisent des hallucinations lors de l'exécution de tâches. Ils fabricquent des statistiques. Ils choisissent les mauvais outils. Ils ignorent les règles métier. Ils revendiquent la réussite lorsque les opérations échouent en réalité. Dev.to et AWS ont documenté quatre techniques spécifiques qui traitent chaque mode d'échec. Ce blog est le guide technique du praticien pour chacune d'elles : ce qu'elle prévient, comment elle fonctionne, et quand l'utiliser.

Les défenses contre les hallucinations ne sont pas théoriques. Ce sont des techniques éprouvées en production qui réduisent le rayon d'impact au point où les agents peuvent être déployés en toute sécurité sur des tâches métier réelles.

Les quatre modes d'échec et ce qui les traite

Avant les techniques, voici les modes d'échec qu'elles sont conçues pour traiter :

Fabrication de statistiques — l'agent invente des chiffres, des dates et des faits à partir de ses données d'entraînement plutôt qu'à partir de l'état réel du monde. Traité par : Graph-RAG.
Choix des mauvais outils — l'agent sélectionne le mauvais outil pour la tâche ou appelle un outil avec des paramètres incorrects. Traité par : sélection sémantique d'outils.
Ignorance des règles métier — l'agent effectue une action qui violate une politique parce qu'il est entraîné à être utile et rationalise pour contourner les contraintes. Traité par : garde-fous neurosymboliques.
Revendication de succès lors d'échecs opérationnels — l'agent signale qu'une tâche est terminée alors que l'opération sous-jacente a échoué. Traité par : validation multi-agent.

Technique 1 : Graph-RAG pour une récupération de données précise

Le RAG standard récupère des documents d'une base de données vectorielle. L'agent synthétise à partir de ces chunks récupérés. Le problème : les chunks récupérés peuvent être erronés, obsolètes ou contradictoires. L'agent synthétise à partir d'un contexte imparfait et produit une hallucination qui semble plausible parce qu'elle provient d'un matériel source qui avait l'air plausible.

Graph-RAG modifie l'architecture de récupération. Au lieu de récupérer des chunks de texte brut, l'agent interroge un graphe de connaissances structuré où les entités, les relations et les faits sont explicitement représentés sous forme de nœuds et d'arêtes. L'agent demande « quelle est la politique de remboursement d'Acme Corp ? » et obtient une réponse structurée et vérifiée à partir du graphe plutôt qu'un paragraphe qui pourrait contenir des erreurs. Seuls les faits qui existent dans le graphe peuvent être récupérés.

L'implémentation pratique : Neo4j ou Amazon Neptune comme base de données graphe, LangChain ou LlamaIndex pour la couche d'implémentation Graph-RAG, et l'agent interroge via un langage de requête structuré comme Cypher.

Quand utiliser Graph-RAG : lorsque l'exactitude factuelle est non négociable pour des données financières, des spécifications produit, des politiques légales, ou tout ce où une mauvaise réponse a des conséquences réelles. Lorsque vous disposez de données structurées qui peuvent être représentées sous forme de graphe.

Quand ne pas utiliser Graph-RAG : lorsque la synthèse créative est l'objectif, l'écriture et le brainstorming nécessitent que le modèle génère plutôt que récupère. Lorsque le graphe de connaissances est incomplet, les agents tomberont sur des nœuds vides et reviendront à leurs poids de toute façon.

Ce que Graph-RAG prévient : la fabrication de statistiques dans les rapports, les mauvaises informations produit dans les communications clients, les détails de politique inventés dans les réponses de support.

Technique 2 : Sélection sémantique d'outils

Les agents ont une liste d'outils et peuvent appeler n'importe quel outil de leur boîte à outils. Le modèle sélectionne les outils basé sur la similarité sémantique entre la tâche et les descriptions d'outils. Le problème : le modèle pourrait choisir un outil sémantiquement similaire mais contextuellement incorrect. L'agent veut envoyer un message et choisit la mauvaise API de messagerie parce que les deux ont « envoyer » dans leur description. L'agent appelle l'API de développement au lieu de l'API de production.

La sélection sémantique d'outils ajoute une étape de vérification. Avant d'appeler un outil, l'agent vérifie que le schéma d'entrée et de sortie de l'outil est correct pour la tâche spécifique. Au lieu de se fier uniquement au jugement du modèle, la sélection d'outils devient un problème de récupération structuré : trouver l'outil dont l'interface correspond à ce que vous essayez d'accomplir.

L'approche d'implémentation : les schémas d'outils sont structurés avec des définitions d'entrée/sortie explicites. L'agent génère ce qu'il attend comme sortie de l'outil. La similarité sémantique entre la sortie attendue et le schéma d'outil réel est notée. Si le score est en dessous du seuil, l'agent escalade ou refuse d'agir.

Quand utiliser la sélection sémantique d'outils : lorsque l'agent dispose de nombreux outils aux noms similaires ou aux finalités qui se recoupent, lorsque les erreurs d'appel d'outils ont des conséquences réelles comme de mauvais appels API ou de mauvaises modifications de données.

Ce qu'elle prévient : appeler le mauvais point de terminaison API, envoyer un message sur le mauvais canal, soumettre un formulaire à la mauvaise destination, utiliser le mauvais format de données pour un appel d'outil.

Technique 3 : Garde-fous neurosymboliques

Le modèle est entraîné à être utile. Il veut accomplir la tâche. Si la tâche entre en conflit avec une règle métier, le modèle pourrait rationaliser un moyen de la contourner. L'agent reçoit une demande de traitement d'un remboursement et l'exécute parce que les agents utiles accomplissent les tâches, sans vérifier si cela viole la politique de remboursement.

Les garde-fous neurosymboliques combinent le réseau neuronal (le modèle) avec la logique symbolique (les règles). Le modèle génère des sorties. La couche de garde-fous intercepte les sorties qui violent les règles. Contrairement aux invites souples qui tentent de rappeler au modèle de vérifier les politiques, les garde-fous sont des contraintes dures qui se déclenchent indépendamment de la confiance du modèle.

Implémentation : définissez une règle comme du code, si la sortie contient X, bloquez et escaladez. Exemple : si la sortie de l'agent contient un montant en dollars supérieur à 10 000 $, une approbation humaine est requise avant l'envoi. Le garde-fou se déclenche, bloque l'action et routage vers un réviseur humain.

Ce que les garde-fous peuvent appliquer : les règles métier comme les limites de remboursement, les seuils de crédit et les flux de travail d'approbation. Les règles de conformité comme les exigences de traitement des données personnelles, les contraintes de résidence des données et les exigences réglementaires. Les règles de sécurité comme aucune exfiltration de données externes et aucune publication sur les réseaux sociaux sans approbation.

La limitation : les garde-fous doivent être explicitement écrits pour chaque règle. Ils ne se généralisent pas. Une règle qui n'a pas été écrite ne se déclenchera pas.

Ce qu'ils préviennent : les agents qui contournent les politiques de remboursement, l'accès ou l'exfiltration de données non autorisé, les actions qui violent les exigences de conformité.

Technique 4 : Validation multi-agent

L'agent qui exécute la tâche est investi dans son accomplissement. Il rationalisera les signes d'avertissement plutôt que d'admettre l'échec. C'est le biais de complétion, le même biais cognitif que les humains ont. Un agent qui reçoit un signal indiquant que quelque chose s'est mal passé interprétera souvent ce signal d'une manière qui lui permet de continuer plutôt que de s'arrêter.

La validation multi-agent brise cette boucle. L'agent 1, le primaire, exécute la tâche et génère la sortie. L'agent 2, le validateur, examine la sortie de l'agent 1 par rapport à la demande originale. L'agent 2 est spécifiquement invité à trouver les erreurs, les incohérences et les échecs. Si l'agent 2 trouve des problèmes, la tâche est signalée pour révision humaine.

Les dimensions de validation :

L'agent a-t-il fait ce qui était demandé ? Vérification de complétude.
L'agent a-t-il utilisé les données correctes ? Vérification factuelle.
L'agent a-t-il suivi le bon processus ? Vérification de conformité.
L'opération a-t-elle réellement réussi ? Vérification du résultat.

Cette dernière dimension traite la constatation sur les agents qui revendiquent le succès lorsque les opérations échouent.

Quand utiliser la validation multi-agent : pour les opérations à enjeux élevés où l'échec est coûteux, pour les opérations où l'auto-évaluation de l'agent n'est pas fiable.

Le compromis en termes de coût : la validation multi-agent double le coût LLM pour les opérations validées. Utilisez-la pour les opérations à enjeux élevés. Automatisez les opérations à faibles enjeux.

Ce qu'elle prévient : les agents qui revendiquent le succès lorsque les opérations échouent réellement, les faux positifs dans les rapports d'achèvement de tâches, les erreurs que l'agent primaire a rationalisées.

Défense en profondeur — Comment les quatre techniques se combinent

Le modèle de défense multicouche :

Couche 1 : Graph-RAG garantit que les faits sont corrects avant que l'agent n'agisse.

Couche 2 : La sélection sémantique d'outils garantit que le bon outil est appelé correctement.

Couche 3 : Les garde-fous neurosymboliques garantissent que les règles métier ne sont pas violées.

Couche 4 : La validation multi-agent capture tout ce que les trois premières couches ont manqué.

Ce que chaque couche ne capture pas : Graph-RAG ne peut pas prévenir les hallucinations créatives ou les erreurs de synthèse. La sélection sémantique d'outils ne peut pas prévenir les faits incorrects sur quel outil utiliser. Les garde-fous ne peuvent pas capturer les violations de règles pour lesquelles ils n'ont pas été écrits. La validation multi-agent ne peut pas capturer les erreurs dans le validateur lui-même.

Aucune technique seule n'est suffisante. Défense en profondeur : chaque couche capture ce que les autres manquent.

Priorité d'implémentation : commencez par Graph-RAG si l'exactitude factuelle est la préoccupation principale. Ajoutez des garde-fous pour vos types d'actions les plus critiques. Ajoutez la sélection sémantique d'outils lorsque les erreurs d'appel d'outils sont coûteuses. Ajoutez la validation multi-agent pour vos workflows les plus critiques.

Ne déployez pas d'agents sans au moins l'une de ces quatre défenses. Commencez par l'action la plus critique de votre agent et superposez à partir de là.