部分场景中可以替代 RAG 的技术

写在前面

最近看到一个说法：长上下文、Agentic Retrieval 或 LLM Wiki 会替代 RAG。

这个说法只对了一半。它们确实可以在部分场景中减少传统 RAG 的必要性，但不是把 RAG 整体淘汰。

传统 RAG 解决的是一个很具体的问题：模型参数里没有足够新、足够私有、足够细的知识，因此需要在回答前从外部知识库检索证据，再把证据放进上下文。它的核心能力不是向量数据库，而是把外部知识带入模型。

所谓替代 RAG，本质上是替代这个链路中的某一部分：

因此，更准确的判断应该是：RAG 不会消失，但“固定切块 + 向量检索 + Top-k 拼接”的朴素 RAG 会越来越少单独使用。新的系统会根据任务选择长上下文、智能检索、结构化知识或混合方案。

一、先明确传统 RAG 的边界

传统 RAG 的流程很固定：用户提出问题，系统把问题向量化，在向量数据库中搜索相似片段，取 Top-k 文档块，再把这些文档块交给大模型生成答案。

这个流程在很多企业知识库中仍然有效。它成本低、架构成熟、可扩展，适合海量文档的常规问答。但它有几个根本问题。

第一，切块会破坏结构。合同条款、财报表格、论文方法、代码调用链经常跨页或跨段落出现，固定 chunk 容易把完整逻辑切碎。

第二，Top-k 召回不是理解。向量相似度只能说明文本表面或语义上相近，不代表这段文本能回答问题。

第三，检索策略是静态的。系统通常在运行前就决定了召回数量、索引类型、重排方式，模型本身很少参与检索决策。

第四，知识结构没有被维护。普通 RAG 更像把文档碎片堆进仓库，缺少页面、实体、关系、目录、版本、权限等长期知识资产。

因此，讨论替代 RAG时，不能简单问是否还需要向量库，而要问四个问题：

这四个问题基本决定了技术选型。

二、Long Context：直接读全文

长上下文是最容易被理解为替代 RAG的技术。它的逻辑很直接：既然模型可以接收几十万甚至上百万 token，那就不做检索，直接把完整文档放进上下文，让模型自己读。

这条路线的推动来自模型能力的变化。OpenAI、Google、Anthropic 等头部厂商都在持续扩展上下文窗口。Google 从 Gemini 1.5 开始公开强调 100 万 token 级长上下文能力；OpenAI GPT-4.1 系列发布时强调 100 万 token 级上下文；Anthropic 也已经把 Claude Sonnet 4 的 100 万 token 上下文能力推向生产可用阶段。长上下文已经不是实验室概念，而是进入工程使用的能力。

但长上下文不是无限记忆。研究者在 Lost in the Middle 中指出，模型对长上下文中间位置的信息利用并不稳定，常出现开头和结尾信息更容易被利用、中间信息被忽略的问题。上下文窗口变大，不等于模型能均匀、可靠地使用所有 token。

适合替代 RAG 的场景

长上下文适合读一遍、单文件、不频繁更新的场景。

典型场景包括合同审阅、审计报告分析、单篇财报研读、长 PR Review、单个代码模块理解、产品手册问答。它们有一个共同点：文档规模可控，任务关注完整上下文，用户希望模型读全文，而不是只看检索片段。

在这些场景中，长上下文有明显优势。

例如合同审阅，用户希望模型检查整份合同中的付款条款、违约责任、数据安全义务和终止条件。这类任务如果先切块检索，很可能漏掉分散在不同章节中的关联条款。直接把合同全文输入模型，反而更符合任务逻辑。

不适合替代 RAG 的场景

长上下文不适合海量知识库、高频更新知识库和低延迟交互场景。

如果企业有几十万份文档、代码仓库持续更新、日志实时变化，直接把全部知识塞进上下文不可行。即使模型窗口足够大，成本和延迟也会快速上升。更重要的是，模型仍然需要知道该读哪些内容，这时检索、过滤和权限控制仍然不可替代。

因此，长上下文更像是替代小规模静态知识库中的检索步骤，而不是替代企业级 RAG 系统。

三、Agentic Retrieval：让检索变成推理行为

Agentic Retrieval 的核心变化是：检索不再是固定流水线，而是由模型根据任务状态动态决定。

传统 RAG 是一次性流程：

Query -> Retrieve -> Generate

Agentic Retrieval 是循环流程：

Reason -> Act -> Observe -> Decide -> Repeat

这个思想可以追溯到 ReAct。ReAct 让模型在推理和行动之间交替：先思考下一步需要什么信息，再调用工具，观察结果，然后继续推理。OpenAI Agents SDK、Anthropic MCP、LangGraph 等框架的发展，也说明头部厂商和工程生态正在把工具调用、状态管理、记忆、追踪和安全执行作为 Agent 系统的基础设施。

它替代了 RAG 的哪一部分

Agentic Retrieval 替代的不是知识库，而是固定检索策略。

在传统 RAG 中，系统预先规定检索几个 chunk、用哪个索引、是否重排。模型只是读结果。Agentic Retrieval 中，模型可以决定：

它更适合复杂问题，而不是简单 FAQ。

企业案例：退款率升高根因分析

假设用户问：

为什么最近退款率升高？

普通 RAG 可能在知识库中检索“退款率”“退款规则”“客服流程”等文档，然后生成一个泛泛解释。但真正原因可能在日志、支付接口、版本发布记录和工单系统中。

Agentic Retrieval 的流程更接近真实排查。

用户问题：为什么退款率最近升高？
1. Reason：退款率升高可能与支付失败、APP 新版本、客服策略有关。
2. Act：查询最近 7 天支付失败日志。
3. Observe：发现支付宝接口失败率异常上升。
4. Reason：需要确认是否由近期发布引起。
5. Act：查询支付系统发布记录。
6. Observe：发现新版本修改了回调处理逻辑。
7. Act：查询相关工单与错误码。
8. Decide：证据足够，输出根因与修复建议。

这个场景中，RAG 的问题不是检索不到文档，而是问题本身需要多步验证。Agentic Retrieval 更像调查过程，而不是搜索过程。

工程代价

Agentic Retrieval 也有明显代价。

第一，成本更高。每一步都可能调用模型和工具，token、API 和延迟都会增加。

第二，不确定性更高。模型可能选择错误工具、重复搜索、过早停止或陷入循环。

第三，需要更严格的运行时。企业系统必须设置最大步数、工具权限、审计日志、错误恢复、超时控制和结果验证。

因此，它适合“查多步、跨系统、找根因”的任务，不适合所有简单问答。简单政策问答仍然用普通 RAG 更合适。

四、LLM Wiki：把知识提前编译成结构

LLM Wiki 的思想是：不要等到用户提问时才临时切块、检索、拼接，而是在知识摄入阶段就把文档整理成模型可读、可导航、可维护的知识系统。

它不是一个单一工具，而是一种知识工程架构。核心组件包括页面化、双向链接、层级目录、实体关系、自动摘要、自动索引和语义导航。

它替代了 RAG 的哪一部分

LLM Wiki 替代的是把知识只当作碎片素材的方式。

传统 RAG 通常把文档切成 chunk，然后向量化入库。系统并不真正维护文档结构，也不理解实体之间的关系。LLM Wiki 则把知识看作一个持续演化的系统。

页面化

页面化的目标是保留知识边界。不是把文档机械切成 500 字一个 chunk，而是构建 page object：

{
  "page_id": "refund_policy.travel",
  "title": "差旅报销规则",
  "summary": "说明差旅费用报销范围、审批流程和票据要求。",
  "content": "...",
  "links": ["invoice_policy", "finance_approval"],
  "entities": ["差旅报销", "发票", "财务审批"]
}

这类结构比裸 chunk 更适合长期维护，也更适合模型导航。

双向链接与实体关系

企业知识不是孤立文档。退款规则会关联财务审批，财务审批会关联发票制度，发票制度会关联税务政策。LLM Wiki 通过实体识别、链接生成和反向索引，把这些文档连成网络。

这也是 GraphRAG 的核心思想之一。Microsoft GraphRAG 通过实体和关系构建图结构，并在图上进行局部或全局检索，使系统可以回答普通向量检索不擅长的跨文档、全局总结和关系型问题。

自动摘要和多层索引

RAPTOR 提出了树状递归摘要的思路：把底层文本聚类并逐层摘要，查询时可以在不同层级检索。LightRAG 则强调轻量级图结构和向量检索结合，用低成本方式保留实体关系和全局关联。

这些方法说明一个趋势：未来知识系统不会只依赖单层向量索引，而会同时使用多种访问路径。

适用场景

LLM Wiki 适合长期沉淀、强关联、持续迭代的知识资产。

典型场景包括代码仓库、API 文档、产品需求、项目交付手册、制度规范、会议纪要和客户项目知识。它们的共同特点是：不是只问一次，而是会长期维护；不是只有文本，而是有实体、关系、版本和权限；不是只要答案，而是要能追溯知识结构。

它不适合超实时数据，例如高频交易、IoT 实时流、系统实时日志。这些场景应该优先使用数据库、时序系统、日志系统或专门监控平台，再让 Agent 按需调用。

五、其他相关路线：不是替代，而是增强

除了长上下文、Agentic Retrieval 和 LLM Wiki，还有几类技术经常被放在替代 RAG的讨论中，但更准确地说，它们是 RAG 的增强。

GraphRAG

GraphRAG 用图结构补足向量检索的弱点。它适合全局性问题，例如“这个项目有哪些主要风险”“某个客户投诉背后的关联流程是什么”。普通 RAG 更擅长找局部证据，GraphRAG 更擅长跨文档关系和全局摘要。

RAPTOR

RAPTOR 用树状摘要解决长文档检索问题。底层是原始文本，上层是逐级摘要。查询可以命中具体片段，也可以命中高层摘要。它适合长文档、论文集合、报告集合和需要不同粒度理解的知识库。

LightRAG

LightRAG 试图用更轻量的图结构和向量检索结合，降低 GraphRAG 的工程成本。它的价值在于提醒我们：结构化知识不一定要上来就做重型知识图谱，轻量实体关系也能显著改善检索。

Fine-tuning

微调不能替代动态知识库。微调适合学习风格、格式、领域语言和稳定模式，不适合频繁更新的事实知识。企业制度、产品价格、项目进度、客户状态这类信息仍然需要外部知识系统。

Memory 和 Prompt Cache

记忆、上下文压缩和 Prompt Cache 可以降低重复输入成本，改善长任务体验。但它们不解决知识来源、权限、更新和引用问题，因此不能单独替代 RAG。

六、技术选型

可以用下面这张表做初步判断。

更简洁的判断是：

读一遍、单文件、不怎么更新 -> Long Context
查多步、跨系统、找根因 -> Agentic Retrieval
要沉淀、强关联、长期维护 -> LLM Wiki
海量文档、低成本、常规问答 -> Classic RAG

七、小结

RAG 的本质不是向量数据库，而是外部知识接入机制。只要模型需要使用参数外知识，就仍然需要某种形式的 RAG。变化在于，外部知识不一定总是以chunk + vector + top-k的形式进入模型。

长上下文把检索前移为直接阅读，适合小规模、静态、完整性要求高的任务。

Agentic Retrieval 把检索变成行动，适合复杂、多步、跨系统任务。

LLM Wiki 把知识处理前移到摄入阶段，适合长期维护的企业知识资产。

从工程角度看，未来更常见的系统不会是单一路线，而是混合架构：小文档直接长上下文，大文档先 RAG，复杂问题走 Agentic Retrieval，长期知识资产逐步 Wiki 化，底层再结合向量、BM25、图谱、权限和时间索引。

因此，真正需要被淘汰的不是 RAG，而是没有边界设计、没有结构化知识、没有评估体系的朴素 RAG。