AlphaEval 管批量跑分、人工抽检管口径一致

批量跑分和人工抽检不是二选一，而是两层：AlphaEval 这类批量评测负责“覆盖面”，把全部任务跑一遍，给出可复现、可对比的分数；人工抽检负责“口径”，确认自动打分的每一项在实际语义上是否和人一致。判断边界可以先按一条粗线走：凡是自动评分器无法用确定性规则判定的样本，都必须进人工；其余样本按分数段和失败状态分层抽检。这条线不需要一开始就划得完美，先跑一轮，用分歧记录反过来修正判定条件和评分项，比在开跑前反复讨论更有效。

批量自动打分解决覆盖和可比，人工抽检解决口径校准，两者分工的关键是先按“开放式回答、多步工具调用、评分项含主观描述”筛出必须人工过目的任务清单，其余样本靠分层抽样覆盖。自动分与人工分不一致时，先记录任务 id、自动分、人工分、分歧原因、处理结论，再决定改评分项还是改抽检范围。验证方式是固定样本集在规则修改前后各跑一遍，看人工与自动的一致情况是否收敛；样本量小、任务分布倾斜时，结论只能作为参考，不能当整体质量结论。

先定哪一类任务必须人工过目

人工预算有限，先花在“自动评分器最容易判错、错了代价又大”的样本上。可以用三个判定条件做筛选，命中任意一条即进入必检清单，三条都不命中的进入抽样池。判定条件建议写成可查询的字段，而不是靠人记：开放式回答（答案无唯一标准形式，如解释、建议、方案类）、多步工具调用（一次任务内有两次以上工具调用或存在调用顺序依赖）、评分项含主观描述（评分项文字里出现“合理”“清晰”“恰当”这类无法直接判定的词）。

必检任务清单：涉及工具调用链的问答、生成类长回答、带主观评分项的任务、上一轮出现过分歧的任务类型。
抽样池：单选或短答案、格式校验类任务、有确定性校验脚本覆盖的字段类任务。
跳过人工：只做格式和 schema 校验、结果可由程序逐字段比对的样本。

清单要落到配置里，抽检脚本读配置决定哪些样本强制人工，避免每次靠人回忆。清单本身也需要定期复核，评测任务新增类型时先补判定条件，再开跑。

把自动打分的评分项拆成可核对条目

抽检时凭整体印象打一个分，事后无法解释分歧从哪来。做法是把每个评分项拆成可以逐条打勾的条目，人工抽检时按条目对照填写，自动打分也按同一条目输出。以常见的回答质量评分为例，可以拆成事实正确性、格式合规、工具使用是否合理三组，每组给一句可判定的描述和判定依据。

score_items:
  - id: fact_correctness
    desc: 回答中的事实性陈述与参考材料一致，无编造实体、数值或引用
    evidence: 参考材料片段 / 工具返回结果
  - id: format_compliance
    desc: 输出符合约定结构（字段齐全、类型正确、无多余段落外壳）
    evidence: schema 校验结果
  - id: tool_usage
    desc: 调用次数与顺序合理，参数取自任务上下文，无冗余或缺失调用
    evidence: 工具调用日志

拆分后的条目要满足两点：人工能在不查文档的情况下判定；自动评分器能对同一条目输出通过或失败。做不到第二条的条目，说明还需要再拆，或者应当直接归入必检清单。抽检页面按条目逐项展示自动判定和人工判定两列，分歧才会落在具体条目上，而不是落在总分上。

抽检样本怎么抽才有代表性

抽样目标是反映分布，不是挑典型。常用做法是分层抽样，三个分层维度可以先用任务类型和分数段，失败率高的任务类型再加一层。每层抽样数量按该层在整体中的占比和风险高低分配，风险层多抽，长尾层保证最少条数，避免某一类任务完全没被看过。

按任务类型分层：每类先抽一个下限，比如每类至少若干条，再按占比追加。
按分数段分层：高分、中段、低分三段各抽一部分，低分段是分歧高发区，权重可以适当提高。
按失败率分层：历史上分歧率或失败率偏高的任务类型单列一层，抽检比例高于平均值。
固定回归样本：每轮都跑同一批已知结论的样本，用来观察评分规则是否被改坏。

每层抽样数量没有通用数字，可以先按“每层不少于若干条、总量控制在人工可完成范围”起步，跑完一轮看各层分歧率，把分歧集中的层调高。抽样脚本要打印本次抽到的任务 id 列表并存档，否则下一轮无法复现同一批样本。

自动分和人工分不一致时怎么处理

分歧不是要说服对方，而是要落到记录上。每次抽检发现自动判定与人工判定不同，就写一行分歧记录，字段固定，便于后续统计和回灌。建议字段：任务 id、自动分、人工分、分歧原因、处理结论。分歧原因用枚举而不是自由文本，否则统计不出来。

task_id,auto_score,human_score,reason,decision
case_0012,0.6,1.0,judge_missed_context,update_rule
case_0013,1.0,0.5,rule_too_lenient,add_check
task_id auto_score human_score reason decision

reason 常见取值：评分器漏读上下文 / 规则过宽 / 规则过严 / 主观条目无判定依据 / 任务本身描述不清。
decision 常见取值：修改评分规则 / 补充判定示例 / 加入必检清单 / 判定为标注错误 / 暂不处理。

处理顺序建议先看任务描述是否清楚，再看评分项是否可判定，最后才动评分规则。同一类 reason 连续出现多次，说明是规则问题而不是个案，优先改规则；分散出现的，先记为标注偏差，不急着改。分歧记录本身要能按任务类型和 reason 聚合，否则看不出趋势。

把抽检结论回灌到评分规则

规则改完必须做对照跑，否则不知道是变好还是变坏。对照跑法可以固定同一批样本集：抽检样本 + 回归样本，规则修改前跑一次记录每条的自动分，修改后再跑一次，逐条比对自动判定是否与人工判定一致。样本集和任务版本要一起存档，保证两次跑的是同一份输入。

# 通用流程骨架，具体命令按本地评测工具替换
run_eval `--set` sample_set_v1 `--rules` rules_old.json `--out` before.json
run_eval `--set` sample_set_v1 `--rules` rules_new.json `--out` after.json
diff_report `--auto` before.json `--human` human_labels.csv

观察指标建议盯四个：人工与自动判定的一致条目数、分歧条目集中在哪些评分项、低分段样本的判定变化、回归样本是否出现翻转。一致条目数上升且回归样本没被改坏，才认为口径在收敛；如果一致条目数上升但某些任务类型的准确判定明显变差，说明规则改动只贴合了抽检样本，需要补抽该类型的样本再验证。样本量小的时候，这些数字只能作为方向参考，需要结合环境确认后再决定是否全量启用新规则。