LLM Wiki：从朴素 RAG 到”知识编译系统”
一句话定位：当你被”RAG 已死”刷屏、又发现自己切块 + 向量召回的 RAG 总是答不准时读这篇。它讲的是一种把”理解知识的成本从查询时前移到入库时”的新范式——LLM Wiki，以及它的三层架构、七大能力、动态更新机制和落地代价。适合已经搭过朴素 RAG、想往企业级/高质量方向升级的人。
目录
- 1. 背景：「RAG 已死」是炒作吗
- 2. 核心结论（速查表）
- 3. 三层架构：Raw → Wiki → Schema
- 4. Wiki 层的七大能力
- 5. 动态知识维护：更新的触发机制
- 6. 实战对照：一个在建 RAG 系统的设计草案
- 7. 现实挑战与常见误区
- 8. 与本知识库其他章节的关联
- 9. 来源与局限性
1. 背景：「RAG 已死」是炒作吗
近一年”RAG 已死”的说法常被拿来当标题。结论先说清楚：
“RAG 已死”是炒作，但炒作背后戳中了一个真问题。
要分清死的到底是什么：
- 没死的：RAG 这个范式（先检索、再把资料喂给模型生成）依然是给大模型补充私有/新鲜知识的主流办法。
- 快被淘汰的：最原始的那套朴素 RAG 实现——把文档硬切块（chunking）→ 每块向量化 → 丢进向量库 → 相似度召回 Top-k → 塞给大模型。
LLM Wiki 的立场不是”取代 RAG”，而是把 RAG 的知识表示层换掉：检索-增强-生成这个骨架还在，只是被检索的对象从”一堆语义模糊的文本碎片”升级成了”结构化、自洽、可维护的 Wiki 词条”。
朴素 RAG 的四个病根
| 病根 | 说明 | 生活类比 |
|---|---|---|
| 切块即破坏语义 | 一个完整论点被从中间切断，召回回来是”半句话” | 把一篇菜谱按每 200 字撕成纸条，你抽到的那张可能只有”翻炒 3 分钟”却不知道炒的是什么 |
| 碎片之间没有关系 | 块与块是孤岛，模型拿到 5 个碎片自己脑补上下文 | 5 张撕碎的纸条丢给你，让你拼出全貌 |
| 冗余与矛盾并存 | 同一事实在 10 篇文档出现 10 次、措辞还互相打架 | 10 个人转述同一条规定，版本各不相同 |
| 相似 ≠ 相关 | 召回靠”语义相似”，但相似的不一定是答案 | 搜”苹果价格”，召回一堆讲 Apple 公司股价的 |
LLM Wiki 借用维基百科的组织哲学来治这四个病：与其存”原始材料的碎片”，不如先让 LLM 把原始材料消化、归纳、重写成一篇篇结构清晰的词条，像人类编辑维护百科那样——一个主题一个词条、词条内部自包含、词条之间交叉引用、重复信息去重、矛盾信息调和。
💡 这一步的本质：把”理解和组织知识”的成本，从「查询时（每次提问都现做）」前移到「入库时（只做一次）」。检索时召回的是”已经被编辑过、能独立成立的高质量词条”，模型拿到的是”成品答案素材”而非”原材料”。这正是 LLM Wiki 性能能”飞起来”的根因。
2. 核心结论（速查表）
| 问题 | 结论 |
|---|---|
| 它是什么 | 一种 RAG 升级范式：入库时就用 LLM 把原始文档”编译”成结构化、自包含、互联的 Wiki 词条，再供检索 |
| 和朴素 RAG 的区别 | 朴素 RAG 在查询时临时拼碎片；LLM Wiki 在入库时预先编译好高质量知识 |
| 骨架 | 三层架构 Raw → Wiki → Schema（原始数据湖 → 编译输出层 → 控制协议） |
| 七大能力 | 页面化 / 层级目录 / 双向链接 / 实体关系 / 自动摘要 / 自动索引 / 语义导航 |
| 最大优势 | 召回少而精（3 篇自包含词条顶朴素 RAG 20 个碎片）、可多跳推理、知识可维护演进 |
| 最大代价 | 构建成本高、知识更新时易级联失效、不适合超实时数据 |
| 什么时候用 | 读多写少、知识相对稳定、对准确性要求高的企业知识库场景 |
| 什么时候别用 | 股票行情、IoT 流、实时日志等超实时数据——用时序数据库更合适 |
| 一句话记忆 | LLM Wiki = 给 RAG 换一颗更高质量的”知识内核”，不是把 RAG 扔掉 |
3. 三层架构：Raw → Wiki → Schema
这是整套系统的主心骨。它把企业知识系统从简单的”存文档”升级为类似**“编译器”**的智能系统——原始数据是源代码，Wiki 词条是编译产物，Schema 是编译规则。
┌─────────────────────────────────────────────────────────┐
│ Raw Layer（原始数据湖）—— 事实来源 Source of Truth │
│ 文档(PDF/Word) + 代码(Git) + 数据库 + IM 记录 … │
│ 特点：数据混乱、不可控，不适合直接处理 │
│ 价值：保留原始事实，为回溯提供依据 │
└───────────────────────────┬─────────────────────────────┘
│ LLM "编译"：消化、归纳、重写
▼
┌─────────────────────────────────────────────────────────┐
│ Wiki Layer（编译输出层）—— 核心知识层 │
│ AI 编译后的结构化知识：页面、摘要、实体、双向链接、关系图 │
│ 本质："知识编译器"的产物 │
│ 价值：把原始数据转成 LLM 可高效利用的"预编译知识" │
└───────────────────────────┬─────────────────────────────┘
│ 受 Schema 约束
▼
┌─────────────────────────────────────────────────────────┐
│ Schema Layer（控制协议）—— 系统规则层 │
│ 定义页面模板、实体 Schema、命名规范、链接规则 │
│ 价值：统一知识表示，避免实体不统一、命名混乱，确保可维护 │
└─────────────────────────────────────────────────────────┘
三层职责对照（单一职责原则在数据架构上的体现）
| 层 | 只负责一件事 | 类比 |
|---|---|---|
| Raw | 忠实保存原文，永不加工 | 餐厅的”原料冷库”——食材原样存着，出了问题能查到源头 |
| Wiki | 把原文编译成人/模型都能读的高质量知识 | ”中央厨房”——把原料做成半成品菜，这是 LLM 干活最重的一层 |
| Schema | 定规矩，让知识表示统一、可检索 | ”出餐标准手册”——规定每道菜怎么摆盘、叫什么名 |
为什么要分三层而不是一步到位
- 可重建：Wiki 写挫了？基于 Raw 重跑即可，原始数据没丢。
- 可演进：换了更强的模型、改了 prompt，只需重新编译 Wiki/Schema，Raw 不动——这正是”对扩展开放、对修改封闭”（开闭原则）。
- 职责清晰：每层只解决一个问题，出错容易定位。
🌟 核心转变一句话：从 Query-time Intelligence（查询时理解） 转向 Ingest-time Intelligence（摄入时编译）。把企业知识库升级为”AI 时代的知识编译系统”。
4. Wiki 层的七大能力
上面三层里，Raw 和 Schema 相对简单，真正的工程量全集中在 Wiki 层。下面七项能力，正好是一条从”知识成型”到”知识检索”的流水线：
①页面化 → ②层级目录 → ③双向链接 → ④实体关系 （把知识"建"出来）
↓
⑤自动摘要 → ⑥自动索引 → ⑦语义导航 （把知识"查"出来）
4.1 页面化（Page-based Knowledge）
一句话理解：别急着切块，先把文档恢复成”有边界、有主题、有层级”的 Page（页面对象）。
要解决的问题：朴素 RAG 把 PDF/文档切成固定大小 Chunk，会丢失”页面身份”——无主题边界、语义不完整、无法识别一个 Chunk 到底属于哪个主题。
真实例子：一份”退款规则”被切成 Chunk_182（上半段） + Chunk_183（下半段），LLM 拿到其中一块，根本不知道这两块属于同一个主题。
实现流程：
Step 1 文档解析 → 提取标题、段落、表格，保留原始结构
Step 2 结构识别 → 识别 Markdown 层级，构建父子关系树
Step 3 生成 Page → 封装成结构化对象 {page_id, title, content, summary}
生活类比：朴素 RAG 像把一本书用碎纸机均匀打成纸屑；页面化像把书按章节拆成一页页带页码和标题的活页，每页自成一个完整意思。
4.2 层级目录（Hierarchy Tree）
一句话理解：给页面之间建一棵”父子树”，让 LLM 像查书一样先定位大类、再聚焦细节，而不是在全库大海捞针。
目录结构示例：
财务制度
├── 报销制度
│ ├── 差旅报销
│ └── 餐饮报销
└── 发票制度与合规
两种实现方式：
| 方式 | 做法 | 适用 |
|---|---|---|
| 文档原生解析 | 直接解析 Markdown 标题层级（#/##），构建抽象语法树（AST Tree），还原作者意图 | 本来就有结构的文档 |
| LLM 自动生成 | 对无结构文本，用 Prompt 让模型分析内容逻辑，输出 JSON 格式的层级关系 | 一团乱麻的纯文本 |
企业级存储：通常存为节点关系型数据库，用父子 ID 自引用维护层级（经典的邻接表建树法）：
{ "node_id": "1001", "parent_id": "1000", "children": [...] }支持：树遍历（Traversal）· 层级检索 · 章节动态扩展。
生活类比：图书馆不会把所有书堆一起让你翻，而是”图书馆 → 楼层 → 区域 → 书架 → 书”层层定位。层级目录就是给知识建这套定位体系。
4.3 双向链接（Bi-directional Links）
一句话理解：借鉴维基百科的内链思想，给孤立的文本片段之间建”互相关联的网”，打破知识孤岛。
为什么重要：朴素 RAG 的 Top-k 检索只返回”直接匹配”的结果。有了双向链接，模型能沿着关联自动扩展相关知识，做”多跳推理”。
典型关联示例：退款规则 ↔ 财务审批 ↔ 发票制度 ↔ 税务政策——问退款，能顺藤摸到税务政策。
三步实现：
Step 1 NER（命名实体识别）→ 识别文本中的关键实体，如"OpenAI, API Key"
Step 2 链接 → 检查实体是否存在，生成 [[API Key]] 这样的链接
Step 3 反向索引 → 自动维护索引，记录"谁引用了当前页面"
反向索引数据结构示例：
{"API Key": ["OpenAI API文档", "系统权限管理规范", "API鉴权机制说明"]}含义：键是实体，值是”所有提到这个实体的文档列表”。查实体时，直接拿到全部相关文档。
技术选型：简单版用向量相似度；进阶版上知识图谱（KG）。
💡 这套机制和你正在读的这个知识库本身一模一样——
[[实体]]正向链接 + “谁引用了我”的反向索引，就是本库反复强调的”双向引用必须真双向”。
4.4 实体关系（Entity Relationship）
一句话理解：从非结构化文本里自动抽取出带类型的”实体 + 关系”三元组，为 AI 提供可计算的骨架。这是双向链接的”重型升级版”。
结构化抽取示例：
原文："张三负责 Apollo 项目。Apollo 项目服务于腾讯。"
抽取：(张三, 负责, Apollo)、(Apollo, 客户, 腾讯)
↑这种 (主语, 谓语, 宾语) 叫 SPO 三元组
双向链接 vs 实体关系的区别（容易混）：
| 双向链接（4.3） | 实体关系（4.4） | |
|---|---|---|
| 记录的是 | ”A 提到了 B”（无类型关联） | “A 和 B 是什么关系”（带类型） |
| 技术 | 向量相似度即可 | 需上图数据库 |
| 能回答 | ”和退款相关的还有啥" | "张三负责的项目都服务于哪些客户” |
两种实现方法：
- LLM 端到端抽取（主流）：用精心设计的 Prompt 让大模型直接输出结构化数据，高效、适配性强。
- 传统 NLP 技术栈：依存句法分析、NER 等工具，在追求极致效率的场景仍有应用，但正逐步被 LLM 方案替代。
存储与最终形态：抽取结果通常存入图数据库（Graph DB，如 Neo4j），把海量碎片化信息编织成一张可被高效查询、遍历、推理的知识图谱（Knowledge Graph），为企业构建专属的”数字大脑”。
4.5 自动摘要（Auto Summary）
一句话理解：企业知识篇幅过长，LLM 难以每次读全文，所以入库时就逐层压缩成摘要。
三级摘要金字塔（自底向上聚合）：
③ Section Summary（全文/章节摘要） ← 输出关键结论与核心观点
↑ 聚合
② Page Summary（页面聚合摘要） ← 把分散 Chunk 摘要整合成页面级
↑ 聚合
① Chunk Summary（细粒度摘要） ← 对最小语义单元初步提炼，保留关键事实与数据
高级玩法：Query-aware Summary（查询感知摘要）
- 核心思想：从”为文档生成通用摘要”转变为”为用户问题动态提取答案”，精准匹配信息需求。
- 技术演进：这已接近 Agentic Retrieval 的核心逻辑（根据用户意图动态调整信息处理路径），是 RAG 的重要升级方向。
- 示例结构：
{page:..., summary_short:..., key_points: [...]}
类比：通用摘要像书的”内容简介”（人人共用，便宜）；query-aware 摘要像你问图书管理员一个具体问题，他翻到相关页当场给你提炼答案（更准但更贵）。
⚠️ 自动摘要和 §7 现实挑战 的”摘要级联失效”是一对矛盾：摘要层层依赖，底层 Chunk 一改，上层 Page/Section 摘要全要重算。
4.6 自动索引（Auto Indexing）
一句话理解：为知识建立多种访问入口，打破单一向量（Embedding）检索的局限。
当前主流 = 混合搜索（Hybrid Search）：现代企业级系统普遍采用混合策略，核心组合是
BM25(关键词) + Vector(语义) + Graph(关联)
企业真实系统中的七种索引类型：
| 索引类型 | 擅长 |
|---|---|
| Vector | 理解文本深层语义含义 |
| BM25 | 经典高效的关键词检索 |
| Entity | 人名/产品名等精准匹配 |
| Graph | 探索实体关联与多跳检索 |
| Hierarchy | 支持目录式层级导航 |
| Temporal | 基于时间维度的过滤 |
| Permission | 精细化的数据权限控制 |
常见技术栈选型：
| 技术栈 | 定位 |
|---|---|
| Elasticsearch / OpenSearch | 成熟搜索引擎，支持 BM25 与向量检索的混合查询 |
| Weaviate / Milvus | 专为 AI 构建的向量数据库，高性能海量向量存储 |
| Vespa | 支持混合搜索的实时大数据处理引擎，适合低延迟场景 |
📌 注意 Entity / Hierarchy / Temporal / Permission 这几路是朴素 RAG 通常没有的维度。尤其 Permission（权限过滤） 是多用户企业系统迟早要补的一课。
4.7 语义导航（Semantic Navigation）
一句话理解：检索从”一次性 Top-k 召回”升级成 “LLM 像人一样，自主决定下一步去哪里探索” 的多步过程。这是七大能力里最前沿的一项。
本质：从”召回”到”导航”
- 不再是简单的 top-k 召回，而是 LLM 自主决定下一步该去哪里探索。
- 类比：像在维基百科上阅读，不断点击链接，从一个知识点跳转到另一个。
- 示例（用户问”退款失败为何增多？”）：
模型一边读一边决定下一跳查什么，最后串出因果链。1.退款规则 → 2.支付系统 → 3.版本更新 → 4.Bug报告 → 5.客服工单
实现：Retrieval as Agent Action（把检索当成 Agent 的动作）
- 核心流程：
reason → retrieve → read → decide next retrieve（推理 → 检索 → 阅读 → 决定下一次检索） - 常见架构：ReAct（思考→行动→观察循环）、Tree Search（在知识图谱上做 BFS/MCTS 导航）
多跳推理的图例：
Win Graduate
Turing Award ───────► Hinton ──────────────► Edinburgh
└──────► Bengio ──────────────► (母校)
└──────► Pearl
沿边走两跳，就能回答”哪些图灵奖得主毕业于爱丁堡”。
🌟 本质区别：传统 RAG 中检索是**“系统行为”（系统固定地召回 Top-k）；语义导航中检索是”模型自主行为”**（模型自己决定查什么、查几次）。这一步把 RAG 推向了 Agent。配合阅读 什么是Agent.md 的 ReAct 模式。
5. 动态知识维护：更新的触发机制
光建好库不够，知识会变。LLM Wiki 的更新不再是人工维护的静态过程，而是**“外部业务事件” + “内部逻辑规则”双轮驱动**的动态进化体系。
| 触发类型 | 由什么驱动 | 典型场景 |
|---|---|---|
| 主动触发（外部事件驱动） | 源头数据变了 | ① 原始数据变更：合同版本迭代、产品手册更新、CRM/DB 新增记录 ② Schema/规则迭代：改了 Schema Layer 规则，触发全量/增量的知识重编译 |
| 被动触发（内部逻辑驱动） | 系统内部连锁反应 | ① 客户/产品属性变更 → 自动重构关联文档与图谱关系 ② 外部知识源自动同步 ③ 业务流程产出（立项文档、会议纪要、合规审计报告）自动纳入 |
💡 关键词是”重编译”——它把知识库类比成代码：改了 Schema（相当于改了编译规则），就要重新编译整个知识库。这跟把 Wiki 层称为”知识编译器”是同一套比喻。本质上是工程里经典的 缓存 + 失效（cache & invalidation） 思想落到了知识库场景：贵的 LLM 计算只做一次并存下来，变更时只补差量。
6. 实战对照：一个在建 RAG 系统的设计草案
把上面的理论落到地上。下面是一个正在搭建中的 RAG 系统的真实设计需求，正好能用来对照 LLM Wiki 的”标准答案”，看自研设计踩在哪一格、还差哪一步。
设计草案的三条需求
- 加关键词检索（混合检索）：在现有向量检索基础上，让 AI 解析用户 query 里的关键词，用关键词再检一遍，结合两种结果综合回答。
- 分阶段流式渲染：现在要等所有步骤跑完才出结果、太慢；改成哪步跑完先显示哪步——先显示检索结果，再显示拼好的最终提示词，最后才显示 LLM 生成的回复。
- 第三种”实体检索”模式：如果 LLM 解析出的关键词是一个实体/概念，就按实体名扫描 Raw 里所有文件，列出内容含
[[实体关键词]]的文件，把文件内容全塞进提示词，取消”Top-5 召回”上限，且这种模式直接跳过关键词检索和向量检索。
对照表：自研草案 vs LLM Wiki 标准答案
| 草案需求 | 对应 LLM Wiki 的能力 | 差距/可升级处 |
|---|---|---|
| ① 关键词 + 向量混合 | 4.6 自动索引 的 Hybrid Search | 标准答案是 BM25 + Vector + Graph 三路，草案只做了前两路，可补 Graph |
| ② 分阶段流式渲染 | （属于交互层优化，课程未直接覆盖） | 合理的工程改进；与知识表示无关，可独立做 |
③ 实体扫描 [[ ]] | 4.3 双向链接 + 4.4 实体关系 | 草案是”实体命中就全量塞上下文”，标准答案进一步做反向索引表（不用每次全扫）和 4.7 语义导航 的”模型自主多跳” |
两个标准答案比草案多走的关键步
- (a) 入库时就页面化 + 建层级树（4.1 / 4.2），而不只是在查询时拼碎片。
- (b) 用 Schema Layer 统一实体命名（§3 / §7）。否则”按实体名扫文件”会被”同一实体多个名字”（如 OpenAI / Open AI / 欧派 AI）坑到——这正是下一节要讲的”实体命名漂移”。
6.1 PageIndex：语义导航的工程化案例
2026-06-18 补充的 PageIndex 案例，可以看作本篇 4.7 语义导航 的一个具体工程落地，而不是”RAG 已死”的普适证明。
一句话定位：PageIndex 是 VectifyAI 开源的 Vectorless / Reasoning-based RAG 框架，用层次树索引 + LLM 推理导航替代朴素 RAG 的 chunk + embedding + 向量相似度。
长 PDF / Markdown
↓
生成层次树索引（标题 / 摘要 / 页码范围 / 子节点）
↓
查询时把树索引放进 LLM 上下文
↓
LLM 判断该去哪些节点找答案
↓
系统按节点 ID 读取原文页面
↓
不够就继续导航，够了就生成答案并保留推理痕迹它对应 LLM Wiki 的哪几项能力：
| PageIndex 设计 | 对应本篇能力 | 价值 |
|---|---|---|
| 文档层次树索引 | 4.1 页面化 + 4.2 层级目录 | 不把年报 / 合同 / 手册切成语义残缺的碎片 |
| 节点标题、摘要、页码范围 | 4.5 自动摘要 | 让模型先读”地图”，再决定去哪找原文 |
| LLM 决定读取哪些节点 | 4.7 语义导航 | 检索从固定 Top-k 召回变成 reason → retrieve → read → decide next retrieve |
| 跟随”详见附录 G”一类引用 | 4.3 双向链接 + 4.4 实体关系 | 弥补向量相似度不懂跨页引用 / 表格上下文的问题 |
它说对了什么：
- 对结构化长文档，查询意图和答案文本经常不相似，单靠余弦相似度容易召回”提到同一个词但不是答案”的 chunk。
- 金融年报、法律合同、监管文件、技术手册这类文档里，表格标题、脚注、页码、附录引用本身就是答案路径的一部分；粗暴切块会破坏这些结构。
- 检索有时确实需要推理：先看目录，再看章节，再顺着引用跳转，这更接近人类专家翻文档的方式。
但标题里的”扔掉向量数据库”不能照单全收：
| 传播说法 | 更准确的沉淀 |
|---|---|
| PageIndex 让 RAG 准确率到 98.7% | 98.7% 来自 Mafin2.5 在 FinanceBench 上的结果，不等于所有 RAG 场景都能达到 |
| 传统向量 RAG 过时 | 向量库仍适合大规模短文档、低延迟、高并发和跨库粗召回 |
| 不需要 chunk / embedding | PageIndex 不做传统固定 chunk；但无 TOC 时仍要按 token 限制分段让 LLM 生成结构，只是目标从”检索 chunk”变成”构建目录树” |
| PageIndex 是 LLM Wiki 的完全体 | 它主要解决单份 / 少量结构化长文档的深度检索；企业级知识系统还要权限、版本、增量更新、实体归一化、跨文档图谱 |
最实用的落地判断：
| 场景 | 更适合 |
|---|---|
| 10 万篇短 FAQ、客服知识库、网页搜索、要求亚秒级响应 | BM25 + Vector + Reranker / Hybrid Search |
| 单份或少量长 PDF：年报、合同、监管文件、技术手册，且准确率比速度重要 | PageIndex / 树索引 / 语义导航 |
| 大规模文档库里要找某份文档，再对该文档深度问答 | 混合路线：先用向量 / 关键词粗召回文档，再用 PageIndex 做单文档深度提取 |
💡 吸收结论：PageIndex 的价值不是证明”向量数据库没用了”，而是给 LLM Wiki 的页面化、层级目录、自动摘要、语义导航提供了一个可运行参照。它更像是结构化长文档场景下的深度检索器，不是所有 RAG 的通用替代品。
7. 现实挑战与常见误区
难得这套方法论自己也”泼了冷水”。落地 LLM Wiki 面临三大核心挑战：
| 挑战 | 说明 |
|---|---|
| 构建成本高 | 相比朴素 RAG”扔文档进去即可”，LLM Wiki 需要文档解析、页面拆分、实体提取、链接生成、图谱构建等复杂工程，对技术团队要求高 |
| 知识更新更难 | Wiki 化后知识间有复杂关系依赖，更新一部分内容可能导致关联的摘要、内部链接或知识图谱失效，日常维护成本显著高于普通知识库 |
| 不适合超实时数据 | 高频变化的股票交易、IoT 实时流、系统实时日志等场景，专业时序数据库/实时查询工具效率远优于 LLM Wiki |
三个必须记进设计清单的工程陷阱
| 陷阱 | 病因 | 对策 |
|---|---|---|
| 实体命名漂移 | 同一个东西出现多个名字，导致实体对不上 | 做实体归一化 / 别名表（Schema Layer 的职责） |
| 自动链接过量 | 什么都连，最后关系多到无法管理 | 给链接设阈值 / 类型约束 |
| 摘要级联失效 | 底层摘要微小变化导致上层摘要体系全部失效 | 做依赖追踪 + 增量重算，别全量重跑 |
常见误区
| 误区 | 为什么错 | 更好的做法 |
|---|---|---|
| ”LLM Wiki 取代 RAG” | 它没换骨架，只换了知识表示层 | 理解为”给 RAG 换高质量内核" |
| "PageIndex 证明可以扔掉向量数据库” | 它强在结构化长文档深度检索，不代表大规模短文档 / 高并发检索也该放弃向量库 | 按场景混用：向量 / BM25 做粗召回，PageIndex 做长文档深读 |
| ”成本前移 = 成本消失” | 入库编译省了查询成本，但构建成本只是被前移、没消失 | 评估知识量与读写比，读多写少才划算 |
| ”LLM 重写的词条一定可信” | 编译时模型可能篡改或编造事实（幻觉） | 可溯源是生死线：词条必须能回查 Raw 验证 |
| ”什么数据都往 Wiki 里塞” | 超实时数据用 Wiki 反而拖累 | 实时数据走时序库，Wiki 只装稳定知识 |
⚠️ 本质升维：传统 RAG 视知识为”被动存储”、系统像”搜索工具”；LLM Wiki 视知识为”持续演化的动态系统”，目标是构建一个”可进化的知识操作系统”，让企业知识从**“死数据”变为”活系统”**。这个愿景很动人，但上面的工程陷阱说明：漂亮的方法论 ≠ 已验证的结论，落地复杂度容易被低估。
8. 与本知识库其他章节的关联
| 相关笔记 | 关系 |
|---|---|
| RAG学习笔记.md | RAG 主线入门：先看那篇懂”先搜再答”的基本盘，再看本篇懂”知识层怎么升级” |
| Embedding-Reranker-向量数据库.md | 基础设施层互补：那篇讲”用什么工具检索”（Embedding/向量库/Reranker/Hybrid Search），本篇讲”知识本身怎么组织”；PageIndex 案例进一步说明”什么时候向量库不是首选”，但工程上常见答案仍是混合路线 |
| 什么是Agent.md | 4.7 语义导航 的 reason→retrieve→read 正是 ReAct 模式；检索从”系统行为”变”模型自主行为”即把 RAG 推向 Agent |
| LLM典型失败模式.md | §7 强调”可溯源是生死线”、“方法论≠已验证结论”，与该篇”能讲≠能做、漂亮报告≠真完成”同源 |
9. 来源与局限性
9.1 来源
- 主要来源：一套国内 AI 培训课的 LLM Wiki 专题课件（共 11 页，含三层架构、页面化、层级目录、双向链接、实体关系、自动摘要、自动索引、语义导航、动态更新、现实挑战等）。
- 辅助来源：作者自己一份在建 RAG 系统的设计需求草案（见 §6）。
- PageIndex 补充来源：微信公众号文章《PageIndex：扔掉向量数据库，RAG 准确率飙到 98.7%》；PageIndex GitHub README（
https://github.com/VectifyAI/PageIndex）；Mafin2.5-FinanceBench benchmark 仓库（https://github.com/VectifyAI/Mafin2.5-FinanceBench）。 - 作者自己的理解：四大病根的类比、双向链接与实体关系的区别表、三个工程陷阱的对策、常见误区表。
9.2 局限性
| 维度 | 局限 |
|---|---|
| 时效性 | 课件提到的技术栈（Elasticsearch/Milvus/Vespa/Neo4j）和”语义导航/Agentic Retrieval”是 2025-2026 的活跃方向，半年后选型可能变化 |
| 覆盖范围 | 课件偏”是什么 + 为什么”，几乎没有可运行代码；本文也未给端到端实现，需要落地代码请配合 Embedding-Reranker-向量数据库.md 的 Pipeline 示例 |
| 实战验证 | 课件自称”我们认真测了”，但未交代测试数据集、对比基线、指标算法——所以性能”飞起来”的结论应当作参考而非定论；PageIndex 的 98.7% 也只应解读为 FinanceBench / Mafin2.5 场景结果，不应外推到所有 RAG |
| 出处存疑 | 课件把”Raw→Wiki→Schema 三层架构”归到 Karpathy 名下。Karpathy 确有 “LLM OS”、Software 2.0/3.0 等公开比喻，但未能核实他正式提出过名为”LLM Wiki”的三层架构。这很可能是课程借名人抬权威的常见手法，引用时建议当作”课程自己的归纳”，不要直接当 Karpathy 原话。 |
最后更新：2026-06-18