Hallucination en IA : définition et moyens de reconnaître une réponse non étayée

Définition : une sortie qui n’est pas étayée

En intelligence artificielle, une hallucination est une sortie qui présente des informations erronées, inventées ou non étayées par les éléments disponibles pour la tâche. Cette définition est opérationnelle : elle décrit le rapport entre ce que produit le système, ce qui lui a été demandé et les sources ou données qu’il devait utiliser. Elle n’implique pas que le système ait une expérience consciente, qu’il perçoive quelque chose qui n’existe pas ou qu’il décide de tromper la personne qui l’interroge.

Le terme est employé de différentes manières dans la recherche. Certains travaux mettent l’accent sur le manque de fidélité à une source ou à un contexte fourni ; d’autres, sur les affirmations fausses ou invérifiables. Il est donc utile de préciser le critère retenu. Une réponse peut contredire un document, ne pas être étayée par les sources disponibles ou être factuellement fausse. Ces problèmes sont liés, mais ne sont pas identiques.

La distinction entre « faux » et « non étayé » est importante. Si une réponse affirme qu’un contrat contient une clause absente du document, cette attribution n’est pas étayée et peut être vérifiée en comparant la réponse au texte. En revanche, si une réponse avance une affirmation sans qu’aucune source soit fournie, le seul contexte ne permet pas toujours de savoir si elle est fausse : elle peut être vraie, fausse ou indéterminée. L’insuffisance des éléments disponibles ne prouve pas automatiquement le contraire.

Dans cette fiche, « hallucination » désigne une affirmation présentée comme fiable alors qu’elle n’est pas justifiée au regard du critère et des éléments pertinents. Ce critère peut être la correspondance avec un texte, la validité d’un calcul, l’existence d’une fonction dans une bibliothèque ou la concordance avec des sources faisant autorité. L’évaluation doit préciser ce qui a été vérifié, plutôt que de qualifier toute une réponse de vraie ou de fausse.

Comment une sortie non étayée peut apparaître et quelle partie du système peut être en cause

Un système génératif produit une réponse à partir de l’entrée, du contexte et des régularités qu’il a apprises. Le résultat peut sembler cohérent tout en comportant des détails qui ne découlent pas de ces éléments. Une question ambiguë, des informations insuffisantes ou une instruction qui présuppose quelque chose de faux peuvent compliquer la production d’une réponse fondée. Ces facteurs n’expliquent pas à eux seuls tous les cas et ne permettent pas de déduire une cause précise du seul texte final.

Dans un système de génération augmentée par récupération, ou RAG, des documents ou des passages sont recherchés afin d’être intégrés au contexte du modèle. La chaîne peut échouer à plusieurs endroits : la recherche peut ne pas trouver la source pertinente, récupérer des éléments inadéquats ou présenter des extraits biaisés ; ensuite, le modèle peut mal interpréter les éléments récupérés, ajouter des affirmations absentes de ceux-ci ou attribuer une idée à la mauvaise source. Une réponse erronée ne prouve donc pas, à elle seule, que le modèle génératif en est l’unique cause.

Le système peut également faire appel à des outils externes : calculatrice, moteur de recherche, base de données ou programme exécuté. Le résultat peut être erroné parce que l’outil a renvoyé des données inadéquates, qu’il a été mal utilisé, que le système a mal interprété sa sortie ou que la réponse finale a décrit quelque chose que l’outil n’avait pas confirmé. Pour évaluer le résultat, il faut examiner toute la chaîne lorsque celle-ci est disponible.

Les tâches multimodales ajoutent des entrées sous forme d’image, d’audio ou d’autres formats. Une description peut attribuer à une image un détail qui n’y est pas clairement visible, transcrire un mot de travers ou présenter une interprétation comme s’il s’agissait d’une observation. L’évaluation doit s’appuyer sur l’entrée correspondante et distinguer ce qui y figure réellement de ce que le système en déduit.

Des distinctions qui évitent les diagnostics imprécis

Une fausseté factuelle est une affirmation qui contredit des faits vérifiables. Une affirmation non étayée est une affirmation pour laquelle des éléments suffisants n’ont pas été établis dans le corpus pertinent. Elle peut se révéler fausse, mais elle peut aussi être vraie et simplement non démontrée dans le contexte examiné. Pour établir une contradiction, il faut une référence adéquate ; pour signaler un manque d’appui, il suffit de montrer que la source ou le document censé justifier l’affirmation ne la contient pas, si tel est le critère de la tâche.

Une inférence invalide franchit une étape qui ne découle pas des prémisses, même si chacune de celles-ci est correcte. Une erreur d’attribution consiste à associer une phrase, une conclusion ou une donnée à une source qui ne l’étaye pas. Une citation inexistante est un cas particulièrement vérifiable : on peut rechercher le passage, contrôler son emplacement et vérifier s’il dit bien ce qui lui est attribué. Une citation présentée sous une forme convaincante n’est pas pour autant authentique ou pertinente.

Le biais désigne des régularités systématiques susceptibles de produire des résultats inégaux ou de favoriser certaines représentations. Ce n’est pas un synonyme d’hallucination : une réponse peut être biaisée sans inventer un fait précis, et une affirmation inventée ne suffit pas à démontrer un biais systématique. L’aléatoire, quant à lui, concerne les variations entre les sorties. Le fait que deux réponses diffèrent ne suffit pas à établir que l’une d’elles est une hallucination : il faut examiner son contenu et les éléments qui l’étayent.

La désinformation implique généralement la diffusion d’informations fausses ou trompeuses et, dans certains usages, une intention de tromper. Qualifier une sortie de modèle d’« hallucination » ne prouve aucune intention. Le terme décrit le résultat observé, non un objectif humain du système. De même, un désaccord entre des sources ne montre pas automatiquement qu’une réponse a été inventée : il peut s’expliquer par des définitions différentes, des dates distinctes ou une véritable controverse.

Un échec de la récupération n’est pas non plus identique à une hallucination produite lors de la génération. Si le système trouve des documents non pertinents et répond fidèlement à leur contenu, le problème peut se situer dans la récupération ou le corpus, même si la réponse ne convient pas à la question. Si le modèle ajoute des informations absentes, il existe aussi un problème d’étayage ou de fidélité. Dans des situations réelles, ces défaillances peuvent se combiner.

Trois exemples concrets

Les exemples qui suivent sont hypothétiques. Il ne s’agit ni d’incidents documentés ni de conseils professionnels. Dans les trois cas, l’essentiel est de comparer une affirmation précise aux éléments pertinents pour la tâche.À

Exemple médical : une contre-indication absente de la source

Imaginons qu’une personne consulte un résumé d’informations pharmacologiques et que le système affirme qu’un médicament est contre-indiqué en association avec un autre. Le terme « contre-indiqué » peut avoir des conséquences importantes : il ne suffit pas que la phrase ait une tournure médicale ou mentionne correctement le nom d’un médicament. Pour vérifier cette affirmation, il faudrait identifier le produit et la source applicable, retrouver l’avertissement exact et déterminer si la portée de l’affirmation correspond bien au texte.

Si le document consulté ne mentionne pas cette contre-indication, on peut dire que l’affirmation n’est pas étayée par ce document. Pour conclure qu’elle est fausse, il faudrait consulter des données cliniques pertinentes et à jour, plutôt que de déduire cette conclusion du silence d’un extrait isolé. Cet exemple ne doit pas non plus être transformé en conseil au patient : en cas de possible interaction ou contre-indication réelle, il convient de s’adresser à un professionnel de santé ou à une source autorisée.

L’évaluation peut décomposer la réponse : les médicaments ont-ils été correctement nommés ? Un avertissement a-t-il été attribué à une source précise ? Cette source contient-elle effectivement cet avertissement ? La formulation exagère-t-elle une précaution ou présente-t-elle une possibilité comme une interdiction absolue ? Un benchmark médical peut aider à comparer des systèmes sur des tâches définies, mais un résultat obtenu sur un ensemble de tests ne permet pas de trancher la correction d’une réponse particulière et ne remplace pas une vérification proportionnée au risque.

Exemple contractuel : attribuer une clause absente

Imaginons un outil qui résume un contrat et affirme qu’il contient une clause de reconduction automatique assortie d’un délai précis. Le moyen le plus direct d’évaluer cette affirmation consiste à rechercher dans le document le texte qui pourrait l’étayer et à examiner les sections pertinentes. Si la clause n’y figure pas, le système ne doit pas la présenter comme un élément du contrat. La conclusion appropriée peut être : « cette clause ne figure pas dans le document fourni », ce qui est plus précis que d’affirmer qu’elle n’existe dans aucune annexe ou version.

Une interprétation peut aussi être discutable sans qu’une clause ait été inventée. Par exemple, une phrase ambiguë peut se prêter à plusieurs lectures juridiques. Il faut alors distinguer le texte littéral, l’interprétation du système et toute conclusion juridique. Citer un numéro de section ne prouve pas davantage que cette section existe ni qu’elle justifie le résumé : il faut vérifier la référence et son contexte.

Cet exemple montre pourquoi la portée de la source compte. Si une seule page a été fournie, l’absence d’une clause sur cette page ne permet pas d’affirmer qu’elle manque dans l’ensemble du contrat. Même si le document entier a été fourni, il peut exister des annexes ou des documents externes qui n’ont pas été inclus. Une évaluation rigoureuse précise les documents examinés et évite de transformer une recherche incomplète en conclusion générale.

Exemple de programmation : décrire une fonction inexistante

Supposons qu’un assistant décrive une fonction d’une bibliothèque et fournisse un appel qui semble plausible, alors que cette fonction n’existe pas dans la version utilisée par le projet. La vraisemblance du nom et des arguments ne suffit pas à valider cet appel. On peut consulter la documentation correspondant à la version concernée, inspecter le code disponible ou exécuter un test minimal dans un environnement contrôlé.

La version et le contexte sont essentiels. Une fonction peut exister dans une version plus récente, dans une extension ou dans un autre module. Constater qu’elle n’apparaît pas dans la documentation d’une version précise permet de circonscrire l’affirmation ; cela ne prouve pas qu’elle n’a jamais existé. Il faut aussi distinguer une explication erronée au sujet d’une API d’un problème d’environnement, d’une dépendance manquante ou d’une configuration incorrecte.

Si la réponse attribue la méthode à une documentation déterminée, la citation peut être vérifiée séparément. Si aucune source n’est mentionnée, le code peut tout de même être testé, mais le résultat d’un test n’apporte des éléments que sur les conditions effectivement testées. Un extrait qui fonctionne dans un cas donné n’est pas pour autant correct, sûr ou compatible avec tous les projets.

Comment évaluer une hallucination potentielle

Il n’existe pas de vérification unique permettant de résoudre tous les types de tâches. L’évaluation commence par la décomposition de la réponse en affirmations vérifiables. Une réponse longue peut mêler des informations correctes, des inférences raisonnables, des détails non étayés et des citations erronées. La juger dans son ensemble rend plus difficile l’identification de ce qui doit être corrigé et des éléments manquants.

Il faut ensuite définir le niveau d’étayage attendu : la réponse devait-elle se limiter à un document, fournir des informations à jour, effectuer un calcul, décrire une image ou résumer des résultats récupérés ? Chaque objectif demande un test différent. Pour une question portant sur un document, la comparaison des passages peut convenir ; pour du code, un test exécutable apporte des éléments sur le comportement éprouvé ; pour des faits actuels, il peut être nécessaire de consulter des sources à jour et faisant autorité.

Dans les systèmes RAG, il est utile de vérifier si chaque affirmation s’appuie sur les passages récupérés et si ceux-ci sont pertinents et suffisants. Un vérificateur de provenance peut aider à relier les affirmations à des extraits, mais ce lien ne démontre pas à lui seul que l’extrait est vrai, actuel ou qu’il s’agit de la source la plus appropriée. Il ne permet pas non plus nécessairement de résoudre les affirmations implicites, les raisonnements complexes ou les informations absentes du corpus.

Les citations et les références doivent être validées en tant qu’éléments concrets : vérifier qu’elles existent, qu’elles proviennent de la source indiquée et qu’elles étayent l’affirmation dans la mesure où celle-ci le prétend. Une citation authentique peut être non pertinente, obsolète ou interprétée hors contexte. À l’inverse, une affirmation peut être correcte même si la citation qui l’accompagne est mal attribuée : il s’agit de défaillances distinctes.

Une vérification humaine est particulièrement importante lorsqu’une erreur risque d’affecter la santé, les droits, les finances, la sécurité ou des décisions difficiles à inverser. L’intensité du contrôle doit être proportionnée à l’impact et à la possibilité de vérifier le résultat. Pour une tâche à faible risque, un test direct peut suffire ; pour une décision à fort impact, la réponse automatisée ne doit pas être considérée comme une vérification indépendante.

Mesures d’atténuation : utiles, mais pas infaillibles

La récupération de sources peut faciliter l’accès aux éléments nécessaires pour répondre et le contrôle des affirmations. Toutefois, récupérer des informations ne garantit ni que la bonne source a été trouvée ni que le modèle l’utilisera fidèlement. Les documents peuvent être incomplets, non pertinents ou contradictoires ; le système peut mal les sélectionner, les interpréter de travers ou ajouter du contenu qui n’y figure pas.

Demander au modèle de dire qu’il ne sait pas ou de s’abstenir lorsqu’il manque de confiance peut réduire certaines réponses spéculatives, mais l’abstention n’est pas pour autant un détecteur infaillible. Le système peut s’abstenir alors que les éléments sont suffisants, ou répondre avec assurance alors qu’ils ne le sont pas. Cette instruction est une mesure de comportement, pas une preuve indépendante de vérité.

Les vérificateurs automatiques peuvent signaler des incohérences, examiner des citations ou comparer une réponse à un ensemble de sources. Leurs résultats dépendent de la tâche, des données et de la méthode employée. Un vérificateur peut manquer une erreur subtile, partager certaines limites avec le générateur ou accepter une source inadaptée. Les évaluations et les benchmarks mesurent des comportements dans des conditions définies ; ils ne certifient pas toutes les réponses futures dans d’autres contextes.

Une publication de recherche d’un fournisseur de modèles avance l’hypothèse que certains mécanismes d’entraînement et d’évaluation pourraient favoriser les réponses devinées plutôt que la reconnaissance de l’incertitude. Cette explication est proposée par ce fournisseur ; elle ne constitue ni une explication universelle ni un consensus indépendant démontré pour chaque cas. Il convient de distinguer une hypothèse sur des causes possibles des éléments concrets permettant d’évaluer une sortie particulière.

Concepts associés et critères pratiques

L’hallucination est liée à d’autres notions du glossaire, mais ne les remplace pas. La fiche sur le grounding traite de la manière dont une réponse s’appuie sur des informations ou un contexte identifiables ; la notion de RAG décrit une architecture qui récupère des éléments pour les intégrer à la génération. Aucun de ces termes n’implique que les affirmations produites soient nécessairement correctes.

L’incertitude concerne les limites de ce qui peut être établi ou le degré de confiance avec lequel une conclusion est avancée. L’exprimer clairement peut aider, mais une formulation prudente ne garantit pas que la réponse soit correctement calibrée. Le fact-checking consiste à confronter des affirmations à des éléments probants ; il peut révéler des erreurs, mais sa qualité dépend du choix des sources et de la question examinée. L’index du glossaire sur les hallucinations permet de trouver ces entrées liées et de distinguer leurs approches.

En pratique, avant d’accepter une réponse, demandez-vous : quelle affirmation précise dois-je utiliser ? Quelle source ou quel test pourrait la confirmer ? La source convient-elle au cas et à la date concernés ? La citation étaye-t-elle réellement ce qui est affirmé ? Quels éléments restent indéterminés ? Si ces questions n’ont pas de réponse, il est plus précis de dire que la réponse n’a pas été vérifiée que de lui attribuer une étiquette définitive.

Pour consigner une vérification, indiquez l’affirmation, les éléments examinés, la méthode de contrôle et le résultat. Employez des catégories circonscrites : étayée par la source examinée, contredite par celle-ci, non étayée dans ce corpus ou impossible à évaluer avec les éléments disponibles. Précisez également la portée, par exemple « dans le document fourni » ou « dans la version testée ». Cette formulation permet de corriger les erreurs sans affirmer davantage que ce que la vérification démontre.

La règle finale est simple : la fluidité, l’assurance du ton, le niveau de détail et une citation d’apparence formelle ne constituent pas des preuves. Une confiance raisonnable repose sur une vérification adaptée à la tâche, à partir de sources pertinentes et en indiquant clairement les limites.

Concepts associés