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

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

L'étude RAGGED l'a mis en évidence : LLaMA et Claude atteignent leur pic à seulement 5 chunks, puis la qualité chute rapidement. Claude a obtenu son meilleur résultat avec un seul fragment, le plus précis possible. Gonfler le contexte jusqu'à la limite est nuisible.

Six points de défaillance

1. Le chunking détruit le contexte : un découpage fixe en 512 tokens sépare l'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. D'après Anthropic, ils réduisent les erreurs de 35 %, de 49 % avec un BM25 contextuel, et de 67 % avec un reranking.

2. Écart sémantique : les embeddings ne saisissent pas l'intention. L'utilisateur demande « Comment résilier mon abonnement ? », alors que le document s'intitule « Account Termination Policy ». Solution : recherche hybride (embeddings + BM25 via Reciprocal Rank Fusion avec k=60), reformulation de la requête, HyDE (recherche à partir d'une réponse hypothétique).

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

4. Multi-hop : le RAG ne sait pas raisonner en chaîne. La question « Qui est le directeur général de l'entreprise qui a racheté le fournisseur du concurrent ? » exige quatre étapes de recherche. Solution : RAG itératif (agentique) ou mémoire sous forme de graphe (Neo4j, Cognee, Microsoft GraphRAG). Le prix à payer : latence et coût.

5. Aucune notion du temps : l'index ne sait pas qu'un document est périmé. Solution : filtrage par métadonnées, versionnage, réindexation automatique, suivi de la dérive de qualité.

6. Résolution d'entités : « Apple » (l'entreprise ou le fruit ?), « Иванов А.В. » et « А. Иванов » apparaissent comme des objets différents. Solution : extraire les entités à l'indexation, construire un index relié, effectuer la recherche via le graphe.

Quand le RAG n'est pas nécessaire

La requête « montre tous les clients dont le risque de départ 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 sur des nombres. Il faut du Text-to-SQL ou une couche sémantique au-dessus de l'entrepôt de données. Les détecteurs universels laissent passer 43 % des erreurs de calcul.

Diagnostic : trois métriques

La Context Relevance détecte les erreurs de chunking et de retrieval (les fragments renvoyés ne sont pas les bons). Le Context Recall détecte les omissions (le chunk contenant la réponse n'a pas été renvoyé). La Groundedness détecte les hallucinations malgré un contexte correct. La question clé : le problème vient-il du retrieval ou de la génération ? Ce sont deux problèmes d'ingénierie distincts, avec des solutions différentes.