Définition

RAG — Définition IT

Retrieval-Augmented Generation : architecture qui combine recherche d'information et génération par un LLM pour produire des réponses ancrées sur des sources vérifiées.

Le RAG (Retrieval-Augmented Generation, ou Génération Augmentée par Récupération) est le pattern d'architecture dominant pour utiliser un LLM sur des données métier. Il consiste à récupérer les passages pertinents d'une base documentaire (recherche), puis à les injecter dans le prompt du modèle (génération) pour qu'il produise une réponse ancrée sur ces sources, plutôt que sur son entraînement seul.

Le RAG est devenu l'approche standard pour réduire les hallucinations, traiter des données récentes ou propriétaires (postérieures au knowledge cutoff), et fournir des réponses sourcées et auditables. Selon Gartner, plus de 80 % des projets GenAI d'entreprise déployés en 2025 s'appuient sur une architecture RAG, contre moins de 20 % en 2023.

Pourquoi le RAG existe

Sans RAG, un LLM répond uniquement à partir de ses paramètres internes — ce qui pose trois problèmes :

•Knowledge cutoff: : le modèle ignore tout ce qui s'est passé après sa date d'entraînement.
•Données privées: : les documents internes de l'entreprise ne sont pas dans son corpus.
•Hallucinations: : sans source à citer, le modèle invente plausiblement.

Le RAG résout ces trois problèmes : la réponse s'appuie sur des sources externes à jour, l'entreprise garde la maîtrise des données, et les sources peuvent être citées.

Comment fonctionne un pipeline RAG

Un pipeline RAG type comprend cinq étapes :

Indexation : les documents sources (PDF, pages web, base SQL, tickets) sont découpés en chunks, embeddés (transformés en vecteurs) et stockés dans une vector database (Pinecone, Weaviate, Qdrant, pgvector, OpenSearch).
Question utilisateur : l'utilisateur pose une question en langage naturel.
Récupération : la question est embeddée à son tour, puis comparée par similarité vectorielle aux chunks indexés. Les top-k chunks les plus pertinents sont retournés.
Augmentation : les chunks récupérés sont injectés dans le prompt du LLM avec la question.
Génération : le LLM produit une réponse en s'appuyant sur ces chunks, idéalement en citant les sources.

Le RAG peut être combiné avec une recherche par mots-clés classique (BM25), des filtres métadonnées, et un re-ranker (modèle qui réordonne les résultats par pertinence).

Variantes de RAG

•Naive RAG: : pipeline basique tel que décrit ci-dessus.
•Advanced RAG: : ajoute pré-traitement (réécriture de la question), post-traitement (re-ranking, compression), métadonnées.
•GraphRAG: : combine vector store et graphe de connaissances pour des questions multi-hop.
•Hybrid RAG: : combine recherche vectorielle et recherche lexicale (BM25).
•Agentic RAG: : un agent IA décide quand et comment récupérer, peut formuler plusieurs requêtes successives.
•Self-RAG: : le modèle critique sa propre réponse et déclenche une nouvelle récupération si besoin.

RAG vs fine-tuning vs long contexte

Trois approches concurrentes pour donner du savoir métier à un LLM :

•RAG: : récupérer dynamiquement le contexte pertinent à chaque question. Souple, mise à jour facile, sourcé. Standard de l'industrie.
•Fine-tuning: : adapter les poids du modèle à un domaine. Coût d'entraînement, mise à jour lourde, mais utile pour le ton, le format ou des tâches très spécifiques.
•Long contexte: : pousser tout le corpus dans la fenêtre de contexte (1M+ tokens chez Gemini 2 ou Claude). Simple mais coûteux à chaque appel, et la qualité diminue sur les contextes très longs (lost in the middle).

Les trois approches sont complémentaires plus que concurrentes. La majorité des déploiements sérieux combinent RAG + fine-tuning léger.

Les défis du RAG en production

Beaucoup de projets RAG démarrent en démo et coincent en production. Les points de vigilance :

•Qualité du *chunking: * : trop fin = perte de contexte, trop large = bruit.
•Embeddings adaptés: : un embedding généraliste (OpenAI text-embedding-3) peut être moins bon qu'un embedding fine-tuné pour le domaine.
•Métadonnées: : sans filtres (date, équipe, classification), la récupération devient bruitée à l'échelle.
•Permissions et confidentialité: : le RAG doit respecter les droits d'accès — un collaborateur ne doit recevoir que les chunks auxquels il a accès. Souvent oublié.
•Évaluation: : mettre en place un eval set propre à l'entreprise pour mesurer pertinence, fidélité aux sources, hallucinations.
•Coût d'inférence: : chaque question coûte un appel LLM + des embeddings ; à grande échelle, le budget peut exploser.
•Mise à jour: : ré-indexer régulièrement les sources, gérer les suppressions.

RAG et contexte du SI

Pour répondre à des questions internes (« qui est propriétaire de cette application ? », « combien dépense-t-on sur Slack ? », « quelles applications sont en obsolescence ? »), le RAG doit puiser dans le patrimoine vivant du SI. C'est précisément ce que Kabeen expose — à la fois via API REST, via MCP et via un endpoint RAG dédié — pour alimenter les copilotes IA d'entreprise avec un contexte exact et à jour.

Outils RAG courants

•Vector databases: : Pinecone, Weaviate, Qdrant, Milvus, pgvector, Chroma.
•Frameworks: : LangChain, LlamaIndex, Haystack, DSPy.
•Embeddings: : OpenAI, Cohere, Voyage, BGE, Mistral Embed.
•Plateformes managées: : Azure AI Search, AWS Kendra, Vertex AI Search.
•Évaluation: : Ragas, TruLens, DeepEval.

Questions fréquentes

Qu'est-ce que le RAG ?

Le RAG (Retrieval-Augmented Generation, ou Génération Augmentée par Récupération) est une architecture qui combine recherche d'information et génération par un LLM. Plutôt que de répondre à partir de ses seuls paramètres, le LLM reçoit dans son prompt les passages pertinents d'une base documentaire interne — ce qui ancre la réponse sur des sources vérifiées et réduit drastiquement les hallucinations.

Pourquoi utiliser le RAG plutôt qu'un LLM brut ?

Trois raisons : (1) un LLM seul ignore tout ce qui s'est passé après son entraînement (knowledge cutoff), (2) un LLM seul ne connaît pas les données internes de votre entreprise, (3) sans source à citer, un LLM invente plausiblement (hallucinations). Le RAG résout ces trois problèmes : sources à jour, données privées maîtrisées, réponses sourcées et auditables.

Quelle différence entre RAG et fine-tuning ?

Le RAG récupère dynamiquement le contexte pertinent à chaque question — souple, facile à mettre à jour, sourcé. Le fine-tuning adapte les poids du modèle à un domaine — meilleur pour le ton, le format ou des tâches très spécifiques, mais coûteux à entraîner et à mettre à jour. Les deux sont complémentaires : la majorité des déploiements sérieux combinent RAG sur les données métier et fine-tuning léger sur le format de réponse.

Quels sont les pièges du RAG en production ?

Sept points de vigilance récurrents : la qualité du chunking, le choix d'embeddings adaptés au domaine, la richesse des métadonnées pour filtrer, le respect des permissions utilisateur (souvent oublié), la mise en place d'un eval set propre, le coût d'inférence à grande échelle, et la stratégie de ré-indexation pour gérer les mises à jour. Un RAG qui marche en démo et casse en production échoue presque toujours sur l'un de ces points.

Besoin d'aide pour cartographier votre SI ?

Kabeen vous aide à inventorier, analyser et optimiser votre portefeuille d'applications.

Essayer gratuitement