基于上传 PDF《那些媒体宣称可以替代RAG的技术》整理，并结合公开资料进行补充校验。
主题：Long Context、Agentic Retrieval、LLM Wiki 与企业级 RAG 演进路线。
检索日期：2026-05-22
1. 核心结论
一句话结论：Long Context、Agentic Retrieval、LLM Wiki 都不是对 RAG 的简单“替代”，更准确地说，它们是 RAG 在不同场景下的增强、重构或上层工程化形态。
1.1 结论摘要
| 技术方向 | 是否能替代 RAG | 更准确的定位 | 最适合场景 |
|---|---|---|---|
| Long Context / 超长上下文 | 局部可以 | 小体量知识库、单文档深度阅读方案 | 合同、财报、说明书、代码 PR Review |
| Agentic Retrieval | 不是替代，而是升级 | 让 LLM 主动规划检索路径的“智能检索编排” | 故障排查、根因分析、跨系统问答、复杂客服 |
| LLM Wiki | 不是替代，而是知识底座重构 | 将企业知识从碎片 Chunk 升级为结构化、可导航、可持续演化的知识系统 | 企业制度、产品文档、代码知识库、长期知识资产 |
| 传统 RAG | 仍是基石 | 企业知识问答的基础检索增强架构 | 海量文档、权限隔离、多租户、低成本高并发查询 |
最终企业级建议：不要在“RAG vs 替代品”之间二选一，而是构建 Hybrid RAG：Long Context + Hybrid Search + Rerank + Agentic Retrieval + LLM Wiki。
2. 传统 RAG 的本质与问题
传统 RAG 的核心流程一般是：
用户问题 Query
-> Embedding 向量化
-> Vector Search / BM25 Search
-> Top-k Chunk 召回
-> 拼接上下文
-> LLM 生成答案
它解决了大模型的三个核心问题：
- 知识不可更新：通过外部知识库让模型使用最新知识；
- 幻觉问题：通过引用外部证据降低胡编概率；
- 私有知识缺失：让模型访问企业内部文档、数据库、工单、日志等。
但传统 RAG 也存在明显短板：
| 问题 | 表现 |
|---|---|
| 检索链路固定 | Query -> Retrieve -> Generate，一次性检索，很难主动补查 |
| Chunk 语义割裂 | 固定大小切块可能切断表格、章节、代码逻辑、跨页引用 |
| Top-k 召回有限 | 只看相似度最高片段，可能漏掉间接相关信息 |
| 缺少多跳推理 | 很难完成“先查 A，再根据 A 查 B，最后综合判断”的任务 |
| 权限与实时性复杂 | 企业场景需要 ACL、多租户、增量更新、审计、数据血缘 |
所以，所谓“替代 RAG”的技术，本质上都在针对这些短板做增强。
3. Long Context：超长上下文
3.1 核心思想
Long Context 的思路非常直接：不再先检索 Chunk，而是把完整文档或大段知识直接放进模型上下文，让模型一次性阅读和推理。
传统 RAG：知识库 -> 检索 -> 拼接 Top-k -> LLM
Long Context：完整文档 / 小型知识库 -> LLM
3.2 优势
| 优势 | 说明 |
|---|---|
| 保留完整语境 | 不会因为 Chunk 切分导致上下文断裂 |
| 适合单文档精读 | 合同、财报、审计报告、产品手册等场景效果好 |
| 架构简单 | 不一定需要向量库、索引服务、召回链路 |
| 适合代码逻辑审查 | 代码调用链、配置上下文、PR 变更逻辑更完整 |
3.3 局限
| 局限 | 说明 |
|---|---|
| 成本高 | 输入 Token 越长，推理成本和延迟越高 |
| 无法承载海量知识 | 10TB 级企业知识库不可能一次性塞进上下文 |
| 注意力衰减 | 长上下文模型并不一定能稳定利用上下文中间位置的信息 |
| 权限控制困难 | 多租户、多角色、字段级权限仍需要检索系统控制 |
| 更新不经济 | 高频变化数据如果每次全量输入，成本不可接受 |
公开研究也指出，长上下文模型虽然能接收更长输入，但当相关信息位于上下文中间时，模型表现可能明显下降，这就是常说的 Lost in the Middle 问题。
3.4 适用判断
可以使用 Long Context 的典型判断口诀：
读一遍、单文件、不常改 -> Long Context。
适合：
- 法律合同深度审阅；
- 财务审计报告分析；
- 产品说明书问答；
- 代码 PR / 单仓库片段 Review；
- 会议纪要总结。
不适合：
- 百万级文档检索；
- 高频更新知识库；
- 多系统跨源查询；
- 强权限隔离场景；
- 对低延迟、低成本要求极高的在线问答。
4. Agentic Retrieval：从被动检索到主动推理
4.1 核心思想
Agentic Retrieval 的核心不是“检索一次”，而是让 LLM 变成检索流程的决策者：
Reason -> Retrieve -> Observe -> Decide -> Repeat -> Answer
也就是：
- Reason：分析用户问题，拆解任务；
- Retrieve：决定调用哪个工具检索；
- Observe：观察检索结果；
- Decide：判断信息是否足够；
- Repeat：不够则继续查，足够才回答。
它的关键变化是：
Retrieval becomes Reasoning：检索不再是固定系统行为，而是推理过程的一部分。
4.2 ReAct 模式
Agentic Retrieval 常见底层范式是 ReAct：
Thought：思考下一步需要什么信息
Action：调用搜索、数据库、日志、API 等工具
Observation：观察工具返回结果
循环执行，直到证据足够。
示例：用户问“为什么最近退款率升高？”
Thought：可能与支付接口失败、APP 新版本、客服策略变化有关
Action：查询最近 7 天退款失败日志
Observation：发现支付宝接口失败率异常上升
Thought：继续检查支付系统近期是否发布过新版本
Action：查询发布记录与配置变更
Observation：发现新版本修改了支付宝回调验签逻辑
Answer：退款率升高的根因是支付系统版本更新导致接口失败率上升
4.3 企业级五层架构
| 层级 | 作用 | 常见实现 |
|---|---|---|
| Tool Layer 工具层 | 连接外部数据源 | 向量检索、BM25、SQL、日志平台、API、知识图谱 |
| Planner 规划器 | 决定下一步做什么 | Prompt Planner、规则 Planner、模型 Planner |
| Memory 记忆层 | 保存已查信息和中间结论 | Redis、MySQL、PostgreSQL、向量记忆 |
| Reasoning Loop 推理循环 | 控制 Think-Act-Observe | LangGraph、自研状态机、Agent Runtime |
| Execution Runtime 执行运行时 | 状态管理、并发、错误处理 | LangGraph、AutoGen、CrewAI、自研工作流引擎 |
4.4 企业落地必须加的控制
Agentic Retrieval 很强，但不能无限制运行。生产环境必须设计以下机制：
| 控制项 | 必要性 |
|---|---|
| max_steps 最大步数 | 防止无限循环 |
| tool_timeout 工具超时 | 防止慢查询拖垮服务 |
| budget_token / budget_cost | 控制 Token 和调用成本 |
| confidence_score | 判断证据是否足够 |
| source_trace | 记录调用链路，方便审计 |
| fallback | Agent 失败时退回普通 RAG |
| permission_check | 每次工具调用都必须校验权限 |
4.5 适用判断
选择口诀：
查多步、跨系统、找根因 -> Agentic Retrieval。
适合：
- 支付失败、退款异常、订单状态异常的根因分析；
- 跨 CRM、工单、合同、财务系统的复杂问答；
- 客服疑难问题处理；
- 运维日志分析；
- 复杂合规审查。
不适合：
- 简单 FAQ；
- 强低延迟场景；
- 检索路径很固定的问题；
- 工具权限和审计没有建设好的系统。
5. LLM Wiki：从碎片化知识到结构化知识系统
5.1 核心思想
LLM Wiki 不是把文档简单切成 Chunk，而是把知识组织成类似 Wikipedia / Confluence 的结构化知识空间。
传统 RAG：
Document -> Chunk -> Embedding -> Top-k -> Answer
LLM Wiki：
Raw Sources -> Page -> Summary -> Entity -> Link -> Graph -> Index -> Navigation -> Answer
它的目标是：
Structured Knowledge > Fragments：结构化知识优于碎片化片段。
5.2 关键能力
5.2.1 页面化 Page-based Knowledge
传统 Chunk 切分容易丢失主题边界。页面化会保留：
- page_id；
- title；
- content；
- summary；
- parent_id；
- children；
- related_pages；
- source_refs。
示例对象：
{
"page_id": "refund_policy_001",
"title": "退款规则",
"content": "...",
"summary": "说明退款申请、审批、原路退回和金额限制规则",
"parent_id": "finance_policy",
"children": ["refund_apply", "refund_approve"],
"related_pages": ["payment_callback", "invoice_policy"]
}
5.2.2 双向链接 Bi-directional Links
让知识不再是孤立文本，而是可以互相跳转的网络。
示例：
退款规则 <-> 财务审批 <-> 发票制度 <-> 税务政策
反向索引示例：
{
"API Key": ["OpenAI API 文档", "系统权限管理规范", "API 鉴权机制说明"]
}
5.2.3 层级目录 Hierarchy Tree
让模型先定位大类，再逐步展开细节。
财务制度
├── 报销制度
│ ├── 差旅报销
│ └── 餐饮报销
└── 发票制度与合规
5.2.4 实体关系 Entity Relationship
从文本中抽取实体与关系，构建知识图谱。
原文：张三负责 Apollo 项目。Apollo 项目服务于腾讯。
抽取：
(张三, 负责, Apollo)
(Apollo, 客户, 腾讯)
存储可以选择：
- Neo4j；
- NebulaGraph；
- JanusGraph；
- PostgreSQL + pgvector + adjacency table；
- Elasticsearch / OpenSearch + 图结构字段。
5.2.5 自动摘要 Auto Summary
摘要可以分层生成：
| 摘要层级 | 说明 |
|---|---|
| Chunk Summary | 对最小语义单元摘要 |
| Page Summary | 对页面聚合摘要 |
| Section Summary | 对章节或文档整体摘要 |
| Query-aware Summary | 根据用户问题动态生成面向问题的摘要 |
5.2.6 自动索引 Auto Indexing
企业级知识系统不能只靠 Vector，推荐多索引组合：
BM25 + Vector + Entity + Graph + Hierarchy + Temporal + Permission
| 索引类型 | 解决的问题 |
|---|---|
| BM25 | 关键词精准匹配 |
| Vector | 语义相似召回 |
| Entity | 人名、项目名、接口名等实体定位 |
| Graph | 多跳关联与路径推理 |
| Hierarchy | 目录导航与章节扩展 |
| Temporal | 时间过滤、版本过滤 |
| Permission | 数据权限、租户隔离 |
5.3 LLM Wiki 三层架构
| 层级 | 说明 | 价值 |
|---|---|---|
| Raw Layer 原始数据层 | PDF、Word、代码、数据库、会议纪要、IM 记录 | 保留事实源头，可追溯 |
| Wiki Layer 编译输出层 | 页面、摘要、实体、链接、图谱、索引 | 将原始资料编译成 LLM 友好的知识空间 |
| Schema Layer 控制协议层 | 页面模板、实体规范、命名规则、链接规则 | 保证知识长期一致、可维护 |
本质变化：
Query-time Intelligence 查询时理解
-> Ingest-time Intelligence 摄入时编译
即：不要每次用户提问时才临时理解文档，而是在数据进入系统时就完成结构化、摘要化、链接化和索引化。
5.4 知识更新流水线
企业级 LLM Wiki 的更新不是“新增文档后向量化入库”这么简单，而是类似代码编译的过程：
Change Detection 变更检测
-> Document Parsing 文档解析
-> Entity Extraction 实体抽取
-> Link Analysis 链接分析
-> Page Update 页面更新
-> Summary Rebuild 摘要重建
-> Graph Update 图谱更新
-> Index Refresh 索引刷新
-> Consistency Check 一致性检查
5.5 现实挑战
| 挑战 | 说明 |
|---|---|
| 构建成本高 | 需要解析、抽取、链接、图谱、索引、增量更新等完整工程链路 |
| 更新复杂 | 一个实体变更可能影响多个页面、摘要、链接和图谱关系 |
| 命名漂移 | 同一实体可能有多个名字，如“支付宝回调”“AliPay Callback” |
| 链接爆炸 | 自动链接过多会导致知识图谱噪声过大 |
| 摘要失效 | 底层内容变化会导致上层摘要需要重建 |
| 不适合超实时数据 | 高频日志、股票、IoT 流数据更适合实时查询系统 |
5.6 适用判断
选择口诀：
要沉淀、强关联、常更新 -> LLM Wiki。
适合：
- Git 代码仓库、PR、Issue、接口文档；
- 产品需求文档、技术设计文档、会议纪要；
- 财务、人事、合规制度；
- 企业长期知识资产；
- 多版本、多实体、多关系、多引用的知识系统。
不适合：
- 一次性临时问答；
- 高频实时日志；
- 只需简单 FAQ 的场景；
- 没有工程团队维护的轻量项目。
6. 三种技术对比
| 维度 | Long Context | Agentic Retrieval | LLM Wiki | 传统 RAG |
|---|---|---|---|---|
| 核心思想 | 全文直喂模型 | LLM 主动规划检索 | 知识结构化编译 | 检索相关 Chunk |
| 解决重点 | 上下文完整性 | 多步推理与跨源查询 | 知识长期组织与演化 | 知识外部化与低成本召回 |
| 系统复杂度 | 低 | 中高 | 高 | 中 |
| 成本 | Token 成本高 | 工具调用成本高 | 构建维护成本高 | 相对可控 |
| 延迟 | 长文本时较高 | 多步调用时较高 | 取决于索引设计 | 通常较低 |
| 适合数据规模 | 小到中 | 中到大 | 中到大 | 大规模 |
| 适合数据更新 | 低频 | 中频 | 中高频但需编译 | 中高频 |
| 适合复杂推理 | 中 | 高 | 高 | 中低 |
| 权限控制 | 较难 | 可做但复杂 | 可做但复杂 | 成熟 |
| 企业落地优先级 | 作为补充 | 第二阶段增强 | 第三阶段知识资产化 | 第一阶段基础能力 |
7. 企业级推荐架构：Hybrid RAG
推荐架构不是替换 RAG，而是在 RAG 基础上叠加多层能力。
数据源层
PDF / Word / Excel / Markdown / Git / DB / CRM / 工单 / 日志
|
v
Raw Layer 原始数据湖
MinIO / OSS / S3 / Git / MySQL / PostgreSQL
|
v
Ingestion Pipeline 摄入流水线
文档解析 -> 清洗 -> 页面化 -> Chunk -> 摘要 -> 实体抽取 -> 链接分析
|
v
Index Layer 索引层
Elasticsearch/OpenSearch(BM25)
Milvus/pgvector(Vector)
Neo4j/NebulaGraph(Graph)
MySQL/PostgreSQL(Metadata + ACL)
|
v
Retrieval Layer 检索层
Hybrid Search -> Rerank -> Context Packing -> Citation Builder
|
v
Agentic Layer 智能体层
Planner -> Tool Calling -> Memory -> Reasoning Loop -> Runtime
|
v
LLM Answer Layer 回答层
答案生成 -> 来源引用 -> 置信度 -> 审计日志 -> 人工反馈
7.1 Java / Spring Boot 落地建议
如果采用 Java 后端技术栈，可以拆成以下模块：
rag-platform
├── rag-api # REST / SSE / WebSocket 接口
├── rag-ingestion # 文档摄入、解析、切分、摘要、抽取
├── rag-index # ES / Milvus / Neo4j / MySQL 索引写入
├── rag-retrieval # 混合检索、重排、上下文组装
├── rag-agent # Planner、Tool Registry、Reasoning Loop
├── rag-wiki # Page、Link、Entity、Hierarchy、Summary
├── rag-permission # 租户、角色、文档 ACL、字段权限
├── rag-evaluation # Recall、Faithfulness、Latency、Cost 评估
└── rag-common # DTO、异常、工具类、审计日志
7.2 推荐技术选型
| 能力 | 推荐组件 |
|---|---|
| 文档存储 | MinIO / S3 / OSS |
| 元数据 | MySQL / PostgreSQL |
| 向量库 | Milvus / pgvector / Elasticsearch Vector |
| 关键词检索 | Elasticsearch / OpenSearch |
| 图数据库 | Neo4j / NebulaGraph |
| Rerank | BGE Reranker / Qwen Rerank / Cohere Rerank |
| Java LLM 框架 | LangChain4j / Spring AI |
| Agent Runtime | LangGraph 可参考思想，自研 Java 状态机也可 |
| 队列 | RabbitMQ / Kafka |
| 缓存 | Redis |
| 权限 | RBAC + ABAC + 文档 ACL |
| 观测 | Prometheus + Grafana + ELK / OpenTelemetry |
8. 分阶段实施路线
阶段 1：先把传统 RAG 做扎实
目标：可用、稳定、可追溯。
- 文档上传、解析、清洗；
- Chunk 切分策略；
- Embedding 入库；
- BM25 + Vector 混合检索；
- Rerank 重排；
- 上下文拼接；
- 答案引用来源；
- 权限过滤；
- 失败兜底。
关键指标：
- Recall@k；
- MRR / NDCG；
- 答案引用覆盖率；
- 幻觉率；
- 平均延迟；
- 单次问答成本。
阶段 2：加入 Retrieval 增强
目标：提高召回质量。
- Query Rewrite；
- Multi Query；
- HyDE；
- Contextual Embedding；
- Contextual BM25；
- Rerank；
- Metadata Filter；
- Parent-Child Retrieval。
阶段 3：加入 Agentic Retrieval
目标：支持复杂问题和跨系统查询。
- Tool Registry；
- Planner；
- Memory；
- Reasoning Loop；
- max_steps；
- tool_timeout；
- source_trace；
- confidence_score；
- fallback_to_rag。
阶段 4：建设 LLM Wiki
目标：把文档库升级为企业知识资产。
- Page Object；
- Hierarchy Tree；
- Entity Extraction；
- Bi-directional Links；
- Auto Summary；
- Graph Index；
- Incremental Recompilation；
- Consistency Check。
阶段 5：评估与治理
目标：可持续运营。
- 建立黄金问题集；
- 建立人工标注集；
- 自动化评测；
- 召回链路埋点；
- Token 成本监控；
- 用户反馈闭环；
- 知识新鲜度检测；
- 权限审计。
9. 最终选型建议
9.1 决策表
| 你的场景 | 推荐方案 |
|---|---|
| 单份合同、财报、说明书，需要完整阅读 | Long Context |
| 文档很多，但问题简单，主要是知识问答 | 传统 RAG + Hybrid Search + Rerank |
| 问题需要多步查询、跨多个系统找证据 | Agentic Retrieval |
| 文档长期维护、关系复杂、版本频繁变化 | LLM Wiki |
| 企业级知识中台 | Hybrid RAG：四者组合 |
9.2 最实用落地结论
- 不要一上来就做 LLM Wiki：先把传统 RAG 的检索、权限、引用和评测做好。
- Long Context 适合补充，不适合承载全部企业知识库。
- Agentic Retrieval 适合复杂问题，但必须有限制、有审计、有兜底。
- LLM Wiki 是长期知识资产方向，但工程成本最高。
- 企业最终形态大概率是 Hybrid：普通问题走 RAG，复杂问题走 Agent，结构知识走 Wiki，单文档精读走 Long Context。
10. 参考资料
以下资料用于联网补充与事实校验。
- Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv, 2020.
arxiv.org/abs/2005.11… - Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL / arXiv, 2024.
aclanthology.org/2024.tacl-1… - Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR, 2023.
arxiv.org/abs/2210.03… - Google Research Blog, ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
research.google/blog/react-… - LangChain Docs, LangGraph Overview.
docs.langchain.com/oss/python/… - Andrej Karpathy, LLM Wiki, Gist, 2026.
gist.github.com/karpathy/44… - Anthropic, Contextual Retrieval in AI Systems, 2024.
www.anthropic.com/news/contex…
11. 一句话总结
RAG 不会被简单替代，它会从“固定检索流水线”进化为“可规划、可导航、可结构化、可持续演化的企业知识操作系统”。
