RAG 的未来：形态迁移，而非死亡

第 1 篇里我画过一条七步链路：抽取 → 清洗 → 分片 → 标注 → 索引 → 检索 → 生成。过去一年有种流传很广的判断：这条链路会整体消失——LLM 自己决定看什么，不再需要外部向量库。我做了近两年财报 RAG，这个系列写的就是这条链路上的坑；最后一篇，正面回答它。

答案先放在这里：链路不会消失，会迁移——Embedding 不会死，只是你看不到它了。但在下结论之前，得先把反方讲到最强。

一、先把“现在的 RAG”固定下来

讨论“会不会死”之前，得先锚定今天 production 级的 RAG 长什么样，否则各说各话。

对照第 1 篇那条链路看今天的系统：每个环节都还活着，但每个环节内部都叠上了策略层。摄取预处理不再是 pdfplumber 抽一遍完事，而是按文档类型分派解析策略；分片从按 token 均分进化到语义分片、结构感知切分；索引普遍是向量加 BM25 双写；查询召回早就是多路的——LLM 先生成几个查询变体，向量和全文并行跑，再融合；召回之后还有 cross-encoder 重排过滤，最后才组装进 prompt 生成。

环节没变，内容变复杂了。在“RAG 将死”的论战里，最容易被演化替代的不是“索引”这个动作本身，而是 embedding distance → top-k → 拼 prompt 那条由外部固定策略决定证据的线性路径。靶子先立准，后面才不浪费弹药。

顺带把外延也立住：RAG 这个词比“向量库 + embedding”宽得多。留存 markdown 让模型自己翻文件也好，建 DB 也好，DB 之上再建 graph 也好，只要是通过 retrieval 改变 LLM 的 generation，就是这把伞下的一种具体实现。把外延划宽，后面谈的“迁移”才有落点：迁移的不是某一种工具的生死，是 retrieval 这件事在系统里的位置。

二、那个“RAG 将死”的论点，逻辑上是自洽的

不竖稻草人。流行的论据主要两个：长上下文让“把所有文档直接塞进 context”变得可行；Agent 能自己搜索、自己翻文件，不需要事先建好向量库。论据背后是一条完整的推理链。

上下文窗口从 8K 一路拉到百万级——Gemini 2M、GPT-5.5 1M、Claude 200K，幻觉率比 8K 时代低了一个量级，Tool Call 的理解和执行越来越可靠。既然如此，为什么要由外部系统替模型决定它该看哪几段？模型完全可以像人翻文件夹一样，自己决定打开哪个文件、看完这段想起另一个文件、再回头核对那张表。被判定相关的文件全量进上下文，Attention 在 token 间的路由就是最好的相关性计算——本身就是一种“软检索”。在这个图景里，“先做向量匹配再注入 prompt”的外部回路消失了，模型自己准备自己的 prompt。

这个论点还有个激进版本，连 Embedding 都绕过去：多模态数据进入模型时以 KV Cache 形式存下压缩表示，推理时直接从 KV Cache 继续 decode。你问“我昨天晚上吃了什么”，模型看过昨天所有照片的 KV 表示，直接出答案；照片太多装不下，就开 subagent 分批过，分类器先筛一遍 yes/no，所有 yes 合并进上下文二次推理。

这套设想我挑过工程毛病——KV Cache 怎么管理、怎么复用、显存怎么扛。但我得承认：它逻辑上自洽，终局意义上方向也对。问题不在逻辑，在时间尺度和工程现实。

三、工程现实：Embedding 更可能变形，而不是死亡

“逻辑自洽”不等于“马上可规模化”。进了真实生产环境，有五笔账绕不过去。前三笔是旧账新算，后两笔常被忽略。

第一笔，成本。一份完整财报 PDF 转成文本大约 15–30 万 token——这个系列反复用的那份 119 页腾讯中报就在这个量级【待核实：与第 1、2 篇 119 页腾讯中报的 token 换算口径对齐】。每次查询都把 30 万 token 塞进 context，按 Claude Opus 的输入定价（$15 / 百万 token）算约 $4.5 一次；走检索只取 top-5 chunk（约 3000 token）加生成，约 $0.05–0.10，单次差 50–100 倍。延迟也随之差出 2–5 秒，交互场景可感知。

第二笔，长上下文不等于稳定有效上下文。Lost in the Middle 验证过：模型对长 context 中间位置的 recall 显著低于开头和结尾。整份财报塞进去，中间第 7 节的关键数字就是比开头第 1 节更容易被漏。“看到了”不等于“稳定利用了”。

第三笔，多模态需要统一可比较的空间，这是 Tool Call 最硬的盲区。一张 4096×4096 的照片、一段微信语音、一段三分钟视频，想找“上周二和谁在哪儿吃了什么”——线索在像素、音频、视频时序里，不在任何文件的 metadata 里。Tool Call 的输入输出是函数签名，给不出“该 load 哪个文件”的先验。让模型事先“看过”十亿级文件？筛选本身就需要距离度量——距离度量就是 Embedding。

第四笔，检索是权限和治理问题，不只是相关性问题。ACL、审计、合规、可追溯是硬要求，“模型自由探索全部数据”第一步就过不了合规。

第五笔，线上系统要稳定的退化路径。模型失误、Tool 失败、上下文预算耗尽时，系统得有可预测的 fallback，向量和关键词索引常年承担的就是这层兜底。

五笔账合在一起：十亿级多模态数据全量进 context，经济上大概率不可行——这是判断性估算，不是实测定律，但成本结构的方向很清楚。全量不可行，“先压缩，再定向加载”的机制就一定存在，变的只是它住在哪一层。

四、形态迁移的三个去向

这是全篇的题眼。把 RAG 看成“把信息从存储层搬运到推理层的机制集合”，正在发生的事不是消亡，是位置迁移：从外部插件，迁进模型和基础设施内部。至少三个去向已经能看到。

一是迁进 KV Cache 管理。MemGPT（以及它的后继项目 Letta）这类系统在用 Embedding 管理虚拟上下文：哪些历史信息留在缓存、哪些淘汰、哪些回填，不按时间顺序也不按 token 位置，按语义相关度——本质是把向量检索用在 Attention 的缓存策略上。

二是迁进 Tool Call 的路由决策。模型决定“调哪个工具、抓哪批文件、要不要继续深挖”时，内部做的仍然是相似性判断和相关性估计——只是你不再直接操作向量库接口，看不到这次“检索”了。

三是迁进硬件执行层。Attention 算子本身也在做“选择性计算”：FlashAttention-3 靠 warp 专门化、pingpong 调度和 FP8 把有效注意力的计算效率推到 H100 理论峰值的 75%，块稀疏类算子更进一步，直接跳过不需要参与的 Query-Key block。要把话说准：这和 embedding 检索是两套机制——算子层跳过哪些 block，依据的是注意力掩码和数值分布，不是语义相似度。但方向是同一个：选择性地访问信息这件事，正被一层层压进用户态代码完全感知不到的地方。

有个不太精确但有用的类比：文件系统之于操作系统。早期的文件系统是用户态工具，用户自己管 inode 和扇区；后来它沉进内核，你通过 open/read/write 用它，却不再需要知道它的存在。没人说“文件系统死了”，它只是从可见变成了不可见。RAG 走的是同一条路。

五、分时间尺度的判断

我不给无条件的预言，判断全部带时间前提。

1–3 年：纯 Vector Database、纯 Embedding API 公司确实承压，差异化在被模型能力快速填平——卖点只是“语义搜索”的话，窗口大到能装下用户全部相关数据时，这个品类的价值会迅速稀释。注意这和上一节“检索+注入仍是最省钱的方案”不矛盾：承压的是把向量检索当单品卖的公司，不是检索这个机制本身。做动态索引、Hybrid 编排、模型内检索优化的系统有过渡期红利：数据安全、延迟、成本、存量基础设施的惯性，决定了 Hybrid 架构这几年仍是企业部署的现实选项。市场奖励的是“检索操作系统”，不是“单点向量能力”。

3–5 年：最大变数是模型训练方向。DeepSeek 公开讲过的方向之一就是 1M context + 更好的 Tool Call 理解 + Computer Use【待核实：此为 DeepSeek 公开讲过的训练方向，发布前按其最新公开表述复核，不写成内部消息】。如果 1M 下的幻觉和 Context Decay 像 8K→256K 那次一样被解决——当时也没人相信 256K 能稳定工作——“把尽量多的相关数据直接交给模型”会优于“帮它筛选”，因为筛选本身会丢信息。但有一关模型能力解决不了：企业级十亿级多模态数据，全量进上下文的推理成本是指数级的，压缩表示这层预处理与索引不可或缺。

长期看，形态大概率分化。一端是低端本地小模型的 RAG——成本敏感、延迟要求高、数据不出本地，用 Embedding 做轻量语义索引，模型兜底不精确匹配。另一端是巨型纯 LLM 系统——上下文装得下的数据和任务，模型端到端自己完成检索推理，不经过外部组件。中间地带，也就是“经典 Embedding 检索 + LLM 生成”这一段，会被上下文软检索慢慢吞掉。

六、如果你现在在做 RAG 系统

判断落到选择上，我给框架，不给标准答案。

两条直接的建议。第一，保留“LLM 主导检索”这个认知方向，同时继续投压缩表示的基础设施——两者不矛盾：前者是方向，后者是成本结构决定的现实。第二，关注模型内检索：MemGPT、Letta、virtual context management 这一脉工作，跟传统 RAG 的关系是“吸收”不是“替换”。理解模型怎么处理内部上下文，会告诉你外部检索层哪些值得留、哪些可以放手。

然后是三个选型问题：你的数据规模和模态，允不允许高比例全量上下文？你的业务偏质量上限，还是偏成本与可治理性？你的系统有没有失败可退化的能力？三问答完，路线自然浮现：小规模高价值任务可以激进地走 LLM 主导检索；大规模企业场景优先 Hybrid，逐步提高模型自治比例；多模态长期资产，重点投表示学习和索引更新，而不是押注单一范式。

七、终篇收束：形态会迁移，链路不会消失

从 2023 年到现在，“找证据 → 给模型看 → 让它生成”这条骨架没变过，变的是找证据的方式和给模型的路径。这个系列前 20 篇讲的东西——上游 PDF 里的脏数据、相似度的时间和口径错觉、运维期的术语漂移——没有一件会因为检索下沉到模型内核而自动消失，它们只会换一层重新出现。

收尾留两句回环。一句给第 1 篇：七步链路每一步的坑，会在新形态里换名字回来——reading order 换成“多模态预处理的信息丢失”，metadata 过滤换成“Tool Call 的访问边界”。一句给第 6 篇：那一篇讲时间错配，问“2025 Q4 的营收”，系统流利地背出 2020 Q4 的数字，相似度分数还很高——这是“相似度有盲区”这条主线最早的案例；无论相似度将来算在向量库里还是 Attention 里，这个教训都成立。

Embedding 不会消失，只是你看不到它了。