Le RAG
n'est pas magique.
C'est une architecture.

Le RAG est souvent présenté comme une solution presque magique : on met ses documents dans une base, on pose une question, et le modèle répond avec la bonne information. Dans la réalité, c'est beaucoup plus intéressant que ça. Et aussi beaucoup plus exigeant.

Le RAG, pour Retrieval-Augmented Generation, consiste à donner au modèle des informations externes au moment où il répond. Le papier fondateur de 2020 posait déjà cette idée : combiner la mémoire interne du modèle avec une mémoire externe récupérée dynamiquement.

Mais en production, la valeur ne vient pas du mot RAG. Elle vient de l'architecture complète autour : comment les documents sont ingérés, découpés, indexés, retrouvés, filtrés, classés, injectés dans le contexte, puis évalués.

Le RAG répond à deux limites très concrètes

Un grand modèle a deux limites importantes. Première limite : sa fenêtre de contexte n'est pas infinie. On ne peut pas lui donner toute la documentation d'une entreprise à chaque question. Deuxième limite : sa connaissance interne est figée à un moment donné, alors que les documents, les prix, les politiques internes et les pratiques évoluent.

Le RAG résout partiellement ce problème en ajoutant une étape de recherche avant ou pendant la génération. Au lieu de demander au modèle de tout savoir, on lui apporte les informations pertinentes au moment de répondre.

C'est très puissant. Mais il faut garder une phrase en tête : un mauvais retrieval donne un mauvais contexte, et un mauvais contexte donne une mauvaise réponse.

Le pipeline complet d'un RAG sérieux

1. Ingestion : nettoyer avant de vectoriser

La première erreur consiste à mettre directement des PDF, des pages web ou des exports Notion dans une base vectorielle. Avant ça, il faut nettoyer, convertir, structurer, enlever les doublons, garder les métadonnées utiles et tracer la source.

Exemple concret : pour une base documentaire interne, il faut savoir si une procédure vient d'un document validé, d'une page ancienne ou d'une note brouillon. Sans métadonnées, l'agent ne peut pas savoir quelle source mérite confiance.

2. Chunking : découper sans casser le sens

Le chunking consiste à découper les documents en morceaux retrouvables. Trop gros, les chunks ramènent trop de bruit. Trop petits, ils perdent le contexte. Le bon découpage dépend du contenu : FAQ, contrat, documentation technique, compte rendu, politique interne.

3. Embeddings : créer une carte sémantique

Les embeddings transforment les textes en vecteurs. Deux passages proches en sens doivent être proches dans cet espace. C'est utile, mais ce n'est pas suffisant. Une recherche sémantique peut rater des termes exacts importants, notamment des codes, des noms de produit ou des références métier.

4. Hybrid search : combiner sens et mots clés

En pratique, j'aime beaucoup les architectures hybrides : recherche vectorielle pour le sens, recherche lexicale pour les termes précis. Cela évite de dépendre d'un seul mode de recherche.

5. Reranking : reclasser avant d'injecter

Le premier retrieval n'est pas toujours le bon. Le reranking sert à reprendre les candidats et les reclasser avec un modèle ou une logique plus fine. C'est souvent là que l'on gagne en qualité, parce qu'on évite d'envoyer au modèle des passages proches mais inutiles.

6. Freshness : gérer la fraîcheur des données

Un RAG peut être faux parce qu'il récupère une information périmée. Il faut donc penser dates, versions, politique de remplacement, suppression, priorité des sources et réindexation.

Pourquoi beaucoup de RAG déçoivent

Beaucoup de projets RAG déçoivent parce qu'ils sont pensés comme une feature, pas comme une chaîne de production. On ajoute une base vectorielle, on branche un modèle, et on découvre ensuite que les réponses sont parfois floues, contradictoires ou impossibles à auditer.

Les causes sont souvent les mêmes : documents mal nettoyés, chunks incohérents, métadonnées absentes, recherche trop naïve, absence de reranking, sources périmées, pas de mesure de qualité.

De plus, le RAG ne supprime pas automatiquement l'hallucination. Il réduit le risque si le bon contexte est récupéré et si la réponse est forcée à rester fidèle aux sources. Mais sans vérification, le modèle peut encore mélanger, extrapoler ou combler les trous.

Un RAG se pilote avec des métriques

La vraie différence entre une démo RAG et un RAG de production, c'est l'évaluation. Il faut construire un petit dataset de questions réelles, avec les sources attendues et les réponses acceptables. Ensuite seulement, on peut mesurer.

• Context precision : les passages récupérés sont-ils réellement utiles ?
• Context recall : les passages nécessaires ont-ils été récupérés ?
• Faithfulness : la réponse respecte-t-elle les sources ?
• Answer relevance : la réponse répond-elle vraiment à la question ?
• Freshness : l'information utilisée est-elle à jour ?

Mon objectif ici est de rendre le sujet très concret : le RAG n'est pas une baguette magique. C'est une architecture de recherche, de contexte et de vérification. Quand elle est bien pensée, elle peut apporter énormément de valeur. Quand elle est bricolée, elle donne simplement une illusion de connaissance.