可以替代 RAG 的技术

主题：超长上下文、Agentic Retrieval 与 LLM Wiki 深度解析
核心问题：这些技术到底是在“替代 RAG”，还是在“升级 RAG”？

一、先理解传统 RAG 的本质

传统 RAG 本质上是一条固定的检索流水线：

Query → Embedding → Search → Top-k → Answer

具体流程是：

1. 用户提出问题；
2. 系统将问题转成向量；
3. 到向量数据库中检索相似内容；
4. 取相似度最高的 Top-k 文档片段；
5. 把这些片段作为上下文交给 LLM，让模型生成答案。

这个流程的优点是简单、稳定、容易落地。但它也有明显问题：

• 检索逻辑是固定的，系统运行前就决定了搜索策略和召回数量；
• LLM 只负责“读检索结果并总结”，不参与检索决策；
• Top-k 返回的是相似片段，不一定是真正能回答问题的内容；
• 文档被切成 chunk 后，容易丢失页面结构、上下文关系和整体逻辑。

所以，很多所谓“替代 RAG”的技术，其实是在解决传统 RAG 的这些缺陷。

---

二、超长上下文：直接把完整资料喂给模型

1. 它是什么

超长上下文的思路很直接：

传统 RAG：知识库 → 检索 → 拼接 → 模型
超长上下文：完整文档库 → 直接输入 → 模型

也就是说，它试图绕过传统 RAG 中“检索”和“拼接”的步骤，直接把完整文档、代码仓库、会议记录、合同或说明书放进模型上下文中，让模型基于完整内容进行推理。

2. 它解决了什么问题

传统 RAG 最大的问题之一，是把文档切成 chunk 后可能造成信息割裂。

比如合同、财报、代码、制度文件，很多信息需要结合全文理解。只检索几个片段，很容易漏掉前后文、跨页引用、表格关系或代码调用链。

超长上下文的价值就在于：

• 避免 chunk 切分造成的上下文断裂；
• 更适合处理单文档、长文档、强逻辑文档；
• 对合同审阅、财报分析、代码 Review、会议纪要理解比较友好；
• 从“片段理解”变成“全局推理”。

3. 它为什么不能完全替代 RAG

虽然大模型的上下文窗口越来越长，但“能放进去”不等于“能稳定用好”。

主要限制有三个：

1. 知识库规模受限
   企业级知识库可能是百万文档、TB 级数据，不可能每次都全部塞进上下文。

2. 成本和延迟较高
   上下文越长，输入 token 越多，推理成本和响应延迟都会上升。

3. 注意力衰减问题
   模型在超长上下文中并不一定能均匀关注所有内容，可能出现“中间遗忘”或信息利用不稳定。

4. 适合使用的场景

超长上下文适合这些情况：

• 一次性处理；
• 单文档为主；
• 文档更新频率低；
• 需要完整阅读原文；
• 不希望被 chunk 切碎。

典型场景：

• 合同审查；
• 财务审计报告分析；
• 产品说明书问答；
• 大型代码文件或 PR Review；
• 静态长文档问答。

可以用一句话记住：

读一遍、单文件、不改了 → 可以优先考虑 Long Context

---

三、Agentic Retrieval：让模型主动决定怎么查

1. 它是什么

Agentic Retrieval 不是简单地做一次检索，而是让 LLM 参与整个检索过程。

传统 RAG 是：

Query → Retrieve → Generate Answer

Agentic Retrieval 是：

Reason → Retrieve → Observe → Decide → Repeat

也就是让模型自己判断：

• 搜什么；
• 什么时候搜；
• 下一步搜什么；
• 现有信息够不够；
• 是否需要继续检索；
• 是否可以结束并生成答案。

它的核心变化是：

Retrieval becomes Reasoning
检索变成推理过程的一部分

2. 它和传统 RAG 的区别

传统 RAG 更像一次固定搜索：

输入问题 → 检索一次 → 生成答案

Agentic Retrieval 更像一个会查资料的助手：

先分析问题
→ 制定检索计划
→ 调用工具查资料
→ 看结果是否足够
→ 不够就继续查
→ 最后再回答

这就从“一次性检索”变成了“循环式推理”。

3. ReAct Pattern：核心实现方式

Agentic Retrieval 里经常使用 ReAct 模式。

ReAct 的核心循环是：

Thought → Action → Observation

对应到实际系统中就是：

1. Thought：思考
   模型根据当前问题和已有信息，判断下一步该做什么。

2. Action：行动
   调用工具，比如搜索日志、查询数据库、访问知识库、调用 API。

3. Observation：观察
   读取工具返回结果，判断是否找到关键信息。

这个循环会持续进行，直到模型认为证据足够，才输出最终答案。

4. 一个例子：追踪退款率升高原因

用户问：

为什么退款率最近升高？

Agent 可能这样处理：

Thought：退款率升高可能和支付接口失败、App 新版本、客服策略变化有关。
Action：查询最近 7 天退款失败日志。
Observation：发现支付宝接口调用失败率异常上升。
Thought：需要确认支付系统最近是否有代码更新。
Action：查询支付系统版本更新记录。
Observation：发现近期支付模块有配置变更。
Answer：退款率升高主要由支付接口异常导致，根因可能是近期配置变更。

这种问题如果只做一次 RAG 检索，很难完整定位原因。

5. 技术实现的五层架构

Agentic Retrieval 通常包含五层：

层级	作用
Tool Layer 工具层	提供检索、数据库查询、API、知识图谱等工具
Planner 规划器	判断下一步应该调用哪个工具
Memory 记忆层	记录已搜索内容、已知事实、历史操作和上下文
Reasoning Loop 推理循环	执行“思考-行动-观察”的循环
Execution Runtime 执行运行时	负责状态管理、并发控制、错误处理和任务编排

其中 Runtime 很重要。因为 Agent 不是一次函数调用，而是一个长生命周期工作流，需要处理状态、循环、中断、恢复、错误和多工具协作。

常见框架包括：

• LangGraph；
• AutoGen；
• CrewAI；
• OpenAI Agents SDK。

6. 适合使用的场景

Agentic Retrieval 适合：

• 多步查询；
• 跨系统检索；
• 需要查根因；
• 问题不标准；
• 需要动态调整检索路径。

典型场景：

• 复杂故障排查；
• 退款失败、支付异常、系统 Bug 根因分析；
• 跨 CRM、合同、财务、项目文档的复杂咨询；
• 客服疑难问题处理；
• 多源信息整合。

可以用一句话记住：

查多步、跨系统、找根因 → 首选 Agentic Retrieval

---

四、LLM Wiki：把知识变成可导航的结构化系统

1. 它是什么

LLM Wiki 的核心思想是：

不要只把知识切碎成 chunk，而是保留知识结构。

传统 RAG 把文档切成很多碎片，容易丢失上下文、层级关系、页面归属和实体关联。

LLM Wiki 则试图把企业知识整理成类似 Wikipedia 或 Confluence 的结构化知识系统，让 LLM 可以像人一样阅读、跳转、导航和推理。

2. 它解决了什么问题

传统 RAG 的问题是“碎片化”：

文档 → chunk → 向量 → Top-k → 答案

LLM Wiki 试图变成“结构化知识空间”：

页面 → 摘要 → 实体 → 链接 → 目录 → 图谱 → 导航

它不是只关心“搜到哪个片段”，而是关心：

• 这个知识属于哪个页面；
• 这个页面属于哪个章节；
• 这个实体和哪些实体有关；
• 这个概念被哪些页面引用；
• 当前问题是否需要跳转到关联页面继续探索。

3. LLM Wiki 的几个核心能力

3.1 页面化 Page-based Knowledge

传统 RAG 常按固定长度切 chunk，可能把一个完整主题切成上下两半。

LLM Wiki 会把文档解析成 Page Object，例如：

page_id
title
content
summary
parent
children
links

这样可以保留页面主题和上下文边界。

3.2 双向链接 Bi-directional Links

借鉴 Wikipedia 的链接思想，把孤立文本变成关联网络。

例如：

退款规则 ↔ 财务审批 ↔ 发票制度 ↔ 税务政策

这样模型不只能找到直接匹配的内容，还能沿着链接做关联扩展和多跳推理。

3.3 层级目录 Hierarchy Tree

通过目录结构，让模型先定位大类，再进入具体章节。

例如：

财务制度
├── 报销制度
│   ├── 差旅报销
│   └── 餐饮报销
└── 发票制度与合规

这比在所有 chunk 里“大海捞针”更清晰。

3.4 实体关系 Entity Relationship

从文本里抽取实体和关系，形成知识图谱。

例如原文：

张三负责 Apollo 项目。Apollo 项目服务于腾讯。

可以抽取成：

(张三, 负责, Apollo)
(Apollo, 客户, 腾讯)

这样系统就可以做多跳推理。

3.5 自动摘要 Auto Summary

企业文档通常很长，LLM 不可能每次都读全文，所以需要摘要系统。

常见层级包括：

Chunk Summary → Page Summary → Section Summary

更高级的是 Query-aware Summary，也就是根据用户问题动态提取相关摘要，而不是只生成通用摘要。

3.6 自动索引 Auto Indexing

LLM Wiki 不只依赖向量索引，而是建立多种访问入口。

常见索引包括：

• Vector：语义检索；
• BM25：关键词检索；
• Entity：实体精确匹配；
• Graph：实体关系与多跳检索；
• Hierarchy：目录导航；
• Temporal：时间过滤；
• Permission：权限控制。

企业系统里常用混合搜索：

BM25 + Vector + Graph

3.7 Semantic Navigation 语义导航

传统 RAG 是 top-k 召回；LLM Wiki 更强调导航。

例如用户问：

退款失败为什么增多？

模型可能导航路径是：

退款规则 → 支付系统 → 版本更新 → Bug 报告 → 客服工单

这类似人类在维基百科中不断点击链接，从一个知识点跳到另一个知识点。

4. LLM Wiki 的三层架构

LLM Wiki 可以理解成三层：

层级	作用
Raw Layer 原始数据湖	保存 PDF、Word、代码、数据库、IM 记录等原始事实
Wiki Layer 编译输出层	生成页面、摘要、实体、链接、关系图等结构化知识
Schema Layer 控制协议	定义页面模板、实体 Schema、命名规范、链接规则

它的核心转变是：

从 Query-time Intelligence 转向 Ingest-time Intelligence
从“查询时临时理解”转向“摄入时提前编译”

也就是说，不要每次提问时才临时理解一堆碎片，而是在知识进入系统时，就把它整理成 LLM 更容易使用的结构。

5. LLM Wiki 的知识更新机制

传统 RAG 更新知识通常是：

新文档 → 切分 → 向量化 → 入库

这更像 Append-only，只是新增搜索素材。

LLM Wiki 的更新更像重新编译：

新知识 → 解析 → 重构 → 全局更新

完整更新流水线可能包括：

变更检测
→ 文档解析
→ 实体抽取
→ 关联分析
→ 页面更新
→ 摘要重建
→ 图谱更新
→ 索引刷新
→ 一致性检查

它不是简单加新文档，而是更新整个知识网络。

6. LLM Wiki 的挑战

LLM Wiki 很强，但落地并不简单。

主要挑战包括：

1. 构建成本高
   需要文档解析、页面拆分、实体提取、链接生成、图谱构建等工程处理。

2. 知识更新更难
   更新一个页面，可能影响摘要、链接、实体关系和图谱结构。

3. 实体命名容易混乱
   同一实体可能有多个名字，容易造成实体漂移。

4. 链接关系可能过量
   自动链接如果没有规则约束，会产生大量低价值关系。

5. 不适合超实时数据
   股票行情、IoT 实时流、系统实时日志等场景，更适合用时序数据库或实时查询工具。

7. 适合使用的场景

LLM Wiki 适合：

• 要长期沉淀；
• 强关联；
• 常更新；
• 需要形成企业级知识资产。

典型场景：

• Git 代码仓库、PR、Issue、API 文档；
• 产品需求文档、项目交付手册、技术会议纪要；
• 财务制度、人事流程、合规政策；
• 需要版本记录、实体关系、知识跳转的复杂知识体系。

可以用一句话记住：

要沉淀、强关联、常更新 → 首选 LLM Wiki

---

五、三种技术如何选择

这三种技术并不是简单的“谁替代谁”，而是适合不同场景。

技术	核心能力	适合场景	不适合场景
超长上下文	直接读完整文档	单文档、低更新、一次性精读	海量知识库、高频更新、低延迟要求
Agentic Retrieval	多步推理式检索	查根因、跨系统、多数据源复杂问题	简单 FAQ、固定问答、小知识库
LLM Wiki	结构化知识导航	企业知识沉淀、强关联、长期维护	超实时数据、高频流式数据、短期临时资料

---

六、最终总结

所谓“替代 RAG”的技术，大多数并不是完全替代 RAG，而是在不同方向上补足传统 RAG 的短板。

可以这样理解：

传统 RAG：解决“怎么从知识库里找片段”
超长上下文：解决“怎么完整读长文档”
Agentic Retrieval：解决“怎么主动、多步、跨系统地查资料”
LLM Wiki：解决“怎么把企业知识结构化、可导航、可持续演化”

更准确的判断是：

Long Context 适合读完整文档；
Agentic Retrieval 适合复杂问题追踪；
LLM Wiki 适合企业知识资产建设；
RAG 仍然是大规模知识问答的基础设施。

未来企业知识系统很可能不是单选，而是组合使用：

基础知识库用 RAG
长文档分析用 Long Context
复杂任务用 Agentic Retrieval
长期知识沉淀用 LLM Wiki

所以，真正的趋势不是“谁替代 RAG”，而是：

RAG 正在从简单检索问答，升级为更完整的企业知识智能系统。