AI知识库演进_RAG到LLM Wiki_OKF开放标准

2023 年，几乎所有做 AI 应用的团队都在做同一件事——RAG。向量库、Embedding、切块、召回，成了「给大模型接知识」的标配动作。

可到了2026年，你会发现一个耐人寻味的现象：包括 Anthropic、Google 这样的 AI 头部玩家，都在悄悄换一种做法。他们不再只把知识切碎、塞进向量库，而是开始让 AI 把知识写成一篇篇互相链接的文档。

这背后是一条清晰的演进线。把知识交给 AI，这件事其实走了好几道弯路，每一代方案都解决了上一代的痛点，又留下新的问题，直到今天。这篇文章，就带你把这张「AI 知识库进化地图」完整走一遍。

01 第 1 阶段：复用古法知识库，把它们变成 AI 的数据源

AI 知识库的起点，不是另起炉灶，而是复用已有的家底。

企业在拥抱 AI 之前，通常已经积累了大量知识：Elasticsearch 里的全文索引、数据仓里的业务表、Confluence 上的产品文档。这些「古法知识库」各自成熟、稳定可靠，没有任何理由把它们推倒重来。

过去这些库是给人或给程序用的。现在，通过 API 或者越来越标准的 MCP（Model Context Protocol），它们能直接暴露给 AI Agent，让 Agent 按需去查询分析。

但古法知识库有一个天生的天花板——它只负责「存」和「取」，不理解语义，不会沉淀，也不会自我组织。其中最典型、也最致命的短板，出在关键词搜索赖以工作的倒排索引上：

只认字面词项： 它本质是按「词项」匹配，你搜的词得和原文里用的词对得上才可能命中；换个同义词、换种说法，就可能整条漏掉——它并不真的「懂」你在找什么，只是在比对字面。
优化也治标不治本： 现代搜索引擎靠分词、同义词词典能缓解一部分，但改变不了「靠字面词项对齐、而非真正理解你要找什么」的本质。
结果又偏又漏： AI 拿到的检索结果又偏又漏，理解和串联只能靠模型每一次临场硬扛。

而这，恰恰是下一代 RAG 想用向量检索去缓解的问题。

02 第 2 阶段：RAG——第一代原生 AI 知识库

如果说古法库是「借来的家底」，那 RAG（检索增强生成）就是第一代真正为大模型量身定做的知识库。

它的思路很直接——既然大模型上下文装不下所有知识，那就把知识拆开、再按需取用：

切块： 先把文档切成一小块一小块。
向量化： 用 Embedding 把每一块映射到向量空间。
召回生成：用户提问时，按向量相似度召回最相关的几块，再塞进上下文让模型生成答案。

在很长一段时间里，RAG 几乎是「给 LLM 接外部知识」的唯一解。它确实解决了两个大问题：降低了模型胡说八道的幻觉，也让模型能用上企业私有的、最新的知识。

但随着大家把 RAG 真正用到生产环境，一系列结构性的毛病逐渐暴露出来。这些问题不是调调参数就能修好的，而是范式自带的：

只会「找相似」，不是真正的语义理解： 向量检索靠的是 Embedding 的相似度打分，它能捞出「看起来相近」的片段，却并不真的懂你的意图。字面相近却答非所问的块会被召回，要绕个弯、结合背景才能判定相关的内容反而被漏掉——相似度终究只是语义的近似，不等于理解。
切块损失、召回不稳： 文档该在哪里切本身就是难题，切不好一段完整语义就被拦腰斩断；而相似度召回又是概率性的，top-k 里混进无关块、漏掉关键块都很常见，答案质量随之飘忽。
知识是一堆孤立的块，彼此没有关系： RAG 的存储是「原始文档 + 向量索引」，块与块之间毫无关联。碰到「同一个病人看过哪些医生、各自开了什么药」这类需要顺着实体关系走的问题，它只能捞回一堆零散片段，拼不出全貌——IBM 就建议改用微软提出的 GraphRAG 来补救。
只增不治理，越堆越脏： 真实项目里几乎没人回头维护知识库，只会不停往里加新内容。过时的、重复的、互相矛盾的块一直躺在库里，时间越久噪声越多，召回准确率持续降低。

说到底，这几条毛病都指向同一件事：RAG 始终停在「检索」这一层——每次临时捞几块相似片段拼给模型，知识本身既没被真正读懂，也没被组织、沉淀成更好的结构。换句话说，它让 AI 学会了「查资料」，却始终没学会把资料消化成自己的知识。

03 第 3 阶段：LLM Wiki——从「检索」到「沉淀」

2026 年4月，Andrej Karpathy 提出了一个听起来很简单、却改变了整个思路的范式：让 LLM 自己来写和维护一个 wiki，人只负责提供来源和提问。

这就是 LLM Wiki 模式。知识不再是一堆只有机器看得懂的向量块，而是一篇篇人和 AI 都能读的、互相链接的 Markdown 页面——就像一个会自己生长的百科全书。

把它和前几代逐一对照，会发现它正好接住了 RAG 留下的每一个坑：

对「只会找相似」——由 LLM 真正读懂后写成文档。知识不再是只有机器看得懂的向量块，而是 LLM 消化理解之后、人和 AI 都能读的结构化知识。于是「检索一段看起来相近的原文」，变成了「直接读一段已经被读懂、被写清楚的结论」——理解替代了相似度猜测。
对「切块损失、召回不稳」——以完整页面为单位，靠导航而非概率召回。 不再把文档切碎、再赌 top-k 能不能命中，而是靠目录、页头、grep、wikilink 逐层定位到该看的那一页。召回稳定、可复现，也不会被拦腰斩断。
对「孤立的块」——用 wikilink 把知识连成网。 每个概念、实体、结论都通过自动维护的 [[wikilink]] 互相链接，「同一个病人看过哪些医生、各自开了什么药」这类关系被显式表达出来，顺着链接就能走通，而不是捞回一堆拼不起来的碎片。
对「只增不治理」——自动检测知识冲突推动持续治理。 LLM Wiki自动检测知识冲突并主动引导知识管理员判断决策，让知识库越长越干净，而不是越堆越脏。

一个最有力的印证是：当下最流行的编码 Agent 之一——Claude Code，用的就是「Markdown 文件 + grep」这套机制，而不是向量库。

LLM Wiki让AI知识库从「一个被检索的仓库」，变成「一个被持续书写、不断增值的大脑」。

04 第 4 阶段：OKF——当 Google 把 wiki 模式变成标准

LLM Wiki 指明方向之后，社区里相关的文章、工具和实践很快冒了出来——AGENTS.md、接入 Agent 的 Obsidian、各种「把元数据当代码管」的知识仓库，思路都朝着同一个方向，却各写各的、彼此不通。

真正让它从一堆零散尝试变成一件「正经事」的，是 2026 年 6 月 Google Cloud 推出的 OKF（Open Knowledge Format）——它把这套玩法收拢成了一个正式标准。

OKF 把 LLM Wiki 变成一个厂商中立、谁都能写、任何工具都能读的公共标准——能打开就能读、能拷贝就能分发。有了它，知识根据同一套规范构建，得以在不同工具之间自由流转，而不再被锁死在某个人的 Obsidian、或某一家厂商的产品里。这也正是 OKF 最大的意义：让「AI 自己写知识库」这件事，从各玩各的，变成可以互通、可以共建的基础设施。

而当连 Google 这样的巨头都愿意下场，把「结构化 Markdown 知识库」立成一个开放标准，这件事本身就说明了：Wiki 模式不是小众实验，而是 AI 知识库正在收敛的大方向。

05 结语：从「检索」走向「沉淀」

回头看这条路，会发现它始终在回答同一个问题：怎么把知识可靠地交到 AI 手里。

我们从复用古法库起步，把 Elasticsearch、数据仓、Confluence 变成 AI 的数据源；接着用 RAG 造出第一代原生 AI 知识库，让机器不再死抠字面，而是靠向量相似度去找相近的内容；再到 LLM Wiki，AI 不再只是检索，而是把知识真正读懂、写成一篇篇互链的文档沉淀下来；最后，OKF 把这套做法立成开放标准，让它能跨人、跨团队、跨工具地被共用。

往后看，一定还会有新的理念和技术冒出来，今天的 LLM Wiki 和 OKF 也未必就是终点。但至少有一个方向已经足够清楚——知识的存放形态，正在从一堆只有机器看得懂的向量碎块，重新回到人和 AI 都读得懂、能追溯、也能持续生长的结构化文档。

06 关于我们

2026 年 8 月，嘉为蓝鲸WeOpsX 一体化智能运维平台的 AI 知识库正式升级为 LLM Wiki 模式。知识不再只是被切块、向量化后等待检索，而是由 AI 持续阅读、整理并沉淀为结构化、相互关联且可持续维护的知识页面，并支持以OKF标准格式进行导出/导入，推动企业运维知识从「被动存储」走向「持续生长」。

点击可跳转 社区版官网：https://bklite.canway.net/