Comprendre le contexte et la récupération contextuelle dans RAG

Dans mon dernier article, je explique comment la recherche hybride peut être utilisée pour améliorer considérablement l’efficacité d’un pipeline RAG. RAG, dans sa version de base, utilisant uniquement la recherche sémantique sur les intégrations, peut être très efficace, nous permettant d’utiliser la puissance de l’IA dans nos propres documents. Néanmoins, la recherche sémantique, aussi puissante soit-elle, lorsqu’elle est utilisée dans de grandes bases de connaissances, peut parfois manquer des correspondances exactes de la requête de l’utilisateur, même si elles existent dans les documents. Cette faiblesse du RAG traditionnel peut être corrigée en ajoutant un composant de recherche par mot clé dans le pipeline, comme BM25. De cette manière, la recherche hybride, combinant recherche sémantique et recherche par mots clés, conduit à des résultats beaucoup plus complets et améliore considérablement les performances d’un système RAG.

Quoi qu’il en soit, même en utilisant RAG avec la recherche hybride, nous pouvons encore parfois manquer des informations importantes dispersées dans différentes parties du document. Cela peut se produire car lorsqu’un document est divisé en morceaux de texte, le contexte, c’est-à-dire le texte entourant le morceau qui fait partie de sa signification, est parfois perdu. Cela peut particulièrement se produire pour un texte complexe, dont le sens est interconnecté et dispersé sur plusieurs pages, et qui ne peut inévitablement pas être entièrement inclus dans un seul morceau. Pensez, par exemple, à faire référence à un tableau ou à une image dans plusieurs sections de texte différentes sans définir explicitement à quel tableau nous faisons référence (par exemple, «comme le montre le tableau, les bénéfices ont augmenté de 6 % » — quelle table ?). En conséquence, lorsque les morceaux de texte sont ensuite récupérés, ils sont dépouillés de leur contexte, ce qui entraîne parfois la récupération de morceaux non pertinents et la génération de réponses non pertinentes.

Cette perte de contexte a été un problème majeur pour les systèmes RAG pendant un certain temps, et plusieurs solutions sans succès ont été explorées pour l’améliorer. Une tentative évidente pour améliorer cela consiste à augmenter la taille des fragments, mais cela modifie souvent également la signification sémantique de chaque fragment et finit par rendre la récupération moins précise. Une autre approche consiste à augmenter le chevauchement des morceaux. Bien que cela contribue à accroître la préservation du contexte, cela augmente également les coûts de stockage et de calcul. Plus important encore, cela ne résout pas complètement le problème : nous pouvons toujours avoir des interconnexions importantes avec les limites des fragments. Des approches plus avancées tentant de résoudre ce défi comprennent Incorporations de documents hypothétiques (HyDE) ou Index récapitulatif des documents. Néanmoins, ceux-ci ne parviennent toujours pas à apporter des améliorations substantielles.

En fin de compte, une approche qui résout efficacement ce problème et améliore considérablement les résultats d’un système RAG est récupération contextuelle, initialement introduit par Anthropic en 2024. La récupération contextuelle vise à résoudre la perte de contexte en préservant le contexte des fragments et, par conséquent, en améliorant la précision de l’étape de récupération du pipeline RAG.

. . .

Et le contexte ?

Avant de parler de récupération contextuelle, prenons du recul et parlons un peu de ce qu’est le contexte. Bien sûr, nous avons tous entendu parler du contexte des LLM ou des fenêtres contextuelles, mais de quoi s’agit-il vraiment ?

Pour être très précis, le contexte fait référence à tous les jetons dont dispose le LLM et sur la base desquels il prédit le mot suivant — rappelez-vous, les LLM fonctionnent en générant du texte en le prédisant un mot à la fois. Ainsi, il s’agira de l’invite de l’utilisateur, de l’invite du système, des instructions, des compétences ou de toute autre directive influençant la manière dont le modèle produit une réponse. Il est important de noter que la partie de la réponse finale que le modèle a produite jusqu’à présent fait également partie du contexte, puisque chaque nouveau jeton est généré sur la base de tout ce qui l’a précédé.

Apparemment, différents contextes conduisent à des résultats de modèles très différents. Par exemple:

• ‘Je suis allé au restaurant et j’ai commandé un‘pourrait afficher’pizza.‘
• «Je suis allé à la pharmacie et j’ai acheté un‘pourrait afficher’médecine.‘

Une limitation fondamentale des LLM est leur fenêtre contextuelle. La fenêtre contextuelle d’un LLM est le nombre maximum de jetons qui peuvent être transmis simultanément en entrée au modèle et pris en compte pour produire une réponse unique. Il existe des LLM avec des fenêtres contextuelles plus grandes ou plus petites. Les modèles frontières modernes peuvent gérer des centaines de milliers de jetons en une seule requête, alors que les modèles antérieurs avaient souvent des fenêtres de contexte aussi petites que 8 000 jetons.

Dans un monde parfait, nous voudrions simplement transmettre toutes les informations dont le LLM a besoin dans le contexte, et nous obtiendrons très probablement de très bonnes réponses. Et cela est vrai dans une certaine mesure – un modèle frontière comme Opus 4.6 avec une fenêtre contextuelle de 200 000 jetons correspond à environ 500 à 600 pages de texte. Si toutes les informations que nous devons fournir correspondent à cette limite de taille, nous pouvons en effet tout inclure tel quel, comme entrée dans le LLM et obtenir une excellente réponse.

Le problème est que pour la plupart des cas d’utilisation réels de l’IA, nous devons utiliser une sorte de base de connaissances dont la taille dépasse largement ce seuil – pensez, par exemple, aux bibliothèques juridiques ou aux manuels d’équipement technique. Étant donné que les modèles ont ces limitations de fenêtre contextuelle, nous ne pouvons malheureusement pas simplement tout transmettre au LLM et le laisser répondre comme par magie – nous devons d’une manière ou d’une autre choisir quoi est l’information la plus importante qui devrait être incluse dans notre fenêtre contextuelle limitée. Et c’est essentiellement l’objectif de la méthodologie RAG : sélectionner les informations appropriées dans une vaste base de connaissances afin de répondre efficacement à la requête d’un utilisateur. En fin de compte, cela apparaît comme un problème d’optimisation/d’ingénierie — ingénierie du contexte — identifier les informations appropriées à inclure dans une fenêtre contextuelle limitée, afin de produire les meilleures réponses possibles.

Il s’agit de la partie la plus cruciale d’un système RAG : s’assurer que les informations appropriées sont récupérées et transmises en entrée au LLM. Cela peut être fait avec la recherche sémantique et la recherche par mot-clé, comme déjà expliqué. Néanmoins, même en rassemblant tous les morceaux sémantiquement pertinents et toutes les correspondances exactes, il y a toujours de fortes chances que quelques des informations importantes peuvent être oubliées.

Mais de quel genre d’informations s’agirait-il ? Puisque nous avons couvert la signification avec la recherche sémantique et les correspondances exactes avec la recherche par mot clé, quels autres types d’informations faut-il prendre en compte ?

Différents documents ayant des significations intrinsèquement différentes peuvent inclure des parties similaires, voire identiques. Imaginez un livre de recettes et un manuel de traitement chimique demandant tous deux au lecteur de « Faites chauffer le mélange lentement ». La signification sémantique d’un tel morceau de texte et les mots réels sont très similaires – identiques. Dans cet exemple, ce qui forme le sens du texte et nous permet de séparer la cuisine du génie chimique est ce que nous appelons contexte.

C’est donc le genre d’informations supplémentaires que nous visons à préserver. Et c’est exactement ce que fait la récupération contextuelle : préserver le contexte – le sens environnant – de chaque morceau de texte.

. . .

Qu’en est-il de la récupération contextuelle ?

Ainsi, la récupération contextuelle est une méthodologie appliquée dans RAG visant à préserver le contexte de chaque morceau. De cette façon, lorsqu’un morceau est récupéré et transmis au LLM en entrée, nous sommes en mesure de conserver autant que possible sa signification initiale – la sémantique, les mots-clés, le contexte – tout cela.

Pour y parvenir, la récupération contextuelle suggère que nous générions d’abord un texte d’assistance pour chaque morceau, à savoir le texte contextuel – cela nous permet de situer le morceau de texte dans le document original dont il provient. En pratique, nous demandons à un LLM de générer ce texte contextuel pour chaque morceau. Pour ce faire, nous fournissons le document, ainsi que le morceau lui-même, dans une seule requête à un LLM et lui demandons de «fournir le contexte pour situer le morceau spécifique dans le document« . Une invite pour générer le texte contextuel pour notre Livre de cuisine italienne le morceau ressemblerait à ceci :

<document> 
the entire document Italian Cookbook document the chunk comes from
</document> 

Here is the chunk we want to place within the context of the full document.

<chunk> 
the actual chunk
</chunk> 

Provide a brief context that situates this chunk within the overall 
document to improve search retrieval. Respond only with the concise 
context and nothing else.

Le LLM renvoie le texte contextuel que nous combinons avec notre bloc de texte initial. De cette façon, pour chaque morceau de notre texte initial, nous générons un texte contextuel qui décrit comment ce morceau spécifique est placé dans son document parent. Pour notre exemple, cela donnerait quelque chose comme :

Context: Recipe step for simmering homemade tomato pasta sauce.
Chunk: Heat the mixture slowly and stir occasionally to prevent it from sticking.

Ce qui est en effet beaucoup plus informatif et précis ! Il n’y a désormais aucun doute sur ce qu’est ce mystérieux mélange, car toutes les informations nécessaires pour déterminer s’il s’agit de sauce tomate ou de solutions d’amidon de laboratoire sont commodément incluses dans le même morceau.

À partir de ce moment, nous traitons le texte initial et le texte contextuel comme une paire incassable. Ensuite, le reste des étapes de RAG avec recherche hybride s’effectue essentiellement de la même manière. Autrement dit, nous créons des intégrations qui sont stockées dans une recherche vectorielle et l’index BM25 pour chaque morceau de texte, précédé de son texte contextuel.

Cette approche, aussi simple soit-elle, entraîne des améliorations étonnantes des performances de récupération des pipelines RAG. Selon Anthropic, la récupération contextuelle améliore la précision de la récupération en un impressionnant 35 %.

. . .

Réduire les coûts grâce à une mise en cache rapide

Je vous entends demander : «Mais est-ce que cela ne va pas coûter une fortune ?« . Étonnamment, non.

Intuitivement, nous comprenons que cette configuration va augmenter considérablement le coût d’ingestion d’un pipeline RAG – le doubler, voire plus. Après tout, nous avons maintenant ajouté un tas d’appels supplémentaires au LLM, n’est-ce pas ? C’est vrai dans une certaine mesure — en effet désormais, pour chaque morceau, nous faisons un appel supplémentaire au LLM afin de le situer dans son document source et d’obtenir le texte contextuel.

Il s’agit cependant d’un coût que nous ne payons qu’une seule fois, au stade de l’ingestion du document. Contrairement aux techniques alternatives qui tentent de préserver le contexte au moment de l’exécution, telles que les intégrations de documents hypothétiques (HyDE), la récupération contextuelle effectue le gros travail pendant la phase d’ingestion du document. Dans les approches d’exécution, des appels LLM supplémentaires sont requis pour chaque requête utilisateur, ce qui peut rapidement faire évoluer la latence et les coûts opérationnels. En revanche, la récupération contextuelle déplace le calcul vers la phase d’ingestion, ce qui signifie que la qualité de récupération améliorée ne s’accompagne d’aucune surcharge supplémentaire pendant l’exécution. En plus de cela, des techniques supplémentaires peuvent être utilisées pour réduire davantage le coût de récupération contextuelle. Plus précisément, la mise en cache peut être utilisée pour générer le résumé du document une seule fois, puis situer chaque morceau par rapport au résumé du document produit.

. . .

Dans mon esprit

La récupération contextuelle représente une amélioration simple mais puissante par rapport aux systèmes RAG traditionnels. En enrichissant chaque morceau avec du texte contextuel, en identifiant sa position sémantique dans son document source, nous réduisons considérablement l’ambiguïté de chaque morceau, et améliorons ainsi la qualité des informations transmises au LLM. Combinée à la recherche hybride, cette technique permet de préserver simultanément la sémantique, les mots-clés et le contexte.

---

Vous avez adoré cet article ? Soyons amis ! Rejoignez-moi sur :

📰Sous-pile 💌 Moyen 💼LinkedIn ☕Achetez-moi un café!

Toutes les images sont de l’auteur, sauf mention contraire.