详细内容或原文请订阅后点击阅览
RAG 还不够——我构建了使 LLM 系统正常运行的缺失上下文层
大多数 RAG 教程侧重于检索或提示。当上下文增长时，真正的问题就开始了。本文展示了一个用纯 Python 构建的完整上下文工程系统，该系统控制内存、压缩、重新排名和代币预算 - 因此 LLM 在实际约束下保持稳定。 帖子 RAG 不够 - 我构建了使 LLM 系统工作的缺失上下文层首先出现在《走向数据科学》上。
来源:走向数据科学TL;DR
纯 Python 中的完整工作实现，具有真实的基准数据。
当上下文增长超过几个回合时，RAG 系统就会崩溃。
真正的问题不是检索——而是实际进入上下文窗口的内容。
上下文引擎显式控制内存、压缩、重新排序和令牌限制。
这不是一个概念。这是一个具有可测量行为的工作系统。
RAG 系统的突破点
我构建了一个运行完美的 RAG 系统 - 直到它不起作用。
当我添加对话历史记录时，一切都开始崩溃。相关文件被丢弃。提示溢出了。该模型开始忘记两轮前说过的话。不是因为检索失败。不是因为提示写得不好。但因为我对实际进入上下文窗口的内容的控制为零。
这是没人谈论的问题。大多数 RAG 教程都停留在：检索一些文档，将它们填充到提示中，调用模型。如果检索到的上下文为 6,000 个字符，但剩余预算为 1,800 个字符，会发生什么情况？当您检索到的五份文档中的三份几乎重复，从而挤掉了唯一有用的文档时，会发生什么情况？当二十轮对话中的第一轮仍然坐在提示中，占据空间，而在它不再相关很久之后，会发生什么？
这些并不是罕见的边缘情况。这就是默认情况下发生的情况——并且它在最初的几个回合内就开始破裂。
以下所有结果均来自系统的实际运行（Python 3.12，仅 CPU，无 GPU），除非计算结果另有说明。
答案是大多数教程完全跳过的一层。在原始检索和快速构建之间，有一个深思熟虑的架构步骤：决定模型实际看到的内容、看到的内容以及顺序。 2025 年，Andrej Karpathy 给它起了一个名字：上下文工程 [2]。我已经构建它几个月了，但没有这么称呼它。
这是我构建的系统，从检索到内存再到压缩，使用实数和可以运行的代码。