LLM‑Wiki vs RAG，以及“RAG要被替代”的真相
2026年9月5日大约 5 分钟
LLM‑Wiki vs RAG，以及“RAG要被替代”的真相
LLM‑Wiki 是 Karpathy 提出的知识编译范式；传统RAG是查询时检索拼接范式。 核心一句话：传统RAG是提问现场翻原始碎片；LLM‑Wiki是提前让AI把资料编译成互相链接的百科知识库再查询。 ❗重点：RAG并没有被彻底替代，只是朴素Naive‑RAG暴露出大量短板，出现多种升级路线（Agentic‑RAG、GraphRAG、LLM‑Wiki），网络上“RAG已死”是营销化夸张说法。
一、原理对比
传统RAG（Naive RAG）
流程：文档切分Chunk → Embedding入库 → 用户提问 → 向量相似度召回片段 → 把碎片塞给LLM生成答案。
- 计算发生在查询时刻，每次提问重新检索、重新做综合推理。
- 原始资料不做深度融合，文档之间互相隔离。
- 只存原始切片，知识不会沉淀，同一个主题每次都要重新拼凑。
LLM‑Wiki
流程：原始源文件(raw) → 摄入(Ingest)阶段LLM深度阅读，提炼、合并、建立双向链接，输出一批结构化Markdown Wiki页面 → 查询时检索Wiki页面回答。
- 计算重心前置到文档摄入阶段；查询阶段只是读取已经整理好的知识页面。
- 新增资料进来，自动更新关联页面、标记矛盾、维护双链，知识具备复利积累。
- 原始源文件保留不动，Wiki是编译后的产物，支持人工编辑、Git版本管理。
| 对比维度 | 传统RAG | LLM‑Wiki |
|---|---|---|
| 核心模式 | Retrieve & Generate（检索‑生成） | Compile & Query（编译‑查询） |
| 处理时机 | 查询时做推理、拼接 | 录入时完成理解、关联、综合 |
| 存储内容 | 原始文本Chunk向量 | 结构化Wiki页面、双向链接、来源引用 |
| 跨文档综合 | 每次提问临时拼凑，容易断裂 | 录入阶段就完成跨源综合，持久保存 |
| 知识沉淀 | 几乎无，用完即抛 | 强；新信息自动更新相关页面 |
| 矛盾检测 | 弱，很难发现文档冲突 | Ingest/Lint阶段自动识别矛盾、过时信息 |
| 写入成本 | 低，主要是Embedding | 高，大量LLM调用做编译 |
| 查询成本 | 每次检索+重排 | 查询开销低，读整理好的页面 |
| 适合规模 | 大规模海量文档 | 中小规模、需要深度沉淀的知识库 |
| 缺点 | 碎片割裂、跨文档推理差、召回不稳定 | 写入开销大；数据巨变时需要重新编译 |
补充：LLM‑Wiki内部也可以用向量检索，检索对象不再是原始chunk，而是编译后的wiki页面，二者不是完全互斥。
二、传统RAG的原生痛点（为什么大家喊“RAG要被替代”）
说的要被替代的，特指朴素Naive‑RAG流水线，不是检索增强这个思想本身。
- 每次查询从零开始，知识没有积累 几十万份文档切成碎片，向量库只存切片；两个文档的关联关系，每次提问都要LLM重新推导。同一个问题反复问，模型每次都要重新拼碎片，不会把之前的洞察保存下来。
- 向量相似度不等于语义理解 向量检索靠余弦相似度，经常出现“文本长得像，但语义无关”；跨多篇文档的综合问答，很容易上下文窗口塞不下，丢失逻辑链条，答案碎片化。
- 线性静态流水线，没有反思闭环 朴素RAG：query→检索→直接生成。 不会判断：检索的片段够不够？有没有矛盾？要不要换检索策略？拿到坏结果也直接输出。
- 更新痛苦 源文档修改，需要重新切分、重新Embedding、重建索引，很难做增量细粒度更新。
但：RAG这套检索增强思想没有死，演化出三条主流升级路线：
- Agentic‑RAG：把检索变成Agent的工具；模型自己决定何时检索、检索几次、是否需要改写query、验证结果，循环反思迭代，RAG被Agent化改造。
- GraphRAG：抽取实体‑关系构建图，解决跨文档关系推理，本质还是RAG体系的增强。
- LLM‑Wiki：切换范式，前置编译，产出结构化知识资产。
三、LLM‑Wiki的短板，不是银弹
很多宣传会夸大LLM‑Wiki，它有明确局限：
- Ingest写放大严重：一份新资料摄入，可能要联动更新十几份wiki页面，消耗大量token，写入成本很高。
- 数据规模天花板：不适合千万级海量原始文档；规模大之后wiki页面爆炸，维护、lint校验成本陡增。
- 信息延迟：源文档更新后，不会立刻生效，需要重新执行ingest编译，存在滞后。
- 编译引入新错误：LLM做摘要、合并、关联时，会引入幻觉，需要人工审核校验。
四、选型怎么判断
- 选传统RAG / Agentic‑RAG
海量原始文档、日志、网页，文档量巨大；
文档更新频繁，需要源数据变更立刻生效；
只需要“找到原文片段”，不需要长期沉淀知识资产；
企业客服、内部文档问答、海量非结构化数据，优先Agentic‑RAG。
- 选LLM‑Wiki
- 领域知识、笔记、研究资料，文档量级中等；
- 需要反复做跨文档综合、概念对比，知识需要持续迭代沉淀；
- 希望产出可人工阅读、可编辑、可版本管理的知识资产，不止用来问答。
五、一句话总结
- RAG≠过时：朴素的静态流水线Naive‑RAG缺陷很多，但检索增强思想持续进化为Agentic‑RAG、GraphRAG。
- LLM‑Wiki不是RAG替代品，是另一种范式：重心从“查询时检索碎片”切换为“录入时编译结构化知识资产”。
- 工程上经常组合：原始大文档库用RAG检索，把高价值信息摄入编译进LLM‑Wiki，Agent再调用Wiki做深度推理。