Google OKF 會取代 RAG 與向量資料庫嗎？先弄清楚 AI Agent 的新知識格式

我第一次看到「Beyond RAG: Google’s Open Knowledge Format is Replacing the Vector Database」這個說法時，覺得它很吸引人，也有點可疑。吸引人，是因為很多人確實受夠了 chunking、embedding、同步與難以除錯的 retrieval；可疑，則是因為一個 Markdown 格式，怎麼會直接取代一整套搜尋基礎設施？

答案先講在前面：不會。OKF 不會全面取代 RAG，也沒有要消滅向量資料庫。它比較像是把散落在 wiki、README、資料目錄和 Agent memory 裡的知識，整理成一種統一、可攜、可以版本控制的原始格式。

先把三者放回各自的層次

RAG 是一套工作流程：在生成答案前，先從外部來源找出相關內容，再交給模型。Vector database 是其中一種檢索基礎設施，擅長用 embedding 找出語意相近的內容。OKF 則是知識的表示與交換格式，處理的是「原始知識應該長什麼樣子」。

OKF             → 知識如何撰寫、連結、交換與版本管理
RAG             → 如何取得外部知識，再交給模型生成
Vector database → 如何儲存向量並執行語意相似搜尋

Google 的 OKF v0.1 規格甚至把「規定 storage、serving 或 query infrastructure」列為 non-goal；官方 README 則把 search index 列為可能的 consumer。換句話說，OKF 從設計上就允許你在它上面建立向量索引，不需要二選一。

OKF 是什麼？名字複雜，做法其實不難

Google Cloud 在 2026 年 6 月中旬公布 Open Knowledge Format，想把近年反覆出現的 LLM-wiki 做法整理成可以交換的規格。OKF bundle 就是一個 Markdown 目錄；每個知識概念是一個檔案，開頭放 YAML frontmatter，再用普通 Markdown link 連到其他概念。

---
type: metric
title: Weekly Active Users
description: 每週至少開啟產品一次的不重複使用者
resource: https://example.com/warehouse/weekly_active_users
tags: [analytics, growth]
---

# Definition

計算過去七天至少產生一次有效事件的不重複使用者。

# Related

- [使用者事件表](../tables/user-events.md)

規格要求的其實不多：每個非保留 Markdown 檔案要有可解析的 frontmatter，而且必須有非空的 type。title、description、resource、tags 與 timestamp 都只是建議欄位；index.md 用來逐層揭露目錄內容，log.md 則可以保存更新歷史。

這裡沒有新的資料庫、SDK 或查詢語言。人可以直接打開檔案，Agent 也可以從 index.md 開始，遇到相關概念再往下讀。Git diff、Pull Request、blame 與回復版本都能照常使用。

我用 KeepOnFirst 做了一個最小 OKF bundle

只介紹規格還不夠，所以我拿本站現有內容做了一個小實驗。Bundle 只放三種概念：一篇文章、一個互動工具，以及一個術語。它沒有複製整個網站，只提供 Agent 導覽所需的摘要、正式網址與關係。

keeponfirst-okf-demo/
├── index.md
├── log.md
├── articles/
│   └── ai-development-evolution.md
├── tools/
│   └── typing-test.md
└── glossary/
    └── context-engineering.md

如果問題是「KeepOnFirst 哪篇文章解釋模型為什麼不該一次讀完整個 repository？」，Agent 可以先讀根目錄 index，選擇 Context Engineering 詞條，再沿著 related link 找到 AI 開發進化論。這條路徑不需要 embedding，也不需要算 cosine similarity。

問題
  → index.md
  → glossary/context-engineering.md
  → articles/ai-development-evolution.md
  → 組合答案並引用正式網址

但這個結果只能說明：三個經過整理、關係明確的概念可以直接導覽。它不能證明 OKF 面對十萬份文件時，比向量搜尋更快或更準。截至 2026 年 7 月 20 日，我也沒有找到 Google 公布 OKF 對傳統 RAG 的正式 accuracy、latency 或 cost benchmark。

哪些情況真的可以先不建向量資料庫？

小型 coding repository、產品規格、API 與資料表目錄、runbook、決策紀錄，以及經過人或 Agent 整理的專案記憶，都適合先試 OKF。這些內容通常有清楚的名稱、天然的階層與明確的關係，Agent 可以靠 index、metadata、檔名搜尋和連結逐步取得。

在這些情況下，可以先不使用向量資料庫，因為任務還沒複雜到需要它。少一個 embedding pipeline，也少了重建索引、同步失敗、model migration 與 retrieval 黑箱等維運問題。

哪些情況向量搜尋仍然很難被取代？

當資料變成大量客服對話、合約、研究報告、郵件或使用者上傳內容，通常沒有精準檔名，也不一定知道該沿哪條 link 找。使用者可能用完全不同的字描述同一件事，這正是 semantic search 擅長的範圍。

大規模系統還需要考慮召回率、延遲、權限過濾、多租戶與增量更新。OKF v0.1 沒有定義這些，也沒有打算定義。它可以是 source of truth，但不會自動變成 production-grade retrieval engine。

一個比較實用的架構：知識是 source code，索引是編譯產物

我認為 OKF 最有價值的用法，是把「人真正維護的知識」和「為了查詢速度產生的索引」分開，不必把 RAG 全部刪掉。前者保留可讀性、關係、引用與歷史；後者則可以隨需求重建。

OKF bundle（source of truth）
        │
        ├─ Direct file traversal → 小型、整理過的 Agent knowledge
        ├─ BM25 index            → 精準詞、API 名稱、錯誤碼
        ├─ Vector index          → 語意與模糊查詢
        └─ Knowledge graph       → 多跳關係與正式推理
                         ↓
                    Agent context

這是我根據規格做出的工程推論，不是 Google 宣布的唯一架構。即使向量索引損壞、換 embedding model 或搬到另一家服務，原始知識仍然是可以 diff、review 與重新編譯的 Markdown。

OKF 現在還缺什麼？

目前至少有三個限制。第一，規格仍是 Version 0.1 — Draft。第二，Google 隨規格提供的 enrichment agent 與 visualizer 被官方明確稱為 proof of concept，目前主要 sample bundle 只有 GA4、Stack Overflow 與 Bitcoin。第三，type 沒有中央 taxonomy，concept link 也只有未定型的關係；正式權限模型、同步衝突與查詢 SLA 都留給實作者。

GoogleCloudPlatform repository 的 README 也註明，這些內容不是正式 Google product。所以更準確的說法是：這是 Google Cloud 團隊提出、公開在 GoogleCloudPlatform 組織下的早期規格，不是已獲得產業普遍採用的標準。

如果現在要試，我會從 5 到 20 個概念開始

不要一開始就把整間公司的文件全部轉換。選一個 Agent 真的會反覆遇到的小範圍，例如產品指標、API、部署 runbook 或架構決策；先建立根 index，為每個 concept 補上 type、title、description、resource 與必要引用，再觀察 Agent 能不能穩定找到資料。

等直接檔案導覽開始漏掉內容，再加全文搜尋；同義詞與模糊查詢變多，再加 vector index；多跳關係成為主要問題，再考慮正式 knowledge graph。讓 retrieval 的複雜度由真實失敗推動，不要只因為一張架構圖看起來比較完整就先加上去。

結論：OKF 處理的是 RAG 之前的問題

OKF 真正值得注意的地方，是它在開始 chunk、embed 與 index 以前，先追問一個更早的問題：我們有沒有一份人和 Agent 都看得懂、能追蹤來源、可以長期維護的知識？

沒有這一層，再厲害的 retrieval 也只是在更快地搜尋一堆沒有整理好的內容。OKF 想補的是這一層。它可能讓一些小型 Agent 不再需要向量資料庫，也可能讓大型 RAG 有一個更乾淨的知識來源；兩者並不衝突。