返回 AICAP-180
B3 · Day 30agent loop + 评测统计

stats-on-evals 收口

B3 整批从「agent loop 跑起来」（D21-25）到「量出来」（D26-27）再到「把数字变可信」（D28-29 的 CI 与 power）。

阶段: B3 · agent loop + 评测统计（Day 21-30） 标签: #model-selection #self-eval-bias #judge-calibration #closing

今日导引（由浅入深）

B3 整批从「agent loop 跑起来」（D21-25）到「量出来」（D26-27）再到「把数字变可信」（D28-29 的 CI 与 power）。

今天 Day 30 收口：把统计脚本接到真实 eval 输出，用「CI 是否含 0」直接给出一句可落地的模型选型结论，并点破一个贯穿全套的隐患——evalBaseline.ts 里的「循环自评」：模型既当被测又当裁判会高估自己，必须独立 grader + 人标 κ 校准。

在 B1→B18 曲线上，这是 B3 的终点，也是从「评测工程」过渡到「评测可信度治理」的节点。明天 Day 31 切入 B4（reasoning/planning/multi-agent + 何时不用 agent）。今天的最小可判定产出：pnpm test 全绿（已达成）；带 CI 的选型结论待真实报告（待跑）。

1. 机理精读

收口 = 让统计真正服务于一个决策。

前两天的 pairedBootstrap 与 power 都是工具；今天把它们落到一个动作：

  • 对 Day26（DeepSeek-V3）与 Day27（Qwen3）两份真实报告的逐题 completion 向量跑配对 bootstrap；
  • 得 Δcompletion 的 95% CI；
  • 含 0 就写「未检出显著差异，按成本/延迟择优」，不含 0 且为正就写「A 显著优于 B」。

一句结论，背后是 CI + power 双重背书，而不是裸点估计拍脑袋。这是「数据驱动选型」与「看谁分高」的分水岭。

循环自评（self-eval）的隐患。

src/aml/evalBaseline.ts 是规则基线评测：

  • 它用 assessCase 的 topTypology 当预测（null → 'normal'）；
  • 对合成金标算 recall / 误报率 / 混淆矩阵；
  • 这本身是确定性的，没问题。

但隐患在更广的 LLM-judge 场景：当被测模型同时充当裁判，它会系统性高估自己（对自己的输出风格、措辞偏好更宽容）。规则引擎自评尚有确定性兜底，LLM 自评则是评测可信度的大坑。解药是 Anthropic《Demystifying evals》(2026-01) 的两条：

  1. 独立 grader（judge 模型 ≠ 被测模型，或至少配确定性 code grader）；
  2. judge↔human 的 Cohen's κ 校准，证明裁判和人类对得上。

为什么 κ 是这套笔记的诚信底线。

judge 给的 completion% 看起来精确，但若 judge 本身偏松，这个数字是虚高的：

  • κ 量化「judge 与人标超出随机的一致程度」；
  • 本 block 里程碑要求 κ≥0.6，且必须配 bootstrap CI（cohensKappa.ts 已建）；
  • 在拿到 κ 之前，judge 数字只能当「待校准的草稿分」，不能作为最终选型依据。

这正是 D26 起反复强调、到 D30 收口时必须兑现的纪律。κ<0.6 时，正确动作是先补人标（runner 读 agent-evals/labels.json，目标 N≥50），而不是硬下结论。

规则基线为何仍要留。

evalBaseline.ts 的规则基线（确定性、可复现、无 key）是 LLM 评测的「对照锚」：

  • 它给出一个不依赖任何模型主观判断的下界（各类型学 recall + normal 误报率）；
  • 当 LLM-judge 的数字与规则基线大幅背离时，往往是 judge 出了问题而非模型变强；
  • 基线是发现 judge 失准的探针。

这也呼应「自建优先、确定性可测」的项目主线——把不确定的 LLM 判分锚在确定的规则判分上。

2. 推导 / 手算 / 代码走读

两块代码：选型用 stats.ts，自评隐患在 evalBaseline.ts。

src/aml/evalBaseline.ts（规则基线，确定性自评的「干净版」）：

  • evalRuleBaseline(ds)（第 19–50 行）：遍历数据集每个 case，predicted = assessCase(c).topTypology ?? 'normal'，按 ${c.label}->${predicted} 累计 confusion。
  • 指标：
    • perTypology[t] = { recall: correct[t]/total[t], n: total[t] }（各类型学召回）；
    • normalFalsePositiveRate = normalFp/normalN（normal 被误判为任一类型学的比例）。
  • 关键诚实点：这里的「自评」是规则引擎判规则引擎自己的输出，确定性、可被代码逐条核对——这正是 LLM 自评缺的兜底；它是对照锚，不是问题源。

src/agent/eval/stats.ts（选型判定）：

  • pairedBootstrap(aCompletion, bCompletion) → { deltaMean, ci95: [lo, hi], n, iters }。
  • 判定规则：lo <= 0 && hi >= 0 → CI 含 0 → 不显著；否则按 deltaMean 符号定方向。

最小判定逻辑（伪代码）：

const { deltaMean, ci95: [lo, hi] } = pairedBootstrap(aComp, bComp)
let conclusion: string
if (lo <= 0 && hi >= 0)      conclusion = "Δ未达显著（CI含0）→按成本/延迟择优"
else if (deltaMean > 0)      conclusion = `A 显著优于 B（Δ=${deltaMean}, CI[${lo},${hi}]）`
else                         conclusion = `B 显著优于 A（Δ=${deltaMean}, CI[${lo},${hi}]）`
// 但：仅当 judgeHumanKappa.kappa >= 0.6 时，上面的 conclusion 才作准；
// 否则先补人标（agent-evals/labels.json，目标 N>=50），结论标注「待 κ 校准」。

κ 接线走读（scripts/run-agent-eval.ts 第 56–66 行 loadHumanLabels）：runner 读 agent-evals/labels.json（{ "<taskId>": "pass"|"fail"|"unknown" }），不存在则返回 undefined（跳过 κ）；存在但非合法 JSON 则 warn + 跳过。runTaskEval 拿到 humanLabels 且配对 ≥2 才算 judgeHumanKappa，并在控制台打印 kappa ± 95% CI (N=…)——把「裁判可不可信」与「谁更优」同屏呈现。

3. 今日实战

  1. 对 Day26 / Day27 两份 agent-evals/ 报告，取逐题 completion 向量，跑 src/agent/eval/stats.ts 的 pairedBootstrap，输出 Δcompletion 的 95% CI，判断是否含 0。
  2. 据 CI 写一句模型选型结论（含 0 → 按成本/延迟择优；不含 0 → 指明谁显著更优）。
  3. 在结论前先确认 judge 已经 κ 校准（κ≥0.6）——否则结论标注「待 κ 校准」并先补 agent-evals/labels.json。
  4. 最后跑全量 pnpm test 确认全绿。

4. 今日实测 / 产出

  • pnpm test 全绿 —— 已达成（378 tests passing，tsc clean）。
  • 带 CI 的选型结论（Δcompletion 95% CI 是否跨 0） —— 待跑（需 OPENROUTER_API_KEY 出 Day26/27 真实报告后填）；stats 脚本与 loop/harness 均已建可离线跑通流程。
  • 真实 Δcompletion / CI / 选型结论未产出数字——不臆造。

5. 常见误区 / 陷阱

  • 用被测模型自评当最终分：循环自评高估自己；judge 须独立 + κ 校准。
  • κ 未达 0.6 就拿 judge 数字下选型结论：裁判没校准，结论无地基。
  • CI 含 0 仍硬选「更优者」：含 0 = 未检出显著差异，应转看成本/延迟。
  • 忽略规则基线对照锚：当 judge 数字与确定性基线大幅背离时，多半是 judge 失准而非模型变强。
  • 把 agent-evals/labels.json 缺失当「κ=高」：缺人标时 κ 是 null（未校准），不是默认通过。

6. 学习资源（每条带 YYYY-MM）

  • Anthropic, Demystifying evals（2026-01）—— 循环自评隐患、judge↔human κ 校准、独立 grader，本日收口主引用。
  • 本仓 src/aml/evalBaseline.ts —— 确定性规则基线（recall / 误报率 / 混淆矩阵）代码走读，作 LLM 评测对照锚。
  • 本仓 src/agent/eval/stats.ts + cohensKappa.ts（2026）—— pairedBootstrap 选型判定 + κ 校准实现。
  • Miller, Adding Error Bars to Evals（2024-11）—— CI 是选型结论的硬前提。

SOTA检查 (2026-06 更新)

  • 当前主流：循环自评隐患是当前 LLM-judge 的共识坑（Anthropic《Demystifying evals》2026-01 强调 judge↔human κ 校准），本 block 里程碑要求 κ≥0.6。
  • 是否仍 SOTA：是。独立 grader + κ + bootstrap CI 背书仍是 2026 评审硬要求。
  • 过时黑名单：避免用被测模型自评当最终分数；judge 须配 Cohen's κ（cohensKappa.ts 已建）+ bootstrap CI；勿用无 CI 的 judge 数字下选型结论。
  • 下次复查点：拿到 OPENROUTER_API_KEY 后回填 Day26/27 真实报告与 κ；进入 B4 后用 reasoning/planning 视角重审「何时根本不该上 agent」。

衔接

  • 昨天：Day 29 — 统计功效 power（量化 29 任务够不够）。
  • 今天：统计脚本接真实报告，CI 含 0 与否给选型结论，点破循环自评隐患；pnpm test 全绿（378），CI 结论待 key。
  • 明天：Day 31 — reasoning/planning 谱系（B4 开篇：CoT/ReAct/self-consistency/plan-execute，以及何时不用多步推理）。
上一篇 · Day 29
统计功效 power
下一篇 · Day 31
reasoning/planning 谱系