代码语言

知识点思维导图

36 个知识节点

参考资料

RAG（25） - LLM Wiki：持续知识编译与 RAG 对比

读完后，你应能完成以下任务：

绘制“RAG（31） - LLM Wiki：持续知识编译与 RAG 对比 / 为什么传统 RAG 还不够”的关键对象与数据流，解释“传统 RAG 在每次提问时检索原始 Chunk，再临时拼接答案。”，并用源码位置、日志或 Trace 标注证据。

为“RAG（31） - LLM Wiki：持续知识编译与 RAG 对比 / 三层结构与三类操作”设计正常与异常输入，验证“Raw Sources 是事实依据，如制度原文、会议纪要和论文。”，输出首个偏差位置与回归测试结果。

实现“RAG（31） - LLM Wiki：持续知识编译与 RAG 对比 / LLM Wiki 与 RAG 怎么选”的最小代码或配置，检验“选择原则不是二选一：几十到几百页、领域稳定且强调阅读积累时，”，输出命令、结果与 Diff，并说明不适用边界。

LLM Wiki 不是新的向量数据库，而是一种由 LLM 持续维护结构化知识制品的模式：原始资料保持不变，模型把跨来源结论编译进相互链接的 Wiki，再让后续查询复用已经完成的整理。

核心知识清单

Raw Sources、Wiki 与 Schema 三层架构
Ingest、Query 与 Lint 三类操作
查询时检索与摄取时持续知识编译
来源回链、冲突标记和人工审阅
Wiki 索引与 BM25、向量检索的组合
更新成本、查询成本、时效和错误传播

一、为什么传统 RAG 还不够

传统 RAG 在每次提问时检索原始 Chunk，再临时拼接答案。它擅长从大量、频繁变化的资料中找到局部证据，但复杂问题可能每次都要重新发现相同关系。例如回答“过去三个版本的退款规则为什么改变”，系统要重复找到版本文档、识别时间线、处理冲突并生成结论。

Karpathy 提出的 LLM Wiki 把一部分工作前移到摄取阶段：新资料进入后， LLM 不只建立索引，还更新主题页、实体页、对比页、交叉链接与冲突说明。下次查询先读已经整理过的 Wiki，复用持续积累的综合结果。这里的“编译”是工程类比，不表示模型生成内容天然正确。

flowchart LR
  S["Raw Sources<br/>不可变原始资料"] --> I["Ingest<br/>读取、提取、对照"]
  C["Schema<br/>目录、格式、操作规则"] --> I
  I --> W["Wiki<br/>主题页、实体页、链接"]
  W --> Q["Query<br/>检索、回答、引用"]
  Q -->|"有复用价值"| W
  W --> L["Lint<br/>冲突、过期、孤页、缺口"]
  L --> I

读图时重点看两条闭环：新来源经 Ingest 更新持久 Wiki，高价值 Query 与 Lint 发现的缺口又回到维护流程； Schema 则持续约束每次写入的目录、格式和审核规则。

二、三层结构与三类操作

Raw Sources 是事实依据，如制度原文、会议纪要和论文。它们应保留来源 URL、采集时间、内容哈希、权限与版本，模型不得覆盖原文。

Wiki 是 LLM 生成的派生层，包含概念、实体、时间线、对比和索引页面。每条重要结论必须回链 Source ID，并记录 verified、needs_review 或 disputed 等状态，不能把模型综合结果冒充原始事实。

Schema 是维护契约，可放在 AGENTS.md 或专用规则文件中，规定目录、页面模板、引用格式、允许修改的范围、冲突处理和审批门禁。没有 Schema，模型只是一次性写摘要，不是可治理的 Wiki 维护者。

三类基本操作分别是：Ingest 把新来源整合进已有页面； Query 基于 Wiki 回答并把高价值分析回填为候选页面； Lint 检查冲突、过期声明、孤立页面、断链和知识缺口。企业场景还应增加发布审批、权限同步、删除传播和回滚。

三、LLM Wiki 与 RAG 怎么选

对比项	查询时 RAG	LLM Wiki
主要处理时机	用户提问时检索和组装	新资料进入时增量整理
持久产物	Chunk、索引和查询日志	可读、互链、持续修订的页面
强项	大规模查找、最新原文、精确引用	跨来源综合、关系积累、浏览学习
主要成本	每次查询的召回、重排和长上下文	每次摄取的多页更新、审阅和一致性检查
主要风险	漏召回、错召回、上下文噪声	错误被写回并传播、旧结论未及时修订
权限要点	每一路召回前执行 ACL 过滤	页面继承来源权限，混合来源取最严格权限

选择原则不是二选一：几十到几百页、领域稳定且强调阅读积累时，可先用 index.md + 全文搜索；资料规模大、查询长尾多或需要严格定位原文时，给 Raw 与 Wiki 分别建立检索索引。常见生产组合是先检索 Wiki 获得综合背景，再检索 Raw Sources 校验关键事实和引用。

四、组合链路：先综合，再核验

问题
  -> 检索 Wiki 页面：获得术语、关系和候选结论
  -> 从 Wiki 的 Source ID 扩展到原始资料
  -> 对 Raw Sources 做 BM25 + 向量检索
  -> Rerank 并执行 ACL 过滤
  -> 生成带原文引用的回答
  -> 高价值新分析进入待审队列，通过后回填 Wiki

这条链路把 Wiki 当作“可维护的语义中间层”，把 Raw Sources 当作最终证据层。回答可以引用 Wiki 帮助解释，但涉及金额、日期、权限、法规等关键事实时，必须回到原始来源核验。

五、可运行完整示例：观察知识如何积累

下面的纯 Python 示例不调用真实 LLM，而是用确定性规则展示核心差异：传统 RAG 每次从原始资料重新拼答案； Wiki Ingest 会把来源和结论持久化，发现不一致时进入审阅状态。

预期第二次输出同时保留两个来源，并把状态改为“需要人工审阅”。真实系统应进一步抽取生效时间和适用范围，不能把所有文本差异都判为业务冲突。

六、生产落地的五个门禁

可追溯：每条 Wiki 声明保存 Source ID、原文位置、提取时间和模型版本。
可审阅：新增、覆盖、合并和删除使用结构化 Diff；高风险领域必须人工批准。
权限安全：Wiki 页引用多个来源时采用最严格 ACL；检索前过滤，禁止生成后再删敏感内容。
可回滚：Raw 不可变，Wiki 用 Git 或版本表记录变更；删除来源时执行影响分析和级联重建。
可评测：分别测来源引用正确率、冲突发现率、过期声明率、Wiki 检索 Recall@K，以及最终回答忠实度。

七、常见误区

把摘要目录叫 LLM Wiki：只有摘要，没有跨页更新、引用和 Lint，不会形成知识复利。
让模型直接改原文：派生结论污染事实层后，无法审计也无法重建。
认为不用检索：页面增加后仍需要索引；区别是检索对象可以包含已编译的 Wiki，而不只是 Raw Chunk。
自动回填所有回答：错误回答会成为下一轮输入。应先进入候选区，通过证据校验和审批再发布。
忽略时态与权限：新版结论未必覆盖旧场景，低权限来源也不能提升到所有人可读的综合页。

学完验收

能画出 Raw Sources、Wiki、Schema 与 Ingest、Query、Lint 的关系。
能说明 RAG 是查询时知识装配，LLM Wiki 是摄取时持续知识编译，两者可以组合。
能为一个 Wiki 声明追溯到原始来源，并演示冲突、权限或删除如何传播。
能用评测数据决定继续使用索引文件，还是引入 BM25、向量检索和 Rerank。

八、总结

为什么传统 RAG 还不够：这里的“编译”是工程类比，不表示模型生成内容天然正确。
三层结构与三类操作：Raw Sources 是事实依据，如制度原文、会议纪要和论文。
LLM Wiki 与 RAG 怎么选：| 主要风险 | 漏召回、错召回、上下文噪声 | 错误被写回并传播、旧结论未及时修订 |
组合链路：先综合，再核验：回答可以引用 Wiki 帮助解释，但涉及金额、日期、权限、法规等关键事实时，必须回到原始来源核验。
可运行完整示例：观察知识如何积累：预期第二次输出同时保留两个来源，并把状态改为“需要人工审阅”。
生产落地的五个门禁：可追溯：每条 Wiki 声明保存 Source ID、原文位置、提取时间和模型版本。 -> 可审阅：新增、覆盖、合并和删除使用结构化 Diff； -> 权限安全：Wiki 页引用多个来源时采用最严格 ACL； -> 可回滚：Raw 不可变，Wiki 用 Git 或版本表记录变更；