Quand l'IA invente plutôt que de demander : comment détecter l'incertitude et éviter les hallucinations en production

L'IA préfère halluciner plutôt qu'admettre qu'elle ne sait pas

Une étude récente publiée par The Decoder met en lumière un comportement problématique des modèles de langage multimodaux : face à une information visuelle manquante ou ambiguë, ils inventent une réponse plutôt que de demander de l'aide. Ce n'est pas une anecdote — c'est un biais systématique mesuré sur 22 modèles via le benchmark ProactiveBench.

ProactiveBench construit plus de 18 000 scénarios impossibles à résoudre sans input humain supplémentaire : objets occultés, angles de caméra non informatifs, images bruitées, croquis approximatifs. Résultat : quasiment aucun modèle ne demande spontanément des précisions. Ils hallucinent ou refusent de répondre.

Pour tout développeur qui intègre un LLM en production, ce constat doit déclencher une question concrète : comment anticiper et compenser ce comportement dans son architecture ?

Pourquoi c'est un problème réel en production

Dans un contexte applicatif, un modèle qui invente avec confiance est bien plus dangereux qu'un modèle qui dit "je ne sais pas". L'utilisateur final reçoit une réponse plausible mais fausse, sans signal d'alerte. Les conséquences varient selon le domaine :

• Support client : une mauvaise information transmise avec assurance crée de la frustration et de la défiance.
• Analyse documentaire : un champ mal interprété peut corrompre un pipeline de données entier.
• Assistance technique : une réponse inventée peut orienter un utilisateur vers une mauvaise solution.

Le vrai enjeu n'est pas d'éliminer l'incertitude — elle est inhérente à tout modèle probabiliste — mais de la rendre observable et actionnables.

Détecter l'incertitude : deux signaux exploitables

Avant d'insérer une logique de clarification, il faut un moyen de mesurer la confiance du modèle sur une réponse donnée. Deux approches complémentaires :

1. L'entropie sur les logits

Si votre modèle expose les probabilités token par token (via une API ou un déploiement local), l'entropie de Shannon sur la distribution de probabilité du token suivant donne un indicateur de dispersion :

H = -∑ p(x) * log2(p(x))

Une entropie élevée signale que le modèle hésite entre plusieurs tokens — signal d'incertitude. Une entropie basse indique une forte confiance (ce qui n'exclut pas une hallucination confiante, mais réduit le risque).

2. Le logit-gap

Plus simple à calculer : la différence de probabilité entre le token le plus probable et le second. Un faible écart signale une indécision du modèle.

logit_gap = probs[0] - probs[1]  # top-1 vs top-2
if logit_gap < THRESHOLD:
    trigger_clarification()

Ces métriques sont disponibles nativement avec des frameworks comme vLLM, llama.cpp ou via l'API OpenAI (logprobs=True). Avec les APIs fermées (Claude, Gemini), l'accès aux logits est limité ou inexistant — dans ce cas, on bascule sur une approche prompt-based.

Insérer une étape "clarify-first" dans votre pipeline

L'idée centrale est simple : avant de laisser le modèle générer une réponse finale, on lui demande d'abord d'évaluer si l'information disponible est suffisante. Si non, on génère une question de clarification ou on escalade vers un humain.

Architecture en deux temps

[Input utilisateur]
        |
        v
[Étape 1 : évaluation de complétude]
"Les informations fournies sont-elles suffisantes pour répondre avec fiabilité ?
 Réponds en JSON : {"sufficient": true|false, "missing": "...", "question": "..."}"
        |
   sufficient?
   /         \
 oui          non
  |            |
[Réponse]  [Clarification ou escalade humaine]

Exemple de prompt de clarification

SYSTEM: Tu es un assistant d'analyse documentaire. Avant de répondre, évalue si tu disposes
de suffisamment d'information. Si l'image ou le document est trop ambigu, génère une question
de clarification ciblée. Ne devine jamais.

Réponds en JSON strict :
{
  "can_answer": boolean,
  "confidence": "high" | "medium" | "low",
  "clarification_needed": string | null,
  "answer": string | null
}

Définir les seuils et le routage

Ces seuils sont à calibrer selon votre contexte métier — une application médicale n'a pas le même tolerance au risque qu'un chatbot de FAQ.

Mini-plan POC : réduire les hallucinations en 3 étapes

Voici une feuille de route minimale pour expérimenter cette approche sur un projet existant :

Étape 1 — Instrumenter (Semaine 1)

• Logger toutes les réponses du modèle avec un score de confiance (via logits si disponible, sinon auto-évaluation prompt-based).
• Identifier les catégories de requêtes à plus fort taux d'erreur.

Étape 2 — Insérer la logique clarify-first (Semaine 2)

• Ajouter l'étape d'évaluation de complétude avant la génération finale.
• Brancher la logique de routage (réponse / clarification / escalade).

Étape 3 — Mesurer (Semaine 3-4)

• Suivre trois métriques clés :
  • Taux d'hallucination : réponses incorrectes confirmées par feedback ou vérification.
  • Taux d'escalade : proportion de requêtes renvoyées à un humain.
  • Latence ajoutée : surcoût de l'étape intermédiaire en ms.
• Ajuster les seuils en fonction des résultats.

L'objectif n'est pas zéro escalade — c'est le bon niveau d'escalade. Un taux de 5-10 % d'escalades légitimes vaut largement mieux qu'un taux de 0 % avec des hallucinations non détectées.

Conclusion

Le benchmark ProactiveBench confirme ce que beaucoup d'équipes constatent empiriquement : les LLMs actuels ne savent pas dire "je ne sais pas" de façon proactive. Cette limitation n'est pas une fatalité — elle appelle une réponse architecturale.

Intégrer une étape de détection d'incertitude et un mécanisme de clarification-first, c'est traiter le modèle pour ce qu'il est : un outil probabiliste puissant, mais qui a besoin d'un garde-fou. En production, ce garde-fou, c'est vous qui le construisez.

Les approches par renforcement mentionnées dans l'étude originale (RL pour inciter les modèles à poser des questions) sont prometteuses, mais encore expérimentales. En attendant, les techniques prompt-engineering et logit-based décrites ici sont applicables dès aujourd'hui sur vos projets PHP/Symfony qui consomment des APIs LLM.