大模型开发必读：从RAG到上下文工程的进化之路（值得收藏）

最新推荐文章于 2025-12-22 12:57:03 发布

原创最新推荐文章于 2025-12-22 12:57:03 发布 · 818 阅读

CC 4.0 BY-SA版权

文章标签：

#机器学习 #人工智能 #开发语言 #深度学习 #大模型教程 #大模型学习 #AI

我至今还记得 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的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

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

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

一直在更新，更多的大模型学习和面试资料已经上传带到优快云的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述