人们一直在为 RAG 写讣告。你现在可能已经看到相关的头条新闻了：长上下文窗口终结了它；智能体（Agents）取代了它；整个模式已经过时了。事实真相更为细分，也更为实用。RAG 并未死亡。真正坍塌的是一种舒适的幻觉——即认为你只需将一堆文档切分成块，喂进向量数据库，就能突然拥有一套可靠、真实的 AI。
几年前，这种推销方案因其简单而具有诱惑力：嵌入你的知识库，将其连接到 LLM，提出问题，然后看着模型仅利用检索到的数据进行回答。对于受控的演示和小型 FAQ 机器人来说，这确实有效。比如一份二十页的帮助台手册，或者一个整洁的内部维基。机器人或多或少能引用正确的段落，领导层也会批准这类试点项目。但试点项目并不等同于生产环境。原型产品并不包含真实业务运营留下的伤痕。
生产环境的数据是杂乱无章的。它包含在十几个文件中重复出现的同一条故障排除笔记，每个文件的时间戳略有不同，状态标签也相互冲突。它包含跨页延伸的复杂表格，当分割器从中间切断它们时，会产生毫无意义的内容。它毫不避讳地保留着矛盾：2023 年的政策手册说的是一套，2024 年 3 月的修正案说的又是另一套，而旧的 PDF 从未被存档。这种“分块、存储、检索”的天真模式将每个段落都视为一座孤岛。它对层级结构、版本历史或冲突解决毫无感知。模型的幻觉并非因为 LLM 坏了，而是因为它接收到的上下文是碎片化的、孤立的，或者根本就是错误的。
一些观察家声称，百万级 token 的上下文窗口让检索变得无关紧要。他们的论点很直接：直接将整个语料库丢进提示词（prompt），让模型全部阅读即可。这听起来很优雅，但也危险地乐观。模型在技术上可能确实能够摄取相当于一部短篇小说的文本量，但在那片广袤的文本中定位一个特定的条款，则是完全不同的能力。针在草堆里依然难以寻觅。长上下文窗口扩大了可用的画布，但它们并没有解决“决定什么内容值得留在画布上”这一艰巨任务。问题从来不仅仅是检索，而是——且始终是——上下文组装（context assembly）。
从天真检索到上下文工程
到了 2026 年，这个领域正在趋于成熟。我们正在跨越将 RAG 视为单一线性流水线的阶段，转向一种将上下文视为经过精心设计的“产品”的架构。
混合搜索优于纯语义搜索。 语义相似度在理解意图方面表现出色，但在处理精确标识符时却显得粗糙。如果工程师查询特定的错误代码（如 ERR_CONNECTION_REFUSED）或软件版本（如 v3.2.1），纯向量搜索可能会在大量概念相似但实际无关的结果海洋中稀释掉精确匹配的结果。这里的演进路径很明确：现代系统将稠密向量检索与关键词搜索相结合，在利用嵌入（embeddings）的同时，配合使用 BM25 或倒排索引等方法。精确的名称、错误代码、版本字符串和产品 ID 会被关键词层捕获，而概念上的细微差别则由向量层处理。
生成前的重排序（Reranking）。 检索天生倾向于召回率（recall）。你会拉取四十或五十个数据块，因为你害怕错过那个“金牌段落”。但将所有这些噪音都喂给大型模型会浪费 token 并掩盖有效信号。重排序通过第二个通常较小的模型来解决这个问题，该模型会根据特定查询对每个候选块的相关性进行评分。只有前五个片段能够晋级，其余的则被丢弃。它充当了检索与生成之间的精密过滤器，确保昂贵的推理模型只阅读真正重要的内容。
保留语义的上下文检索。 分块是一种“暴力”行为。分割器可能会将一个段落与其章节标题、表格标题、周围的法律免责声明或修改其含义的脚注切断。上下文检索通过在片段到达模型之前对其进行丰富来缓解这一问题。你在片段前添加指示出处的元数据：“此摘录属于 2024 年第三季度事故报告，数据库停机章节，严重程度：紧急。” 这样，模型看到的不再是一个漂浮的句子，而是一个处于特定语境中的信息片段。片段重新找回了它的定位。
按意图进行模块化路由。 并非所有问题都属于装满文档的向量数据库。用户询问如何重置密码，可能需要一篇帮助文章；而用户询问上季度东北地区收入下降的原因，则需要对数据仓库执行 SQL 查询，而不是一段语义相似的关于区域销售策略的文字。成熟的系统现在会根据意图进行路由，并选择合适的工具。程序性操作查阅文档；结构化分析使用关系型数据库；追踪调试使用日志聚合器；实时状态使用 API。检索层变成了一个调度器，而非单一模式。
智能体推理循环。 有些问题无法通过单一的搜索步骤来回答，它们需要重新表述。模糊的初始查询会被澄清；检索到的断言会通过第二个来源进行交叉验证。如果文档与 API 规范相矛盾，系统会标记冲突，而不是捏造一个折中方案。模型会决定何时再次搜索、何时优化查询，以及何时已收集到足够的证据来回答问题。这不是一次性检索，而是将搜索作为子程序使用的结构化推理。
用于关系型问题的 GraphRAG。 某些业务问题关乎连接，而非句子。哪个组件故障触发了哪些下游警报？哪个供应商为哪个工厂供货，备选路线是什么？组织中谁对这一特定预算项目拥有决策权？扁平的文本块会抹平这些关系，因为它们的设计初衷并非保留拓扑结构。而知识图谱可以做到。当问题涉及影响力、血缘关系、模式或网络结构时，遍历图谱所提供的上下文是任何段落检索都无法复制的。
真正重要的问题
关于 RAG 的讨论需要转变。不要再问如何构建通用的 RAG 流水线，而要开始问：模型必须解决什么特定任务？为了保证准确性需要哪些精确数据？如何验证组装后的上下文是否充分？这些问题会迫使你转向上游，关注数据质量、模式设计、验证循环和来源溯源。它们会揭示你的知识库是否甚至适合自动化消费。
RAG 不再是一个安装后即可遗忘的单一线性过程。它是一门组装正确上下文的学科，以便模型能够进行有效的推理。这意味着要将检索视为一个系统设计问题，而非仅仅是导入一个库。
工具正在变得更加锋利。搜索是混合式的。路由是智能化的。检索是经过排序、增强和验证的。2022 年那些简单的幻象必须破灭，以便真正有用的东西能够取而代之。你现在的任务不仅仅是从数据库中检索文本，而是构建在模型开始思考之前就预知其所需内容的系统。
如果你正在这个领域进行开发，GyaanSetu 学习社区是一个可以与解决相同问题的人交流实践心得的地方：https://t.me/GyaanSetuAi