Les erreurs d’une IA générative ne se corrigent pas toutes de la même façon. Une hallucination ajoute une information non fondée : il faut vérifier les sources. Une erreur de raisonnement produit une conclusion incohérente malgré des faits corrects : il faut rejouer les étapes avec un oracle. Un biais crée un écart systématique entre groupes ou formulations : il faut comparer des séries de cas. Le diagnostic précède donc la mesure de réduction.
Pourquoi le mot « hallucination » est souvent trop vague
Une réponse fausse peut venir d’une source absente, d’une règle mal appliquée, d’une instruction ambiguë, d’un calcul erroné, d’un biais du jeu de données, d’une récupération RAG défaillante ou d’un format tronqué. Appeler toutes ces erreurs « hallucinations » empêche de choisir le bon contrôle.
Le NIST AI Risk Management Framework recommande d’identifier des méthodes et métriques adaptées aux risques, de documenter les incertitudes et de suivre les risques dans le temps. En pratique QA, cela implique une taxonomie d’erreurs, un jeu de référence et une preuve avant/après.
Trois familles d’erreurs à distinguer
Hallucination : information inventée ou non fondée
Une hallucination désigne ici une affirmation présentée comme factuelle alors qu’elle n’est pas étayée par les sources autorisées ou l’oracle applicable.
Exemples : inventer un délai de remboursement, citer une section inexistante, attribuer une règle à une norme qui ne la contient pas ou fabriquer le résultat d’un test non exécuté.
Diagnostic principal : vérifier la provenance de chaque affirmation importante.
Erreur de raisonnement : conclusion incorrecte malgré des faits disponibles
Une erreur de raisonnement désigne une conclusion qui ne découle pas correctement des règles et faits fournis.
Exemples : appliquer la mauvaise borne d’une partition, inverser une priorité entre règles, conclure qu’une combinaison est valide alors qu’elle viole une condition ou effectuer un calcul incorrect.
Diagnostic principal : rejouer les transformations ou calculs avec un oracle indépendant.
Biais : écart systématique entre groupes ou cas comparables
Un biais désigne un écart systématique dans les résultats associé à une caractéristique, un groupe, une formulation ou une représentation, lorsque cet écart est indésirable ou non pertinent pour la tâche.
Un résultat différent n’est pas automatiquement un biais injuste : la différence peut être justifiée par la règle métier. Il faut comparer des cas équivalents, documenter la caractéristique testée et faire évaluer l’impact.
Diagnostic principal : comparer des groupes et des paires de cas contrôlés.
| Famille | Signe observable | Oracle utile | Première mesure |
|---|---|---|---|
| Hallucination | affirmation sans provenance | document d’autorité | citations obligatoires et statut indéterminé |
| Raisonnement | étapes correctes mais conclusion fausse | calcul, table de décision, règle formelle | vérification déterministe |
| Biais | écarts répétés entre cas équivalents | politique et jeu comparatif | tests par paires et analyse par groupe |
Méthode expérimentale pour provoquer et diagnostiquer les erreurs
Étape 1 — Préparer une exigence volontairement incomplète
Objectif : vérifier si le système reconnaît l’incertitude.
Action : retirer une règle nécessaire, par exemple le délai maximal d’un remboursement, tout en conservant une réponse attendue claire : « indéterminé » ou une question.
Résultat attendu : le modèle ne complète pas la valeur manquante.
Erreurs à éviter : choisir une lacune sans impact ; écrire l’oracle après avoir vu la sortie.
Étape 2 — Créer plusieurs variantes du prompt
Objectif : isoler l’effet d’une consigne ou d’un contrôle.
Action : comparer un prompt de base, un prompt avec sources/citations et un prompt avec refus explicite d’inventer.
Résultat attendu : configurations identifiées et comparables.
Erreurs à éviter : changer aussi le modèle, la température et les données ; comparer des formats différents sans normalisation.
Étape 3 — Exécuter plusieurs fois
Objectif : observer la stabilité.
Action : répéter chaque combinaison avec les mêmes paramètres et conserver toutes les sorties.
Résultat attendu : distribution des erreurs, pas seulement un exemple.
Erreurs à éviter : ne garder que la meilleure sortie ; conclure qu’une absence d’erreur sur un essai constitue une garantie.
Étape 4 — Classer chaque échec
Objectif : appliquer la mesure correspondante.
Action : étiqueter hallucination, raisonnement, biais, omission, format, refus ou sécurité, avec preuve et gravité.
Résultat attendu : tableau d’incidents exploitable.
Erreurs à éviter : forcer un cas dans une seule catégorie lorsque plusieurs causes sont possibles ; confondre symptôme et cause racine.
Étape 5 — Tester une mesure de réduction
Objectif : démontrer un effet mesurable.
Action : ajouter une source, une contrainte, une vérification déterministe, un contrôle d’accès ou un jeu comparatif selon le diagnostic.
Résultat attendu : comparaison avant/après sur tout le jeu.
Erreurs à éviter : vérifier seulement le cas qui avait échoué ; accepter une réduction moyenne avec une nouvelle erreur critique.
Prévenir, détecter, limiter et stabiliser
Prévenir
Utilisez des sources autorisées, un contexte pertinent, un format contraint et une séparation nette entre instructions et données. Prévenir réduit les occasions d’erreur mais ne démontre pas leur absence.
Détecter
Exigez des citations vérifiables, utilisez des règles déterministes, comparez à des jeux de référence et organisez une critique indépendante. Une citation n’est utile que si elle soutient réellement l’affirmation.
Limiter
Maintenez une validation humaine pour les décisions à conséquence, accordez les permissions minimales et fixez des seuils de blocage. Une mauvaise réponse ne doit pas pouvoir déclencher automatiquement une action irréversible.
Stabiliser
Contrôlez les paramètres, répétez les exécutions, mesurez les variations et surveillez les régressions. La stabilité d’un format ne garantit toutefois pas l’exactitude du contenu.
Contrôles adaptés aux hallucinations
- restreindre les sources autorisées ;
- demander une référence par affirmation ;
- accepter explicitement la réponse
indéterminé; - vérifier que le passage cité soutient la conclusion ;
- séparer faits, hypothèses et recommandations ;
- comparer à une base de faits construite avant l’exécution ;
- empêcher une sortie non vérifiée de devenir un oracle.
Le NIST Generative AI Profile, publié en juillet 2024, fournit un cadre transversal de gestion des risques GenAI. L’absence totale d’hallucination ne doit pas être promise : le système doit être conçu pour rendre les affirmations vérifiables et limiter l’impact d’une erreur.
Contrôles adaptés aux erreurs de raisonnement
Les explications textuelles du modèle peuvent aider la revue, mais elles ne constituent pas une preuve que le calcul interne est exact. Préférez :
- une fonction déterministe pour les calculs et validations de schéma ;
- une table de décision validée pour les règles combinatoires ;
- un second chemin de calcul indépendant ;
- des cas limites préparés à l’avance ;
- des relations métamorphiques lorsque l’oracle exact est difficile.
Un test métamorphique désigne un test qui vérifie une relation attendue entre plusieurs entrées et sorties lorsque le résultat exact de chaque cas est difficile à connaître. Par exemple, si seul le nom d’un utilisateur change dans une story sans modifier aucune règle, la couverture proposée ne devrait pas changer.
Contrôles adaptés aux biais
Un test de biais commence par une hypothèse et des groupes définis, pas par une impression sur quelques sorties.
- identifier la décision ou le contenu évalué ;
- définir les caractéristiques pertinentes et celles qui ne devraient pas influencer le résultat ;
- créer des paires de cas identiques sauf pour la caractéristique testée ;
- répéter les exécutions ;
- mesurer les écarts par groupe ;
- faire examiner la pertinence et l’impact par les parties concernées ;
- documenter les limites de l’échantillon.
Le NIST AI RMF inclut explicitement l’évaluation et la documentation de la justice et des biais identifiés dans la fonction Measure. Une métrique isolée ne suffit pas à décider qu’un système est « équitable » dans tous les contextes.
Exemple hypothétique 1 — Hallucination dans une user story
La story exige un remboursement « rapide » mais ne contient aucun délai. Sur dix exécutions, le prompt initial propose plusieurs valeurs différentes et les présente comme des critères.
Le diagnostic est une hallucination factuelle : le délai n’a pas de source. La mesure ajoute trois contraintes : chaque valeur doit citer un passage, une absence de règle doit produire indéterminé, et les questions sont séparées des critères. Le jeu complet est rejoué. La réussite correspond à zéro délai inventé et à une question correctement formulée, pas à la sélection de la valeur la plus plausible.
Exemple hypothétique 2 — Erreur de raisonnement sur une remise
La règle validée indique : remise de 10 % si le total est supérieur ou égal à 100 €, puis plafonnement du montant remisé à 30 €. Les faits sont correctement extraits, mais le modèle applique la remise après le plafond sur certains cas.
L’oracle est une fonction déterministe. Les cas 99,99 €, 100 €, 300 € et 400 € sont rejoués. La correction ne consiste pas seulement à demander « réfléchis mieux » : le calcul est délégué à une fonction testée, tandis que le modèle se limite à expliquer la règle et préparer les données.
Exemple hypothétique 3 — Biais de formulation dans la priorisation
Un assistant classe des tickets identiques dont seuls les prénoms ou pronoms diffèrent. Les priorités varient régulièrement entre groupes alors que la règle de sévérité ne dépend pas de ces caractéristiques.
Le test utilise des paires contrôlées, plusieurs formulations et des exécutions répétées. L’équipe vérifie si l’écart persiste, examine le prompt et retire les attributs inutiles de l’entrée. Elle surveille ensuite la performance globale afin qu’une mesure de réduction ne dégrade pas la détection des incidents critiques.
Erreurs fréquentes dans le diagnostic
Utiliser la confiance déclarée par le modèle
Un pourcentage produit dans le texte n’est pas nécessairement calibré. Utilisez des preuves observables et mesurez le comportement sur des cas connus.
Demander au modèle d’expliquer sa propre erreur
Son explication peut être utile comme hypothèse, pas comme analyse causale certaine. Reproduisez l’échec et modifiez une variable à la fois.
Confondre variation et erreur
Deux formulations peuvent être également correctes. Définissez les propriétés obligatoires avant de mesurer la stabilité.
Corriger toutes les erreurs avec un prompt plus long
Un calcul doit parfois être délégué à du code, une donnée doit être ajoutée ou une permission retirée. Le prompt n’est qu’une couche de contrôle.
Oublier les régressions
Une contrainte peut réduire les inventions tout en augmentant les refus ou les omissions. Rejouez le jeu entier et suivez plusieurs métriques.
Conclusion
Le diagnostic transforme une « mauvaise réponse » en problème testable. Vérifiez la source pour une hallucination, rejouez la règle pour un raisonnement erroné et comparez des groupes pour un biais. Commencez par un atelier contrôlé, conservez toutes les exécutions et mesurez chaque réduction sur un jeu de non-régression. Pour auditer un usage GenAI réel, vous pouvez demander un diagnostic QA.