说RAG已死的人，大概率没在生产环境被退款和支付搞崩溃过

---

上周五下午，一个做知识库的朋友甩了张截图给我。

「RAG 已死，长上下文一统天下」——某技术论坛的帖子标题。他配了三个捂脸表情。

我当时正跟一个混合检索的权重参数较劲，随手回了句：「说 RAG 死了的人，大概率没在生产环境真正跑过。」

回完就后悔了。这话太绝对。

但我也没撤回。因为某种程度上，我确实这么想。

这事儿我琢磨了快两年。2023 年初开始碰 RAG，那会儿的玩法——怎么说呢——简陋得可爱。把 PDF 切成 500 字小块，text-embedding-ada-002 转向量，扔进 Chroma，用户提问就召回 Top-3，拼进 prompt。完事儿。

Demo 跑得欢。

一上生产，翻车。

翻车现场是这样的：用户问「怎么退款」，系统给他检索出三篇「支付流程」的文档。语义上确实相关，都跟钱有关。但用户要的是退款，不是支付。用户骂了句「什么破机器人」，转人工了。

这就是 RAG 1.0 的典型问题。纯向量检索找的是「相似」，不是「相关」。你品品，在向量空间里，「退款」和「支付」的余弦相似度可能高达 0.85 以上，但业务上这俩是反义词。

绝了。

后来我踩了不少坑，也开始理解为什么有人觉得 RAG 不行了。

一个原因是长上下文模型确实猛。Claude 3 出来的时候支持 200K token，Gemini 1.5 Pro 直接干到 100 万，现在各家都在卷这个。如果你的知识库就几百页文档，确实没必要折腾检索——全塞进去完事儿。省事。

但这里有个坑。我实测过，当上下文超过 100K token 之后，模型的「中间迷失」现象非常明显。你把一份 200 页的报告扔进去，问它第 137 页的一个数据，它大概率会漏掉或者编一个。这不是模型不够聪明，是注意力机制在长序列下的天然衰减。DeepMind 那篇论文说得挺直白——模型不是真的「记住」了 1000 万字，它只是把它们塞进去了，检索信息时会变得混乱。

另一个原因是成本。你把整本《红楼梦》塞进 prompt，每次提问都要为那 70 多万字付费。我算过一笔账：用 GPT-4o，单次查询塞满 100K context 的成本大概是纯检索方案的 8 到 12 倍。并发一上来，账单直接爆炸。

所以长上下文不是银弹。它吃掉了一部分简单场景，但真正复杂的企业场景，RAG 反而在进化。

去年我开始尝试一些新做法。名字就不起了，听着唬人，其实核心就几招。

用父子窗口切块。传统切块的矛盾在于：块切太大，检索不精准；块切太小，上下文丢失。父子窗口的解法很聪明——用 300 字的小块做检索，但返回给 LLM 的是包含这个小块的 1000 字大块。检索精准了，上下文也完整了。我在《红楼梦》知识库上测过，宝玉挨打那段的问答准确率从 62% 提到了 89%。

然后是混合检索。向量检索加 BM25 关键词检索，两条路同时跑，结果合并后再用 Reranker 重排序。这招解决了「产品编号搜不到」的问题——纯向量对精确关键词不敏感，但 BM25 天生就是干这个的。Anthropic 在 2024 年推出的 Contextual Retrieval 也是这个思路，他们给的数据是混合检索把失败率降低了 49%，叠上重排序之后降了 67%。

还有问题改写。用户说话很随意的。「那个报销咋搞」——这种口语化的 query，向量搜索根本匹配不上。所以在检索之前加一步，让 LLM 把用户的问题改写成更规范、更完整的检索 query。这招成本很低，效果很明显。

再就是加了个自反思机制。让 LLM 在生成答案之前，先检查检索到的文档是否真的相关、是否足够回答问题。不够就再检索一轮，或者换个角度检索。Self-RAG 那篇论文把这个思路系统化了，但我在实际项目里做的更轻量——就加了一个判断步骤，检索质量直接提升了 15 个百分点。

说实话，这套方案跑了一年多，效果确实不错。但我也得承认，它比 RAG 1.0 复杂太多了。多了三个模型调用环节，延迟从 800ms 涨到了 2.3 秒，运维成本也上去了。

所以我现在跟团队说：简单场景别折腾，直接塞 prompt 或者用基础 RAG 就够了。只有当你明确遇到了检索质量问题，再考虑上这些进阶方案。

GraphRAG、Agentic RAG 这些更复杂的架构，我试过，确实在某些场景很香——比如需要跨文档推理的法律案件分析。但大多数业务场景用不上，硬上就是过度设计。

简单系统更稳定，环节少，出错的地方就少。

这句话是我花了大半年才真正理解的。

回到开头那个问题：RAG 会不会消亡？

我的判断是：不会。但它会从「应用」变成「基础设施」。就像数据库，没人天天讨论数据库会不会消亡，但哪个系统离得开它？RAG 或者说更广义的「上下文工程」，正在成为所有 AI 应用的标配组件。

2023 年那种「切块加向量加 Top-K」的入门版 RAG，确实已经过时了。但 RAG 这个思路本身，正在被吸收进更大的体系里——混合检索、智能重排、查询改写、记忆系统、工具调用，这些东西合在一起，构成了一个完整的上下文引擎。

大厂们也没闲着。OpenAI 的 API 里内置了 file search，做的就是混合检索。Anthropic 搞了 Contextual Retrieval。Google DeepMind 最近发了 RLM 论文，让模型像程序员一样用代码检索长文本——这本质上也是一种更智能的检索策略。

所以你看，大家不是在告别 RAG，而是在把它从一个 Demo 做成一套工业级系统。

最后说个挺有意思的事。上周那个问我「RAG 是不是死了」的朋友，昨天又发消息来了。他说他们团队评估了一圈，决定还是用 RAG，但是升级到了混合检索加重排序的方案。

我问他为啥。

他说：「长上下文太贵了，而且用户问『那个产品咋样』的时候，模型根本不知道『那个』是哪个。」

绝了。

这就是真实世界的需求。不是论文里的 benchmark，不是技术社区的争论，而是一个用户说了句模糊的话，系统得能接住。

RAG 还活着，活得挺好。只是它不再是一个 buzzword 了。

它变成了水管、电线、地基——看不见，但缺不了。

你觉得呢？