何時不應微調：RAG、提示工程或 API 更好的 5 種情況

Ertas 是一個微調平台。我們建立它是因為微調解決了提示工程和 RAG 無法解決的真實問題。但我們也看過團隊花數週微調模型用於更簡單的方法本可以更好地解決的任務。那是浪費的時間和金錢，並侵蝕了對微調作為技術的信任。

我們寧願你用正確的方法成功，也不願你用微調失敗。因此以下是五種你不應微調的情況——以及該怎麼做。

情況一：你的知識庫頻繁變化

情境： 你正在為電商公司構建客戶支援機器人。產品目錄、定價、退貨政策和配送資訊每週都在變化。你希望模型給出準確、最新的答案。

為何微調在這裡是錯誤的： 微調在訓練時將知識烘焙到模型中。當你在當前產品目錄上訓練時，模型學習到「UltraWidget Pro」售價 299 美元，配送需要 3 至 5 個工作日。下週，價格降至 249 美元，配送改為 2 至 3 天。你微調的模型仍然顯示 299 美元和 3 至 5 天。

要讓模型保持最新，每次發生任何變化時都需要重新訓練。在每週更新周期下，這意味著每週重新訓練——每個周期都要花費計算時間，需要資料準備，並有在其他行為上發生回歸的風險。經濟上行不通。

替代方案：RAG。 檢索增強生成在查詢時從你的知識庫中檢索相關文件。當價格變化時，你更新向量資料庫中的文件。模型在每次請求時看到當前資訊，無需任何重新訓練。

幾分鐘內更新你的向量索引。幾小時內重新訓練模型。對於快速變化的資訊，選擇是顯而易見的。

例外： 如果你需要模型在使用 RAG 獲取知識的同時具有特定的溝通風格或遵循特定的回應模式，你可以結合兩者。微調用於行為，RAG 用於事實。這通常是最佳架構——但當知識是多變的時候，單獨微調不是答案。

情況二：你需要模型引用來源

情境： 你正在為咨詢公司構建研究助手。分析師提問並需要有特定報告、研究或內部文件支持的答案。每個主張都必須可追溯到來源。

為何微調在這裡是錯誤的： 微調的模型將資訊吸收到其權重中。它可以告訴你它「知道」什麼，但無法告訴你它在哪裡學到的。沒有任何機制讓微調的模型指向支持其輸出的特定文件、頁碼或段落。

你可以嘗試在訓練資料中包含來源參考（訓練模型輸出帶有引用的主張），但這很脆弱。模型學會生成看起來合理的引用，而非實際的引用。它會以與真實引用相同的信心偽造文件標題和頁碼。

替代方案：帶有檢索元資料的 RAG。 RAG 系統從已識別文件中檢索特定的文字片段。每個片段攜帶元資料——文件標題、頁碼、章節、日期。模型根據檢索的片段生成回應，你可以在答案旁邊顯示來源元資料。

這給你真正的可追溯性。引用是真實的，因為它們來自檢索系統，而非模型的生成。對於合規密集的行業——法律、金融、醫療、咨詢——這不是可選的。

細微差別： 微調可以改善模型使用檢索上下文的方式。微調的模型可能更善於從多個檢索文件中合成資訊並產生連貫的回應。但引用能力本身必須來自檢索架構，而非微調。

情況三：你只需要偶爾的一次性任務

情境： 你的機構構建自訂 AI 解決方案。你有一個客戶需要將 5,000 個產品描述從一種格式一次性轉換為另一種格式。這是一個將運行一次就完成的批次任務。

為何微調在這裡是錯誤的： 微調有固定的前期成本：資料準備（2 至 8 小時工作）、訓練計算（5 至 50 美元）和評估時間（1 至 2 小時）。對於你只運行一次的任務，這個投資通常超過直接使用 API 的成本。

以每次請求 0.01 至 0.03 美元，通過前沿 API 處理 5,000 個項目花費 50 至 150 美元。微調模型、部署它並處理同樣的 5,000 個項目，總成本大致相同——但需要顯著更多的日曆時間。如果你不打算再次使用，微調的模型沒有殘餘價值。

替代方案：使用 API 加精心設計的提示。 對於一次性批次任務，API 方法設置更快，更易於迭代，成本大致相同。寫一個好的系統提示，在 50 個範例上測試，調整，然後處理完整批次。

閾值： 當你預計每天持續處理超過 50 個請求時，微調開始在經濟上有意義。低於這個量，每次請求的成本節省無法抵消訓練的固定成本。如果一致性對業務至關重要，計算會改變（見情況五的例外），但對於大多數一次性任務，API 是正確的工具。

情況四：你的任務需要廣泛的世界知識

情境： 你希望一個模型能夠為教育平台回答關於歷史、科學、時事和文化的一般性問題。它需要處理從小學水準到研究生水準的數十個科目的問題。

為何微調在這裡是錯誤的： 微調使模型變窄。它通過將模型的權重專門化為你的訓練分佈，使模型在你的特定任務上更好。這種專業化是有代價的——模型在訓練分佈之外的事情上變得不那麼能幹。

如果你在歷史問題上微調 7B 模型，它在歷史方面變得更好，但在科學方面可能略微變差。如果你在兩者上都微調，你需要一個龐大而多樣的訓練資料集以避免降低任何單一領域的性能。到那時，你實際上是在重做模型的預訓練，這是不實際的。

廣泛的世界知識是大型前沿模型建立的目的。一個在數萬億個 token 上訓練的 4,000 億以上參數模型有能力跨領域持有廣泛的知識。一個在 5,000 個範例上微調的 7B 模型在廣度上無法競爭。

替代方案：通過 API 使用大型前沿模型。 GPT-4o、Claude 3.5 Sonnet 或 Gemini 1.5 Pro 已經具備你的任務所需的廣泛知識。直接使用它們，並配以適當的提示。

成本問題： 前沿 API 在規模上很昂貴。如果你達到 API 成本變得難以承受的量，考慮混合方法：使用 RAG 從你的知識庫檢索相關知識，並將其提供給較小的模型。這給你廣泛的知識庫覆蓋和小型模型的成本效率——沒有微調的狹窄化效應。

情況五：你還沒有嘗試好的提示工程

情境： 你有一個任務。你寫了一個基本提示。輸出不夠好。你得出結論，你需要微調。

為何微調在這裡是錯誤的： 這是我們看到的最常見的錯誤。團隊在寫了 200 字的系統提示並在 10 個範例上測試後就跳到微調。他們還沒有嘗試：

• 提示中的少量範例。 在系統提示中添加 3 至 5 個高品質的輸入輸出範例可以顯著提高輸出品質。這需要 30 分鐘，而非 30 小時。
• 思維鏈提示。 對於推理任務，要求模型在產生最終答案之前「逐步思考」，在許多基準上提高了 10 至 30% 的準確率。
• 結構化輸出指令。 明確指定輸出格式，包括字段名稱和類型，通常無需微調就能解決格式問題。
• 迭代提示改進。 在 50 個以上多樣化範例上測試，識別失敗模式，並通過針對性的提示修改解決它們。大多數團隊在 3 至 4 次迭代後放棄，而 10 至 15 次迭代本可以解決問題。
• 模型選擇。 有時問題不是提示，而是模型。嘗試不同的基礎模型（或更大的模型）可能立即解決問題。

好的提示工程比微調更快且更便宜地迭代。提示更改需要幾秒鐘測試。微調更改需要幾小時。在投資訓練之前，始終耗盡提示優化。

當提示工程真正耗盡時： 你有一個超過 1,500 個 token 的系統提示，包含 5 個以上的少量範例。你在 100 個以上的輸入上測試過。你對提示迭代了 15 次以上。準確率已達到平台期。模型在相同運行中不一致。此時，你有強有力的證據表明任務超出了提示所能交付的——你的提示成為生成微調資料的起點。請閱讀我們的遷移手冊以了解確切流程。

決策流程圖

當你評估是否微調時，按順序回答這些問題：

1. 你是否徹底優化了你的提示？ 如果沒有，先做這個。成本：幾小時。潛在收益：完全解決問題。

2. 你的任務需要頻繁更新的知識嗎？ 如果是，使用 RAG。微調烘焙了過時的知識。

3. 你需要來源引用嗎？ 如果是，你需要一個檢索組件。單獨微調無法提供真正的引用。

4. 這是一次性或低量任務嗎？ 如果每天低於 50 個請求且沒有持續需求，使用 API。微調的固定成本無法自圓其說。

5. 任務是否需要跨多個領域的廣泛知識？ 如果是，使用大型前沿模型。微調縮窄了能力。

6. 你的任務是否狹窄、高量且需要一致的行為？ 如果三者都是，微調。這是微調的優勢所在。

如果你到達問題 6，微調可能是正確的選擇。任務足夠狹窄可以很好地訓練，量足夠高可以合理化投資，並且需要只有學習的行為（而非提示的行為）才能提供的一致性。

何時組合方法

上面五種情況描述了單獨微調是錯誤答案的時候。但微調與其他方法結合通常是最好的答案：

RAG 加微調的模型。 使用 RAG 進行知識檢索，使用微調的模型進行回應生成。模型通過微調學習你的特定回應風格、格式和語調。它從檢索系統獲得當前的、可引用的知識。這是大多數機構應該為生產系統評估的架構。

帶有 RAG 的微調 Llama 8B 模型在領域特定任務上通常優於帶有 RAG 的前沿模型——因為微調的模型更好地理解如何使用檢索的上下文用於你的特定領域。

微調加提示工程。 即使微調的模型也受益於系統提示。帶有提供會話特定上下文（用戶偏好、當前日期、任務變體）的短（200 個 token）系統提示的微調模型，優於同一模型沒有提示的情況。微調處理行為基礎；提示處理每請求的客製化。

微調加 API 後備。 對於 90% 狹窄和 10% 廣泛的任務，為 90% 微調，並將剩餘 10% 路由到前沿 API。使用分類器（本身可以是小型微調模型）來確定每個請求應走哪條路徑。這給你常見情況的微調成本效率和邊緣情況的前沿模型能力。

誠實的評估

微調是一種強大的技術。它為狹窄任務產生更快、更便宜、更一致的模型。它實現了將資料保持在第三方伺服器外的隱私保護部署。它為機構創造了真正的技術護城河。

但它並非總是正確的工具。在 AI 方面成功的團隊是那些將技術與問題匹配的人——而非那些對每個問題應用他們最喜歡的技術的人。

如果你的情況符合上面五種情況之一，節省自己的時間並使用更簡單的方法。如果你已經通過所有五個問題，你的任務確實需要微調，我們構建 Ertas 是為了讓這個過程盡可能直接。

---

延伸閱讀：

• 微調 vs RAG：何時使用各自（以及何時結合） — 兩種方法的詳細技術比較
• 提示工程有天花板。之後是什麼。 — 識別你何時真正耗盡了提示優化
• 為客戶選擇微調 vs RAG：如何建議正確的方法 — 關於向客戶推薦方法的機構導向指南