Contextual Retrieval : La Technique RAG Avancée qui Réduit

Le Problème du RAG Classique

Pour comprendre pourquoi le Contextual Retrieval est nécessaire, rappelons le fonctionnement du RAG standard. Si vous débutez avec le RAG, consultez d'abord notre guide sur les fondamentaux du RAG.

Le pipeline RAG classique :

1. →Découper la base de connaissances en chunks (~quelques centaines de tokens)
2. →Encoder les chunks en vecteurs (embeddings)
3. →Stocker dans une base vectorielle
4. →À la requête : trouver les chunks similaires → les ajouter au prompt

Le problème : Chaque chunk est encodé isolément. Un chunk qui dit « Le revenu a augmenté de 3% » perd l'information sur quelle entreprise, quel document, quelle période.

Ce sur quoi l'annonce Anthropic du Contextual Retrieval est honnête, et ce que les praticiens sur r/MachineLearning et r/LocalLLaMA confirment régulièrement : le RAG naïf est surtout un problème de ranking déguisé en problème de retrieval. La qualité des embeddings est généralement correcte. Ce qui échoue, c'est que les 5 meilleurs chunks par similarité cosinus ne forment pas une réponse cohérente, parce que chaque chunk a été encodé comme s'il n'avait pas de voisins. Ajouter un préfixe de contexte court avant l'embedding est peu coûteux, et la réduction annoncée de ~49 % des échecs de retrieval (avec reranking) est cohérente avec ce que les équipes reproduisent en production.

Là où la communauté nuance à juste titre : ce n'est pas magique. Les préfixes contextuels ajoutent des tokens au coût d'indexation, ils nécessitent le prompt caching pour être économiquement viables à l'échelle d'un vrai corpus, et ils ne rattrapent pas un mauvais chunking. Si vos chunks sont de mauvaise longueur ou découpent des frontières sémantiques (un tableau coupé en deux, un corps de fonction séparé de sa signature), les embeddings contextuels ne font que récupérer du non-sens bien décrit.

Séquençage pragmatique : bien chunker d'abord (découpes sémantiques, respect de la structure markdown/code), ajouter BM25 en retrieveur parallèle, mesurer une baseline avec un eval set tenu à l'écart, puis empiler embeddings contextuels et reranking. Les équipes qui sautent directement au Contextual Retrieval sans harnais de mesure concluent souvent qu'il « n'aide pas » — alors que la vérité, c'est qu'elles n'ont aucun moyen de le savoir.

BM25 : Le Complément Indispensable aux Embeddings

Avant d'aborder le Contextual Retrieval, il faut comprendre BM25 (Best Matching 25), un algorithme de ranking textuel basé sur la correspondance lexicale.

La clé : Combiner embeeddings ET BM25 via rank fusion donne de meilleurs résultats que chacun isolément.

La Solution : Contextual Retrieval

L'idée est simple mais puissante : ajouter un contexte explicatif à chaque chunk AVANT de l'encoder.

Avant vs Après

# ❌ Chunk classique (sans contexte)
"The company's revenue grew by 3% over the previous quarter."

# ✅ Chunk contextualisé
"This chunk is from an SEC filing on ACME Corp's performance 
in Q2 2023; the previous quarter's revenue was $314 million. 
The company's revenue grew by 3% over the previous quarter."

Le Prompt de Contextualisation

Pour chaque chunk, Claude génère un contexte de 50-100 tokens :

<document>
{{WHOLE_DOCUMENT}}
</document>

Here is the chunk we want to situate within the whole document:
<chunk>
{{CHUNK_CONTENT}}
</chunk>

Please give a short succinct context to situate this chunk 
within the overall document for the purposes of improving 
search retrieval of the chunk. Answer only with the succinct 
context and nothing else.

Résultat : Le contexte généré est concaténé au début du chunk, puis le tout est encodé (embedding ET BM25).

Implémentation avec Prompt Caching

Le coût de contextualiser chaque chunk avec le document complet pourrait être prohibitif. La solution : le prompt caching.

Comment ça marche :

1. →Charger le document complet en cache (coût unique)
2. →Pour chaque chunk, envoyer seulement le chunk + le prompt de contextualisation
3. →Le document en cache est réutilisé automatiquement

Coût : ~1,02$ par million de tokens de documents (coût unique lors de l'indexation).

Pour en savoir plus sur le prompt caching, consultez notre guide dédié au prompt caching Claude.

import anthropic

client = anthropic.Anthropic()

def contextualize_chunks(document: str, chunks: list[str]) -> list[str]:
    """Ajoute un contexte à chaque chunk via Claude avec prompt caching."""
    contextualized = []
    
    for chunk in chunks:
        response = client.messages.create(
            model="claude-sonnet-4-5-20250514",
            max_tokens=200,
            messages=[{
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": f"<document>\n{document}\n</document>",
                        "cache_control": {"type": "ephemeral"}
                    },
                    {
                        "type": "text",
                        "text": (
                            f"<chunk>\n{chunk}\n</chunk>\n\n"
                            "Give a short succinct context to situate "
                            "this chunk within the overall document for "
                            "improving search retrieval. "
                            "Answer only with the succinct context."
                        )
                    }
                ]
            }]
        )
        
        context = response.content[0].text
        contextualized.append(f"{context}\n\n{chunk}")
    
    return contextualized

Pipeline Complet : Contextual Embeddings + Contextual BM25 + Reranking

Le pipeline optimal combine les trois techniques :

Résultats de Performance

Le Reranking Expliqué

Le reranking est un post-traitement qui réévalue la pertinence des chunks :

1. →Retrieval initial : Top 150 chunks (embeddings + BM25)
2. →Reranking : Un modèle spécialisé score chaque chunk par rapport à la requête
3. →Sélection : Top 20 chunks les plus pertinents
4. →Génération : Le LLM utilise ces 20 chunks pour répondre

Pourquoi top-20 plutôt que top-10 ou top-5 ? Les benchmarks montrent que top-20 donne systématiquement de meilleurs résultats que des fenêtres plus petites, car le LLM a plus de contexte pour synthétiser sa réponse.

Findings Clés et Recommandations

1. →Embeddings + BM25 > Embeddings seuls, Toujours combiner les deux via rank fusion
2. →Top-20 chunks > Top-10 ou Top-5, Plus de contexte = meilleures réponses
3. →Le contexte ajouté aux chunks améliore significativement la précision, C'est le cœur du Contextual Retrieval
4. →Le reranking > Pas de reranking, L'étape finale qui maximise la précision
5. →Tous les gains se cumulent, Contextual Embeddings + Contextual BM25 + Reranking + Top-20

Comparaison avec le RAG Avancé : Lost in the Middle

Le Contextual Retrieval et le problème « Lost in the Middle » sont deux facettes différentes de l'optimisation RAG :

• →Contextual Retrieval résout le problème de la perte de contexte lors de l'encodage (côté retrieval)
• →Lost in the Middle résout le problème de la perte d'attention au milieu de longs contextes (côté génération)

Pour une analyse complète du phénomène Lost in the Middle, consultez notre guide RAG avancé.

Pour Aller Plus Loin

• →Fondamentaux du RAG et Context Engineering, Les bases avant le Contextual Retrieval
• →RAG Avancé : Lost in the Middle, L'autre défi du RAG
• →Prompt Caching Claude, Indispensable pour réduire les coûts de contextualisation
• →Context Engineering : Les 4 Piliers, Vision globale de la gestion du contexte
• →Les 5 Patterns d'Architecture d'Agents, Intégrer le RAG dans des systèmes agentiques