Recherche et récupération (RAG)

Le principe

Le RAG — Retrieval-Augmented Generation — combine la récupération de documents pertinents avec la génération de texte. Au lieu de compter uniquement sur les connaissances internes de Claude, vous lui fournissez, au moment de la question, les documents qui s’y rapportent. Le modèle cesse alors d’être une source de savoir pour devenir un moteur de raisonnement appliqué à votre matière.

Trois raisons justifient cette bascule. La première tient à la fraîcheur : Claude a une date de coupure dans ses connaissances, et le RAG permet d’injecter des informations récentes sans rien réentraîner. La deuxième est la précision factuelle — en fournissant les documents source, vous mettez le modèle en position de citer et de vérifier ses réponses plutôt que de puiser dans un souvenir approximatif. La troisième concerne les domaines spécialisés : une base de connaissances interne, une documentation technique ou des données propriétaires n’ont jamais figuré dans l’entraînement, et seul le RAG peut les rendre disponibles.

L’enchaînement

1. L'utilisateur pose une question
2. Votre systeme recherche les documents pertinents (base vectorielle, moteur de recherche)
3. Les documents trouves sont injectes dans le prompt
4. Claude repond en se basant sur ces documents

Le point important de ce schéma est que l’étape 2 se passe entièrement hors du modèle. La qualité de la réponse finale se joue donc largement avant que le prompt ne soit écrit.

Une implémentation minimale

# Supposons que vous avez une fonction de recherche
documents = search_knowledge_base(user_query)

# Construisez le prompt avec les documents
prompt = f"""Réponds a la question en te basant uniquement sur les documents fournis.
Si les documents ne contiennent pas la réponse, dis-le.

<documents>
{documents}
</documents>

<question>
{user_query}
</question>"""

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=2000,
    messages=[{"role": "user", "content": prompt}]
)

Vous reconnaissez ici toute la grammaire des leçons précédentes : une consigne explicite, deux blocs délimités en XML, une porte de sortie en cas d’absence d’information. Le RAG n’introduit aucune technique de prompting nouvelle ; il applique celles que vous maîtrisez à un contexte alimenté dynamiquement.

Les réglages qui font la différence

Séparez les documents avec des balises XML individuelles — <doc1>, <doc2> — plutôt qu’en les concaténant : Claude peut alors indiquer d’où vient chaque élément de réponse. Placez la question après les documents, ce qui donne de meilleurs résultats sur les longs contextes, l’instruction restant fraîche au moment de conclure. Demandez des citations en forçant l’extraction de passages avant la réponse, exactement comme dans la leçon sur les hallucinations. Prévoyez le cas où rien ne correspond, en donnant explicitement la permission de dire que l’information n’a pas été trouvée. Et limitez le nombre de documents injectés, car trop de contexte dilue la pertinence au lieu de l’augmenter.

Ce qu’il y a sous le capot

Un système RAG complet suppose une chaîne de traitement en amont :

1. Découper vos documents en morceaux (chunks)
2. Générer des embeddings pour chaque morceau
3. Stocker les embeddings dans une base vectorielle
4. Rechercher les morceaux les plus similaires à la question
5. Injecter les résultats dans le prompt

Les embeddings sont des représentations numériques du sens d’un texte : deux textes proches sémantiquement auront des embeddings proches. C’est ce qui permet de retrouver un passage parlant de « résiliation anticipée » à partir d’une question sur « comment arrêter mon contrat avant la fin », là où une recherche par mots-clés serait passée à côté.

Les limites à connaître

La qualité du RAG dépend entièrement de la qualité de la recherche en amont : un modèle excellent ne rattrape pas un mauvais résultat de recherche, il rédige simplement une mauvaise réponse avec élégance. Des documents hors sujet ou trop nombreux dégradent les résultats, comme nous l’avons vu avec les informations distractrices. Et le coût en tokens augmente mécaniquement avec la quantité de documents injectés, ce qui fait de la sélection un sujet économique autant que technique. C’est sur ce compromis — chercher mieux plutôt que fournir plus — que se joue la réussite d’un projet RAG.

Testez vos connaissances

Le tour des techniques est complet — vérifiez qu’elles sont prêtes à l’emploi.

1. Pourquoi attribuer un rôle à Claude change-t-il ses réponses ?

Réponse : Le rôle condense des centaines de consignes implicites : ton, niveau, priorités — « tu es un relecteur juridique » cadre mieux qu’une liste de règles éparses.

2. À quoi servent les balises XML dans un prompt ?

Réponse : À séparer sans ambiguïté les instructions des données : Claude ne confond plus consignes et contenu à traiter — indispensable dès qu’on interpole du texte externe.

3. Que gagne-t-on à « laisser Claude réfléchir étape par étape » ?

Réponse : Sur les tâches de raisonnement, dérouler les étapes avant la conclusion réduit nettement les erreurs — on demande le raisonnement d’abord, la réponse ensuite.

4. Quand le few-shot prompting est-il le plus rentable ?

Réponse : Sur les cas subtils (ton, sarcasme, formats complexes) : un exemple montre ce qu’une consigne peine à décrire — les cas faciles réussissent de toute façon.

5. Citez deux techniques pour réduire les hallucinations.

Réponse : Autoriser explicitement « je ne sais pas » (laisser une sortie honnête), et exiger des citations ou extraits du document source avant la réponse — la réponse doit s’ancrer dans des preuves.

Ces techniques se combinent : les prompts complexes du cours les assemblent toutes. Prochaine étape naturelle : les évaluations, pour mesurer ce que chaque technique rapporte.