Aller au contenu
Chapitre 03 · 13 min

La récupération bien faite

La génération augmentée par récupération (RAG) est le patron le plus utile et le moins risqué de l'IA appliquée — et celui qui est le plus souvent mal construit. La version naïve impressionne en démo et échoue en production pour une poignée de raisons prévisibles. Ce chapitre présente ces raisons et leurs correctifs.

“N'obligez pas le modèle à mémoriser la bibliothèque. Donnez-lui les trois pages dont il a besoin, ouvertes au bon paragraphe.”

Ce qu'est réellement le RAG

Le RAG sépare ce que le système sait de ce qu'il dit. La connaissance vit dans un index que vous contrôlez et pouvez mettre à jour toutes les heures. Le modèle ne fournit que le langage et le raisonnement sur ce que vous mettez devant lui. Quand une question arrive, vous cherchez dans l'index, récupérez les passages les plus pertinents, et les placez dans le prompt comme contexte.

RAG — retrieval-augmented generation pipelineA pipeline from left to right: a user query is sent to a search system, which finds the most relevant chunks from a document store. Those chunks are added to the prompt and sent to the LLM, which produces an answer grounded in the retrieved context.userquerysearchvector + BM25top chunksfrom your docspromptquery + contextLLManswerINDEXthe model answers from context, not from memory
Le modèle répond à partir des segments récupérés, pas de ses données d'entraînement. Vous mettez à jour l'index, jamais le modèle.

C'est la bonne réponse à presque tous les problèmes de « dialoguez avec nos docs », « assistant de support » ou « base de connaissance interne ». C'est moins coûteux que l'ajustement fin, actualisable en temps réel, et — ce qui est crucial — auditable : vous pouvez montrer exactement de quelle source vient la réponse.

Le pipeline naïf, et pourquoi il casse

La version démo : découpez chaque document en segments de 500 jetons, plongez chacun, stockez dans une base de données vectorielle, plongez la requête, prenez les cinq segments les plus proches, farcissez-les dans le prompt. Ça fonctionne sur une FAQ bien rangée et s'effondre sur de vrais ensembles de documents. Voici où :

  • Mauvais découpage — la réponse est répartie sur deux segments, et ni l'un ni l'autre n'est suffisant seul.
  • Récupération ratée — le passage pertinent ne figure pas dans les premiers résultats parce que la requête et le document utilisent des mots différents.
  • Mauvais modèle de plongement — votre domaine (juridique, médical, jargon interne) n'est pas bien représenté, donc les vecteurs « similaires » ne le sont pas vraiment.
  • Contexte ignoré — le modèle dispose du bon passage mais répond quand même à partir de ses données d'entraînement.
  • Index périmé — le document a changé ; l'index n'a pas suivi.

Le patron qui fonctionne : hybride + re-classement + citations

Trois ajouts corrigent la plupart des RAG en production. Premièrement, la recherche hybride : combinez la similarité vectorielle avec la recherche par mots-clés à l'ancienne (BM25). La recherche vectorielle capture le sens ; la recherche par mots-clés capture les termes exacts (codes d'erreur, noms, références) que les vecteurs atténuent. Exécutez les deux et fusionnez les résultats.

Deuxièmement, le re-classement. Récupérez large — cinquante candidats — puis notez-les avec un re-classeur plus précis (et plus coûteux), et gardez seulement les cinq meilleurs pour le prompt. Vous obtenez le rappel d'une recherche large avec la précision d'une recherche minutieuse.

Retrieve wide, then re-rank to a fewThree shrinking boxes from left to right: retrieve a wide net of 50 candidates, re-rank them with a more precise model, then keep only the top 5 to put in the prompt. Recall first, precision second.retrieve widetop 50re-rankcross-encoderkeep besttop 5
Lancez un filet large pour le rappel, puis re-classez pour la précision. Le modèle ne voit que les quelques passages les plus susceptibles de contenir la réponse.

Troisièmement, les citations. Demandez au modèle de citer l'identifiant du segment utilisé pour chaque affirmation. Cela rend la réponse auditable, vous permet d'afficher les sources dans l'interface, et — de façon mesurable — réduit la dérive du modèle par rapport au texte récupéré.

Quand la récupération est le mauvais outil

Le RAG répond aux questions dont la réponse est écrite quelque part. Il n'aide pas pour les questions qui demandent un raisonnement sur l'ensemble du corpus (« quels sont les trois grands thèmes de ces 10 000 billets ? »), ni pour le calcul (« quel est notre temps de résolution moyen ? »). Celles-là demandent de l'agrégation, de l'analytique ou des outils — couverts au prochain chapitre — pas de la récupération.

Retrieval versus reasoningA 2-by-2 quadrant. The horizontal axis goes from retrieval-heavy to reasoning-heavy. The vertical axis goes from easy to hard. Tasks like "name a capital" and "summarise this article" sit in the easy retrieval corner; long-horizon planning sits in the hard reasoning corner.HARD ↑EASY← RETRIEVALREASONING →name a capitalsummarise this articlesolve this puzzlelong-horizon planwrite a function
La récupération brille sur « trouvez le passage qui répond à ceci ». Elle peine dès que la tâche se déplace vers le raisonnement sur tout à la fois.

En une ligne chacun

  • Le RAG sépare ce que le système sait (l'index) de ce qu'il dit (le modèle). Mettez à jour l'index, pas le modèle.
  • Le RAG naïf casse sur le découpage, les récupérations ratées, les mauvais plongements, le contexte ignoré et les données périmées — tout ça est invisible sans évaluations.
  • Le patron qui fonctionne : recherche hybride + re-classement + citations.
  • Le RAG répond à « trouvez le passage », pas à « raisonnez sur tout » ou « calculez un nombre » — ceux-là ont besoin d'outils.

Où aller ensuite