Google Cloud的Open Knowledge Format非常棒，标准化了基于LLM-Wiki灵感的分层级、有关系的文本知识结构，我非常喜欢这个标准。

https://t.co/vHZXvjN2Vv

Open Knowledge Format如何改善数据共享

来源：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/ 随着基础模型的不断改进，缺乏相关上下文往往限制了它们的能力，尤其是在它们被用于构建智能代理系统时。虽然这些模型可以帮助你编写代码、总结文档或分析数据集，但它们仍然需要正确的信息才能产生准确且可操作的结果。

因此，今天我们推出了Open Knowledge Format (OKF)，这是一个开放规范，它将LLM-wiki（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）模式形式化为一种可移植、可互操作的格式。这是一个供应商中立、对代理和人类友好的标准，用于表示现代AI系统所需的元数据、上下文和整理的知识。

按发布版本，OKF v0.1将知识表示为一个包含YAML前置元数据的Markdown文件目录，并采用一小套约定俗成的规则，使得不同生产者编写的Wiki可以被不同代理直接消费，无需转换。

就是这样。没有复杂的压缩方案，没有新的运行时，没有必需的SDK。一个OKF文档包就是：

• 纯Markdown——可在任何编辑器中阅读，可在GitHub上渲染，可被任何搜索工具索引
• 纯文件——可作为tarball分发，可托管在任何Git仓库中，可挂载到任何文件系统
• 纯YAML前置元数据——用于少数需要可查询的结构化字段：type、title、description、resource、tags和timestamp

如果你用过Obsidian、Notion、Hugo或过去一年出现的任何LLM Wiki模式，你会觉得它的结构很熟悉。OKF将实现这些模式互操作所需的一小套约定进行了标准化。

接下来，我们来看OKF能为你的组织解决什么问题，它是如何工作的，如何开始使用它，以及未来的发展方向。

碎片化的上下文环境

在大多数组织中，基础模型使用的信息绝大多数是内部知识：表的模式、业务指标的含义、事故的应急处置手册、两个系统之间的连接路径、旧API的废弃通知等等。

如今，这些知识的原子片段存在于各种高度碎片化的系统中：

• 拥有各自API的元数据目录
• Wiki、第三方系统或共享驱动器
• 代码注释、文档字符串或笔记本单元格
• 少数高级工程师的头脑中

当AI代理需要回答“如何从事件流中计算每周活跃用户？”时，它必须从这些分散、互不兼容的界面中拼凑答案。每个供应商都提供自己的目录、自己的SDK、自己的知识图谱模式，而这些知识都无法轻易地在产品或组织之间移植。

结果是：每个代理构建者都在从头解决同样的上下文组装问题，每个目录供应商都在重新发明相同的数据模型，而知识本身则被锁定在最初创建它的界面中。

作为活Wiki的知识

开发团队正在改变他们构建AI代理的方式。与其让模型一遍又一遍地搜索相同的文档来获取相同的事实，你可以为你的代理提供一个共享的Markdown库，它会随时间推移变得越来越有用。这可以让你的代理承担起阅读和更新自己文件的繁重工作，而你的团队则负责管理内容，像管理代码一样管理它。

著名AI研究员和教育家Andrej Karpathy在他的LLM Wiki Gist（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）中最清晰地阐述了这一想法。他写道：“LLM不会感到无聊，不会忘记更新交叉引用，而且可以一次处理15个文件。”那些导致人类放弃个人Wiki的记账工作，正是LLM所擅长的。

类似的“知识即Wiki”模式以不同名称不断出现：连接到编码代理的Obsidian vaults、AGENTS.md/CLAUDE.md家族的约定文件、充斥着agent在进行实际工作前需要查阅的index.md和log.md工件的仓库、以及数据团队内部的“元数据即代码”仓库。

这种模式引人注目且强大，但每个实例都是定制的。Karpathy的Wiki、你团队的Wiki以及供应商的目录导出可能看起来相似（Markdown、前置元数据、交叉链接），但没有任何一个是故意设计为相互协作的。对于每个文档应该携带什么字段，或者文件名有什么含义，没有达成共识。因此，Wiki中编码的知识仍然孤立在原始团队中，导致每当构建新代理时就需要重复劳动。

缺少的是格式，而不是另一个服务

这个问题的答案不是另一个知识服务。你需要一种格式，一种表示知识的方式，它需要满足：

• 任何人都可以生产，无需SDK
• 任何人都可以消费，无需集成
• 在系统、组织和工具之间迁移时仍能存活
• 与它所描述的代码一起存在于版本控制中
• 人类可读且代理可解析：同一个文件，无需转换层

通过设计，OKF就是这种格式。

OKF的工作原理：一个屏幕内的设计

一个OKF包是一个Markdown文件目录，表示概念：任何你想捕捉的东西，包括表、数据集、指标、剧本、应急手册和API。每个概念对应一个文件。文件路径就是概念的标识：

每个概念文档有一个小的YAML前置元数据块用于结构化字段，以及一个Markdown正文用于其他所有内容：

概念之间通过普通的Markdown链接互相连接，这使得目录变成了一个图，其关系比文件系统隐含的父子链接更为丰富。包可以可选地包含index.md文件（用于代理在层级中导航时的渐进式展示）和log.md文件（用于按时间顺序记录变更历史）。

完整的v0.1规范（包括一致性标准、交叉链接规则以及少量保留文件名）只占一页篇幅。

设计背后的三个原则

**1. 最小化意见。**OKF对每个概念只要求一件事：一个type字段。其他所有内容（例如，有哪些类型、包含哪些其他字段、正文有哪些章节）都留给生产者决定。规范定义了互操作界面，而不是内容模型。

**2. 生产者/消费者独立。**OKF明确区分了谁写知识和谁消费知识。人类手工编写的包可以被AI代理消费。元数据导出管道生成的包可以在可视化工具中浏览。一个LLM合成的包可以被另一个LLM查询。格式就是契约；两端的工具可以独立更换。

**3. 格式而非平台。**OKF不绑定任何特定的云、数据库、模型提供商或代理框架。它永远不需要专有账户或SDK来读取、写入或提供服务。我们将其作为开放标准发布，因为知识格式的价值在于有多少方使用它，而不在于谁拥有它。

伴随规范我们发布了什么

为了让格式更加具体，我们发布了生产端和消费端的参考实现：

• 一个增强代理，它会遍历BigQuery数据集，为每个表和视图草拟一个OKF概念文档，然后运行第二次LLM遍历，爬取权威文档并用引用、模式和连接路径来丰富每个概念。
• 一个静态HTML可视化器，它可以将任何OKF包转换为单个自包含文件中的交互式图谱视图；无需后端，无需在查看端安装，数据不会离开页面。
• 三个现成可浏览的示例包：GA4电子商务（https://developers.google.com/analytics/bigquery/web-ecommerce-demo-dataset）、Stack Overflow（https://pantheon.corp.google.com/marketplace/product/stack-exchange/stack-overflow?e=PanGm2themeLaunch::PanGm2themeEnabled,PanGm2themeDarkLaunch::PanGm2themeDarkControl&mods=pan_ng2&project=hormati-bqml）和Bitcoin公共数据集（https://cloud.google.com/blog/topics/public-datasets/bitcoin-in-bigquery-blockchain-analytics-on-public-data?e=48754805），由参考代理生成并提交到仓库作为符合OKF的活示例。

这些都是故意做的概念验证。代理演示了生产OKF的一种方式；格式本身不要求特定的代理框架或LLM。可视化器演示了消费OKF的一种方式；格式本身不要求HTML或图谱视图。我们期望（并且希望！）生产者和消费者的生态系统远远超出我们目前已发布的。

我们下一步的打算

OKF v0.1是一个起点，而不是一个最终的标准。随着越来越多的生产者和消费者出现，以及我们共同学习代理在实践中实际需要什么样的知识表示，该格式将继续演进。

我们从第一天起就公开出版，因为这是知识格式赢得其名称的唯一方式，无论你是在构建知识目录、增强管道、专门为AI代理设计的Wiki，还是任何AI知识领域的东西。

从现在开始，我们鼓励你：

• 阅读规范（它很短！）
• 为你的源系统、数据库、文档站点编写生产者
• **编写消费者：**一个查看器、一个搜索索引、一个能对包进行推理的代理
• 针对自己的数据尝试参考实现
• **提交问题、发送PR或提出扩展：**规范是版本化的，并明确设计为向后兼容增长。

仓库、规范以及示例包都可以在GitHub（https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf）上找到。我们还更新了Google Cloud的Knowledge Catalog（https://cloud.google.com/blog/products/data-analytics/introducing-the-google-cloud-knowledge-catalog），使其能够获取Open Knowledge Format并提供给我们的代理。你可以在相关代码和示例中找到具体实现（https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode/demo）。

格式本身就是贡献。我们发布的工具是为了让它变得真实，并降低尝试的成本。无论你今天的知识以何种形式存在，OKF的设计目标就是成为它明天可以交换的通用语言。

由Google Cloud Data Cloud团队发布。Open Knowledge Format是一个开放规范；我们明确欢迎贡献、替代实现以及超越Google产品的采纳。

除了作者之外，这项工作还得益于Google内部许多其他人的关键想法，我们感谢他们的贡献。

发布于：

• 数据分析（https://cloud.google.com/blog/products/data-analytics）
• AI与机器学习（https://cloud.google.com/blog/products/ai-machine-learning）
• BigQuery（https://cloud.google.com/blog/products/bigquery）