OKF开放知识格式深度解析纯文本文件夹能否替代向量数据库摘要近期Google 以开放知识格式Open Knowledge FormatOKF将一种基于纯文本文件夹的知识管理方式推向标准化舞台。这一思路与 Karpathy 提出的 “LLM Wiki” 理念一脉相承直接挑战了当前主流的 RAG 向量数据库方案。本文将从技术原理、架构设计、与 RAG/MCP 的边界对比、潜在隐患等角度进行客观剖析探讨 OKF 的真实价值与适用场景。一、背景AI “记忆” 问题的两种路线过去两年为 LLM 赋予外部知识记忆的主流方案是RAGRetrieval-Augmented Generation。其典型流程为将文档切分为大量文本块chunks通过 Embedding 模型将每块映射为高维向量存入专用向量数据库如 Milvus、Pinecone、pgvector 等查询时将问题向量化做近似最近邻ANN检索取 Top-K 片段交给模型生成。这套方案能跑通但有结构性缺陷每次查询都从零开始模型拿到的是彼此孤立、缺乏上下文的碎片模型需要反复重新推导一小时前已经理清过的关系计算成本与延迟被重复支付知识之间的关联、矛盾、层级结构在 “切块 向量化” 过程中被不可逆地打散。2025 年 4 月Andrej KarpathyOpenAI 联合创始人、前 Tesla AI 负责人在 GitHub 上提出了一个相反思路 ——“LLM Wiki”不在查询时刻临时检索而是一次性将知识构建为一个相互链接的纯文本文件夹一部可像代码库一样被阅读的 “活百科全书”由 AI 负责维护、交叉引用与归档。随后Google Cloud 将这个社区构想提炼为正式规范 ——开放知识格式OKF。二、OKF 是什么一个 “反重” 的规范OKF 的核心思想可以概括为一句话知识库即文件夹概念即文件链接即关系图。2.1 核心约定概念说明Bundle一个普通文件夹代表一个完整的知识库文件每个文件对应一个概念一张表、一个指标、一份操作手册等文件路径即该概念的命名 / 地址文件间链接构成知识图谱的关系边两个特殊文件一个用于列出目录manifest一个用于记录变更changelog2.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 查询期计算维度RAGOKF Wiki关联建立查询时临时检索构建时一次性完成摘要 / 概念标记无预先生成矛盾梳理无预先处理成本支付每次查询重复支付一次构建多次读取OKF 把 “连接、概念标记、矛盾梳理、摘要” 这些昂贵的理解工作前置到 Bundle 构建阶段模型在查询时只需直接读取最终答案无需重新推导。3.2 可扩展性目录 按需加载LLM 的上下文窗口有限而大型企业可能拥有数千甚至上万个知识文件。OKF 的应对策略是每个文件夹附带简短目录manifest模型先读目录定位相关文件只加载需要的单个文件跳过其余成千上万个。这种 “索引 按需读取” 的机制使模型不会因整个知识库的规模而卡死实现了与 “全库向量检索” 完全不同的扩展路径。3.3 纯文本可版本化、可审查、可离线这是 OKF 最具工程吸引力的一点存在 Git 中像代码一样管理可做Diff在Pull Request中由人类审查可打包交给离线运行的本地模型读取无需数据库服务器、无需 API Key只要能打开文件即可。相比之下向量数据库的知识不可直观阅读、难以 Diff、依赖专有服务在工程治理上存在天然短板。四、边界澄清OKF 与 MCP、SEO 的关系为避免概念混淆需明确 OKF 的定位边界4.1 OKF ≠ MCP不竞争MCPModel 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 Git纯文本、可 Diff、可 PR 审查知识规模大、需精准检索、上下文有限✅OKF目录索引 按需加载避免全库加载数据高度动态、实时性强⚠️RAG / 混合方案OKF 静态需外部刷新机制需语义相似度检索、模糊匹配⚠️向量数据库纯文件夹难以做 ANN超大规模、毫秒级检索⚠️专业向量 / 全文检索引擎文件夹遍历性能受限强一致性、语义对齐要求高⚠️需额外定义本体ontologyOKF 本身不约束语义推荐架构混合模式实践中更可行的方向是“OKF 作为结构化知识骨架 RAG 作为动态补充”用 OKF 管理稳定、核心、需治理的领域知识指标定义、表结构、操作手册用向量数据库承载高频变动、需语义检索的内容通过MCP将两者统一暴露给 Agent。八、结语“智能体基本上就是一个装满 Markdown 文件的文件夹。”这句社区流行语点出了一个深刻变化AI 工程正在从 “堆砌复杂基础设施” 回归到 “简洁可治理的文本抽象”。科技行业花了两年时间与大量资金才意识到 —— 让机器拥有记忆未必需要奇特的基础设施一个组织良好的文本文件夹或许就够用了。但也要清醒认识到格式是可见的治理是不可见的。两个结构完全相同的 OKF 文件夹一个能在生产环境长期稳健运行另一个可能在悄悄腐烂 ——仅凭文件本身你无法区分二者。真正决定成败的是哪些内容被锁定、哪些允许 AI 重写、以及如何防止长期漂移的治理纪律。OKF 作为一个年轻规范目前 Google 之外的采用面仍有限其生命力有待观察。但无论格式最终成败它传递的核心理念已经成立在 AI 时代知识的组织方式本身就是产品的一部分。参考资料Andrej Karpathy,LLM Wiki提案GitHub2025 年 4 月Google Cloud,Open Knowledge Format (OKF)官方规范“为什么文件夹胜过向量数据库”—— 视频逐字稿整理内容相关背景RAG 架构、MCP 协议、BigQuery 数据治理实践 OKF（开放知识格式）深度解析：纯文本文件夹能否替代向量数据库？
OKF开放知识格式深度解析纯文本文件夹能否替代向量数据库摘要近期Google 以开放知识格式Open Knowledge FormatOKF将一种基于纯文本文件夹的知识管理方式推向标准化舞台。这一思路与 Karpathy 提出的 “LLM Wiki” 理念一脉相承直接挑战了当前主流的 RAG 向量数据库方案。本文将从技术原理、架构设计、与 RAG/MCP 的边界对比、潜在隐患等角度进行客观剖析探讨 OKF 的真实价值与适用场景。一、背景AI “记忆” 问题的两种路线过去两年为 LLM 赋予外部知识记忆的主流方案是RAGRetrieval-Augmented Generation。其典型流程为将文档切分为大量文本块chunks通过 Embedding 模型将每块映射为高维向量存入专用向量数据库如 Milvus、Pinecone、pgvector 等查询时将问题向量化做近似最近邻ANN检索取 Top-K 片段交给模型生成。这套方案能跑通但有结构性缺陷每次查询都从零开始模型拿到的是彼此孤立、缺乏上下文的碎片模型需要反复重新推导一小时前已经理清过的关系计算成本与延迟被重复支付知识之间的关联、矛盾、层级结构在 “切块 向量化” 过程中被不可逆地打散。2025 年 4 月Andrej KarpathyOpenAI 联合创始人、前 Tesla AI 负责人在 GitHub 上提出了一个相反思路 ——“LLM Wiki”不在查询时刻临时检索而是一次性将知识构建为一个相互链接的纯文本文件夹一部可像代码库一样被阅读的 “活百科全书”由 AI 负责维护、交叉引用与归档。随后Google Cloud 将这个社区构想提炼为正式规范 ——开放知识格式OKF。二、OKF 是什么一个 “反重” 的规范OKF 的核心思想可以概括为一句话知识库即文件夹概念即文件链接即关系图。2.1 核心约定概念说明Bundle一个普通文件夹代表一个完整的知识库文件每个文件对应一个概念一张表、一个指标、一份操作手册等文件路径即该概念的命名 / 地址文件间链接构成知识图谱的关系边两个特殊文件一个用于列出目录manifest一个用于记录变更changelog2.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 查询期计算维度RAGOKF Wiki关联建立查询时临时检索构建时一次性完成摘要 / 概念标记无预先生成矛盾梳理无预先处理成本支付每次查询重复支付一次构建多次读取OKF 把 “连接、概念标记、矛盾梳理、摘要” 这些昂贵的理解工作前置到 Bundle 构建阶段模型在查询时只需直接读取最终答案无需重新推导。3.2 可扩展性目录 按需加载LLM 的上下文窗口有限而大型企业可能拥有数千甚至上万个知识文件。OKF 的应对策略是每个文件夹附带简短目录manifest模型先读目录定位相关文件只加载需要的单个文件跳过其余成千上万个。这种 “索引 按需读取” 的机制使模型不会因整个知识库的规模而卡死实现了与 “全库向量检索” 完全不同的扩展路径。3.3 纯文本可版本化、可审查、可离线这是 OKF 最具工程吸引力的一点存在 Git 中像代码一样管理可做Diff在Pull Request中由人类审查可打包交给离线运行的本地模型读取无需数据库服务器、无需 API Key只要能打开文件即可。相比之下向量数据库的知识不可直观阅读、难以 Diff、依赖专有服务在工程治理上存在天然短板。四、边界澄清OKF 与 MCP、SEO 的关系为避免概念混淆需明确 OKF 的定位边界4.1 OKF ≠ MCP不竞争MCPModel 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 Git纯文本、可 Diff、可 PR 审查知识规模大、需精准检索、上下文有限✅OKF目录索引 按需加载避免全库加载数据高度动态、实时性强⚠️RAG / 混合方案OKF 静态需外部刷新机制需语义相似度检索、模糊匹配⚠️向量数据库纯文件夹难以做 ANN超大规模、毫秒级检索⚠️专业向量 / 全文检索引擎文件夹遍历性能受限强一致性、语义对齐要求高⚠️需额外定义本体ontologyOKF 本身不约束语义推荐架构混合模式实践中更可行的方向是“OKF 作为结构化知识骨架 RAG 作为动态补充”用 OKF 管理稳定、核心、需治理的领域知识指标定义、表结构、操作手册用向量数据库承载高频变动、需语义检索的内容通过MCP将两者统一暴露给 Agent。八、结语“智能体基本上就是一个装满 Markdown 文件的文件夹。”这句社区流行语点出了一个深刻变化AI 工程正在从 “堆砌复杂基础设施” 回归到 “简洁可治理的文本抽象”。科技行业花了两年时间与大量资金才意识到 —— 让机器拥有记忆未必需要奇特的基础设施一个组织良好的文本文件夹或许就够用了。但也要清醒认识到格式是可见的治理是不可见的。两个结构完全相同的 OKF 文件夹一个能在生产环境长期稳健运行另一个可能在悄悄腐烂 ——仅凭文件本身你无法区分二者。真正决定成败的是哪些内容被锁定、哪些允许 AI 重写、以及如何防止长期漂移的治理纪律。OKF 作为一个年轻规范目前 Google 之外的采用面仍有限其生命力有待观察。但无论格式最终成败它传递的核心理念已经成立在 AI 时代知识的组织方式本身就是产品的一部分。参考资料Andrej Karpathy,LLM Wiki提案GitHub2025 年 4 月Google Cloud,Open Knowledge Format (OKF)官方规范“为什么文件夹胜过向量数据库”—— 视频逐字稿整理内容相关背景RAG 架构、MCP 协议、BigQuery 数据治理实践