[!info] related notes

• 所属 MOC: agent-evals-moc、testing-moc
• 前置概念: agent-configuration-bundle
• 关系笔记: bodysense-diagnosis-model-governance-eval-loop

Agent Configuration 的 Interaction Effect

一句话定义

Agent Configuration 的 Interaction Effect 指：某个组件的效果依赖另一个组件取值，组合表现不能由各组件单独表现简单相加预测。

为什么 bundle 回归不能直接归因

如果一次同时发生：

Model A → Model B
Prompt v7 → Prompt v8

然后生产 rejection 从 1% 上升到 5%，目前只能确定观测到的拒绝率上升。还需检查流量构成、样本量、评判口径和同期环境变化；拒绝危险请求增加也未必是质量回归。

即使受控比较确认新 configuration bundle 有回归，也不能仅凭前后对比判断是 Model B、Prompt v8，还是二者组合造成。

最小 2×2 实验

              Prompt
             v7     v8
Model A     A+v7   A+v8
Model B     B+v7   B+v8

这允许分别观察：

• Model main effect；
• Prompt main effect；
• Model × Prompt interaction。

例如：

A+v7 = 1.0%
A+v8 = 1.1%
B+v7 = 1.2%
B+v8 = 5.8%

在拒绝率的加性尺度上，交互对比为 (5.8 − 1.2) − (1.1 − 1.0) = 4.5 个百分点：Prompt v8 的变化在 Model B 上更大。这是交互效应的点估计；没有样本量、重复运行和不确定性估计，不能据此宣称统计显著，也不能断定“B 一定坏”或“v8 一定坏”。

交互依赖所选尺度：百分点差、相对风险与 log-odds 上的“无交互”并不等价。

实验控制

为了让归因更可信，应尽量保持：

• 同一批 paired cases；
• 其他 configuration 字段固定；
• 每个 variant 有稳定 identity；
• 必要时随机或交错运行顺序；
• Judge blind to variant identity；
• 对随机模型使用足够 repeat runs；
• 固定指标定义，报告样本量与不确定性；同一 case 的重复输出不当作独立 case。

Offline / Shadow / Canary 的不同用途

Offline / Shadow
→ 更适合拆变量、做因果诊断和 variant comparison

Canary
→ 更适合验证最终 Champion vs Challenger bundle 的真实生产表现

复杂 factorial debugging 不应直接在真实用户路径上随意展开。

与 Capability Policy 的关系

某个组合失败，不足以证明某项 capability 应从 PREFERRED 升级为 REQUIRED。先识别 interaction、具体 model failure 或 prompt failure，再决定是否真的存在 capability-class 级证据。

学习检查

• 新版本拒绝率上升，为什么还不能判定质量回归？
• 上例 4.5 个百分点的交互对比如何得到？为什么不是 4.5% 的相对增长？
• paired cases 与重复运行分别控制什么变化？

常见误解

• 组件单测都通过，组合一定通过：Agent 行为高度依赖组件交互。
• 新版本回归就回滚最后改的组件：若同时变更多项，归因并不成立。
• factorial experiment 只用于学术统计：对 Model × Prompt × Policy 这种配置系统，它是非常实用的工程诊断方法。