Recherche par agents et contexte suffisant : lorsque RAG ne dispose pas d’informations suffisantes

La recherche vectorielle n’est pas ce qui fait échouer la plupart des systèmes RAG. Le vrai problème en production est un modèle qui répond tout en manquant de preuves suffisantes. Il ne s’agit pas de ne rien trouver : le système propose généralement quelque chose, les extraits semblent pertinents, et la réponse est fluide et assurée. Pourtant, elle reste incomplète, car les faits nécessaires se trouvaient dans plusieurs documents, systèmes, tableaux, tickets, manuels, journaux ou relations graphiques.

Le schéma classique consiste en une seule passe :

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

Cela convient pour les questions simples, mais celles liées aux entreprises le sont rarement. Une politique est décrite dans un document et ses exceptions dans un autre. Un ticket décrit l’incident, une note de version explique un comportement modifié, une ligne de base de données contient l’état actuel, un arête de graphe révèle une dépendance, un tableau PDF présente les chiffres réels, et une conversation antérieure enregistre ce que l’utilisateur a déjà tenté. En ne récupérant que les premiers extraits similaires, le modèle répond trop tôt. Le RAG n’est pas mort ; il doit savoir quand il manque d’informations suffisantes.

Réponses prématurées

De nombreux systèmes RAG échouent en silence. Ils ne disent jamais qu’il n’y a pas assez de preuves. Ils fournissent une réponse fluide, structurée et en grande partie plausible, mais fausse.

Imaginez un agent de support interne à qui l’on demande pourquoi l’export d’Acme a échoué après une migration d’espace de travail. Un outil simpliste trouve une page de dépannage pour les exports et affirme que des permissions manquaient. Cela peut être en partie vrai. Une réponse complète prend en compte le registre de migration d’Acme, une note de version concernant les changements de permissions d’export, le ticket de la semaine dernière, le rapport d’incident interne, les indicateurs fonctionnels du compte ainsi que un graphe de dépendances indiquant le service d’export concerné. Un seul document ne pourrait jamais contenir tout cela, il faut donc que le système de recherche fonctionne davantage comme un agent.

Que signifie un contexte suffisant

Un contexte suffisant signifie que les éléments disponibles permettent de donner une réponse fiable. Des fragments peu liés entre eux, un score de similarité élevé ou cinq documents retournés ne comptent pas. Avant de générer une réponse, le système doit s’assurer de disposer de la politique applicable, des exceptions, de l’état actuel, du registre officiel, des liens entre les entités, d’informations suffisantes pour expliquer la cause et non seulement le symptôme, ainsi que d’une méthode pour citer la source. S’il manque quelque chose, il doit revenir en arrière et effectuer une nouvelle recherche. C’est là que se situe la différence entre le RAG classique et la récupération agente.

De top-k à la recherche d’éléments de preuve

Le RAG standard considère la récupération d’informations comme une étape unique : on récupère les données une fois puis on répond. La récupération agente, quant à elle, la traite comme un flux de travail :

Retrieve once → answer

Plan → retrieve → inspect → judge evidence → retrieve again → answer

Rien n’oblige le modèle à répondre en se basant sur la première information reçue. Il agit plutôt comme un analyste de recherche qui cherche, ouvre des documents, les compare, suit les relations entre eux, vérifie les informations et ne répond que lorsque le contexte est suffisant.

Pourquoi les agents augmentent le niveau de complexité

Un chatbot répond à une question. Un agent, quant à lui, prend des décisions : choisir des outils, appeler des API, mettre à jour des données, soumettre des demandes, recommander des actions, demander une approbation ou procéder à de nombreuses étapes. Un contexte incomplet se propage alors dans les étapes suivantes :

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

Un agent de production ne devrait pas se contenter de signaler un document similaire. Il devrait être en mesure d’indiquer où se trouvent la politique, l’exception, l’état du compte en ligne ainsi que l’incident associé, et affirmer que ces éléments résolvent la question. C’est une architecture différente.

La direction vers laquelle évolue la récupération par agents

Les recherches récentes sur RAG et les graphes de connaissances pointent vers une récupération contrôlée par des agents, consciente des graphes, évaluée en fonction des preuves et soutenue par une mémoire. Tous les systèmes n’ont pas besoin d’un graph de connaissances géant, mais la couche de récupération nécessite plus d’intelligence que simplement l’incorporation d’une requête et le retour des k résultats les plus pertinents. Plusieurs directions sont possibles.

Récupération inter-corpus

Les connaissances de l’entreprise ne se trouvent pas dans une seule base de données vectorielle bien organisée. Elles sont réparties sur Google Drive, Confluence, Notion, Slack, Jira, GitHub, des entrepôts, des tickets de support, des tableaux de bord, des API internes, des documents produits et des manuels PDF. Un bon système doit savoir où chercher en premier. Un planificateur de recherche peut classifier la question en fonction de critères tels que les politiques, le comportement du produit, des besoins spécifiques aux clients, des incidents, des métriques financières ou des dépendances techniques, et l’orienter en conséquence. Rechercher partout est coûteux, et chercher au mauvais endroit est encore pire.

La recherche en tant qu’outils

Un modèle utile présente la recherche comme un ensemble contrôlé d’outils plutôt que comme un résultat fixe :

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

Cela reflète l’enquête humaine : recherche, ouverture des résultats prometteurs, inspection des sections, affinage de la requête et comparaison des preuves. Le modèle de raisonnement guide le processus, mais uniquement au sein d’un ensemble d’outils limité, ce qui offre de la flexibilité sans accès illimité.

Parcours du graphe de connaissances

La recherche vectorielle permet de trouver du texte sémantiquement similaire, tandis que de nombreuses questions pratiques reposent sur des relations. Quels clients sont affectés par ce service ? Quels produits dépendent de cette API ? Quelle politique s’applique dans cette région ? Quelle déploiement a causé cet incident ? Il s’agit de questions liées au contexte, et non de questions de similarité. Un graphe peut relier directement les entités :

Customer → Workspace → Feature Flag → Service → Incident → Release Note

Un agent peut suivre ces liens au lieu d’espérer que le fragment approprié apparaisse parmi les premiers résultats. Cela constitue une preuve d’une navigation plus que d’une simple récupération d’informations. L’utilisez lorsque les relations entre les éléments sont importantes, et évitez-le lorsqu’il semble simplement sophistiqué.

Évaluation de la suffisance des preuves

Après la récupération, le système doit déterminer si les preuves sont suffisantes. Répondent-elles directement à la question ? Y a-t-il des entités, des dates ou des sources manquantes ? Les sources sont-elles contradictoires ? L’origine possède-t-elle une véritable autorité ? La réponse peut-elle être citée ? Lorsque les preuves sont faibles, le système continue de chercher :

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

La boucle empêche les réponses prématurées et facilite le débogage, car on peut voir pourquoi l’agent a cherché à nouveau.

Graphes de contexte et mémoire de l’agent

RAG traite généralement des connaissances externes, mais les agents ont également besoin de mémoire : ce que l’utilisateur a demandé précédemment, ce qui a été recherché, quelles preuves ont été acceptées, ce qui a été décidé et quels postulats restent en suspens. Un buffer de conversation simple ne suffit pas. Une conception plus efficace lie la mémoire aux entités et aux décisions, de sorte que la trace du raisonnement devient elle-même de la mémoire :

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

Lorsque le même problème se reproduit, l’agent n’a pas à repartir de zéro, ce qui est crucial pour les agents qui fonctionnent sur de longues périodes.

RAG multimodal et conscient des documents

Une grande partie des connaissances d’entreprise n’est pas sous forme de texte brut. Elles se trouvent dans des PDF, des tableaux, des captures d’écran, des diagrammes, des formules, des scans, des graphiques, des diapositives et des formulaires. Une segmentation ordinaire déforme la structure : les tableaux se transforment en textes confus, les formules perdent leur contexte, les diagrammes deviennent des estimations issues de l’OCR, et les sections sont séparées des légendes qui les expliquent. Un processus conscient des documents comprend le texte, les tableaux, les figures, la mise en page, la hiérarchie des titres, les légendes, les champs de formulaire ainsi que la relation entre les éléments visuels et le texte. Les domaines de la finance, de la santé, de la fabrication, du droit, de l’assurance et de la documentation technique en dépendent le plus.

Budgets de outils et de contexte

Les outils consomment également du contexte. En chargeant des dizaines d’outils de récupération, de graphes, de bases de données et de recherche, leurs schémas entrent en concurrence avec les éléments de preuve :

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

Le RAG agentiel nécessite donc un environnement de exécution conscient du budget, capable de décider quels outils afficher, combien de fragments inclure, s’il faut résumer les résultats des outils et, ce qui est crucial, quand s’arrêter. L’objectif est de récupérer suffisamment d’informations, sans continuer indéfiniment.

Une architecture de production

Ensemble, un système de récupération agentiel en environnement de production ressemble beaucoup plus à un plan de contrôle qu’à un pipeline :

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

Le message pratique est plus simple : ne laissez pas RAG répondre tant qu’il n’a pas suffisamment de preuves.

Le cas Acme, du début à la fin

Lorsqu’on demande pourquoi une exportation a échoué après la migration de l’espace de travail, le RAG standard récupère le guide de dépannage des exportations ainsi que les FAQ sur la migration, et répond que l’exportation a probablement échoué en raison d’un manque de permissions. Un système agent enquête :

1. Rechercher dans les documents de support les cas d’échec d’exportation.
2. Rechercher dans les notes de version les modifications liées à la migration de l’espace de travail.
3. Ouvrir la configuration du compte du client.
4. Vérifier l’état des flags fonctionnels.
5. Rechercher dans l’historique des incidents.
6. Suivre le graphe de dépendances depuis le service d’exportation jusqu’au service de permissions.
7. Décider si les preuves sont désormais suffisantes.
8. Rédiger la réponse en citant les sources.

La réponse est la suivante : Acme a été migré vers le nouveau modèle d’espace de travail, tandis que le service d’exportation continuait de vérifier le chemin des permissions obsolètes. Le paramètre de l’espace de travail est activé, mais la politique d’exportation n’a jamais été mise à jour ; par conséquent, la solution consiste à mettre à jour cette politique pour le modèle d’espace de travail. Ce n’est pas un modèle plus performant qui a changé le résultat, mais plutôt une meilleure collecte de preuves.

Quoi construire en premier

Avec un système RAG existant, ne réconstruisez pas tout. Suivez ces étapes dans l’ordre :

1. Ajoutez une vérification de suffisance. Avant de générer une réponse, demandez si les preuves obtenues sont suffisantes pour cette question précise ; si ce n’est pas le cas, effectuez une autre recherche ou posez une question de clarification à l’utilisateur.
2. Ajouter un routage des sources. Rechercher chaque source à chaque fois est une perte de temps. Classer d’abord la requête : les questions relatives aux politiques doivent être envoyées aux documents de politique, les problèmes des clients aux tickets accompagnés de l’état du compte, les pannes techniques aux documents, aux journaux et au graphe de services, et les questions sur les métriques à la couche sémantique.
3. Intégrer des outils de récupération tels que search, open, find, summarize, follow_entity_relation et query_structured_record, afin que la récupération devienne itérative.
4. Ajouter une exploration de graphe où les réponses dépendent de la propriété, des dépendances, de la filiation, de la causalité, de la hiérarchie, des liens à plusieurs étapes ou des exceptions de politique.
5. Préserver la structure du document. Pour les PDF, les rapports, les diapositives, les tableaux et les diagrammes, utiliser une analyse consciente du document et stocker sa structure plutôt que de simplement la diviser en fragments.
6. Conservez une trace des preuves qui enregistre les sources consultées, les documents ouverts, les faits retenus, les lacunes identifiées ainsi que la raison pour laquelle le système a décidé qu’il disposait de suffisamment d’informations. Cet enregistrement est ce qui assure la confiance dans les systèmes RAG agents.

À ne pas surdimensionner

Cela peut devenir trop complexe, et toutes les techniques ne conviennent pas à tous les cas d’usage. Une simple recherche de FAQ n’a probablement pas besoin d’un graphe de connaissances, les documents en texte brut n’ont pas besoin d’une analyse multimodale, les questions-réponses ponctuelles n’ont pas besoin d’une mémoire graphique à long terme, et un domaine entièrement interne n’a pas besoin de recherche externe. La question à se poser est de savoir quel type de preuves cette question nécessite. Pour un document simple, un RAG classique peut suffire. Lorsque la réponse nécessite des sources, des relations, de la mémoire et de l’état actuel, c’est alors que la récupération par agents justifie sa complexité.

Le changement

Le mouvement actuel dans le domaine du RAG ne vise pas à remplacer la recherche vectorielle. Il ajoute un contrôle sur le processus de récupération des informations. La recherche vectorielle reste importante, tout comme la recherche par mots-clés. Les graphes de connaissances sont utiles lorsque des relations existent, l’analyse de documents lorsque une structure est présente, et la mémoire lorsque un agent travaille sur le long terme. La tâche réelle consiste à combiner ces éléments. La prochaine génération ressemblera moins à ceci :

Vector DB → top-k chunks → LLM

et d'autres comme celui-ci :

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

RAG échoue non seulement lorsqu’il récupère des fragments de mauvaise qualité, mais aussi lorsqu’il obtient des fragments partiellement utiles et répond prématurément. Pour les questions simples, la méthode top-k peut encore fonctionner. Cependant, pour les applications d’entreprise, de recherche, de support, d’opérations ainsi que les agents traitant de nombreux documents, la récupération nécessite un mécanisme de boucle plus robuste :

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

C’est le passage du RAG standard à la récupération par agents. Ce n’est pas parce que le RAG est mort. Les agents en production doivent savoir quand ils ne disposent pas d’informations suffisantes.