RAG et ingénierie de contexte : révolutionner les LLM

Les défis des systèmes RAG

Les systèmes de génération augmentée par récupération, connus sous le nom de RAG, rencontrent des difficultés importantes lorsque le contexte d'une conversation s'étend au-delà de quelques échanges. Le véritable problème ne réside pas dans la récupération des informations pertinentes, mais dans la gestion de ce qui est effectivement inclus dans la fenêtre de contexte. Un moteur de contexte est essentiel pour contrôler la mémoire, la compression, le réajustement et les limites de tokens.

Le point de rupture des systèmes RAG

J'ai personnellement construit un système RAG qui fonctionnait de manière impeccable jusqu'à ce que l'historique de conversation soit intégré. À ce moment-là, le système a commencé à se dégrader. Des documents pertinents étaient écartés, le prompt débordait, et le modèle commençait à oublier des éléments mentionnés seulement deux échanges auparavant. Ce problème n'était pas dû à une récupération défaillante ou à un prompt mal formulé, mais à un manque de contrôle sur les informations intégrées dans la fenêtre de contexte.

Ces situations ne sont pas rares. Par exemple, lorsque le contexte récupéré atteint 6 000 caractères, mais que le budget restant est de 1 800, ou lorsque trois des cinq documents récupérés sont des quasi-duplicatas, écartant le seul document utile. Que se passe-t-il lorsque le premier échange d'une conversation de vingt échanges reste dans le prompt, occupant de l'espace, longtemps après avoir cessé d'être pertinent ?

Ce qui manque dans les tutoriels

La réponse réside dans une couche que la plupart des tutoriels omettent complètement. Entre la récupération brute et la construction du prompt, il y a une étape architecturale délibérée : décider de ce que le modèle voit réellement, combien de cela, et dans quel ordre. En 2025, Andrej Karpathy a donné un nom à cela : ingénierie de contexte. J'avais construit cela pendant des mois sans l'appeler ainsi.

Ce qu'est réellement l'ingénierie de contexte

Il est crucial de bien comprendre les termes, car ils peuvent prêter à confusion.

• Ingénierie de prompt : l'art de ce que vous dites au modèle — votre prompt système, vos exemples en few-shot, vos instructions de format de sortie. Cela façonne la façon dont le modèle raisonne.

• RAG : une technique pour récupérer des documents externes pertinents et les inclure avant la génération. Cela ancre le modèle dans des faits sur lesquels il n'a pas été formé.

• Ingénierie de contexte : la couche intermédiaire — les décisions architecturales concernant les informations qui entrent dans la fenêtre de contexte, combien de cela, et sous quelle forme. Elle répond à la question : étant donné tout ce qui pourrait aller dans ce prompt, que devrait-on réellement y inclure ?

Ces trois éléments sont complémentaires. Dans un système bien conçu, chacun a un rôle distinct.

Architecture complète du pipeline

Un pipeline complet d'ingénierie de contexte pour les systèmes RAG combine récupération, gestion de la mémoire, compression et contrôle du budget de tokens pour construire des applications LLM efficaces et évolutives.

Composant 1 : Le récupérateur

La plupart des implémentations RAG choisissent une méthode de récupération et s'arrêtent là. Le problème est qu'aucune méthode unique ne domine tous les types de requêtes.

• Correspondance de mots-clés : rapide et précise pour des termes exacts.
• TF-IDF : gère le poids des termes.
• Embeddings vectoriels denses : capturent les relations sémantiques que les mots-clés manquent complètement.

Le récupérateur prend en charge trois modes : mots-clés, tfidf, et hybride. Le mode hybride exécute les deux méthodes et mélange leurs scores avec un poids réglable.

Composant 2 : Le réajusteur

La récupération vous donne des candidats. Le réajusteur décide de l'ordre final. Il applique une somme pondérée à deux facteurs, mélangeant le score de récupération avec une valeur d'importance basée sur des tags.

Composant 3 : Mémoire avec déclin exponentiel

C'est le composant que la plupart des tutoriels omettent complètement, et celui où les systèmes naïfs s'effondrent le plus rapidement. La mémoire conversationnelle a deux modes de défaillance : oublier trop vite ou oublier trop lentement. La solution est le déclin exponentiel, où les échanges s'estompent continuellement en fonction de trois facteurs.

Budget de tokens sous pression

Comment le budget de tokens est distribué à travers les échanges est crucial pour maintenir l'efficacité du système.