这两周，中文开发者社区围绕 RAG 开了一场集体审判。
8月28日，知乎专栏一篇拆解 Mistral 新发布的 Agentic Search 的文章给出了一组扎眼数字：在 FinanceBench 金融文档问答基准上，多步检索把准确率从单步 RAG 的 26.7% 拉到 86%。知乎专栏原因说得很直白：传统检索只跑一次，相关资料根本没被检索到，模型只能基于残缺上下文硬编。
几乎同期，知乎问题「为什么现在 Agent 重新用回 Grep，而不是先做 RAG？」积累了 16 万+浏览。高赞回答的判断是：Claude Code 的 rg、Codex 的 ripgrep 证明了新路线——检索不再是固定管道，模型自己找文件、自己搜片段，基模 coding 能力越强，grep 用得越好。知乎
对面同样热闹。「RAG（检索增强生成）会不会消亡？」下 78 赞、287 收藏的企业实践复盘写着：知识库问答第一版上线被打脸、准确率约六成，两个月把切块、重排、混合检索、意图过滤逐层调优做到自测九成五，留下一句戳破风口的话——RAG 的瓶颈不在模型，在工程。知乎
喊「RAG 已死」的和说「我的 RAG 挺好用」的，到底谁对？对已经搭了知识库问答、或正被需求评审卡着的 Agent 开发者，真正的问题不是站队，而是：我的系统要不要拆？不拆，先补哪一块？下面三个问题，就是这个决策的手术刀。
问题一：26.7% 输掉的是一代模型，还是一次管道决策？
先拆 Mistral 那组数字，因为它容易被误读成风向。Agentic Search 做的事不是换更大的生成模型，而是把检索的控制权交给模型本身：给它五个工具（search、open、navigate、read、grep），由它自主决定下一步搜什么、翻哪页、读哪段——先粗搜、发现缺口、再定向补搜，和人类研究员的工作流一致。知乎专栏
有开发者把这条路线总结得更狠：Agent 要完成一项现实任务，本质上就是不断缩小信息差，把搜到的信息变成可以信任的证据，再根据新的证据判断和行动——Agent Search 的本质不是搜索，而是寻证。知乎专栏在这套视角里，Grep、RAG、Hybrid Search、Graph 不再是孤立的技术名词，而是 Agent 获取证据的不同方式。
所以 26.7% 暴露的不是「检索没用」，而是教程时代默认继承的那个假设：检索一次就停。长文档基准上，这个假设直接把系统真实可用率压到三成以下——这也是为什么另一边那位企业开发者会觉得「十个问题里有四个答非所问」。
但也要看清边界，原解读文章自己泼了冷水：这个提升高度依赖「资料可被工具访问且结构化程度足够」，一堆没索引的扫描件 PDF，agent 再聪明也搜不到。落地价值约等于检索能力乘以语料可检索性——别让 agent 的规划能力，去救你连可检索性都没做的语料。知乎专栏
问题二：你赖以为生的「相关性」，真的可靠吗？
这是这波争论里最反直觉的事实信号。中科院计算所公开的 AuthorityBench 基准（arXiv:2603.25092，代码与数据集 MIT 开源）在 RAGAuth 上做了受控对照：以 Qwen3-14B 为例，k=1 时，只按来源权威（PageRank 代理）过滤的答案准确率 76.67%，而「语义相似度优先」的相关性过滤只有 51.67%，甚至低于不过滤基线的 58.33%。知乎换句话说，在这份评测里，按「最相似」挑上下文，很多情况下还不如不挑。
论文作者给的实验结论毫不客气：相关性过滤经常低于不过滤。知乎原因不玄学：同样语义相似的两条结果，官方运维手册和内容农场搬运文，向量相似度分不出高下，来源权威可以。287 收藏那篇复盘帖里「数据库连接池配置和索引优化被切成同一块、AI 被干扰答非所问」的事故，打的是同一个敌人——检索把不该一起进上下文的东西放进来了。
两个事实指向同一处：这波贬值的核心资产从来不是 RAG 本身，而是没人评测过的默认配置——固定长度切块、纯向量 top-k、检索一次就完事。还在跑教程默认值的，和 26.7% 是同一批风险敞口；把管道逐层调透的，和 95% 在同一个安全区。
问题三：grep 取代 RAG，还是只取代了某一类 RAG？
回到 Grep 阵营，它最强的证据在代码库场景，而且同样来自 Anthropic 官方口径：8月30日知乎一篇基于官方博客整理的《大型代码库中 Claude Code 的成功部署模式》写得直白——传统 RAG 编码工具要先把整个代码库向量化入库，大团队高频提交下索引经常跟不上，返回的函数可能早被重命名或删除，还不会提示信息已过时。知乎专栏
但同一篇文章也给出了这条路线的前提：Claude 需要足够的初始上下文才知道往哪找，仓库结构混乱、缺分层说明文件时，agent 可能还没干活就先耗尽上下文窗口——换句话说，仓库越乱，grep 越搜不动。知乎专栏这篇整理里还有一个值得抄作业的提醒：官方建议每 3 到 6 个月做一次全面的配置检查，写给旧模型的指令放到新模型上，可能反而起反作用。
成本这一项社区也没放过。grep 问题的另一条回答提出：「为什么一定要主模型做这个杂活？能不能找一个高速模型先把 rg 结果搜出来？」——主模型多轮循环检索，意味着每次查询的 token 和延迟都在涨。toC 个人工具里这笔账好算：多花的 token 比养一整套向量库便宜；在高并发企业问答里就不一定了。《为什么现在 RAG 越少越少提及了》那篇 33 赞的复盘把社区转向的词汇表都列了出来：Skills、Tools、MCP、Memory、Context Files——对个人开发者，搭建、费用、增量同步三头成本加起来，确实打不过一个免费 tool。知乎专栏但这笔账搬到企业侧，完全是另一种算法。
所以结论不是谁取代谁。Grep 问题高赞回答自己也划了边界：不是 RAG 没用，垂直场景 RAG 仍是主流——谈的是 80% 场景的银弹，不是 100% 场景的银弹。知乎grep 取代的是代码库场景的索引型检索；企业知识库、高频文档问答、客服机器人里，pipeline 仍是主战场。
对号入座：你的场景拆还是保
你的场景 | 检索形态建议 | 理由与成本要点 |
|---|---|---|
Coding Agent / 代码库问答 | 转 agentic search（rg/glob+文件遍历） | 免索引维护、实时准确；前提是仓库结构清晰，代价是 token 上升 |
企业知识库日常问答（静态文档、高频次） | 保 pipeline，补 rerank+混合检索 | 单次成本可控（本地 bge-reranker 延迟 30-50ms）；调优六步投入产出比高 |
多跳复杂问题（财报/合同/长报告） | pipeline 粗检 + agentic 补检 | 单步检索结构性漏检，86% 那类基准正是这个场景 |
合规审计、来源引用 | pipeline+引用，或 agentic 但必须存完整轨迹 | 检索轨迹可审计是门槛，不是加分项 |
个人/小团队知识库 | 先别建向量库 | 搭建+费用+增量同步三头成本，文件级检索够用 |
本周就能做的三个动作，而不是今晚就拆
建一个 200 题评测集再开会讨论。真实提问、客服记录、边界 case 各占一部分，每题带标准答案——那位做到 95% 的开发者，最关键的投入就是先花一周攒了这个评测集。没有它，「要不要上 Agentic」和「要不要换供应商」都是拍脑袋；有了它，优化才从「感觉好了一点」变成「83% 到 88%，主要在专有名词场景」。
把 badcase 归因一遍。检索漏了 / 切块混了 / 来源脏了 / 模型幻觉了——只有「检索漏了」这一类值得为它引入多步检索；来源脏了先做权威过滤和元数据治理，别急着上大杀器。AuthorityBench 那种「相关性不如权威」的反例，恰恰说明归因比堆新组件便宜。
在 query 分布最难的 20% 试点 agentic 补检。已有 pipeline 保留做粗检，agent 只对没召回的补搜。这条路线不拆系统、保住延迟与审计基线，又拿到多步能力——不是重做 RAG，是给管道装上决策权。
接下来值得盯的信号：Mistral 之后，头部模型厂商把 agentic search 做成标准产品的节奏；AuthorityBench 这类「测检索假设」的评测会不会进入框架选型必答题；以及向量数据库厂商的价格与开源动作——社区唱衰不会杀死产品，价格战和替代品会。
写在最后
这波争论真正改变的不是「RAG 死没死」，而是检索的控制权归谁：从「工程师预设一条管道、模型只能用结果」，变成「模型自己决定怎么搜、搜到哪算够」。贬值的是没人评测过的默认配置，升值的是评测集、来源治理、跨阵营的检索编排——这些恰好都是大厂发布会不带、但你的生产事故里全有的东西。
所以，拆向量库之前，先跑你自己的评测集。它给出的分数，决定你保下来的是资产，还是负债。
