干货收藏 | RAG已死？顶级开源数据库创始人揭秘上下文工程新范式

最新推荐文章于 2025-11-07 16:56:23 发布

原创最新推荐文章于 2025-11-07 16:56:23 发布 · 657 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #大模型入门 #大模型学习 #大模型 #RAG #LLM #AI大模型

前言

AI 时代，人只分两种：
一种，是被噪音吞噬的“信息流食者”；
另一种，是驾驭 AI、以思想为利刃的 “未来拓荒者”。

今天必须给大家安利一篇 latent.space 中信息密度爆炸的文章。作者是 Jeff Huber，顶级开源向量数据库 Chroma 的创始人和 CEO。

先介绍下 Chroma，如果你在玩 AI 应用，特别是 RAG，那你不可能不知道它。Chroma 凭借其超赞的开发者体验（pip install 就能跑，还要啥自行车 🚲），已经成为无数 AI 项目的首选，月下载量超过 500 万，GitHub star 数 22k+，可以说是向量数据库领域的开源霸主。连大名鼎鼎的 Voyager 论文里用的都是它。

最近，Jeff Huber 抛出了一个极其劲爆的观点：“RAG 已死”。

什么鬼？

我们辛辛苦苦学了半天的 RAG，怎么说死就死了？

别急，Jeff 接下来给出了他的新答案：上下文工程（Context Engineering）为王。

随着大模型上下文窗口越来越长，AI 的工作负载也从简单的聊天机器人转向了更有影响力的 Agent，那个曾经被我们忽视的“上下文窗口”，现在成了兵家必争之地。

这篇文章，就是 Jeff 对这个问题的深度思考和实战总结。干货满满，准备好你的小本本，我们发车了！🚀

⚡️ 先上结论：Jeff Huber 的 5 个独家检索秘诀

Jeff 开篇就直接甩出了 5 个搞检索（Retrieval）的独家秘诀，全是硬菜，朋友们拿好不谢！

✅ 别再说你做的是 “RAG” 了，咱们要做的是“检索”（Retrieval）。 把基础概念搞清楚：密集检索（dense）、词法检索（lexical）、过滤（filters）、重排（re-rank）、组装（assembly）、评估循环（eval loop），这才是专业的玩法。

✅ 第一阶段，用混合召回（hybrid recall）搞定。 别怕给 LLM 太多候选内容，它又不是人，阅读能力超强。先捞个 200-300 个候选结果出来，完全没问题。

✅ 把上下文（context）组装起来之前，一定要先重排（re-rank）！ 这是铁律，能极大提升最终生成质量。

✅ 尊重“上下文腐烂”（Context Rot）这个事实。 精简、结构化的上下文，远比塞满整个窗口的冗长上下文效果好得多。后面会详细讲这个。

✅ 跟团队一起搞个小小的黄金数据集（gold set）。 然后把它接入到你的 CI 和 Dashboard 里，持续评估，这比你瞎猜强一万倍。

🧠 一个完整的上下文工程流水线

Jeff 不光给出了心法，还给了一套完整的操作流程图，从数据摄入到查询再到外循环优化，非常清晰。

数据摄入（Ingest）

• 解析 + 分块 (Parse + chunk): 要懂你的业务领域，比如按标题、代码块、表格来切分。
• 丰富信息 (Enrich): 加上标题、锚点、符号、元数据这些。
• 可选：LLM “块摘要” (LLM “chunk summaries”): 用自然语言给代码或者 API 写个总结。
• 嵌入 (Embeddings): 生成密集向量（dense），也可以加上稀疏信号（sparse signals）。
• 写入数据库 (Write to DB): 把文本、向量、元数据都存进去。

查询（Query）

• 第一阶段混合检索 (First-stage hybrid): 向量 + 词法/正则 + 元数据过滤，一把梭。
• 候选池 (Candidate pool): 大概捞个 100-300 个候选。
• 重排 (Re-rank): 用 LLM 或者 cross-encoder 模型来重排，选出最好的 20-40 个。
• 上下文组装 (Context assembly):

• 指令/系统提示（system prompt）放最前面。
• 去重，合并相似内容。
• 来源多样化。
• 严格控制 Token 上限。

外循环优化（Outer loop）

• 缓存/成本控制 (Cache/cost guardrails): 别把钱烧光了。
• 基于黄金集做生成式基准测试 (Generative benchmarking): 后面会讲这个神器。
• 错误分析 (Error analysis): 回过头去重新分块、调整过滤器或者重排的 prompt。
• 记忆/压缩 (Memory/compaction): 把交互历史总结成可检索的事实。

为什么要做 Chroma？从“炼金术”到“工程学”

聊到为啥要创办 Chroma，Jeff 的回答很有意思。

他说，在 AI 领域，搞个 demo 很容易，但要做一个生产级的、可靠的系统就难于上青天。从 demo 到生产的鸿沟，感觉不像是在搞工程，更像是在搞炼金术（alchemy）。

他提到了一个经典的 XKCD 梗：一个人站在一堆冒着热气的垃圾上，别人问他：“这是你的数据系统？” 他说：“是啊。” “你怎么知道它好不好用，怎么改进它？” “哦，就搅和搅和，看看会不会变好一点。” 哈哈，是不是画面感十足？

Jeff 觉得这太扯了。所以 Chroma 的使命，就是想帮助开发者用 AI 构建生产级应用，让这个过程更像工程，而不是炼金术。

别再傻傻分不清：信息检索 vs. 搜索

Jeff 认为，我们正在为 AI 构建的是“现代搜索基础设施”（modern search infrastructure for AI）。这个“为 AI” （for AI）体现在四个不同层面：

1. 工具技术不同： AI 时代的搜索工具和传统搜索不一样了。
1. 工作负载不同： 以前，搜索结果的最后一公里是人来完成的，你在一堆蓝色链接里点来点去。现在，是 LLM 在消费这些结果。
1. 开发者不同： 构建搜索的开发者画像变了。
1. 消费者不同： 人类只能消化 10 个蓝色链接，但 LLM 可以消化成千上万个。

这个洞察太关键了！消费者的改变，从根本上决定了系统的设计。

核心痛点：烦人的“上下文腐烂”（Context Rot）

这部分是全文的精华！

很多模型厂商都在吹牛，搞各种“大海捞针”（needle in a haystack）测试，图表做得一片绿，告诉你他们的模型在百万 Token 上下文里也能完美利用。

但 Jeff 和他的团队通过研究发现了一个残酷的现实：上下文腐烂（Context Rot）。

简单说，就是当你往上下文窗口里塞的 Token 越来越多时，模型的性能并不会保持不变，反而会下降。模型会开始忽略一些指令，推理能力也会变差。

Chroma 最近发布的技术报告《Context Rot》就详细阐述了这个问题。他们发现，即使是市面上最强的模型，随着上下文长度增加，性能都会出现明显衰减。

所以，朋友们，别再迷信无限上下文了。上下文工程的核心，就是要在“腐烂”发生前，把最精华、最相关的信息挑出来，喂给模型。

记忆的本质：上下文工程的终极福利

我们总说要给 AI 加上“记忆”（Memory）。在 Jeff 看来：

• 记忆（Memory）是目的，是收益。
• 上下文工程（Context Engineering）是实现这个目的的工具。

无论是短期记忆、长期记忆，还是所谓的“离线压缩”（Offline Compaction）和“睡眠计算”（sleep time compute），本质都是在解决“如何在正确的时间，把正确的信息放进上下文窗口”这个问题。

破局之道：生成式基准测试（Generative Benchmarking）

那怎么知道我的上下文工程做得好不好呢？靠感觉吗？

当然不是！Jeff 团队的另一份技术报告《Generative Benchmarking》给出了答案。

很多时候，我们有大量的文档（也就是答案），但我们没有与之对应的问题（查询）。这份报告的核心思想就是：用 LLM 来从你的文档（chunks）中生成高质量的问题（queries），从而自动创建出“问题-答案”对，构成你的黄金测试集。

一旦有了这个黄金数据集，你就可以定量地评估你的检索策略了。比如：

• 换个 embedding model，召回率从 80% 提升到了 90%，好，那就换！
• 调整一下分块策略，成本没变，速度快了 20%，好，那就调整！

这个方法，直接把“炼金术”变成了可以量化、可以迭代的“工程学”。

针对代码场景的思考

Jeff 也分享了在代码这种特殊场景下的检索策略。

• Regex（正则表达式）依然是王道。 在你知道你要找什么的时候（比如在你的项目中找 cap table 这个文件），词法搜索非常高效。Jeff 透露，Chroma 已经原生支持了高性能的 Regex 搜索。
• Embedding 是补充。 当你不知道具体文件名，只能模糊描述时（比如“那个存了所有投资人列表的电子表格”），语义搜索就能派上用场。
• 代码的 Embedding 仍有巨大潜力。 Jeff 认为现在大家对代码的 embedding 使用还非常初级，比如可以先用 LLM 给代码生成一段自然语言描述，再去 embedding 这段描述，效果可能会更好。

写在最后

听完 Jeff 的分享，我感觉脑子里的很多概念一下就清晰了。

AI 时代，我们不能再满足于做一个只会拼装、把所有东西都塞进上下文的“黑盒玩家”。我们需要像 Jeff 一样，深入到底层，去理解每个环节的原理和 trade-off。

从“RAG”到“上下文工程”，这不仅仅是一个名词的变化，更是一种思维模式的升级。它要求我们从一个被动的“信息投喂者”，转变为一个主动的“上下文建筑师”。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

在这里插入图片描述

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。
在这里插入图片描述
最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。