Erreurs RAG : 6 raisons pour lesquelles la mémoire d'un agent IA déraille, et comment diagnostiquer le retrieval

Le RAG (Retrieval-Augmented Generation) connecte une base de connaissances externe aux réponses des LLM, avec la promesse de débarrasser le modèle des hallucinations. En pratique, 73 % des pannes des systèmes RAG proviennent d'une mauvaise recherche, et 40 % des pipelines ne parviennent pas du tout à extraire les données nécessaires. Les ingénieurs tentent souvent de traiter les symptômes — changer de modèle d'embedding, augmenter le top-k, mettre à jour le LLM. Mais si le prompt a reçu dès le départ un contexte inadapté, c'est la couche de retrieval qui est cassée, et l'hallucination n'est que la conséquence de cette erreur.

L'étude RAGGED a révélé un pic de performance pour LLaMA et Claude à seulement 5 chunks, au-delà duquel la qualité chute rapidement. Claude a obtenu son meilleur résultat avec un seul fragment, mais extrêmement précis. Gonfler le contexte au maximum est contre-productif.

Les six points de défaillance

1. Le chunking détruit le contexte — un découpage fixe de 512 tokens sépare une entité de la phrase qui la qualifie, un chunk sans titre perd son sens, un tableau de 200 lignes se transforme en bruit. Solution : découper selon la structure du document, reporter les titres dans chaque chunk, utiliser des embeddings contextuels. Selon Anthropic, ces derniers réduisent les erreurs de 35 %, de 49 % avec un BM25 contextuel, et de 67 % avec un reranking.

2. Rupture sémantique — les embeddings ne captent pas l'intention. L'utilisateur demande « Comment annuler mon abonnement ? », le document s'appelle « Account Termination Policy ». Solution : recherche hybride (embeddings + BM25 via Reciprocal Rank Fusion avec k=60), reformulation de la requête, HyDE (recherche basée sur une réponse hypothétique).

3. Désalignement entre retrieval et génération — augmenter le top-k améliore le Hit@k, mais la qualité de la réponse finit par chuter. L'étude de Liu et al., « Lost in the Middle », a montré que le modèle exploite mieux l'information placée au début et à la fin du contexte. La valeur optimale de top-k se détermine expérimentalement ; RAGGED a montré un optimum allant de k ≤ 1 à k ≥ 10. Le seuil de recall de 85 % sert de repère — en dessous, il faut réparer le retrieval.

4. Multi-hop — le RAG ne sait pas raisonner en chaîne. Une question comme « Qui est le PDG de l'entreprise rachetée par le fournisseur d'un concurrent ? » exige quatre étapes de recherche successives. Solution : RAG itératif (agentique) ou mémoire sous forme de graphe (Neo4j, Cognee, Microsoft GraphRAG). Le prix à payer : latence et coût accrus.

5. Absence de notion temporelle — l'index ne sait pas qu'un document est devenu obsolète. Solution : filtrage par métadonnées, versionnement, réindexation automatique, surveillance de la dérive de qualité.

6. Résolution d'entités — « Apple » (l'entreprise ou le fruit ?), « Dupont J. » et « J. Dupont » apparaissent comme des objets distincts. Solution : extraire les entités dès l'indexation, construire un index relié, effectuer la recherche via un graphe.

Quand le RAG n'est pas la solution

Une requête comme « affiche tous les clients dont le risque de churn dépasse 0,7 » relève du SQL, pas de la recherche. Le RAG ne sait pas faire d'agrégations, de tris, ni de filtrages numériques. Il faut recourir au Text-to-SQL ou à une couche sémantique au-dessus du stockage. Les détecteurs génériques laissent passer 43 % des erreurs de calcul.

Diagnostic : trois métriques

Le Context Relevance détecte les erreurs de chunking et de retrieval (les mauvais fragments ont été renvoyés). Le Context Recall détecte les omissions (le chunk contenant la réponse n'a pas été renvoyé). Le Groundedness détecte les hallucinations malgré un contexte correct. La question clé : est-ce le retrieval ou la génération qui est cassé ? Ce sont deux problèmes d'ingénierie distincts, aux solutions différentes.