Une hallucination de l'IA est un résultat qu'un système d'IA présente comme plausible ou factuel mais qui est faux, non fondé ou incohérent avec son matériel source. Dans les modèles de langage génératif, une formulation fluide peut donner l'air d'un détail inventé fiable même lorsque le modèle n'a aucune base fiable pour cela.

Les modèles de langage génèrent du texte en estimant les suites probables à partir des motifs de leur entraînement et de leur contexte. Ils ne vérifient pas automatiquement chaque affirmation par rapport à une source vérifiée. Une demande de citation précise, un fait manquant dans l'invite ou une question inhabituelle peuvent donc produire un contenu sûr de lui mais incorrect. Les outils de recherche, l'ancrage et la validation peuvent réduire certaines erreurs, mais chacun a des limites et peut échouer à sa manière.

Architecture et gouvernance

L'hallucination est une propriété de l'architecture, et non une défaillance de celle-ci. Cela ne signifie pas que chaque sortie inexacte est inoffensive ou que les organisations doivent l'accepter sans contrôles. Cela signifie que la gouvernance doit prévoir les erreurs plausibles comme un comportement attendu du système, plutôt que de traiter un modèle comme une base de données qui ne nécessite qu'une correction occasionnelle.

Le niveau de vérification doit correspondre aux conséquences de l'utilisation. Un assistant de brainstorming peut avoir besoin d'un rappel clair indiquant que les suggestions nécessitent une révision. Un système utilisé pour des décisions médicales, juridiques, financières ou liées à l'emploi nécessite une validation plus forte, des sources faisant autorité, une révision documentée et une limite claire de ce qu'il peut décider. Un examinateur humain doit disposer des informations et du temps nécessaires pour vérifier la réponse, plutôt que de simplement approuver un écran rempli de texte fluide.

Réduire l'exposition et rendre les erreurs visibles

Les organisations peuvent tester les modes de défaillance probables avant le déploiement, y compris les informations manquantes, les invites ambigües et les entrées contradictoires. Elles doivent mesurer l'exactitude factuelle sur des tâches représentatives, inspecter les citations et les liens sources, et tester si le système signale l'incertitude de manière appropriée. L'évaluation doit se poursuivre après la sortie, car les modifications apportées aux invites, aux modèles, aux sources de récupération et au comportement des utilisateurs peuvent altérer les résultats.

La conception peut faciliter la vérification : afficher le matériel source, distinguer les faits récupérés du texte généré et donner aux utilisateurs un moyen simple de signaler les erreurs. Les politiques doivent identifier les résultats qui nécessitent une confirmation indépendante et interdire que des réponses non étayées soient utilisées comme unique base pour des décisions à fort impact. Le signalement d'incidents peut révéler des schémas récurrents et guider les mises à jour de la formation, des invites, des contrôles ou de l'utilisation prévue.

Les utilisateurs ont également besoin de conseils indiquant que la fluidité n'est pas une preuve. Si un résultat affecte une autre personne, l'argent, la sécurité ou un dossier officiel, la responsabilité incombe aux personnes et à l'organisation qui utilisent le système. La question pertinente n'est pas de savoir si un modèle peut parfois se tromper, mais si le système est conçu de telle sorte que les erreurs puissent être trouvées, contenues et corrigées avant qu'elles ne causent des dommages évitables.