Introduction au RAG

Nouvelle section, nouveau défi : les grands documents. La génération augmentée par la recherche (RAG, Retrieval Augmented Generation) consiste à découper les documents en morceaux et à ne fournir à Claude que les morceaux utiles à chaque question. Avant de la construire pièce par pièce, posons le problème qu’elle résout.

Le problème des grands documents

Vous avez un rapport financier de 800 pages et vous voulez demander : « Quels facteurs de risque l’entreprise mentionne-t-elle ? » Le document contient la réponse ; encore faut-il la mettre sous les yeux de Claude.

Option 1 : tout mettre dans le prompt

C’est l’approche directe : extraire tout le texte et l’envoyer d’un bloc. Aucune infrastructure, mais des limites. Les modèles actuels ont une grande fenêtre, un million de tokens pour Haiku 5.5 sur Bedrock, et une requête Bedrock ne peut pas dépasser 20 Mo ; un très gros corpus finit toujours par déborder. Surtout, le coût et l’attente se répètent à chaque question : on renvoie 800 pages pour un chiffre qui tient en deux paragraphes. Et la qualité peut baisser quand le modèle doit trier beaucoup d’informations sans rapport avec la question.

Option 2 : découper et ne garder que l’utile

Le RAG prétraite le document une fois, puis ne récupère que les morceaux pertinents :

1. découper le document en morceaux, par exemple « Stratégie », « Facteurs de risque », « Bilan » ;
2. quand une question arrive, chercher ce qu’elle vise ;
3. trouver les morceaux les plus pertinents ;
4. ne mettre que ces morceaux dans le prompt.

Pour la question sur les risques, le système retrouve le morceau « Facteurs de risque » : Claude reçoit un contexte ciblé au lieu du rapport entier.

Ce que le RAG apporte

• Claude se concentre sur le contenu pertinent.
• L’approche passe à l’échelle : de très grands documents, des collections entières.
• Les prompts plus courts coûtent moins cher et répondent plus vite, à chaque question.

Ce qu’il coûte

Le RAG ajoute de la complexité. Il faut un prétraitement pour découper les documents, et un mécanisme de recherche pour retrouver les bons morceaux : si la recherche rate le passage clé, Claude répondra sans lui. Un morceau isolé peut aussi perdre le contexte qui lui donnait son sens. Et il existe de nombreuses façons de découper un texte, chacune avec ses compromis. Les leçons de la section affrontent ces défis un par un.

Quand l’utiliser

Le RAG brille avec de grands documents ou des collections, quand les questions ne visent qu’une partie du contenu. Sa complexité se justifie quand le contenu ne tient plus confortablement dans un prompt, quand la latence compte, ou quand les coûts s’accumulent sur de nombreuses questions. Pour un document de dix pages interrogé deux fois, joignez simplement le document. Entre les deux, la mise en cache des prompts (section 6) réduit le coût d’un même long document renvoyé à chaque question.

À vous de jouer

RAG ou pas ? Pour trois cas de votre travail (un contrat de 20 pages, une base de 2 000 fiches produit, la documentation interne d’une équipe), estimez la taille du contenu et le nombre de questions par jour. Pour chacun, choisissez : tout dans le prompt, prompt avec cache, ou RAG, et justifiez en une phrase.

Sources officielles : Introducing Retrieval Augmented Generation (Claude Academy) · Claude on Amazon Bedrock (Opus 4.6 and earlier) (documentation Claude : fenêtre de contexte et limite de 20 Mo)

Points clés à retenir

• Le RAG ne fournit à Claude que les morceaux utiles, au lieu du document entier à chaque question.
• Tout envoyer finit par buter sur la taille, et répète le coût et l’attente à chaque question.
• Le pipeline : découper une fois, puis chercher et envoyer un prompt court à chaque question.
• Contreparties : un prétraitement, une qualité qui dépend de la recherche, un contexte parfois amputé.
• Le RAG se justifie à l’échelle ; pour un petit document, joignez-le, éventuellement avec le cache.