Le RAG expliqué aux développeurs

Un grand modèle de langage ne connaît que ce qu’il a vu à l’entraînement. Il ignore votre documentation interne, vos derniers tickets, vos fiches produit. Pire, quand on l’interroge sur ce qu’il ne sait pas, il peut inventer une réponse plausible mais fausse. Le RAG — Retrieval-Augmented Generation — est la technique de référence pour corriger cela : on va chercher les bonnes informations avant de générer la réponse. Voici comment ça marche, du point de vue d’un développeur qui doit l’implémenter.

L’idée fondamentale

Le principe du RAG tient en une phrase : au lieu de demander au modèle de répondre de mémoire, on lui fournit les documents pertinents dans le prompt, et on lui demande de répondre en s’appuyant dessus.

Le déroulé est le suivant : l’utilisateur pose une question, un système de recherche retrouve les passages de vos données les plus liés à cette question, ces passages sont injectés dans le contexte du modèle, et le modèle rédige une réponse ancrée dans ces sources. On combine ainsi la fluidité du LLM avec la fraîcheur et la fiabilité de vos données maison.

Les briques d’un pipeline RAG

Les embeddings

Tout repose sur les embeddings : la transformation d’un texte en un vecteur de nombres qui capture son sens. Deux textes proches sémantiquement — « comment réinitialiser mon mot de passe » et « procédure de récupération de compte » — produisent des vecteurs proches, même sans mots en commun. C’est ce qui permet une recherche par sens, et non par simple correspondance de mots-clés.

La base vectorielle

Ces vecteurs sont stockés dans une base vectorielle, optimisée pour une opération précise : trouver rapidement, parmi des millions de vecteurs, ceux les plus proches d’un vecteur de requête. Plusieurs solutions existent (bases dédiées ou extensions de bases classiques). Toutes répondent à la même question : « quels sont les k passages les plus similaires à cette requête ? »

Le chunking

On n’indexe pas des documents entiers : on les découpe en chunks, des morceaux de taille raisonnable (un paragraphe, une section). Le chunking est une étape sous-estimée mais décisive :

Trop gros : le chunk dilue l’information pertinente dans du bruit et gaspille le contexte.
Trop petit : le passage perd son sens, coupé de ce qui l’entoure.
Chevauchement : faire déborder légèrement les chunks les uns sur les autres évite de couper une idée en plein milieu.

Un bon découpage suit la structure logique du document (titres, sections) plutôt qu’un comptage aveugle de caractères.

Le pipeline de bout en bout

Un système RAG se construit en deux temps : l’indexation (une fois, ou à chaque mise à jour des données) et la requête (à chaque question).

Phase d’indexation

# Pseudo-code illustratif — phase d'indexation
for document in corpus:
    chunks = decouper(document, taille=500, chevauchement=50)
    for chunk in chunks:
        vecteur = modele_embedding.encoder(chunk)
        base_vectorielle.ajouter(vecteur, texte=chunk, source=document.id)

Phase de requête

# Pseudo-code illustratif — phase de requête
def repondre(question):
    v_question = modele_embedding.encoder(question)
    passages = base_vectorielle.rechercher(v_question, k=5)
    contexte = "\n\n".join(p.texte for p in passages)
    prompt = f"""Réponds à la question en te basant uniquement
sur le contexte ci-dessous. Si l'information n'y est pas, dis-le.

Contexte :
{contexte}

Question : {question}"""
    return modele_llm.generer(prompt)

Deux détails font toute la différence en pratique. D’abord, l’instruction « réponds uniquement à partir du contexte » réduit fortement les inventions. Ensuite, citer les sources (renvoyer les source des passages utilisés) rend la réponse vérifiable — un atout majeur en entreprise.

Quand utiliser le RAG (et quand s’en passer)

Le RAG n’est pas la réponse à tout. Il brille dans des cas précis.

Utilisez le RAG quand :

vos données sont volumineuses, changeantes ou privées (documentation, base de connaissances, catalogue) ;
vous avez besoin de réponses traçables, avec sources citées ;
le coût ou la lenteur d’un réentraînement du modèle seraient prohibitifs.

Le RAG est moins pertinent quand :

la connaissance nécessaire tient déjà dans le modèle ou dans un prompt court — inutile de monter une infrastructure de recherche ;
la tâche relève du raisonnement pur ou du style, pas de la récupération de faits ;
vos données évoluent à chaque seconde et un simple appel d’API en temps réel suffirait.

Il faut aussi le distinguer d’approches voisines. Le fine-tuning apprend au modèle un comportement ou un style, mais ne lui donne pas de faits frais et vérifiables — le RAG, si. Et lorsque la question exige d’agir (interroger une base en direct, appeler un service), on entre dans le domaine des agents et des outils : notre guide sur le Model Context Protocol montre comment un modèle se connecte à ce type de capacités.

Un socle simple, une exécution soignée

La force du RAG est aussi son piège : le schéma de base se code en une après-midi, mais la qualité se joue dans les détails — stratégie de chunking, choix du modèle d’embedding, nombre de passages récupérés, formulation du prompt, filtrage des sources. Commencez simple, mesurez la pertinence des réponses sur des questions réelles, puis affinez brique par brique. C’est cette itération, plus que la sophistication initiale, qui sépare un prototype d’un système utile.