Hallucinations des modèles de langage : pourquoi elles surviennent et comment les limiter

Une réponse plausible n’est pas forcément une information exacte

Une hallucination désigne une réponse produite par un modèle de langage qui paraît cohérente, précise et convaincante, mais qui contient une information fausse, invérifiable ou déformée. Le phénomène peut prendre plusieurs formes : une référence bibliographique inexistante, une date erronée, une fonctionnalité attribuée au mauvais logiciel, un calcul incorrect ou une synthèse qui mélange plusieurs documents.

Le terme hallucination ne signifie pas que le système perçoit une réalité imaginaire. Il décrit plutôt un écart entre la réponse générée et les faits attendus. Un modèle de langage ne consulte pas automatiquement une base de connaissances exhaustive au moment où il répond. Il produit une suite de mots en s’appuyant sur des régularités apprises pendant son entraînement et sur les éléments présents dans la conversation ou dans les documents qui lui sont fournis.

Cette distinction est importante pour l’utilisateur. Une formulation assurée, une réponse longue ou un vocabulaire technique ne constituent pas une preuve de fiabilité. L’aisance rédactionnelle et l’exactitude factuelle sont deux propriétés différentes. Une réponse peut être bien écrite tout en reposant sur une prémisse fausse.

Les organismes de référence en gestion des risques liés à l’intelligence artificielle, dont le National Institute of Standards and Technology avec son AI Risk Management Framework, recommandent d’évaluer les systèmes selon leur contexte d’usage. Une erreur sans conséquence dans une séance de brainstorming n’a pas le même impact qu’une erreur utilisée pour interpréter un contrat, configurer un réseau ou prendre une décision médicale.

Comment un modèle de langage fabrique une réponse

Un modèle de langage traite le texte sous forme de fragments appelés jetons. À chaque étape de la génération, il estime quelles suites sont les plus compatibles avec le contexte fourni. Cette opération permet de produire des phrases fluides et d’exploiter des relations complexes entre les mots, les concepts et les styles de rédaction. Elle ne correspond pas à une consultation consciente d’une encyclopédie interne.

Lors de l’entraînement, le modèle observe de très grandes quantités de textes et ajuste des paramètres afin de mieux prédire les séquences. Il apprend ainsi des structures linguistiques, des associations de concepts et des façons de répondre à une question. Il peut aussi mémoriser certaines informations, mais cette mémoire n’est ni complète, ni toujours à jour, ni organisée comme une base de données vérifiée.

Quand une question demande un nom, une date ou une source peu représentée dans les données d’entraînement, le système peut générer une réponse qui respecte les formes habituelles sans disposer du fait exact. Par exemple, une référence inventée peut comporter un titre crédible, un auteur reconnu et une année plausible parce que ces éléments apparaissent souvent ensemble dans les textes. La structure est convaincante, mais la référence n’existe pas.

Les modèles sont aussi optimisés pour être utiles et suivre les instructions. Cette orientation peut les pousser à répondre même lorsque la demande est ambiguë, impossible ou fondée sur une information fausse. Un système prudent devrait parfois demander une précision ou signaler une limite. Selon sa conception et son réglage, il peut préférer fournir une réponse complète, au risque de combler les lacunes par une supposition.

Probabilité linguistique et vérité factuelle

La probabilité qu’une phrase soit produite ne mesure pas directement sa véracité. Une affirmation souvent rencontrée dans les données peut recevoir une forte probabilité même si elle ne correspond pas au cas particulier décrit par l’utilisateur. À l’inverse, une information exacte mais rare peut être exprimée avec hésitation ou être omise.

Cette différence explique pourquoi demander au modèle d’être certain ne garantit pas une meilleure réponse. La certitude affichée relève de la formulation. Elle ne remplace pas une source, un outil de recherche, un calcul contrôlé ou une validation humaine.

Les principales situations qui favorisent les hallucinations

Les hallucinations ne proviennent pas d’une cause unique. Elles apparaissent lorsque plusieurs facteurs se combinent, notamment la nature de la question, la qualité du contexte et le réglage du système.

• Question ambiguë : un terme peut désigner plusieurs versions d’un logiciel, plusieurs pays ou plusieurs périodes. Si le modèle ne demande pas de précision, il risque de choisir une interprétation inadaptée.
• Information absente ou récente : une nouveauté publiée après la période d’entraînement, une modification de tarification ou une décision récente peut être inconnue du modèle.
• Demande portant sur une entité peu documentée : les noms propres rares, les produits régionaux et les documents internes sont difficiles à traiter sans contenu fourni par l’utilisateur.
• Contexte trop long ou mal structuré : des informations contradictoires, des instructions dispersées ou un document volumineux peuvent réduire l’attention portée aux éléments pertinents.
• Question orientée : une formulation qui présuppose un fait faux peut inciter le modèle à accepter cette prémisse plutôt qu’à la remettre en cause.
• Calcul ou transformation complexe : la génération de texte n’offre pas la même garantie qu’un outil de calcul, un interpréteur de code ou une base de données spécialisée.
• Réglage de génération : une température élevée et des mécanismes favorisant la diversité peuvent produire des formulations originales, mais aussi accroître les écarts factuels dans certaines tâches.

Les erreurs peuvent également se propager au fil d’une conversation. Si une première réponse contient une fausse information et que l’utilisateur la reprend dans un message suivant, le modèle peut traiter cette affirmation comme un élément établi. La conversation devient alors un contexte qui renforce l’erreur.

Les risques concrets pour les particuliers et les professionnels

Le risque le plus courant est la confiance excessive dans une réponse qui semble adaptée. Pour une question générale, l’erreur peut conduire à une mauvaise compréhension. Dans un contexte technique, elle peut provoquer une perte de temps, une configuration incorrecte ou une exposition inutile de données.

En informatique, une commande inventée peut modifier un système ou supprimer des fichiers si elle est exécutée sans lecture préalable. En cybersécurité, une recommandation inexacte peut donner un faux sentiment de protection. Dans le développement logiciel, une bibliothèque imaginaire ou une fonction inexistante peut retarder le diagnostic et introduire une dépendance non maintenue.

Les erreurs touchent aussi les documents produits avec une IA. Une synthèse peut attribuer une idée au mauvais auteur, omettre une réserve importante ou présenter une hypothèse comme un résultat. Dans un environnement professionnel, cette confusion peut affecter la traçabilité, la conformité ou la qualité d’une décision.

Les données personnelles et confidentielles constituent un risque distinct. Même une réponse correcte ne justifie pas de transmettre un mot de passe, une clé d’accès, un dossier client ou un document interne à un service dont les règles de conservation et de réutilisation ne sont pas connues. La lutte contre les hallucinations doit donc être associée à une politique de protection des données.

Le document OWASP Top 10 for Large Language Model Applications classe la production d’informations incorrectes parmi les risques à prendre en compte dans les applications fondées sur les grands modèles de langage. La mesure adaptée dépend du domaine, de la gravité d’une erreur et de la possibilité de vérifier la sortie.

Réduire les erreurs dès la formulation de la demande

Un prompt précis ne transforme pas un modèle en source infaillible, mais il réduit les ambiguïtés et facilite le contrôle. Une demande utile décrit le contexte, le périmètre, le format attendu et le comportement à adopter lorsque l’information manque.

1. Définir le rôle de la réponse : préciser s’il s’agit d’une explication, d’une comparaison, d’une synthèse ou d’une procédure de dépannage.
2. Délimiter le contexte : indiquer le système utilisé, sa version, la période concernée, le pays et les contraintes techniques pertinentes.
3. Fournir les données de référence : copier les extraits utiles dans la demande ou joindre un document dont le contenu peut être consulté par l’outil.
4. Interdire les compléments non vérifiés : demander au modèle de signaler une information absente au lieu de l’inventer.
5. Exiger une séparation : distinguer les faits présents dans le document, les déductions et les points qui nécessitent une vérification.
6. Demander des hypothèses explicites : lorsqu’une donnée manque, faire indiquer l’hypothèse retenue et son influence sur la conclusion.

Une formulation comme analyse ce texte en citant uniquement les éléments présents dans le document est plus contrôlable qu’une demande générale de résumé. Pour une procédure, il est pertinent de demander les prérequis, les effets de chaque étape, les risques et la méthode de retour arrière.

Il faut aussi éviter de transformer une préférence de style en exigence de vérité. Demander une réponse affirmative, définitive ou sans réserve peut réduire la visibilité des incertitudes. Une réponse plus utile expose les limites pertinentes sans noyer l’utilisateur dans des avertissements génériques.

Vérifier une réponse avant de lui faire confiance

La vérification doit être proportionnée à l’enjeu. Elle ne consiste pas à relancer le même modèle avec la question identique, car une seconde réponse peut reproduire la même erreur. Il faut rechercher des éléments indépendants et contrôler la chaîne de raisonnement.

1. Repérer les affirmations vérifiables : dates, chiffres, noms, versions, références, commandes, compatibilités et obligations réglementaires.
2. Contrôler les sources primaires : consulter la documentation officielle du produit, le texte réglementaire, la publication scientifique ou le dépôt de code concerné, selon le sujet.
3. Reproduire les calculs : utiliser une calculatrice, un tableur ou un script relu par une personne compétente. Un modèle peut expliquer une formule tout en se trompant dans son application.
4. Tester dans un environnement isolé : pour une commande ou un morceau de code, utiliser une copie des données, une machine virtuelle ou un environnement de test lorsque cela est possible.
5. Comparer plusieurs sources indépendantes : une affirmation répétée par plusieurs pages qui se recopient n’est pas forcément confirmée.
6. Demander une reformulation critique : faire rechercher les contre-exemples, les conditions d’échec et les informations manquantes.

Pour vérifier une citation, il faut retrouver le document, le passage et le contexte. Une référence qui ne peut être localisée ne doit pas être présentée comme une source. Pour vérifier un conseil de sécurité, il faut examiner sa date, son périmètre et les conditions dans lesquelles il s’applique.

Dans un processus professionnel, conserver la question posée, la version du modèle si elle est connue, les documents transmis et les corrections apportées aide à établir une traçabilité. Cette pratique rend les erreurs visibles et permet d’améliorer les consignes utilisées par la suite.

Ancrer les réponses dans des documents et des outils fiables

La génération augmentée par récupération, souvent appelée RAG, consiste à rechercher des passages pertinents dans une collection de documents avant de demander au modèle de répondre. Le système ne se fonde alors pas uniquement sur les paramètres appris. Il reçoit un contexte sélectionné, généralement accompagné de références internes permettant de remonter au document source.

Cette méthode réduit les erreurs lorsque la collection est à jour, bien indexée et adaptée à la question. Elle ne les supprime pas. Le moteur peut retrouver un mauvais passage, le modèle peut mal interpréter le texte ou la collection peut contenir une information obsolète. La qualité du résultat dépend donc de toute la chaîne, de l’import du document jusqu’à la présentation de la réponse.

Une mise en œuvre robuste comporte plusieurs précautions :

• identifier l’auteur, la date, la version et le périmètre de chaque document ;
• retirer les doublons et signaler les documents remplacés ;
• conserver des passages assez larges pour ne pas supprimer une exception ou une condition ;
• demander une réponse limitée au contexte récupéré lorsque la question porte sur une règle interne ;
• afficher les références utilisées afin de permettre une relecture ;
• prévoir une réponse d’abstention lorsque les documents ne contiennent pas l’information recherchée.

Les outils externes apportent aussi une spécialisation utile. Un moteur de calcul est préférable pour l’arithmétique, une base structurée pour les inventaires et un analyseur de code pour certaines vérifications syntaxiques. Le modèle peut orchestrer ces outils ou expliquer leur résultat, mais il ne doit pas être considéré comme leur remplacement automatique.

Comparer les méthodes de limitation des hallucinations

Ces méthodes sont complémentaires. Abaisser la température ne compense pas l’absence de sources. Ajouter une recherche ne remplace pas l’examen d’une référence. Une validation humaine n’est efficace que si la personne dispose du temps et des éléments nécessaires pour contrôler la réponse, plutôt que de se contenter de relire sa formulation.

Une procédure de travail adaptée aux tâches sensibles

Pour une réponse susceptible d’influencer une décision, une procédure en plusieurs étapes réduit le risque de prendre une sortie générée pour un fait établi.

1. Qualifier l’enjeu : déterminer ce qui pourrait se produire si la réponse est fausse. Une erreur réversible peut être traitée différemment d’une erreur touchant la sécurité, l’argent, les droits ou la confidentialité.
2. Préparer le contexte : rassembler les documents pertinents, supprimer les données personnelles inutiles et préciser les versions concernées.
3. Obtenir une première analyse : demander une réponse structurée, avec les éléments certains, les hypothèses et les inconnues séparés.
4. Contrôler les points critiques : vérifier les affirmations qui conditionnent la conclusion, plutôt que de relire uniquement la grammaire ou le style.
5. Faire relire par une personne compétente : pour une question juridique, médicale, financière ou de sécurité, l’IA ne remplace pas l’expertise requise.
6. Tester avant déploiement : appliquer la procédure sur des cas connus, des cas limites et des exemples volontairement ambigus.
7. Conserver une trace : archiver la version du document, les sources et les corrections lorsque la décision doit être justifiée.

Pour le code et les commandes système, ajouter une étape de sauvegarde et une possibilité de retour arrière. Ne pas exécuter une commande destructive sur une machine de production à partir d’une réponse non vérifiée. Pour les données, tester sur une copie et contrôler les droits d’accès avant toute automatisation.

Construire une culture de vérification au quotidien

La prévention des hallucinations repose moins sur une phrase magique que sur une organisation du travail. Les utilisateurs doivent savoir quelles tâches peuvent être accélérées par une IA et lesquelles exigent un contrôle renforcé. Une synthèse interne, une aide à la reformulation et une liste de pistes ne présentent pas le même niveau de risque qu’une instruction opérationnelle.

Il est utile de définir des règles claires : quelles données ne doivent jamais être transmises, quelles sources sont acceptées, qui valide une réponse sensible, comment signaler une erreur et combien de temps les documents sont conservés. Ces règles concernent aussi les extensions de navigateur, les assistants intégrés aux suites bureautiques et les outils qui envoient automatiquement le contenu sélectionné vers un service externe.

Les équipes peuvent constituer un jeu de tests avec des questions fréquentes, des cas ambigus et des exemples où une réponse d’abstention est attendue. Chaque modification importante d’un prompt, d’un modèle ou d’une base documentaire peut alors être évaluée sur les mêmes cas. Cette démarche ne prouve pas que le système est exact dans toutes les situations, mais elle révèle les régressions et les limites connues.

Pour l’utilisateur individuel, trois réflexes offrent déjà une protection importante : considérer toute information précise comme à vérifier, demander les conditions et les limites d’une recommandation, puis retrouver la source avant d’agir. Une IA peut accélérer la recherche d’une piste ou la compréhension d’un sujet. La responsabilité de confirmer un fait et d’évaluer ses conséquences reste distincte de la génération du texte.

FAQ : comprendre et limiter les hallucinations

Une hallucination signifie-t-elle que toute réponse est fausse ?

Non. Une réponse peut être correcte, partiellement correcte ou fausse. Le problème vient du fait que la formulation ne permet pas toujours de distinguer ces cas. La fiabilité doit être évaluée en fonction du sujet, de la date des informations, des sources disponibles et de l’enjeu de la décision.

Demander au modèle de ne rien inventer suffit-il ?

Cette consigne améliore parfois le comportement, notamment lorsqu’elle est associée à un contexte documentaire et à une règle d’abstention. Elle ne constitue pas une preuve. Le modèle peut mal déterminer si une information est connue, ou présenter une déduction comme un élément du document. Les affirmations importantes doivent donc être contrôlées.

Une réponse accompagnée de références est-elle forcément fiable ?

Non. Une référence peut être réelle mais ne pas soutenir l’affirmation, être ancienne, ou être citée hors contexte. Il faut retrouver le document, lire le passage pertinent et vérifier qu’il concerne bien le cas étudié.

La recherche sur Internet supprime-t-elle les hallucinations ?

Elle peut améliorer l’actualité des informations, mais elle ajoute d’autres risques : source peu fiable, résultat mal interprété, page inaccessible ou confusion entre plusieurs versions. La recherche doit être suivie d’un examen des sources et d’une comparaison avec les documents de référence.

Quand faut-il éviter d’utiliser une réponse générée sans validation experte ?

Une validation adaptée est nécessaire lorsque l’erreur peut causer un préjudice important, affecter la sécurité, engager des droits, exposer des données confidentielles ou modifier un système critique. Dans ces situations, l’IA peut contribuer à préparer une analyse, mais elle ne doit pas être l’unique fondement de la décision.