Modes de défaillance agentiques du RAG : récupération, tempêtes d’outils et ballonnement du contexte (et comment les repérer tôt)

échoue de manière prévisible. La récupération renvoie des morceaux défectueux ; le modèle hallucine. Vous corrigez votre découpage et passez à autre chose. La surface de débogage est petite car l’architecture est simple : récupérer une fois, générer une fois, c’est fait.

Agentic RAG échoue différemment car la forme du système est différente. Ce n’est pas un pipeline. C’est un boucle de contrôle: planifier → récupérer → évaluer → décider → récupérer à nouveau. Cette boucle est ce qui le rend puissant pour les requêtes complexes, et c’est exactement ce qui le rend dangereux en production. Chaque itération est une nouvelle opportunité pour l’agent de prendre une mauvaise décision, et les mauvaises décisions s’aggravent.

Trois modes de défaillance apparaissent à plusieurs reprises une fois que les équipes font passer le RAG agentique au-delà du prototypage :

1. Thrash de récupération : L’agent continue de chercher sans converger vers une réponse
2. Tempêtes d’outils : appels d’outils excessifs qui se succèdent et réessayent jusqu’à ce que les budgets soient épuisés
3. Gonflement du contexte: la fenêtre contextuelle se remplit de contenu à faible signal jusqu’à ce que le modèle cesse de suivre ses propres instructions

Ces échecs se présentent presque toujours lorsque « le modèle s’est dégradé, mais la cause profonde n’est pas le modèle de base ». Il manque de budgets, de règles d’arrêt faibles et d’observabilité nulle de la boucle de décision de l’agent.

Cet article détaille chaque mode de défaillance, pourquoi il se produit, comment le détecter rapidement avec des signaux spécifiques et quand ignorer complètement le RAG agentique.

Qu’est-ce que Agentic RAG (et qu’est-ce qui le rend fragile)

Classic RAG récupère une fois et répond. Si la récupération échoue, le modèle ne dispose d’aucun mécanisme de récupération. Il génère le meilleur résultat possible à partir de tout ce qui revient. Agentic RAG ajoute une couche de contrôle par-dessus. Le système peut évaluer ses propres preuves, identifier les lacunes et réessayer.

La boucle de l’agent fonctionne à peu près comme ceci : analyser la question de l’utilisateur, construire un plan de récupération, exécuter des appels de récupération ou d’outil, synthétiser les résultats, vérifier s’ils répondent à la question, puis s’arrêter et répondre ou revenir en arrière pour une autre passe. Il s’agit du même modèle de récupération → raison → décision décrit dans Architectures de style ReActet cela fonctionne bien lorsque les requêtes nécessitent un raisonnement à plusieurs sauts ou des preuves dispersées entre les sources.

Mais cette boucle introduit une fragilité fondamentale. L’agent optimise localement. À chaque étape, il demande : « Est-ce que j’en ai assez ? et lorsque la réponse est incertaine, la valeur par défaut est « obtenir plus ». Sans règles d’arrêt strictes, les spirales par défaut. L’agent récupère, plus, escalade, récupère à nouveau, à chaque passage brûlant des jetons sans garantir la progression. LangGraph’s propre tutoriel officiel de RAG agent avait exactement ce bug : une boucle de récupération infinie qui nécessitait un réécriture_count bouchon à fixer. Si l’implémentation de référence peut boucler indéfiniment, les systèmes de production le feront certainement.

Le correctif n’est pas une meilleure invite. Il s’agit de budgétisation, de contrôle et de meilleurs signaux.

Taxonomie des modes de défaillance : qu’est-ce qui casse et pourquoi

Retrieval Thrash : la boucle qui ne converge jamais

Le thrash de récupération est l’agent qui récupère à plusieurs reprises sans se décider sur une réponse. Dans les traces, vous le voyez clairement : des requêtes quasi-dupliquées, des termes de recherche oscillants (élargissement, puis rétrécissement, puis élargissement à nouveau) et une qualité de réponse qui reste stable au fil des itérations.

Un scénario concret. Un utilisateur demande : « Quelle est notre politique de remboursement pour les employés distants en Californie ? » L’agent récupère la politique générale de remboursement. Son vérificateur signale la réponse comme incomplète car elle ne mentionne pas les règles spécifiques à la Californie. L’agent reformule : «Remboursement du travail à distance en Californie.» Il récupère un document RH tangentiellement lié. Toujours pas confiant. Il reformule encore : « Remboursement des dépenses du code du travail de Californie. » Trois autres itérations plus tard, il a épuisé son budget de récupération, et la réponse est à peine meilleure qu’après le premier tour.

Les causes profondes sont cohérentes : des critères d’arrêt faibles (le vérificateur rejette sans dire ce qui manque spécifiquement), une mauvaise reformulation des requêtes (reformulation plutôt que ciblage d’une lacune), des résultats de récupération de signal faibles (le corpus ne contient véritablement pas la réponse, mais l’agent ne peut pas la reconnaître), ou une boucle de rétroaction dans laquelle le vérificateur et le récupérateur oscillent sans converger. Conseils de production de plusieurs équipes converge vers le même nombre : trois cycles de récupération de cap. Après trois tentatives ratées, renvoyez une réponse au mieux avec un avertissement de confiance.

Tempêtes d’outils et ballonnement du contexte : lorsque l’agent s’inonde lui-même

Les tempêtes d’outils et la surcharge du contexte ont tendance à se produire ensemble, et chacune aggrave l’autre.

Une tempête d’outils se produit lorsque l’agent déclenche des appels d’outils excessifs : tentatives en cascade après des délais d’attente, appels parallèles renvoyant des données redondantes ou stratégie « tout appeler pour être sûr » lorsque l’agent est incertain. Une startup documentée des agents effectuant 200 appels LLM en 10 minutes, brûlant entre 50 et 200 dollars avant que quiconque ne s’en aperçoive. Une autre scie les coûts grimpent de 1 700 % lors d’une panne de fournisseur alors que la logique de nouvelle tentative devenait incontrôlable.

Le gonflement du contexte est le résultat en aval. Des résultats massifs de l’outil sont collés directement dans la fenêtre contextuelle : JSON brut, résumés intermédiaires répétés, mémoire croissante jusqu’à ce que l’attention du modèle soit trop dispersée pour suivre les instructions. Les recherches montrent systématiquement que les modèles accordent moins d’attention aux informations enfouies au milieu de contextes longs. Stanford et Meta « Perdu au milieu » L’étude a révélé des baisses de performances de plus de 20 points de pourcentage lorsque les informations critiques se trouvent au milieu du contexte. Lors d’un test, la précision du contrôle qualité multi-documents a en fait chuté performance inférieure à livre fermé avec 20 documents inclus, ce qui signifie que l’ajout du contexte récupéré a activement aggravé la réponse.

Les causes profondes : pas de budgets ou de limites de débit par outil, pas de stratégie de compression pour les sorties des outils et des configurations de récupération « tout remplir » qui traitent le top 20 comme une valeur par défaut raisonnable.

Comment détecter ces échecs tôt

Vous pouvez détecter les trois modes de défaillance avec un petit ensemble de signaux. L’objectif est de rendre visibles les pannes silencieuses avant qu’elles n’apparaissent sur votre facture.

Signaux quantitatifs à suivre dès le premier jour :

• Appels d’outils par tâche (moyenne et p95) : les pointes indiquent des tempêtes d’outils. Enquêter sur plus de 10 appels ; dur-kill au-dessus de 30.
• Itérations de récupération par requête: si la médiane est de 1 à 2 mais que p95 est de 6+, vous avez un problème de thrash sur les requêtes difficiles.
• Taux de croissance de la longueur du contexte: combien de jetons sont ajoutés par itération ? Si le contexte évolue plus vite que les preuves utiles, vous êtes en proie à une surcharge.
• latence p95: la latence de queue est l’endroit où se cachent les échecs agents, car la plupart des requêtes se terminent rapidement tandis que quelques-unes tournent en spirale.
• Coût par tâche réussie: la métrique la plus honnête. Cela pénalise les tentatives inutiles, et pas seulement le coût moyen par exécution.

Traces qualitatives : forcer l’agent à justifier chaque boucle. À chaque itération, enregistrez deux choses : « Quelles nouvelles preuves ont été obtenues ? » et « Pourquoi cela ne suffit-il pas pour répondre ? » Si les justifications sont vagues ou répétitives, la boucle bat son plein.

Comment chaque échec correspond aux pics de signal : le thrash de récupération apparaît alors que les itérations augmentent tandis que la qualité des réponses reste plate. Les tempêtes d’outils se traduisent par une augmentation du nombre d’appels, des délais d’attente et des augmentations de coûts. Le gonflement du contexte apparaît sous la forme d’une augmentation des jetons de contexte tandis que le suivi des instructions se dégrade.

Règles Tripwire (définies comme des plafonds stricts) : maximum 3 itérations de récupération ; maximum 10 à 15 appels d’outils par tâche ; un plafond de jetons de contexte par rapport à celui de votre modèle efficace fenêtre (pas son maximum revendiqué) ; et une minuterie murale à chaque course. Lorsqu’un fil-piège se déclenche, l’agent s’arrête proprement et renvoie sa meilleure réponse avec une incertitude explicite, sans aucune nouvelle tentative.

Atténuations et cadre décisionnel

Chaque mode de défaillance correspond à des atténuations spécifiques.

Pour le thrash de récupération : limiter les itérations à trois. Ajoutez un « nouveau seuil de preuve » : si la dernière récupération ne fait pas apparaître un contenu significativement différent (mesuré par la similarité avec les résultats précédents), arrêtez-vous et répondez. Contraindre la reformulation afin que l’agent doit cibler une lacune spécifique identifiée plutôt que de simplement reformuler.

Pour les tempêtes d’outils : définir des budgets et des limites de taux par outil. Dédupliquez les résultats entre les appels d’outils. Ajoutez des solutions de secours : si un outil expire deux fois, utilisez un résultat mis en cache ou ignorez-le. Les équipes de production utilisant des méthodes basées sur l’intention le routage (classification de la complexité des requêtes avant de choisir le chemin de récupération) rapporte une réduction des coûts de 40 % et une amélioration de la latence de 35 %.

Pour le gonflement du contexte : résumer les résultats de l’outil avant de les injecter dans leur contexte. Une réponse API de 5 000 jetons peut être compressée jusqu’à 200 jetons de résumé structuré sans perte de signal. Limitez le top-k à 5 à 10 résultats. Dédupliquez les fragments de manière agressive : si deux fragments partagent plus de 80 % de chevauchement sémantique, conservez-en un. LLMLingua de Microsoft atteint une compression rapide jusqu’à 20 fois avec une perte de raisonnement minimale, ce qui corrige directement le gonflement des pipelines agents.

Des politiques de contrôle applicables partout : timebox à chaque course. Ajoutez un mode « réponse finale requise » qui s’active lorsqu’un budget est atteint, obligeant l’agent à répondre avec toutes les preuves dont il dispose, ainsi que des marqueurs d’incertitude explicites et des suggestions d’étapes suivantes.

La règle de décision est simple : utilisez le RAG agentique uniquement lorsque la complexité des requêtes est élevée. et se tromper coûte cher. Pour les FAQ, les recherches de documents et les extractions simples, le RAG classique est plus rapide, moins cher et beaucoup plus facile à déboguer. Si la récupération en un seul passage échoue régulièrement pour vos requêtes les plus difficiles, ajoutez un deuxième passage contrôlé avant de passer à l’agent complet.

Agentic RAG n’est pas un meilleur RAG. C’est RAG plus une boucle de contrôle. Et les boucles de contrôle exigent des budgets, des règles d’arrêt et des traces. Sans eux, vous expédiez un flux de travail distribué sans télémétrie, et le premier signe d’échec sera votre facture cloud.