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

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

摘要
从“知识是怎么形成的”来看，文件库、Wiki 或向量数据库都不能直接等同于知识库。本文会先说明知识库真正要解决的六个问题，再将 Google 提出的 OKF 与 RAG、LLM 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 构建个人知识库的模式”，是 Andrej Karpathy 在 2026 年发布的 idea file 中对 LLM Wiki 的描述。它并非具体产品，也不属于强制标准。

它对常规 RAG 的主要质疑在于：每次提问都重新检索并拼接原始资料，会导致复杂的综合工作被不断重复，知识本身却没有持续沉淀。

在原始资料与查询之间设置 Wiki 层，并持续维护它，这就是 LLM 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 工具能否使用这些知识？
• 生成的答案能否反向追溯到相关证据？

知识库若只有“文件上传成功、向量索引完成”，却没有回答这些问题，就仍旧只处于资料接入阶段。

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

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

“RAG 已经过时”和“LLM Wiki 会取代 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% 内容