RAG 為什麼會踩坑：chunking 破壞結構、向量檢索的不確定性，還有同步惡夢

在 demo 裡，RAG 往往看起來很順：丟一堆文件進去，問問題，它找出相關段落再生成答案。但知識一旦變得真實、持續更新又結構複雜，問題就會一個個冒出來。真正麻煩的地方多半不在模型，而在「檢索」這一層。

我想把它的使用邊界講清楚：RAG 在什麼情況下容易踩坑，以及哪些知識該用能保留結構的格式，哪些才真的需要向量檢索。

坑一：chunking 把結構切碎

向量檢索需要先把文件切成 chunk 再 embedding。問題是，很多知識的意義在「結構」裡：一張表格、一份 schema、一個橫跨數段的定義，被切開之後，每個 chunk 單獨看都殘缺。你可能拿到「這張表有這個欄位」，卻拿不到「它跟另一張表怎麼 join」。

坑二：向量檢索是機率性的

向量檢索靠語意相似度找內容，結果只能說「大概相關」，不能當成「一定正確」。你可能拿到對的 chunk，也可能拿到一個語意很近、但其實過期或講的是另一個情境的 chunk。對「差不多就好」的問答可以，對「必須正確」的定義、指標、runbook 就危險。

坑三：embedding 與資料同步是惡夢

知識會更新。每次更新，對應的 embedding 就要重算、重新入庫，還要確保檢索到的不是舊版。當資料變動頻繁，維持 embedding 與真實資料一致，會變成一項需要持續照看的營運工作；出了問題也很難除錯，因為你看不到它「為什麼」取到那一塊。

坑四：沒有明確關係，多跳就斷

向量檢索是「找相似」，不是「走關係」。當問題需要多跳——先找到 A、再從 A 找到相關的 B、再確認 C——純語意相似很容易在中間斷掉。它沒有一張明確的關係圖可以走。

這些失敗模式指向同一件事

這四個坑都出現在同一種情況：知識本身是結構化、精選，而且關係明確。這類內容不適合被切碎成向量再靠相似度猜；它更適合放在能保留結構、把關係寫成明確連結，還能像 code 一樣版本控制的格式。這正是 OKF 想處理的那一層。

另一方面，當知識量很大、缺乏結構，查詢又常常只是換個說法時，向量檢索仍然是合適的工具。那時候你要的就是「找相似」的能力。關鍵是把工具放在它適合的地方。