从 Vector Retrieval 到 Knowledge Graph：Google OKF 的企业 AI 上下文架构解析

过去几年，企业AI领域遇到上下文问题，第一个冒出来的答案几乎都是："搭个RAG流水线吧。"

这套做法听起来很标准：上一个向量数据库，把公司那些PDF切成小段，生成嵌入向量，运行时再做语义相似度搜索。如果只是模糊地探索式搜索，确实够用。

但到了2026年，所有东西都靠RAG来搞的裂缝已经大到没法忽视。切块会破坏表格结构，向量检索本质上是概率性的——你可能拿到对的块，也可能捞到过时的块。让嵌入跟数据快速更新保持同步？那绝对是运维的噩梦。

就在这时候，Google Cloud开源了

，让"RAG一切"的噪音消停了下来。这既不是新云数据库，也不是LLM框架或SDK。它是一个供应商中立、可移植的规范，用来正式化——就是AI研究者Andrej Karpathy长期倡导的那种结构化的、互联的"大脑"概念。

OKF把策略从"在非结构化文件上概率搜索"转向了"在活的、可供人类和agent阅读的知识图谱里做确定性导航"。这才是核心变化所在。

Open Knowledge Format (OKF) 到底是什么？

OKF标准化了组织知识、业务逻辑和后端模式的结构化方式。任何AI agent都能原生遍历并理解这些，不需要自定义翻译层。

OKF集合——称为

——并不是昂贵的黑盒数据库。它就是一个由纯文本Markdown文件组成的标准目录，用YAML frontmatter包裹着。

OKF Bundle 的结构

在OKF bundle里，目录路径定义了概念的唯一身份。信息不是被粗暴倒进索引，而是被编译成高度聚焦、单一的"概念"文件（比如内部API合约、财务指标或数据库模式）。

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

每个概念文件遵循严格但极简的设计：顶部是一个

（只要求一个字段：type），后面是。

下面是真实OKF文件的例子，描述了一个关键业务指标：

---
type: metric
id: analytics/metrics/active_users
title: Weekly Active Users (WAU)
owner: data-eng@company.com
updated_at: 2026-06-15
citations:
  - source: "https://github.com/internal-org/dbt/models/wau.sql"
---

# Weekly Active Users (WAU)
在滚动7天窗口内，触发了至少一次核心后端API交易的唯一用户ID总数。
## 计算规则
我们明确排除内部QA和测试账号：
`WHERE user_id NOT IN (SELECT user_id FROM staging.internal_testers)`
## 相关组件
- 见[[analytics/tables/customers]]获取用户维度映射。
- 见[[analytics/tables/billing]]关联活跃订阅周期。

OKF 的三大核心支柱

OKF之所以能在传统企业wiki和RAG失败的地方站稳脚跟，是因为三条架构原则：

• 格式优于平台：
  OKF不需要云账户、重型软件或定制SDK。完全git-native。你可以做版本控制，通过pull request审计，精确追踪公司知识随时间的变化。

• LLM当wiki管理员：
  人类历来不擅长维护文档；文档会立刻腐化。在OKF范式里，后台AI agents充当维护引擎。当开发者更新代码或数据库模式时，agent会自动修改相关OKF markdown文件，修复交叉链接，并将更新记录到bundle的log.md里。

• 通过图链接实现确定性：
  OKF不靠余弦相似度数学来猜哪些数据跟查询相关，而是用显式的Markdown链接（[[concept_path]]）。这能把标准文件夹转化为绝对的、确定性的

  知识图谱
  ，AI agent可以沿着它逻辑遍历。

真实场景：RAG vs. OKF

看看这怎么改变企业内部AI数据分析agent的日常工作流。

目标

你向AI agent请求："写一个executive SQL查询，用来计算我们Q2的Churn Rate。"

旧的RAG方式

• agent把你的查询转成向量嵌入。

• 它搜索包含数千个被切块的PDF、Confluence页面和历史Slack日志的向量数据库。

• 数据库返回三个块：一份2023年的PPT、一篇旧的工程wiki，还有两位数据工程师关于怎么算churn的争论对话。

• LLM把相互冲突的定义混在一起，困惑了，写出了一个从错误模式拉数据的损坏SQL查询。

OKF方式

• agent读取公司OKF bundle的根index.md。

• 它直接遍历到analytics/metrics/churn_rate.md。

• 它提取绝对的、经过审计的SQL片段和结构逻辑。

• 它沿着文件的显式Markdown链接[[analytics/tables/customers]]，立刻找到当前模式定义和连接键。

• agent第一次尝试就生成了完全准确的查询，并引用了确切的文件、更新时间以及负责该文件的工程师。

正面对比：RAG vs. OKF

核心结构：分段、碎片化的向量块 | 结构化Markdown + YAML frontmatter
检索引擎：概率式（数学近邻）| 确定性（显式图链接遍历）
人类界面：低（需要查询工程数据库）| 高（可在GitHub或Obsidian中原生阅读）
维护成本：高（重新索引、嵌入漂移）| 低（Git提交和pull请求）
最佳用例：海量、非结构化、原始数据归档 | 高风险、权威的业务定义和规则

现代AI栈：一种混合架构

RAG不会完全消失。它的角色在变。让概率系统去找公司税务标识符或"Revenue"的定义，根本就是个糟糕的设计。对于这些高风险的绝对企业事实，OKF正在取代RAG。

从现在看，团队在构建一种混合架构。AI路由器充当流量控制器：

[ 用户请求 ]
                  │
                  ▼
           ┌──────────────┐
           │  AI 路由器   │
           └──────┬───────┘
                  │
      ┌──────────────┴──────────────┐
      ▼                             ▼
[ OKF Bundle ]               [ RAG Pipeline ]
(核心规则、模式、     (归档PDF、客户
  运行手册、精度)        工单、规模探索)

通过用OKF实现确定性精度，用RAG搜索广泛历史数据，组织正在构建既高度强大又异常稳定的AI系统。OKF没有消灭检索；它为AI agents提供了一张标准化地图，帮它们找到内容。

想了解Open Knowledge Format的完整逐步技术解析，可以看看OKF规范和构建bundle的详细技术解析。这个视频资源解释了标准的结构设计，回顾了GitHub规范，展示了如何用纯Markdown文件开始为AI agents组织知识。