Où les pipelines RAG agissent de manière aveugle : cartographie des échecs liés aux modèles d’agentivité

La méthode standard de génération améliorée par la récupération d’informations suit une logique simple : récupérer, générer, répondre. Elle convient pour une démonstration, mais les questions réelles en environnement de production révèlent rapidement ses limites. Le système de récupération fournit des extraits irrelevants, l’utilisateur formule sa question en termes que vos documents n’ont jamais utilisés, la réponse n’est pas du tout présente dans l’index, ou le modèle écrit quelque chose que le texte récupéré ne prend pas en compte. Ajouter plus de documents dans la requête ne résout aucun de ces problèmes, car le problème n’est pas la quantité de contexte, mais plutôt l’absence de décision quant à la prochaine étape à suivre.

C’est cette couche de prise de décision que l’on entend par RAG agent. Ce guide la considère comme un ensemble de réponses ciblées aux différents modes d’échec, plutôt que comme une architecture unique, afin que vous puissiez examiner votre propre pipeline, identifier l’étape où il agit actuellement de manière aveugle, et choisir le modèle le plus adapté pour y remédier.

Pourquoi le pipeline à une seule étape échoue

Lorsque cette hypothèse échoue, rien dans le pipeline ne s’en aperçoit :

• Des documents de mauvaise qualité sont tout de même transmis au modèle, qui tente de répondre à partir d’eux.
• Une requête dont le vocabulaire ne correspond pas aux documents ne fournit que peu d’informations utiles.
• Si la base de connaissances ne contient tout simplement pas la réponse, le système n’a aucune autre solution.

Un changement de perspective utile consiste à cesser de se demander uniquement comment améliorer la récupération des informations et à commencer par se demander ce que le système doit faire lorsque cette récupération n’est pas suffisante. Chacun des modèles présentés ci-dessous constitue une réponse à une version de cette deuxième question. Si vous souhaitez une comparaison plus large des architectures de récupération avant d’examiner les modèles individuels, consultez RAG vs agentic RAG vs graph RAG.

Évaluation de la récupération et réécriture de la requête

Prenons par exemple la question : « Comment LangGraph gère-t-il la persistance ? » Supposons que le système de récupération renvoie cinq extraits, dont un seul est pertinent. Un pipeline linéaire envoie les cinq extraits au modèle pour qu’il les trie, ce qui affaiblit la pertinence des informations utiles et favorise la confusion.

• Récupérer les documents
• Évaluer les résultats
• Réécrire la requête si elle est insuffisante
• Récupérer à nouveau

Recours en cas d’absence de réponse dans l’index

La réécriture ne sert à rien si les informations existent quelque part dans votre corpus. Souvent, ce n’est pas le cas. Imaginez un assistant basé sur une documentation collectée il y a un mois, et qu’un utilisateur demande des informations concernant une fonctionnalité annoncée hier. Aucune reformulation ne permettra de retrouver un document qui n’a jamais été indexé.

RAG corrective résout ce problème. Après avoir évalué les documents récupérés, le flux de travail considère un résultat insuffisant comme un signal à modifier la stratégie, par exemple en interrogeant une autre source telle que une recherche sur le web. Le flux linéaire « récupérer, puis générer » devient alors :

• récupérer
• évaluer les documents
• corriger, si l’évaluation est mauvaise
• générer

Le terme « correct » est délibérément large. Selon l’application, cela peut signifier réécrire la requête, consulter une autre source ou entreprendre une autre action. La caractéristique déterminante est que l’échec de la récupération déclenche une autre procédure plutôt qu’une réponse insuffisante. Gardez à l’esprit que l’ajout d’un mécanisme de secours en ligne modifie votre modèle de confiance : le contenu web public est moins soigneusement sélectionné que votre propre documentation, il peut donc être utile de marquer ou de filtrer les réponses qui s’y appuient.

Routage de chaque question vers la bonne source

Une autre hypothèse implicite dans les systèmes RAG de base est que chaque question doit être traitée par le même outil de récupération. De nombreux systèmes réels disposent en même temps de plusieurs sources de connaissances : la documentation interne de l’entreprise, les documents publics du produit, un ou plusieurs stockages vectoriels et une recherche web en temps réel.

Ces sources ne sont pas interchangeables. Une question concernant une politique interne des ressources humaines ne doit pas être répondue à partir du web ouvert. Une question portant sur une version de bibliothèque publiée la semaine dernière ne doit pas dépendre uniquement d’un stockage vectoriel créé avant cette publication.

RAG adaptatif ajoute une décision de routage au début du processus. Avant de récupérer quoi que ce soit, le système classe la question et détermine quelle source est la plus appropriée pour y répondre, puis évalue le contexte fourni par cette source. Le chemin de récupération est choisi pour chaque question plutôt que d’être fixe pour toutes. Un routeur peut être aussi simple qu’une instruction de classification ou un ensemble de règles ; il n’a pas besoin d’être sophistiqué pour éliminer toute une catégorie de réponses provenant de sources inadaptées.

Vérifier la réponse, pas seulement les documents

Une défaillance plus subtile est facile à manquer : une récupération excellente ne garantit pas forcément une bonne réponse. Le modèle peut recevoir les passages exactement appropriés et produire néanmoins une réponse qui dépasse leur portée ou s’éloigne de la question posée.

La solution consiste à évaluer également le résultat généré. Après la génération, un flux de travail agent peut poser les questions suivantes :

• Toute affirmation contenue dans la réponse est-elle fondée sur le contexte récupéré ?
• La réponse aborde-t-elle bien ce que l’utilisateur a réellement demandé ?
• Le modèle a-t-il ajouté des informations que le contexte ne prend pas en compte ?

Si la réponse échoue, le flux de travail peut la réviser ou la régénérer. Cela vous offre deux vérifications distinctes qu’il est utile de maintenir séparées : savoir si les bonnes informations ont été récupérées, et si ces informations ont été utilisées correctement. Les séparer facilite également beaucoup le débogage, car une erreur peut être attribuée à l’étape de récupération ou à l’étape de génération, plutôt que simplement au fait « que le bot a eu tort ». L’article sur l’évaluation de RAG selon l’étape d’échec développe cette idée.

Pause pour une décision humaine

Certains résultats ne devraient pas être décidés automatiquement. Les motifs typiques justifiant un examen par un humain incluent :

• des preuves ambiguës ou contradictoires
• des réponses qui nécessitent une approbation formelle avant d’être utilisées
• un faible niveau de confiance de la part des évaluateurs du système lui-même

un projet de réponse qui nécessite clairement des modifications

Le système RAG avec intervention humaine installe un point de contrôle dans le flux de travail où quelqu’un peut valider le résultat, le rejeter ou le modifier avant que l’exécution ne se poursuive. Il ne s’agit pas d’un recul par rapport à l’automatisation : le système gère toujours seul les cas courants et n’envoie en haut de la pile que ceux qui nécessitent réellement un jugement, ce qui représente généralement une utilisation bien meilleure du temps des évaluateurs que de vérifier tout ou rien. Les frameworks d’orchestration basés sur des graphes tels que LangGraph conviennent parfaitement à cela, car ils peuvent conserver l’état du flux de travail au point de contrôle et le reprendre une fois que la personne a répondu.

Distribution du travail entre des agents spécialisés

Au fur et à mesure que les flux de travail s’agrandissent, il devient difficile de gérer un seul agent chargé de toutes les responsabilités et de lui donner des instructions efficaces. Certains problèmes se décomposent naturellement en rôles distincts : récupération, recherche, évaluation, etc.

Une configuration avec plusieurs agents superviseurs confie à l’un d’eux la tâche de coordination. Le superviseur décide quel spécialiste doit passer à l’étape suivante, tandis que chaque spécialiste s’occupe d’une tâche précise. Il ne s’agit pas d’ajouter des agents pour leur propre compte ; chaque agent supplémentaire entraîne un retard, des coûts plus élevés et nécessite de nouvelles instructions à gérer. Cela en vaut la peine lorsque le problème implique réellement plusieurs étapes ou spécialités et que les instructions destinées à un seul agent forment une liste ingérable de cas particuliers.

Mettre en œuvre des recherches indépendantes en parallèle

Chaque étape n’a pas besoin d’attendre la précédente. Si une réponse nécessite des informations provenant de plusieurs sources indépendantes, les interroger l’une après l’autre — source A, puis B, puis C — avant de donner une réponse est une perte de temps.

Le modèle de diffusion parallèle effectue ces recherches en même temps : la question est envoyée simultanément à A, B et C, et leurs résultats sont fusionnés avant que la réponse ne soit générée. Les tâches de récupération ou de traitement indépendantes s’exécutent en parallèle et sont combinées à la fin. Cela peut rendre les workflows complexes plus rapides et plus faciles à structurer, car chaque branche est autonome. L’inconvénient est que l’étape de fusion doit gérer des résultats qui se chevauchent ou sont contradictoires, et elle doit décider quoi faire si l’une des branches échoue ou atteint son délai limite.

Planification avant exécution

Certaines questions ne peuvent absolument pas être répondues par une seule recherche. Elles nécessitent plusieurs recherches, des transformations intermédiaires ou des étapes de raisonnement dont l’ordre est important.

Le principe de planification et d’exécution du RAG permet de gérer cela en séparant la réflexion sur les tâches à effectuer de leur exécution proprement dite. Le flux devient alors le suivant :

• recevoir la question
• élaborer un plan
• exécuter les étapes prévues
• évaluer les résultats
• donner une réponse

Le planificateur détermine ce qui doit être fait ; l’exécution s’occupe des étapes individuelles. Cela est particulièrement utile pour les questions composées, comme les comparaisons entre plusieurs documents, où une utilisation directe des outils conduit souvent à des réponses superficielles ou incomplètes. Un plan permet également de vérifier ce qui s’est passé en cas d’erreur, ce qui est plus difficile avec un agent qui improvise à chaque étape.

Qu’est-ce qui fait réellement d’un système RAG un agent ?

Appeler un LLM ou qualifier quelque chose d’agent ne fait pas automatiquement d’un système un agent. La propriété distinctive est que le système peut évaluer sa situation et choisir sa prochaine action. Un flux de travail fixe suppose une recherche suivie d’une réponse. Un système agent peut se poser une série de questions :

• La recherche est-elle vraiment nécessaire pour cette question ?
• Ce qui a été obtenu est-il réellement utile ?
• Faut-il rechercher à nouveau avec une requête différente ?
• Une autre source serait-elle plus adaptée ?
• La réponse est-elle étayée par des preuves ?
• Un être humain doit-il intervenir ?
• Faut-il laisser prendre le relais un autre agent spécialisé ?
• Planifier d’abord le travail donnerait-il de meilleurs résultats ?

Chaque question correspond à l’un des schémas mentionnés ci-dessus, c’est pourquoi il est utile de considérer l’agentic RAG comme un ensemble d’outils de prise de décision plutôt que comme une conception monolithique. Ces schémas s’adaptent naturellement à l’orchestration de graphes : le classement et le routage deviennent des arêtes conditionnelles, les boucles deviennent des cycles avec un compteur dans l’état, la révision par un humain devient une interruption, et la diffusion devient des branches parallèles qui se rejoignent.

Associez le schéma à l’échec

Aucune application n’a besoin de tous ces schémas, et chacun d’eux ajoute du retard, des coûts et des éléments mobiles. Choisissez en fonction de l’échec que vous observez réellement :

• Si la qualité de la récupération est le principal problème, une réécriture de la requête avec un outil d’évaluation de pertinence peut suffire.
• Si la base de connaissances présente des lacunes, ajoutez une source de secours.
• Si vous utilisez plusieurs sources de connaissances, ajoutez un mécanisme de routage.
• Si certaines décisions nécessitent un contrôle, ajoutez un point de vérification humain.

Si le flux de travail implique des tâches spécialisées distinctes ou des recherches indépendantes, envisagez l’ajout d’un superviseur ou une structure de traitement parallèle.

Si les questions nécessitent plusieurs étapes dépendantes, intégrez une phase de planification.

Conclusion

La question qui mène à des améliorations utiles n’est pas de savoir comment rendre un système RAG plus autonome. Elle concerne plutôt les domaines où le système agit actuellement de manière aveugle : il envoie des documents qui n’ont pas été vérifiés, cherche dans les sources inappropriées, fait confiance à des réponses sans fondement ou prend des décisions qui devraient être prises par un humain. Instrumentez le processus afin de déterminer quels sont ces échecs les plus fréquents, ajoutez le point de décision le plus simple capable de gérer celui qui se produit le plus souvent, puis mesurez à nouveau avant d’ajouter un nouvel élément.