RAG : la technique qui rend les LLM fiables en entreprise

Introduction

Un LLM (Large Language Model) comme GPT, Claude ou Gemini ne connaît rien de vos documents internes. Il a été entraîné sur le web public, pas sur vos mails, vos notes Notion ou vos rapports confidentiels. Le RAG (Retrieval-Augmented Generation, ou « génération augmentée par récupération ») comble ce vide sans réentraîner le modèle. C'est la technique que toutes les organisations sérieuses utilisent pour brancher un LLM sur leurs données privées, et c'est aussi celle qui échoue le plus silencieusement en production quand elle est implémentée trop naïvement.

Cet article détaille le fonctionnement réel du RAG : comment on transforme des documents en objets cherchables, comment on retrouve les bons passages, et pourquoi la version « tutoriel » de cette architecture ne tient pas la route face à de vrais utilisateurs.

Le RAG en bref : pourquoi cette technique s'impose

Deux notions à maîtriser avant d'aller plus loin :

• Un LLM prédit le mot suivant à partir d'un texte d'entrée. Rien de plus, rien de moins.
• Un vecteur (ou embedding) est une liste de nombres qui représente le sens d'un texte. Deux textes proches en signification ont des vecteurs proches mathématiquement.

Avant le RAG, deux options existaient pour exploiter des données privées : le fine-tuning (réentraîner un modèle, coûteux et rigide) ou l'absence pure et simple de contexte métier. Le RAG propose une troisième voie : injecter dynamiquement, dans le prompt, les passages pertinents récupérés à la volée dans une base documentaire.

Cette architecture est au cœur de fonctionnalités comme Azure OpenAI On Your Data, des connecteurs Microsoft Graph utilisés par Copilot, ou des solutions bâties avec LangChain ou LlamaIndex.

L'indexation : transformer des documents en vecteurs cherchables

L'indexation est le travail effectué une seule fois, en amont, pour rendre une base documentaire interrogeable.

Le découpage (chunking)

Les modèles d'embedding ont une limite de taille en entrée (souvent quelques centaines à quelques milliers de tokens). Il faut donc découper les documents en morceaux, ou chunks :

• Trop petit (environ 50 mots) : le morceau perd son contexte et devient une phrase isolée sans signification propre.
• Trop grand (plusieurs milliers de mots) : le vecteur résultant mélange trop d'idées différentes, ce qui rend la recherche imprécise.
• Taille pratique : entre 500 et 1 000 mots par chunk, avec découpage sur des frontières naturelles (fin de paragraphe, de section).

Une technique courante consiste à ajouter un overlap (chevauchement) entre chunks consécutifs, par exemple un chunk de 0 à 500 mots, le suivant de 450 à 950 mots. Cela évite qu'une idée à cheval sur une frontière soit perdue.

1{
2  "chunk_size": 800,
3  "chunk_overlap": 100,
4  "splitter": "recursive_character"
5}

Des approches plus fines existent, comme le chunking sémantique, qui découpe non pas sur une longueur fixe mais quand le sujet change réellement dans le texte.

La transformation en embeddings

Un modèle d'embedding (par exemple text-embedding-3 d'OpenAI ou BGE en open source) ne génère pas de texte : il prend un chunk en entrée et produit un vecteur, typiquement de 1 536 dimensions pour text-embedding-3-small. Chaque dimension capture une facette abstraite du sens (thématique, ton, technicité, etc.).

1from openai import OpenAI
2client = OpenAI()
3 
4response = client.embeddings.create(
5    model="text-embedding-3-small",
6    input=chunk_text
7)
8vector = response.data[0].embedding  # liste de 1536 flottants

Le stockage dans une base vectorielle

Les vecteurs sont stockés dans une base de données vectorielle optimisée pour retrouver rapidement des vecteurs proches d'un autre vecteur : Pinecone, Chroma, Weaviate, ou dans l'écosystème Microsoft, Azure AI Search avec son support natif de la recherche vectorielle.

La recherche vectorielle : retrouver les bons passages

Une fois la question de l'utilisateur transformée en vecteur (avec exactement le même modèle d'embedding que celui utilisé pour indexer les documents), on cherche les chunks les plus proches par recherche des k plus proches voisins (k-NN), k valant généralement 3 à 5.

La mesure de proximité la plus utilisée est la similarité cosinus : au lieu de mesurer une distance, on mesure l'angle entre deux vecteurs. Un score proche de 1 signifie des textes similaires, proche de 0 des textes sans rapport, proche de -1 des textes opposés.

Génération de la réponse : le prompt augmenté

Une fois les chunks pertinents récupérés, ils sont injectés dans un prompt structuré :

1Réponds à la question suivante en te basant uniquement sur le contexte ci-dessous.
2 
3Contexte :
4{chunks récupérés}
5 
6Question : {question de l'utilisateur}

Le flux complet du RAG vanille (ou RAG basique) tient en six étapes :

1. L'utilisateur pose une question.
2. La question est vectorisée.
3. On recherche les chunks les plus proches dans la base vectorielle.
4. Les chunks sont insérés dans un prompt.
5. Le prompt est envoyé au LLM.
6. La réponse générée est retournée.

Cette architecture fonctionne techniquement, mais elle échoue régulièrement dès qu'elle sort du cadre de la démo.

Pourquoi le RAG basique échoue en production

Trois points de rupture reviennent systématiquement :

Comment fiabiliser le RAG : query translation, reranking et auto-correction

Reformuler la question avant de chercher

La query translation consiste à faire réécrire la question par le LLM sous plusieurs angles avant la recherche (technique du multiquery), puis à combiner les résultats de chaque reformulation.

Une variante plus efficace s'appelle HyDE (Hypothetical Document Embedding). Le LLM invente une réponse hypothétique à la question, même fausse. Cette fausse réponse n'est jamais montrée à l'utilisateur : elle sert uniquement de clé de recherche, car sa longueur et son vocabulaire ressemblent davantage à un vrai document qu'à une question de cinq mots. La recherche par similarité cosinus devient alors nettement plus précise.

Reranking avec un cross-encoder

La recherche par embedding est rapide mais grossière : question et document sont vectorisés séparément, sans jamais être lus ensemble. Le reranking corrige ce défaut en deux passes :

1. Recherche par embedding classique : on récupère 50 candidats parmi des millions de documents.
2. Un cross-encoder lit la question et chaque candidat simultanément, mot par mot, et attribue un score de pertinence fin. On ne garde que les 3 à 5 meilleurs.

Cette cascade coûte plus cher en calcul, mais elle réduit fortement le bruit dans le contexte final envoyé au LLM.

Le RAG correctif (Corrective RAG / Self-RAG)

Le RAG correctif, aussi appelé adaptive RAG, transforme la chaîne linéaire en boucle de vérification :

• Les documents récupérés sont-ils pertinents ? Sinon, on reformule la question ou on bascule vers une recherche web.
• La réponse générée est-elle réellement ancrée dans les documents fournis, ou le modèle hallucine-t-il ? Si oui, on régénère.

Cette approche est documentée dans des travaux de recherche largement cités, notamment Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection et Corrective Retrieval Augmented Generation. Elle constitue la base des architectures RAG déployées en production par les équipes qui traitent des volumes réels d'utilisateurs.

RAG vanille contre RAG en production

Pour aller plus loin techniquement, la documentation officielle de Azure AI Search sur la recherche vectorielle et le guide Azure OpenAI On Your Data détaillent les mécanismes d'ingestion, de chunking et de recherche hybride disponibles nativement dans l'écosystème Microsoft.

Points clés à retenir

• Le RAG repose sur trois étapes : indexation (chunking, embedding, stockage vectoriel), récupération (k-NN, similarité cosinus) et génération (prompt augmenté).
• Un seul modèle d'embedding doit être utilisé de bout en bout, pour l'indexation comme pour la recherche.
• Le RAG vanille échoue à trois endroits précis : questions mal formulées, chunks non pertinents, hallucinations du LLM.
• Les correctifs éprouvés sont HyDE/multiquery pour la reformulation, le reranking par cross-encoder pour la précision, et le RAG correctif pour l'auto-vérification.
• Avant tout déploiement en production, testez le comportement du système sur des questions ambigües réelles, pas uniquement sur des questions de démo bien formulées.

Si votre organisation envisage un projet RAG sur Azure, commencez par valider le niveau de service Azure AI Search requis pour la recherche vectorielle, puis mesurez la qualité de récupération avant d'ajouter les couches de reranking et de correction.