OKF + RAG 一起用：給 AI agent 一張地圖，再給它一個搜尋

比較篇先把層次分清楚了：OKF、RAG、向量資料庫其實分屬三層。接著就要問一個更實際的問題：它們要怎麼組在一起？

兩層架構：來源層 + 檢索層

實務上可以分工。OKF 當「來源層」：把精選、結構化、值得信任的知識，用可讀、可連結、可版本控制的格式管好——指標定義、schema、runbook、架構決策。向量／RAG 當「檢索層」：需要在大量長尾內容裡動態搜尋時，再疊到上面。

agent 的知識流：先查找，再檢索

agent 會先做「結構化查找」：從 OKF 的 index 進來，沿 type 與連結走到它確定需要的節點。這一段要的是精確與可信；如果問題落在大量非結構的長尾裡，結構化查找不夠用，再補一次「語意檢索」。順序很重要：先確定能被信任的那部分，再用搜尋補模糊地帶。

為什麼「用 OKF 當來源」會讓 RAG 也更好

把 OKF 放在來源層，帶來的好處不只多一層管理，也會直接改善上面的檢索。因為結構被保留，chunk 不會把表格與定義切殘；關係是明確連結，多跳問題有圖可走；每個概念有固定的路徑身分，引用（citation）更穩定、也更容易追溯。來源可以版本控制，索引也能隨時從乾淨的來源重建，同步問題更容易追查。

OKF v0.1 規格已把 search index 列為它的一種 consumer，所以你可以直接從 bundle 建向量索引。實際組合就是「乾淨的來源，加上需要時才啟用的搜尋」。

什麼時候該把檢索層加上去

別一開始就上最重的方案。照比較篇的規則做：先用 OKF＋檔案導覽；當檔案導覽開始漏內容，加全文檢索；當查詢常常是換句話說、模糊語意，才加向量索引；當問題主要變成多跳關係，再考慮正式的知識圖。觀察到哪一種 retrieval 失敗，再決定是否往上加。

可以把整套架構記成一句話：OKF 給 agent 一張地圖，RAG 給它一個搜尋。地圖讓它在需要精確與信任的地方走得準，搜尋則補上模糊與長尾內容。知識系統要擴大時，這兩者通常會疊在一起。