从炼金术到工程学：在AI浪潮中，我们如何告别RAG，拥抱真正的“上下文工程”？

我至今还记得 RAG（检索增强生成）这个词刚火起来时的情景。那感觉，就像是哥伦布发现了新大陆。一夜之间，所有人都成了 RAG 的信徒。它简单、直接，承诺了一个美好的未来：只要把你的私有数据“喂”给大模型，它就能无所不知、无所不晓。AI 应用开发的门槛，仿佛瞬间被夷为平地。

那时候，大家都在谈论 RAG，会议室里、技术论坛上，到处都是它的身影。它像一个万能公式，简单到只需要两个步骤：检索（Retrieval），然后生成（Generation）。听起来无懈可击。我们都沉浸在这种“灵丹妙药”式的兴奋中，以为抓住了通往 AGI 的捷径。初创公司们拿着 RAG 的故事，轻松就能拿到融资；开发者们用着 LangChain 或者 LlamaIndex，几行代码就能搭出一个看起来很酷的 Demo。

那是一个充满希望的“淘金热”时代，而 RAG，就是我们手里最时髦的铁锹。

但正如所有被过度神化的概念一样，当我们真正拿着这把铁锹深入挖掘时，才发现事情远没有那么简单。Chroma 的创始人 Jeff Huber 在那次 Latent Space 的采访中，用了一个词来形容 RAG——“糟糕”（awful）。这个词像一盆冷水，浇醒了许多沉浸在狂热中的人，也包括我。

他说，RAG 是个糟糕的抽象，因为它把检索、生成、结合这三个完全不同的概念硬生生地捆绑在一起，结果让所有人都感到困惑。更糟糕的是，市场把 RAG 简化成了一个极其肤浅的操作：“用 Embedding 做一次向量搜索”。

这番话让我醍醐灌顶。我们确实被这个时髦的缩写绑架了。我们开始忽略构建一个真正可靠系统背后那些最关键、最困难的问题。Jeff 形容当时的状态像是在玩“炼金术”。他描绘了一个生动的画面：一个人站在一堆冒着热气的垃圾前，当被问及这是否就是他的数据系统时，他回答“是”。再问他怎么知道这系统好不好，怎么让它更好？他只会说，“你就随便搅一搅，然后看看会不会变好。”

这不就是我们当时很多人的真实写照吗？我们把所有的文档切块、做 Embedding，然后一股脑地扔进向量数据库。当用户提问时，我们进行一次相似度搜索，把最靠前的几个片段塞给大模型，然后祈祷它能给出一个靠谱的答案。当效果不好时，我们就开始“玄学调参”：调整 chunk size，换个 Embedding 模型，或者修改一下 Prompt。我们确实在“随便搅一搅”，期待奇迹发生。

我们忽略了，从一个看起来能跑的 Demo 到一个真正稳健的生产级应用之间，横亘着一条巨大的鸿沟。而 RAG 这个过于简化的概念，恰恰掩盖了这条鸿沟的深度和宽度。

就在我们对 RAG 的“炼金术”感到迷茫时，Jeff 提出了一个更精确、也更具工程思维的词：上下文工程（Context Engineering）。

这个词瞬间击中了我。它不再是一个含糊的打包方案，而是一门严谨的学科。Jeff 给它的定义清晰而深刻：“上下文工程的任务，就是在每一步生成时，决定上下文窗口里应该放什么。”

这才是问题的核心。大语言模型就像一个记忆力超群但注意力有限的天才，它能处理的信息量是惊人的，但你不能把全世界的图书馆都塞到它面前，指望它瞬间找到你想要的那句话。你必须像一个图书管理员一样，精准地把最相关的那几本书、那几页纸递给它。这个“递书”的过程，就是上下文工程。

Jeff 进一步把它拆解为两个循环：

•内循环：在单次生成中，如何从海量信息中，精准地挑选出最关键的内容放进当前的上下文窗口。

•外循环：随着时间的推移和与用户的交互，系统如何学习，如何变得越来越擅长挑选信息，从而不断优化内循环的效果。

这个概念的提出，标志着我们开始从一种“黑箱思维”转向一种“白箱思维”。我们不再把希望寄托于“搅一搅”，而是开始像真正的工程师一样，去设计、度量和优化那个至关重要的“上下文”。

我立刻想起了那些业界顶尖的 AI 应用，无论是 Perplexity AI 的精准回答，还是 Cursor 的智能代码补全。它们之所以体验出色，本质上不就是因为它们在上下文工程上做到了极致吗？它们总能在最恰当的时机，把最准确的信息——无论是网络搜索结果、代码库片段，还是历史对话——喂给模型。

这才是它们真正的护城河。Jeff 一针见血地指出：“现在所有你能想到的，做得比较好的 AI 初创公司，他们真正擅长、最核心的一件事就是上下文工程。”

要理解上下文工程为什么如此重要，就必须先理解一个残酷的现实：上下文腐烂（Context Rot）。

在很长一段时间里，各大模型厂商都在宣传它们超长的上下文窗口，从几千个 Token 一路卷到上百万，甚至上千万。它们发布的那些“大海捞针”测试图表，几乎都是一条完美的直线，仿佛在告诉我们：别担心，把所有东西都扔进来吧，我的模型能搞定一切。

但现实是，这是一个美丽的谎言。Chroma 发布的那份关于 Context 的技术报告，无情地揭示了真相：随着上下文窗口中 Token 数量的增加，LLM 的性能会显著下降。模型会变得“注意力不集中”，推理能力会变弱，甚至会直接忽略掉你明确给出的指令。

这就好比在一个嘈杂的派对上，你试图和一个朋友进行深度对话。当周围只有三五个人时，你们交流顺畅；但当房间里挤满了一百个人，每个人都在大声说话时，即使你的朋友听力再好，也很难捕捉到你话语里的所有细节和深意。

“上下文腐含”就是大模型的“派对噪音问题”。当上下文窗口被无关或低相关度的信息填满时，那些真正关键的“信号”就被淹没在了“噪音”之中。模型的性能不是线性提升，反而在某个临界点之后开始腐烂。

这也就解释了，为什么简单粗暴地把所有东西都塞进上下文窗口的做法，往往效果很差。这不仅是成本和效率的问题，更是质量的问题。缓存（Caching）可以解决一部分效率问题，但它无法解决上下文腐烂带来的质量下降。

因此，上下文工程的核心挑战，变成了一个经典的优化问题：如果你有一万个候选信息片段，但上下文窗口里只有二十个空位，你如何能确保放进去的是最精华、最相关的那二十个？

那么，这门新兴的“手艺”具体是怎么做的呢？它不是单一的技术，而是一个工具箱，一种组合拳。

Jeff 在访谈中提到了一个非常普遍且有效的模式：多阶段检索（Multi-stage Retrieval）。

这就像我们自己找资料的过程。比如，我想写一篇关于“文艺复兴时期佛罗伦萨的艺术”的文章。我不会直接去读完整个图书馆的所有书。

第一步，我会进行粗筛。我会先用一些快速的方法，把候选范围缩小。我可能会用图书馆的检索系统，搜索“文艺复兴”、“佛罗伦萨”、“艺术”这几个关键词（类似全文搜索）；或者，我也会找找那些带有“艺术史”标签的书架（类似元数据过滤）；我还可能凭感觉，找那些看起来最相关的书籍（类似向量搜索的语义相似度匹配）。通过这一步，我可能从几万本书里，圈定了三百本候选书。

第二步，我会进行精排。现在，我需要在这三百本书里，找出最核心的二三十本。我会快速翻阅这三百本书的目录、前言和索引，判断它们和我主题的真正相关性。这个过程，就像是让一个更强大的“模型”（我自己的大脑）对候选集进行重新打分和排序（Re-ranking）。

AI 应用中的上下文工程，也是同样的道理。第一阶段，用向量搜索、全文搜索、元数据过滤等高效的手段，从海量数据中快速召回几百个候选片段。第二阶段，再调用一个大模型（甚至可以是专门的 re-rank 小模型），对这几百个候选片段进行更精细的打分和排序，最终选出最精华的部分，喂给负责最终生成的那个核心模型。

我看到很多顶尖团队都在实践这种思想。他们甚至会用 Prompt 来让大模型本身充当一个出色的“重排器”。Jeff 预测，随着大模型变得越来越便宜，这种“暴力美学”式的重排会成为主流。专门的 re-rank 模型或许不会消失，但会像 ASIC 或 FPGA 一样，只在那些对成本和性能要求极致的场景下才会使用。

更重要的是，上下文工程的工具箱里，不只有这些时髦的新工具。Jeff 提到，像**正则表达式（Regex）**这种“老古董”，在代码搜索这类特定场景下依然极其有效。谷歌和 GitHub 的代码搜索，主力就是正则。

这给了我很大的启发：真正的工程思维，不是盲目追新，而是深刻理解每一种工具的边界和适用场景，然后像一个匠人一样，把它们巧妙地组合在一起，去解决实际问题。Embedding 擅长处理语义的模糊性，而正则则能提供无与伦比的精确性。它们不是替代关系，而是互补关系。

这次访谈最让我着迷的，是 Jeff 对未来的思考。他认为，我们今天的做法，在五到十年后回头看，可能会显得“非常粗糙，甚至有点好笑”。

他畅想了未来检索系统的几个可能性：

第一，停留在潜在空间（Latent Space）。现在我们把文本转成向量（Embedding），检索完之后，再把结果转回文本给大模型。这个“来回翻译”的过程，既损耗信息又效率低下。为什么不能让模型直接在那个充满丰富语义的向量空间里工作呢？这就像我们不需要把脑海中的想法一字一句说出来再给自己听一遍，才能进行下一步思考一样。

第二，持续检索（Continuous Retrieval）。今天的模式是“一次检索，一次生成”。我们先搜集好所有资料，然后一口气写完文章。但更自然的方式，难道不应该是“边写边查”吗？当模型生成到某个节点，发现信息不足时，它应该能主动地、实时地去检索新的信息来补充上下文。最近已经有一些相关的研究，比如教模型在内部推理时自己决定何时去检索。这让模型从一个被动的“信息消费者”，变成一个主动的“信息探索者”。

这些想法让我意识到，我们目前对大模型的利用方式，还处在非常初级的阶段。我们把它当成一个黑箱，从外部给它喂数据。而未来的方向，一定是把检索、记忆这些能力，更深度地内化到模型自身的结构和工作流中去。

这也引出了他对“记忆”的看法。Jeff 认为，“记忆”这个词很好，因为它通俗易懂，但它的本质，依然是上下文工程。所谓的长期记忆、短期记忆，最终都要落实到“在恰当的时机，把合适的信息放入上下文窗口”这个问题上。我们不必被各种花哨的记忆类型、信息图谱所迷惑。

他提到了一个更朴素也更有力的概念：压缩（Compression）。这就像我们电脑的磁盘碎片整理，或者数据库的索引重建。系统可以在后台，通过离线的计算和推理，不断地对已有的信息进行整理、合并、提炼、总结，从而让未来的检索更高效、更精准。这听起来没有“人工梦境”或者“睡眠周期”那么性感，但它是一个真正经过时间检验的、来自计算机科学的工程智慧。

访谈的最后，话题从技术转向了创业哲学和个人信仰。这部分内容，让我对 Jeff 和 Chroma 这家公司有了更深的理解。

他说，创业有两种流派。一种是精益创业，不断追逐用户的反馈，哪里有需求就去哪里。但这种方式的风险是，你最终可能会做出一款“给初中生用的约会软件”，因为它迎合的是最底层、最直接的需求。

而他选择了第二种流，派：坚持一个非常坚定的、甚至是逆势的观点，然后疯狂地专注去做。

Chroma 的发展路径完美地诠释了这一点。在向量数据库赛道最火热、所有人都急着融资、抢占市场的时候，他们却选择放慢脚步，花了很长时间去打磨他们的云产品 Chroma Cloud。因为他们不想为了速度，而牺牲掉他们最看重的“卓越的开发者体验”。

Jeff 说：“你做一件事的方式，其实就是你做所有事的方式。” 这句话深深地打动了我。从 Chroma 简洁的 API（​​pip install chromadb​​），到他们设计精美的网站和文档，再到他们高信息密度的技术报告，处处都体现出一种对细节、对品质、对工艺水准（Craftsmanship）的极致追求。

这种追求，源于创始人自身的品味和坚持。他认为，创始人必须是公司的“品味把关人”，确保公司的文化、产品和品牌拥有一致的灵魂。

最后，他谈到了人生。他说人生短暂，如风中烟雾，所以应该只去做自己真正热爱的事，只和自己喜欢的人共事，只服务自己真心想服务的客户。他谈到了人类的繁荣，谈到了那些需要几个世纪才能完成的工程，比如巴塞罗那的圣家堂。

那一刻我明白了，他们之所以如此在意上下文工程的细节，之所以愿意花巨大的精力去打磨一个看似简单的数据库，并不仅仅是为了商业上的成功。在这一切背后，有一种更宏大的愿景在驱动着他们：把 AI 应用的开发，从充满不确定性的“炼金术”，变成一门严谨、可靠、甚至优雅的“工程学”。

他们想种下的，是一棵自己或许无法完全看到它枝繁叶茂的大树。

回望 RAG 的兴衰，再到上下文工程的崛起，我看到的不仅仅是技术概念的迭代，更是一种思想的进化。我们正在告别那个充满泡沫和炒作的“淘金热”时代，走向一个更成熟、更理性的“大航海”时代。前路依然充满未知，但我们手中的罗盘，已经变得前所未有的清晰。

本文转载自​​芝士AI吃鱼​​，作者：芝士AI吃鱼