#模型时代# 为什么RAG是个有害的误导术语？

Latent Space刚采访了Chroma创始人Jeff Huber，提出了一个很犀利的说法：RAG已死，上下文工程当立。英文：Long Live Context Engineering; RAG is dead。

根据Jeff Huber的观点，RAG这个术语存在三个层面的严重问题：

1. 概念混淆：把独立的事物强行捆绑

RAG全称是Retrieval-Augmented Generation（检索增强生成），Jeff指出这个术语最大的问题是"它把检索、增强、生成三个完全独立的概念硬塞进一个缩写里"。

这就像把"开车去超市买菜"简化成一个词"开超菜"，然后所有人都在讨论怎么优化"开超菜"，却忘了这其实是三件可以独立优化的事：
- 检索（Retrieval）本身就是个复杂的工程问题，涉及向量搜索、全文搜索、元数据过滤等多种技术
- 增强（Augmented）是个模糊的概念，到底是增强什么？怎么增强？
- 生成（Generation）又是另一个独立的环节，有自己的优化空间

当你把这三个东西混在一起，开发者就失去了清晰思考的能力，无法识别问题到底出在哪个环节。

2. 狭隘化理解：RAG ≠ 单一向量搜索

更糟糕的是，RAG在实践中被简化理解为"就是用一个embedding模型做向量搜索，然后把结果塞给LLM"。Jeff说："of course rag got known now as is branded as like you know oh you're just using single dense vector search and that's what rag is it's also dumb"。

这种狭隘理解导致的后果是：
- 开发者以为做好向量搜索就解决了所有问题
- 忽视了多阶段检索、重排序、上下文优化等关键环节
- 把一个系统工程问题简化成了单点技术问题

3. 缺失核心洞察：真正的问题是Context Engineering

Jeff提出，我们真正需要关注的是Context Engineering——"决定在任何LLM生成步骤中，什么内容应该出现在上下文窗口中"。

这个定义直击要害：
- 不是所有检索到的内容都应该被使用（Context Rot问题）
- 不是检索越多越好（模型注意力会下降）
- 不是一次检索就够了（可能需要持续动态检索）

Context Engineering包含内循环和外循环：
- 内循环：这一次生成，我该放什么进上下文？
- 外循环：如何基于反馈持续优化上下文选择策略？

为什么这个区别如此重要？

当你用RAG思维时，你会这样思考：
"我的RAG系统表现不好，是不是该换个更好的embedding模型？"

但当你用Context Engineering思维时，你会问：
- 我的上下文窗口里是否包含了真正相关的信息？
- 上下文的顺序和组织是否合理？
- 模型在当前上下文长度下的注意力是否已经衰减？
- 是否需要在生成过程中动态调整上下文？

这就是为什么Jeff说"现在所有成功的AI创业公司，他们唯一真正擅长的就是Context Engineering"——不是因为他们有更好的RAG系统，而是因为他们理解了如何为LLM精心策划上下文。

RAG这个术语不仅没有帮助我们理解问题，反而成为了思维的枷锁。抛弃它，拥抱Context Engineering，才能真正构建出生产级的AI应用。