RAG (Retrieval-Augmented Generation)

Qu'est-ce que le RAG ?

Le Retrieval-Augmented Generation (RAG) est une architecture dans laquelle le prompt d'un LLM est complété dynamiquement par des documents récupérés depuis un store externe, juste avant la génération. Au lieu de s'appuyer uniquement sur les poids figés lors de l'entraînement, le modèle lit du contexte fraîchement récupéré et ancre sa réponse dans ce contenu.

La boucle minimale est la suivante : (1) générer des embeddings pour la requête de l'utilisateur, (2) récupérer les k chunks les plus proches dans un vector store, (3) préfixer ces chunks au prompt, (4) générer. Chaque étape a des implications en termes de coût et de qualité.

Pourquoi le RAG est important pour les agents de coding IA en 2026

Les agents de coding comptent parmi les plus gros utilisateurs de RAG en production. Leurs « documents » sont des fichiers sources, des pages README, des références API, des runbooks et des logs d'erreurs — du contenu qui change à chaque commit et qu'aucun modèle ne peut avoir mémorisé avec précision.

Pression sur le budget de contexte. Un agent travaillant sur un grand monorepo ne peut pas charger l'intégralité du code dans sa context window. Le RAG est le mécanisme de sélection : il décide quels fichiers entrent dans la fenêtre. La qualité du retrieval détermine directement combien de tokens du modèle sont consacrés à du code pertinent plutôt qu'à du bruit.

Fraîcheur. Les données d'entraînement ont une date limite. Votre API interne, votre SDK personnalisé, le guide de style de votre équipe — rien de tout cela ne figure dans les poids d'un modèle public. Le RAG est la réponse standard : maintenir un index vectoriel en temps réel, récupérer à la demande, rester à jour sans fine-tuning.

Maîtrise des coûts. Un agent naïf pourrait injecter dans le prompt tous les fichiers potentiellement liés « au cas où ». Le RAG discipline cette approche : seuls les top-k chunks sont inclus, plaçant la taille du prompt sous un plafond prévisible. Associé à une étape de compaction (suppression du boilerplate des chunks récupérés avant leur entrée dans le prompt), il est possible de réduire drastiquement le coût en tokens par requête. Voir réduire l'utilisation de tokens des agents de coding IA.

Le goulot d'étranglement de la qualité du retrieval

Le plafond du RAG est fixé par le retrieval, pas par la génération. Un modèle puissant lisant des chunks non pertinents hallucine avec confiance. Les trois leviers :

1. Taille des chunks. Trop grande : le signal se dilue dans du remplissage. Trop petite : le contexte inter-lignes se perd. Pour du code source, les chunks au niveau des fonctions surpassent généralement les chunks au niveau des lignes ou des fichiers.
2. Modèle d'embeddings. Les embeddings constituent la colonne vertébrale du retrieval. Un modèle d'embeddings faible signifie que du code sémantiquement pertinent se classe derrière des correspondances superficiellement similaires mais inutiles.
3. Re-ranking. Un cross-encoder léger re-score les 50 meilleurs candidats avant que les 5 finalistes n'entrent dans le prompt. Cela ajoute un petit coût en tokens pour un gain de précision significatif.

RAG vs fine-tuning

Le fine-tuning ancre la connaissance dans les poids — coûteux, lent à mettre à jour, et opaque. Le RAG stocke la connaissance en externe — facile à mettre à jour, auditable et débogable (vous pouvez journaliser exactement quels chunks ont été récupérés). Pour la plupart des cas d'usage d'agents en 2026, le RAG est le bon choix par défaut et le fine-tuning est l'optimisation à laquelle on recourt une fois que le RAG atteint ses limites.

RAG vs une fenêtre de 1M de tokens

L'argument « pourquoi ne pas tout charger ? » a pris de l'ampleur en 2026. En octobre 2026, tous les modèles Claude actuels (Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5) offrent un context window de 1M de tokens, et Anthropic facture une requête de 900k tokens au même tarif par token qu'une requête de 9k (sauf Haiku 5.5, plus cher au-delà de 100k tokens de prompt) ; GPT-6 Astra affiche une fenêtre de 1 050 000 tokens. « Tout charger » devient techniquement possible pour beaucoup de dépôts de taille moyenne. Ça ne le rend pas bon marché : un agent renvoie ce contexte à chaque tour, donc une fenêtre remplie à 800k tokens, c'est une facture d'input de 800k tokens par étape. Le retrieval reste ce qui garde chaque tour petit. Beaucoup d'agents de code récupèrent désormais via des appels d'outils (grep, recherche de symboles, lectures ciblées de fichiers) plutôt que via un index vectoriel préconstruit, mais le principe reste celui du RAG : aller chercher les quelques morceaux pertinents, pas tout le corpus.

Quand le RAG n'est PAS le bon outil

• Bases de connaissances petites et stables. Si l'intégralité de votre référence tient dans une context window et change rarement, sautez la couche de retrieval et chargez-la directement. Le RAG ajoute de la latence et de la complexité sans apporter de bénéfice.
• Recherches syntaxiques précises. Trouver toutes les occurrences d'une signature de fonction spécifique est un problème de grep/AST, pas de retrieval. La semantic search et le RAG sont complémentaires aux outils de correspondance exacte, non des remplaçants.
• Chemins critiques en latence. Chaque aller-retour RAG ajoute un appel d'embeddings plus une requête vers le vector store avant même que la génération ne commence. Si votre budget de rate limit ou votre SLA utilisateur est serré, un prompt mis en cache peut surpasser un retrieval frais.
• Requêtes hautement structurées. Quand la réponse est déterministe — « quel est le type de retour de la fonction X ? » — un outil d'analyse statique fournit une réponse plus rapide, moins coûteuse et exacte.

Voir aussi

• Embeddings — la colonne vertébrale vectorielle qui rend le retrieval possible
• Fine-tuning — l'alternative au retrieval, et le moment où elle cesse d'en valoir la peine
• Context window — le budget que le RAG est conçu à remplir intelligemment
• Token — l'unité de coût pour chaque chunk injecté par le RAG
• Tokenizer — détermine comment les chunks sont comptés dans le budget de contexte
• Context engineering
• Réduire l'utilisation de tokens des agents de coding IA