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 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. 1. 工具技术不同： AI 时代的搜索工具和传统搜索不一样了。

2. 2. 工作负载不同： 以前，搜索结果的最后一公里是人来完成的，你在一堆蓝色链接里点来点去。现在，是 LLM 在消费这些结果。

3. 3. 开发者不同： 构建搜索的开发者画像变了。

4. 4. 消费者不同： 人类只能消化 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 时代，我们一起从“炼金术士”进化为真正的“工程师”！哈哈！

  如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。 

 这份《LLM项目+学习笔记+电子书籍+学习视频》已经整理好，还有完整版的大模型 AI 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓