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

评测统计基础

- 能力曲线位置：B3 是「agent loop + 评测统计」双线推进——Day 21-22 搭 agent 这一侧（回路判据 + 工具契约），今天切到统计这一侧。

阶段: B3 · agent loop + 评测统计（Day 21-30） 标签: #eval-stats #confidence-interval #wald-ci #statistical-power

今日导引（由浅入深）

  • 能力曲线位置：B3 是「agent loop + 评测统计」双线推进——Day 21-22 搭 agent 这一侧（回路判据 + 工具契约），今天切到统计这一侧。
  • 最朴素也最致命的问题：当你在 29 个任务上跑出 completion=0.72，你能不能说「这个 agent 真的有 72% 的成功率」？不能——这只是一个点估计，真值可能在 0.55-0.89 之间晃。
  • 为什么现在学：今天补的「给评测数字加误差棒」是后面 Day 26（runTaskEval 打通）、Day 27-28（模型 A/B + paired bootstrap）、Day 29（power）能下结论的前提；没有 CI，所有对比都是自欺。
  • 最小可判定产出：对 tasks.ts 的 29 任务跑一次 baseline，记 completion 率 p 并手算 Wald 95% CI——离线 fixture 可先跑通流程，真实 p 需 key。

1. 机理精读

单个 completion 率点估计会骗人。

  • 在 N 个任务上观察到 k 个通过，比例 p̂ = k/N 只是对真实成功率 p 的一次抽样估计。
  • N 越小，这次抽样的随机波动越大——29 个任务里多通过/少通过一两个，p̂ 就跳好几个百分点（1/29 ≈ 3.4pp/题）。
  • 所以只报 p̂ 是不诚实的，必须同时报告这个估计的不确定性，即置信区间（CI）。
  • 参考 Miller《Adding Error Bars to Evals》(2024-11)：eval 数字没有误差棒就不可比、不可下结论。

Wald 95% CI 的公式与直觉。 二项比例的正态近似（Wald）给出：

CI ≈ p̂ ± 1.96 · √( p̂(1 - p̂) / n )

直觉拆解：p̂(1-p̂) 是单次伯努利试验的方差（p̂=0.5 时最大、靠近 0 或 1 时最小），除以 n 是均值的方差，开方得标准误（standard error, SE），乘 1.96 得 95% 双侧半宽。半宽随 √n 收窄——要把 CI 缩一半，样本量得翻四倍。这就是为什么 29 个任务「太少」。

样本量越小，CI 越宽，power 越低。

  • power（统计功效）是「当两个方案真有差异时，你的实验能把它检出来的概率」。
  • 因果链：N 小 → SE 大 → CI 宽 → 两个方案的 CI 大幅重叠 → 检不出真实差异（power 低）。
  • 这条链把「N=29 不够」从直觉变成可量化的事实，也预告了 Day 29（统计功效 power）会正式处理「要多大 N 才够」。

n=29 的具体感知。

  • 对 p̂≈0.7、n=29，半宽 ≈ 1.96·√(0.7·0.3/29) = 1.96·√(0.21/29) = 1.96·√0.007241 ≈ 1.96·0.08510 ≈ 0.167。
  • 也就是说，0.72 的点估计配的是约 [0.55, 0.89] 的 95% CI——区间宽到几乎不能支撑任何精细结论。
  • 提前把这个数字算出来，是为了在跑真实 eval 前就清醒：29 任务只够看大方向，不够分胜负。
  • 这也呼应 MEMORY 里那条真实测量：DeepSeek-V4 A/B 的 Δ+10.3pp 配的是 95% CI[0,20.7]，下界压到 0 → 在 N=29 量级上「not-significant」，正是 CI 太宽的活样本。

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

手算 Wald CI（逐步），设观察到 p̂=0.70、n=29（即 29 题里约 20 题通过）：

  1. 方差项：p̂(1-p̂) = 0.70 × 0.30 = 0.21
  2. 均值方差：0.21 / 29 = 0.0072414
  3. 标准误 SE：√0.0072414 = 0.08510
  4. 半宽：1.96 × 0.08510 = 0.16680
  5. CI：0.70 ± 0.167 = [0.533, 0.867]

半宽 0.167 意味着：要想把 95% CI 收到 ±0.05（半宽缩 3.3 倍），样本量得放大 ≈3.3²≈11 倍，即 ~320 题——这就是「29 任务太少」的定量代价，也是 Day 29 power 分析的引子。

换一个更极端的 p̂=0.90、n=29：SE=√(0.09/29)=√0.003103=0.05570，半宽=1.96·0.05570=0.1092，CI=[0.791, 1.009]——上界越过 1，说明 Wald 对极端 p 不稳（这正是 SOTA 检查里提到、后续可换 Wilson 区间的原因）。

Wilson 区间对照（同 p̂=0.90、n=29），公式中心点会向 0.5 收缩、且永不越界：

中心 = (p̂ + z²/2n) / (1 + z²/n)，z=1.96，z²=3.8416
     = (0.90 + 3.8416/58) / (1 + 3.8416/29)
     = (0.90 + 0.06624) / (1 + 0.13247)
     = 0.96624 / 1.13247 = 0.8533
半宽 = z/(1+z²/n) · √( p̂(1-p̂)/n + z²/4n² )
     = 1.96/1.13247 · √(0.09/29 + 3.8416/(4·841))
     = 1.7307 · √(0.003103 + 0.001142) = 1.7307 · 0.06515 = 0.1128
Wilson CI ≈ [0.741, 0.966]  ← 上界 ≤1，比 Wald 的 [0.791, 1.009] 稳。

结论：常规 p（0.3-0.7）用 Wald 够；p̂ 贴近 0/1 或 n 小时切 Wilson，避免「概率 >1」这种荒谬区间。

baseline 的 codeCheck 启发式只是首过。 比如 aml-structuring-classic 的 codeCheck = has(/structur|smurf/i)（tasks.ts），它只看输出里有没有 structuring/smurf 关键词——能过正则不代表答案对（可能误报、可能格式错、可能编造）。所以 completion 率的「真分」要由 LLM-judge 的 outcome 判分给，codeCheck 仅做廉价过滤，二者口径不同，不能混报。

任务套件走读（src/agent/eval/tasks.ts）：

  • 套件导出为 EVAL_TASKS = [...AML_DETECT, ...AML_RESTRAINT, ...AML_COMPLIANCE, ...AGENT_CORE]（tasks.ts:353），实测 29 个 task（每个含唯一 id）。
  • 文件头注释明示这些任务是专家依据 FATF/BSA AML 类型学 + 已知 LLM-agent 失败模式手写的，不是从生产 transcript 挖的（AML Copilot 是确定性规则引擎，目前没有真实 LLM transcript）。
  • 任务刻意瞄准模型会翻车的地方：over-flagging（把正常模式误报）、缺数据时编造、破坏输出格式、服从注入指令、该人审却自动行动。
  • 类别枚举 EvalCategory 覆盖 aml-detect / aml-restraint / aml-typology / aml-compliance / format / honesty / robustness / planning / safety / injection / reasoning（tasks.ts:25），tasksByCategory() 可统计各类计数。
  • 每个 task 的 codeCheck 是便宜的启发式首过（如 has(/structur|smurf/i)），真正的 outcome 判分 + partial credit 由 Day 26 接入的 LLM-judge 做。
  • 文件头还写明 CLOSED LOOP：真模型跑完后，把观察到的真实失败追加为新任务，并手标 ≥50 条到 agent-evals/labels.json 校准 judge（Cohen's kappa）——与 B2 的 judge 校准对接。

3. 今日实战

  1. Read src/agent/eval/tasks.ts，确认 29 任务套件结构（4 组拼接，11 个类别）。
  2. 跑一次 baseline：先用离线 fixture 跑通 harness 流程（验证 generate→codeCheck→judge→聚合通路），记 completion 率 p。
  3. 手算 Wald 95% CI：对 p≈0.7、n=29，半宽 ≈ 1.96·√(0.7·0.3/29) ≈ ±0.167，提前感知「29 任务太少」。
  4. 笔记里附 baseline completion% ± CI 一行；标注真实 p 需 key，离线 fixture 仅验流程。

4. 今日实测 / 产出

  • 产出：笔记附 baseline completion% ± CI 一行。
  • 状态：待跑（需 OPENROUTER_API_KEY）；可先用离线 fixture 跑通 harness 出 completion% + commit。
  • tasks.ts 的 29 任务套件已建（AML/BSA + agent failure modes，测试绿）。
  • 手算预告：n=29、p≈0.7 时 Wald 半宽约 ±0.167（CI 约 [0.53, 0.87]），区间太宽 → 29 任务只够看大方向。

5. 常见误区 / 陷阱

  • 只报点估计、不报 CI。 2026 评审硬要求误差棒；0.72 不配 CI 等于没说。
  • 拿宽 CI 当结论下。 n=29 的 ±0.167 半宽不足以分胜负，只能看趋势——别用它声称 A 比 B 强。
  • 对极端 p 硬套 Wald。 p̂ 靠近 0 或 1 时 Wald CI 会越界（>1 或 <0），应换 Wilson 区间。
  • 把 codeCheck 的 pass 当最终成绩。 codeCheck 是启发式首过（正则匹配），真正判分靠 LLM-judge + partial credit（Day 26）。
  • 不区分「completion 率的 CI」与「判分本身的噪声」。 即使 N 够大、CI 够窄，若 LLM-judge 未经 κ 校准（B2/Day 28 之后），数字本身也不可信——这是两层不确定性，须分别压住。

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

  • Miller, Adding Error Bars to Evals（Anthropic）— 2024-11（eval 误差棒方法论，本日机理主线）
  • Brown et al. / Anthropic, Don't Pass@k（pass@k/pass^k 批评）— 2025-10（B4 会用到，预告 Wald 局限）
  • 本仓代码：src/agent/eval/tasks.ts（EVAL_TASKS 29 任务，11 类别，CLOSED LOOP 注释）— 2026-06
  • 本仓代码：src/agent/eval/agentEval.ts（runTaskEval 聚合 completionRate / unknownRate / codePassRate）— 2026-06
  • Wilson, Probable Inference, the Law of Succession, and Statistical Inference — 1927（Wilson 区间原始来源，极端 p 更稳）

SOTA检查 (2026-06 更新)

  • 当前主流方案：Miller《Adding Error Bars to Evals》(2024-11) 方法论仍 current——eval 必须带 CI，是 2026 评审硬门槛。
  • 是否仍 SOTA：是，但要注意局限——单纯 Wald CI 对极端 p（接近 0 或 1）不稳，大样本/极端比例可换 Wilson 区间；后续 B4 会引入 pass@k/pass^k 与《Don't Pass@k》(2025-10) 的批评。
  • 过时黑名单：勿只报点估计无 CI；勿对 p̂→0/1 硬套 Wald 而不切 Wilson。
  • 下次复查点：B4 阶段对照《Don't Pass@k》(2025-10) 重审 pass@k 口径；周一 WebSearch「eval error bars 2026」「pass@k critique 2026」。

衔接

  • 昨天：Day 22 — Tool 设计契约（agent 的 API 表面：schema + 结构化错误）
  • 今天：给评测数字加误差棒——Wald 95% CI，n=29 半宽 ±0.167，提前知道「任务太少」
  • 明天：Day 24 — 无框架 agent loop 骨架（observe→act→observe，硬上限 8 步）
上一篇 · Day 22
Tool 设计契约
下一篇 · Day 24
无框架 agent loop 骨架