別在 AI 交付中迷信「全量微調」：為什麼「RAG + 動態上下文」才是快速迭代的生存之道

在 AI Lab 的實際交付過程中，很多團隊在面對模型知識缺失或領域專業度不足時，最本能的反應是：「我們需要微調 (Fine-tuning) 一個自己的模型。」

這種想法在學術界很流行，但在工程交付中，這往往是通往「交付地獄」的快車道。

微調的「幻覺」與現實

很多專案經理認為微調能讓模型「學會」新知識。但事實是：微調的主要作用是改變模型的語氣、格式和行為模式，而不是高效地注入海量事實性知識。

如果你試圖透過微調讓模型記住 100 份最新的產品手冊，你會發現：
1. 知識更新成本極高：手冊一旦改了一個版本，你得重新訓練或增量訓練。
2. 災難性遺忘：為了讓它記住產品 A，它可能忘了怎麼寫一個正確的 Python 迴圈。
3. 幻覺依然存在：模型可能會自信地把微調資料中的兩個不同版本混淆在一起。

工程化的替代方案：RAG + 動態上下文

在實際的工程實踐中，我們採用的是 RAG (Retrieval-Augmented Generation) + 動態上下文管理 的組合拳。其核心邏輯是將「知識」與「推理能力」解耦。

1. 將知識外掛化 (Externalize Knowledge)

不要試圖把知識塞進權重 $\theta$，而要把知識放在向量資料庫（如 Milvus 或 Pinecone）中。
- 原子化切片：將文件切分為 300-500 token 的語義區塊，並保留元數據（頁碼、章節）。
- 多路召回：結合 BM25（關鍵字）和 Embedding（語意），確保檢索的查全率。

2. 建構動態上下文視窗 (Dynamic Context Window)

現在的模型（如 Qwen, GPT-4o）支援極長的上下文視窗。與其微調，不如在 Prompt 中建構一個臨時的「知識庫」。
- 重排序 (Reranking)：檢索出 Top-20 個片段後，使用 Reranker 模型篩選出最相關的 Top-5。
- 結構化注入：使用 <context> 標籤明確告知模型：「以下是參考資料，請僅基於此內容回答」。

對比分析：微調 vs RAG

維度	全量/指令微調 (SFT)	RAG + 動態上下文
更新頻率	低（需重新訓練）	高（秒級更新索引）
可解釋性	黑盒（無法溯源）	白盒（可直接給出引用連結）
部署成本	高（需獨立權重儲存/載入）	低（共用基礎模型）
準確度	易產生事實性幻覺	基於原文，幻覺顯著降低

實戰教訓：什麼時候才需要微調？

雖然我們推崇 RAG，但並不是完全拋棄微調。在以下場景中，微調是不可替代的：
- 極致的格式控制：當你需要模型輸出極其複雜的 JSON 或特定 DSL，且 Prompt 無法穩定約束時。
- 特定風格遷移：例如讓 AI 模仿某個特定人物的說話語氣或寫作風格。
- 降低 Token 開銷：當你的 System Prompt 長達數千 token 時，可以透過微調將這些指令內化到權重中。

總結

AI 工程化的本質是尋找成本最低、魯棒性最高、可維護性最強的路徑。

對於絕大多數企業級交付專案，「RAG $\rightarrow$ Rerank $\rightarrow$ Long Context」的鏈路遠比 「資料清洗 $\rightarrow$ 微調 $\rightarrow$ 測試 $\rightarrow$ 重練」的迴圈要高效得多。不要在追求「擁有自己的模型」這種虛榮心上浪費時間，要把精力花在如何建構高品質的資料索引和檢索策略上。