Hallucination d'un LLM
Une hallucination est une réponse de LLM plausible mais fausse, non étayée ou inventée : une référence qui n'existe pas, un chiffre erroné, une fonctionnalité que l'entreprise n'a jamais livrée. Elle vient du fonctionnement même du modèle, qui produit une suite de texte probable et non un fait vérifié. Un ton fluide et assuré n'apporte aucune garantie d'exactitude.
Pourquoi c’est important pour un PM
Dans un produit, une hallucination est un défaut qui coûte : une politique de remboursement erronée donnée à un client, une clause imaginaire dans le résumé d'un contrat, un paramètre inventé dans du code généré. Le PM ne peut pas supprimer ce risque. Il décide où il est acceptable, comment il est détecté et ce que l'interface fait pour éviter qu'un utilisateur agisse sur une réponse non vérifiée.
Exemple
L'assistant d'une application de voyage affirme à un client que son billet est annulable sans frais, parce que des tarifs proches le sont souvent. Les conditions du billet disent l'inverse. La solution n'est pas un meilleur ton : l'assistant doit lire les vraies règles tarifaires via un outil et les citer, ou refuser de répondre.
Points clés
- Les hallucinations sont plus fréquentes sur les faits rares, les chiffres précis, l'actualité récente et les sujets peu présents dans les données d'entraînement.
- Fournir la source au modèle (RAG, document joint, résultat d'outil) les réduit sans les faire disparaître.
- Autoriser le modèle à répondre « je ne sais pas », ou à laisser un champ vide, est un choix de conception à spécifier et à tester.
- Un taux d'hallucination se mesure sur un jeu de cas, pas à l'impression : le même prompt peut avoir raison lundi et tort mardi.
- La complaisance, cette tendance du modèle à donner raison à son interlocuteur, est un défaut voisin qui rend les questions orientées risquées.
Erreurs fréquentes
- Croire qu'un modèle plus récent ou plus gros n'hallucine plus.
- Demander au modèle de vérifier sa propre réponse et prendre son verdict pour une preuve.
- Masquer les sources dans l'interface, ce qui prive l'utilisateur de tout moyen de contrôle.
- Prendre le niveau de confiance que le modèle s'attribue pour une probabilité calibrée.
Pour aller plus loin dans Module
Les formations et les leçons qui traitent cette notion :
- Comprendre ce que les LLM savent faire, et ce qu’ils ratent
- Prompter comme un PM : déléguer, décrire, vérifier
- Choisir et utiliser ses outils d'IA au quotidien
- Concevoir une architecture RAG adaptée à son produit
- Obtenir des sorties IA fiables et exploitables par le produit (JSON, schémas, appels de fonction)