今年七八月，只要你还在看 AI 圈，就一定刷到过这类标题：RAG 已死。知乎上「为什么现在 Agent 重新用回 Grep，而不是先做 RAG？」这个问题，高赞回答干脆断言“RAG 死了”。知乎更早的「RAG（检索增强生成）会不会消亡呢？」几十万人看过，几天前还有人往里添新答案。Karpathy 扔出 LLM-WIKI，劝大家别再用 RAG 检索笔记；Google 把切块、检索、引用塞进一行 API。
如果你此刻正维护着一个半成品的 RAG 知识库，或者正准备立项一个，说不心痒是不可能的：要不要停手？我把两边论据都翻完之后的结论是：三份“死刑判决”都是真的，但都没有判到你头上。先看清楚账，再决定要不要扔掉手里这套。
三份“死刑判决”，打的是三个不同的靶子
先快速对一下齐。RAG 的基础流水线大家都熟：文档切块、向量化存进向量库、提问时检索 Top-K、塞给大模型生成答案。三份判决书，分别打的是这条流水线上的三个词：“向量”“检索”和“临时”。
判决书一：平台把整条链路收编进 API。 去年 11 月 Google Gemini 的 FileSearch 上线时，36氪的标题是《RAG被判死刑：Google用一行API架空工程师》。36氪上传文件、调用 generateContent，切块、embedding、索引、检索、引用全部在模型内部完成。
定价也便宜得让自建党流泪：首次索引每百万 tokens 收 0.15 美元，之后的存储和检索基本免费。36氪
它打中的是文档量小、没有权限隔离、没有私有化要求的需求——这类需求，自建确实没有成本优势。它接不住的是要权限、要审计、要自定义检索逻辑的企业场景：API 抽象得越彻底，你交出去的控制权越多。
判决书二：Agent 迭代检索，比 RAG 便宜几个数量级。 grep 派的核心论据是：coding Agent 已经证明，靠反复 grep、反复读文件就能定位信息，不需要预先建向量库，迭代效率和成本都碾压 RAG。那位高赞答主甚至预测，RAG 作为一个低效率范式年内就会被取代。知乎
但同一篇回答也承认了软肋：数据里有多个命名相似的对象时，grep 到谁几乎纯运气。知乎grep 在代码库上好用，是因为标识符全局唯一；而你公司知识库里的《Q2 促销方案》和《Q2 促销方案（修订版 v3）》，在 grep 眼里就是两个分不清的文件。
判决书三：Karpathy 的编译思路。 今年春天 Karpathy 发了一份 gist：把笔记当不可变的源代码，LLM 当编译器，一次性编译成结构化、互相链接的 Wiki，而不是每次提问临时重建。他没有宣布新模型，没有发布新框架。36氪日常只有三个动作：Ingest（喂新料，AI 横扫全库更新相关页面）、Query（问编译好的成品）、Lint（定期自查矛盾和过时论断）。
这个思路真的锋利，社区反响也猛：这份 gist 如今四万四千多星，有人已经把自己的 Wiki 扩展到上百页、数十万字。36氪但它解的是“个人知识沉淀”题：语料可控，主人自己当终审。换成几千篇文档、十几个作者的企业知识库，编译成本直线上升——每加一篇文档可能牵动十几个页面，没人审得过来。
反证这边：有人真的把 60% 做到了 95%
就在“死刑”讨论最热的时候，「会不会消亡」那个问题下出现了一篇一线复盘：公司内部几千篇技术文档，第一版 Spring AI 加向量库，三天上线，准确率六成左右——同事问“数据库连接池怎么配”，AI 回答了一堆索引优化；领导亲自试，问本季度 OKR，AI 回“我无法获取该信息”。接下来两个月，他把准确率从 60% 抬到 95%。知乎几步操作的顺序值得抄下来。
先把默认的固定 500 token 切块换成按标题的语义切分，单项就提升 8 个百分点。知乎他的结论是：切块策略的影响远大于模型选择和 prompt 工程。
再加一层 rerank（本地部署 bge-reranker-v2-m3，延迟三五十毫秒），68% 跳到 79%，是他眼里投入产出比最高的一步。知乎然后是混合检索，向量加 BM25，补上向量对专有名词不敏感的短板，79% 到 86%；接着检索前让 LLM 抽意图、带元数据过滤，86% 到 91%，代价是多一次调用、三百毫秒左右延迟；最后给回答挂来源引用，准确率不变，可信度变——用户能点进去验证。
另一个反常识的判断来自切块讨论区：RAG 效果烂，八成问题出在切块，而不是 embedding 模型。知乎embedding 喜欢短文本、大模型需要长上下文，切分本质上是在两者之间做调和。
一个真实事故：因为“禁忌症”标题和“孕妇慎用”正文被切进了两个 chunk，系统对“孕妇能吃这个药吗”回答“可以服用”。知乎这类事故，换再好的 embedding 模型都救不了。这说明一件事：60% 的知识库和 95% 的知识库之间，差的往往不是架构，是工程细节。很多被“宣判死刑”的系统，其实停在 60% 这个阶段。
你们吵的不是同一个场景
把四条路线摆上同一张桌子：
路线 | 代表 | 最适合的场景 | 天生的代价 |
|---|---|---|---|
自建 RAG | RAGFlow、Spring AI、LangChain | 企业多文档、权限、引用、审计 | 效果吃工程细节，前期投入重 |
平台托管 | Gemini FileSearch | 文档少、快速验证、个人开发者 | 交出控制权，难私有化 |
Agent 迭代检索 | coding Agent 的 grep | 代码库、标识符明确的场景 | 命名歧义靠运气，token 成本不可控 |
编译型 Wiki | Karpathy LLM-WIKI | 个人/小团队知识沉淀 | 编译成本随语料涨，要人审 |
仔细看，这四者甚至不算竞品：它们吃的是四盘不同的菜。
更值得注意的信号是，36氪 8 月 10 日的持续学习盘点里，和 RAG 血缘最近的那条路线——“外挂记忆”（MemGPT/Letta 这类把知识存在模型外、不碰权重的做法）——被归为最直接、最快落地的一条。36氪
原因也直白：直接改权重会撞上灾难性遗忘，模型学新知识时把旧能力一起覆盖掉，连通用能力都跟着退化。36氪不碰权重、把记忆挂外面，是眼下风险最低的“继续学习”方式。
所以真实趋势不是 RAG 死了，而是 RAG 被拆掉了：简单的部分被平台 API 收编，精确的部分被 Agent 迭代检索拿走，个人沉淀的部分被编译思路重写。剩下的——企业规模、命名歧义、要引用要审计的检索质量——恰恰是三份判决书都替代不了的部分，也恰恰是决定你的系统停在 60% 还是走到 95% 的部分。
行动清单：你在哪个阶段，就走哪步
准确率还在 70% 以下的：先别谈换架构。按上面复盘的顺序来，先改切块，再加 rerank，再混合检索，再意图过滤，最后挂引用。rerank 是性价比最高的一步，本地部署延迟只有几十毫秒。
语料少于五十篇、全是单文件的：先别建向量库，直接试托管 API 或长上下文塞进去，更快更便宜。代码库、标识符明确的场景：让 Agent 自己 grep，别为检索而检索。个人笔记、小团队沉淀：值得花一个周末试编译思路，哪怕不用全套框架，“标矛盾、定期 Lint”两个动作先抄走。企业多文档在跑的：继续投入，但投在切块、文档解析和评测体系上，而不是换更新的框架。
继续观察的信号：Agent Memory 这条线（Letta、Mem0 等）怎么从 RAG 演化出去；PageIndex 这类不建向量库的树状索引路线。微博腾讯悄悄开源的企业级知识平台 WeKnora 之类的新玩家。微博
RAG 没有死。死掉的是“连一连就能拿 80 分”的错觉。这门技术刚过红利期，进入工程细节期——下次再听到“RAG 已死”，先问自己一句：我的系统，是在 60% 的阶段，还是在 95% 的阶段？
