超越 RAG：Google OKF 与向量数据库的新分工

📝

Google Cloud 发布 Open Knowledge Format（OKF）v0.1 草案，以 Markdown + YAML 定义可移植知识格式，不取代 RAG 而是提供标准化知识地图——格式优于平台、Agent 可参与维护、显式链接形成可遍历关系。混合架构才是未来。

本文转载自微信公众号，如有侵权请联系删除。

过去三年，面对企业级 AI 的上下文问题，工程师的默认反应几乎都是：”搭一条 RAG 流水线吧。”

部署向量数据库，把公司 PDF 切分成块，生成向量嵌入，运行时再做语义相似度搜索。这种方式对于模糊、探索性的搜索还算够用。

但到了 2026 年，”万物皆可 RAG”这条路的问题已经无法忽视：切块可能破坏复杂表格的结构；向量检索本质上是概率性的，可能拿到正确片段，也可能拿到过时内容；要让向量嵌入与快速变化的数据保持同步，运维成本也很高。

为了解决这类问题，Google Cloud 发布了 Open Knowledge Format（OKF）v0.1 草案。它不是新的云数据库，不是 LLM 框架，也不是 SDK，而是一份厂商中立、可移植的开放规范，将”LLM Wiki”范式正式化。这个思路与 Andrej Karpathy 等研究者倡导的结构化、相互连接的知识库概念一脉相承。

OKF 提供了另一种组织知识的方式：不只依赖对非结构化文件的概率搜索，还可以让人类和智能体沿着目录层级与显式链接，浏览一套持续维护的知识集合。

OKF 到底是什么？

OKF 规范了组织知识、业务逻辑和后端 schema 的表达方式，让不同 AI agent 能够读取和遍历这些内容，而不必依赖某个厂商的专用格式。

OKF 将一套自包含的知识集合称为 Knowledge Bundle（知识包）。它本质上是一个目录树，其中每个概念都由带 YAML frontmatter 的纯文本 Markdown 文件表示。

在 OKF bundle 中，文件路径定义了概念 ID。信息不是简单丢进索引，而是被整理成聚焦的单一”概念”文件，例如内部 API 契约、财务指标或数据库 schema。

一个 OKF Bundle 的结构

company_brain/
├── index.md               # 根目录，用于渐进式展开
├── engineering/
│   ├── index.md
│   └── service_mesh.md    # 架构概念
└── analytics/
    ├── index.md
    ├── tables/
    │   ├── customers.md   # 单个数据库概念文件
    │   └── billing.md
    └── metrics/
        └── active_users.md # 精确的业务定义

每个概念文件都遵循极简设计：顶部是 YAML frontmatter，其中只有 type 为必填字段；下方则是自由格式的 Markdown 正文。

OKF 文件示例

下面是一个符合规范的 OKF 文件，用来描述关键业务指标：

---
type: Metric
title: Weekly Active Users (WAU)
description: Weekly active users based on core API activity.
resource: https://github.com/internal-org/dbt/models/wau.sql
tags: [analytics, engagement]
timestamp: 2026-06-15T00:00:00Z
---

# Weekly Active Users (WAU)

The total unique count of user IDs who have triggered at least one
core backend API transaction within a rolling 7-day window.

## Computation Rules

We explicitly exclude internal QA and test accounts:
`WHERE user_id NOT IN (SELECT user_id FROM staging.internal_testers)`

## Related Components

- See `customers` for primary user dimension mappings.
- See `billing` to correlate usage with active subscription cycles.

## Citations

[1] [WAU SQL source](https://github.com/internal-org/dbt/models/wau.sql)

OKF 的三大核心支柱

与传统企业 wiki 或只依赖向量检索的 RAG 系统相比，OKF 有三个值得关注的设计原则：

格式优于平台。 OKF 不要求云账号、重型软件或专用 SDK。它由普通文件组成，可以放进 Git，用 pull request 审计，并逐行追踪知识随时间发生的变化。

智能体可以参与维护。 文档很容易过时。在一种典型的 OKF 实践中，后台 AI agent 可以充当维护引擎：当代码或数据库 schema 更新时，agent 同步修改相关 Markdown 文件、修复交叉链接，并在 bundle 的 log.md 中记录变化。需要注意的是，这是可选实践，不是规范强制的运行方式。

通过显式链接形成可遍历关系。 OKF 使用标准 Markdown 链接（如 customers）表达概念之间的关系。目录层级与链接共同形成图状结构，AI agent 可以按路径逐步遍历，而不必只依赖余弦相似度猜测相关内容。

真实场景：RAG vs. OKF

看看企业里的 AI 数据分析师 agent 日常工作流会有什么变化。

目标： 你问 AI agent：”写一条供管理层使用的 SQL，计算第二季度的 Churn Rate（流失率）。”

仅靠 RAG 的方式

1. Agent 把你的查询转成向量嵌入
2. 在向量数据库里搜索成千上万个被切碎的 PDF、Confluence 页面和历史 Slack 记录
3. 数据库返回三块内容：一份 2023 年的 PPT、一篇旧的工程 wiki、两位数据工程师争论怎么算流失率的聊天记录
4. LLM 把这些相互矛盾的定义拼在一起，最终生成一条从错误 schema 读取数据的 SQL

OKF 方式

1. Agent 读取公司 OKF bundle 的根 index.md
2. 直接导航到 analytics/metrics/churn_rate.md
3. 提取经过审计的 SQL 片段和结构逻辑
4. 跟随文件中的标准 Markdown 链接 customers，查找当前 schema 定义和 join key
5. 在生成查询时引用具体文件、更新时间和负责人，从而提高结果的准确性与可审计性

正面对比：RAG vs. OKF

特性	RAG	OKF
核心结构	切分后的向量片段	结构化 Markdown + YAML frontmatter
导航方式	通常依赖概率性的向量近邻	目录层级与显式链接
人类可读性	取决于原始资料和系统界面	高，可直接在 GitHub 或 Obsidian 中阅读
维护方式	重新切块、索引与更新嵌入	Git commit、diff 和 pull request
最佳场景	海量、非结构化原始数据归档	高风险、权威的业务定义和规则

现代 AI 栈：混合架构

RAG 不会完全消失，它的角色正在变化。让概率检索系统单独决定公司的法定税号或”收入”定义，本身就是高风险设计。OKF 更适合承载这些需要明确来源、版本和责任人的权威知识。

一种更合理的方向是混合架构，由 AI Router 充当流量控制器：

        [ 用户请求 ]
              │
              ▼
        ┌──────────────┐
        │  AI Router   │
        └──────┬───────┘
               │
    ┌──────────┴──────────────┐
    ▼                         ▼
[ OKF Bundle ]         [ RAG Pipeline ]
(核心规则、schema、    (归档 PDF、客服工单、
 运行手册、精确知识)     大规模探索)

用 OKF 管理结构明确、可审计的知识，用 RAG 搜索宽泛的历史资料，组织就能构建更稳定的 AI 系统。OKF 没有消灭检索，也没有取代向量数据库；它提供的是一种标准化知识地图，让人类和 agent 更清楚应该去哪里查找、如何追溯来源。

---

更多内容请参考：

• Secret Dev 原文
• Google Cloud 官方博客
• OKF Spec（GitHub）