开放知识格式如何改善数据共享 | Google Cloud 博客

来源: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing 抓取时间: 2026-07-21 16:19:20

数据分析

介绍开放知识格式 2026年6月12日

Sam McVeety

技术主管，数据分析，工程，数据云，Google Cloud

Amir Hormati

技术主管，BigQuery，工程，数据云，Google Cloud

立即试用 Gemini Enterprise 商业版

工作场所 AI 的前门 立即试用 随着基础模型的不断改进，缺乏相关上下文往往限制了它们的能力，尤其是当它们用于构建智能体系统时。虽然这些模型可以帮助您编写代码、总结文档或分析数据集，但它们仍然需要正确的信息才能产生准确且可操作的结果。 这就是为什么今天我们要推出开放知识格式（OKF），这是一个开放规范，将 LLM-wiki 模式正式化为一种可移植、可互操作的格式。这是一个供应商中立、智能体和人类友好的标准，用于表示现代 AI 系统所需的元数据、上下文和精选知识。 已发布的 OKF v0.1 将知识表示为带有 YAML 前端元数据的 Markdown 文件目录，并带有一小组商定的约定，使不同生产者编写的 Wiki 可以被不同智能体使用而无需翻译。 就是这样。没有复杂的压缩方案，没有新的运行时，不需要 SDK。OKF 文档包是：

• 纯 Markdown——可在任何编辑器中阅读，可在 GitHub 上渲染，可被任何搜索工具索引
• 纯文件——可作为 tarball 交付，可托管在任何 git 仓库中，可挂载在任何文件系统上
• 纯 YAML 前端元数据——用于需要可查询的一小部分结构化字段：类型、标题、描述、资源、标签和时间戳

如果您使用过 Obsidian、Notion、Hugo 或过去一年出现的任何 LLM Wiki 模式，这种形式会感觉很熟悉。OKF 正式确定了使这些模式可互操作所需的一小组约定。 让我们看看 OKF 可以为您的组织解决什么问题，它如何工作，如何开始使用它，以及接下来会发生什么。

碎片化的上下文格局

在大多数组织中，基础模型使用的信息绝大多数是内部知识：表的模式、您企业对指标的定义、事件的运行手册、两个系统之间的连接路径、旧 API 的弃用通知等。 如今，这些知识原子存在于各种高度碎片化的系统中：

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

当 AI 智能体需要回答"如何从我们的事件流中计算每周活跃用户数？"时，它必须从这些分散的、互不兼容的表面中组装答案。每个供应商都提供自己的目录、自己的 SDK、自己的知识图模式，而且没有一种知识可以轻松地跨产品或组织移植。 结果是：每个智能体构建者都在从头开始解决相同的上下文组装问题，每个目录供应商都在重新发明相同的数据模型，而知识本身被锁定在创建它的任何表面后面。

知识作为活的 Wiki

开发者团队正在改变构建 AI 智能体的方式。您可以给您的智能体一个共享的 Markdown 库，随着时间的推移它会变得越来越有用，而不是使用模型一遍又一遍地在相同的文档中搜索相同的事实。这让您的智能体承担阅读和更新自己文件的苦差事，而您的团队则策划内容并像代码一样管理它。 Andrej Karpathy，著名的 AI 研究者和教育家，在他的 LLM Wiki gist 中最清晰地表达了这个想法。"LLM 不会感到无聊，不会忘记更新交叉引用，并且可以在一次遍历中触及 15 个文件，"他写道。导致人类放弃个人 Wiki 的簿记工作正是 LLM 擅长的。 类似的知识即 Wiki 模式以不同的名称不断出现：连接到编码智能体的 Obsidian vaults、AGENTS.md / CLAUDE.md 系列约定文件、智能体在进行实际工作之前咨询的充满 index.md 和 log.md 工件的仓库，以及数据团队内部的"元数据即代码"仓库。 这种模式引人注目且功能强大，但每个实例都是定制的。Karpathy 的 Wiki 和您团队的 Wiki 以及供应商的目录导出可能看起来都很相似（Markdown、前端元数据、交叉链接），但它们都没有被有意设计为协作。没有关于每个文档应该携带哪些字段，或者什么文件名意味着什么的商定答案。结果是，编码在 Wiki 中的知识仍然孤立在原始团队中，导致每次构建新智能体时都会产生冗余工作。

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

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

• 任何人都可以生成，无需 SDK
• 任何人都可以使用，无需集成
• 在系统、组织和工具之间移动后仍然存在
• 与它描述的代码一起驻留在版本控制中
• 人类可读且智能体可解析：相同的文件，没有翻译层

根据设计，OKF 就是这种格式。

OKF 如何工作：一屏中的设计

一个 OKF 包 是一个 Markdown 文件目录，代表 概念：您想要捕获的任何内容，包括表、数据集、指标、剧本、运行手册和 API。每个概念都是一个文件。文件路径是概念的身份： 正在加载... sales/ ├── index.md ├── datasets/ │ ├── index.md │ └── orders_db.md ├── tables/ │ ├── index.md │ └── orders.md │ └── customers.md └── metrics/ │ ├── index.md └── weekly_active_users.md 每个概念文档都有一个小的 YAML 前端元数据块用于结构化字段，以及一个用于其他所有内容的 Markdown 主体： 正在加载... --- type: BigQuery Table title: Orders description: 每个已完成客户订单一行。 resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders tags: [sales, revenue] timestamp: 2026-05-28T14:30:00Z \--- # 模式 | 列 | 类型 | 描述 | |---------------|-----------|------------------------------------------| | order_id | STRING | 全局唯一订单标识符。 | | customer_id | STRING | FK 到 customers。 | # 连接 与 customers 在 customer_id 上连接。 概念通过普通的 Markdown 链接相互链接，将目录变成一个比文件系统隐含的父子链接更丰富的关系 图。包可以选择性地包含 index.md 文件（用于智能体在层次结构中导航时的渐进式披露）和 log.md 文件（用于更改的时间顺序历史）。 完整的 v0.1 规范（包括一致性标准、交叉链接规则和少量保留文件名）可以放在一个页面上。

设计背后的三个原则

1. 最低限度的意见化。 OKF 对每个概念只要求一件事：一个类型字段。其他所有内容（例如，存在什么类型、要包括哪些其他字段、主体有哪些部分）都留给生产者。规范定义了互操作性表面，而不是内容模型。 2. 生产者/消费者独立性。 OKF 清楚地分离了编写知识的人和使用知识的人。人类手工编写的包可以被 AI 智能体使用。元数据导出管道生成的包可以在可视化工具中浏览。一个 LLM 合成的包可以被另一个 LLM 查询。格式是契约；两端的工具是可独立交换的。 3. 格式，而不是平台。 OKF 不绑定到任何特定的云、数据库、模型提供商或智能体框架。它永远不需要专有帐户或 SDK 来读取、写入或提供服务。我们将其作为开放标准发布，因为知识格式的价值来自有多少方使用它，而不是来自谁拥有它。

我们随规范一起提供的内容

为了使格式具体化，我们在生产者和消费者两端都发布了 参考实现：

• 一个 丰富智能体，它遍历 BigQuery 数据集，为每个表和视图起草 OKF 概念文档，然后运行第二次 LLM 遍历，抓取权威文档，并用引用、模式和连接路径丰富每个概念。
• 一个 静态 HTML 可视化工具，它将任何 OKF 包变成一个单一的自包含文件中的交互式图视图；没有后端，在查看端不需要安装，没有数据离开页面。
• 三个可直接浏览的示例包：GA4 电子商务、Stack Overflow 和 比特币公共数据集，由参考智能体生成并作为符合 OKF 的活示例提交到仓库。

这些是概念证明，是故意的。智能体演示了一种生成 OKF 的方式；该格式不需要任何特定的智能体框架或 LLM。可视化工具演示了一种使用它的方式；该格式不需要 HTML 或图视图。我们期望（并希望！）生产者和消费者的生态系统将远远超出我们已经交付的范围。

我们从这里走向何方

OKF v0.1 是一个起点，而不是一个完成的标准。随着更多生产者和消费者的出现，以及随着我们共同了解智能体在实践中实际需要什么知识表示，该格式将不断发展。 我们从第一天开始就公开发布，因为这是知识格式赢得其名称的唯一方式，无论您是在构建知识目录、丰富管道、为 AI 智能体量身定制的 Wiki，还是 AI 知识领域的任何东西。 从这里开始，我们鼓励您：

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

仓库、规范和示例包可在 GitHub 上获得。我们还更新了 Google Cloud 的 知识目录，使其能够摄取开放知识格式并将其提供给我们的智能体。您可以在 这里 找到相关代码和示例。 格式本身就是贡献。我们提供的工具的存在是为了使其成为现实，并降低尝试它的成本。无论您今天的知识采取什么形式，OKF 都旨在成为它明天可以交换的通用语言。

由 Google Cloud 数据云团队发布。开放知识格式是一个开放规范；明确欢迎贡献、替代实现以及在 Google 产品之外的采用。 除了作者之外，这项工作的完成还要感谢 Google 许多其他人的关键想法，我们感谢他们的贡献。 发表于

• 数据分析
• AI 与机器学习
• BigQuery

相关文章

数据分析提升您的列级安全性：在 BigQuery 中使用 IAM 数据治理标签作者 Vignesh Rajamani • 5 分钟阅读 数据分析使用 BigQuery 和 %%bqsql 魔法弥合 SQL 和 Python 之间的差距作者 Tim Swena • 7 分钟阅读 数据分析如何使用 BigQuery 大规模分析和治理 Gemini Enterprise 应用使用情况作者 Aishwarya Prabhat • 9 分钟阅读 数据分析前沿与中心：谁来评估评估？作者 Manav Garg • 10 分钟阅读