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.1 規格明確寫著「不規定 storage、serving 或 query」，官方也把 search index 列為它的一種 consumer。換句話說，你可以在 OKF bundle 上再建向量索引。
兩者怎麼一起用
實務上可以這樣分工：OKF 當「來源層」，把精選、結構化、值得信任的知識用可讀、可版本控制的格式管好；向量／RAG 當「檢索層」，需要在大量長尾內容裡動態搜尋時，再疊到上面。agent 先做結構化查找（沿 OKF 的路徑與連結），需要時再補一次語意檢索。這會是系列後面「OKF + RAG 架構」那篇的主題。
一條實際的決策規則
別一開始就把整間公司的文件都塞進向量資料庫。先從最簡單的做法開始，讓實際觀察到的 retrieval 失敗，決定什麼時候該加複雜度。
先用 OKF + 檔案導覽。當檔案導覽開始漏內容，加全文檢索（BM25）。當查詢常常是換句話說、模糊語意，加向量索引。當問題主要變成「多跳關係」，才考慮正式的知識圖。每一步都由真實的失敗來推動，而不是先上最重的方案。
因此，把「OKF vs RAG vs 向量資料庫」放在一起比較，前提就不太對。它們其實是三個層次。比較有用的問題是：我的知識現在卡在哪一層，該補哪一層？