L'hallucination n'est pas un bogue qui sera corrigé dans la prochaine version — c'est une conséquence structurelle du fonctionnement des modèles de langage. Un modèle génère du texte en prédisant le prochain token le plus probable étant donné tout ce qui a précédé. Il n'a pas de base de données de faits interne, aucun moyen de vérifier des affirmations par rapport à la réalité, et aucun concept de vrai contre faux. Quand il produit une affirmation qui semble plausible mais est fausse, il fait exactement ce pour quoi il a été entraîné : générer du texte fluide et contextuellement approprié. Le problème est que « contextuellement approprié » et « factuellement correct » ne sont pas la même chose, et le modèle n'a aucun mécanisme pour les distinguer.
Les hallucinations les plus dangereuses sont les subtiles. Un modèle qui invente une personne complètement fictive est facile à repérer. Un modèle qui attribue une vraie citation à la mauvaise personne, cite un vrai article avec la mauvaise année, ou génère un endpoint d'API plausible qui n'existe pas — ceux-là sont plus difficiles. Les développeurs l'ont appris à leurs dépens. Il y a des cas bien connus d'avocats soumettant des mémoires juridiques générés par IA avec des citations de jurisprudence fabriquées qui étaient parfaitement formatées mais référençaient des affaires qui n'ont jamais existé. Les hallucinations de code sont tout aussi courantes : un modèle pourrait suggérer d'importer une fonction de bibliothèque qui a été renommée il y a trois versions, ou référencer une signature de méthode qui correspond presque mais pas tout à fait à la vraie.
Plusieurs facteurs rendent l'hallucination plus ou moins probable. Des paramètres de température plus élevés augmentent l'aléatoire, ce qui peut augmenter les taux d'hallucination sur les questions factuelles. Poser des questions sur des sujets obscurs qui apparaissent rarement dans les données d'entraînement produit plus d'hallucinations que poser des questions sur des sujets bien couverts. Les sorties plus longues et plus complexes offrent plus d'occasions pour que les choses tournent mal. Et les modèles sont particulièrement enclins à halluciner quand ils sont sous pression pour produire une réponse — si vous posez une question et que le modèle ne sait pas, son entraînement le pousse à générer une réponse qui semble confiante plutôt que de dire « je ne suis pas sûr ». C'est pourquoi donner explicitement à un modèle la permission de dire « je ne sais pas » réduit mesurablementles taux d'hallucination.
L'industrie a développé une stratégie de défense en couches. L'ancrage et le RAG fournissent des sources externes que le modèle peut référencer plutôt que de se fier à la mémoire paramétrique. Des paramètres de température plus bas réduisent l'aléatoire pour les tâches factuelles. Les prompts système peuvent instruire le modèle de citer ses sources et signaler l'incertitude. Les vérifications post-génération — passer la sortie dans un second modèle ou un pipeline de vérification des faits — attrapent certaines erreurs avant qu'elles n'atteignent les utilisateurs. Anthropic, OpenAI et Google ont tous investi massivement dans l'entraînement de modèles mieux calibrés quant à leur propre incertitude, de sorte qu'ils sont plus susceptibles de nuancer ou de décliner plutôt que de confabuler. Mais aucune de ces défenses n'est parfaite, et traiter toute sortie d'IA comme parole d'évangile sans vérification reste risqué pour tout ce qui a des conséquences.
Une idée reçue mérite d'être abordée : les taux d'hallucination se sont considérablement améliorés entre les générations de modèles, et certains extrapolent pour conclure que le problème sera « résolu » bientôt. Ce ne sera probablement pas le cas, du moins pas complètement, parce que l'architecture elle-même ne dispose pas d'un mécanisme de vérification de la vérité. Ce qui s'améliore, c'est la calibration — les modèles modernes hallucinent moins souvent et expriment mieux l'incertitude. Mais « moins souvent » n'est pas « jamais », et dans les domaines à enjeux élevés comme la médecine, le droit ou la finance, même un taux d'hallucination de 1 % sur les affirmations factuelles est inacceptable sans vérification humaine. La conclusion pratique est de concevoir vos systèmes en supposant que le modèle se trompera occasionnellement, et d'intégrer la vérification dans votre processus plutôt que d'espérer que la prochaine mise à jour du modèle la rendra inutile.