Hallucination IA

Une hallucination IA n’est pas forcément une phrase absurde. Elle peut citer une procédure inexistante, attribuer une clause au mauvais document ou compléter un numéro manquant avec un détail vraisemblable. Le modèle de langage cherche une suite cohérente avec les mots reçus. Il ne possède pas, par défaut, de mécanisme qui confronte cette suite à une source de vérité.

Le risque augmente quand l’utilisateur pose une question ambiguë, demande une certitude sans fournir le contexte ou attend une réponse sur un sujet absent du corpus. Des consignes contradictoires, un extrait tronqué et une documentation périmée peuvent aussi pousser le système à combler un vide plutôt qu’à signaler sa limite.

• Erreur factuelle : une date, une règle ou une référence est inventée.
• Erreur d’attribution : une information exacte est rattachée au mauvais client, contrat ou produit.
• Erreur de portée : une exception devient une règle générale.
• Fausse citation : le système donne l’apparence d’une source qui ne contient pas l’affirmation.

La fluidité d’une réponse ne constitue jamais une preuve. Un bon parcours distingue la génération de texte, les documents dont elle s’appuie et la décision prise par l’utilisateur. Comprendre cette séparation est plus utile que demander au modèle d’être prudent sans changer son contexte.

Dans un atelier de formation IA, les équipes apprennent à repérer les formulations qui demandent une vérification : affirmation très précise sans référence, réponse hors périmètre ou conclusion formulée malgré des données incomplètes.

On réduit une hallucination IA en limitant ce que le système doit deviner. Pour une réponse documentaire, un RAG peut rechercher des passages pertinents, les transmettre au modèle et afficher les sources à l’utilisateur. Cette architecture ne garantit pas que la recherche a trouvé le bon passage ni que la synthèse le respecte, mais elle donne un point de contrôle concret.

La consigne doit préciser le comportement attendu quand une preuve manque. Demander une question de clarification, une réponse « non trouvé dans les documents fournis » ou l’escalade vers une personne compétente est souvent préférable à une réponse générale. Le prompt engineering sert ici à écrire ces règles de refus, de citation et de format de manière testable.

1. Rassemblez les questions réellement reçues par les utilisateurs.
2. Identifiez la source autoritative de chaque réponse et son propriétaire.
3. Testez la recherche, la sélection des extraits et la réponse comme trois étapes distinctes.
4. Affichez un lien ou un extrait qui permet de contrôler les assertions importantes.

Une réponse sans résultat est parfois le bon résultat. Un assistant de support qui ne trouve pas la procédure applicable doit savoir l’indiquer et orienter l’utilisateur vers le canal prévu. Cette discipline évite que l’outil installe progressivement des habitudes fondées sur des réponses seulement plausibles.

Pour un chatbot d’entreprise, les tests doivent contenir des demandes adverses, des termes métier proches et des documents retirés. Ils révèlent autant les défauts de recherche que les défauts de génération.

Le niveau de contrôle dépend de l’action qui suit la réponse. Un brouillon de message peut être relu par son auteur avant envoi. Une instruction qui affecte un paiement, un contrat, un recrutement, une décision de santé ou un accès à des données exige un cadre plus strict. Dans ces cas, l’outil peut assister la préparation, mais il ne doit pas présenter sa conclusion comme une décision autonome.

La conception doit définir qui revoit quoi, selon quel document et dans quel délai. Elle doit aussi prévoir un moyen de signaler une erreur, de corriger le corpus et de retrouver la version de l’assistant qui a répondu. La journalisation est utile lorsqu’elle documente le contexte, la source consultée et le geste humain ; elle n’est pas une garantie si personne ne l’examine.

• Limitez d’abord le périmètre aux questions dont les réponses peuvent être vérifiées.
• Écrivez des scénarios d’abstention avant de mesurer la qualité des réponses utiles.
• Révisez les erreurs signalées pour distinguer un défaut de source, de recherche ou de consigne.
• Retirez une fonction lorsque l’équipe ne peut plus assurer la vérification attendue.

Nous déconseillons d’automatiser une décision sensible sur la seule base d’un texte généré. Un audit IA peut cartographier les conséquences d’une erreur et définir le contrôle proportionné. L’objectif n’est pas de promettre zéro hallucination, mais de rendre les erreurs détectables, corrigeables et sans effet disproportionné.

Un pilote doit être arrêté ou réduit si les utilisateurs contournent les vérifications pour gagner du temps. Cette observation dit davantage sur la conception du service qu’un tableau de démonstration.