Introducing the Open Knowledge Format（9分钟阅读）

# 开放知识格式如何改进数据共享 来源：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上渲染，可被任何搜索工具索引 - **纯粹的文件**——可作为tar包分发，可托管在任何git仓库中，可挂载到任何文件系统上 - **纯粹的YAML前置块**——用于存放少量需要可查询的结构化字段：`type`、`title`、`description`、`resource`、`tags`和`timestamp` 如果你使用过Obsidian、Notion、Hugo或过去一年出现的任何LLM wiki模式，你会觉得这种结构很熟悉。OKF将实现这些模式互操作所需的一小部分约定形式化。 让我们看看OKF可以为你的组织解决什么问题、它是如何工作的、如何开始使用它，以及下一步的计划是什么。 ### 碎片化的上下文环境 在大多数组织中，基础模型所使用的信息绝大部分是内部知识：某个表的模式、你的业务指标含义、某个事件的运行手册、两个系统之间的连接路径、某个旧API的弃用通知，等等。 如今，这些知识单元分布在各种高度碎片化的系统中： - 带有自有API的元数据目录 - 维基、第三方系统或共享驱动器 - 代码注释、文档字符串或笔记本单元格 - 少数高级工程师的大脑 当AI智能体需要回答"如何从事件流中计算每周活跃用户？"时，它必须从这些分散且互不兼容的信息源中拼凑出答案。每个供应商都提供各自的目录、各自的SDK、各自的知识图谱模式，而这些知识都无法轻松地在不同产品或组织之间移植。 结果是：每个智能体构建者都在从头解决相同的上下文组装问题，每个目录供应商都在重新发明相同的数据模型，而知识本身则被锁定在创建它的那个信息源中。 ### 知识作为活着的维基 开发者团队正在改变构建AI智能体的方式。与其让模型一遍又一遍地搜索相同的文档来获取相同的事实，不如给智能体一个共享的markdown库，这个库会随着时间推移变得越来越有用。这可以让你的智能体承担起阅读和更新自身文件的苦差事，而你的团队则负责内容策划并像管理代码一样管理它。 著名AI研究员和教育家Andrej Karpathy在他的LLM Wiki gist（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）中清晰地阐述了这一观点。他写道："LLM不会感到无聊，不会忘记更新交叉引用，并且可以一次处理15个文件。"导致人类放弃个人维基的繁琐记录工作，恰恰是LLM擅长的事情。 类似的"知识即维基"模式以不同名称反复出现：连接到编码智能体的Obsidian vaults（https://obsidian.md/help/vault）、AGENTS.md/CLAUDE.md系列约定文件、包含index.md和log.md工件的仓库（智能体在开始实际工作之前会查阅这些文件），以及数据团队内部的"元数据即代码"仓库。 这种模式引人注目且功能强大，但每个实例都是定制化的。Karpathy的维基、你团队的维基以及某个供应商的目录导出可能看起来很像（markdown、前置块、交叉链接），但它们都没有被有意设计为可以协同工作。对于每个文档应携带哪些字段，或者哪些文件名代表什么含义，都没有达成一致的标准。因此，维基中编码的知识仍然被隔离在原始团队内部，导致每次构建新智能体时都要重复劳动。 ### 缺少的是格式，而不是另一个服务 这个问题的答案不是另一个知识服务。你需要一个**格式**，一种能够表示知识的方式，它应该： - 任何人无需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://console.cloud.google.com/bigquery?ws=!1m4!1m3!3m2!1sbigquery-public-data!2sstackoverflow）和Bitcoin公共数据集（https://cloud.google.com/blog/topics/public-datasets/bitcoin-in-bigquery-blockchain-analytics-on-public-data?e=48754805），由参考智能体生成并提交到仓库，作为符合OKF规范的实例。 这些都是有意识的概念验证。智能体演示了**一种**生产OKF的方式；格式本身并不要求特定的智能体框架或LLM。可视化工具演示了**一种**消费方式；格式本身并不要求HTML或图形视图。我们期望（并且希望！）生产者和消费者的生态系统能够远远超出我们目前发布的范围。 ### 下一步做什么 OKF v0.1是一个起点，而不是一个完成的标准。随着更多生产者和消费者的出现，以及我们共同在实践中了解到智能体真正需要什么样的知识表示，这个格式将会不断发展。 我们从第一天起就公开发布，因为这是知识格式赢得其名字的唯一途径——无论你是在构建知识目录、扩充流水线、面向AI智能体的维基，还是在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），使其能够摄取开放知识格式并将其提供给我们的智能体。你可以在这里找到相关代码和示例（https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode/demo）。 格式本身就是贡献。我们发布的工具是为了让它变得切实可行，并降低尝试它的成本。无论你的知识今天以什么形式存在，OKF都被设计成一种可以用于未来交换的**通用语言**。 --- 由Google Cloud Data Cloud团队发布。开放知识格式是一种开放规范；我们明确欢迎贡献、替代实现以及在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）