RAG agentique vs RAG classique : quand l'agent n'ajoute que de la latence

La promesse du RAG agentique est séduisante : au lieu d'un pipeline fixe (retrieve → generate), l'agent décide lui-même quand chercher, quoi chercher, s'il faut reformuler, itérer, ou combiner plusieurs sources. Plus de souplesse, meilleure qualité.

La réalité sur nos projets est plus nuancée. L'architecture agentique a amélioré significativement les résultats sur certains cas. Sur d'autres, elle a introduit 3 à 8 secondes de latence supplémentaire pour un gain de qualité imperceptible.

Voici notre grille d'arbitrage.

Ce qu'on appelle RAG agentique

Le terme recouvre plusieurs choses distinctes. Pour être précis, on distingue :

Self-querying : l'agent génère plusieurs reformulations de la requête initiale et lance plusieurs recherches en parallèle avant de synthétiser. Utile quand la question est ambiguë ou sous-spécifiée.

Iterative retrieval (ReAct) : l'agent alterne "penser → chercher → penser → chercher" en boucle jusqu'à avoir suffisamment d'information. Inspiré du pattern ReAct (Yao et al., 2022).

Multi-step reasoning : l'agent décompose une question complexe en sous-questions, résout chacune, puis synthétise les réponses partielles.

Tool-augmented RAG : l'agent peut appeler d'autres outils en plus du retrieval (calculateur, API externe, base de données structurée).

Ces quatre variantes ont des profils de coût et d'utilité très différents.

Le RAG classique : ce qu'il résout bien

Un RAG pipeline fixe (retrieve top-k → rerank → generate) couvre 80 % des cas d'usage documentaires courants :

• Question factuelle sur un corpus stable ("quel est le délai de rétractation")
• Résumé d'un document ou d'un thème
• Comparaison entre deux éléments explicitement présents dans le corpus

Sa latence est prévisible : retrieve (200 ms) + rerank (100 ms) + generate (1-3 s) = 1,3 à 3,3 s end-to-end. Pas d'incertitude sur le nombre de tours.

Son point faible : il ne s'adapte pas quand la requête est mal formée, ambiguë, ou nécessite de croiser plusieurs sources non directement liées.

Quand l'agent apporte réellement de la valeur

Cas 1 : questions multi-documents avec synthèse transversale

"Quelles sont les différences de politique de remboursement entre nos trois offres ?"

Un RAG classique remonte les chunks les plus proches sémantiquement de "remboursement offres". Ces chunks peuvent venir d'un seul document, ou des trois, ou d'aucun directement. La synthèse transversale est difficile à obtenir en un seul tour.

Un agent peut décomposer : "cherche la politique de remboursement offre A", "cherche offre B", "cherche offre C", puis synthétiser. Les trois sous-requêtes sont ciblées et le résultat est plus cohérent.

On a mesuré sur un assistant de support client pour une offre SaaS à trois niveaux : le score de satisfaction des réponses sur ce type de question passait de 61 % (RAG classique) à 84 % (RAG multi-step). Latence supplémentaire : +4 secondes.

Cas 2 : requêtes avec des critères de filtrage implicites

"Trouve-moi les procédures qui ont été mises à jour depuis la fusion de janvier"

Un RAG vectoriel ne gère pas nativement les filtres temporels implicites. Un agent peut extraire le filtre ("depuis janvier 2024"), le convertir en filtre metadata, et lancer une recherche filtrée.

# Ce que le self-querying génère à partir de la requête naturelle
structured_query = {
    "query": "procédures mises à jour",
    "filter": {
        "updated_at": {"$gte": "2024-01-01"},
        "type": "procedure",
    }
}

LangChain propose un module Self-Query Retriever qui automatise cette conversion. Il fonctionne bien quand les types de filtres sont prévisibles et documentés.

Cas 3 : corpus hétérogène multi-sources

Quand l'assistant doit croiser une base documentaire interne avec une API externe (prix en temps réel, données de stock, calendrier), l'architecture agentique avec outils est la seule option. Le RAG classique ne peut pas appeler d'API.

Quand l'agent n'apporte rien

Requêtes simples et directes

"Quelle est la durée de la garantie sur le produit X ?"

Cette question a une réponse unique dans le corpus. Un retrieval vectoriel simple la trouve. Passer par un agent qui "réfléchit" s'il a besoin de reformuler, puis décide que non, puis génère la même requête, c'est +2 secondes pour le même résultat.

Sur nos tests, 65 % des requêtes de support client documentaire de ce type tombent dans cette catégorie. Pour elles, le RAG classique est optimal.

Quand le retrieval de base est mal calibré

L'erreur qu'on observe régulièrement : des équipes qui ajoutent de l'agentique pour corriger un retrieval défaillant. L'agent est censé "compenser" en reformulant ou en cherchant plusieurs fois ce qu'un bon index vectoriel aurait trouvé du premier coup.

Si le recall@5 de votre retrieval est à 60 %, fix your retrieval. Un agent ReAct qui cherche 3 fois dans un index qui retourne du mauvais contenu retourne du mauvais contenu 3 fois, avec 3 fois la latence.

Contrainte de latence forte

Sur une interface conversationnelle avec une contrainte < 2 secondes, un agent iteratif est incompatible. Un tour ReAct avec GPT-4o = 2 à 4 secondes. Deux tours = 4 à 8 secondes. C'est inenvisageable sur mobile ou dans un contexte de support client temps réel.

Notre grille de décision

Avant d'ajouter de l'agentique, on répond à ces quatre questions :

1. Est-ce que le retrieval classique (recall@5 > 80 %) résout déjà le problème ?
2. La requête nécessite-t-elle de croiser des informations de plus de deux documents non directement liés ?
3. Y a-t-il des filtres ou conditions implicites dans la requête que le vectoriel ne peut pas exprimer ?
4. La latence supplémentaire (+2 à +8 s par tour) est-elle acceptable pour l'UX cible ?

Si les réponses sont "oui", "non", "non", "non", RAG classique. Si au moins deux des trois dernières sont "oui", l'agentique est à évaluer.

La question ouverte : existe-t-il un routeur fiable qui détecte automatiquement si une requête nécessite plusieurs tours d'itération, sans lui-même consommer autant de temps qu'un tour entier du pipeline agentique ?