可以替代 RAG 的技术
先说结论：所谓“替代” RAG 的技术，其实大多不是在完全取代它，而是在不同的方向上补足传统 RAG 的短板。传统 RAG 简单、稳定、容易落地，但它的缺陷也很明显——检索逻辑固定、LLM 只负责总结、Top-k 返回的不一定是正确答案、文档切 chunk 后容易丢上下文。那么，有什么方案能解决这些问题？
一、先理解传统 RAG 的本质
说白了，传统 RAG 本质上就是一条相当“死板”的检索流水线：
Query → Embedding → Search → Top-k → Answer
具体怎么走的呢？用户提出问题，系统把问题转成向量，到向量数据库里检索相似内容，取出最像的 Top-k 个文档片段，再把这些片段作为上下文丢给 LLM，让模型基于这些碎片生成答案。
这条流水线的优点是简单、稳定、容易落地，但问题也摆在台面上：
- 检索逻辑是写死的，系统上线前就决定了搜索策略和召回数量；
- LLM 只扮演“读书总结员”，不参与检索决策；
- Top-k 返回的只是长得像的片段，不一定能真正回答问题；
- 文档被切成 chunk 后，页面结构、上下文关系和整体逻辑都容易丢失。
所以，市面上那些号称能“替代 RAG”的技术，其实很多都是在解决传统 RAG 的这些硬伤。
二、超长上下文：直接把完整资料喂给模型
1. 它是什么
超长上下文的思路非常直接：
传统 RAG：知识库 → 检索 → 拼接 → 模型
超长上下文：完整文档库 → 直接输入 → 模型
它试图绕过“检索”和“拼接”这两个步骤，直接把完整文档、代码仓库、会议记录、合同或说明书塞进模型上下文中，让模型基于完整内容进行推理。
2. 它解决了什么问题
传统 RAG 最让人头疼的问题之一，就是把文档切成 chunk 后的信息割裂。
想想看，合同、财报、代码、制度文件，很多信息需要结合全文才能理解。只检索几个片段，很容易漏掉前后文、跨页引用、表格关系或代码调用链。
超长上下文的价值在于：
- 避免了 chunk 切分造成的上下文断裂；
- 更适合处理单文档、长文档、强逻辑文档；
- 对合同审阅、财报分析、代码 Review、会议纪要理解相当友好；
- 把“片段理解”升级成了“全局推理”。
3. 它为什么不能完全替代 RAG
现在大模型的上下文窗口确实是越来越长了，但“能放进去”和“能稳定用好”之间，隔着不小的距离。
主要有三个限制：
知识库规模受限
企业级知识库可能是百万文档、TB 级数据，不可能每次都全部塞进上下文。成本和延迟较高
上下文越长，输入的 token 就越多，推理成本和响应延迟都会跟着往上涨。注意力衰减问题
模型在超长上下文中并不一定能均匀关注所有内容，容易出现“中间遗忘”或信息利用不稳定的情况。
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 模式，核心循环是：Thought → Action → Observation
对应到实际系统中就是：
- Thought（思考）：模型根据当前问题和已有信息，判断下一步该做什么。
- Action（行动）：调用工具，比如搜索日志、查询数据库、访问知识库、调用 API。
- 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 Na vigation）
传统 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 很强，但落地并不简单。
主要挑战包括：
- 构建成本高——需要文档解析、页面拆分、实体提取、链接生成、图谱构建等工程处理。
- 知识更新更难——更新一个页面，可能影响摘要、链接、实体关系和图谱结构。
- 实体命名容易混乱——同一实体可能有多个名字，容易造成实体漂移。
- 链接关系可能过量——自动链接如果没有规则约束，会产生大量低价值关系。
- 不适合超实时数据——股票行情、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 正在从简单检索问答，升级为更完整的企业知识智能系统。
