De la gestion plutôt que de la magie

Introduction: le risque invisible

Les hallucinations, c’est-à-dire des affirmations générées par un LLM mais factuellement incorrectes, comptent parmi les risques les plus critiques dans l’utilisation de l’IA générative (pour le thème de la confiance, voir aussi mon autre article.)

Les systèmes RAG (Retrieval Augmented Generation), souvent présentés comme solution contre les hallucinations, introduisent en réalité de nouvelles sources d’erreurs. Ils promettent d’appuyer leurs réponses sur tes propres données fiables, mais peuvent malgré tout se tromper dangereusement.

La bonne nouvelle: les hallucinations ne sont pas une fatalité technologique. Elles sont avant tout un problème de qualité des données et d’architecture, donc un problème contrôlable

Que sont les hallucinations et pourquoi sont-elles dangereuses?

On parle d’hallucination quand un LLM génère des faits incorrects, mais les présente avec beaucoup de confiance et de conviction. Contrairement à une «simple» erreur, les hallucinations sont particulièrement problématiques, car elles:

• semblent plausibles: la réponse paraît parfaitement adaptée et sonne autoritaire.
• sont stylistiquement correctes: formulation, ton et structure paraissent professionnels.
• sont difficiles à repérer: même des expert·e·s peuvent les manquer en lisant rapidement
• abusent de la confiance: les utilisateur·rice·s supposent que le système se base sur des données vérifiées

Les exemples concrets ne manquent pas: sources inventées, articles de loi erronés ou étapes de processus entièrement imaginées.

Comment les hallucinations apparaissent-elles techniquement?

Un Large Language Model (LLM) fonctionne en prédisant le mot le plus probable à partir du contexte précédent. Son objectif est de fournir une réponse en évitant de dire «Je ne sais pas».

Cela crée un problème fondamental: Même lorsque les informations nécessaires sont incomplètes, voire inexistantes, le modèle va produire une réponse. C’est précisément là que naissent les hallucinations.

Pour contrer cela de manière systématique, deux stratégies de base existent:

1. Fournir du contexte:
   En fournissant le bon contexte pertinent (par ex. via RAG), on augmente la probabilité que le modèle s’appuie sur des informations correctes et génère une réponse correcte.

2. Reconnaître les cas out-of-distribution / «Je ne sais pas»:
   Quand une demande dépasse le domaine de connaissances, le système doit le reconnaître et ne pas répondre, plutôt que d’inventer quelque chose de faux ou incertain.

Systèmes RAG: promesses et réalité

Les systèmes RAG sont censés adresser exactement ce problème. Leur logique:

1. Au lieu de laisser le LLM répondre uniquement avec son «savoir appris du monde»,
2. le système cherche d’abord dans une base de connaissances (spécifique au·à la client·e) les informations pertinentes
3. et le LLM formule ensuite la réponse sur la base des documents trouvés et du prompt

Un RAG bien conçu peut réduire massivement les hallucinations.
Un RAG mal conçu ajoute de nouvelles sources d’erreurs et rend le débogage bien plus difficile.

Sources typiques d’erreurs dans les systèmes RAG

Problème 1: le retrieval échoue

Avant que le LLM ne réponde, il doit recevoir les documents pertinents. C’est là que beaucoup d’erreurs fondamentales se produisent:

Les informations pertinentes ne sont pas trouvées:

• Les algorithmes de recherche ne reconnaissent pas certains documents pourtant essentiels
• Du contenu important est caché dans des tableaux, des PDF ou des fichiers mal structurés et n’est pas ou mal capturé
• Le contexte du LLM est saturé d’informations inutiles, les informations vraiment pertinentes se perdent

Des documents obsolètes ou non pertinents sont utilisés:

• Le système récupère par exemple un communiqué de presse de 2019, totalement dépassé
• Des informations contradictoires provenant de sources différentes se retrouvent dans le même contexte

Les particularités du domaine ne sont pas représentées:

• Les embeddings ne capturent pas des distinctions essentielles du domaine
  Exemple: sur un site administratif, «s’annoncer» signifie presque toujours «annoncer son domicile à l’office des habitant·e·s», pas «s’inscrire à un cours de salsa».

Résultat: le LLM utilise un contexte faux ou incomplet – et hallucine en toute confiance.

Problème 2: l’étape de génération interprète mal

Même si le retrieval fonctionne correctement et fournit les bons documents, le LLM peut mal interpréter l’information:

Mauvaise interprétation:

• Le LLM ne saisit pas les nuances d’un texte juridique
• Des conditions («Si X, alors Y») deviennent des règles absolues
• Des exceptions sont ignorées ou trop généralisées

Combinaisons d’informations inadmissibles:

• Le LLM combine des informations provenant de différents documents de manière créative, mais incorrecte
• Il «déduit» B à partir de A alors que ce lien n’est pas valable
• Il tente de «mettre à jour» des informations obsolètes et se trompe

Compléments issus du savoir général:

• Le document trouvé ne répond qu’en partie à la question
• Le LLM complète les parties manquantes avec son savoir général
• Le résultat est un mélange de faits vérifiés et de contenu inventé

Nous avons très peu de contrôle direct sur cette étape de génération. Nous pouvons seulement choisir un modèle adapté et optimiser le prompt. Cela rend tout ce qui précède et suit encore plus important.

Trois stratégies essentielles pour réduire les risques

Si les hallucinations sont avant tout un problème d’architecture et de qualité des données, alors on peut aussi les combattre de manière systématique. Trois stratégies sont, selon notre expérience, essentielles:

1. La qualité des données comme fondation

Un système RAG est aussi bon que les données auxquelles il accède
L’ancien principe IT s’applique parfaitement: Garbage in, garbage out.

Principes clés:

• Alignement sur les besoins réels:
  Tout ce qui se trouve sur l’intranet n’aide pas à répondre aux questions des utilisateur·rice·s.
  La base de connaissances doit s’aligner sur les cas d’usage, pas sur la structure de dossiers de l’organisation.

• Enrichir les documents:
  Les documents doivent souvent être découpés pour entrer dans un LLM.
  Du contexte se perd facilement Il doit être ajouté explicitement (métadonnées, titres, champs de validité).

• Assurer l’actualité – Once Only:
  Les informations doivent être gérées une seule fois, de manière centralisée.
  Des copies multiples rendent la cohérence quasi impossible.
  Pour un système RAG, cela signifie: des «single sources of truth», pas cinq versions légèrement différentes du même processus.

2. Mécanismes de fallback et logique d’incertitude

Un bon système sait quand il ne sait pas et agit en conséquence.
Notre principe: mieux vaut un «Je ne peux pas t’aider» conservateur qu’une réponse inventée.

Concrètement:

• Définir des seuils d’incertitude:

  • Seuils sur différentes étapes du retrieval (distance vectorielle, score de pertinence)
  • En dessous: aucune réponse, mais un message transparent pour l’utilisateur·rice

• Routing pour les thèmes critiques:

  • Déterminer les thèmes «critiques» (impôts, santé, droit – dépend du·de la client·e).
  • Pour ces thèmes: fallbacks prédéfinis, par ex. «Je ne peux pas calculer ta charge fiscale. Merci d’utiliser le calculateur officiel.»

• Marquer clairement l’out-of-scope:

  • Quand un sujet dépasse la base de connaissances, le système doit le dire clairement – au lieu de répondre avec du demi-savoir.

3. Donner du pouvoir aux utilisateur·rice·s, ne pas les tromper

Même si on pouvait réduire techniquement les hallucinations, le langage reste ambigu.
Exemple: «Mon chien m’a apporté une balle. Je l’ai shootée.», quoi exactement a été shooté? Le langage n’est jamais 100 % clair.

Cela signifie: aucune question ne pourra jamais être répondue 100 % correctement. Donc:

a) Indiquer les sources pour chaque réponse

• Montrer les documents utilisés
• Lier précisément (tableau, section, paragraphe)
• Indiquer quand une réponse combine plusieurs sources

b) Rendre visibles les confidence scores

• Où possible, indiquer de manière simple le niveau de confiance du système.
• À long terme: mieux quantifier et visualiser ces scores.
  Entre-temps: mieux vaut un indicateur simple et honnête qu’une précision trompeuse.

c) Des disclaimers honnêtes, pas du marketing

La meilleure technologie ne sert à rien si les utilisateur·rice·s font confiance aveuglément.

• Écrire clairement dans l’interface: «Ce système peut se tromper.»
• Expliquer ce que le système peut faire et ce qu’il ne peut pas
• Éviter un discours marketing qui crée de fausses attentes
• Éviter aussi le jargon juridique que personne ne lit
  L’objectif: une communication honnête et compréhensible.

Une IA responsable, c’est possible

Pour moi, trois points sont essentiels:

1. Les hallucinations sont contrôlables:
   Elles ne sont pas un destin inévitable, mais le résultat de la qualité des données et de l’architecture. Les deux sont entre tes mains.

2. La transparence vaut mieux que la perfection:
   Tu ne pourras jamais éviter 100 % des hallucinations.
   Mais tu peux concevoir ton système pour que les utilisateur·rice·s puissent reconnaître, comprendre et gérer les erreurs.

3. C’est aussi un sujet de management, pas seulement d’ingénierie:
   Les décisions importantes (qualité des données, processus, responsabilités) doivent être prises au niveau managérial, pas uniquement par l’équipe IT.

L’utilisation de chatbots RAG comporte chances et risques.
Celles·ceux qui comprennent les risques et les adressent systématiquement peuvent saisir les opportunités – de manière responsable et sûre.