行動應用的微調 vs 提示工程

提示工程是每個開發者最先使用的工具。撰寫一個系統提示詞告訴模型如何行為、輸出什麼、避免什麼。對於原型開發來說效果出奇地好。

微調是第二個工具，在提示工程碰到瓶頸時使用。在你想要的確切行為範例上訓練模型。前期工作量更大，但以更低的成本提供更好的結果。

對於行動應用，這個選擇有超越準確性的影響。提示工程需要在每次 API 呼叫時發送長系統提示詞（成本）。微調將指令嵌入到模型權重中（推論時免費）。

提示工程：快速路徑

工作原理

你撰寫一個指導模型的系統提示詞：

You are a cooking assistant for the RecipeApp. When users ask about
recipes, provide step-by-step instructions. Always include prep time
and cooking time. Format ingredients as a bulleted list. Keep
responses under 200 words. Never suggest recipes that include
allergens without a warning. If the user asks about non-cooking
topics, politely redirect to cooking.

這個提示詞在每次 API 呼叫時都會發送。模型在大多數時候遵循（大部分的）這些指令。

優勢

• 速度： 幾分鐘即可撰寫和測試
• 靈活性： 透過編輯文字就能改變行為
• 不需要訓練資料： 零範例即可運作
• 不需要基礎設施： 只是 API 呼叫
• 迭代速度： 幾秒鐘內嘗試新的提示詞

劣勢

• Token 成本： 你的 800-1,500 token 系統提示詞在每次請求時都會計費。在 10K 月活躍用戶、每天 90K 次請求的情況下，每月額外產生 7,200-13,500 萬個 tokens。
• 不一致性： 模型以機率方式遵循指令。70-85% 的遵循率是典型的。邊界情況會溜過。
• 有限的領域知識： 模型只知道提示詞中的內容。你無法將整個產品目錄放入系統提示詞中。
• 提示詞注入漏洞： 使用者有時可以覆蓋系統提示詞指令。
• 準確度天花板： 再多的提示工程也無法教會通用模型你的特定領域術語、風格或邊界情況。

微調：精確路徑

工作原理

你建立你想要的確切輸入-輸出行為的範例：

{"messages": [
  {"role": "user", "content": "Quick pasta recipe for one person"},
  {"role": "assistant", "content": "**One-Pot Garlic Pasta**\n\nPrep: 5 min | Cook: 12 min\n\n- 100g spaghetti\n- 2 cloves garlic, minced\n- 2 tbsp olive oil\n- Red pepper flakes\n- Parmesan\n\n1. Boil pasta in salted water\n2. Saute garlic in olive oil (2 min)\n3. Toss drained pasta with garlic oil\n4. Top with pepper flakes and parmesan"}
]}

在 500-5,000 個這樣的範例上訓練模型。模型學會你的格式、風格、領域知識和邊界情況處理方式。

優勢

• 準確度： 領域任務上 90-96%，對比提示工程的 70-85%
• 不需要系統提示詞： 指令在權重中。每次請求零額外 tokens。
• 領域知識： 模型了解你的產品、術語和風格
• 一致性： 回應可靠地遵循訓練過的格式
• 裝置端部署： 微調模型在本地運行。無 API 成本、無延遲、無網路依賴。
• 提示詞注入抵抗力： 行為在權重中，而非可覆蓋的文字指令

劣勢

• 前期時間： 訓練資料準備需要數小時到數天
• 訓練成本： 每次微調運行 $5-50（一次性）
• 較不靈活： 改變行為需要重新訓練
• 資料需求： 最少 200-500 個高品質範例

正面比較

領域任務的準確度

微調在領域特定指標上持續優於提示工程。差距在格式遵循和領域術語上最大，微調鎖定了你需要的確切模式。

每月成本（10K 月活躍用戶，每天 90K 次請求）

微調有一次性成本（每次訓練運行 $5-50）。部署後，每次推論成本為零。每月成本僅為新使用者模型下載的 CDN 頻寬。

延遲

各自的優勝場景

提示工程優勝的時機：

• 你正在原型開發，還不確定使用者是否需要這個功能
• 任務是通用的（非領域特定）
• 你沒有訓練資料
• 行為需要每週變更
• 使用者數量非常少（500 月活躍用戶以下）

微調優勝的時機：

• 你已驗證功能並正在擴展
• 任務是領域特定的（你的產品、你的術語、你的格式）
• 準確度很重要（分類、擷取、合規敏感內容）
• 你有 500+ 個期望行為的範例（或可以建立它們）
• 成本、延遲、離線支援或隱私很重要

遷移路徑

這兩種方法不是互斥的。它們是循序的：

1. 從提示工程開始。 快速建構功能。驗證使用者興趣。使用雲端 API 發布。

2. 收集訓練資料。 帶有你提示詞的每次 API 呼叫都會產生一個輸入-輸出對。你的提示工程 API 日誌成為你的微調資料集。

3. 訊號明確時進行微調。 當你知道使用者想要這個功能、當你的提示詞穩定、當成本或延遲很重要時，在你收集的資料上微調一個小型模型。

4. 部署到裝置端。 匯出 GGUF，發送給使用者。系統提示詞消失。準確度提升。成本降至零。

像 Ertas 這樣的平台讓微調步驟變得容易上手：上傳你的訓練資料（可以直接來自你的 API 日誌）、選擇基礎模型、使用 LoRA 訓練、匯出 GGUF。微調基礎設施為你處理。

提示詞到微調的流程

你的 API 日誌是一座金礦。每條日誌記錄包含：

• 使用者輸入（訓練輸入）
• 系統提示詞（隱含編碼在期望輸出中）
• 模型輸出（訓練輸出，經過品質篩選後）

篩選高品質的輸出（模型正確遵循你指令的部分），格式化為訓練範例，你就有了微調資料集。你的提示工程越好，你的微調資料就越好。

這就是為什麼這兩種方法相輔相成。好的提示詞創造好的訓練資料。好的訓練資料創造不再需要提示詞的模型。

Ship AI that runs on your users' devices.

Free plan with 30 credits/mo, no card required. Paid plans from $25/mo USD.

Start freeor view pricing →