Accueil / Articles

Le récupération contextuelle pour RAG : ce que cache le chiffre de 67 %, son coût et les moments où il échoue.

La récupération contextuelle pour RAG : comment l’insertion de préfixes corrige les fragments orphelins, pourquoi le chiffre de 67 % reflète trois modifications, ce que l’affichage en mémoire économise, et quand cela échoue.

Éditeur : REACTAPP.TOP13 min de lecture2903 mots

Sources: Your RAG Chunk Doesn’t Know Whose Revenue Grew 3% — Contextual Retrieval

« Le chiffre d’affaires de l’entreprise a augmenté de 3 % par rapport au trimestre précédent. » Une base de données vectorielle peut contenir des milliers de phrases comme celle-ci, et chacune d’elles est fonctionnellement inutile tant qu’il n’est pas clair de quelle entreprise il s’agit et de quel trimestre.

La faute ne réside pas dans le modèle qui écrit la réponse finale. Elle réside dans un fragment qui a été intégré à l’index sans identité. Tout pipeline RAG construit à partir de dossiers, de contrats, de documentation technique ou de code source est vulnérable, car ces corpus reproduisent le même schéma linguistique en de nombreux endroits, ne laissant au système de récupération aucun moyen de distinguer ces répétitions.

Le traitement est peu coûteux. Son prix est exprimé en dollars par million de tokens, et il suffit d’une seule phrase générée, écrite une seule fois lors de la création de l’index. Lors des tests d’Anthropic, un tel préfixe a réduit les récupérations infructueuses de jusqu’à 67 %. Ce chiffre affiché cache une certaine structure, et le cas d’usage choisi pour le mettre en évidence a depuis donné lieu à un contre-exemple. Il existe également quatre paramètres pour lesquels il est difficile de justifier les dépenses.

L’idée principale en bref

Lorsqu’un index divise les documents en blocs de quelques centaines de tokens, certains blocs perdent leur sujet et leur période temporelle. L’expression « Les revenus ont augmenté de 3 % » ne mentionne ni l’entreprise ni le trimestre, et aucun modèle d’incorporation ne peut restituer cette information, car elle n’est pas présente dans le texte.

La récupération contextuelle résout le problème une seule fois, au moment de l’indexation. Un modèle de langage reçoit le document complet ainsi qu’un fragment, et il écrit un court préfixe descriptif de cinquante à cent tokens indiquant de quoi traite ce fragment, à qui il s’adresse et quand.

Une deuxième étape, qui est pourtant importante, est souvent omise dans de nombreux résumés. Le texte enrichi est ensuite alimenté dans l’index vectoriel ainsi que dans l’index BM25, un classeur lexical qui précède les embeddings et compare des mots exacts plutôt que leur signification. Une seule intervention corrige donc les deux composantes de la pile de recherche, au coût d’une indexation unique et non à chaque requête.

Dans l’évaluation d’Anthropic, le seul préfixe d’embedding a permis de réduire de 35 % les récupérations infructueuses. L’ensemble du système, avec BM25 et le reclassement, a permis une réduction de 67 %. Le cache des prompts permet de maintenir ces coûts faibles, car le document entier est lu une seule fois et non à partir de zéro pour chaque fragment.

La technique n’est pas universelle, et c’est là que cela devient intéressant. D’abord, le mécanisme et le prompt lui-même.

Un préfixe qui donne son identité à un chunk

L’intuition précède la mécanique. Un chunk extrait d’un document est comme une page arrachée d’un classeur, sans en-tête, sans numéro de dossier ni date. Lue isolément, elle empêcherait quiconque de savoir quelle entreprise a vu ses revenus augmenter, ou quand. Un modèle d’embedding se retrouve face au même vide, à ceci près qu’il n’a aucun moyen de le signaler.

Le mécanisme restaure l’en-tête manquant. Lors de l’indexation, le modèle reçoit deux entrées : le document source complet et un chunk qui en fait partie, et il a pour seule tâche d’écrire un court contexte permettant de situer ce chunk au sein du tout.

Le prompt d’Anthropic tient en quelques lignes :

<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.

Appliqué au fragment d’exemple, le résultat pourrait ressembler à : « Ce fragment provient d’un dépôt SEC concernant les performances d’ACME Corp au deuxième trimestre 2023 ; le chiffre d’affaires du trimestre précédent était de 314 millions de dollars. » La phrase concernant une croissance de 3 % suit immédiatement. Environ cent tokens suffisent pour transformer un fragment isolé en une entrée muni d’une clé.

Le texte enrichi est ensuite enregistré dans deux index : l’un est l’index d’incorporation (Contextual Embeddings), l’autre est l’index de mots-clés (Contextual BM25). Comme le nom ACME est indiqué dans chaque fragment, BM25 peut identifier l’entreprise sur n’importe quelle page du rapport, alors qu’auparavant seule la page de couverture en faisait mention.

Ce n’était d’ailleurs pas non plus la première idée testée. Anthropic a rapporté des expériences antérieures avec des résumés de documents génériques associés aux blocs, qui ont donné des « gains très limités », ainsi qu’avec HyDE et l’indexation basée sur des résumés, qui n’ont pas été très efficaces non plus (Anthropic, septembre 2024). Seul le préfixe est resté.

Ce qui distingue un résumé d’un préfixe est de nature mécanique. Un résumé est partagé par tous les blocs d’un document, il ne peut donc pas différencier le bloc A du bloc B au sein du même rapport annuel, tandis que chaque préfixe de localisation est écrit pour sa propre position dans le document.

Les corpus composés de dossiers, de contrats, de documentation technique ou de bases de code, où un même schéma linguistique réapparaît à de nombreux endroits, sont précisément les contextes où les blocs se perdent aujourd’hui. Le préfixe d’incorporation seul permet une réduction de 35 % des erreurs, et ce n’est que le premier niveau.

Un escalier à l’intérieur d’un seul numéro

On cite souvent « 67 % » comme étant l’effet d’une seule technique. Le tableau publié indique quelque chose de différent, et il ressemble davantage à une progression graduelle qu’à un saut unique.

Les résultats sont mesurés selon la formule un moins recall@20 : c’est la proportion de requêtes dont le fragment correct n’a pas figuré parmi les vingt meilleurs. Anthropic qualifie cela de taux d’échec et le présente pour des bases de code, de la fiction, des articles arXiv et des publications scientifiques.

Quatre configurations s’empilent les unes sur les autres :

  • La configuration de référence, utilisant des embeddings simples sur des fragments bruts : 5,7 % des requêtes échouent.
  • Avec uniquement des embeddings contextuels : 3,7 %, soit une réduction de 35 % due uniquement au préfixe.
  • Avec l’ajout de BM25 contextuel : 2,9 %, ce qui représente une réduction cumulative de 49 %, l’index des mots-clés apportant la majeure partie de cet avantage.
  • Avec l’ajout du réclassement : 1,9 %, c’est de là que provient le chiffre de 67 %, grâce à l’étape finale.

Un réclassificateur est un deuxième modèle qui lit conjointement la requête et un fragment candidat. Il est plus lent que la première passe, mais bien plus précis. Ici, il a réduit 150 candidats à vingt. Les quatre graphiques présentés décrivent la configuration d’incorporation la plus performante du test, Gemini Text 004, et ne représentent pas une moyenne parmi les modèles d’incorporation testés par Anthropic.

Cette répartition modifie la décision, et pas seulement le résultat global. Une équipe qui utilise déjà des recherches hybrides et un réclassificateur en production devrait s’attendre à ce que la contextualisation seule permette d’atteindre près de 35 % plutôt que 67 %, puisque les deux autres niveaux sont déjà pris en charge. Interpréter ce chiffre comme un effet unique est une erreur fréquente, et une grande partie de la réduction provient des composants standards de récupération qui accomplissent leur fonction habituelle.

Un fil de discussion sur Hacker News soulève une mise en garde importante : personne n’a publié les performances du simple BM25, sans aucune contextualisation, dans ce même test. Sans cette colonne de données, il est impossible de déterminer dans quelle mesure l’augmentation à 49 % est due au contexte dans l’index lexical et dans quelle mesure elle est due à une recherche hybride simple.

Un piège lors de la citation des chiffres

Tout ceux qui citent ces résultats peuvent également tomber dans un piège de calcul. Le guide d’Anthropic présente un ensemble de données plus petit, composé de neuf bases de code et de 248 requêtes, évaluées selon une autre mesure : Pass@20 passe de 90 % pour la version de base à 97 % pour l’ensemble complet. Corpus différent, métrique différente, donc mélanger ces chiffres avec les précédents constitue simplement une erreur.

Cette réduction n’est pas gratuite. Elle coûte de l’argent au moment de l’indexation, mais un mécanisme permet de maintenir ce coût proche d’un dollar plutôt que de mille.

Pourquoi un dollar et non mille

Considérons l’approche naïve. Un document de 8 000 tokens est divisé en dix parties. Sans aucune optimisation, chaque appel relit l’intégralité du document, de sorte que le même texte est traité dix fois pour décrire dix paragraphes différents.

C’est ce profil de coûts qui a bloqué cette idée pendant des années. Les gens l’ont rejetée en la qualifiant de méthode de force brute et l’ont écartée dans les budgets, bien avant que les avantages en termes de qualité ne soient mesurés.

Le cacheage des prompts modifie les calculs à un niveau précis : le document est envoyé une seule fois sous forme de préfixe fixe. La première demande entraîne une écriture dans le cache au prix d’environ 1,25 fois le prix de base, tandis que chaque demande ultérieure concernant ce même document entraîne une lecture dans le cache au prix d’environ un dixième du prix de base.

En supposant des tailles typiques pour les blocs et les documents, la contextualisation coûte 1,02 dollar une seule fois par million de tokens de texte source. Ce montant est indiqué en même temps que les paramètres utilisés, à savoir des blocs de 800 tokens et des documents de 8 000 tokens, dont les coûts sont rarement communiqués. Cela permet de recalculer en utilisant des chiffres locaux plutôt que de se fier aveuglément à ces valeurs.

Dans un exemple tiré d’un livre de recettes couvrant 737 blocs, près de 62 % des tokens d’entrée provenaient du cache. Le coût total est ainsi passé d’environ 9,20 dollars à environ 2,85 dollars. Un modèle plus performant n’était pas responsable de cette économie de deux tiers : c’est le fait de ne lire le document qu’une seule fois qui l’a permis.

Le détail de l’ordre qui décide de tout

Un détail pratique détermine si tout cela se concrétisera. Le cache fonctionne sur la correspondance de préfixes, il faut donc traiter tous les fragments d’un même document l’un après l’autre pour pouvoir réutiliser une seule entrée de cache. Le parallélisme entre différents documents est possible, un travailleur par document, mais mélanger des fragments de plusieurs documents dans une seule file d’attente ne l’est pas. Un pipeline naïf typique distribue les fragments sur un pool de threads partagé, ce qui fait que le cache est consulté seulement de temps en temps, entraînant ainsi le paiement du tarif plein.

La figure mérite également une mise en garde. 1,02 $ reflète le prix du modèle en 2024 et n’est pas une valeur constante. La prochaine génération de ce modèle coûte quatre fois plus pour les données d’entrée, donc reproduire ce chiffre aujourd’hui sans recalculer les devis donne un prix obsolète.

Les aspects économiques semblent excellents pour les déclarations SEC, le même type de document utilisé comme exemple phare. Pourtant, quelqu’un a testé ce même type de document et a obtenu le résultat inverse.

Un exemple emblématique qui échoue à son propre test

C’est ici que commencent les parties que la plupart des résumés omettent.

L’illustration utilisait un extrait d’un dossier déposé auprès de la SEC, mais la liste des domaines analysés exclut ces dossiers. Elle mentionne des bases de code, des œuvres de fiction, arXiv et des publications scientifiques ; par conséquent, les documents financiers servent d’exemple narratif et non de corpus testé.

D’autres ont comblé cette lacune et ont obtenu un résultat inverse. Les ingénieurs de Snowflake (Tarakad, Yu, Samdani, Merrick, mars 2025) ont utilisé environ 23 000 dossiers 10-K et 10-Q authentiques comme corpus et ont évalué leur système sur environ 500 requêtes manuscrites.

L’enrichissement de chaque extrait avec un résumé volumineux, unique et rédigé par le modèle, que l’équipe a elle-même qualifié de récupération contextuelle, a entraîné une baisse des scores de 5,8 points pour un modèle et de 0,4 pour l’autre. Le résultat a été une perte, accompagnée d’une consommation de ressources informatiques considérablement plus élevée.

Lorsque des métadonnées bon marché surpassent un modèle coûteux

La découverte la plus intéressante concerne ce qui a fonctionné dans le même experiment. L’injection de métadonnées au niveau du document, à savoir le nom de l’entreprise, la date de dépôt et le type de formulaire, a permis d’augmenter la précision des réponses de près de 50 à 60 % à une fourchette de 72 à 75 %, sans aucune utilisation de modèle de langage.

Cet contraste illustre bien la leçon. Le problème était réel, car le fragment ne connaissait effectivement pas son entreprise. Pourtant, le remède le moins cher a surpassé le plus coûteux, car le nom de l’entreprise reste constant tout au long du processus de dépôt et son ajout ne nécessite aucun modèle.

Cette comparaison n’est pas une réplication rigoureuse, et cela doit être indiqué clairement. Snowflake a utilisé sa propre prompt, son modèle d’incorporation, sa taille de fragment et sa méthode d’évaluation, de sorte que les résultats ne peuvent pas être comparés directement comme s’ils provenaient d’un même outil. Ils concernent cependant le même type de document, ce qui explique leur pertinence.

Deux autres résultats atténuent l’enthousiasme. Une étude de référence de 2026 basée sur T²-RAGBench, indépendante de l’étude Snowflake, a testé la contextualisation sur des documents financiers contenant des tableaux. Elle a constaté des améliorations de 2,8 points de pourcentage avec une récupération dense et de 2,2 points avec une récupération hybride (arXiv). Ces améliorations sont réelles et reproductibles, mais elles sont loin des 67 % annoncés.

Cette même étude de référence, qui couvre plus de 23 000 requêtes sur 7 318 documents, révèle également un fait qui devrait inquiéter quiconque travaille avec des rapports : la plupart des erreurs restantes proviennent de désaccords dans la structure des tableaux. Un préfixe de texte ne peut pas y remédier, car il ne permet que de marquer avec précision les segments qui restent illisibles.

Le deuxième point concerne les ressources informatiques nécessaires. ConTEB (2025) a comparé la méthode de type Anthropic à un modèle d’incorporation entraîné spécifiquement à cette fin. Le modèle entraîné a obtenu en moyenne des résultats légèrement supérieurs et a traité chaque document environ cent fois plus rapidement (arXiv). Les différences de qualité sont minimes, car l’approche basée sur des préfixes l’emporte clairement sur certains ensembles de données, tels qu’un corpus d’assurances, mais perd de justesse sur d’autres. Ce que le modèle entraîné offre réellement, c’est une réduction des coûts informatiques.

Il existe également une autre conception concurrente. Late Chunking (Jina AI, septembre 2024) aborde le même problème à un niveau inférieur en incorporant l’ensemble du document et en le divisant en parties uniquement après le transformateur, sans faire appel à un modèle de langage. Sa faiblesse structurelle réside dans le fait qu’aucun élément n’est ajouté à l’index des mots-clés, ce qui fait perdre la moitié des avantages offerts par Contextual BM25.

Pour la plupart des corpus d’entreprises, c’est cette asymétrie, plus que l’écart métrique, qui détermine probablement le choix. Il s’agit d’une décision subjective, et la référence ConTEB citée ne la teste pas directement, puisque BM25 n’est pas parmi les composants qu’elle évalue.

Lorsque l’exemple présenté s’avère avoir un contre-exemple, la question pertinente devient de savoir où la technique échoue à être utile, et comment un corpus donné peut être vérifié en cinq minutes.

Cinq minutes de test avant tout investissement

Commencez par un test et non par une mise en œuvre. Prenez dix extraits aléatoires dans l’index et lisez chacun d’eux isolément. Si l’on peut déterminer de quoi chacun traite et d’où il provient, ces extraits possèdent déjà un contexte, et l’ajout d’un préfixe ne ferait qu’augmenter le nombre de tokens sans apporter d’informations supplémentaires.

Le test ne nécessite aucun code et ne prend que cinq minutes. C’est également la seule preuve qui concerne les données réelles et non celles de quelqu’un d’autre.

Quatre situations documentées où cette technique ne s’avère pas utile :

  • Un corpus de moins de deux cent mille tokens. Selon les conseils d’Anthropic pour cette échelle, il convient d’inclure l’ensemble de la base de connaissances dans la demande et d’éviter complètement la récupération d’informations. La contextualisation est destinée aux cas où le corpus ne tient plus dans la fenêtre de contexte.
  • Des fragments déjà autonomes. Les paires de FAQ, les fiches produits et les entrées de dictionnaire décrivent déjà eux-mêmes leur sujet, de sorte qu’un préfixe se contente de le répéter.
  • Un corpus qui change fréquemment. Le coût est unique uniquement si les documents restent stables. Les documents révisés chaque semaine donnent lieu à un nouveau paiement chaque semaine.
  • Des tableaux et des rapports financiers. Lorsque c’est la structure du tableau qui pose problème, plutôt qu’un nom d’entreprise manquant, le fragment est décrit avec précision mais reste illisible.

Le encadrement convient en trois lignes. Un corpus petit et stable est adapté aux contextes longs grâce au stockage en mémoire cache. Un corpus volumineux avec des blocs ambigus convient à la recherche contextuelle. Des entrées courtes et autonomes conviennent à une recherche hybride classique, sans frais supplémentaires.

L’ordre d’adoption est important, et c’est souvent ce qui entraîne des déceptions. La contextualisation augmente la valeur de la recherche hybride sans la remplacer. Une équipe qui ne dispose pas de BM25 ni de réclassement devrait les intégrer en premier ; ignorer cet ordre signifie acheter le troisième niveau alors que le premier fait encore défaut.

Calculez les coûts avant le déploiement, et non après. La formule est connue, les tailles des blocs et des documents sont déterminées, et la seule véritable incertitude réside dans le fait que le processus atteigne réellement le cache.

Que prendre en compte lors de l’examen de conception

Retournons à la phrase d’ouverture. « Les revenus ont augmenté de 3 % » n’était jamais faux. Elle était dépourvue de sujet. La solution n’était ni un modèle plus intelligent ni une meilleure intégration des données, mais simplement l’ajout d’une en-tête une seule fois, au moment de l’indexation.

  • Peu importe la puissance du modèle de génération de réponses, un fragment sans contexte est inutile. La cause réside dans l’indexation, et non dans des hallucinations.
  • Trois interventions permettent d’atteindre le taux de 67 % mentionné, et non une seule. Le préfixe seul donne déjà près de trente-cinq pour cent, et la recherche hybride avec réclassement complète le reste.
  • Le cache des prompts a rendu cette technique abordable, et non un modèle plus puissant ; en outre, les économies disparaissent sans un traitement document par document.
  • Le type de document utilisé dans l’exemple comporte un contre-exemple bien documenté : dans les déclarations SEC, des métadonnées de documents peu coûteuses ont surpassé des appels à un modèle coûteux par fragment.
  • Une vérification de cinq minutes d’un index réel vaut plus que n’importe quelle manchette. Lisez les dix extraits séparément.

En pratique, cela se résume à trois étapes, dans cet ordre : effectuer le test des dix extraits, vérifier si le corpus correspond à l’un des quatre cas négatifs, et seulement ensuite calculer le coût d’indexation à l’aide de la formule publiée. Seule la troisième étape nécessite un budget, tandis que les deux premières permettent de déterminer s’il est utile d’en demander un.

Une précaution reste à prendre. Anthropic a publié le détail des résultats dans un appendice, sous forme de PDF statique et non en tant que jeu de données brut, et les équipes indépendantes qui ont tenté de reproduire ces chiffres soulignent cela comme un problème de reproductibilité. Les évaluations directes sur des corpus dans des langues autres que l’anglais sont également rares. Tant que ces lacunes ne seront pas comblées, chaque chiffre présent ici provient d’une configuration spécifique et non d’une loi physique, et ce qui manque le plus aujourd’hui, ce sont des mesures de performance sur des corpus non anglophones.