Un RAG classique reçoit une question, récupère des passages puis génère une réponse. Cette chaîne est rapide, compréhensible et adaptée à de nombreux usages documentaires. Un RAG agentique ajoute une boucle : le modèle analyse la question, choisit une source ou un outil, examine le résultat, reformule et poursuit jusqu’à un critère d’arrêt.
Cette autonomie peut résoudre des questions multi-étapes. Elle augmente également le nombre d’appels, la variabilité et la surface d’attaque. L’objectif n’est pas de rendre tout RAG agentique, mais de réserver la planification aux tâches qui en ont besoin.
Le RAG classique comme baseline
Une architecture simple comprend :
- normalisation de la question ;
- recherche plein texte, vectorielle ou hybride ;
- filtrage des droits ;
- reranking éventuel ;
- construction du contexte ;
- génération avec citations ;
- contrôle de format.
Elle est testable étape par étape. La latence et le coût sont prévisibles. Une grande partie des problèmes vient de la qualité du corpus, du découpage ou de la recherche, pas de l’absence d’agent.
Les limites d’une recherche unique
Une seule requête devient insuffisante lorsque la question demande :
- comparer plusieurs entités ;
- relier des événements dans le temps ;
- consulter des sources différentes ;
- calculer à partir de résultats ;
- résoudre une ambiguïté ;
- vérifier une affirmation ;
- enchaîner recherche et outil métier.
Une question comme « quelles clauses ont changé entre les deux versions et quel impact sur les dossiers ouverts ? » nécessite plusieurs étapes et sources.
Avant l’agent : les stratégies intermédiaires
Reformulation contrôlée
Une règle ou un modèle produit quelques variantes, puis les résultats sont fusionnés. Le nombre d’appels reste borné.
Décomposition selon un patron
Pour une comparaison, le système crée une sous-question par entité puis rassemble les réponses. La structure est connue et testable.
Routage
Un classifieur choisit l’index, la langue ou l’outil. Il ne planifie pas librement.
Reranking et contexte voisin
Parfois, le passage pertinent existe déjà dans les candidats. Améliorer le classement suffit.
Ces techniques offrent une partie des bénéfices avec moins de variabilité.
Ce qu’ajoute un RAG agentique
Un agent maintient un état de recherche, choisit une prochaine action et évalue si l’information est suffisante. Il peut :
- demander une clarification ;
- sélectionner une source ;
- générer une requête ;
- appeler une API ;
- lire un résultat ;
- détecter une lacune ;
- vérifier une affirmation ;
- synthétiser avec provenance.
Les actions doivent rester dans un catalogue borné et le plan n’est jamais une autorisation.
Les critères qui justifient une boucle agentique
Variabilité du chemin
Les questions exigent des étapes différentes qui ne peuvent pas être codées simplement.
Sources multiples
Documents, base, web autorisé et outils métier doivent être coordonnés.
Vérification possible
Le système peut contrôler une somme, une citation, une cohérence ou la présence d’une preuve.
Valeur suffisante
Le gain sur les questions complexes compense la latence et le coût.
Tolérance à l’incertitude
Le résultat est relu ou utilisé dans une décision dont les contrôles sont adaptés.
Jeu d’évaluation
Des cas multi-étapes permettent de mesurer si la boucle apporte réellement une amélioration.
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Quatre niveaux de RAG, de la récupération unique à la recherche agentique itérative avec vérification.
Concevoir le plan comme un état explicite
Le plan ne doit pas exister uniquement dans un texte caché. Le système conserve des étapes structurées : objectif, action, paramètres, résultat, preuve, statut et prochaine décision.
Cette représentation permet :
- limitation du nombre d’étapes ;
- reprise ;
- affichage à l’utilisateur ;
- audit ;
- comparaison ;
- interruption.
Les raisonnements privés du modèle ne sont pas nécessaires. Il suffit de conserver des décisions opérationnelles et justifications courtes.
Choisir des outils bornés
Un outil de recherche reçoit une requête, des filtres et un nombre maximal. Un calculateur exécute une opération définie. Un accès métier respecte les droits. L’agent ne reçoit pas un shell, un SQL ou un navigateur illimité.
Chaque outil renvoie des données structurées, une provenance et les erreurs. Les résultats sont considérés comme non fiables jusqu’à validation.
Définir les critères d’arrêt
Une boucle sans limite peut continuer à chercher, consommer et accumuler du bruit. Les critères incluent :
- nombre maximal d’étapes ;
- budget de tokens ou coût ;
- durée ;
- preuves suffisantes ;
- absence de nouvelle information ;
- confiance minimale ;
- besoin de clarification ;
- action interdite.
Lorsque le critère n’est pas atteint, le système produit une réponse partielle ou un refus explicite.
Vérifier plutôt que s’auto-convaincre
Demander au même modèle s’il est satisfait ne constitue pas une preuve. Les vérifications utiles sont externes : références existantes, calcul, schéma, contraintes métier, seconde méthode de recherche ou revue humaine.
Un modèle peut jouer un rôle critique, mais ses verdicts sont calibrés sur des cas humains et ne remplacent pas les contrôles déterministes.
Gérer les citations multi-étapes
Chaque affirmation finale doit être reliée aux passages et résultats qui la soutiennent. Le système conserve la provenance à chaque étape et évite qu’un résumé intermédiaire perde les références.
Lorsqu’un calcul utilise plusieurs sources, afficher les entrées, les versions et la formule. Les contradictions sont signalées.
Sécurité
La boucle augmente l’exposition à la prompt injection : chaque document et réponse d’outil peut tenter d’influencer le plan. Les données restent séparées des politiques. Les outils et destinations sont contrôlés par une couche indépendante.
Le contexte de chaque étape est minimal. Les secrets ne sont jamais accessibles au modèle. Les appels web ou code s’exécutent dans un environnement isolé.
Latence et expérience utilisateur
Une recherche agentique peut prendre plusieurs secondes ou minutes. L’interface montre l’état utile : sources en cours, étape, possibilité d’annuler et résultat partiel. Elle n’affiche pas de pseudo-raisonnement théâtral.
Les tâches longues peuvent être asynchrones, avec notification et reprise. Un cache réutilise les sous-résultats stables lorsque les droits et la fraîcheur le permettent.
Coût
Le coût varie avec le nombre d’étapes, de requêtes, de tokens et de rerankings. Un budget par tâche et un modèle de routage empêchent les boucles coûteuses.
Les questions simples doivent emprunter le chemin direct. Un classifieur ou des règles peuvent réserver l’agent aux intentions complexes.
Évaluer l’apport
Comparer le RAG agentique à une baseline forte, pas à un prototype faible. Mesurer :
- taux de réponse correcte ;
- couverture des preuves ;
- qualité des refus ;
- nombre d’étapes ;
- latence ;
- coût ;
- stabilité ;
- erreurs d’outil ;
- satisfaction.
L’analyse par type de question révèle où l’agent est utile et où il dégrade l’expérience.
Déployer progressivement
Commencer en mode observation : l’agent propose un plan sans agir, puis comparer à la méthode actuelle. Activer ensuite quelques outils en lecture, des budgets stricts et une revue humaine.
Les cas échoués alimentent la suite d’évaluation. Les limites sont augmentées seulement si les gains sont prouvés.
La simplicité comme architecture par défaut
Un RAG classique bien conçu reste le meilleur choix pour une base de connaissances et des questions directes. La recherche agentique devient pertinente lorsque la tâche exige réellement une exploration variable et vérifiable.
Partitech peut construire une baseline RAG, concevoir les boucles de recherche, sécuriser les outils et mettre en place les évaluations comparatives. L’objectif est d’ajouter de l’autonomie uniquement là où elle améliore la qualité utile.
Parlons de votre projet
Évaluer l’intérêt d’un RAG agentique sur vos cas réels avec Partitech. Contactez Partitech.