摘要
知识库不等于文件库、Wiki 或向量数据库。本文从“知识是怎么形成的”出发，解释知识库真正解决的六个问题，并把 RAG、LLM Wiki 与 Google 提出的 OKF 放回同一套五层系统中。
最近我一直在想一个问题：RAG 是不是知识库比较好的解决方案？
做知识库时，我们很容易从技术开始讨论：文件怎么切分、Embedding 选什么、向量数据库用哪一个、召回率怎么样。
但再往前一步，会发现这个问题其实问早了。
如果我们还没有说清楚知识库到底要解决什么，就会把“上传了一批文件，并且可以向大模型提问”当成知识库建设已经完成。
我现在更倾向于这样理解：
知识库不是一个向量数据库，也不是一个装满文件的 Wiki。它是一套把原始资料持续转化为可理解、可验证、可维护、可检索知识的系统。
在这套系统里：
RAG 负责找到知识； LLM Wiki 负责积累知识； OKF 负责让知识跨工具流动。
这三者不是互相替代的产品，而是在解决三个不同层次的问题。
一、文件、信息和知识，有什么不同？
一个 PDF、一份产品手册、一段会议录音，本身首先是资料。
当我们从资料中识别出产品名称、价格、生效时间和适用对象，它们变成了信息。只有当这些信息被放回具体业务语境，能够回答问题、支持判断，并且知道来源和适用边界时，才开始成为可使用的知识。
举一个简单的例子：
“99,800”只是一个数据； “企业版年费为 99,800 元”是一条信息； “企业版年费为 99,800 元，自 2026 年 7 月 1 日起适用于中国大陆企业客户，来源是已审批的价格说明”才是一条可使用、可核验的知识。
我们熟悉的 DIKW 模型，常用“数据—信息—知识—智慧”描述这种变化。
Russell Ackoff 在《From Data to Wisdom》中区分了数据、信息、知识、理解与智慧。Jennifer Rowley 后来梳理了不同文献中的 DIKW 表达，也指出各层之间如何转换并没有完全一致的定义。
所以我不会把 DIKW 当成一条自动流水线。
资料不会因为被上传就自动变成知识，信息也不会因为被向量化就自动变得可信。
二、知识库到底是什么？
我的定义是：
知识库是一套把分散资料和个人经验，转化为可查找、可理解、可验证、可复用并能持续维护的答案的系统。
这里的关键词不是“存储”，而是“转化”和“持续维护”。
一条真正能够长期使用的知识，通常需要回答这些问题：
它描述的对象是什么？ 它提出了什么事实、规则或判断？ 证据来自哪里？ 适用于什么范围？ 从什么时候开始有效？ 谁对它负责？ 当前是草稿、已确认、已过期，还是存在冲突？
知识库因此保存的不只是内容，还包括内容之间的关系，以及使用这些内容的条件。
三、知识库真正要解决哪六个问题？
为了避免被具体工具带着走，我把知识库的目标收敛成六个问题。
1. 找得到
资料散落在网盘、聊天记录、邮件、Wiki、工单和人的脑子里。知识库首先要降低寻找答案的成本。
2. 看得懂
找到原文件不等于得到答案。系统需要把长文档、表格和记录，整理成围绕对象、问题与场景组织的知识。
3. 信得过
答案需要能够回到原始来源。没有证据、没有负责人、没有确认状态的内容，只能算线索，不能直接当成结论。
4. 不过期
价格、产品能力、制度和流程都会变化。知识库要知道什么已经失效，什么正在等待重新确认。
5. 不打架
官网、合同、销售材料和员工笔记可能给出不同说法。系统不能静默选择一个看起来最像答案的文本，而应暴露冲突并进入确认流程。
6. 能复用
一条已经确认的知识，不应该每次都从几十页资料里重新推导。它应该能够被搜索、问答、写作、客服或 Agent 反复调用。
这六点也给了我们一个判断标准：
如果一个系统只能“搜到相似段落”，它解决了知识访问，却还没有完成知识治理。
四、RAG 解决了什么？
RAG 是 Retrieval-Augmented Generation，即检索增强生成。
2020 年的原始论文将模型自身的参数化记忆与外部的非参数化记忆结合起来：系统先检索相关材料，再让生成模型基于这些材料作答。
这条路径很重要。它让大模型不必只依赖训练时记住的内容，也非常适合“从一批资料中找到相关内容并回答问题”。
传统的原始文档 RAG 通常是这样工作的：
文档被切分并建立索引； 用户提出问题； 系统检索相似片段； 大模型临时组合答案。
但这套流程本身并不自动保证：
片段之间的冲突已经解决； 旧版本已经失效； 同一个实体在不同文件中的名称已经统一； 某条结论已经由负责人确认； 这次综合得到的认识会沉淀下来，供下一次直接复用。
因此，更准确的说法不是“RAG 不是知识库”，而是：
RAG 更像知识库的查询与消费层。它可以找到材料，但不会天然替你完成知识生产和治理。
五、LLM Wiki 补上了什么？
2026 年，Andrej Karpathy 发布了一份名为 LLM Wiki 的 idea file，把它描述为一种“使用 LLM 构建个人知识库的模式”。它不是一个具体产品，也不是一套强制标准。
它对常规 RAG 的核心质疑是：如果每次提问都从原始资料重新检索和拼接，复杂的综合工作也会被一遍遍重做，知识本身并没有持续积累。
LLM Wiki 提出的做法，是在原始资料和查询之间增加一个持续维护的 Wiki 层：
原始资料保持不变，作为事实来源； LLM 生成和维护结构化、互相链接的 Markdown 页面； 新资料进入后，更新实体页、主题总结、交叉引用和冲突记录； 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 主要建立表示与交换契约； 治理贯穿所有层，但不能由其中任何一个名词自动完成。
所以“我们用了 RAG”“我们使用 Markdown”“我们兼容 OKF”，都不能单独证明已经建成了知识库。
八、判断一个知识库，先问这张清单
讨论具体工具之前，可以先检查：
原始资料是否保留，并且可以回溯？ 系统是否形成了稳定的知识对象，而不只是文档片段？ 新资料进入后，旧知识会不会更新？ 不同来源冲突时，系统会不会暴露问题？ 知识是否有负责人、状态、版本和有效期？ 知识能否被不同搜索、问答和 Agent 工具消费？ 生成的答案是否能够回到证据？
如果这些问题都没有回答，只是“文件上传成功、向量索引完成”，知识库仍然停留在资料接入阶段。
最后也要承认边界：知识库不能替一个组织决定它自己都没有决定的问题。
如果企业没有统一价格、没有明确政策边界、没有负责人愿意确认，系统最多只能把缺口与冲突暴露出来，不能凭空制造一个正确答案。
所以我目前的结论不是“RAG 已经过时”，也不是“LLM Wiki 会取代 RAG”。
知识库需要同时处理知识的生产、表示、治理和消费。RAG 负责找到知识，LLM Wiki 负责积累知识，OKF 负责让知识跨工具流动；真正决定知识是否可信的，仍然是来源、规则和责任机制。
当这些层次被分开，我们才有可能讨论一个知识库产品到底缺了什么，而不是继续把“上传文件后可以问答”当成知识库的全部。
