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 |
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 indiquent au LLM : « Soyez précis et prudent — préférez null plutôt que deviner. » Les champs nullables du schéma donnent au modèle la permission explicite de dire « Je ne sais pas ».
Cela répond directement à la pression de schéma — la cause n° 1 des hallucinations structurées.
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.
8 règles de validation vérifient la sortie du LLM pour détecter les incompatibilités de type, les références invalides et les erreurs structurelles. Une validation échouée déclenche ModelRetry — les erreurs sont renvoyées au LLM pour correction.
Jusqu'à 6 tentatives de correction automatiques au sein d'une même exécution de l'agent. Le LLM corrige ses propres erreurs.
Les champs marqués preserve: true (identifiants, SKU, horodatages) 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.
Champs protégés : identifiants d'entités, codes système (EAN, SKU), identifiants d'import, horodatages de création.
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.