我要投稿

RAG 已死，上下文工程当立

发布日期：2025-08-23 17:06:14 浏览次数： 1964

作者：BubbleBrain

微信搜一搜，关注“BubbleBrain”

朋友们好，今天给大家带来最新的 Latent Space 的一期播客的内容，这期内容非常有价值，跟当下最火的概念，上下文工程，息息相关。同时内容里也提到了 RAG，Memory 等这些非常核心的要素。

他们采访的对象是 Chroma 的创始人，Jeff Huber, 来分享一些他的观点。

原视频地址：

https://www.youtube.com/watch?v=pIbIZ_Bxl_g

另外，这里介绍一下 Chroma。做过 AI 应用开发，特别是 RAG的同学应该不是很陌生，Chroma 是一个开源的向量检索数据库，提供 AI 应用所需要的向量检索+关键词全文检索+正则+元数据过滤的一体化方案。可以本地嵌入式运行，也可连到托管的 Chroma 云端上。

所以，作为 Chroma 的创始人，Jeff 分享的内容还是很值得一看的。我对此进行了一些整理，希望大家理解起来更加方便一些。

那，我们现在开始。

1.上下文工程：AI 时代的核心技能

对于最近很火的上下文工程，Jeff 将其定义为：在任何给定的LLM 生成步骤中，精确决定上下文窗口应包含何种信息的任务。

这里包含了两个循环，Jeff 认为一个是内循环，决定当前这一步中，应该塞入哪些内容给到模型作为上下文，还有一个是外循环，随着对话次数的增加、时间的积累，逐渐要让模型选择最相关的信息。

他甚至批评 RAG 这一个术语，认为它将检索、增强、生成三个概念硬拼在一起，且常被误解为只做单次的向量检索。Jeff 自己说他是从来不用 RAG 这个词汇的。

「emmm..确实是这样，做过 RAG 项目的同学其实都有经验，RAG 中最重要的就是检索这一环节，如果检索内容都出现问题了，后面的增强、生成都是白扯，所以 RAG 其实就是只有检索这一part」

Chroma 通过研究，发现当前的 AI 应用中存在着严重的上下文腐烂的问题。当模型的上下文窗口中存在着更多 Token 时，模型的注意力会下降，推理能力也会随之减弱。对于当前前沿模型声称能够完美利用百万级 Token 上下文窗口的说法，Jeff 也保持着怀疑的态度。Chroma 的报告显示，许多模型在长上下文的场景中的性能并不理想。

「作为一个经常评测各大模型的博主，这点真的深有同感。很多模型虽然声称虽然有 256k 甚至 1M 的上下文窗口，但是长上下文表现非常不理想。推荐阅读 MinMax 的长上下文评测：DeepSeek用户看过来：这个开源模型的上下文是它的15倍，还能思考80k字" data-itemshowtype="0" linktype="text" data-linktype="2">DeepSeek用户看过来：这个开源模型的上下文是它的15倍，还能思考80k字」

为了解决这些问题，Jeff 同样分享了上下文工程中的实用策略：

两阶段检索范式：首先进行第一阶段检索（向量、全文、元数据检索），从海量候选数据中快速筛选出少量相关数据。随后将这些初步筛选结果交给 LLM 作为重排序器进行精细筛选。随着 LLM 变得更快，更便宜，Jeff 认为以往专用的重排序模型将逐渐被 LLM 替代。
代码上下文优化：代码是一种特殊的上下文。Chroma 原生支持 Regex （正则表达式搜索）并引入了独特的Forking 功能，用户可以再百毫秒内创建现有索引的副本，从而高效地对不同 git 提交、分支或发布标签的代码库进行重索引和搜索。当然，千万不要神化 embedding，regex 仍然解决 85%-90% 的查询，embedding 通常还能带来 5-15% 的额外增益，所以这套组合拳才是实际项目工程中的最优解。

「Claude Code 包括 Cline 这类代码 Agent其实专门说过一个点是，它们从来不对代码做 Embedding或索引，而是直接通过调用工具的方式来做代码搜索。推荐可以看下我写的这篇分享: Claude烧钱，Cline更烧钱，但聪明的开发者都在抢着用｜ Cline 博客分享Jeff 其实是认为拿代码来做 Embedding 还非常的早期，可能现在的代码库我们使用 Regex 就能解决大部分的问题，但是Embedding 还能在这之上带来更好的效果。」
数据预处理与信号增强：Jeff 强调，在数据读取并处理的时候，要尽可能地提取并注入结构化信息和元数据。例如，通过 Chunk Rewriting 技术，让 LLM 为代码生成自然语言描述，然后将这些描述与代码本身一同embedding 或者单独做 embedding 处理。
构建黄金数据集的重要性：Jeff 指出，构建小型、高质量的数据集对于量化评估和持续改进系统非常重要。许多团队都是有文档、有答案、就是没有用户的查询，导致无法量化检索的优劣。正确的做法是：使用 LLM 为你的语料自动生成 query-chunk 对，得到小而精的评测集，用它来权衡召回，精度，成本，可用性再稳步迭代。实践证明：几百条高质量的评估集，能带来巨大的回报。