剛開始用 Dify 的人，最常做的一件事是把手上所有文件都丟進知識庫。
直覺上這很合理：資料越多，AI 知道得越多。實際上到某個規模之後，回答品質會開始下降，而且原因不容易看出來。
30 秒總覽
| 問題 | 答案 |
|---|---|
| 資料多了會更準嗎 | 通常相反 |
| 為什麼 | 撈回的段落數固定，競爭者變多 |
| 最有效的解法 | 按主題拆成多個知識庫 |
| Top-K 該調大嗎 | 不該，三到五段通常最好 |
| 先撐不住的是 | 建立索引的時間，不是查詢 |
為什麼資料變多反而變差
RAG 的運作方式是：使用者問問題 → 系統在知識庫裡找出最相關的幾段 → 把這幾段連同問題一起送給模型 → 模型根據這些段落回答。
關鍵在「最相關的幾段」是有數量上限的。
知識庫從 50 段變成 5,000 段，系統一樣只撈回三到五段。差別是：現在有更多長得很像但其實不相干的段落在跟正確答案競爭。
結果就是那個很多人遇到但講不出原因的現象——「以前問得到的問題，現在答錯了。」
分塊大小的取捨
文件會被切成小段（chunk）再建立索引。這個大小直接決定檢索品質。
| 切太小 | 切太大 | |
|---|---|---|
| 檢索精準度 | 高 | 低（一段裡混了多個主題） |
| 上下文完整度 | 低（答案被切斷） | 高 |
| 典型症狀 | 回答斷頭、缺前後文 | 回答離題、抓到不相干內容 |
沒有一體適用的數字，但有個判斷原則：一段應該剛好包含一個完整的概念。
FAQ 型的內容適合切小（一問一答就是一段），操作手冊適合切大一點（一個完整步驟不該被拆開）。這也是為什麼不同性質的文件最好分開建知識庫，而不是全部混在一起。
Top-K 不是越大越好
Top-K 決定每次檢索撈回幾段。很多人把它調大，想說「多給一點資料總不會錯」。
會錯。撈回十幾段的問題有三個：慢、貴（送給模型的 token 變多）、而且模型會被不相干的內容帶偏。
多數情境三到五段就夠。如果三段撈不到正確答案，問題出在分塊或文件品質，調大 Top-K 只是把雜訊一起帶進來。
知識庫該怎麼長大
比起「塞更多」，這幾個做法有效得多：
- 按主題拆成多個知識庫。產品文件、退換貨政策、技術規格各自獨立，讓應用依情境選用。這是改善檢索品質最有效的一步。
- 定期清掉過期內容。舊版的產品說明留在庫裡，它會跟新版競爭，而且模型分不出哪個是新的。
- 來源檔先整理過。把 200 頁的手冊拆成幾個主題檔案，比整本丟進去好很多。
- 用真實問題測。拿客戶實際問過的十個問題定期測一輪，這比看任何指標都準。
資源會在哪裡先撐不住
知識庫變大，最先有感的是建立索引的時間——每次新增文件都要重新解析與產生向量，大檔案在這一步吃記憶體。
日常查詢的成本增加得比較緩慢，但同時使用的人多的時候會放大。方案的 2 vCPU／10 GB 對純文字知識庫相當充裕，真正逼近上限的通常是放了大量掃描 PDF 的情況。
不過在加資源之前，值得先確認你遇到的是資源問題還是設計問題——這兩者的症狀不一樣。
拆知識庫的三種切法
| 切法 | 什麼時候用 |
|---|---|
| 按主題 | 最常見——產品／政策／技術規格 |
| 按對象 | 有些內容不該讓客戶看到 |
| 按時效 | 現行版與歷史版分開 |
第三種最容易被忽略，但影響很大：舊版產品說明留在同一個庫裡，它會跟新版競爭，而模型分不出哪個是現行的。
拆完之後，應用可以依情境選用不同的知識庫，或用工作流先分類再決定查哪一個。做法在 工作流編排教學。
知識庫長大的三個階段
| 階段 | 症狀 | 該做的 |
|---|---|---|
| 剛開始 | 回答準，偶爾找不到 | 補文件就好 |
| 中期 | 開始答錯，而且錯得很有自信 | 拆知識庫、清過期內容 |
| 後期 | 上傳變慢、索引時間長 | 看資源，或減少來源檔大小 |
最危險的是中期。「以前問得到的問題，現在答錯了」——因為現在有更多長得很像但不相干的段落在跟正確答案競爭。
這個階段最容易做出的錯誤反應是「再補更多文件」，那會讓情況更糟。
怎麼知道該拆了
三個具體訊號：
- 同一個問題，答案時好時壞——檢索撈到的段落不穩定
- 回答引用了明顯不同主題的段落——例如問退貨政策卻引用了產品規格
- 你自己都說不清楚知識庫裡有什麼——那模型更不可能分得清
拆分方式在下面那段。拆知識庫是唯一一個「做了幾乎一定會變好」的調整，比調任何參數都有效。
常見問題
Q：知識庫有筆數上限嗎？
空間上，純文字的需求很小。但放得下不代表該放——品質瓶頸會遠早於容量瓶頸出現。
Q：拆成幾個比較好？
按主題拆，不是按數量拆。產品文件、退換貨政策、技術規格各自獨立是常見的分法。判斷標準是「這兩類內容會不會互相干擾」。
Q：舊版本的文件要刪掉嗎？
要。舊版產品說明留在庫裡會跟新版競爭，而模型分不出哪個是現行的。過期內容該移出去，不是留著當參考。
Q：怎麼測有沒有變好？
準備十個真實問過的問題，每次調整後跑一遍。沒有固定的測試題，「感覺變好了」通常是錯覺。
Q：文件更新了要重傳嗎？
要，知識庫不會自動同步。價格與政策這類會變的內容尤其危險——機器人會很有自信地回答舊版資訊。
定期該做的一件事
知識庫不是設定完就結束的東西，它需要維護。最低限度是每季用固定的十個問題測一輪。
那十題要是真實問過的問題，而且要固定不換——換題目就沒有基準了。測完記錄哪幾題答錯、錯在檢索還是生成。
連續兩季答對率下降，通常代表兩件事之一：文件累積太多該拆了，或有過期內容還留在庫裡跟新版競爭。
資料來源與延伸連結
Dify 的功能與介面會隨版本調整，實際操作前建議對照官方文件：
- Dify 官方文件
- Dify 版本更新紀錄——功能異動以此為準
- Dify 原始碼與 Issue 追蹤
延伸閱讀
- Dify 託管的資源邊界：什麼情況下 2 vCPU 會不夠
- Dify 的技術強項：RAG 知識庫、工作流編排與為什麼它比較吃資源
- Dify 教學：打造你的第一個 AI 聊天機器人
- Dify 常見問題：API Key、知識庫調校與資源配置
- RoamerHost Dify 託管方案
想找人幫你做？
這些流程要是不想自己搭，或是規模大到需要有人一起規劃，浪花科技（RoamerHost 的母公司）承接企業流程自動化與 AI Agent 的委託開發：
Dify
