判定逻辑不能散在临时笔记本里——下一个人无法复用。
写在文档里的评测，等于没有评测
很多团队的评测"定义"写在文档里 ✗：判定标准、样本清单、指标口径 ✔ ——
但没有可执行的脚本 ✔。结果每年都要有人重新实现一遍 ✗，
而且两个人的实现细节不同，指标无法比较 ✗。
评测要落成脚本 ✔：一条命令能跑、输出结构固定、结果可存档 ✔。
一、评测脚本该有的四个部分
```
① 样本加载（含版本号 ✔）
② 调用被测系统（限速、可重试、可缓存 ✔）
③ 判定（规则 + 人工标注表 ✔）
④ 报告（指标 + 失败类型 + 明细文件 ✔）
```
第 ③ 部分是关键 ✗：判定逻辑必须可读、可测、可版本化 ✔ ——
不能散在临时笔记本里 ✔（下一个人无法复用 ✔）。
二、三个硬性要求
1. 可复跑 ✔：同一批样本 + 同一系统版本 → 指标应稳定 ✔；
2. 可对比 ✔：报告里带"上一次运行"的对照（或与基线文件比较 ✔）；
3. 可存档 ✔：每次运行输出一个带时间戳的结果文件 ✔（便于画趋势 ✔）。
三、把"人工判定"也纳入流程
规则判不了的部分（生成质量、语气 ✔）需要人看 ✔。做法：
· 脚本导出待人工判定的清单（含输入、输出、样本 id ✔）；
· 人工填回一张表（格式固定 ✔），脚本再合并它的结果 ✔；
· 人工表也要版本化 ✔（否则历史结果无法复现 ✔）。
要点：人工环节不能被绕过（脚本应检查人工表是否存在且覆盖 ✔），也不能静默为空 ✔。
四、评测脚本本身的测试
· 判定函数的单元测试（正例/反例 ✔ —— 尤其是"该拒答却作答"这类边界 ✔）；
· 回归用例：故意构造一个"必然失败"的样本 ✔，确认脚本会报错 ✔（我给门禁做反证是同一个思路 ✔）；
· 变更判定逻辑时，旧结果要能重算 ✔（或明确标注口径已变 ✔）。
五、与流水线的关系
· 本地跑：make eval 一条命令 ✔；
· CI 跑：冒烟集（几十条、1 分钟内 ✔）阻断合并 ✔；
· 夜间跑：完整集 + 成本/延迟统计 ✔（见评测接进 CI 那篇 ✔）。
一条判据
> 换一个人来做同一件事 ✔，能否只读脚本就明白"怎么判定、为什么这么判定" ✔，并复跑出一样的数字 ✔？
> 不能，说明评测还停在文档与个人习惯上 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：AI 与人工的分工线怎么划：效率与风险的平衡
下一篇：检索里的否定与例外：别让模型只看到一半 →
第 85 / 171 篇