范围界定自定义模型
当尚不清楚问题的答案是否是自定义训练模型时，请从此处开始。大多数情况下，用户已经确信自己想要微调、离线运行或削减成本，却没有说出该请求背后的实际约束。此技能的存在是为了减慢这一步骤：先明确约束，排除更便宜的修复方案，然后才定义训练需要实现的目标。
首先要明确约束
人们很少直接说出约束。他们通常提出一个解决方案：“我想微调一个模型”、“我想离线运行这个”、“我想要自己的模型”。这些每个都是五种实际约束之一的代理。在进一步推进之前，先弄清楚实际是哪种约束，因为此技能其余部分以及接下来使用哪八个技能，都取决于答案。
| 用户说的 | 通常意味着什么 |
|---|---|
| “成本太高” | 成本 |
| “太慢了”或“往返耗时太长” | 延迟 |
| “数据不能离开本地” | 隐私 |
| “必须在无连接的情况下工作” | 离线运行 |
| “它总是出错”或“结果不一致” | 行为一致性 |
如果这些都不符合，直接询问。一个没有底层约束的“我想要自己的模型”通常只是热情而非需求，基于热情进行训练会产出没人真正需要的模型。
在同意训练之前要尝试的四件事
训练是改变模型行为最慢、最昂贵的方式。先排除更便宜的选项。完整细节、每个选项的大致成本以及它不再足够的信号，请参见 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 | 成本分析 | 需要计算拥有模型 vs 使用 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