AI 应用评测体系：从 Golden Set 构建到线上灰度闭环

判断一个传统接口对不对，跑一遍断言就知道；判断一段模型回答好不好，却常常连「标准答案」都写不出来。LLM 评估的难是系统性的难。本文讲清难在哪里、公开基准能信多少、LLM-as-Judge 怎么用才不被带偏，以及如何靠 Golden Set 和业务指标搭起一条可持续的回归流水线。

为什么大模型评估难

三个结构性原因决定了这件事无法照搬传统测试：

开放式生成没有唯一答案。同一个问题有一百种正确表达方式，字符串匹配、BLEU/ROUGE 这类重合度指标既会冤枉措辞不同但正确的答案，也会放过文笔流畅的错误答案。
输出非确定。temperature 大于 0 时同一条用例每次运行的结果都不同，单次通过不代表稳定通过。
质量是多维的。事实正确、覆盖完整、格式合规、语气得当、没有越权，是几根独立的轴。一个总分会稀释关键失败——语气满分的错误退款指引，仍然是失败。

MMLU、HumanEval 这类公开基准的价值在于初筛：快速排除中文能力弱、上下文窗口不够、工具调用不达标的候选模型。但把榜单分数当成上线依据，会踩三个坑：

结论很直接：榜单用来缩小候选范围，模型能不能接进你的业务，只能靠自己的评测集回答。

让一个更强的模型给被测模型的输出打分，成本远低于纯人工，也适合开放式回答。但 Judge 自身存在已知偏差，用之前必须知道怎么缓解：

Judge Prompt 要写清评分维度、每一档的锚点行为和输出格式，一次只评一个可判定的方面；证据不足时允许输出「无法判断」并转人工，别逼它硬猜一个结论。Judge 上线前，先拿一小批人工标注集测一致率——这个校准动作省不得。

Golden Set 是应用自己的标准测试集，价值不在数量，而在每条样本都有明确的输入和可重复执行的判定标准（rubric）。样本有三个来源：

分层比总量更关键：核心集挡回归，扩展集测泛化，对抗集测安全；高风险场景单独设门禁，不允许被大盘平均分稀释。另外要留一部分保留集不参与调参，否则团队会逐渐「记住」已有用例。Golden Set 是资产而非一次性工程——绑定版本号，定期复查失效样本，否则优化方向会被一份腐化的测试集带歪。

评测的终点不是分数，是业务结果。任务执行型场景先看任务完成率：把任务拆成可验证的完成标准（退款单创建成功、状态正确、金额无误），逐条核对，全部通过才算完成。注意区分「说成功了」和「真成功了」——前者看回复文本，后者要查外部状态。

模型有随机性，关键任务要重复运行多次：pass@k（k 次里至少成功一次）反映能力上限，pass^k（k 次全部成功）才接近支付、合规这类场景需要的稳定性。单次成功率 90% 时，连续 5 次全对的概率只有约 59%，「跑几次总能成」不能当作生产保障。

线上侧配代理指标：满意反馈率、追问率、人工接管率。它们是信号而非结论——必要的澄清会推高追问率，风险场景及时转人工是正确行为，必须结合任务完成率一起解读。

评测要嵌进发布流程，而不是发布前的即兴动作：

每条评测记录要绑定 Prompt 版本、模型 ID、评测集版本与代码提交，否则跨版本对比必然失真。接入 CI 时分层控制耗时：PR 阶段只跑核心回归集（规则检查优先），完整全集放到主分支定时任务。阈值组合使用——绝对阈值守质量底线，相对阈值防版本退步。

为什么不能只用公开 benchmark 验收？ 榜单数据分布与业务脱节、存在污染与刷榜空间、平均分会掩盖高风险失败；它适合筛模型，不适合当发布门禁。

LLM-as-Judge 与人工评估结论冲突怎么办？ 把分歧样本单独收集进校准集，检查是 rubric 维度不够细，还是 Judge 存在系统性偏差；用一致率指标量化吻合程度，而不是凭感觉二选一。

Golden Set 多少条够用？ 没有通用数字。几十条足够跑通评测流程；用于发布门禁的样本量，要由业务风险、历史方差和最小可接受差异反推。分布覆盖往往比总量更先决定评测能否发现问题。