这周知乎上，「RAG是不是要死了」这个话题又吵起来了。
「做一个大模型RAG系统，最难搞定的是哪部分工作？」这个问题下，有条回答开门见山：最难搞定的是，RAG已经基本上凉透了。26年咯，不提RAG咯。知乎作者拆了Codex和ChatGPT的Memory实现机制，发现里面根本看不到向量数据库的位置，阅读量冲到64万。旁边那个「RAG（检索增强生成）会不会消亡呢？」的老问题，这两天也涌进新回答，页面热度76万。
但同一时间，B站上「2026年RAG知识库搭建系统教程」播放量19.8万、7400多人收藏。哔哩哔哩LangChain+Ollama的企业知识库实战课，收藏也有4300多；知乎上「混合检索+重排」「GraphRAG实测」的技术文章每天都在更新。
一边说「凉透了」，一边在疯狂学。到底哪边是真的？我把这两天知乎、B站、36氪的讨论翻了一遍，结论是：两边都没错，因为说的根本不是同一个东西。凉的是「切块→向量化→相似度召回」这条裸管线；没凉的，是「让大模型看着你的资料再回答」这件事本身。
「判死派」的三个论据，确实不是空穴来风
先说清楚这波「RAG已凉」的论据，有三个是实打实的：
第一，头部产品的记忆系统，确实没走传统RAG路线。 按知乎这位拆过Codex仓库的作者分析，Codex的Memory是「SQLite控制面+专用LLM提炼记忆+Markdown文件存储+主Agent按文件系统检索」：对话结束时不急着写记忆，而是等空闲时异步跑一个专门的提炼模型，先把「用户要做什么、任务怎么推进、被纠正过什么」抽出来写成Markdown，再由一个整合Agent归并进MEMORY.md索引文件。知乎全程没有向量数据库的事。
第二，长上下文是真的能顶一部分活。 「RAG会不会消亡」那个问题下，最典型的提问就是：我有个11万字左右的txt文档，能不能直接塞进对话里问，还要RAG干嘛？对现在动辄百万token上下文的模型来说，小规模文档问答，直接塞全文确实够用了。
第三，有人在给「替代方案」带货，而且来头不小。 36氪7月报道过，Karpathy提出别再用RAG检索知识库，让大模型把知识「编译」成一座持续生长的活Wiki，相关项目两个月拿下5000多Star。36氪再往前，还有「RAG被判死刑：Google用一行API架空工程师」这类标题。36氪声量叠起来，就显得RAG气数已尽。
但评论区是另一个画风
真正值得看的，是那条64万阅读回答下面的评论区。
点赞最高的一条评论（15赞）就说：rag还是需要，他感觉memory和rag是两个东西，把rag当memory本来就是一个很愚蠢的事情。知乎后面跟评基本都在补刀：
「复杂的RAG的正经用途是大规模数据库的查找，就memory这点规模跟谁碰瓷呢」；
有人直接抛出落地难题：「我的业务是to Gov的，真正需要落地。面对庞大的数据量，memory怎么调用和储存？相对RAG怎么做到透明可控？」
有人质疑质量：「搞这么复杂的架构还都交给大模型判断，80%发生大模型自作聪明瞎编东西进入你说的记忆库」；
最扎心的来自打工人：「净说大实话，让还在推Dify+RAG的人怎么接？」「但是JD上也要求这些😂」。知乎
还有一个很多人没注意到的细节：那个「抛弃RAG」的Codex Memory，本身就是一套检索系统。SQLite存原始记录，MEMORY.md当索引目录，主Agent按需去文件系统里捞内容，再用使用频次反馈决定哪些记忆该保留。换成大白话——存进去、建索引、按需取，一样没少，只是把「向量相似度」换成了「LLM理解+文件检索」。
检索这件事从来没消失，只是换了马甲。
判断一：凉的是裸管线，不是RAG
把时间线拉出来看更清楚：去年10月就有文章直接问「长上下文窗口、Agent崛起，RAG已死？」。36氪11月有「RAG被判死刑」，今年7月是Karpathy的活Wiki，8月是Codex记忆机制之争。「死」了快一年，需求端却一点没降——教程照样爆、JD照样要求、知乎技术区照样日更。
原因不复杂：裸向量管线的痛点，到今天也没有别的方案全面接住——
海量文档。长上下文再长也有边界，还贵。企业里几百GB的制度、合同、工单，塞不进去，也塞不起。
引用溯源。金融、政务这类场景，每句回答都要能指回原文出处。召回文档块、附上来源引用，目前仍然是最可控的做法。
成本。每个问题都把全量资料塞进上下文，按次计费会很疼；召回几个相关片段，成本差出一个量级。
可控性。企业系统里，「由LLM自己决定记住什么、忘掉什么」很难过审计，而RAG的索引是可以人工检查、可以回滚的。
真正在淘汰的，是那套「文档→切块→向量化→top-k召回→直接回答」、不做任何优化的裸管线。证据就在这两天的热文里：大家讨论的已经是混合检索+重排序、查询改写、GraphRAG对比实测、PageIndex这种「不用向量库、让大模型推理着读文档目录树」的新路线（据相关文章介绍，该项目GitHub已有3.5万Star）。知乎RAG在进化，不是在死亡。
判断二：你可以不搭RAG，但先对号入座三种情况
那到底什么时候真的可以省掉RAG？综合这轮讨论，可以对号入座：
情况一：资料量真的少。 个位数到几十份文档、总字数在模型上下文里放得下、主要是一次性问答——直接塞全文，比搭一套RAG省事，还不容易错。评论区有句话说得糙但准：「就你那点数据量，关键词搜一下就行了。」
情况二：个人知识沉淀。 不做企业系统，只想让AI读懂你的笔记、论文、阅读记录。Karpathy式的「知识编译成活Wiki」、Agent记忆这类方向，确实比传统RAG值得关注。但代价要说清楚：有知乎用户提醒「小本本记得太厚了，读一次相当费」（记忆文件往往要整份读入）。知乎而且存在LLM把错误信息写进记忆的风险，需要定期陪着模型修订记忆。
情况三：单份长文档问答。 不少模型已经自带长文档解析能力，先直接测效果，够用就不必重复造轮子。
反过来——资料海量、要频繁更新、要引用溯源、要控成本、要过合规审计——那2026年RAG还是你的主力，别被热搜带节奏。
判断三：继续搭，钱按这个顺序花
如果确认要继续搭、继续优化，这周知乎技术圈的实战文章指向的优先级，基本是这样的：
第一优先级：混合检索+重排。 纯向量召回「看着像但答不对」几乎是通病——问「订单A2024-001的状态」，向量对编号这类精确匹配天然不敏感。BM25关键词检索+向量检索的混合召回，再加一层重排模型，是公认见效最快的一步。有实战文章直接用了「效果立竿见影」这个说法。知乎
第二优先级：先建评测集，再谈调优。 很多人优化RAG靠手感，参数改来改去不知道是变好还是变坏。挑50个用户真实会问的问题，标注标准答案和该命中的文档，才有尺子量效果。这步不花钱，但最容易被跳过。
第三优先级：查询改写和多轮对话检索。 多轮对话里「就我问的那个事儿」这种半截话，检索器根本不知道搜什么，需要查询改写、子问题拆解这类手段。今年ACL上也有一批对话式RAG的新工作，方向很集中。
第四优先级：盯着反直觉的新研究。 比如中科院计算所最近一篇论文（据知乎作者的拆解与复现）发现：筛文档时只按来源权威过滤、完全不看内容相关性，准确率反而最高。知乎这类结论有它的适用场景，还不是放之四海皆准，但值得放进关注列表。还有「循环工程」的思路——检索不该一条命走到底，答不上来要能重试、能换路，把长文档检索从「先选一批页再硬答」改成「读、记、更新置信度、再找」的循环。知乎知乎
最后：给你一份「RAG真凉」的观察清单
与其争论RAG死不死，不如盯住几个可以验证的信号。这几条如果出现，才是真正该转向的时候：
企业级记忆产品成规模出现——可审计、可回滚、权限可控，而不是单机Agent的小本本；
长上下文价格再降一个量级，「塞全文」比维护一套索引还便宜；
招聘JD里不再要求向量数据库和检索优化经验——这条最诚实。
在这些信号出现之前，给还在搭知识库的朋友一句话：别再搭新的裸管线，也别因为热搜就把现有系统推倒。把钱花在混合检索、重排和评测集上，这三样不管叙事怎么变，都不白搭。
