Habr : 6 raisons pour lesquelles la mémoire d'un agent RAG déraille, et comment vérifier le retrieval

Quand un agent RAG répond à côté, le soupçon se porte d'abord sur le modèle de langage. La pratique pointe plus souvent la recherche : si le fragment utile n'a pas atteint le contexte, même un LLM performant inventera une réponse ou annoncera qu'il n'a pas les données. L'analyse publiée sur Habr porte sur six causes de ces défaillances et sur une méthode de diagnostic du retrieval. L'annonce de la publication ne donne que la définition de la technologie ; la liste des causes elle-même est repliée sous le cut. Voici donc la carte des défaillances typiques, que les ingénieurs vérifient généralement dans cet ordre.

Le RAG (Retrieval-Augmented Generation) relie le modèle à une base de connaissances externe. L'agent ne s'appuie pas uniquement sur ce qu'il a appris à l'entraînement : il cherche d'abord des informations dans des documents d'entreprise, des référentiels ou sur internet, puis rédige sa réponse à partir de ces sources. Le pipeline compte au moins cinq étapes : découpage des documents, vectorisation, indexation, recherche et assemblage du contexte. Une erreur à n'importe laquelle d'entre elles produit le même symptôme : l'agent « a oublié ».

Où la recherche casse le plus souvent

Première zone de risque : le découpage en chunks. Des morceaux trop petits perdent leur contexte, des morceaux trop grands diluent le sens du vecteur. Un tableau coupé en deux ou une définition séparée de son terme ne seront retrouvés par aucune requête.

Deuxième zone : le modèle d'embeddings. S'il gère mal le russe, une terminologie pointue ou le code, des textes sémantiquement proches se retrouvent éloignés dans l'espace vectoriel.

Troisième zone : la fraîcheur de l'index. Le document a été mis à jour, mais la réindexation n'a pas été lancée, et l'agent cite avec aplomb la version du règlement de l'an dernier. Pour la mémoire de l'agent, c'est la source la plus fréquente de réponses « périmées ».

Quatrième zone : la formulation de la requête. L'utilisateur écrit « comment poser un congé ? », alors que le document de la base s'intitule « Procédure d'octroi du congé annuel payé ». La réécriture de la requête et la décomposition d'une question complexe en sous-requêtes aident à y remédier.

Cinquième zone : le classement. La recherche vectorielle pure retrouve mal les références produits, les noms et les abréviations. Un schéma hybride avec BM25, associé à un reranker appliqué aux meilleurs candidats, apporte généralement un gain de précision notable.

Sixième zone : l'assemblage du contexte. Les modèles exploitent moins bien les faits situés au milieu d'un long prompt. Les doublons, les fragments superflus et un mauvais ordre dégradent la qualité, même quand la recherche a fonctionné correctement.

Comment diagnostiquer le retrieval

Le principe central : évaluer la recherche séparément de la génération. Pour cela, on constitue un jeu de questions de référence, chacune étant associée à l'avance à un fragment source. Quelques dizaines ou deux cents exemples suffisent, mais ils doivent refléter de vraies requêtes d'utilisateurs, et non des questions inventées par les développeurs.

On calcule ensuite les métriques :

• recall@k : part des questions pour lesquelles le fragment utile figure dans les k premiers résultats. Si cette métrique s'effondre, inutile d'aller plus loin ;
• precision@k : proportion de résultats réellement utiles parmi ceux retrouvés, autrement dit la quantité de bruit qui part dans le prompt ;
• MRR : rang moyen du premier résultat correct ;
• nDCG : qualité de l'ordre des résultats lorsque plusieurs fragments sont pertinents ;
• latence de la recherche et du reranking, car une précision payée en secondes d'attente est souvent inacceptable pour un agent.

Si le recall est élevé mais que les réponses restent mauvaises, le problème se situe plus loin dans le pipeline : dans l'assemblage du contexte ou dans le modèle lui-même. Si le recall est faible, on commence par les chunks et les embeddings.

Marche à suivre

Constituez d'abord le jeu de référence et relevez les chiffres de départ. Modifiez ensuite un seul paramètre à la fois : taille des chunks, modèle d'embeddings, ajout de BM25, reranker, nombre de fragments transmis. Comparez chaque changement aux métriques, et non à l'impression laissée par quelques dialogues réussis.

Mettez aussi en place un suivi dédié : journalisez la requête, les fragments retrouvés et leurs scores. Quand un utilisateur se plaint d'une mauvaise réponse, regardez en premier lieu si le document utile figurait dans les résultats. Planifiez une réindexation régulière et vérifiez que les documents mis à jour ont bien atteint l'index. Et ne corrigez pas le retrieval avec le prompt : demander « réponds plus précisément » ne ramènera pas un fait absent du contexte.