L'analyse détaillée d'un développeur sur la construction d'un « moteur de contexte » met en lumière ce que les équipes RAG en production ont discrètement résolu : la récupération fonctionne, mais gérer ce qui entre réellement dans la fenêtre de contexte du LLM, ça marche pas. Le système, implémenté en Python pur avec des benchmarks mesurables, contrôle explicitement la mémoire, la compression, le re-classement et les budgets de tokens — s'attaquant au fossé entre la récupération brute et la construction de prompts où la plupart des implémentations RAG échouent.

Ça correspond directement à ce que j'ai couvert quand Karpathy a abandonné RAG pour une gestion des connaissances native LLM en avril. Le problème fondamental, c'est pas la précision de récupération — c'est architectural. Les tutoriels RAG s'arrêtent à « récupère des documents, fourre dans le prompt », mais les systèmes en production ont besoin de décisions délibérées sur le flux d'information. Quand le contexte récupéré fait 6 000 caractères mais ton budget est de 1 800 tokens, quand des documents quasi-identiques évincent les utiles, quand l'historique de conversation du premier tour occupe encore de l'espace vingt tours plus tard — c'est là que RAG de base casse.

La communauté plus large converge sur ce même problème sous différents angles. Le repository RAG Techniques avec 27 000 étoiles met l'accent sur des architectures à cinq couches qui gèrent les modes d'échec séquentiellement. D'autres développeurs implémentent une recherche hybride BM25 + vectorielle avec re-classement cross-encoder, ou abandonnent complètement RAG pour des bases de connaissances markdown maintenues par LLM. Ce qui relie ces approches, c'est le contrôle explicite sur la composition du contexte plutôt que d'espérer que récupération + prompting vont somehow marcher à grande échelle.

Pour les équipes qui font tourner des chatbots multi-tours ou des systèmes RAG avec de grandes bases de connaissances, c'est pas théorique. La gestion du contexte devient le goulot d'étranglement dès les premiers tours de conversation. Le choix, c'est construire cette couche délibérément ou regarder ton système se dégrader pendant que le contexte s'accumule — ce qui explique pourquoi les équipes en production investissent du temps d'ingénierie dans ce qui devrait théoriquement être résolu par un meilleur prompting.