微调质量清单：部署前的 10 项测试

模型训练完了，指标看着不错，客户演示也很顺利。这时团队里有人抛出了一个把专业代理机构和业余爱好者分开的问题：「我们真的可以把这套东西交付出去了吗？」

多数代理机构答不上来。他们靠的是直觉，「测试的时候感觉挺好」，手上却没有一套成体系的流程。这份清单要补的就是这个缺口：十项具体测试，每一项都有明确的通过与未通过标准，在每一次向客户部署之前跑一遍。

把它打印出来，放进你的项目模板。不要因为工期紧就跳过其中的步骤。跑完这份清单要花 2 到 3 小时，而一次糟糕的部署之后，紧急排障加上安抚客户往往要吃掉 20 到 30 小时。

测试 1：黄金测试集上的准确率

检查内容： 把黄金测试集（50 到 100 个已知正确输出、且从未用于训练的样本）跑过微调后的模型，算出准确率。

检查方法： 准备一个 JSONL 文件，里面装着一对一对的输入和输出，然后把每一条输入都送进模型。分类任务看输出是否完全匹配；生成任务则请一位领域专家把每一条输出评为「正确」「部分正确」或「错误」。

通过标准：

• 分类任务：准确率 92% 以上
• 生成任务：85% 以上评为正确，评为错误的低于 5%
• 任何单一错误类别占测试用例总数的比例都不超过 3%

未通过时的处理： 准确率低于阈值，就去找出错误模式。通常的修法是针对失败情形补 50 到 100 条有针对性的训练样本，然后重新训练。别抱着「先上线，应该会没事」的心态发布。

测试 2：幻觉率

检查内容： 模型多久会生成一次听上去合情合理、实际上与事实不符的信息？在法律、医疗和金融场景里，这一项尤其关键。

检查方法： 挑出 30 条测试输入，它们的正确答案都要涉及具体的事实：人名、日期、数字、引注、产品细节。把它们跑过模型之后，拿你的源材料去逐条核对每一份输出里的每一个事实性陈述。

通过标准：

• 高风险领域（法律、医疗、金融）零幻觉事实
• 一般商业场景幻觉率低于 3%
• 手上没有信息时，模型应当表达不确定，而不是编造

未通过时的处理： 出现幻觉，通常说明训练数据量太小，或者模型过拟合到了模式上，而没有真正学到事实。具体的缓解手段见我们的微调模型幻觉问题指南。也可以考虑加一层 RAG 来做事实锚定。

测试 3：格式合规

检查内容： 模型能否稳定产出客户应用所要求的那种格式？内容再完美，格式错了，下游的每一个集成都会崩。

检查方法： 跑 50 条测试输入，用程序把每一份输出都对照你的格式规范校验一遍。输出应该是 JSON，就把它解析一遍；应该按模板分成若干指定小节，就逐节检查每一节是否都在；应该控制在字数上限以内，就把字数数出来。

通过标准：

• 格式合规率 98% 以上
• 没有任何一条输出会导致下游解析报错
• 格式边界情况（空字段、特殊字符、Unicode）的处理保持一致

未通过时的处理： 格式问题是最好修的。补 20 到 30 条格式正确的样本重新训练即可。如果模型的 JSON 输出时好时坏，再在系统提示里写明格式要求，做个双保险。

测试 4：延迟基准

检查内容： 模型的响应时间能否满足客户场景的要求？每次响应要 8 秒的模型，用在批处理上没问题，放进实时聊天界面就无法接受。

检查方法： 跑 100 条测试输入，对每一条都测量首 token 时间和总生成时间，再算出 p50（中位数）、p90（90 分位）和 p99（99 分位）三档延迟。

通过标准：

• p50 延迟满足客户的要求（聊天场景通常在 1 秒以内，文档处理在 5 秒以内）
• p99 延迟不超过 p50 的 3 倍（说明性能稳定）
• 没有请求超时或卡死

未通过时的处理： 延迟主要取决于模型大小和硬件。模型太慢，可以考虑换更小的基座模型、提高量化程度，或者升级部署硬件。从 Q8 换成 Q4 量化通常能把延迟降低 30% 到 40%，质量损失很小。

测试 5：边缘情况处理

检查内容： 输入超出预期范围时，模型会怎么表现？空输入、超长输入、语种不对的输入、自相矛盾的指令、提示注入攻击。

检查方法： 按下面这几类准备 20 到 30 条边缘输入：

• 5 条空输入或近乎为空的输入
• 5 条长度是常规输入 5 到 10 倍的输入
• 5 条范围外请求（要求模型做它没有被训练过的事）
• 5 条对抗性输入（提示注入、越狱尝试）
• 5 条客户领域特有的边界情形

通过标准：

• 零灾难性失败（冒犯性内容、数据泄露、系统提示外泄）
• 至少 80% 的边缘情况能优雅降级（礼貌拒绝，或给出合理的尽力回答）
• 没有死循环、空输出或乱码

未通过时的处理： 把没通过的边缘情况连同正确处理的示例一起加进训练数据，重新训练。要提升对抗鲁棒性，再补 10 到 20 条模型正确拒绝提示注入的样本。

测试 6：偏见与公平性检查

检查内容： 模型对不同人群、地区或业务细分的对待是否公平？微调模型的偏见往往来自训练数据分布不均。

检查方法： 构造 20 组测试输入对，每一组里的两条输入之间，唯一的区别只有一个人口统计变量（姓名、地点、性别、年龄）。把两个版本都跑过模型，再比较输出在语气、质量和给出的建议上有没有实质性的差异。

通过标准：

• 不同人群之间的输出质量没有统计显著差异
• 不因人口统计信息产生刻板印象或预设
• 无论输入暗示的人群属性如何，语气和帮助程度保持一致

未通过时的处理： 审查训练数据的人群分布。如果 90% 的训练样本都来自同一个人群，模型在其他人群上的表现就会变差。把数据集调平，重新训练。

测试 7：安全防护

检查内容： 模型会拒绝生成有害、违法或不当的内容吗？微调有可能削弱基座模型的安全训练，训练数据里包含试探边界的样本时尤其如此。

检查方法： 跑 15 到 20 条这几类测试输入：

• 有害指令（暴力、自伤、违法活动）
• 生成私密信息（伪造的社保号、信用卡号）
• 违反客户品牌规范的内容
• 本应附带免责声明的医疗或法律建议

通过标准：

• 对真正有害的请求，拒绝率 100%
• 专业建议（法律、医疗、金融）附有恰当的免责声明
• 即便被人用巧妙的方式诱导，也不生成私密数据格式的内容
• 输出符合客户的品牌语气和内容政策

未通过时的处理： 安全防护被削弱的话，你多半需要在训练数据里补上明确的拒绝样本，其中包含 20 到 30 条模型正确回绝有害请求的例子。品牌一致性方面，补充一批能体现正确语气和边界处理方式的样本。

测试 8：与基线的 A/B 对比

检查内容： 微调模型真的比替代方案更好吗？基线可能是配了一段好系统提示的基座模型、用提示词驱动的 GPT-4，或者客户现在正在用的方案。

检查方法： 把同样的 50 条测试输入分别跑过微调模型和基线。再把成对的输出交给一位盲评人，他并不知道哪一份输出来自哪一个模型，由他为每一对挑出更好的那一份，或者把这一对标为持平。

通过标准：

• 微调模型在两两对比中至少赢下 60%
• 微调模型不存在任何一个持续输给基线的类别
• 在客户真正在意的那个任务上，质量提升是看得出来的

未通过时的处理： 微调模型没有明显赢过基线，就说明这次微调的效果还不足以支撑部署。回头检查训练数据的质量和数量。有时候诚实的答案是：在这个场景里，用前沿模型做提示工程就已经够用了。

测试 9：单次推理成本

检查内容： 这个模型的运行成本，能否同时装进客户的预算和你的利润要求？每次请求 0.50 美元的模型，和每次 0.005 美元的模型，是完全不同的两笔生意。

检查方法： 按你的部署方式算出单次推理成本：

• 自托管：（每小时 GPU 成本）/（目标延迟下的每小时请求数）
• 云端部署：（每小时实例成本）/（实测吞吐量）
• 把所有成本都算进去：算力、存储、网络传输、监控

通过标准：

• 单次推理成本低于客户给出的预算
• 代理机构的利润率至少 40%（如果你是按推理次数向客户收费）
• 在预计规模下（当前量的 3 倍、10 倍）成本依然可行

未通过时的处理： 优化部署方式：换更低的量化等级、做请求批处理、换更小的模型版本，或者调整部署硬件。如果成本从根子上就撑不起这个场景，那就在部署之前把话跟客户说开，别等第一张账单出来才说。

测试 10：客户验收标准

检查内容： 模型是否满足客户在项目启动时定下的那些具体标准？这是最重要的一项测试，因为它衡量的正是客户真正在意的东西。

检查方法： 翻出工作说明书或项目启动会上确定下来的验收标准。针对其中的每一条，准备 10 到 20 个能直接验证它的测试用例，把测试跑完，并把结果记录下来。

常见的客户验收标准：

• 「必须正确归类我们 95% 的工单」
• 「生成的回复必须符合我们的品牌语气」
• 「处理一份文档必须在 3 秒以内」
• 「必须能处理西班牙语输入」
• 「不得把一个部门的信息透露给另一个部门」

通过标准： 客户定义的验收标准全部满足。某条标准表述含糊时，把你的理解写下来，在部署前拿到客户签字确认。

未通过时的处理： 某条验收标准没过，就把它排在所有其他问题之前优先修。内部十项测试过了九项、却卡在客户首要标准上的模型，还不能交付。

清单在实际工作中的执行

时间预估： 十项测试认真跑一遍要 2 到 4 小时。第一次会更久，因为要搭测试集、写评估脚本。之后每一次都更快，测试资产可以复用和扩充。

由谁来做： 理想情况下，跑清单的人和训练模型的人分开。新鲜的眼睛能挑出更多问题。团队人手少的话，至少让另一个人复核边缘情况和安全这两项测试。

什么时候跑：

• 每一次向客户部署之前（没有商量余地）
• 每一轮重新训练之后
• 生产模型每月跑一次，哪怕什么都没改（用来捕捉漂移）
• 客户报告问题之后立即执行

记录留档： 每一次跑清单都把结果记下来：日期、模型版本、测试集版本、每一项测试的通过与否，以及所有临界项的备注。这会积累成一份审计轨迹，对赢得客户信任和做自己的质量追踪都有价值。

最重要的那一条规则

测试没通过，就不要发布。对于处理真实客户数据的生产模型，没有「下个版本再修」这种说法。一次失败部署的代价，包括客户信任受损、紧急排障、潜在的法律责任，永远高于为修问题而把上线推迟几天。

以可靠著称的代理机构能收更高的价钱，客户留得更久，也更容易拿到转介绍。这份清单就是把这种口碑系统化地做出来的办法。

---

延伸阅读

• 如何评估你的微调模型：本清单中提到的每一种评估方法的详细指南
• Ertas Studio 与代理机构自建微调的对比：为你的代理机构工作流挑选合适的工具