用小评测集做 AI 功能验收：可复现的模型与提示词对比
发布于 2026-10-01
用小评测集做 AI 功能验收：可复现的模型与提示词对比
AI 功能的迭代有个绕不开的问题：改了提示词、换了模型，效果到底是变好还是变差？靠"我试了几个感觉不错"下结论，迟早翻车。
一套最小可用的评测集并不复杂：一批固定输入 + 一键跑批 + 可对比的结果。
一、样本从哪来
最好的来源是线上真实请求：把用户实际问过的、以及出过问题的案例抽出来，脱敏后入集。经验上：
2030 条覆盖主流场景的样本，就能发现大多数回归；
每个曾经修过的 Bug，都应该变成一条固定样本（回归用例）；
边界样本（空输入、超长输入、夹杂格式化的输入）单独留几条。
样本量不是关键，覆盖度与稳定性才是。
二、怎么打分
按验收难度从低到高：
1. 规则校验：格式、枚举值、JSON 可解析、字段是否齐全——程序判分，零主观；
2. 关键信息比对：答案里是否包含必需要素（用规则或关键词）；
3. 模型裁判：让另一个模型按评分标准打分——成本低但有偏好，务必固定裁判提示词与版本，并且人工抽查一部分校准。
能规则化的就规则化。模型裁判是兜底手段，不是默认选项。
三、对比流程的三个纪律
一次只改一个变量：要么换模型，要么改提示词，别同时动；
记录版本：模型名、提示词版本、参数（温度等）都要落进结果文件，否则结果无法复现；
看全貌：只报平均分会掩盖回归——必须看"哪些样本变差了"。
四、别忽略成本与延迟
评测结果至少要包含三维：质量、耗时、token 消耗。真实场景里，"效果略好但成本翻倍"的选择未必成立；把三列摆在一起，决策会清晰很多。
五、常见坑
样本泄漏：把测试样本写进了提示词示例，评测分数虚高；
只看平均值：95 分里藏着 5 条归零的样本，上线就是事故；
评测集长期不更新：线上出现了新场景，评测集还停在三个月前。
一句话总结：没有评测集的 AI 迭代，只是在用线上用户做测试。建一套小集子，成本不过半天，收益是每一次改动都可回退、可解释。