长上下文没有杀死RAG：成本、延迟、可靠性三大陷阱

当模型开始一次性读取一百万个 token 时，所有人都宣称 RAG 已死。"把所有东西都丢进上下文就行了。"两年后，检索反而比以往任何时候都更加核心。以下是这场炒作错在了哪里。

这是当前应用 AI 领域最有价值的辩论之一，因为搞错了会浪费金钱并损害产品。巨型上下文窗口可以取代检索这一直觉非常直观——但大多数情况下是错误的。

诱人的论点

长上下文模型可以接受庞大的输入——整本书、整个代码库。于是推理就变成了：既然可以直接把所有东西交给模型让它自己整理，为什么还要费力构建检索管道去获取相关的片段呢？架构更简单，不需要向量数据库，不会有分块的麻烦。表面上很有说服力。

为什么"把所有东西都丢进去"会失败

三堵墙，而且你会很快撞上每一堵。

成本。 每次调用都是按 token 付费的。将大量上下文塞进每个请求比检索少量相关段落要昂贵得多。在任何实际的量级上，"把所有东西都丢进上下文"都是一个预算灾难。

延迟。 需要处理的 token 越多，响应就越慢。每个查询都使用巨大的上下文会让你的产品变得迟钝，这种迟钝用户能立即感受到。

注意力退化。 模型不会均匀地关注一个巨大的上下文——它们可靠地追踪开头和结尾，而在中间变得模糊。如果把关键事实埋在一百万个 token 的中间，模型可能会有效地忽略它。更多的上下文可能通过在噪声中淹没信号来产生更差的答案。

还有一个问题是新鲜度：你的知识在不断变化，而你无法将一个不断增长、持续更新的语料库塞进一个固定的窗口。检索允许你更新一个文档并让系统立即反映这一点。这正是我设计 AI 系统时的思考方式——获取相关的，而不是每次都拖拽所有东西。

它们是伙伴，不是竞争对手

成熟的看法不是"RAG 对比长上下文"——而是两者兼顾，各司其职。检索将一个庞大且不断变化的知识库缩小到重要的段落；然后长上下文窗口为模型提供空间来推理这些段落加上对话加上指令，而无需你斤斤计较。更大的窗口并没有杀死检索——它们通过解除过度压缩输入内容的压力，使检索变得更加有效。

更大的上下文窗口是一个更好的工作空间，而不是决定把什么带进房间的替代品。检索是你选择的方式；上下文是你推理的地方。任何告诉你长上下文会终结 RAG 的人都是在优化架构简单性，而忽略了成本、延迟以及注意力实际的行为方式。最好的系统是聪明地检索，然后很好地利用宽裕的上下文。

关于如何构建这些系统的更多内容，请访问 www.divyakush.com。

正确解释 RAG：检索如何保持 LLM 的诚实——合作伙伴中检索这一半的深入解析。