En bref

Un LLM sait ce qu’il a appris pendant son entraînement. Passé cette date, il ne sait plus rien de ce qui s’est passé dans le monde — et il n’a jamais rien su de vos documents internes. Le RAG (Retrieval-Augmented Generation) résout ce problème sans modifier le modèle : au lieu de tout mémoriser, le modèle apprend à aller chercher.

Le principe est simple. Quand vous posez une question, un moteur de recherche identifie les passages les plus pertinents dans une base de connaissances externe, puis les glisse directement dans le contexte du modèle avant qu’il génère sa réponse. Le modèle répond en s’appuyant sur ces passages, comme un médecin qui consulte un dossier avant de parler au patient.

Explication

Le problème que RAG résout

Les poids d’un LLM sont figés au moment de l’entraînement. GPT-4 ne connaît pas les actualités d’aujourd’hui. Claude ne connaît pas la documentation interne de votre entreprise. Fine-tuner (ré-entraîner) un modèle sur de nouvelles données coûte cher, prend du temps, et doit être recommencé à chaque mise à jour. Le RAG est une alternative : brancher une mémoire externe sur le modèle au moment de l’inférence.

L’architecture en quatre étapes

1. Les embeddings — transformer le texte en coordonnées

Avant de pouvoir chercher, il faut indexer. Chaque document de la base de connaissances est découpé en morceaux (chunks), puis chaque chunk est converti en un vecteur numérique — un embedding. Cet embedding représente la sémantique du texte : deux phrases qui disent la même chose avec des mots différents auront des vecteurs proches. Ce calcul est fait une seule fois à l’indexation.

2. Le vector store — une bibliothèque de coordonnées

Tous ces vecteurs sont stockés dans une base de données vectorielle (vector store). Contrairement à une base SQL qui cherche des mots exacts, le vector store cherche par proximité géométrique — il trouve les vecteurs les plus “proches” d’une requête donnée.

3. Le retrieval — chercher les passages pertinents

Quand l’utilisateur pose une question, cette question est elle aussi convertie en embedding. Le vector store calcule alors la distance entre ce vecteur-requête et tous les vecteurs stockés (généralement par similarité cosinus), et renvoie les N chunks les plus proches sémantiquement — même si aucun mot exact ne correspond.

4. La génération augmentée — répondre en s’appuyant sur les sources

Les chunks récupérés sont injectés dans le prompt envoyé au LLM, juste avant la question de l’utilisateur. Le modèle dispose maintenant d’un contexte enrichi. Il génère sa réponse en s’appuyant sur ces extraits, et peut citer leur source.

[Question] → [Embedding requête] → [Recherche vectorielle]
                                           ↓
                              [Chunks pertinents récupérés]
                                           ↓
                    [Prompt = question + chunks] → [LLM] → [Réponse sourcée]

Pourquoi c’est utile

Le RAG permet d’utiliser un modèle généraliste sur une base de connaissances propriétaire sans le ré-entraîner. Une entreprise peut brancher son modèle sur sa documentation technique, ses contrats, ses tickets support — et obtenir un assistant qui connaît son contexte sans avoir exposé ses données à un prestataire d’entraînement.

Exemples concrets

Données à jour

Un LLM entraîné en 2024 ne connaît pas les décisions de justice de 2025. Avec RAG, un cabinet d’avocats peut indexer la jurisprudence au fil de l’eau et interroger une base toujours fraîche. Pas de ré-entraînement — juste une mise à jour de la base documentaire.

Réduction des hallucinations

Sans RAG, le modèle génère en puisant dans ses probabilités d’entraînement. Il peut “inventer” une référence plausible mais fausse. Avec RAG, il s’appuie sur des passages concrets fournis en contexte : la réponse est ancrée dans des documents réels. Les hallucinations ne disparaissent pas, mais leur fréquence diminue significativement sur les questions factuelles.

Sources traçables

Chaque assertion du modèle peut être liée au chunk source dont elle provient. L’utilisateur peut vérifier. C’est un avantage majeur dans les contextes où la confiance doit être auditée — médical, juridique, réglementaire.

La limite du chunking

Découper les documents en chunks est une décision critique. Trop petits, les chunks perdent leur contexte : un passage qui n’a de sens que dans le paragraphe précédent devient inutilisable. Trop grands, les chunks consomment une part importante de la fenêtre de contexte du modèle, diluant l’information pertinente dans du bruit. Il n’existe pas de taille universelle — c’est un paramètre à calibrer selon le type de documents et la nature des requêtes.

Une autre limite documentée : même avec les bons documents récupérés, le modèle peut ne pas les utiliser correctement s’ils se trouvent au milieu d’un contexte long. Les recherches de Liu et al. (Stanford, 2024) ont montré que les performances des LLM suivent une courbe en U selon la position de l’information pertinente dans le contexte — l’information en début et en fin est mieux exploitée que l’information centrale.

Le coût caché

Chaque requête RAG implique une recherche vectorielle plus l’injection de N chunks dans le prompt. Cela augmente le nombre de tokens envoyés au modèle à chaque appel — et la facturation suit. Pour les applications à fort volume, le coût du retrieval devient un paramètre d’architecture à part entière.

Ce qu’il faut retenir

  • Le RAG n’entraîne pas le modèle — il lui donne accès à une mémoire externe au moment de l’inférence.
  • Le flux est : indexation (embeddings + vector store) → retrieval (recherche par similarité) → génération augmentée (prompt enrichi).
  • Les avantages principaux : données à jour sans ré-entraînement, réduction des hallucinations, sources citables, coût inférieur au fine-tuning.
  • Les limites principales : qualité du retrieval (garbage in, garbage out), sensibilité au chunking, effet “lost in the middle”, coût par requête.
  • La qualité du modèle d’embeddings et la stratégie de découpage des documents sont aussi importantes que le choix du LLM.

Sources