Mon RAG hallucine et il a des fuites, que faire ?

L’incident récent du chatbot “AskOurProduct”, qui a révélé des détails sur des fonctionnalités non annoncées tout en en inventant d’autres, est un cas d’école. Le système, basé sur une architecture RAG (Retrieval-Augmented Generation), a été alimenté avec l’ensemble de la documentation interne, y compris des brouillons. Le résultat : des fuites d’information confidentielle et des hallucinations qui ont dégradé la confiance des utilisateurs. Cet échec n’est pas celui d’un LLM, mais celui d’une conception de RAG laxiste. Un RAG de production n’est pas un simple “chat-with-your-docs”. C’est un système qui exige des contrôles stricts sur ses sources, ses citations et sa capacité à dire “je ne sais pas”.

anatomie d’une fuite par RAG

L’incident est le résultat d’une chaîne de failles de conception, pas d’une attaque complexe.

la défense en 3 actes

Pour construire un RAG fiable, trois garde-fous sont non-négociables.

1. la liste blanche de sources

N’indexez jamais “toutes” vos données. Le principe doit être l’inverse : n’indexer que ce qui a été explicitement approuvé pour une consultation externe.

Action: Maintenez une liste blanche (allowlist) des sources autorisées (ex: pages d’un wiki avec le tag “publié”, documents dans un dossier “validé”). Tout le reste est ignoré.
Processus: Chaque nouvelle source doit passer par un processus de validation simple avant d’être ajoutée à la liste.

# Exemple de configuration d'un pipeline d'indexation
rag_pipeline_config:
  source_type: "confluence"
  allowlist:
    - space: "PUBLIC_KB"
      label: "faq-produit"
    - space: "DOCS"
      label: "guide-utilisateur"
  # Le reste est ignoré par défaut

2. la citation obligatoire

Ne faites pas confiance au LLM pour décider de citer ses sources. Forcez-le à le faire via une instruction claire dans le prompt et une vérification en sortie.

Action: Modifiez votre prompt pour inclure une contrainte forte : “Tu dois citer tes sources pour chaque affirmation en utilisant l’ID du document. Si tu ne peux pas sourcer une information, ne l’inclus pas.”
Processus: Après la génération, un script simple doit vérifier que la réponse contient bien des identifiants de source qui étaient présents dans le contexte. Si ce n’est pas le cas, la réponse est rejetée.

# Vérification post-génération
def is_response_valid(response, context_ids):
    cited_ids = set(re.findall(r'\[doc-(\w+)\]', response))
    if not cited_ids:
        # Rejeter si aucune source n'est citée
        return False
    # Rejeter si des sources non fournies sont citées
    return cited_ids.issubset(context_ids)

3. le refus est une fonctionnalité

Un système fiable sait quand il ne sait pas. La capacité à refuser de répondre à une question hors-périmètre est une fonctionnalité, pas un bug.

Action: Incluez dans votre prompt une instruction de “fallback” : “Si les documents fournis ne te permettent pas de répondre à la question, réponds exactement : ‘Je ne suis pas en mesure de répondre à cette question avec les informations dont je dispose.’”
Processus: En sortie, si vous détectez cette phrase exacte, vous pouvez afficher un message d’aide plus élaboré à l’utilisateur, au lieu d’une réponse vide ou hallucinée.

erreurs à ne pas reproduire

L’index fourre-tout: L’erreur la plus commune est de brancher le RAG sur un répertoire ou une base de connaissances entière sans filtrer. La gouvernance des sources est la première ligne de défense.
Faire confiance au prompt seul: Penser qu’une instruction comme “sois factuel” suffit est une illusion. La vérification des citations en sortie est une assurance nécessaire.
Ne pas tracer les échecs: Chaque fois que le système refuse de répondre ou qu’une citation est invalide, cela doit être loggué. C’est une mine d’or pour comprendre les limites de votre base de connaissances.

faq

Comment gérer les mises à jour de documents ? Votre pipeline d’indexation doit être incrémental. Il doit détecter les documents modifiés ou supprimés pour mettre à jour l’index vectoriel, afin d’éviter que le RAG ne cite des sources obsolètes.
Le RAG peut-il quand même halluciner ? Oui, mais le risque est fortement réduit. Il peut encore mal interpréter un document ou faire une synthèse incorrecte. C’est pourquoi la citation des sources est cruciale : elle permet à l’utilisateur de vérifier par lui-même.
Est-ce que ces contrôles ralentissent beaucoup la réponse ? L’impact est négligeable. La vérification des citations ou la détection d’une phrase de refus sont des opérations très rapides qui ajoutent au plus quelques millisecondes à la latence totale.

Menu