企業知識庫與 AI Agent
RAG 與微調怎麼選？資料更新、成本與風險比較
RAG 與微調不是互相排斥的兩個產品。RAG 在回答時取得外部資料，微調則用訓練資料調整模型在特定任務上的行為。若問題是「模型不知道本週更新的公司規定」，通常先考慮 RAG；若問題是「輸出格式與任務表現不穩定」，才評估提示、工具或微調。
用需求判斷
適合先用 RAG
- 知識會頻繁更新，例如產品規格、內規與客服文件。
- 回答需要附來源，讓人員可以核對。
- 不同使用者只能看到不同文件。
- 希望修正知識時更新文件與索引，而非重新訓練。
可能需要微調
- 任務目標穩定，而且有足夠、合法、品質一致的輸入輸出範例。
- 要改善固定分類、風格、格式或領域任務表現。
- 提示與少量範例已不足以達到可驗收品質。
- 團隊能管理訓練資料版本、評估集、模型版本與回退。
Microsoft 的官方比較將 RAG 描述為在回答前以語意搜尋加入資訊，微調則以較小的特定資料集重新訓練模型。兩者也可以組合：用微調改善行為，再用 RAG 提供最新知識。
常見錯誤
不要用微調背誦會變動的價格、政策或庫存。資料一變就要重新處理訓練與驗證，也不容易要求模型逐句提供來源。
也不要把 RAG 當成免整理資料。過期文件、互相矛盾的版本與錯誤權限進入索引後，檢索只會更快找到錯的內容。RAG 的品質很大一部分取決於文件治理與測試題。
成本應怎麼算
RAG 成本包含文件整理、擷取、切塊、embedding、索引、查詢、生成、監控與重新索引。微調成本包含資料標註、清理、訓練、評估、模型託管與版本重訓。不要只比較單次 API 價格，要比較一年內更新與維護責任。
建議決策順序
- 先定義任務、可接受錯誤與真實測試集。
- 以提示加少量範例建立基準。
- 需要最新或私有知識時加入 RAG。
- 確定問題仍是穩定行為而非檢索後，再做小範圍微調實驗。
- 用相同測試集比較品質、延遲、成本與風險。
無論選哪一種方式，都應遵循 NIST AI RMF 的 Govern、Map、Measure、Manage 思路，記錄用途、風險、測量與處置，而不是只看示範答案。
可先閱讀RAG 入門，再用RAG 驗收清單建立基準；若要規劃企業導入，可查看企業 AI 服務。