跳出技术视角，先明知识库本质：解析LLM Wiki与OKF在知识系统中的关键作用，重新定义知识转化的三层逻辑。
核心内容：
1. 知识库本质：非文件库/Wiki/向量数据库，而是持续转化资料为可理解知识的系统
2. RAG、LLM Wiki、OKF的分层作用：RAG负责检索，LLM Wiki负责积累，OKF负责跨工具流动
3. 知识库核心问题：从资料到信息再到知识的转化逻辑及验证、维护、跨工具流动等关键要素

摘要
本文先追溯“知识是怎么形成的”，再说明知识库真正面对的六个问题，最后把 RAG、LLM Wiki 与 Google 提出的 OKF 纳入同一套五层系统。知识库不能直接等同于文件库、Wiki 或向量数据库。

最近，我始终在思考一个问题：RAG是否是知识库更合适的解决方案？

讨论知识库建设时，人们很容易先从技术入手，例如文件如何切分、选择哪种Embedding、采用哪个向量数据库，以及召回率表现如何。

但继续向前追问，就会发现提出这个问题的时机其实太早。

如果知识库究竟要解决什么尚未明确，我们便可能把“上传一批文件，并能向大模型提问”误认为知识库已经建成。

现在，我更愿意从下面的角度理解：

一套系统若能持续处理原始资料，使其成为可检索、可维护、可验证且可理解的知识，才称得上知识库；向量数据库或装满文件的 Wiki 都不能单独等同于它。

在这个系统之中：

• RAG承担知识查找；
• LLM Wiki承担知识积累；
• OKF负责知识在不同工具间流动。

三者并非能够相互替代的产品，而是分别处理三个不同层次的问题。

一、文件、信息与知识有什么区别？

首先只能算资料的，包括一段会议录音、一份产品手册和一个 PDF。

产品名称、价格、生效时间及适用对象一旦从资料中被识别，资料便形成信息。可使用的知识还需要下一步：把信息置于具体业务语境，明确其来源和适用边界，并使其能够支持判断、回答问题。

来看一个简单示例：

• “99,800”仅仅是一项数据；
• 一条信息可以是“企业版年费为 99,800 元”；
• 只有补足适用对象、时间和来源，才构成可使用、可核验的知识：“来源是已审批的价格说明，中国大陆企业客户自 2026 年 7 月 1 日起适用企业版年费 99,800 元”。

这种变化通常由熟悉的 DIKW 模型表述为“数据—信息—知识—智慧”。

数据、信息、知识、理解与智慧的区别，由Russell Ackoff在《From Data to Wisdom》中作出。此后，Jennifer Rowley对各类文献中的 DIKW 表达进行了梳理，同时指出，各层如何转换并不存在完全统一的定义。

因此，我不会把DIKW理解为一条自动运行的流水线。

上传这一动作不会让资料成为知识；同样，向量化本身也不能赋予信息可信度。

二、知识库究竟是什么？

我的定义如下：

可查找、理解、验证、复用并持续维护的答案，是知识库这套系统的产物；其输入来自分散资料与个人经验。

其中的重点并非“存储”，而是“转化”以及“持续维护”。

一条可以长期使用的真正知识，通常必须回答以下问题：

• 它所描述的对象是什么？
• 它表达了哪些事实、规则或判断？
• 它的证据来源在哪里？
• 它适用的是哪一范围？
• 它从何时起开始生效？
• 谁需要对它承担责任？
• 它是否存在冲突，或处于已过期、已确认、草稿中的哪种状态？

除内容本身外，知识库还要保存使用条件，并记录不同内容彼此之间的关系。

三、知识库真正需要解决哪六个问题？

为避免思路被具体工具牵引，我把知识库目标归纳为六个问题。

1. 能找到

网盘、聊天记录、Wiki、邮件、人的脑子和工单里都可能散落资料。知识库首先解决的是答案难找、寻找成本高的问题。

2. 能看懂

找到原始文件并不代表获得答案，系统还要整理长文档、表格和记录，使知识围绕对象、问题与场景进行组织。

3. 值得信任

答案必须能够追溯到原始来源。缺少证据、负责人和确认状态的内容只能作为线索，不能直接用作结论。

4. 不会过期

价格、产品能力、制度和流程都会发生变化，知识库需要识别哪些内容已经失效，哪些内容正等待重新确认。

5. 不会冲突

官网、合同、销售材料和员工笔记可能存在不同表述。系统不应悄然选择一段最像答案的文字，而要展示冲突，并让其进入确认流程。

6. 可以复用

不必每次都在几十页资料中重新推导一条已确认知识；客服、写作、问答、搜索或 Agent 都应能反复调用它。

这六项要求也提供了一套判断标准：

知识访问可以靠“搜到相似段落”实现，但仅有这项能力的系统，距离知识治理仍有差距。

四、RAG解决了哪些问题？

检索增强生成的英文名称是Retrieval-Augmented Generation，缩写为RAG。

模型自身的参数化记忆，在2020 年的原始论文中与外部非参数化记忆结合。运行时先由系统检索相关材料，生成模型随后基于材料作答。

大模型因此不再局限于训练时记住的内容，这是这条路径的重要之处。它尤其适用于这样的问题：先从一批资料中定位相关内容，再据此回答。

传统的原始文档RAG通常按照以下方式运行：

1. 先对文档进行切分并建立索引；
2. 随后由用户提出问题；
3. 系统再检索相似片段；
4. 最后由大模型临时组织答案。

不过，这个流程本身不会自动保证以下事项：

• 不同片段之间的冲突已经得到解决；
• 旧版本内容已经被判定失效；
• 同一实体在不同文件中的名称已经实现统一；
• 某项结论已经获得负责人的确认；
• 本次综合形成的认识能够沉淀，并在下次直接复用。

所以，与其说“RAG不是知识库”，更准确的说法应该是：

知识库中的查询与消费层更接近RAG：材料能由它找到，但知识生产及治理不会随之自然完成。

五、LLM Wiki补充了什么？

一份名为 LLM Wiki 的 idea file 由Andrej Karpathy在2026 年发布，其中描述了“使用 LLM 构建个人知识库的模式”。这是一种模式，而非具体产品或强制标准。

它对常规RAG提出的核心质疑是：若每次提问都重新检索并拼接原始资料，复杂综合工作便会不断重复，而知识本身并未持续积累。

原始资料与查询之间，可以按 LLM Wiki 的做法加入持续维护的 Wiki 层：

• 保留原始资料不变，将其用作事实来源；
• 结构化并相互链接的 Markdown 页面，由 LLM 负责生成及维护；
• 实体页、冲突记录、交叉引用和主题总结，会在新资料进入后得到更新；
• 目录和页面类型如何设置、如何命名及维护，由Schema 或规则文件加以约束。

知识库由此不再仅在“查询时临时拼答案”，而是在“摄取时持续编译知识”。

检索并未被 LLM Wiki 判定为无用。同一份说明中，Karpathy指出，小规模场景可以采用 index.md，全文、混合或向量搜索则可在规模扩大后继续加入。

已经过整理、维护和关联的知识页面，同样可以成为RAG的检索对象；它并非只能处理原始文档碎片。

六、OKF又提供了哪些补充？

不同团队即使采用 LLM Wiki 模式，建立的 Wiki 也可能在约定、字段和目录方面各不相同，工具之间因而难以交换。

Google Cloud 在 2026 年 6 月发布了 Open Knowledge Format（OKF）v0.1 草案，把 LLM Wiki 模式进一步形式化为开放格式。

Google对这一问题给出了直接判断：真正需要补足的是一种格式，并非再增加一个知识服务。

OKF的最小形态并不复杂，主要包括：

• 一个由Markdown文件组成的目录；
• 每项概念分别对应一个文件；
• 类型、标题、描述、资源、标签、时间等字段，保存在文件头的 YAML frontmatter 中；
• 概念之间存在怎样的关系，由 Markdown 链接表示；
• 可选的 index.md 用于支持逐层发现内容；
• 可选的 log.md 用于记录变化。

它的价值不在于增加一个知识库界面，而在于让同一批知识既能供人阅读，也能被Agent解析、纳入版本控制，并可在不同工具之间迁移。

不过，OKF v0.1被有意设计成最小化交换规范，该规范仅强制每个概念具有 type 字段，至于查询设施、服务与存储，则明确不在规定范围内。

这说明它处理的是“如何表示与交换知识”，却不会自动处理负责人、权限、确认状态、有效期和冲突审批。产品仍需在OKF之上定义自身的治理字段和流程。

七、把三者重新放入一套完整系统

若在一张图中统一观察 RAG、LLM Wiki 和 OKF，我倾向于用五层来拆解知识库：

层次	主要任务	典型能力
原始资料层	保存事实来源	文件、网页、数据库、录音、记录
知识编译层	从资料中生成可复用知识	摘要更新、冲突发现、关联、合并、归一、抽取
表示与交换层	使知识可读、可解析并可迁移	Markdown、元数据、链接、OKF 或领域 Schema
治理层	判断知识是否值得信任和使用	审核、权限、有效期、版本、状态、负责人、来源
检索与应用层	在具体任务中调用知识	搜索、RAG、问答、写作、Agent 工具

按照这套结构来看：

• RAG主要处于检索与应用层；
• 知识编译及持续维护，是 LLM Wiki 重点加强的部分；
• OKF主要负责建立表示与交换契约；
• 治理贯穿全部层次，却无法由其中任何一个概念自动完成。

是否已经建成知识库，不能由“我们兼容 OKF”“我们使用 Markdown”或“我们用了 RAG”中的任何一句单独证明。

八、判断知识库时，先检查这张清单

在讨论具体工具前，可以先核对以下事项：

• 原始资料是否得到保留，而且能够追溯？
• 文档片段之外，系统有没有建立稳定的知识对象？
• 新资料进入系统后，旧知识是否会随之更新？
• 当不同来源发生冲突，系统是否会展示问题？
• 知识是否具备负责人、状态、版本和有效期？
• 不同搜索、问答和Agent工具是否都能使用这些知识？
• 生成的答案能否追溯至相关证据？

若这些问题均未解决，系统只实现了“文件上传成功、向量索引完成”，那么知识库仍处于资料接入阶段。

最后也必须承认一个边界：知识库不能代替组织决定其自身都尚未决定的问题。

系统能做的是暴露缺口和冲突，无法无中生有地给出正确答案；这一限制适用于企业价格不统一、政策边界不明确且没有负责人愿意确认的情况。

我目前并不认为“LLM Wiki 会取代 RAG”，也没有得出“RAG 已经过时”的结论。

知识库必须同时承担知识的生产、表示、治理和消费。RAG用于查找知识，LLM Wiki用于积累知识，OKF用于推动知识跨工具流动；知识能否可信，最终仍取决于来源、规则和责任机制。

只有区分这些层次，我们才能讨论一款知识库产品究竟缺少什么，而不再把“上传文件后能够问答”视为知识库的全部。

---

参考资料

1. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
   https://arxiv.org/abs/2005.11401
2. Andrej Karpathy: LLM Wiki
   https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
3. Google Cloud：Introducing the Open Knowledge Format
   https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
4. Open Knowledge Format v0.1 Specification
   https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
5. Russell Ackoff：From Data to Wisdom
   https://faculty.ung.edu/kmelton/documents/datawisdom.pdf
6. Jennifer Rowley：The wisdom hierarchy
   https://journals.sagepub.com/doi/10.1177/0165551506070706

登录后查看剩余70%内容