RAG enterprise : comment éviter les hallucinations sur les données d'entreprise

Le problème que personne ne veut admettre

Une entreprise du secteur des assurances a déployé un chatbot interne basé sur GPT-4 pour répondre aux questions sur les contrats. Trois semaines plus tard, un opérateur a constaté que le système citait des clauses inexistantes avec une totale assurance. Les dégâts en termes de crédibilité interne ont été significatifs. Le coût du rollback a dépassé celui du déploiement initial.

Ce n'est pas un cas isolé. Selon des données agrégées de Gartner et des enquêtes internes menées par des cabinets de conseil, 67 % des projets RAG enterprise échouent ou sont réduits en périmètre dans les six mois suivant le go-live. La cause n'est presque jamais le modèle : c'est l'architecture de retrieval.

---

La vraie nature du problème d'hallucination en RAG

Dans un système RAG enterprise, les hallucinations ont une cause précise : le modèle reçoit un contexte insuffisant, ambigu ou erroné, et comble les lacunes avec des inférences non ancrées dans les données réelles.

Les trois patterns les plus fréquents :

1. Retrieval de chunks incorrect Les documents sont découpés en chunks de taille fixe (ex. 512 tokens) sans respecter la structure sémantique. Un paragraphe sur les pénalités contractuelles se retrouve séparé de l'en-tête du contrat. Le retriever récupère le chunk sur les pénalités, mais le modèle ne sait pas à quel contrat il se rapporte.

2. Seuils de similarité trop permissifs Le retriever renvoie des documents avec une cosine similarity de 0,62, alors que le seuil minimal acceptable pour des textes juridiques ou réglementaires devrait être ≥ 0,80. Le modèle travaille avec un contexte non pertinent et compense en inventant.

3. Absence de vérification du grounding Aucun composant ne vérifie que les affirmations du modèle sont traçables aux chunks récupérés. Le modèle peut citer des données absentes du contexte sans qu'aucun mécanisme ne l'intercepte.

---

L'architecture correcte pour le RAG enterprise

Chunking sémantique, pas de taille fixe

Abandonner le chunking à taille fixe. Utiliser un découpage respectant la structure du document :

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=150,
    separators=["\n\n", "\n", ". ", " "],
    length_function=len
)

Pour les documents structurés (contrats, manuels techniques, réglementations), implémenter un parser hiérarchique qui préserve le fil contextuel : chaque chunk transporte des métadonnées sur le document parent, la section et le numéro d'article.

chunk_metadata = {
    "source": "contrat_fourniture_2024_v3.pdf",
    "section": "Article 7 - Pénalités",
    "page": 12,
    "doc_type": "legal",
    "last_updated": "2024-03-15"
}

Ce métadonnée est récupéré avec le chunk et inclus dans le prompt. Le modèle sait toujours d'où vient l'information.

Retrieval en deux étapes avec re-ranking

Un seul retriever vectoriel ne suffit pas pour des datasets enterprise complexes. L'approche correcte :

Étape 1 — Retrieval de candidats : récupération large avec vector search (top-k = 20, seuil bas)
Étape 2 — Re-ranking : un cross-encoder (ex. cross-encoder/ms-marco-MiniLM-L-6-v2) réévalue la pertinence des 20 candidats et sélectionne les 5 vraiment pertinents pour la requête

from sentence_transformers import CrossEncoder

re_ranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
scores = re_ranker.predict([(query, chunk) for chunk in candidate_chunks])
top_chunks = [candidate_chunks[i] for i in sorted(range(len(scores)), key=lambda x: scores[x], reverse=True)[:5]]

Le re-ranker réduit drastiquement le bruit dans le contexte transmis au modèle.

Seuils de confiance explicites

Définir des seuils minimaux par type de document :

| Type de document | Seuil cosine similarity minimal | |---|---| | Réglementation / compliance | 0,82 | | Contrats | 0,80 | | Base de connaissance technique | 0,75 | | FAQ internes | 0,70 |

Si aucun chunk ne dépasse le seuil, le système doit répondre avec un fallback explicite : « Je n'ai pas trouvé d'informations suffisamment pertinentes dans le dataset d'entreprise pour répondre à cette question. » — jamais une invention.

Couche de vérification du grounding

Le dernier niveau de défense : un composant qui vérifie, après génération, que chaque affirmation factuelle de la réponse est traçable aux chunks de contexte fournis.

Approches praticables :

NLI-based : utiliser un modèle d'inférence en langage naturel (ex. facebook/bart-large-mnli) pour vérifier que la réponse est entailed par le contexte
Citation forcing : forcer le modèle à citer le chunk source pour chaque affirmation via un prompt structuré
Confidence scoring : demander au modèle d'auto-évaluer sa certitude sur une échelle 1-5 avant de retourner la réponse

System prompt (extrait) :
« Pour chaque affirmation factuelle dans ta réponse, indique entre crochets le numéro du chunk source [chunk_N]. Si tu ne trouves pas de support dans les chunks fournis, écris explicitement : INFORMATION NON DISPONIBLE DANS LE DATASET. »

---

Monitoring en production

Un système RAG sans monitoring est aveugle. Métriques minimales à suivre :

Retrieval recall@5 : combien de réponses pertinentes se trouvent dans les top-5 chunks récupérés
Answer faithfulness : rapport entre les affirmations ancrées dans le contexte et le total des affirmations (outil : RAGAS)
Fallback rate : pourcentage de requêtes ne dépassant pas le seuil de confiance — une valeur >15 % signale des problèmes de couverture du dataset
Latence par étape : séparer la latence de retrieval de celle de génération pour identifier les goulots d'étranglement

# Exemple d'évaluation avec RAGAS
ragas evaluate \
  --dataset ./eval_dataset.json \
  --metrics faithfulness,answer_relevancy,context_recall

---

Take-away opérationnel

Le chunking de taille fixe est la première cause d'hallucinations dans les RAG d'entreprise. Le remplacer par un chunking sémantique hiérarchique avec métadonnées contextuelles.
Implémenter un retrieval en deux étapes. Un seul vector store d'embeddings ne suffit pas pour les datasets enterprise.
Définir des seuils de confiance par type de document. Un fallback explicite vaut toujours mieux qu'une réponse inventée.
Ajouter une couche de vérification du grounding avant de retourner la réponse à l'utilisateur.
Mesurer la faithfulness avec RAGAS ou des outils équivalents. Sans métriques, la qualité reste une approximation.

Un système RAG bien conçu n'élimine pas tout risque d'erreur, mais rend chaque erreur traçable et corrigeable. C'est la différence entre un prototype et un système enterprise.

---

Evviva Group accompagne les partenaires IT dans la conception et le déploiement d'architectures RAG à usage enterprise. Si vous évaluez un projet similaire, nous sommes disponibles pour une discussion technique.