建立一套会持续有用的 AI 评测集

评测集不是“模型曾经答得很好”的 Prompt 收藏夹，而是一件持续维护的决策工具：它要回答某条具体工作流是否可以变更。为此，案例要像用户真正提交的任务，参考结果要能复核，评分也要把关键失败单独暴露出来，不能让它们消失在平均分里。

10 条案例试验适合判断一个想法值不值得继续投入。长期评测集解决的是下一阶段问题：更换 Prompt、模型、检索资料或工具以后，真实工作流是否变得更好，同时没有破坏某个重要任务切片？

先写清评测支持哪个发布决定

先记录评测结果会触发什么决定，例如“替换当前分类器”“允许初稿进入复核队列”或“更新检索索引”。没有决定，团队容易不断收集案例，却无法说明某个分数到底允许做什么。

同时定义评测单位。一个单位可以是“客户请求加目标路由”，也可以是“问题、回答和引用片段”。不要把整段对话、单条消息和单个抽取字段塞进同一个分母，它们的失败方式并不相同。

在选择指标前写下不可妥协门槛。平均分提高，不能抵消泄露受限文档、编造退款承诺或执行不可逆动作。这类失败应单独计数，并直接触发停止发布。

从真实工作中抽取任务切片

选择一个能代表当前使用场景的近期流量窗口，去掉重复项和本就属于其他流程的事件，再标出真正影响行为的切片。常见维度包括语言、输入长度、任务子类型、资料是否齐全、歧义程度、紧急度和风险等级。只保留那些可能改变发布决定的维度。

为每个切片指定目标占比或最低案例数。完全随机的样本可能漏掉数量少、伤害却大的场景。应主动纳入这些案例，但把它们与普通流量估计分开报告，这样既不扭曲日常表现，也不会隐藏安全问题。

保留一组最终比较前不会反复调试的案例。如果每个失败案例都被加入 Prompt 示例，同时继续留在同一测试集中，系统可能只是在熟悉题目上进步，对新输入却没有更可靠。

让参考结果容纳多种正确表达

抽取、路由和计算任务可以有精确标准值；写作和问答任务往往不只有一个好答案。此时不要只保存一段所谓“标准回答”，而应记录必须出现的结论、允许使用的证据、禁止生成的说法，以及可以接受的不确定性表达。

准备简短评分指南，分别给出通过、部分通过和失败样例。让两位评审者独立判断一小组相同案例，再讨论分歧，直到差别被写进指南，而不是只留在个人感觉中。任务或评审成员变化时要重新校准。

自动评分器可以扩大执行规模，但必须先与校准后的人工判断对照。记录它在哪些切片过宽、过严，或只是偏爱某种写作风格。评分器解释得流畅，不等于它真的遵守了工作流验收规则。

案例一：为电商退货请求分流

运营团队希望把退货请求分为普通退货、商品损坏、疑似欺诈和人工处理。历史数据里普通退货占大多数，而代价最高的错误往往出现在少见组合，例如配送争议叠加高价值商品。

团队从近期请求中抽样，按目标路由、证据完整度、订单时间、语言和疑似滥用情况建立切片。参考标签不直接沿用旧自动化结果，而是由两位有经验的客服依据当前政策重新判断，并记录目标路由以及决定性证据。只要系统把一条疑似欺诈请求错误送入普通退货，即使总准确表现上升，也会阻止发布。

上线后，被人工推翻的路由进入候选池，但不自动塞进评测集。负责人要先复核、分配切片、删除不必要个人数据，并记录它从哪个评测版本开始生效。

案例二：依据内部制度回答问题

制度助手必须从批准文档中回答，并展示支持依据。每个评测单位包含问题、允许使用的文档版本、必须保留的结论、支持段落位置，以及回答不能丢失的限定条件。

案例同时覆盖直接查找、不同版本答案发生变化、文档之间冲突、资料没有答案，以及提问者无权查看来源的情况。团队分别报告答案支持度、引用正确性、限定条件保留情况和拒答是否恰当。一个混合总分会掩盖“回答听起来准确，却引用错误版本”的系统。

制度更新后，受影响案例要更换参考结果并写版本说明。旧案例可以留作复现过去发布，但不再参与当前决定。

从第一版评测蓝图开始

不要先追求庞大样本。第一版只要能覆盖决定路径并暴露致命失败即可。为每条案例建立下面这些字段：

字段	作用	容易遗漏的细节
case_id	让结果、讨论和修复可以追溯	不要用题目全文充当编号
task_slice	标记任务类型与风险切片	一个案例可以有多个标签
input_snapshot	保存当时真正交给系统的输入	包括系统指令、上下文和工具返回
expected_behavior	写必须出现与不得出现的行为	不强迫开放式任务只有一种措辞
blocking_rule	指出是否能阻止发布	与验收契约中的规则编号对应
reviewer_note	解释边界判断	记录分歧如何解决
source_version	固定参考资料的有效版本	资料更新后不能静默覆盖

第一次运行时先人工复核全部案例，检查评测脚本是否把完整输入送到了正确版本的工作流。只有对照人工结论后，才让自动评分承担一部分重复判断。这样能够避免出现“评分程序一直正常，但它测的并不是上线系统”这一类隐蔽错误。

阅读一份评测报告

报告首页只回答四件事：测试了哪个版本，和哪个基线比较，哪些门槛通过，最后做了什么发布决定。随后再展开切片结果、失败案例与评审分歧。

看到总分上升时，先问提升来自哪些切片；看到总分下降时，也要确认是否因为新增了更难、更真实的案例。两个不同版本的评测集不能直接拿裸分比较。对于每个阻断性失败，报告应给出案例编号、违反规则、影响范围、负责人和复测条件，而不是只贴一段模型输出。

常见问题

案例多久更新一次？ 不按固定数量扩充。新业务分支、新输入格式、资料版本变化或线上出现新失败机制时更新，并为变化留下版本说明。

可以让另一个模型做评分吗？ 可以辅助，但必须先用校准样本确认它对关键规则的判断与人工一致，并把评分模型和 Prompt 版本写进运行记录。

线上差评能直接加入吗？ 不能。先确认它属于当前任务、删除无关敏感信息、补齐参考判断，再决定放入回归集、观察集还是只作为单次事故材料。

把评测集作为有版本的资产运行

每次评测都记录数据集版本、工作流版本、配置、评分器版本和日期。只有当生产环境出现新的任务切片或失败机制时才添加案例；任务已经消失、来源失效，或题目被泄露进训练和 Prompt 示例时，应退役或改写案例。

定期检查切片覆盖。案例更多不等于更好；一套来源清楚、参考仍然有效的小评测集，远比一个无人能解释的大文件夹有用。结果应按切片发布，列出阻断性失败并写明最终决定，让以后的人能够复现这次判断。

不适用边界

评测集只能估计已经定义并取样的任务行为，不能证明模型适合其他用户、语言、工具或风险等级，也发现不了抽样和验收规则从未命名的失败。

不要用公开榜单或供应商总分替代自己的工作流案例，也不要在缺少权限和最小化处理时重复利用生产输入。高影响场景还可能需要领域、安全、隐私和法务负责人进行独立测试。如果评审者连什么算合格都无法达成一致，应先暂停模型比较，修复任务契约，而不是继续增加样本数量。