Lorsque les LLM produisent des données structurées, ils peuvent fabriquer des faits d'apparence plausible. Entity Enricher utilise 8 couches de défense pour garantir que vous obtenez des données exactes ou aucune donnée — jamais de fiction énoncée avec assurance.
En texte libre, une phrase hallucinée est manifestement vague. En sortie structurée, un champ halluciné comme "founded_year": 1987 paraît fiable et est presque impossible à distinguer d'une valeur correcte. Trois facteurs rendent cela particulièrement dangereux :
Une valeur JSON hallucinée ressemble exactement à une vraie. Aucune réserve, aucun « approximativement » — juste une donnée nette et assurée qui se trouve être fausse.
Les champs obligatoires forcent le LLM à produire une valeur même lorsqu'il n'a aucune connaissance. Le modèle invente des données plutôt que de laisser un vide dans la structure.
Les données structurées alimentent directement les bases de données, les analyses et les automatisations. Une valeur erronée se propage dans les pipelines sans révision humaine.
| Motif | Exemple | Cause |
|---|---|---|
| Fabrication assurée | "ceo": "John Smith" | Le LLM remplit un champ obligatoire avec un nom plausible |
| Confusion temporelle | "revenue": "$2.3B" | Date limite des données d'entraînement ou confusion entre périodes |
| Confusion d'entités | Attributs de l'entreprise A sur l'entreprise B | Noms similaires dans des données d'entraînement qui se recoupent |
| Valeurs par défaut plausibles | "employees": 500 | Le LLM choisit un nombre « raisonnable » plutôt que d'admettre son ignorance |
| Relations inventées | "subsidiary_of": "Alphabet" | Le LLM déduit une relation qui n'existe pas |
Plusieurs de ces cas relèvent du schéma, non du modèle : une propriété comme revenue laisse ouverts la devise, la période et la portée (groupe ou entité), et un nom désignant quelque chose que l'entité ne possède tout simplement pas ne laisse au modèle rien à rechercher. La vérification d'ambiguïté signale les deux cas, énumère les lectures que la propriété admet et suggère le renommage ou la description qui n'en retient qu'une seule.
Entity Enricher ne repose pas sur une seule technique. Il empile 8 couches de défense indépendantes, chacune ciblant un mode de défaillance différent. Si une couche laisse passer une hallucination, la suivante l'intercepte.
Avant le début de l'enrichissement, un LLM rapide détermine par classification si l'entité correspond au type du schéma. Cela bloque à la source l'hallucination d'une entité entière.
Exemple : « Titan » évalué avec un schéma « Planet » est signalé comme une lune — les modèles d'enrichissement reçoivent ce contexte et utilisent null pour les champs spécifiques aux planètes.
Toutes les stratégies donnent cette instruction au LLM : « Soyez précis et prudent — n'inventez jamais une valeur. » Le modèle déclare les champs qu'il n'a pas pu déterminer au lieu de renseigner des valeurs fictives, et ces déclarations deviennent d'honnêtes valeurs nulles dans la sortie.
Cela répond directement à la pression du schéma — la cause n°1 des hallucinations structurées. Une inconnue déclarée lève aussi l'ambiguïté sur les vraies réponses : un 0 que le modèle assume est une donnée, un 0 déclaré ne l'est pas.
Les propriétés du schéma sont regroupées par domaine d'expertise. Chaque appel LLM ne voit que les champs de son domaine, avec pour instruction de se concentrer exclusivement sur celui-ci.
Un périmètre plus restreint signifie moins d'occasions d'halluciner. Un expert financier ne devine jamais les données réglementaires.
Les propriétés clés (marquées is_key: true) sont mises en évidence dans les prompts pour ancrer le LLM sur les informations d'identification avant de remplir les autres champs.
Cela ancre le modèle sur des faits connus, réduisant la dérive vers des détails inventés.
La sortie de l'enrichissement est validée au regard des types, des formats et de la structure du schéma. Un échec déclenche ModelRetry — l'erreur précise est renvoyée au LLM pour correction, et la réparation est chirurgicale : seules les feuilles erronées sont redemandées, pas la réponse entière.
Jusqu'à 5 tentatives de correction automatique au cours d'une même exécution de l'agent. (La génération de schéma se corrige différemment — étape par étape, avec des solutions de repli déterministes.)
Les champs marqués preserve: true (ID, SKU, identifiants d'import) sont restaurés à leurs valeurs d'entrée d'origine après l'enrichissement — le LLM ne peut pas écraser les données de référence. Les requêtes d'enrichissement doivent fournir une valeur pour chaque champ préservé, afin que rien ne soit jamais fixé à null ni inventé.
Dans les tableaux, les éléments enrichis sont réassociés à vos éléments d'entrée grâce à leurs champs clés ; les éléments découverts par l'IA reçoivent null au lieu d'un identifiant inventé.
Traitement de la même entité par au moins 2 modèles indépendants et comparaison des résultats champ par champ. Les désaccords sont signalés comme des hallucinations potentielles.
Si Claude indique un chiffre d'affaires de 2,3 Md$ et GPT-4 de 1,8 Md$ — ce conflit est détecté et signalé.
Les conflits détectés sont résolus par vote basé sur des règles (majorité, médiane, union) ou par un arbitre LLM dédié qui évalue l'exactitude, l'exhaustivité et la cohérence.
Chaque décision d'arbitrage inclut un raisonnement et un niveau de confiance — une transparence totale sur la façon dont les conflits ont été résolus.
Principe fondamental
Une donnée manquante vaut toujours mieux qu'une donnée erronée. Chaque couche renforce ce principe — le système est conçu pour renvoyer null plutôt qu'une invention plausible.