定義自訂模型的範圍
當還不確定問題是否真的需要自訂訓練模型時，從這裡開始。大多數情況下，人們在提出要求時已經認定要進行微調、離線執行或削減開支，但卻沒有說出背後真正的限制條件。這個技能的目的就是先放慢一步：先找出真正的限制，排除較便宜的解決方案，然後才定義訓練必須達成的目標。
先找出限制條件
人們很少直接說出限制條件。他們通常會直接提出解決方案：「我想微調一個模型」、「我想離線執行這個」、「我想要自己的模型」。每一種說法都只是五種真正限制條件的代理。在繼續之前，先釐清它到底是哪一種，因為這個技能的其餘部分，以及接下來要使用其他八個技能中的哪一個，都取決於這個答案。
| 對方說什麼 | 通常代表什麼 |
|---|---|
| 「成本太高」 | 成本 |
| 「太慢了」或「往返時間影響很大」 | 延遲 |
| 「資料不能外洩」 | 隱私 |
| 「必須在無網路連線下運作」 | 離線運作 |
| 「它一直出錯」或「它不一致」 | 行為一致性 |
如果以上都不符合，就直接詢問。單純一句「我想要自己的模型」而沒有背後具體的限制條件，通常只是熱情而非需求，為熱情而訓練出來的模型，最終也沒有人真正需要它。
在同意訓練之前，先嘗試這四件事
訓練是改變模型行為最慢、最昂貴的方式。先排除更便宜的選項。完整細節、每種方案的大致成本，以及它不再足夠的確切訊號，都記錄在 references/alternatives-to-training.md 中。簡短版本如下：
- 更好的提示。 當模型已經知道答案，只是表達、格式化或應用時不一致時就足夠。當一個經過深思熟慮的提示在大量真實輸入中仍然出錯時則不足。
- 檢索。 當問題在於缺少或過時的知識，而非行為時就足夠。當正確的事實已經在上下文之中，但模型仍然忽略或誤用它們時則不足。
- 較小的託管模型。 當任務比目前模型設計的範圍更狹窄，且使用相同提示的較小託管模型能以更低成本或延遲達到相同品質標準時就足夠。當沒有任何託管模型（無論大小）能達到該標準時則不足。
- 模型之間的路由。 當工作負載是簡單與困難請求的混合，且便宜的模型已經能正確處理簡單的部分時就足夠。當困難的部分才是真正驅動成本、延遲或品質抱怨的原因時則不足。
請依此順序進行。每一種都比訓練更便宜嘗試、更容易排除。
當訓練是錯誤的答案時
這是本技能中最重要的段落。訓練自訂模型並非一個稍微貴一點的預設好主意。它經常是錯誤的答案，在這裡明確指出這一點，可以省去後續大量的浪費。若符合以下任何一種情況，請勿訓練：
- 任務是知識檢索，而非行為。 如果模型在獲得正確的事實後行為正確，那麼差距在於檢索，而非權重。訓練無法教會模型在訓練完成後會改變的事實，而且每次資料變更都重新訓練，比檢索慢得多且昂貴得多。
- 可用的範例少於幾百個。 模型無法從寥寥幾個範例中可靠地學習新行為。低於這個門檻時，要麼先投資產生更多標記資料，要麼使用不需要大量資料的方法：更好的提示、少量範例集或檢索。
- 品質標準是前沿級別的開放式推理。 真正的開放式推理、新穎的解決問題能力或廣泛的通用知識，並非訓練能為較小的開放模型所帶來的。訓練會將模型限制在特定的任務和格式上。它不會將小型模型變成能進行開放式推理的前沿模型。
如果其中一項為真，就直接說清楚，並轉向真正合適的替代方案，而不是讓對話漂流到「應該微調哪個基礎模型」。
當訓練是正確的時，定義目標
如果以上都不排除訓練，且四個替代方案都無法達到品質標準，那麼訓練就是合理的下一步。在觸碰基礎模型或資料集之前，先寫下以下五件事：
| 定義 | 說明 |
|---|---|
| 任務 | 一句話：模型實際上要做什麼，針對哪種輸入 |
| 品質標準 | 一個具體、可檢查的通過條件，而非「好」或「比前沿模型好」 |
| 延遲預算 | 一個數字，以及它必須在哪個運行環境達到該數字 |
| 部署目標 | 裝置端、本地、邊緣或託管GPU雲端，由限制條件實際存在的位置決定 |
| 如何衡量成功 | 在訓練之後、任何人宣布完成之前，用來判斷的評估方式 |
跳過這個步驟是訓練專案產生出一個沒人能確切判斷是否比先前模型更好的模型的最常見原因。關於如何建立這種評估，請參閱 evaluating-a-tuned-model。
一旦決定訓練，references/training-options.md 提供了誠實的選項清單，說明應該在哪裡實際執行：你自己的GPU到幾個託管平台，每個都有真實的選擇標準。請根據該參考資料而非憑記憶推薦，並直接說出所陳述的標準指向哪一行，而不是讀完整個表格。它直接回答了「哪個最容易使用」的問題。
其他八個技能
這是通往套件中其餘技能的入口。
| 技能 | 階段 | 何時前往此處 |
|---|---|---|
inspecting-a-model-bundle | 檢查 | 模型檔案或目錄已存在，但不清楚裡面有什麼 |
debugging-a-bad-fine-tune | 除錯 | 訓練過的模型重複輸出、永不停止或忽略其訓練資料 |
evaluating-a-tuned-model | 評估 | 需要知道微調是否真的勝過基線 |
costing-a-model-vs-an-api | 成本分析 | 需要計算擁有模型勝過使用API的使用量門檻 |
shipping-a-model-in-a-react-native-app | 部署 | 部署到 React Native 或 Expo |
shipping-a-model-in-an-ios-app | 部署 | 部署到 Swift、MLX 或 Core ML |
shipping-a-model-in-an-android-app | 部署 | 部署到 Kotlin、MediaPipe 或 LiteRT |
shipping-a-model-in-a-flutter-app | 部署 | 部署到 Flutter |
撰寫決策文件
在使用者的專案根目錄中撰寫 MODEL-DECISION.md，以便決策理由能超越本次對話而留存。請嚴格按照以下順序使用這些章節：
# 模型決策
## 限制條件
<成本 | 延遲 | 隱私 | 離線運作 | 行為一致性，一行說明原因>
## 考慮過的選項
<每個替代方案一行：提示、檢索、較小的託管模型、路由，並說明為何足夠或不足>
## 決策
<訓練，或不訓練。如果訓練：上述定義的目標>
## 我們如何知道它有效
<決定此事的評估方式，或指向 evaluating-a-tuned-model>
如果決策是「不訓練」，這個檔案仍然值得撰寫。它是為什麼做出這個決定的記錄，並且可以避免同一個問題在三週後沒有記憶的情況下被重新爭論。
交接事項
- 決策是「不訓練」：在此停止，或回到真正適用的替代方案
- 決策是「訓練」，且已有模型檔案可供使用：inspecting-a-model-bundle
- 決策是「訓練」，且是時候執行了：從
references/training-options.md中選擇一個平台 - 訓練已完成且需要評估：evaluating-a-tuned-model