從提示工程到微調：遷移手冊

您有一個花了幾週時間才完善的系統提示。它有 2,000 個 token 長，塞滿了示例、邊緣案例說明和格式規則。它能用——大部分時候。但它很脆弱、昂貴，且以持續耗費您時間的方式不一致。

這是將該提示遷移到微調模型的手冊。不是理論，不是推銷話術。而是代理商和產品公司的團隊用來將成本降低 60–80%，同時提高輸出一致性的逐步流程。

您已達到提示工程上限的跡象

在投資微調之前，請確保您確實處於上限，而不只是在寫糟糕的提示。以下是具體指標：

您的提示超過 2,000 個 token。 這麼長的系統提示意味著您通過大量指令來編碼行為。每個 token 在推理時都要花錢，隨著提示長度增加，模型對您指令的注意力會降低。如果您每個請求僅在系統提示上花費 $0.01–0.03，那是一個結構性問題。

小的提示變更會破壞不相關的輸出。 您修復了模型對邊緣案例 A 的處理，突然它對任務 B 的格式退化了。這是您的提示是紙牌屋的跡象——模型在整體上解釋指令，一個部分的變更以不可預測的方式與其他部分交互。

相同運行的輸出各不相同。 您發送相同的輸入，使用相同的提示，溫度設置為 0，仍然有 15–25% 的時間得到明顯不同的輸出。模型處於其輸出空間中，注意力的微小數值差異會產生不同的路徑。更多提示無法修復這個問題——模型需要更強的行為信號。

您在用自然語言編碼複雜的條件邏輯。 「如果輸入包含日期，則將其格式化為 ISO 8601，除非它是相對日期，如『下週二』，在這種情況下根據當前日期轉換為絕對日期，但如果輸入還包含時區...」這種邏輯屬於代碼或學習行為，而不是系統提示。

您已達到精確度平台。 兩週的提示迭代使您從 75% 精確度提升到 82%。又兩週使您達到 84%。您現在花費整天時間試圖擠出一個百分點。模型沒有足夠的信號繼續前進。

遷移決策框架

並非每個提示都應該成為微調模型。以下是投資回報計算：

任務的月度 API 成本。 如果您通過 API 在單一任務上每月花費超過 $200（包括長系統提示帶來的膨脹 token 成本），微調可能在 2–4 週內收回成本。在單個 GPU 上運行的微調 8B 模型每月計算成本約為 $50–150，在沒有系統提示的情況下處理相同任務，且通常產生更好的結果。

量很重要。 微調有固定的前期成本——準備資料和訓練的時間。在每天 100 個請求的情況下，這個投資在幾週內就能攤銷。在每天 5 個請求的情況下，可能需要幾個月。低於每天大約 50 個請求時，除非一致性對業務至關重要，否則繼續使用提示工程。

任務窄度很重要。 微調最適合窄且定義明確的任務。「將客戶電子郵件分類為 12 個類別」是理想的候選。「成為可以做任何事的通用助手」則不是。如果您的提示涵蓋具有清晰輸入和輸出的單一任務，您處於微調領域。

遷移流程：五個步驟

步驟 1：記錄您當前的提示和預期行為

在更改任何東西之前，凍結您的當前系統。記錄：

• 確切的系統提示（在 git 中版本化）
• 50–100 個代表性輸入及其實際輸出
• 您認為哪些輸出是正確的、部分正確的和錯誤的
• 您試圖修復的具體故障模式

這成為您的評估基準。您將把微調模型與此基準進行比較，您需要關於當前系統實際表現的真實資料。大多數團隊在測量之前高估了他們提示的性能。

步驟 2：從您的提示中提取訓練資料

您系統提示中的每個示例都是等待提取的訓練示例。一個包含 5 個少量示例的 2,000 個 token 提示已經包含了您的前 5 個訓練對。但真正的洞察是您的提示還包含隱式訓練資料：

• 每個指令（「列表始終使用項目符號」）暗示著幾十個輸出使用項目符號的輸入-輸出對
• 每個邊緣案例規則暗示著練習該規則的訓練示例
• 每個格式要求暗示著展示正確格式的示例

逐行檢查您的提示。對於每條指令，創建 10–20 個演示指令被正確遵循的輸入-輸出對。如果您的提示有 15 條不同的指令，僅從解碼提示就給您 150–300 個訓練示例。

步驟 3：再生成 1,000–2,000 個額外示例

從提示提取的示例是個開始，但您需要量。以下是實用方法：

1. 採用您目前正在使用的現有提示 + API 組合
2. 在多樣化輸入中生成 3,000–5,000 個輸出
3. 積極篩選——只保留符合您品質標準的輸出
4. 目標是 1,000–2,000 個高品質訓練對

這一步通常需要幾個小時的 API 調用，費用約 $20–50，具體取決於任務。關鍵是篩選。不要在訓練資料中包含平庸的輸出。如果當前系統 80% 的時間產生正確輸出，就篩選到那 80% 並丟棄其餘的。

專業提示： 包含涵蓋已知故障模式的輸入。如果基於提示的系統 30% 的時間在日期格式化上失敗，生成許多日期格式化示例，並手動更正 API 出錯的輸出。這就是微調模型最清楚地超越提示的地方。

步驟 4：微調較小的模型

有了訓練資料，實際微調很簡單：

• 基礎模型： Llama 3.1 8B 或 Qwen 2.5 7B 是大多數任務的強大起點。它們足夠小可以在單個 GPU 上訓練，且對窄任務足夠強大。
• 方法： 大多數任務使用 rank 16–32 的 LoRA。完整微調很少必要，且增加了過擬合風險。
• 訓練： 在您的資料集上進行 2–4 個 epoch。更多的 epoch 有過擬合風險，尤其是對於較小的資料集。
• 驗證： 保留 10–15% 的資料用於驗證。監控損失曲線以防過擬合。

在 Ertas Studio 上，整個過程需要 30–90 分鐘，具體取決於資料集大小和 GPU 可用性。您上傳資料，選擇基礎模型，配置 LoRA 參數並訓練。沒有基礎設施設置，沒有 CUDA 驅動調試。

步驟 5：嚴格比較品質

針對微調模型運行步驟 1 中的評估基準。比較：

• 精確度： 微調模型是否匹配或超越了基於提示的系統？在大多數情況下，它會超越 5–15 個百分點，因為它見過的示例是提示中所能容納的 100 倍。
• 一致性： 每個測試輸入運行 5 次。微調模型應產生幾乎相同的輸出。提示常常有所不同；微調行為更穩定。
• 延遲： 沒有 2,000 個 token 的系統提示，微調模型處理請求更快。在較小模型上預計延遲降低 30–50%。
• 成本： 計算每個請求的成本。自托管 8B 模型通常比對前沿模型的 API 調用（帶有長提示）便宜 1/10 到 1/50。

如果微調模型在特定領域表現不佳，針對這些領域添加更多訓練示例並重新訓練。微調是迭代的，就像提示工程一樣——但迭代是累積的而不是相互抵消的。

常見遷移錯誤

嘗試微調通用模型而不是窄模型。 如果您的提示執行五個不同的任務，不要為所有五個微調單一模型。訓練五個獨立的 LoRA 適配器。每個適配器保持小巧，訓練快速，並擅長其特定任務。在 Ertas 上，您可以在推理時無開銷地切換適配器。

在切換生產流量之前沒有進行充分測試。 讓微調模型以影子模式運行至少一週——處理真實輸入並將輸出與當前系統進行比較，而不向用戶提供結果。在您的用戶發現之前捕獲故障。

跳過資料品質步驟。 500 個高品質訓練示例優於 5,000 個平庸示例。花時間在篩選和更正上。如果訓練資料中的示例有格式錯誤，模型將學習該錯誤。

使用過高的 LoRA rank。 Rank 64 或 128 聽起來比 rank 16 更好，但對於窄任務，它通常只是過擬合。從低開始，評估，只有在欠擬合是問題時才提高 rank。

成本比較：前後對比

以下是代理商遷移合同條款提取任務的真實場景：

微調模型訓練花費 $40 的計算費用，不到兩天就收回了成本。

Ertas 如何使這成為一個下午的項目

上面的遷移手冊有五個步驟。在 Ertas Studio 上，基礎設施阻力降至接近零：

1. 上傳您的訓練資料（JSONL 格式）——Ertas 驗證格式並標記品質問題
2. 從模型中心選擇基礎模型——Llama、Qwen、Mistral 等預先加載
3. 配置和訓練——LoRA rank、學習率和 epoch 的合理默認值，如果您需要完全控制
4. 評估——內建對您的測試集的評估，包含精確度、一致性和延遲指標
5. 部署——一鍵部署到 Ertas Deploy，或導出適配器用於自托管

從「我有一個要替換的提示」到「我有一個已部署的微調模型」的整個過程，對典型任務需要 2–4 小時。模型訓練本身是 30–90 分鐘。其餘是資料準備，無論您使用什麼工具都是一樣的。

困難的部分從來不是基礎設施。而是知道何時進行切換以及如何準備資料。這正是這本手冊的用途。

---

相關閱讀：

• 提示工程有其上限。以下是超越之後的道路。 — 更深入探討為什麼提示停止改進
• 如何微調 LLM：完整指南 — 微調過程的技術細節
• 無代碼微調 AI — 使用 Ertas Studio 的無代碼介面進行遷移