RAG 真的已经死了吗？我对 Agent 检索选型的思考

Fri, 03 Jul 2026 18:42:00 +0800

最近看到一些围绕“RAG 已死”和“Coding Agent 为什么不使用传统 RAG”的讨论。对我来说，比判断一种技术是否过时更有价值的，是弄清楚：任务到底需要找什么信息，用什么方式找到它，以及找来的内容如何帮助模型回答。

这篇笔记保留我对检索方案的理解和选型思考，不推断具体产品当前的内部实现，也不把讨论中的观点当成已经完成的实验结论。

一、先明确讨论中的 RAG 指什么

我会先把两个概念分开：

广义的检索增强生成：先获取外部信息，再把相关内容交给模型生成回答。这里的检索可以是关键词搜索、代码搜索、网页搜索或数据库查询。
讨论中常见的向量 RAG 流水线：文档切块、生成 embedding、建立向量索引、召回相关片段，再组织上下文。

这只是为了明确本文的讨论范围，并不是说 RAG 只能由这两种方式定义。关键词检索、向量检索、混合召回和多轮搜索，本来就可以组合。

因此，看到“某个 Agent 不用 RAG”时，我首先会追问：它不依赖外部检索，还是没有采用预先建立向量索引的那条路径？这两个判断差别很大。

我不认同直接把“某些场景不使用向量索引”推导成“检索增强已经失去价值”。

二、数据怎么组织，会影响检索的起点

观察维度	文档知识库	代码库
可利用的组织信息	标题、章节、目录、元数据，完整程度因资料而异	文件路径、模块、符号、导入关系等
常见检索需求	按含义寻找相关论述、规则和依据	定位符号、调用位置、行为实现和相关测试
字面检索的优势	精确条款号、术语、标题等明确线索	函数名、错误信息、配置键等明确线索
语义检索的价值	查询表述与原文措辞不同的时候	只知道行为描述、不知道符号名称的时候

如果我已经知道函数叫 generateResponse，优先搜索符号和字面内容通常是一个直接的起点。但如果问题是“哪里处理流式回复中断”，又不知道具体实现名，语义线索和多轮探索仍然可能有帮助。

同样，法律或业务文档也不一定缺少结构，它们可能有清晰的章节、条款和元数据。不能仅凭“代码”或“文档”两个标签决定检索方案。

我更关心的是：当前问题有没有可靠的定位线索，数据是否提供可以利用的结构。

三、高频变更增加了索引同步的要求

代码频繁变化时，我会特别关注检索结果是否对应当前工作区。即使找到的片段很相关，如果它来自旧版本，也可能把模型带到错误方向。

采用向量索引，需要考虑变更检测、增量更新、删除处理，以及不同分支或工作区之间的隔离。这些是工程成本，但不意味着每次修改都必须重建整个索引。

直接搜索当前文件也有自己的成本：搜索范围可能过大，结果可能嘈杂，复杂问题可能需要多轮查询和读取。

我的判断方式是把两类成本一起看：维护索引要付出什么，放弃索引后又会增加多少搜索时间和模型调用。

四、长上下文改变了取舍，但没有替我们完成检索

上下文容量变大之后，有些小型资料集可以直接放入模型，也有些任务值得保留完整文件，以免切块丢失依赖关系。

但“能装进去”和“适合全部装进去”是两回事。我仍然会问：

资料是否真的能放入当前上下文预算？
输入的成本和延迟是否可以接受？
无关内容会不会干扰定位和推理？
当前任务需要完整关系，还是只需要少量证据？

长上下文可以减少某些任务对复杂检索流程的依赖，却不能自动保证信息利用效果。反过来，片段也不是越短越好：缺少定义、前提和调用关系，可能让回答失去依据。

我倾向于根据任务在完整内容与相关片段之间选择，而不是把“全部塞进去”或“只给 top-k”当成固定答案。

五、Agentic Search 与向量检索可以互相补充

我理解的 Agentic Search，是让模型根据已有结果决定下一次搜索或读取动作：

提出初始查询
→ 阅读搜索结果
→ 发现新线索或缺口
→ 改写查询、切换工具或继续读取
→ 收集足够证据后回答

它强调的是检索过程如何被组织，不是某一种底层搜索算法。循环里既可以使用字面搜索、BM25，也可以使用向量检索。

多轮探索的吸引力在于：模型不必一次猜中正确问题，可以逐步从路径、符号和相关内容中扩大或缩小范围。对应的代价是额外轮次、模型调用和上下文开销，也依赖模型能否判断下一步该查什么。

向量召回则可以作为候选发现的一步，再配合关键词、元数据过滤、重排和后续读取。是否更快、更省或更准确，需要在实际任务上测量。

我不会因为一种方法是多轮的，就认为它一定优于单次召回；也不会因为检索由向量完成，就认为整个回答流程已经高效可靠。

六、把质量、成本、时效性和权限一起纳入选型

做检索选型时，我会从以下几个问题入手：

问题	我会考虑的方案与检查点
已知精确名称、编号或错误文本吗？	先尝试字面、符号或字段查询
用户只知道含义，原文表述可能不同吗？	尝试向量召回或混合检索
数据有可用的字段、目录和关系吗？	优先利用过滤、结构化查询和导航信息
一次检索经常无法得到完整证据吗？	评估多轮搜索、查询改写和关联读取
数据变化频繁吗？	检查版本一致性、索引更新延迟和当前文件读取
延迟和成本限制严格吗？	限制轮次、候选量和读取规模，并实测端到端成本
数据有访问权限或隔离要求吗？	在检索和结果读取阶段验证权限、存储及缓存边界

安全性也不能只根据“有没有索引”判断。索引存储、检索服务、日志、缓存和模型输入都有各自的数据边界，直接搜索同样需要访问控制。

对我来说，选型不是先挑一个技术名字，而是先明确任务的证据需求，再选择能够满足它的最小可行组合。

七、减少 token 消耗，要关注实际读进来的内容

如果 Agent 已经定位到一个函数，却仍然反复读取整个大文件，我会检查能否使用行范围、符号范围或相关片段缩小输入。

但不能为了减少 token 切掉必要上下文。函数依赖的类型、调用方、配置和测试，可能正是判断行为所需要的证据。

我会优先尝试：

先搜索定位，再按范围读取。
对已读取内容去重，避免重复塞入上下文。
保留路径、行号或来源信息，方便回到原文核实。
证据不足时按需扩展，而不是一次读取所有资料。
给多轮检索设置停止条件，避免无目的地循环。

这些方法是否有效，应该观察任务成功率、遗漏情况、延迟和输入输出 token，而不是只比较输入长度。

八、我会怎样回答“RAG 是否过时”

我的回答会先明确对方指的是广义检索增强，还是切块、embedding 和向量索引的具体路线。

随后围绕数据规模、结构、变更频率、权限、延迟和成本展开：已知明确符号时可以先做字面定位；需要跨表述发现相关内容时，可以考虑语义或混合检索；需要逐步探索时，可以由 Agent 编排多轮检索。

最后用真实任务验证。至少比较答案是否有依据、是否遗漏关键信息、检索内容是否最新，以及整个流程的成本和延迟。没有同口径评估，就不轻易宣称某种方案全面胜出。

这次讨论带给我的提醒是：不要用“已死”替代工程判断。检索方案的价值，最终体现在它能否以可接受的成本，为当前任务提供正确、及时、权限合规的证据。

上下文工程 on XEDCZQ的博客