On sait transformer du texte en vecteurs et retrouver les passages les plus proches d'une question grâce à une base vectorielle. Il reste à boucler la boucle : prendre ces passages, les donner au LLM, et obtenir une réponse ancrée dans vos données plutôt qu'inventée. C'est exactement ce que fait un RAG — Retrieval-Augmented Generation, génération augmentée par la recherche. Cet article pose le principe du RAG et décompose son architecture en quatre étapes — ingestion, indexation, retrieval, génération — réparties en deux temps : une phase d'indexation qu'on fait une fois, et une phase de requête rejouée à chaque question.
Le principe : récupérer puis générer
Un LLM seul ne connaît pas vos données et invente quand on l'interroge dessus. Le RAG corrige ce défaut par une idée simple : avant de répondre, on va chercher les passages pertinents dans une base de connaissances, et on les fournit au modèle dans son prompt. Le modèle ne répond plus « de mémoire » mais à partir d'un contexte qu'on lui a placé sous les yeux.
On parle de génération augmentée parce qu'on enrichit la requête avec un contexte récupéré dynamiquement. La génération reste le travail du LLM ; ce qui change, c'est qu'elle s'appuie sur des sources fraîches, propriétaires et vérifiables au lieu des seules connaissances figées de l'entraînement. Le bénéfice est triple : des réponses à jour (on met à jour la base, pas le modèle), ancrées (donc moins d'hallucinations) et traçables (on sait de quels passages vient la réponse).
Deux temps : indexer une fois, requêter à chaque question
L'architecture d'un RAG se lit en deux phases distinctes, qu'il ne faut pas confondre.
La phase d'indexation prépare la base de connaissances. Elle se fait en amont, une seule fois (puis à chaque mise à jour du corpus) : on charge les documents, on les découpe, on les vectorise et on range le tout dans la base vectorielle. C'est un traitement hors ligne, qui peut prendre du temps sans gêner personne.
La phase de requête répond à une question d'utilisateur. Elle se rejoue à chaque appel, et doit être rapide : on encode la question, on récupère les passages les plus proches, on les assemble avec la question dans un prompt, et le LLM génère la réponse. C'est la partie en ligne, celle que l'utilisateur attend.
Les quatre étapes
Les deux premières relèvent de l'indexation, les deux dernières de la requête.
- Ingestion.
On rassemble les documents bruts (pages web, PDF, fiches produit, tickets…) et on les nettoie pour n'en garder que le texte utile. Puis on les
découpe en morceaux — les
chunks — de taille raisonnable. Ce découpage est loin d'être anodin : la qualité du chunking conditionne tout le reste.
- Indexation.
Chaque chunk est transformé en vecteur par le
modèle d'embedding, puis stocké dans la
base vectorielle avec son texte d'origine et ses métadonnées (source, catégorie, date…). À l'issue de cette étape, la base est prête à être interrogée.
- Retrieval (récupération).
À l'arrivée d'une question, on l'encode avec
le même modèle d'embedding que les documents, puis on demande à la base les
k chunks les plus proches (par exemple les 3 ou 5 passages les plus pertinents). C'est le cœur de la recherche sémantique.
- Génération.
On construit un
prompt qui réunit la question et les passages récupérés, avec une consigne claire : « réponds
uniquement à partir du contexte fourni ». Le LLM rédige alors une réponse ancrée dans ces passages — et l'on peut afficher les sources utilisées.
Le prompt augmenté : là où tout se joue
L'étape de génération mérite qu'on s'y arrête, car c'est elle qui transforme des passages récupérés en réponse fiable. Le principe : on injecte le contexte dans le prompt et on contraint le modèle à s'y tenir.
Deux consignes y sont essentielles. « Uniquement à partir du contexte » empêche le modèle de répondre de mémoire et le force à s'ancrer. « Si tu ne sais pas, dis-le » lui donne le droit d'avouer son ignorance plutôt que d'halluciner — un aveu d'ignorance vaut mieux qu'une réponse fausse et confiante. C'est cette discipline du prompt qui distingue un RAG fiable d'un RAG qui invente malgré ses sources.
RAG, fine-tuning, gros prompt : pourquoi le RAG
Le RAG n'est pas la seule façon de spécialiser un LLM sur vos données ; c'est souvent la plus pragmatique.
- Tout mettre dans le prompt (coller le corpus entier à chaque appel) ne tient pas : fenêtre de contexte limitée, coût qui explose avec les tokens, et réponses dégradées quand on noie le modèle sous du non-pertinent.
- Le fine-tuning ré-entraîne le modèle sur vos données. Il ajuste le style et le comportement, mais grave les connaissances « en dur » : coûteux à refaire, difficile à mettre à jour, et toujours sujet aux hallucinations sur les faits précis.
- Le RAG garde les connaissances à l'extérieur du modèle, dans une base qu'on met à jour à volonté. On change un document, la réponse change — sans réentraînement. Et les sources restent traçables.
Conclusion
Un RAG répond en deux temps : une phase d'indexation qui découpe et vectorise les documents dans une base (ingestion, indexation), et une phase de requête qui récupère les passages pertinents et les injecte dans le prompt pour une génération ancrée (retrieval, génération). La fiabilité tient autant à la qualité de la récupération qu'à la discipline du prompt — « réponds uniquement à partir du contexte ». La toute première étape, l'ingestion, repose sur une opération décisive et souvent sous-estimée : le découpage des documents en chunks.
