Un assistant documentaire d'entreprise repose presque toujours sur le RAG, la génération augmentée par récupération. Derrière ce sigle unique se cachent pourtant trois architectures très différentes. Le RAG naïf récupère quelques passages et les confie au modèle. Le RAG avancé optimise chaque étape de cette chaîne sans en changer la forme. Le RAG agentique transforme la récupération en boucle de raisonnement. Le bon choix dépend du type de questions posées par vos équipes, et rarement de la sophistication de la technologie.

En bref

Le RAG se décline en trois paliers. Le RAG naïf suffit pour des questions simples sur un corpus propre. Le RAG avancé (recherche hybride, reranking, réécriture de requête) corrige la majorité des échecs du naïf pour un surcoût modeste et une latence prévisible. Le RAG agentique se justifie pour les questions qui exigent plusieurs étapes, plusieurs sources ou un calcul, au prix d'une latence variable et d'un coût par question plus élevé. En pratique, la meilleure architecture combine souvent un RAG avancé par défaut et une boucle agentique réservée aux questions complexes, aiguillées par un routeur.

  • Palier 1, le RAG naïf : une recherche, un appel au modèle.
  • Palier 2, le RAG avancé : une recherche optimisée, toujours une seule passe.
  • Palier 3, le RAG agentique : plusieurs recherches et outils, pilotés par le modèle.

D'où vient le terme « RAG naïf » ?

L'expression a été popularisée par la revue de littérature de Gao et al. publiée fin 2023, qui classe les systèmes RAG en trois générations : naïve, avancée et modulaire. Le mot « naïf » ne porte aucun jugement. Il désigne la forme la plus directe du procédé, sans optimisation particulière. Si le principe même du RAG vous est nouveau, notre guide du RAG en entreprise en pose les bases.

Depuis 2024, une autre famille s'est imposée dans le vocabulaire des équipes techniques : le RAG agentique, dans lequel un agent fondé sur un modèle de langage pilote lui-même la récupération. Une revue dédiée (Singh et al., 2025) en propose une typologie détaillée.

Beaucoup d'articles opposent aujourd'hui directement le RAG naïf au RAG agentique. Cette présentation saute l'étage le plus utile en production. Nous retenons donc ici trois paliers, le modulaire étant traité comme une manière d'assembler les briques des deux derniers.

Palier 1, le RAG naïf

Fonctionnement

À l'ingestion, les documents sont découpés en segments. Chaque segment est converti en vecteur par un modèle d'embedding, puis stocké dans une base vectorielle. Au moment de la question, celle-ci est vectorisée à son tour. Le système retient les segments les plus proches et les place dans le contexte du modèle de langage, qui rédige la réponse.

Une recherche, un appel au modèle. La latence est faible, le coût par question prévisible, le comportement facile à tracer.

Là où il suffit

Le RAG naïf donne de bons résultats quand trois conditions sont réunies. Les questions portent sur un seul document à la fois. Le vocabulaire des utilisateurs ressemble à celui des documents. Le corpus est propre, bien structuré, sans doublons ni versions concurrentes. Une FAQ interne, un règlement intérieur ou une base de procédures récente remplissent souvent ces conditions.

Là où il échoue

Ses défaillances sont bien connues et se reproduisent d'un projet à l'autre.

  • Le segment mal découpé. La réponse se trouve à cheval sur deux segments, ou un tableau a été coupé en deux.
  • Le vocabulaire métier. Sigles, références de lots, codes produits ou numéros d'articles réglementaires sont mal servis par la seule recherche sémantique, qui privilégie le sens au détriment de la correspondance exacte.
  • La question mal formulée. Une requête vague ou trop courte ramène des passages voisins mais inutiles.
  • L'absence de rattrapage. Si la recherche échoue, rien ne le détecte. Le modèle répond avec ce qu'il a reçu, au risque d'inventer.
  • Les questions composites. Une question qui croise deux documents ou deux périodes ne trouve presque jamais les deux morceaux dans une seule recherche.

Palier 2, le RAG avancé

Le RAG avancé conserve la forme linéaire du naïf. Il reste une seule passe, mais chaque étape est renforcée. Ses techniques se répartissent en trois moments.

Avant la récupération

  • Un découpage qui respecte la structure des documents (titres, sections, tableaux conservés entiers) plutôt qu'une coupe tous les N caractères.
  • Des métadonnées exploitables (type de document, version, date, service, niveau de confidentialité), qui permettent de filtrer avant de chercher et d'appliquer les droits d'accès de chaque utilisateur.
  • La réécriture de requête. Le modèle reformule la question, ajoute les synonymes métier, ou génère une réponse hypothétique qui sert ensuite de requête (technique dite HyDE).

Pendant la récupération

Le levier principal tient dans la recherche hybride. Une recherche lexicale de type BM25, qui excelle sur les sigles et références exactes, est combinée à la recherche vectorielle. Les deux classements sont fusionnés, souvent par la méthode Reciprocal Rank Fusion. Cette combinaison corrige à elle seule une grande partie des échecs liés au vocabulaire métier.

Après la récupération

  • Le reranking. Un modèle spécialisé (cross-encoder) relit les vingt ou cinquante candidats et les reclasse selon leur pertinence réelle pour la question. Seuls les meilleurs sont transmis au modèle de langage.
  • La compression du contexte, qui retire des passages les phrases sans rapport avec la question.
  • Les citations obligatoires. Le modèle rattache chaque affirmation à un passage source, ce qui rend les réponses vérifiables et les erreurs visibles.

Pourquoi ce palier compte

Le RAG avancé traite les causes les plus fréquentes d'échec du naïf sans changer la nature du système. La latence reste prévisible et le débogage simple. Le surcoût se limite à un modèle de reranking, parfois à un appel supplémentaire pour réécrire la requête. Pour la majorité des assistants documentaires, ce palier constitue la bonne cible de départ.

Sa limite tient à sa linéarité. Il ne sait toujours pas enchaîner deux recherches dont la seconde dépend du résultat de la première, ni constater qu'il n'a rien trouvé pour réessayer autrement.

Palier 3, le RAG agentique

Dans un système agentique, le modèle de langage cesse d'être un simple rédacteur. Il décide de ce qu'il faut chercher, où le chercher, si le résultat suffit et quoi faire dans le cas contraire. Quatre mécanismes le permettent.

  • Le routage. Le modèle choisit la source adaptée à la question, qu'il s'agisse de la base documentaire, d'une base de données structurée ou d'un système métier interrogé par API.
  • La décomposition. Une question complexe est découpée en sous-questions traitées dans l'ordre, la réponse de l'une servant à formuler la suivante.
  • L'auto-évaluation. Le système juge la pertinence des passages récupérés et, s'ils sont insuffisants, reformule puis relance la recherche. Les travaux Self-RAG (Asai et al., 2023) et Corrective RAG (Yan et al., 2024) ont formalisé ce principe.
  • L'appel d'outils. Requête SQL, calcul, consultation d'un référentiel. Le modèle combine texte récupéré et données exactes dans une même réponse.

Le prix de la boucle

Chaque tour de boucle ajoute un ou plusieurs appels au modèle. Une question peut donc mobiliser trois, cinq ou dix appels là où le RAG avancé n'en fait qu'un ou deux. La latence devient variable, le coût par question aussi. Le débogage se complique, car le même système peut emprunter deux chemins différents pour deux questions voisines. Les tests de non-régression exigent enfin un jeu d'évaluation plus riche.

Deux garde-fous deviennent indispensables. Un plafond d'itérations évite qu'une question sans réponse ne tourne indéfiniment. Une journalisation de chaque étape permet de comprendre a posteriori pourquoi le système a répondu ce qu'il a répondu. Ces mécanismes rejoignent ceux d'un agent IA, dont le RAG agentique constitue l'application à la recherche documentaire.

Les trois paliers comparés

Comparatif du RAG naïf, du RAG avancé et du RAG agentique sur neuf critères
CritèreRAG naïfRAG avancéRAG agentique
Appels au modèle par question11 à 2Variable, souvent 3 et plus
LatenceFaibleFaible à modéréeVariable
Prévisibilité du coûtForteForteFaible sans plafond d'itérations
DébogageSimpleSimpleComplexe, journalisation par étape nécessaire
Sigles, références exactesFragileBien servis (recherche hybride)Bien servis
Questions multi-documentsÉchoue souventPartiellementAdapté
Calcul ou données structuréesNonNonOui, via outils
Détection d'un échec de récupérationNonNonOui
Prérequis principalCorpus propreCorpus structuré, métadonnéesModèle fiable en appel d'outils, jeu d'évaluation

Ce qui change en déploiement on-premise

La plupart des comparaisons raisonnent en coût d'API, facturé au token. Dans un déploiement souverain sur vos propres serveurs, l'arbitrage change de nature.

Le coût se mesure en temps GPU. Le coût marginal d'une question est faible, mais la capacité de calcul est fixe. Chaque tour de boucle agentique occupe le GPU plus longtemps et allonge la file d'attente des autres utilisateurs. Généraliser l'agentique peut ainsi dégrader le temps de réponse de toute l'organisation aux heures de pointe.

La fiabilité dépend de la taille du modèle. Les modèles open-weight que l'on héberge raisonnablement sur site sont en général moins sûrs que les très grands modèles propriétaires sur les tâches qui font fonctionner une boucle agentique. Il s'agit de choisir le bon outil, de juger la pertinence d'un passage et de décider quand s'arrêter. Piloté par un modèle trop petit, le système peut tourner en rond ou conclure trop tôt. Cet écart se mesure sur vos propres questions, avant tout engagement.

Le RAG avancé reste économe en ressources. Ses composants (index BM25, modèle de reranking compact) demandent peu de calcul et tournent parfois sur processeur. Ils améliorent la qualité sans peser sur la capacité GPU réservée à la génération.

En contexte on-premise, l'architecture la plus robuste combine donc généralement un RAG avancé pour l'essentiel du trafic et une boucle agentique bornée, limitée au routage et à la décomposition simple, pour les questions qui l'exigent réellement. Les choix d'hébergement, de juridiction et de gouvernance associés sont détaillés dans notre guide du RAG souverain et on-premise, et les critères de sélection d'une solution dans notre page IA d'entreprise sécurisée on-premise.

Comment décider : une méthode en quatre temps

  1. Constituer un jeu d'évaluation. Rassemblez quelques dizaines de vraies questions posées par les futurs utilisateurs, avec la réponse attendue et le document qui la contient.
  2. Classer ces questions par type. Question factuelle sur un document, question croisant plusieurs documents, question demandant un calcul ou une donnée chiffrée, question comparative dans le temps.
  3. Mesurer palier par palier. Testez d'abord un RAG naïf, puis ajoutez les techniques du RAG avancé une à une, en mesurant à chaque fois le taux de bonnes réponses par type de question.
  4. Réserver l'agentique aux classes qui échouent encore. Si une famille de questions résiste au RAG avancé, un routeur peut l'orienter vers une boucle agentique, pendant que le reste du trafic emprunte le chemin court.

Cette démarche évite deux erreurs symétriques. La première consiste à déployer un RAG naïf qui déçoit dès la première semaine. La seconde revient à bâtir une architecture agentique coûteuse pour des questions qu'un reranker aurait suffi à traiter. Nous appliquons la même logique d'évaluation dans notre article sur le pilote RAG en ressources humaines.

Illustration dans l'industrie pharmaceutique

Les deux exemples suivants sont des illustrations types, non des cas clients.

« Quelle est la température de stockage prévue par la procédure de conditionnement en vigueur ? » relève du RAG avancé. La réponse tient dans un document, mais il faut retrouver la bonne version et la bonne référence de procédure, ce que la recherche hybride et le filtrage par métadonnées assurent.

« Quels écarts reviennent le plus souvent dans les rapports de déviation des trois dernières années, et quelles actions correctives ont été engagées ? » relève de l'agentique. Il faut interroger plusieurs années de rapports, regrouper, compter, puis rapprocher chaque écart de ses actions correctives. Les exigences de traçabilité et de validation propres à ces environnements sont traitées dans notre guide du RAG en secteur réglementé.

Quelle architecture pour vos documents ?

Le Diagnostic IA express de 30 minutes qualifie vos types de questions, l'état de vos documents et vos contraintes d'hébergement, avant tout choix technique. Gratuit et sans engagement.

Demander mon Diagnostic IA express

Questions fréquentes

Que signifie « RAG naïf » ?

Le RAG naïf désigne la forme la plus simple de génération augmentée par récupération. Une seule recherche vectorielle retrouve les passages les plus proches de la question, puis un seul appel au modèle de langage rédige la réponse. Le terme a été popularisé par la revue de Gao et al. (2023) et ne porte aucun jugement de valeur.

Quelle différence entre RAG avancé et RAG agentique ?

Le RAG avancé optimise une chaîne qui reste linéaire, avec une recherche hybride, un reranking et une réécriture de la requête, en une seule passe. Le RAG agentique confie au modèle le pilotage de la récupération, qui peut enchaîner plusieurs recherches, appeler des outils et relancer une recherche jugée insuffisante.

Le RAG agentique est-il toujours plus performant ?

Non. Sur des questions simples portant sur un seul document, il n'apporte généralement pas de gain par rapport à un RAG avancé, tout en augmentant la latence et le coût. Son avantage se concentre sur les questions multi-étapes, multi-sources ou nécessitant un calcul.

Par quel palier commencer un projet d'assistant documentaire ?

Le RAG avancé constitue le point de départ le plus sûr pour la majorité des projets. Il corrige les échecs fréquents du RAG naïf pour un surcoût limité, et il fournit une base mesurable à partir de laquelle décider si une boucle agentique se justifie pour certaines questions.

Le RAG agentique fonctionne-t-il en déploiement on-premise ?

Oui, à condition de borner la boucle. En local, chaque itération consomme du temps GPU partagé entre tous les utilisateurs, et les modèles hébergés sur site sont souvent moins fiables pour l'appel d'outils que les très grands modèles propriétaires. Un plafond d'itérations, une journalisation par étape et un routage qui réserve la boucle aux questions complexes sont recommandés.

Sources

Retour au blog