RAG et Injection de Contexte

1. Le problème de la connaissance

La connaissance paramétrique d'un modèle de langage — les informations encodées dans ses poids pendant l'entraînement — a deux limites strictes. La première est la date limite d'entraînement (cutoff) : le modèle ne connaît pas les événements postérieurs à une certaine date. La seconde est une limite de couverture : même pendant la fenêtre d'entraînement, de vastes quantités d'informations spécifiques à un domaine, propriétaires ou simplement obscures n'ont jamais été ingérées.

La réponse standard est l'affinage (fine-tuning) : ajuster les poids du modèle sur vos données de domaine pour que l'information fasse partie de sa mémoire paramétrique. C'est souvent le mauvais choix. Le fine-tuning est coûteux, lent et introduit ses propres modes d'échec — notamment le risque d'oubli catastrophique — une perte de performance sur les tâches générales — particulièrement avec un fine-tuning complet sur des ensembles de données petits ou restreints. Plus important encore, il confond deux problèmes très différents : enseigner au modèle comment se comporter versus lui donner quoi savoir.

Lewis et al. (2020) ont introduit le RAG comme une architecture formelle, combinant un module de récupération non paramétrique avec un modèle séquence-à-séquence paramétrique, montrant des améliorations constantes par rapport à la génération en vase clos sur les benchmarks de traitement du langage naturel (NLP) gourmands en connaissances.^#NeurIPS Depuis lors, le RAG est devenu l'architecture dominante pour tout système qui a besoin de fonder la sortie du modèle sur des informations vérifiables, mises à jour et spécifiques à un domaine.

L'implication pratique est claire : avant de vous tourner vers le fine-tuning, vous devriez vous demander si le problème est un problème d'accès aux connaissances plutôt qu'un calibrage comportemental. Si la réponse est oui, le RAG — bien implémenté — sera plus rapide à construire, moins cher à exploiter et plus facile à auditer. La mise en garde est que "bien implémenté" pèse plus lourd qu'il n'y paraît. La plupart des échecs de RAG ne sont pas des échecs de l'idée sous-jacente ; ce sont des échecs de découpage, de récupération ou d'injection.

2. Le pipeline RAG

Un système RAG comporte trois étapes distinctes. Comprendre chaque étape indépendamment est le prérequis pour diagnostiquer les échecs, car un problème à l'étape un se propage silencieusement aux étapes deux et trois — produisant une réponse assurée, fluide et entièrement erronée.

La propriété clé de ce pipeline est que les étapes un et deux sont entièrement séparées du modèle de langage. Le LLM ne participe qu'à l'étape trois. Cela signifie que vous pouvez changer le système de récupération, mettre à jour l'index de documents ou changer le modèle d'embedding sans toucher à votre prompt ni à votre modèle de génération. Le pipeline est modulaire par conception.

Cela signifie également que la qualité de la récupération est un plafond infranchissable pour la qualité de la génération. Un modèle qui reçoit un contexte médiocre, non pertinent ou contradictoire ne peut pas compenser par un raisonnement astucieux — il va soit halluciner pour combler le vide, soit produire une réponse qui reflète fidèlement le mauvais contexte. Le principe "Garbage in, Garbage out" s'applique à chaque étape, mais l'étape de récupération amplifie l'erreur avant même que le LLM n'ait la possibilité de la corriger.

3. Stratégies de découpage (Chunking)

Le découpage est la décision la plus sous-estimée dans un pipeline RAG. Il détermine la granularité de ce que le système de récupération peut trouver et contrôle le compromis entre précision et contexte. Un fragment trop petit fait perdre le sens ; un fragment trop grand pollue la fenêtre de contexte avec du contenu non pertinent qui dilue le signal.

Il n'existe pas de taille de fragment universellement correcte. Le bon choix dépend de votre type de document, de la limite de jetons de votre modèle d'embedding et de la nature des requêtes que votre système recevra. Voici les quatre principales stratégies et leurs cas d'application.

Découpage à taille fixe

Divisez le document en fragments de N jetons (ou caractères) avec un chevauchement de M jetons entre les fragments adjacents. Le chevauchement garantit que les phrases coupées à la limite d'un fragment disposent toujours de leur contexte dans au moins un fragment. C'est la stratégie la plus simple et le bon point de départ.

Note : 512 jetons conviennent à la plupart des modèles d'embedding de 2022–2024. Les modèles plus récents prenant en charge des entrées de plus de 8k jetons peuvent bénéficier de tailles de fragments plus grandes — consultez la documentation de votre modèle d'embedding pour connaître sa longueur d'entrée optimale.

Découpage sémantique

Au lieu de couper à des nombres de jetons fixes, coupez aux limites sémantiques naturelles — sauts de paragraphe, titres de section ou changements de sujet détectés en comparant la similitude des embeddings entre phrases consécutives. Lorsque la similitude cosinus entre la phrase n et la phrase n+1 tombe en dessous d'un certain seuil, vous avez trouvé une limite.

Le découpage sémantique produit des fragments plus cohérents — chaque fragment est plus susceptible de traiter d'un seul sujet — ce qui améliore la précision de la récupération. Le compromis est la taille variable des fragments, ce qui complique la gestion du budget de la fenêtre de contexte en aval. Utilisez cette stratégie lorsque la structure du document est irrégulière (ex: contenu web scrapé, rapports aux formats mixtes) et qu'un découpage fixe briserait systématiquement des unités logiques.

Découpage hiérarchique

Indexez les documents à plusieurs niveaux de granularité simultanément : sections entières pour une récupération thématique large, paragraphes pour une récupération de précision. Au moment de la requête, récupérez au niveau du paragraphe mais renvoyez la section environnante comme contexte. Ce schéma "petit vers grand" — récupérer de petits fragments, injecter de grands fragments — est particulièrement efficace pour les longs documents techniques où la réponse pertinente est une phrase spécifique, mais où cette phrase n'a de sens que dans le contexte de sa section.^#Survey

Late chunking

Une approche plus récente de Günther et al. (2024) : intégrez (embed) le document complet d'abord, puis découpez les embeddings de jetons résultants plutôt que le texte brut.^#Late Parce que les embeddings sont calculés avec le contexte complet du document, la représentation vectorielle de chaque fragment capture le sens du texte environnant — résolvant le problème du "contexte perdu" inhérent au découpage à taille fixe sans la complexité de la récupération hiérarchique. Si votre modèle d'embedding prend en charge les contextes longs (>8k jetons), cette méthode mérite d'être évaluée.

4. Embedding et recherche par similitude

Un modèle d'embedding projette un morceau de texte vers un vecteur dense dans un espace à haute dimension, de sorte que les textes sémantiquement similaires se retrouvent proches les uns des autres selon la distance cosinus. C'est le fondement de la recherche sémantique : au lieu de faire correspondre des mots-clés, vous faites correspondre du sens.

Le choix du modèle d'embedding importe plus que ce que la plupart des équipes prévoient, et il importe différemment selon votre domaine. Les modèles d'embedding à usage général (ex: text-embedding-3-large d'OpenAI, embed-v3 de Cohere ou des alternatives open-source comme bge-m3) sont performants sur le langage courant. Ils se dégradent sur le vocabulaire spécifique à un domaine — termes juridiques, nomenclature médicale, noms de produits propriétaires — car ces termes sont apparus rarement dans les données d'entraînement et leurs embeddings sont imprécis.

Pour la recherche par similitude à grande échelle, une recherche exacte des plus proches voisins sur des millions de vecteurs est prohibitive en termes de calcul. Les algorithmes de plus proches voisins approximatifs (ANN) — le plus utilisé étant FAISS (Meta AI Similarity Search) — partitionnent l'espace vectoriel en utilisant des structures comme HNSW (Hierarchical Navigable Small World graphs) ou IVF (Inverted File Index), permettant une recherche sub-linéaire au prix d'un léger compromis sur le rappel.^#FAISS

Pour les systèmes de production avec moins de ~100k documents, la recherche exacte est souvent assez rapide et supprime une source d'échec. Utilisez l'indexation ANN quand vous en avez besoin, pas par défaut.

Recherche hybride

La recherche sémantique excelle dans la correspondance d'intention mais échoue sur les chaînes de caractères exactes : codes de produits, noms, identifiants et termes rares qui n'ont jamais fait partie de la distribution d'entraînement du modèle d'embedding. La recherche lexicale (BM25 ou similaire) excelle dans la correspondance exacte et de termes rares mais passe à côté des paraphrases et des synonymes.^#BM25

La recherche hybride combine les deux signaux. En pratique : lancez la recherche sémantique et BM25 en parallèle, puis fusionnez les ensembles de résultats en utilisant la Reciprocal Rank Fusion (RRF) ou une combinaison linéaire apprise. Les propres conseils d'Anthropic sur la récupération contextuelle ont montré que l'enrichissement contextuel des fragments à lui seul réduisait les échecs de récupération de 49 %, et de 67 % lorsqu'il était combiné à la recherche hybride et au reclassement.^#Anthropic

Ajoutez un cross-encoder reranker comme étape finale. Les cross-encoders notent les paires requête-fragment conjointement (plutôt que séparément, comme le font les modèles d'embedding bi-encoder) et sont considérablement plus précis — au prix de la latence. Appliquez le reclassement uniquement aux 20 meilleurs candidats sémantiques, pas à l'index complet.

5. Injection de contexte

La récupération vous donne des fragments pertinents. L'injection pose la question de savoir comment assembler ces fragments dans un prompt sur lequel le modèle peut raisonner correctement. C'est un problème d'ingénierie de prompt, pas un problème de récupération — et c'est là que la plupart des implémentations RAG laissent passer une qualité significative.

L'approche naïve : concaténer les fragments récupérés sous forme de texte brut et les ajouter à la requête utilisateur. Cela fonctionne, mais cela ne dit pas au modèle ce qu'est le texte, d'où il vient, quel était le degré de confiance de la récupération ou comment gérer les conflits entre fragments. Un modèle présenté avec un mur de texte indifférencié fera de son mieux, mais "faire de son mieux" inclut l'hallucination de transitions entre les fragments et l'échec à attribuer correctement les affirmations.

Le modèle d'injection

Structurez votre injection de contexte. Chaque fragment récupéré doit arriver dans le prompt avec au minimum : un identifiant de source, le contenu du fragment et un séparateur. Un modèle d'injection bien conçu ressemble à ceci :

L'étiquette de pertinence montrée ici est dérivée du score de similitude du récupérateur — haute, moyenne ou basse en fonction des seuils que vous définissez. Elle n'est pas générée automatiquement ; votre couche d'orchestration doit mapper le score flottant à une étiquette et l'insérer dans le modèle.

Enrichissement contextuel des fragments

Un fragment récupéré isolément perd souvent son sens. La phrase "La politique ne s'applique qu'aux utilisateurs enregistrés" ne signifie rien sans savoir de quelle politique il s'agit, dans quel contexte, de quel document. La récupération contextuelle — consistant à ajouter à chaque fragment, au moment de l'indexation, un bref résumé généré par LLM de son contexte documentaire — améliore considérablement la précision de la récupération car les embeddings portent désormais des informations situationnelles, et non seulement la phrase brute.^#Anthropic

Cette étape d'enrichissement ajoute un coût LLM ponctuel au moment de la construction de l'index — générer un court préfixe contextuel pour chaque fragment — mais c'est un coût fixe qui améliore considérablement la qualité de la récupération au moment de l'exécution. C'est l'une des interventions les plus rentables disponibles dans un pipeline RAG standard.

6. Le budget de la fenêtre de contexte

Une fenêtre de contexte a une capacité fixe, et chaque jeton que vous dépensez pour le contexte récupéré est un jeton indisponible pour les instructions système, l'historique de la conversation et le propre raisonnement par chaîne de pensée du modèle. Gérer ce budget explicitement — plutôt que d'espérer que ça rentre — est la différence entre un système qui se dégrade gracieusement sous la charge et un système qui tronque silencieusement le fragment le plus pertinent.

En pratique, les modèles de pointe prennent désormais en charge des fenêtres de contexte de 128k à 1M de jetons, ce qui rend le débordement moins probable. Mais deux problèmes plus subtils subsistent. Premièrement, les contextes très longs font que les modèles accordent moins de fiabilité aux informations situées au milieu — l'effet "perdu au milieu" (lost in the middle) documenté par Liu et al. (2023) : la performance du modèle se dégrade considérablement lorsque les informations pertinentes apparaissent au milieu d'un contexte long, par opposition au début ou à la fin.^#Middle Deuxièmement, injecter plus de contexte que nécessaire augmente la latence et le coût sans améliorer la qualité de la réponse — et la dégrade parfois, car le modèle doit maintenant distinguer le signal du bruit dans un ensemble de documents plus large.

Une allocation pratique pour un système RAG de complexité moyenne sur un contexte de 32k jetons :

Si le contenu récupéré dépasse systématiquement le budget, la bonne réponse n'est pas d'augmenter le top-k ou la taille des fragments — c'est d'améliorer la précision de la récupération afin que vous ayez besoin de moins de fragments pour couvrir les informations pertinentes. Un système de récupération qui doit renvoyer 10 fragments pour être sûr que le bon est inclus est un système de récupération qui doit être corrigé.

7. Modes d'échec

Les systèmes RAG échouent d'une manière qualitativement différente des échecs de génération simple. Un échec de génération simple est visible — le modèle dit "Je ne sais pas" ou produit quelque chose d'évidemment faux. Un échec RAG est souvent invisible : le modèle produit une réponse assurée, bien structurée et fluide qui est fondée sur le mauvais contenu. Les utilisateurs lui font confiance. Le système enregistre une exécution réussie. L'erreur se propage silencieusement.

Comprendre les quatre principaux modes d'échec est le prérequis pour construire des pipelines d'évaluation qui les capturent réellement.

Échec de récupération (Retrieval miss)

Le bon fragment existe dans l'index mais n'est pas renvoyé. Les causes incluent : la requête est formulée différemment du document (un décalage de vocabulaire que la recherche sémantique atténue partiellement mais n'élimine pas), la limite du fragment coupe la phrase pertinente, ou le modèle d'embedding a une faible précision pour ce domaine. Détection : mesurer le rappel@k par rapport à un ensemble de données requête-réponse étiqueté. Correction : recherche hybride, reclassement, expansion de requête ou enrichissement contextuel des fragments.

Empoisonnement du contexte (Context poisoning)

Les fragments récupérés contiennent du contenu contradictoire, obsolète ou factuellement incorrect — et le modèle le traite comme faisant autorité car le prompt d'injection lui demande de s'appuyer sur le contexte fourni. C'est sans doute le mode d'échec le plus dangereux car il est induit par l'architecture : l'instruction de fondation qui empêche l'hallucination empêche également le modèle de corriger un mauvais contexte en utilisant ses connaissances paramétriques.

Atténuations : indexez les métadonnées incluant la date et la version du document ; instruisez le modèle explicitement sur les règles de résolution de conflit ("en cas de contradiction entre les sources, préfère la source datée la plus récente") ; implémentez une étape de dédoublonnage post-récupération qui supprime les versions de documents périmées.

Inadéquation Récupération–Réponse

Les fragments récupérés sont thématiquement liés à la requête mais ne contiennent pas réellement les informations nécessaires pour y répondre. Le modèle, instruit de répondre à partir du contexte, soit génère une réponse à partir de ses connaissances paramétriques tout en semblant citer les fragments récupérés, soit produit une réponse évasive mais assurée ("D'après les informations disponibles, il semble que…") qui ne donne aucune indication sur l'échec de récupération sous-jacent.

Cet échec est courant lorsque la taille des fragments est trop petite (la phrase pertinente est présente dans le corpus mais répartie sur deux fragments, dont aucun ne franchit seul le seuil de récupération) ou lorsque la requête nécessite de synthétiser des informations sur plusieurs documents qui ne sont pas récupérés ensemble. Détection : score de fidélité (faithfulness) — comparer la réponse générée aux fragments récupérés pour vérifier que chaque affirmation dans la réponse est étayée par le contexte fourni.

Sur-récupération et dilution du contexte

Injecter trop de fragments dégrade la qualité de la réponse même lorsque le bon fragment est présent. Le modèle doit traiter plus de contenu, le signal pertinent est dilué par un contexte non pertinent et la probabilité que le modèle accorde de l'attention au bon fragment diminue. Liu et al. (2023) ont montré que la performance du modèle sur le QA multi-documents se dégrade de manière non linéaire à mesure que le nombre de documents injectés augmente, avec les chutes les plus prononcées lorsque l'information pertinente est positionnée au milieu du contexte.^#Middle

La correction est contre-intuitive : récupérez plus, injectez moins. Utilisez un top-k élevé à l'étape de récupération (ex: 20 candidats), appliquez un reclassement (reranking) et n'injectez que les 4 à 6 meilleurs après reclassement. La précision au moment de l'injection importe plus que le rappel au moment de la récupération.

8. Guide de décision

Le RAG n'est pas la réponse à tous les problèmes d'accès à l'information. L'appliquer indistinctement ajoute une complexité d'infrastructure et des modes d'échec inutiles lorsque la connaissance paramétrique du modèle est suffisante. Utilisez le cadre suivant avant de vous tourner vers une base de données vectorielle.

Les architectures RAG avancées — Self-RAG (Asai et al., 2023), qui apprend au modèle à décider quand récupérer et à critiquer son propre contenu récupéré^#Self-RAG ; FLARE (Jiang et al., 2023), qui récupère de manière itérative en fonction des prédictions de jetons à faible confiance^#FLARE — répondent à certains des modes d'échec décrits ci-dessus, au prix d'une complexité et d'une latence accrues. Elles méritent d'être connues, mais l'ordre correct est : construisez d'abord un pipeline RAG naïf fonctionnel, mesurez ses modes d'échec par rapport à vos requêtes spécifiques, puis appliquez des améliorations ciblées. La complexité ajoutée avant l'évaluation est une complexité que vous ne pouvez pas justifier.

Références

1. #NeurIPS Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. L'article fondateur sur le RAG, combinant un récupérateur DPR avec un générateur BART ; a démontré des améliorations constantes par rapport à la génération en vase clos sur le QA à domaine ouvert. NeurIPS 2020. arXiv:2005.11401
2. #Survey Gao, Y., et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. Taxonomie complète des architectures RAG incluant le RAG naïf, avancé et modulaire ; couvre les stratégies de découpage, d'indexation, de récupération et de génération. arXiv:2312.10997
3. #Late Günther, M., et al. (2024). Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models. Propose d'intégrer (embed) le document complet avant le découpage pour préserver le contexte inter-fragments dans la représentation vectorielle de chaque fragment. arXiv:2409.04701
4. #FAISS Douze, M., et al. (2024). The Faiss Library. Aperçu technique de FAISS, couvrant les stratégies d'indexation IVF, HNSW et de quantification de produit pour la recherche des plus proches voisins approximatifs à l'échelle du milliard. arXiv:2401.08281
5. #BM25 Robertson, S. & Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Fondements de la fonction de classement BM25. Reste la référence dominante de récupération lexicale dans les systèmes de recherche hybride. Foundations and Trends in Information Retrieval, 3(4). doi:10.1561/1500000019
6. #Anthropic Anthropic. (2024). Introducing Contextual Retrieval. Décrit la technique d'enrichissement contextuel des fragments — en ajoutant au début de chaque fragment le contexte documentaire généré par LLM au moment de l'indexation — signalant une réduction de 67 % des échecs de récupération lorsqu'elle est combinée à la recherche hybride et au reclassement. anthropic.com/news/contextual-retrieval
7. #Middle Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. Démontre que la performance des LLM sur le QA multi-documents se dégrade lorsque les informations pertinentes sont positionnées au milieu de contextes longs ; informe la stratégie d'ordonnancement des fragments lors de l'injection. arXiv:2307.03172
8. #Self-RAG Asai, A., et al. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique Through Self-Reflection. Entraîne le modèle à générer des jetons de réflexion spéciaux pour décider quand récupérer et pour noter la pertinence et le soutien des passages récupérés. ICLR 2024. arXiv:2310.11511
9. #FLARE Jiang, Z., et al. (2023). Active Retrieval Augmented Generation. Présente FLARE : le modèle génère une continuation provisoire, identifie les jetons à faible confiance comme déclencheurs de récupération et récupère les passages pertinents pour affiner la sortie. arXiv:2305.06983