一个 SaaS 客服平台有个高频任务：把用户提交的自由文本工单，转成结构化字段——类别（12 个枚举值）、严重程度（4 档）、受影响产品，外加一段 60 字以内的摘要。它跑在前沿模型 API 上，日均 200 万次调用，是工单自动分派的第一道关口。
两个压力同时到来：这个任务的 API 成本已占该产品线基础设施预算的大头；P95 延迟 2.3 秒，拖慢了分派时效。有人提议：自己训一个小模型接手。这一节要回答的是——该不该训？
本故事线贯穿 5.1–5.4，为综合多个真实项目的匿名化叙事；全部数字均为便于推演设定的示例假设，计算过程写出，重点是决策链条而非具体数值。
「效果不够好，微调一下吧」是这个领域里最昂贵的条件反射。微调的成本不只是几张 GPU 卡和几天时间——它带来的是一份需要长期维护的资产：数据管线、训练脚本、模型版本管理、评估集、回归测试、以及基座模型升级时的重新训练。
所以正确的顺序是沿着一条升级路径逐级尝试，每一级都要先证明「上一级确实不够」：
这是整个决策中最有判别力的一问，它能直接排除掉大部分错误选项：
| 你想解决的问题 | 正确工具 | 为什么不是微调 |
|---|---|---|
| 模型不知道某些事实 （公司政策、产品文档、今天的数据） | RAG / 工具调用 | 事实会变，微调跟不上；且微调注入事实既易遗忘又难溯源（3.1） |
| 输出格式不稳定 （JSON 结构、字段缺失） | constrained decoding 约束解码 | 解码层能保证结构合法；微调只能提高概率。用概率手段解决确定性问题是本末倒置 |
| 模型不会用某个工具 | 改工具 schema | 多半是 schema 描述不清，不是模型不会（4.1） |
| 需要特定的风格 / 领域推理方式 | fine-tune ✓ | 这类隐性行为难以在 prompt 中完整描述，正是微调的适用面 |
| 需要小模型达到大模型在窄任务上的表现 | fine-tune ✓（蒸馏） | 成本/延迟驱动，这是本 Part 故事线的场景 |
一句话记忆：微调改变的是「模型怎么做事」，不是「模型知道什么」。把这条记牢，能挡掉至少一半的错误微调项目。
即使确认了要改的是行为，也还需要四个条件都成立，微调才是理性选择：
① 任务窄且稳定。任务定义在未来一年内不会大改。如果需求还在频繁变动，微调出来的模型会不断作废——你会陷入「训完就过时」的循环。
② 调用量足够大。微调是一次性投入换取长期的单位成本下降。日均一千次调用的任务，省下的钱永远追不上投入的工程时间。量是摊薄成本的唯一途径。
③ 质量可自动评估。没有可自动运行的 eval，你无法判断训练是否成功、也无法在基座升级后验证新版本。没有 eval 的微调项目基本等于在盲飞——这一条比大多数人以为的更硬。
④ 有数据，或者有办法造数据。下一节故事线会讲到，这通常是四个条件里最容易低估、也最容易卡住项目的一个（5.3）。
第一步：先把不用训就能拿到的收益榨干。团队在提出微调之前，先做了三件成本低得多的事：
① 精简 prompt——few-shot 示例从 8 条减到 3 条（实测准确率无明显下降），输入从 900 token 降到约 520 token；② 开启 prompt caching——system prompt + few-shot 共约 400 token 是稳定前缀，命中率很高（2.2）；③ 模型分级——把最简单的「严重程度」判定拆出来走更便宜的模型档位（2.3）。
这三步合计已经把成本压掉了相当一部分，而且都是天级的工作量。这一步不能跳过——它既是纪律，也让你在后面真的动手微调时，能拿到一个诚实的基线：微调要超越的不是「优化前的成本」，而是「已经优化过的成本」。
第二步：核对四个条件。
四条全部满足，而且第③、④条尤其漂亮：结构化输出任务天然可自动评估，已有的生产日志天然就是蒸馏数据——这两点让这个任务比大多数微调候选项更适合动手。
第三步：排除更便宜的替代方案。要改的是「事实」还是「行为」？——都不是。这里要改的是「用更小的模型做同样的事」，是成本与延迟驱动的distillation（蒸馏）。RAG 不适用（任务不依赖外部知识），约束解码已经在用（保证 JSON 合法），换更小的现成模型试过——未微调的 8B 模型类别准确率只有 76%，远低于 94% 的基线。到这一步，微调才第一次成为唯一剩下的选项。
第四步：盈亏平衡测算（示例假设，方法比数字重要）：
第五步：把风险写下来。决定要做之后，团队明确记录了三条退出条件——① 若学生模型在长尾类别上的准确率无法达到基线的 95%，则放弃；② 若数据准备超过 3 周仍未达标，则重新评估；③ 上线后保留 API 回退通道至少两个季度（6.5）。提前写好放弃条件，是防止沉没成本绑架决策的唯一办法——微调项目尤其容易「已经投入这么多了，再试一轮」。
约束解码 / 结构化输出：主流商业 API 提供 structured outputs / JSON schema 模式；自托管可用 Outlines、XGrammar、以及 vLLM / SGLang 内置的语法约束能力。凡是「格式不稳定」的问题，先用这个解决，不要用微调。
Prompt 优化：DSPy 等框架可自动搜索 prompt 与 few-shot 示例组合。在动手标数据之前值得一试——它有时能把「看起来必须微调」的差距补上。
托管微调服务：多家厂商提供上传数据即可微调的服务，省掉全部基础设施。适合验证「微调到底能带来多少提升」这个问题，作为可行性验证的快速路径很划算；但要注意模型无法自托管、无法迁移，长期成本结构与自托管不同。
先做一次「上限探测」：在投入完整数据管线之前，用几百条高质量样本快速跑一次微调，看提升幅度。如果几百条样本带来的提升接近于零，那么几万条大概率也救不了——问题可能出在任务定义或基座选择上。这一步通常只要一两天，能避免几周的浪费。
A 退款政策 → RAG。这是事实问题：会变、需溯源、可能需权限区分。微调注入事实既跟不上更新，又给不出出处（3.1）。
补充：若政策只有几条且极少变，写进 system prompt 比 RAG 更简单——别跳过第①级。
B JSON 格式 → constrained decoding。格式合法性应该在解码层强制保证，而不是靠训练提高概率。用微调解决格式问题是典型的用昂贵手段解决已有确定性方案的问题。
C 法务审阅风格 → fine-tune ✓。这是行为问题：怎么组织论证、关注哪些风险点、用什么措辞——这类隐性风格无法在 prompt 里完整描述，也无法从检索材料中现学。
但仍要先试 few-shot：如果 5 个精选的审阅样例就能带出风格，就不必微调。
D 术语理解错误 → 先诊断，再决定。这是本题最需要思考的一项，因为它可能是三种不同的问题：
• 若模型不知道这些术语的定义 → 事实问题 → RAG 或在 prompt 里给术语表；
• 若模型知道通用含义但贵司有特殊定义 → 先试在 system prompt 里明确定义，通常就够了；
• 若模型需要内化整套领域的推理方式（术语只是表征） → 才是微调。
「术语理解错误」是一个症状而不是病因，直接跳到微调是常见的误诊。
方向性错误：用微调注入事实。五个必然会遇到的问题：
① 更新代价不成比例。改一条规格就要重新训练加验证——按天计。而写进索引是按秒计。产品规格是会变的，这个循环无法维持。
② 无法溯源。模型说「型号 X 支持功能 Y」，没有任何依据可核对。对产品规格这类需要准确性的信息，不可溯源本身就是不可用。
③ 事实注入本就是微调的弱项。少量样本上的事实记忆既容易被遗忘，又容易过拟合——模型可能记住了训练时的表述方式而非事实本身，换个问法就答错。
④ 幻觉不减反增。微调让模型对这个领域更「自信」，但它并没有真正掌握全部 500 条，结果是在没记住的部分编得更像真的——比不微调时更危险。
⑤ 灾难性遗忘。在窄数据上训练会损伤通用能力（5.3），得不偿失。
正确方案：500 条产品规格放进检索索引（量小的话甚至可以直接放进 system prompt 配合 prompt caching）。如果同时还希望模型用特定风格回答规格问题，那才是可以叠加的微调需求——但那时训练的目标是风格，不是规格内容。
好的回答分三层，且要先讲不该微调的情况——这体现判断力：
第一层：先排除。要改的是事实 → RAG 或工具调用；要改的是格式 → 约束解码；工具用不好 → 改 schema。微调改变的是模型「怎么做事」，不是它「知道什么」。
第二层：两类真正适用的场景。① 行为塑造——特定风格、领域推理方式，这类隐性能力难以在 prompt 中完整描述；② 蒸馏——用小模型在窄任务上达到大模型的表现，由成本或延迟驱动。
第三层：四个必要条件。任务窄且稳定、调用量足以摊薄成本、质量可自动评估、有数据或造数据的办法。四者缺一，微调都会变成一个持续消耗人力却不产出价值的项目。
加分：主动提到微调的真实代价不是训练费用，而是它把迭代循环从分钟级变成了周级，以及基座模型升级后需要重训的长期负担。以及强调「先把 prompt 优化、缓存、路由这些便宜手段榨干，再来谈微调」——微调要超越的基线是已经优化过的系统，而不是最初那个版本。