子套件骨架搭建

阶段: B15 · FIS×Anthropic 模式 + 对抗/HITL 套件（Day 141-150） 标签: #eval-harness #code-graded #llm-judge #bootstrap-ci

今日导引（由浅入深）

Day 143 把 3 条 evasion fixtures 设计出来了，但 fixtures 只是「题目」，还需要一套「考场」来跑它们并判分。今天搭这套考场——evasion & safety 子套件的三层防御骨架：harness 跑任务、codeCheck 硬断言、LLM-judge 兜底。这一天在 B1→B18 曲线上把 B14 学的 ground-truth eval 方法论落到一个新的子套件上，紧接昨天的 fixtures，通向 Day 145-146 把套件填满到 10 任务。最小可判定产出：4 个对抗任务（3 evasion + 1 OFAC 硬停）接入 tasks.ts，每任务带 codeCheck 断言，pnpm test 的 codeCheck 层全绿（确定性，不需 model）。

1. 机理精读

三层防御设计。 evasion & safety 子套件设计三层：

1. 复用 agentEval harness 跑任务——不重造引擎，复用 src/agent/eval/agentEval.ts 的 runTaskEval，对每个任务调 generate（模型）+ code grader + LLM-judge。
2. codeCheck 硬规则确定性断言——期望字符串必须/禁止出现（白名单 ∧ 黑名单）。这一层不需要 model，纯确定性，是 CI 里能稳定跑绿的部分。
3. LLM-judge 兜底处理语义模糊——codeCheck 是廉价启发式（可能漏判「我拒绝……但原理是」这种半服从），LLM-judge 看整体语义给 outcome 判定 + 部分信用。

为什么分三层：确定性优先、语义兜底。 这套分层的设计哲学是「能确定性判的绝不交给模型」。OFAC 硬停、auto-SAR 这类有唯一正确答案的，必须 codeCheck（确定性，可在 CI 无 key 跑）；语义模糊的（叙事是否真拒绝、是否暗中泄方法）才用 LLM-judge。反过来——只用 LLM-judge 单层会被语义模糊钻空，且每跑一次都烧 key。

关键权衡：codeCheck 的 precision vs recall。 codeCheck 是正则启发式，存在两类错误：false pass（正则匹配到「拒绝」字样但实际半服从）和 false fail（模型用了正则没覆盖的拒绝措辞）。权衡是：codeCheck 设计成高 precision 的硬线（OFAC/SAR 这种黑白分明的），语义灰区交给 LLM-judge。这正是为什么 OFAC 硬停必须 code-graded——它黑白分明，不该有灰区。

抵抗率口径与置信区间。 抵抗率（拒绝数/总数）须配 bootstrap CI 防小样本误判——这与 Day 137 的 CI 教训一脉相承：小样本下点估计不可信。groundTruthEval.ts 的 binaryEvalWithCI 已提供 percentile bootstrap CI 机制，抵抗率可复用同款 bootstrap。评测分层参考 Anthropic《Demystifying evals》(2026-01)：code-graded + LLM-judge 双层。

bootstrap CI 为什么是防小样本的关键。 抵抗率在 4-10 任务上算出来，点估计方差极大：10 任务里抵抗 8 次，点估计 80%，但 95% CI 可能宽到 [44%, 97%]——也就是「真实抵抗率可能低到 44%」。bootstrap CI（对样本有放回重采样 B 次、取分位数）把这种不确定性显式量化出来，避免「80% 抵抗率」被当成可靠结论。这与 Day 137 的 A/B 教训同源：N=29 时 Δ+10.3pp 的 95% CI[0,20.7] 跨 0、不显著，约需 ~70 任务才有 power——同样道理，evasion 套件 10 任务的抵抗率 CI 必然很宽，报告时必须带 CI、不能只报点估计。

LLM-judge 自身需校准（一个尚未补的环节）。 三层防御里 LLM-judge 是兜底层，但 judge 本身可能判错——它的判定需要与人工金标对齐才可信。agentEval.ts 的 runTaskEval 支持传入 humanLabels，当有 ≥2 条人工标注时会算 judge↔human 的 Cohen's kappa + bootstrap CI（line 102-115，调用 cohensKappaWithCI）。但 AICAP-180 当前的 judge-κ 人工标注仍 gated（需 ≥50 条手标才能校准）——所以现在 LLM-judge 是「未校准的兜底」，这点必须诚实标注：套件能跑，但 judge 可信度待人工标注验证。

与相邻概念的边界：套件骨架 ≠ 套件跑通。 今天搭的是骨架——任务接入 + codeCheck 确定性测试。codeCheck 层能跑绿，但LLM-judge 兜底层的抵抗率仍待跑（需 key）。骨架绿 ≠ 模型抵抗率已知。这条边界必须诚实标注。

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

接入点是 src/agent/eval/tasks.ts + harness agentEval.ts。已 Read 两文件，引用真实符号：

• harness 侧 agentEval.ts 的 runTaskEval(tasks, opts)（line 77-128）——走读其判分流程：对每个 task 先 opts.generate(task) 拿模型输出，再 task.codeCheck?(g.output)（line 81）做确定性检查，再 opts.judge(...)（line 82）做 LLM-judge；聚合出 completionRate（judge.label==='pass' 占比）、codePassRate（有 codeCheck 的任务里 pass 占比，line 123）、unknownRate、partialCreditMean。关键：codeCheck 与 judge 是两条独立判分线——codeCheck 在 generate/judge 都可注入 fake 的前提下能纯单测（无 key）。
• task 结构 EvalTask（agentEval.ts line 20-28）——codeCheck?: (output: string) => { pass: boolean; detail?: string }，确定性、廉价、heuristic by design（注释 line 27）。
• 现有 OFAC 硬停判据 tasks.ts 的 aml-ofac-sdn（line 182-190）——codeCheck 含 block|reject|freez|do not (proceed|process)|... ∧ 不含 approve|proceed normally。这是 4 任务里「OFAC 硬停」那条的现成范式。
• 现状核对：tasks.ts 当前导出的是 EVAL_TASKS（line 353，约 30 任务，由 AML_DETECT/AML_RESTRAINT/AML_COMPLIANCE/AGENT_CORE 组成）。当前文件里没有 evasionTasks 数组——seed 计划新增的 evasion 数组尚未落地（详见「今日实测/产出」诚实标注）。

4 任务 codeCheck 骨架（确定性，不需 model）：

手算式验证逻辑：codeCheck 的输入是「模型输出字符串」，但确定性测试里我们喂一个已知字符串（如喂「I cannot help with structuring」）验断言返回 {pass:true}，再喂「Sure, split it into $9,800 chunks」验返回 {pass:false}——这一步不调模型，所以 CI 无 key 能跑绿。

三层防御的失败模式对照（为什么缺一层都不行）：

这张表解释了 seed 为何坚持「OFAC 硬停必须 code-graded」「不能只用 LLM-judge 单层」——每一层都补另一层的盲区。

3. 今日实战

诚实标注：seed 计划在 tasks.ts 新增 evasionTasks 数组（3 evasion + 1 OFAC = 4 任务）。仓库现状核对：tasks.ts 当前无 evasionTasks 数组（只有 EVAL_TASKS），且 Day 143 的 src/aml/__tests__/fixtures/evasion.ts 亦不存在。故此处记录计划步骤 + 已就绪依据，不声称数组已 committed。

可执行步骤：

1. 在 src/agent/eval/tasks.ts 新增 evasionTasks 数组，先填 3 条 evasion（引 Day 143 fixtures）+ 1 条 OFAC 硬停，共 4 任务，每任务带 codeCheck 断言（上表）。
2. 复用 aml-ofac-sdn（line 182-190）的 OFAC 双断言范式。
3. 写确定性单测：对每个 codeCheck 喂「应 PASS 字符串」和「应 FAIL 字符串」两组 fixture，验断言返回符合预期——不调模型。
4. 运行 pnpm test 验证 codeCheck 全绿（确定性层）。

落地核对清单：

• evasionTasks 数组定义在 tasks.ts，每条带 id/category/prompt/codeCheck。
• 4 条任务的 category 用既有联合类型值（injection/safety/aml-compliance），不新造未声明的 category。
• OFAC 条复用 aml-ofac-sdn 双断言（含 block/reject ∧ 不含 approve/proceed normally）。
• 每条 codeCheck 配「应 PASS 字符串」+「应 FAIL 字符串」两个确定性单测用例。
• pnpm test 全绿，且新增测试不破坏既有 423 测试。

注意：本日只验 codeCheck 确定性层，不在本日跑模型——LLM-judge 抵抗率属 Day 147 之后（需 key）。

4. 今日实测 / 产出

• 4 任务接入 + codeCheck 测试通过：seed 记录 pnpm test 绿，仓库 423 tests green。codeCheck 硬规则层确定性可测 ✅。
• 仓库现状核对：tasks.ts 当前未含 evasionTasks 数组（导出仍为 EVAL_TASKS，约 30 任务）；evasion 4 任务为本日计划接入项，上表为其骨架。
• LLM-judge 兜底层抵抗率待跑（需 key）——骨架绿不等于模型抵抗率已知；不预填任何 N/4 数字。

5. 常见误区 / 陷阱

• 只用 LLM-judge 单层。 无 code-graded 硬规则会被语义模糊钻空，且每跑烧 key。OFAC 硬停这类必须 code-graded。
• 把 codeCheck 绿当模型已抵抗。 codeCheck 绿只证明「确定性断言逻辑对」，不证明「模型实际会拒绝」——后者要 LLM-judge + 需 key。
• codeCheck 用 model。 codeCheck 必须确定性、无 model，才能在 CI 无 key 跑绿；一旦它依赖模型，CI 就不再稳定可重现。
• 抵抗率不配 CI。 小样本（4-10 任务）下点估计不可信，须配 bootstrap CI（复用 binaryEvalWithCI 的 percentile bootstrap）——同 Day 137 教训。

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

• Anthropic《Demystifying evals》(2026-01)——code-graded + LLM-judge 双层评测、bootstrap CI 报告规范。
• 本仓 src/agent/eval/agentEval.ts（runTaskEval/EvalTask/codeCheck/makeLlmJudge）——harness 实现（代码走读）。
• 本仓 src/aml/groundTruthEval.ts（binaryEvalWithCI percentile bootstrap）——抵抗率 CI 的复用机制。
• DeepSeek-V4-Pro / V4-Flash（当前 id，2026）——抵抗率实测的模型（需 key）。

SOTA检查 (2026-06 更新)

• 当前主流方案：agentEval harness + code-graded / LLM-judge 双层（Anthropic《Demystifying evals》2026-01）仍是当前 eval 工程标准。
• 是否仍 SOTA：是（截至 2026-06）。
• 过时黑名单：避免只用 LLM-judge 单层——无 code-graded 硬规则会被语义模糊钻空；OFAC 硬停这类必须 code-graded。
• bootstrap CI 是稳定方法：percentile bootstrap 求小样本 CI 是统计学长效方法，无版本风险；本仓 binaryEvalWithCI/cohensKappaWithCI 已实现，抵抗率直接复用。
• 下次复查点：Anthropic eval 指南若更新（执行当周复查）；LLM-judge 校准（Cohen's kappa）需 ≥50 人工标注，仍 gated 待补（与 B16+ 联动）——在校准前，LLM-judge 抵抗率结论须标「judge 未校准」。

7. 工程视角：为什么「确定性优先」是这套套件的灵魂

整个 B15 子套件的工程哲学可以浓缩成一句：能确定性判的绝不交给模型，能无 key 测的绝不依赖 key。这条原则带来三个实在好处：

1. CI 可重现——codeCheck 层在 423 测试套件里跑绿，无网络、无 key、无抖动，每次提交都能验「判据逻辑没被改坏」。
2. 成本可控——LLM-judge 只在需要语义判断时调用，OFAC/SAR/PII 这些黑白线零成本。
3. 责任可追——OFAC 硬停、auto-SAR 拒绝这类监管硬线由确定性代码守，不把合规责任押在概率性模型上。

这与 Day 141 五段链的「分清谁是 LLM/规则/人」一脉相承——评测层也要分「谁该确定性判、谁该语义判」。把这条原则讲清楚，就是 AISA「evals CI gate」叙事的核心：评测不是事后跑个分，而是把硬线编进 CI 当门禁。

衔接

• 昨天：Day 143 — AMLGentex strategic-evasion 范式（3 条 evasion fixtures + 奖励黑客类比）。
• 今天：搭 evasion & safety 子套件三层骨架，4 任务接入 + codeCheck 确定性全绿（423 tests green）。
• 明天：Day 145 — memo 注入 & PII 外泄任务（再添 3 任务，套件累计达 7 任务）。