跨模型稳健性
Day 46 拿到了 v2v1 的 Δ，Day 47 校准了判这个 Δ 的裁判。但还有最后一个隐患没排除：这个 Δ 会不会只是 DeepSeek-V3 这一个模型的怪癖？
阶段: B5 · tool/context engineering + 指标树（Day 41-50） 标签: #robustness #cross-model #sign-agreement #qwen3
今日导引（由浅入深）
Day 46 拿到了 v2>v1 的 Δ，Day 47 校准了判这个 Δ 的裁判。但还有最后一个隐患没排除：这个 Δ 会不会只是 DeepSeek-V3 这一个模型的怪癖？
在 B1→B18 曲线上，今天（Day 48）做的是结论稳健性（robustness）的最后一道关卡——用第二个独立模型 Qwen3 在完全相同的任务集和判分器上重跑 v1/v2，看 Δ 的方向（sign）是否一致。
昨天解决「裁判可信」，今天解决「不是单模型偶然」，两者合起来才让明天（Day 49）的仪表盘有资格把这个 Δ 当作活数据展示。
这是 B5 这条「证明工具改进」证据链里最后一块、也是最容易被偷懒省掉的一块——很多团队只在一个模型上跑完就宣布胜利，正是跨模型复核缺位导致的 eval 过度自信。
今天的最小可判定产出：Qwen3 下 v1=?/M、v2=?/M 两数字 + 「方向是否与 DeepSeek-V3 一致」的判定（待 key）。
1. 机理精读
单模型 Δ 的脆弱性。 一个工具改进在某个特定模型上奏效，可能是因为它恰好契合了那个模型的预训练偏好或 prompt-following 习惯，而非工具设计本身真的更好。 LLM 对 schema 措辞、enum 取值、description 风格的敏感度因模型而异——DeepSeek-V3 偏爱的写法，换 Qwen3 未必。 所以单模型的 Δ 是一个与模型纠缠的量，不能直接外推为「v2 普遍更好」。 Anthropic《Demystifying evals》(2026-01) 的多模型复核思想正是为此：用第二个独立模型证伪「这只是该模型的怪癖」。
sign agreement 是比 Δ 大小更稳的信号。 跨模型比较时，我们不要求两个模型的 Δ 数值相等——绝对值受各模型基线影响，本来就会不同。 我们要求的是方向一致：若 DeepSeek-V3 上 v2>v1，Qwen3 上也 v2>v1，则「v2 改进方向」在两个独立模型上都成立，结论稳健性大幅提升。 这叫 sign agreement / 方向一致性。 反之，若一个模型上 v2 更好、另一个上 v1 更好，则说明这个工具改进是模型特异的，不能宣称是普适改进——这本身也是有价值的负结果。
为什么是「独立」模型而非同家族。 复核模型要尽量与首测模型架构/训练数据独立，才能真正证伪怪癖。 用 DeepSeek-V3 的另一个尺寸去复核 DeepSeek-V3，共享的偏好太多，证伪力弱。 Qwen3（Alibaba）与 DeepSeek（深度求索）是不同机构、不同训练 pipeline 的开源模型，构成有效的独立复核。这是选 Qwen3 的设计理由。
约束的传递：same task set + same grader 必须延续。
跨模型复核仍受 Day 46 的受控变量纪律约束——唯一允许变的旋钮是「模型」，任务集（tasks.ts 的同一 tool-use 子集）、判分器（Day 47 校准过的同一 judge）必须和 DeepSeek-V3 那轮完全一致。
否则方向比较又被混杂污染。
边界：方向一致 ≠ 永远更好。 两模型方向一致只把结论从「单模型成立」提升到「两独立模型成立」，仍不是「所有模型/所有任务成立」的全称证明。 它是稳健性的增量证据，不是终点。 收口（Day 50）会诚实地把结论限定在「这两个模型、这批任务、这个 judge」的范围内。
与「不要换错旋钮」的关系。 Day 46 教的是「同任务/同 judge，只换工具版本」；今天教的是「同任务/同 judge/同工具版本对比逻辑，只换模型」。 两者看似矛盾（一个固定模型、一个固定工具），其实是同一受控变量法在不同维度上的两次应用：A/B 固定模型测工具差，跨模型复核固定工具测模型间的方向一致性。 理解这一点就理解了 eval 实验设计的元原则——每张表只允许一个自变量。这条原则会一路贯穿到 B6 对真 MCP server 的端到端评测：换 transport、换 auth、换部署形态时，仍要一次只动一个旋钮，否则归因链立刻断裂。
2. 代码走读：跨 provider 调用与方向判定
跨模型复核不需要新代码，靠的是 runner 的 provider 可切换 + abCompare 的纯函数复用。
- provider 切换（
scripts/run-agent-eval.ts）：resolveProvider(provider)根据--provider解析 baseURL/默认模型/env key，ENV_KEY表里openrouter: 'OPENROUTER_API_KEY'。换模型只需换--provider/--model，其余EVAL_TASKS、judge 逻辑不变——这是「跨 provider 调用路径已 wired」的代码依据。 - 任务集不变：runner 永远
import { EVAL_TASKS } from '../src/agent/eval/tasks'，没有按 provider 分叉，保证 Qwen3 跑的是和 DeepSeek-V3 字面相同的任务。 - judge 一致：
const judgeModel = judgeId === modelId ? model : buildModel(...)——复核轮要显式指定与 DeepSeek-V3 轮相同的 judge 配置，维持 same-grader。 - 方向判定靠
abCompare（src/agent/eval/abCompare.ts）：对 Qwen3 的 v1/v2 两份报告再调一次abCompare，拿到 Qwen3 的deltaMean。比较两个模型的deltaMean符号：sign(Δ_deepseek) === sign(Δ_qwen3)即方向一致。abCompare是纯函数，对任何 provider 产的报告一视同仁。 - 报告归档：两轮报告都落
agent-evals/reports/run-<stamp>.json，文件名带时间戳，便于事后核对是同任务集（runner 用new Date().toISOString().replace(/[:.]/g,'-')生成 stamp）。 - dry-run 兜底：无 key 时 runner 打印
Would run ${EVAL_TASKS.length} tasks on "${modelId}"并return，所以 Qwen3 的真实两数字同样待 key。 - commit 溯源：runner 用
execSync('git rev-parse --short HEAD')把短 commit 写进报告，两个模型的报告各自带 commit/时间戳，事后能确证它们跑在同一份工具代码上——跨模型复核的可复现性靠这个落地。
sign-agreement 判定的四种结局
把两模型各自的 Δ 符号列成真值表，结论强度一目了然（Δ>0 记 v2 更好；这里用「v2 优于 v1」口径，与 deltaMean=A−B 的符号需对齐解读）：
| DeepSeek-V3 Δ | Qwen3 Δ | sign 一致? | 结论 |
|---|---|---|---|
| v2>v1 | v2>v1 | 是 | 稳健：改进方向在两独立模型成立，可写进收口 |
| v2>v1 | v1>v2 | 否 | 模型特异：v2 只对 DeepSeek-V3 好，不能宣称普适（有价值的负结果） |
| v1>v2 | v1>v2 | 是 | 稳健地说明 v2 反而更差——回退 v2 设计 |
| ≈0（CI 跨 0） | 任意 | — | 单模型本就不显著，跨模型无从谈方向 |
- 关键：我们比的是符号，不是数值。即便 DeepSeek-V3 上 +15 pp、Qwen3 上 +4 pp，只要都为正就算方向一致。
- 第 4 行提醒：若 Day 46 的 Δ 本身 CI 跨 0（不显著），跨模型复核也救不了——得先回去扩大任务集 M 把 CI 收窄。
3. 今日实战
- 确认 Qwen3 在 OpenRouter 的具体 variant id（如
qwen3-235b），执行当周用npm view/ OpenRouter 控制台重验。 - 对 v1 工具版本跑：
pnpm eval:agent --provider openrouter --model <qwen3-variant> --judge <同 Day46 的 judge>。 - 切到 v2，保持同 provider/judge/任务集，重跑得第二份报告。
- 用
abCompare()算 Qwen3 的deltaMean，与 Day 46 DeepSeek-V3 的deltaMean比符号，给出「方向一致 / 不一致」判定。 - 无 key 时：用离线 fixture 模拟 Qwen3 两份报告跑通
abCompare+ 符号比较逻辑，commit 占位；真实数字待 key。
4. 今日实测 / 产出
- 真实结果 「待跑（需 OPENROUTER_API_KEY）；可先用离线 fixture 跑通 harness 出 completion%+commit」。
- 产出 transcript：Qwen3 下 v1=?/M、v2=?/M 两数字 + 方向是否与 DeepSeek-V3 一致的判定。
- harness 跨 provider 调用路径已 wired（runner 的
resolveProvider+ 固定EVAL_TASKS）。 - 本日不臆造 Qwen3 通过数，也不把待跑升级成已完成。
5. 常见误区 / 陷阱
- 用已退役的 Qwen2.5 顶替 Qwen3：seed 明确禁止——复核模型必须是当周仍活跃的 Qwen3 variant。
- 要求两模型 Δ 数值相等：错；只比方向（sign），绝对值受各自基线影响本就不同。
- 复核时偷偷换了任务集或 judge：方向比较被混杂污染，复核失去意义。
- 把方向一致当成「v2 永远更好」：只是两独立模型成立，仍非全称证明。
- 首测 Δ 本就不显著（CI 跨 0）还硬比方向：方向无从谈起，应先回 Day 46 扩 M 把 CI 收窄。
- 用闭源旗舰当「独立」复核但不锁版本：模型静默升级会让复核不可复现，复核模型也要记录确切 variant id + 日期。
6. 学习资源（每条带 YYYY-MM）
- Anthropic, Demystifying evals — 2026-01（多模型复核 / robustness 段）。
- Qwen3 技术报告 / 模型卡（Alibaba）— 2025（2025 主线开源模型，2026-06 仍活跃）。
- 本仓代码：
scripts/run-agent-eval.ts（resolveProvider/ENV_KEY）、src/agent/eval/abCompare.ts、src/agent/config/providers.ts（provider 注册表）— 2026-06。 - DeepSeek-V3 模型卡（深度求索，首测模型基线）— 2025。
- OpenRouter 模型目录（跨 provider 模型 id / 价格，执行当周重验）— 2026-06。
SOTA检查 (2026-06 更新)
- 当前主流：跨独立模型的 sign-agreement 复核仍是 eval 结论稳健性的标准做法，2026-06 仍 SOTA。
- 是否仍 SOTA：是。Qwen3（Alibaba）为 2025 主线开源模型，2026-06 仍活跃，是有效的独立复核模型。
- 过时黑名单：用已退役的 Qwen2.5 顶替 Qwen3；用同家族不同尺寸冒充「独立」复核；单模型一次跑批就外推全称结论。
- 下次复查点：执行当周重验 OpenRouter 上 Qwen3 具体 variant id（如
qwen3-235b）是否仍可用、是否有新版本替代。
衔接
- 昨天：Day 47 — 判分一致性校准（κ≥0.6），保证 judge 可信。
- 今天：用独立模型 Qwen3 复核 v1/v2 Δ 方向是否与 DeepSeek-V3 一致，证伪「单模型怪癖」。
- 明天：Day 49 — 指标仪表盘雏形，把 Day46/48 的活数据聚合成可视化。