OKF（开放知识格式）深度解析：纯文本文件夹能否替代向量数据库？

OKF（开放知识格式）深度解析：纯文本文件夹能否替代向量数据库？

摘要：近期，Google 以开放知识格式（Open Knowledge Format，OKF）将一种基于纯文本文件夹的知识管理方式推向标准化舞台。这一思路与 Karpathy 提出的 “LLM Wiki” 理念一脉相承，直接挑战了当前主流的 RAG + 向量数据库方案。本文将从技术原理、架构设计、与 RAG/MCP 的边界对比、潜在隐患等角度进行客观剖析，探讨 OKF 的真实价值与适用场景。

一、背景：AI “记忆” 问题的两种路线

过去两年，为 LLM 赋予外部知识记忆的主流方案是 RAG（Retrieval-Augmented Generation）。其典型流程为：

这套方案能跑通，但有结构性缺陷：

• 每次查询都从零开始，模型拿到的是彼此孤立、缺乏上下文的碎片；
• 模型需要反复重新推导一小时前已经理清过的关系，计算成本与延迟被重复支付；
• 知识之间的关联、矛盾、层级结构在 “切块 + 向量化” 过程中被不可逆地打散。

2025 年 4 月，Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 负责人）在 GitHub 上提出了一个相反思路 —— “LLM Wiki”：不在查询时刻临时检索，而是一次性将知识构建为一个相互链接的纯文本文件夹（一部可像代码库一样被阅读的 “活百科全书”），由 AI 负责维护、交叉引用与归档。

随后，Google Cloud 将这个社区构想提炼为正式规范 —— 开放知识格式（OKF）。

二、OKF 是什么：一个 “反重” 的规范

OKF 的核心思想可以概括为一句话：知识库即文件夹，概念即文件，链接即关系图。

2.1 核心约定

2.2 唯一的硬性规则

每个文件必须声明它是什么类型的事物（通过一个类型字段，如 type）。

除此之外，规范刻意保持极度宽容：

• 允许未知字段（工具遇到不认识的字段不报错）；
• 允许断链（broken links）；
• 允许无法解析的文件；
• 读取方（reader）被要求包容混乱，而非强制严格校验。

这种 “要求极少、允许随意打破规则” 的设计哲学，使得开发者一个下午即可搭建起一个可用的 OKF Bundle。

2.3 一个直观示例

my_bundle/
├── _manifest.md # 目录索引
├── _changelog.md # 变更记录
├── metrics/
│ ├── dau.md # type: metric
│ └── revenue.md # type: metric
├── tables/
│ └── user_event.md # type: bigquery_table
└── playbooks/
└── onboarding.md # type: runbook

每个 .md 内部用 Markdown 编写正文，并通过 [相关概念](./tables/user_event.md) 的方式互相链接，形成一张可遍历的图。

三、文件夹为什么 “胜过” 向量数据库：三个技术动因

需要明确：这里的 “胜过” 是有条件的，指在特定知识管理场景下，结构化纯文本相比 RAG 有结构性优势。具体体现在三点：

3.1 工作时机：构建期计算 vs 查询期计算

OKF 把 “连接、概念标记、矛盾梳理、摘要” 这些昂贵的理解工作前置到 Bundle 构建阶段，模型在查询时只需直接读取最终答案，无需重新推导。

3.2 可扩展性：目录 + 按需加载

LLM 的上下文窗口有限，而大型企业可能拥有数千甚至上万个知识文件。OKF 的应对策略是：

这种 “索引 + 按需读取” 的机制，使模型不会因整个知识库的规模而卡死，实现了与 “全库向量检索” 完全不同的扩展路径。

3.3 纯文本：可版本化、可审查、可离线

这是 OKF 最具工程吸引力的一点：

• 存在 Git 中，像代码一样管理；
• 可做 Diff，在 Pull Request 中由人类审查；
• 可打包，交给离线运行的本地模型读取；
• 无需数据库服务器、无需 API Key，只要能打开文件即可。

相比之下，向量数据库的知识 不可直观阅读、难以 Diff、依赖专有服务，在工程治理上存在天然短板。

四、边界澄清：OKF 与 MCP、SEO 的关系

为避免概念混淆，需明确 OKF 的定位边界：

4.1 OKF ≠ MCP（不竞争）

• MCP（Model Context Protocol） 是实时传输数据的管道 / 协议，解决 “模型如何接入工具与数据源”；
• OKF 是流经该管道的数据内容 / 组织格式，解决 “知识本身如何结构化存储”。

二者是 “管道” 与 “内容” 的关系，可互补共存。

4.2 OKF ≠ SEO 技巧

OKF 中的内容是 面向 AI Agent 的私有知识，不是为搜索引擎优化而生的公开网页。其目标是让 Agent 准确理解，而非让爬虫收录。

4.3 OKF ≠ 自动更新系统

这是常被误读的一点：OKF 规范本身不提供任何保持内容时效性的机制。它定义了一个静态容器格式，至于内容如何同步、何时刷新，完全依赖外部流程。

五、客观审视：OKF 的三层隐患

任何技术方案都有其适用边界，OKF 也不例外。深入剖析其设计，可识别出三个递进层次的隐患。

5.1 第一层：维护流程缺失（时效性风险）

规范里虽有时戳字段，但 “字段 ≠ 流程”，格式本身不会自动更新任何东西。实际表现：

• 单人拥有文件夹：维护者可及时更新，运行良好；
• 团队共享文件夹：往往 一个月内即过时，无人主动维护；
• 后果：Agent 基于过期知识作答，产生 " silently wrong " 的隐性错误。

本质：知识的时效性不是格式问题，而是治理流程问题，需要配套调度、校验、责任分配机制。

5.2 第二层：生成质量不可靠（“混乱图书管理员” 问题）

OKF 的前提假设是 “AI 是不知疲倦且准确的图书管理员”，但现实中 LLM 在大规模编写整洁 Markdown 时表现欠佳：

• 搞砸格式、弄乱标题层级；
• 捏造出从未实际创建过的文件链接（幻觉式引用）；
• 破坏文档结构的一致性。

Google 的应对方案值得玩味：没有去解决源头问题，而是在规范中加入 “宽容规则” —— 要求读取方包容未知字段、断链、无法解析的文件。这在客观上是一种 “以容错换灵活性” 的损害控制（damage control），将治理负担从 “写入方” 转移到了 “读取方”。

5.3 第三层：语义未标准化（最深层的局限）

OKF 标准化的是 “容器（container）”，而非 “语义（semantics）”：

• 唯一的必填字段是一个 自由填写的类型标签；
• 同一概念可被不同团队标注为 BigQuery table、table、relational asset —— 格式上都合法，语义上却各说各话。

结论：OKF 解决的是 “知识如何被组织和交换”，而 “知识含义如何对齐” 仍是使用方自己的责任。可移植 ≠ 可理解。

六、更深层的观察：OKF 与 Google 生态的协同

从出处看，OKF 并非源自 Google AI 实验室，而是来自 BigQuery 团队，这一背景揭示了其战略取向：

• 所有示例数据集均在 BigQuery 上发布；
• 编写 Bundle 的参考工具运行于 Gemini；
• 存放 Bundle 的推荐产品指向 Google 自身知识产品（并为此更名）。

这意味着 OKF 客观上构成了 Google Cloud 数据生态的一环：以开放规范降低采用门槛，同时将用户知识资产锚定在 BigQuery + Gemini + 知识产品的技术栈上。“开放标准” 与 “生态绑定” 并不矛盾，而是常见的平台战略组合。

七、适用场景与选型建议

综合以上分析，OKF 并非 “银弹”，但在特定场景下确有优势。给出选型参考：

推荐架构：混合模式

实践中更可行的方向是 “OKF 作为结构化知识骨架 + RAG 作为动态补充”：

• 用 OKF 管理稳定、核心、需治理的领域知识（指标定义、表结构、操作手册）；
• 用向量数据库承载高频变动、需语义检索的内容；
• 通过 MCP 将两者统一暴露给 Agent。

八、结语

“智能体基本上就是一个装满 Markdown 文件的文件夹。”

这句社区流行语点出了一个深刻变化：AI 工程正在从 “堆砌复杂基础设施” 回归到 “简洁可治理的文本抽象”。科技行业花了两年时间与大量资金才意识到 —— 让机器拥有记忆，未必需要奇特的基础设施，一个组织良好的文本文件夹或许就够用了。

但也要清醒认识到：格式是可见的，治理是不可见的。两个结构完全相同的 OKF 文件夹，一个能在生产环境长期稳健运行，另一个可能在悄悄腐烂 —— 仅凭文件本身，你无法区分二者。真正决定成败的，是 哪些内容被锁定、哪些允许 AI 重写、以及如何防止长期漂移 的治理纪律。

OKF 作为一个年轻规范，目前 Google 之外的采用面仍有限，其生命力有待观察。但无论格式最终成败，它传递的核心理念已经成立：

在 AI 时代，知识的组织方式本身，就是产品的一部分。

参考资料