Comment évaluer les hallucinations des LLM : checklist pratique

Le mot hallucination regroupe plusieurs défauts différents ; un unique hallucination rate ne constitue donc pas un contrat fiable. La closed-book factuality demande si une affirmation est correcte par rapport à un fait externe vérifié. Groundedness vérifie si la source fournie soutient l’affirmation. Instruction faithfulness détecte les écarts par rapport à l’input, tandis que self-consistency détecte les contradictions au sein d’une même réponse. Une réponse peut être grounded dans un document erroné ou factuellement correcte grâce à la mémoire du modèle alors que le contexte fourni ne la soutient pas.

Commencez par un decision contract : scénario, types de claims, sources autorisées, date de coupure des connaissances, coût de l’erreur, abstention correcte et action après un résultat incertain. NIST emploie le terme plus précis confabulation pour un contenu faux présenté avec assurance et souligne un risque particulièrement important dans les réponses longues et complexes par domaine. L’eval doit nommer le failure mode concret plutôt que d’attribuer une intention humaine au modèle.

• Factuality → le claim correspond à un fait externe faisant autorité à une date fixée.
• Groundedness → un evidence span précis soutient toute la portée du claim.
• Consistency → la réponse ne se contredit pas et ne contredit ni l’historique ni l’input structuré.
• Calibration → la confidence ou la décision de répondre correspond à la fréquence réelle des erreurs.

Pour les tâches fact-seeking courtes, utilisez des questions avec une réponse stable et non ambiguë ainsi qu’un evidence record contenant URL ou document ID, span exact, revision, verifiedAt et reviewer. SimpleQA illustre une conception étroite utile : réponse courte et verdicts séparés correct, incorrect et not attempted. Mais ce benchmark ne démontre ni la qualité long-form, ni RAG, ni votre domaine ; un jeu public reste une baseline, pas un certificat de release.

Ajoutez vos propres slices : fait connu, fait rare, question ambiguë, false premise, information après le cutoff, document obsolète, conflit de sources, no-answer et questions avec plusieurs formes valides. Pour un workflow grounded, incluez des contextes supportive, irrelevant, partially supportive et contradictory. Ne générez pas toutes les questions à partir des mêmes chunks sans revue : les jeux synthétiques reprennent souvent le vocabulaire des sources et rendent retrieval et grading artificiellement faciles.

Un seul verdict pour un paragraphe masque les réponses partiellement correctes. Le claim extractor doit isoler les affirmations vérifiables extérieurement, nombres, dates, entités, relations causales et attribution, tout en conservant scope et qualifiers. Pour chaque claim, le grader renvoie supported, contradicted, unverifiable ou not-in-context avec les evidence IDs. La simple présence d’une citation n’est pas une preuve : le span doit réellement impliquer le claim et pas seulement être proche thématiquement.

Mesurez séparément claim coverage, factual precision, unsupported critical claims et contradiction rate. Le completeness extractor doit également être calibré : s’il omet une date inventée, le downstream score sera artificiellement élevé. Annotez manuellement un slice représentatif, mesurez l’agreement entre reviewers et analysez la disagreement taxonomy. Un model grader est utile à l’échelle, mais son prompt, sa version, l’ordre des preuves et sa retry policy font partie de l’eval versionné.

L’eval doit offrir au modèle une sortie sûre : poser une question de clarification, indiquer que les preuves sont insuffisantes ou escalader vers un humain. Comptez correct, incorrect et abstained comme outcomes distincts, puis construisez une courbe risk-coverage montrant comment l’erreur évolue lorsque le système traite une part croissante des requêtes. Une accuracy élevée après refus de presque tout n’est pas utile sans coverage ; un answer rate élevé peut masquer des suppositions dangereuses.

Ne vous fiez pas uniquement à la confidence déclarée par le modèle. Calibrez-la sur des held-out cases avec reliability bins ou Brier score et comparez-la à des signaux simples : suffisance des evidence, disagreement entre plusieurs samples et verifier verdict. Semantic entropy étudie la variation au niveau du sens et peut détecter des confabulations, mais ses auteurs les distinguent des erreurs systématiques et cohérentes. Un uncertainty detector complète donc la vérification factuelle sans la remplacer.

Comparez candidate et baseline sur les mêmes frozen cases, séparément par langue, domaine, longueur, freshness, source, disponibilité de retrieval et gravité de l’erreur. Le score agrégé peut progresser grâce à des trivia faciles pendant que des dates financières ou des qualifiers médicaux régressent. Pour les slices high-risk, définissez des critical invariants : aucune entité, aucun nombre ni aucune citation inventés ne doivent atteindre le résultat final sans vérification ou human review.

Ne testez pas seulement le modèle. Fixez les versions du corpus, retriever, search API, prompt, citation resolver, claim extractor, verifier et renderer. Injectez empty retrieval, stale cache, broken source, partial document, revisions contradictoires et verifier timeout. Si les evidence sont indisponibles, l’UI ne doit pas transformer un claim unverifiable en réponse assurée. Conservez un redacted trace de l’input au rendu afin de distinguer retrieval miss, generation defect, grader error et presentation bug.

• Dataset health → label agreement, source freshness, leakage et slice coverage.
• Answer quality → correct, incorrect, abstained et critical failures pondérés par le risque.
• Evidence quality → claim coverage, citation entailment et unsupported-claim rate.
• Operations → latence, grader disagreement et coût par réponse vérifiée.

Le decision record fixe dataset revision, sources, modèle, prompt, versions du pipeline, primary metric, segment thresholds, critical failures, owner et known-good rollback bundle. La promotion exige une paired non-regression significative en pratique, la réussite des critical slices et un coût acceptable par réponse vérifiée. N’annoncez ni threshold universellement sûr ni victoire d’un modèle sur la seule base d’un vendor benchmark : vos sources, langues, traffic mix et conséquences d’erreur diffèrent.

Le rollout commence par offline replay, passe à shadow evaluation, à un petit canary puis à une production limitée par le risque. Une user correction confirmée peut devenir regression fixture après privacy review ; un clic implicite ou l’absence de plainte ne prouvent pas la factuality. Si un critical unsupported claim atteint un utilisateur, réduisez la coverage, désactivez le modèle ou la retrieval revision concernés, restaurez le known-good bundle et examinez les réponses déjà émises si le domaine l’exige. Production monitoring doit employer la même taxonomy que l’eval offline.