RAG (Retrieval-Augmented Generation) : définition et fonctionnement

Le RAG est l'une des briques techniques qui alimentent les agents IA autonomes d'aujourd'hui, aux côtés de l'appel d'outils et de la mémoire persistante. Le sigle vient d'un article de recherche publié en mai 2020 par une équipe de Facebook AI Research (aujourd'hui Meta), Patrick Lewis en tête. À l'époque, le constat était simple : les grands modèles de langage stockent une quantité impressionnante de savoir dans leurs paramètres, mais ils ne peuvent ni le mettre à jour facilement, ni pointer précisément vers une source. Le RAG propose une solution : laisser le modèle aller chercher l'information dans une base externe au moment de répondre, plutôt que de tout faire reposer sur sa mémoire figée à l'entraînement.

Définition détaillée

Retrieval-Augmented Generation, ou génération augmentée par la recherche, désigne une architecture qui combine deux briques distinctes : un mécanisme de recherche (retrieval) qui va chercher des passages pertinents dans une base documentaire externe, et un modèle de génération de texte qui rédige la réponse finale à partir de ces passages. Dans l'article fondateur de Lewis et ses co-auteurs (NeurIPS 2020), le RAG associe une mémoire paramétrique (les connaissances internes du modèle pré-entraîné) et une mémoire non paramétrique (une base de documents consultée à la volée), pour améliorer les performances sur des tâches qui demandent des connaissances précises.

Le consensus autour de cette définition est large : que ce soit dans la littérature académique ou dans les explications grand public comme celle de NVIDIA, le RAG revient toujours à cette même mécanique en deux temps, chercher puis générer. Les divergences concernent surtout la mise en œuvre technique (type de base vectorielle, méthode de découpage des documents, nombre de passages récupérés), pas la définition du principe lui-même.

Le RAG répond à deux limites connues des modèles de langage : les hallucinations, quand le modèle invente une réponse plausible mais fausse, et l'obsolescence, quand une information a changé depuis la date d'entraînement du modèle. En ancrant la génération sur des documents réels et à jour, le RAG réduit ces deux problèmes sans nécessiter de ré-entraîner le modèle.

Comment ça marche

Le déroulé typique d'une requête RAG suit trois étapes. D'abord, la question de l'utilisateur (ou le besoin d'un agent) est transformée en une recherche dans une base documentaire, souvent via une recherche de similarité sur des représentations vectorielles du texte, parfois combinée à une recherche par mots-clés classique. Ensuite, les passages les plus pertinents remontés par cette recherche sont injectés dans le contexte envoyé au modèle de langage, en plus de la question initiale. Enfin, le modèle génère sa réponse en s'appuyant sur ces passages, idéalement en citant ou en s'alignant sur leur contenu plutôt qu'en improvisant.

Cette mécanique se prête bien à l'usage par un agent IA autonome : la recherche documentaire peut être exposée comme un outil que l'agent appelle lui-même, au moment où il juge en avoir besoin, plutôt que d'être systématiquement déclenchée avant chaque réponse. C'est la différence entre un RAG « statique », branché en amont de chaque requête, et un RAG « agentique », où le modèle décide quand chercher, quoi chercher, et s'il doit chercher à nouveau si le premier résultat ne suffit pas.

Exemple concret avec Atako

La documentation publique d'Atako ne détaille pas l'architecture interne de recherche documentaire utilisée par ses agents, donc impossible d'affirmer ici qu'Atako utilise du RAG au sens strict de l'article de Lewis et al. Ce qui est documenté, en revanche, c'est le mécanisme le plus proche : chaque agent dispose d'une bibliothèque de fichiers partagée par l'entreprise, organisée en dossiers, avec des formats prévisualisables (Markdown, CSV, JSON, PDF, HTML, images, texte, code source). Ces fichiers peuvent être partagés avec un agent en lecture, ou ajoutés directement dans un dossier dédié à l'agent, par un humain ou par l'agent lui-même.

Cette bibliothèque de fichiers, combinée à la mémoire persistante d'un agent qui survit aux redémarrages et aux pauses, joue le rôle de base de connaissance externe que l'agent peut consulter avant de répondre ou d'agir, ce qui correspond dans l'esprit au principe du RAG : aller chercher de l'information réelle plutôt que de s'appuyer uniquement sur ce que le modèle a mémorisé à l'entraînement. Un agent configuré pour le support client, par exemple, peut consulter des fichiers de documentation produit partagés dans son dossier avant de répondre à un ticket, plutôt que de deviner la réponse.

Erreurs fréquentes

Première confusion fréquente : croire que le RAG est une fonctionnalité qu'on active d'un clic, comme un bouton dans un logiciel. C'est en réalité une architecture, avec des choix techniques concrets (comment découper les documents, comment les indexer, combien de passages remonter) qui déterminent directement la qualité des réponses.

Deuxième erreur : penser que le RAG élimine totalement les hallucinations. Il les réduit en ancrant la génération sur des documents vérifiables, mais un modèle peut encore mal interpréter un passage, ou générer une réponse à partir de documents non pertinents remontés par une recherche imparfaite. Le RAG déplace le risque, il ne le supprime pas.

Troisième erreur : confondre RAG et fine-tuning. Le fine-tuning modifie durablement le modèle en le ré-entraînant sur des données spécifiques ; le RAG laisse le modèle intact et lui ajoute une base externe consultée à chaque requête, ce qui est plus rapide à mettre à jour et généralement moins coûteux.

Enfin, sous-estimer l'importance de la qualité de la base documentaire est une erreur classique. Un système RAG branché sur des documents obsolètes, mal structurés ou incomplets produira des réponses de mauvaise qualité, quelle que soit la puissance du modèle de génération utilisé derrière.