微調 vs 提示工程：選擇正確的方法

為何這個選擇很重要

你有一個大型語言模型（LLM）和一項任務：也許是分類客戶電子郵件、生成產品描述，或回答支援問題。你可以精心設計一個提示，或是在你的資料上微調模型。兩者都旨在提升效能，但在成本、速度和彈性上有所不同。選錯方法可能會浪費數週的努力或讓你的預算爆表。本文將拆解這些權衡，並提供一個實用的框架來幫助你決定。

什麼是提示工程？

提示工程是指設計輸入文字來引導模型的輸出。你可以使用指令、範例或思維鏈推理。模型的權重保持凍結。你不斷迭代提示，直到結果夠好為止。

• 優點：無需訓練、可立即迭代、適用於任何模型 API、前期成本低。
• 缺點：受上下文視窗限制、可能需要大量範例（few-shot），增加 token 成本、效能會遇到瓶頸。

提示工程通常是第一個該嘗試的方法。它快速且便宜，適合原型開發。

什麼是微調？

微調是在你的資料集上更新模型的權重。你提供大量的輸入-輸出配對，模型會學習你領域特定的模式。這可以透過 API（例如 OpenAI 微調）或在本地使用開源模型來完成。

• 優點：在利基任務上可達到更高準確度、縮短提示長度（節省 token）、可能改善延遲。
• 缺點：需要標註資料、訓練需要花費金錢和時間、資料變更時需要重新訓練、有過擬合風險。

當你有數千個範例且任務穩定時，微調能發揮最大效益。

關鍵差異一覽

何時使用提示工程

如果符合以下任一情況，就從提示工程開始：

1. 你正在進行原型開發。你需要快速驗證想法，而不需投入資料收集。
2. 你的任務很常見。摘要、翻譯和簡單問答通常用好的提示就能運作良好。
3. 你的資料有限。標註範例少於幾百個。
4. 你的需求經常變動。提示變更是即時的；微調則需要重新訓練。
5. 你使用多個模型。在一個模型上有效的提示，通常稍作調整就能用在其他模型上。

即使你最終會進行微調，提示工程也能幫助你理解任務和基準效能。

何時該考慮微調

在以下情況，微調會變得有吸引力：

1. 你擁有大量且高品質的資料集。至少幾百個範例，理想情況下有數千個。
2. 提示工程遇到瓶頸。你已經嘗試各種提示和 few-shot 範例，但準確度停滯不前。
3. 你需要降低 token 成本。包含大量範例的長提示在規模化時很昂貴；微調後的模型可以使用較短的提示。
4. 你的任務需要專業知識。領域特定的術語、格式或推理，難以在提示中明確指定。
5. 你需要一致的輸出格式。微調比單純的指令更能強制執行結構。

但要注意：微調並非萬靈丹。如果你的資料有雜訊或任務模糊不清，模型會學到那些雜訊。

混合方法：RAG 與 Few-Shot

你不必只選擇一種。檢索增強生成（RAG）結合檢索器和 LLM：你取得相關文件並將其納入提示中。這非常適合事實經常變動的知識密集型任務。Few-shot 提示（在提示中包含範例）是針對有明確模式之任務的輕量級微調替代方案。

考慮這些折衷方案：

• RAG：適用於動態知識，無需訓練。
• Few-shot 提示：適用於少量範例就足夠的任務。
• 微調 + RAG：微調以掌握風格和格式，使用 RAG 來處理事實。

實用的決策框架

遵循以下步驟來做選擇：

1. 定義成功指標。準確度、延遲、每次請求成本。
2. 先嘗試提示工程。花一兩天迭代提示，包括 few-shot 範例。
3. 評估。如果指標符合你的需求，就停止。如果不符合，繼續下一步。
4. 評估資料。你有足夠的高品質標註資料嗎？如果沒有，考慮資料收集或 RAG。
5. 估算成本。比較長提示的 token 成本與微調的訓練和推論成本。
6. 試行微調。如果可能，從小型模型開始，衡量改善幅度。
7. 監控並迭代。微調後的模型需要隨著資料漂移定期重新訓練。

程式碼範例：使用 OpenAI API 進行微調

以下是準備資料並啟動微調工作的最小範例（概念性，沒有 API 金鑰無法執行）：

import openai

# Prepare dataset in JSONL format
# Each line: {"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}

openai.api_key = "your-api-key"

# Upload file
file = openai.File.create(
    file=open("training_data.jsonl", "rb"),
    purpose="fine-tune"
)

# Create fine-tune job
job = openai.FineTuningJob.create(
    training_file=file.id,
    model="gpt-3.5-turbo"
)

print(job.id)

這說明了工作流程：資料準備、上傳和建立工作。實際實作會因供應商而異。

成本與效能考量

微調有前期成本（訓練）和持續成本（在自訂模型上進行推論，每 token 的費用可能高於基礎模型）。提示工程的前期成本較低，但如果提示很長，每次請求的成本會較高。在規模化時，如果微調能大幅縮短提示，可能會更便宜。然而，如果你的任務經常變動，重新訓練的額外負擔可能會超過節省的成本。

在效能方面，微調在狹窄任務上可能優於提示，但在一般任務上可能會退化（災難性遺忘）。提示則保留了模型的一般能力。

常見問題

我可以在沒有大型資料集的情況下進行微調嗎？

可以，但結果可能不佳。微調通常需要至少幾百個範例才能看到有意義的改善。如果範例更少，提示工程或 few-shot learning 會更有效。

微調在生產環境中總是更好嗎？

不是。許多生產系統僅依賴提示工程，特別是當任務屬於一般性質或資料經常變動時。微調最適合資料充足且穩定的專業化任務。

我怎麼知道我的提示夠好了？

定義明確的指標（例如準確度、F1、人工評估），並在保留集上測試。如果提示達到你的目標，你就不需要微調。如果它停滯在目標之下，考慮微調或 RAG。

結論

提示工程和微調是互補的，而非互斥的。從提示開始，充分發揮其潛力，然後評估微調是否值得投資。對許多應用來說，精心設計的提示結合 RAG 或 few-shot 範例，就能提供出色的結果，而無需承擔訓練的額外負擔。當你確實進行微調時，確保你的資料乾淨且指標明確。

需要格式化 JSONL 訓練資料嗎？試試我們的 JSON Formatter，在上傳前驗證並美化你的資料集。