Un modèle peut produire une réponse grammaticalement parfaite et factuellement fausse. On parle souvent d'hallucination, mais ce mot ne décrit pas un accident isolé. Le système continue simplement à générer la suite la plus plausible, même quand il manque une preuve.

Pourquoi le modèle invente

Le modèle n'interroge pas automatiquement une base de vérité. Ses poids contiennent des régularités apprises, pas un registre garanti de faits. Une question ambiguë, trop récente, très spécialisée ou fondée sur une prémisse fausse augmente le risque.

Trois situations se ressemblent mais demandent des réponses différentes :

  • Le modèle ne possède probablement pas l'information.
  • L'information est dans le contexte, mais le modèle la retrouve mal.
  • Le modèle possède des indices contradictoires et choisit une suite plausible.

Évaluer une tâche réelle

Un benchmark public donne un repère, mais il ne remplace pas vos cas d'usage. Construisez un petit jeu d'évaluation avec des questions représentatives, des réponses attendues et une règle de notation claire.

Cas de test→Réponses→Critères→Erreurs classées→Correction du système

Une bonne évaluation sépare plusieurs critères : exactitude, complétude, respect du format, présence de sources, sécurité et temps de réponse. Une seule note globale masque les compromis.

Des critères observables

Pour une réponse documentaire, vous pouvez vérifier :

  1. Chaque affirmation importante est-elle soutenue par un passage fourni ?
  2. La citation pointe-t-elle vers la bonne source ?
  3. Le modèle signale-t-il quand les documents ne suffisent pas ?
  4. La réponse distingue-t-elle fait, hypothèse et recommandation ?

Pour du code, exécutez les tests. Pour un calcul, refaites l'opération avec un outil déterministe. Pour une procédure dangereuse, ajoutez une validation humaine.

RAG, outils et limites

Un système RAG récupère des passages avant la génération. Il peut améliorer la factualité, mais il ajoute de nouveaux points de panne : mauvais découpage, recherche imprécise, document obsolète ou citation mal reliée.

Un outil externe, comme une calculatrice ou une API, déplace une partie du travail vers un système déterministe. Il faut encore vérifier que le modèle appelle le bon outil avec les bons paramètres et interprète correctement son résultat.

Comparer deux modèles

Utilisez les mêmes demandes, les mêmes paramètres de génération et le même matériel. Mélanger modèle, température, contexte et runtime empêche de savoir ce qui explique le résultat.

Notez aussi la latence et la mémoire. Un modèle légèrement meilleur mais quatre fois plus lent peut être moins utile dans une interface interactive. Inversement, un modèle rapide qui invente des références critiques n'est pas acceptable.

Installer une boucle de progrès

Conservez les erreurs représentatives, classez leur cause et rejouez les tests après chaque changement. Votre jeu d'évaluation devient un contrat de comportement. Il protège contre les régressions quand vous changez de modèle, de prompt, de quantization ou de moteur de recherche.

L’essentiel

  • Une hallucination est une suite plausible produite sans preuve suffisante, pas un accident rare.
  • L'objectif est de rendre l'erreur détectable, mesurable et moins coûteuse.
  • Un petit jeu d'évaluation sur vos propres cas vaut mieux qu'un score de benchmark général.
  • Séparez les critères : exactitude, complétude, format, sources, sécurité et latence.
  • Le RAG et les outils réduisent certains risques mais ajoutent leurs propres points de panne.

Testez-vous

Répondez de tête ou par écrit, puis vérifiez. Se tester juste après la lecture aide à retenir.

  1. Pourquoi un modèle invente-t-il une référence avec assurance ?

    Voir la réponse

    Il ne consulte pas automatiquement une base de vérité. Il génère la suite la plus plausible, même quand l'information lui manque.

  2. Que doit contenir un bon jeu d'évaluation pour un assistant documentaire ?

    Voir la réponse

    Des questions présentes dans les documents, des questions ambiguës et des questions absentes. On vérifie les bonnes réponses, les demandes de précision et le refus d'inventer.

  3. Pour comparer deux modèles, que faut-il garder identique ?

    Voir la réponse

    Les demandes, les paramètres de génération, le contexte, le runtime et le matériel. Sinon, impossible de savoir ce qui explique la différence.

Sources et pour aller plus loin