智能体的线上实验

E16

运维 · 评估与可观测性

智能体的线上实验。

要看清任务成功率三个百分点的提升，在算上任何智能体特有因素之前，每组就已经需要约 3,700 次会话，而按用户聚类通常还要再乘三——所以多数团队为一次提示词改动跑的那个 A/B 测试，不是一个弱实验，而是一次配了看板的抛硬币。解法几乎从来不是加流量，而是随机分组时随机的是用户而非请求、挑一个方差你付得起的决策指标，并在诚实的答案是「带护栏的灰度发布」时承认它。

STEP 1

在写变体之前，先把样本量算出来。

本页所有论点都源自一次三十秒就能做完、却几乎从来没人做的计算。对一个二元结果——任务成了或没成——在 80% 检验效能与 5% 双侧显著性水平下，每组所需的会话数是：

n ≈ (z(α/2) + z(β))² × 2p(1-p) / δ²
  = (1.96 + 0.84)² × 2 × 0.70 × 0.30 / δ²

  δ = 0.03  (70% → 73%)   n ≈ 3,700 sessions per arm
  δ = 0.05  (70% → 75%)   n ≈ 1,300 sessions per arm
  δ = 0.10  (70% → 80%)   n ≈   330 sessions per arm

三件事随即成立。小效应是买不起的：效应减半，看清它的代价就翻两番，所以一个你认为值两个百分点的改动，本来就不是线上测试能确认的东西。一个每天跑 200 次会话的线上智能体，要分辨三个百分点，每组大约需要五周——而这五周里你会换掉模型、提示词和一个工具。如果你的结果是由裁判打分而非直接观察到的，那么裁判与人类标注之间的分歧还会在此之上再加一层方差，这正是质量回归检测背后的同一套算术。

先把数算出来，大多数实验在开跑前就已见分晓——不是被结果决定的，而是被「这个结果究竟有没有可能出现」决定的。

STEP 2

随机分的是用户，不是请求。

按请求随机分组很诱人，因为它把样本量最大化了；而对智能体来说，它在三个具体的地方是错的。智能体带记忆，所以某个用户落在实验组的那次会话，会改变对照组接下来看到的东西。用户会适应——一个发现智能体很擅长处理多段式请求的人会开始那样发问，而这种行为明天会跟着他进入他被分到的任何一组。还有，一个任务经常横跨好几次会话，按请求分配会把一份活儿劈进两组，于是两边都没量准。

请在「记忆与人」所在的那个层级上分配：用户；面向企业的智能体则是租户。然后老老实实付聚类的代价，因为同一用户的会话之间是相关的：

design effect = 1 + (m - 1) × ICC

  m   = sessions per user in the window   (say 20)
  ICC = within-user correlation           (0.05-0.15 is typical)

  deff = 1 + 19 × 0.10 = 2.9
  3,700 sessions per arm  →  ~10,700 sessions  ≈  535 users per arm

把聚类数据当作独立数据来分析，是智能体实验报出「它并不拥有的显著性」的头号方式——这么做会把标准误按设计效应的平方根左右缩小，也就是凭空造出一个结果。如果每组的独立用户少于几百个，再多的会话量也救不了这个测试；而按租户分配还有它自己的算术：十家企业客户根本没法随机分成两组，这也是为什么多租户智能体通常需要租户内设计，或者干脆不做实验。

STEP 3

按方差挑出唯一一个决策指标，其余都当护栏。

任务成功率是人人都想要的指标，也是最贵的一个，因为它是二元的、常常滞后，而且没有裁判或人工就往往观察不到。更便宜的指标并不是更差的指标——它们只是每次会话方差更小的指标，而这会直接换成更短的实验：

完成所需的步数或工具调用次数。连续、每次运行都能观测到，而且通常正是这次改动本来想改善的东西。
升级或转人工率。虽是二元，但往往离 50% 更远，而且它本身就是业务指标，不是业务指标的替身。
智能体产出与用户最终交付物之间的编辑距离。稠密、免费、由领域专家写下，理由见生产反馈信号。
单次会话内的重试与追问率。「这次改动让智能体变差了」最灵敏的早期信号，而且它以小时为单位变化，不是以周。

只挑一个作为决策指标并事先锁定。其余的一切——单任务成本、轨迹 p95 延迟、安全事件、拒答率——都是护栏：它们可以叫停发布，但不能事后被提拔为胜利条件。两个决策指标不是严谨的实验，而是两次宣布胜利的机会。延迟尤其必须在轨迹层面读，而不是调用层面，理由见度量智能体延迟。

STEP 4

偷看不是免费的，所以请把序贯检验买下来。

每个人都每天盯看板，一好看就收手。在固定样本量的检验下，这种行为不叫没耐心，它是在改变假阳性率：在名义 5% 的门槛上看五次，真实的犯错率会接近 15%，而一个一年这么跑二十个实验的团队，会发布好几项什么也没做成的改动。

只有三个诚实的选项。事先定死样本量，在到达之前不看决策指标——可行、不受欢迎，最好配一份自动报告，这样就不必去信任任何人的自制力。改用为持续监控而设计的序贯方法——分组序贯边界或恒定有效置信区间——它大约多花 10–20% 的样本，换来随时看、随时可提前收手的权利。或者让看板只服务护栏：安全与成本持续监控，决策指标封存不看。

在开跑前把停止规则写进工单里：指标、效应量、样本量上限或边界，以及每种结局分别怎么办——包括「没有差别」。一个没有事先登记「无效则如何」的实验，结局永远相同：改动照发，因为总有人做了它；而测试沦为一道形式，代价是你的五个星期。

STEP 5

降方差比加流量便宜。

如果拿不到更多用户，那就从已有的用户身上榨出更多信息。三种手法能从网页实验干净地迁移到智能体上，而在这里被严重低估：

实验前协变量（CUPED）。用每个用户在实验开始前几周的自身表现来校正他的结果。方差会乘上 1 - ρ²，其中 ρ 是实验前指标与实验期指标的相关系数；ρ 只要有 0.5，就能砍掉四分之一的样本需求。智能体的用户周与周之间自相似得惊人，所以 ρ 常常还更高。
分层。在任务类型、租户规模或语区之内做随机分组，而不是在所有东西之间。一条 20% 是难任务、80% 是琐碎任务的混合流量，其方差大半在配比上，而不在处理效应上。
与线上测试并行的配对离线回放。让两个变体跑在同一批录制轨迹上，用同样的桩数据与随机种子。它回答的是另一个问题——它看不见用户的适应——但它用配对数据回答，成本只是零头，这正是在线评测与离线评测所描述的分工。

要顶住不去用大家最先想到的第四种手法：把人群收窄到效应看起来变大为止。只在最活跃的用户上测，确实能更快拿到显著性，而它显著的那个人群，并不是你要发布给的那个人群。

STEP 6

当实验买不起时，就跑带护栏的灰度发布，并且直说。

大多数智能体团队的流量，撑不起对大多数改动做一次效能充分的检验，而正确的反应是别再假装了。带护栏的灰度发布是另一件工具，它主张的是另一件事：它并不确立这次改动有帮助，它确立的是这次改动没有明显造成伤害。

先用离线评测集设闸——这是唯一真正在测量质量的一步，也是评测集才是真正规格说明的原因。
让新变体对着线上流量做影子运行但不对外提供服务，比较的是轨迹而不是结果。
按 1% → 5% → 25% → 100% 放量，每一档都要长到足以覆盖一个完整的、任务类型有周期性的星期。
自动回滚只挂在护栏上：错误率、升级率、单任务成本、p95 延迟、安全事件。其机制属于发布与版本管理，那个开关属于功能开关。
在变更记录里写明这是一次灰度发布，不是一次测试。半年后总会有人引用「我们测出来的那 4% 提升」，而那时必须能查到：从来没有过这样一次测量。

下一次线上测试之前，按顺序做这四件事。一：按你真正预期的效应量和你真实的日流量，算出所需的 n，并得出这个测试能结束的日历日期。二：如果那个日期在三周之后，就停手——把它改成带护栏的灰度发布，把省下的时间花在评测集上。三：如果买得起，就按用户 ID 随机分组，事先登记唯一一个决策指标和一条停止规则，并列出你的护栏。四：在到达样本量上限之前，看板只看护栏。这套纪律不是统计学上的挑剔——它是那个让你不至于跑完一个五周、其结果本就注定读不出来的测试的东西。

延伸阅读：评测方差与统计效能把同一套算术用在离线侧，模拟用户讲每个多轮数字里量到的第二套系统，评估的成本讲这一切要吃掉多少。