知识库并非 RAG：LLM Wiki 和 OKF 分别补足了什么？

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

摘要
从“知识是怎么形成的”入手，本文把 RAG、LLM Wiki 和 Google 提出的 OKF 纳入同一套五层系统，梳理知识库真正面对的六个问题，并说明它为何不能与文件库、Wiki 或向量数据库画等号。

最近，我一直在思考一个问题：RAG 算不算知识库的较好解决方案？

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

然而再向前追问一步，就会发现这个问题提出得太早。

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

现在，我更愿意这样理解它：

在这套系统之中：

• 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 不是知识库”，更准确的表达是：

五、LLM Wiki 补足了什么？

一种“使用 LLM 构建个人知识库的模式”，是 Andrej Karpathy 对其在 2026 年发布的 idea file——LLM Wiki——所作的描述。它并非强制标准，也不是具体产品。

它对常规 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 就能回到同一张图中；我更倾向于这样理解：

在这一结构之中：

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

已经建成知识库，不能仅凭“我们兼容 OKF”“我们使用 Markdown”或“我们用了 RAG”中的任何一项来证明。

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

在讨论具体工具以前，可以先逐项确认：

• 原始资料是否得到保留并且能够回溯？
• 系统形成的是稳定知识对象，还是仅有文档片段？
• 加入新资料以后，原有知识是否会随之更新？
• 不同来源发生冲突时，系统能否揭示问题？
• 知识是否标明负责人、状态、版本及有效期？
• 不同的搜索、问答和 Agent 工具能否消费这些知识？
• 生成答案以后，是否能够追溯到相应证据？

如果这些问题均未得到回答，系统只是“成功上传文件、完成向量索引”，那么知识库依然处于资料接入阶段。

最后还需承认一项边界：知识库无法替组织决定那些组织自身都尚未决定的问题。

系统无法凭空制造正确答案；当企业缺少统一价格、明确政策边界和愿意确认的负责人时，它最多只能暴露冲突与缺口。

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

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

参考资料

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% 内容