OKF vs RAG vs 向量資料庫：差在哪，什麼時候用哪一個
每次看到「Beyond RAG，OKF 正在取代向量資料庫」這種標題，我都會覺得它很吸引眼球，卻也容易把人帶偏。問題在於：它把三個根本不在同一層的東西放在一起比高下。
如果你還不確定 OKF 是什麼，可以先看這個系列的第一篇；這裡我直接處理大家真正卡住的問題——這三個到底差在哪，我什麼時候該用哪一個。
先讀：Google OKF 會取代 RAG 與向量資料庫嗎？
先把三者放回正確的層次
可以先這樣記：OKF 回答「知識該長什麼樣子」，RAG 回答「怎麼把外部知識取來再生成」，向量資料庫回答「怎麼存向量並做語意相似搜尋」。它們處理的是不同層次的問題。
| OKF | RAG | 向量資料庫 | |
|---|---|---|---|
| 它是什麼 | 知識的表示／交換格式 | 一種檢索工作流 | 一種檢索基礎設施 |
| 解決哪一層 | 知識怎麼寫、連結、版本管理 | 怎麼取外部知識再交給模型 | 怎麼存向量、做語意相似搜尋 |
| 最適合 | 精選、結構化、反覆要用的知識 | 大量非結構文件的動態搜尋 | 換句話說、模糊語意的查詢 |
| 弱點 | 規模一大，全靠檔案導覽會漏 | 要維護索引與同步 | chunk 破壞結構、可能取到過期塊 |
什麼時候 OKF 自己就夠
如果知識經過整理、結構清楚，而且 agent 會反覆使用——像是指標定義、API、部署 runbook、架構決策——OKF 通常只要一個 markdown 目錄和檔案導覽就夠了。這類知識量不大、關係明確，agent 從 index 沿著連結走，通常比只靠 embedding 猜更容易檢查，也能像 code 一樣 diff 和 review。
我在自己的 repo 就是這樣做的：把架構、決策、雷區各寫成一個節點，讓 Claude 和 Codex 不用每次重爬整個 repo。那次實驗的數據放在系列最後一篇。
實測：把 repo 做成 OKF bundle 給 agent 當記憶什麼時候你仍然需要 RAG 或向量資料庫
一旦知識變成「大量、非結構，而且查詢常常只是換個說法」，單靠檔案導覽就很難撐住。你不可能叫 agent 走訪十萬份客服對話或整個文件庫。這時候 RAG 這套工作流才派上用場；向量資料庫則是常見的檢索基礎設施，用 embedding 找語意相近的內容，對模糊查詢和同義說法比較有彈性。
OKF 也沒有要取代這一層。它的規格（現行 v0.2）明確寫著「不規定 storage、serving 或 query」，官方也把 search index 列為它的一種 consumer。換句話說，你可以在 OKF bundle 上再建向量索引。
兩者怎麼一起用
實務上可以這樣分工：OKF 當「來源層」，把精選、結構化、值得信任的知識用可讀、可版本控制的格式管好；向量／RAG 當「檢索層」，需要在大量長尾內容裡動態搜尋時，再疊到上面。agent 先做結構化查找（沿 OKF 的路徑與連結），需要時再補一次語意檢索。這會是系列後面「OKF + RAG 架構」那篇的主題。
一條實際的決策規則
別一開始就把整間公司的文件都塞進向量資料庫。先從最簡單的做法開始，讓實際觀察到的 retrieval 失敗，決定什麼時候該加複雜度。
先用 OKF + 檔案導覽。當檔案導覽開始漏內容，加全文檢索（BM25）。當查詢常常是換句話說、模糊語意，加向量索引。當問題主要變成「多跳關係」，才考慮正式的知識圖。每一步都由真實的失敗來推動，而不是先上最重的方案。
實例：本站停在第 1 步，build 只驗格式
本站 repo 的 knowledge/ 目錄就停在第 1 步。2026-11-04 的 knowledge/index.md 列了 24 個節點。這些節點分 7 組：入口、架構、參考、資料管線、雷區、操作、寫作。agent 動工前先讀 index，再依每條的一句描述挑節點讀。規格 §8 建議條目帶上該概念 frontmatter 裡的 description。本站每條都寫成「* [標題](路徑) - 描述」，build 會檢查這個格式。build 只檢查有描述，不比對描述與 frontmatter 是否相同。本站沒有建全文索引，也沒有向量索引。
build 末段有一道 OKF 閘門（scripts/check-okf.mjs），任何一份不合格就讓 build 失敗。規則照規格 §11 的三條合格條件。第一，非保留的 .md 要有可解析的 YAML frontmatter。第二，每個 frontmatter 要有非空的 type。第三，index.md 與 log.md 要照 §8、§9 的結構。
閘門另加一條本站規則：相對連結要指到存在的檔案。規格 §6.1 反而寫「Consumers MUST tolerate broken links」，也就是讀取端不能因斷鏈拒收。所以這條是本站對寫入端的要求，不是規格要求。這道閘門管「知識寫對格式沒有」，不管「agent 找不找得到」。
本文沒有量測本站的漏查率，所以不宣稱 24 個節點一定夠用。要不要走第 2 步，看的是實際漏查紀錄：agent 依描述找不到該讀的節點，才是加全文檢索的時機。
因此，把「OKF vs RAG vs 向量資料庫」放在一起比較，前提就不太對。它們其實是三個層次。比較有用的問題是：我的知識現在卡在哪一層，該補哪一層？
更正紀錄
2026-10-17 更新。v0.2 規格最早提交在 GitHub 的 GoogleCloudPlatform/knowledge-catalog。提交日是 2026-07-24（UTC，commit 780fe9d）。原文寫「v0.1 規格」，現在改成「規格（現行 v0.2）」。v0.2 仍把 storage、serving、query 列為 non-goal，本文論點不變。文末補上規格與官方 README 兩個來源。