一位开发者对构建"上下文引擎"的详细分析突出了生产环境RAG团队一直在悄悄解决的问题：检索有效，但管理真正进入LLM上下文窗口的内容无效。该系统用纯Python实现，具有可测量的基准，显式控制内存、压缩、重排序和token预算——解决了原始检索和提示构建之间的差距，这正是大多数RAG实现失败的地方。

这直接对应了我在4月份报道的Karpathy放弃RAG转向LLM原生知识管理时所涉及的内容。根本问题不是检索精度——而是架构问题。RAG教程止步于"检索文档，塞进提示"，但生产系统需要对信息流做出深思熟虑的决策。当检索的上下文有6000个字符但你的预算只有1800个token，当近似重复的文档排挤掉有用的文档，当第一轮对话历史在二十轮后仍占据空间——这就是基础RAG失效的地方。

更广泛的社区正从不同角度聚焦于这个相同问题。拥有27000星标的RAG Techniques仓库强调五层架构，按顺序处理失效模式。其他开发者正在实现混合BM25+向量搜索配合交叉编码器重排序，或完全放弃RAG转向LLM维护的markdown知识库。连接这些方法的是对上下文组成的显式控制，而不是寄希望于检索+提示在规模化时能奇迹般地工作。

对于运行多轮聊天机器人或拥有大型知识库的RAG系统的团队来说，这不是理论问题。上下文管理在最初几轮对话内就成为瓶颈。选择是有意识地构建这一层，或者眼看着系统随着上下文积累而退化——这解释了为什么生产团队正在投入工程时间解决理论上应该通过更好的提示来解决的问题。