Introduction au RAG

Nouvelle section, nouveau problème : les gros documents. Imaginez devoir répondre à des questions sur un rapport financier de 800 pages — le genre de corpus qu’aucun prompt ne peut avaler confortablement. Le RAG (Retrieval Augmented Generation, génération augmentée par récupération) est la technique de référence pour ce cas : plutôt que d’injecter le document entier dans chaque requête, il trouve et inclut uniquement les sections les plus pertinentes pour chaque question. Avant de le construire, comparons honnêtement les deux options.

Option 1 : tout mettre dans le prompt

L’approche naïve consiste à extraire tout le texte du document et à l’injecter directement dans le prompt, question à la suite. Elle a le mérite de la simplicité — aucune infrastructure, aucun préprocessing — et elle bute sur trois murs. D’abord une limite dure : la fenêtre de contexte plafonne la quantité de texte que Claude peut traiter, et un très gros corpus ne rentre tout simplement pas. Ensuite une dégradation douce : même quand tout rentre, un modèle noyé sous des centaines de pages exploite moins bien chaque passage — l’information pertinente se dilue dans la masse. Enfin l’économie : chaque question refacture l’intégralité du document en tokens d’entrée, et les prompts géants sont aussi les plus lents. Payer 800 pages de traitement pour répondre à une question dont la réponse tient dans deux paragraphes, c’est le rapport coût/utilité le plus défavorable qui soit.

Option 2 : découper en segments (c’est le RAG)

L’alternative renverse la logique : découper le document en segments lors d’une étape de preprocessing, puis, à chaque question de l’utilisateur, rechercher les segments pertinents et n’inclure qu’eux dans le prompt. Claude reçoit alors un prompt court, concentré sur le contenu qui compte.

Les bénéfices découlent directement de cette concentration. Le modèle travaille sur l’essentiel au lieu de trier des centaines de pages, ce qui améliore la qualité des réponses. L’approche passe à l’échelle — que le corpus fasse 800 ou 80 000 pages, le prompt garde la même taille — et s’étend naturellement à plusieurs documents interrogés d’un coup. Et les prompts réduits se paient moins cher et se traitent plus vite, à chaque question.

Le prix à payer est une complexité nouvelle, qu’il faut regarder en face. Le RAG exige une étape de preprocessing — découper, indexer — avant la première question. Il lui faut un mécanisme de recherche capable de retrouver les bons segments, et c’est une pièce d’ingénierie à part entière : si la recherche rate le passage utile, Claude répondra sans lui. Les segments extraits peuvent aussi manquer de contexte — une phrase isolée de sa section peut devenir ambiguë. Enfin, il existe plusieurs stratégies de découpage, et le choix influe directement sur la qualité de la recherche. Toute la section qui s’ouvre traite précisément ces difficultés une à une.

Composants clés du RAG

Le programme de construction découle de ce diagnostic :

1. Preprocessing et découpage de documents
2. Mécanisme de recherche pour trouver les segments pertinents
3. Sélection intelligente des segments à inclure dans les prompts

Les prochaines leçons suivent cet ordre : d’abord les stratégies de découpage, puis les embeddings et la recherche sémantique, enfin l’assemblage du pipeline complet — jusqu’à un système capable de répondre, preuves à l’appui, sur des documents entiers.

Points clés à retenir

• Le RAG répond au problème des gros documents : n’injecter que les sections pertinentes pour chaque question
• Tout mettre dans le prompt bute sur la fenêtre de contexte, dilue l’attention du modèle et refacture le corpus à chaque question
• Le RAG concentre le prompt : meilleures réponses, passage à l’échelle, coûts et latence réduits
• En contrepartie : preprocessing obligatoire, qualité dépendante de la recherche, segments parfois décontextualisés
• Trois chantiers à venir : découpage, recherche, sélection des segments