Dify 知識庫變大之後：檢索品質與資源的取捨
很多人以為知識庫塞越多資料，AI 回答越準。實際上多數情況剛好相反。這篇講知識庫長大之後會發生什麼，以及分塊、Top-K 該怎麼調。
🚀 想直接開始?60 秒部署你的 Dify
AI 應用開發平台 — No-Code 建構你的 AI。月付 NT$1,599 起,
剛開始用 Dify 的人，最常做的一件事是把手上所有文件都丟進知識庫。
直覺上這很合理：資料越多，AI 知道得越多。實際上到某個規模之後，回答品質會開始下降，而且原因不容易看出來。
為什麼資料變多反而變差
RAG 的運作方式是：使用者問問題 → 系統在知識庫裡找出最相關的幾段 → 把這幾段連同問題一起送給模型 → 模型根據這些段落回答。
關鍵在「最相關的幾段」是有數量上限的。
知識庫從 50 段變成 5,000 段，系統一樣只撈回三到五段。差別是：現在有更多長得很像但其實不相干的段落在跟正確答案競爭。
結果就是那個很多人遇到但講不出原因的現象——「以前問得到的問題，現在答錯了。」
分塊大小的取捨
文件會被切成小段（chunk）再建立索引。這個大小直接決定檢索品質。
| 切太小 | 切太大 | |
|---|---|---|
| 檢索精準度 | 高 | 低（一段裡混了多個主題） |
| 上下文完整度 | 低（答案被切斷） | 高 |
| 典型症狀 | 回答斷頭、缺前後文 | 回答離題、抓到不相干內容 |
沒有一體適用的數字，但有個判斷原則：一段應該剛好包含一個完整的概念。
FAQ 型的內容適合切小（一問一答就是一段），操作手冊適合切大一點（一個完整步驟不該被拆開）。這也是為什麼不同性質的文件最好分開建知識庫，而不是全部混在一起。
Top-K 不是越大越好
Top-K 決定每次檢索撈回幾段。很多人把它調大，想說「多給一點資料總不會錯」。
會錯。撈回十幾段的問題有三個：慢、貴（送給模型的 token 變多）、而且模型會被不相干的內容帶偏。
多數情境三到五段就夠。如果三段撈不到正確答案，問題出在分塊或文件品質，調大 Top-K 只是把雜訊一起帶進來。
知識庫該怎麼長大
比起「塞更多」，這幾個做法有效得多：
- 按主題拆成多個知識庫。產品文件、退換貨政策、技術規格各自獨立，讓應用依情境選用。這是改善檢索品質最有效的一步。
- 定期清掉過期內容。舊版的產品說明留在庫裡，它會跟新版競爭，而且模型分不出哪個是新的。
- 來源檔先整理過。把 200 頁的手冊拆成幾個主題檔案，比整本丟進去好很多。
- 用真實問題測。拿客戶實際問過的十個問題定期測一輪，這比看任何指標都準。
資源會在哪裡先撐不住
知識庫變大，最先有感的是建立索引的時間——每次新增文件都要重新解析與產生向量，大檔案在這一步吃記憶體。
日常查詢的成本增加得比較緩慢，但同時使用的人多的時候會放大。方案的 2 vCPU／10 GB 對純文字知識庫相當充裕，真正逼近上限的通常是放了大量掃描 PDF 的情況。
不過在加資源之前，值得先確認你遇到的是資源問題還是設計問題——這兩者的症狀不一樣。
