无法收敛的验证器循环

把验证器锁定为一次调用。 每一轮只跑一次 verifier,在 worker 看到判决和理由之前就把它们冻结,然后把这份冻结判决当作后续修改的真值。验证器没有在修改进行到一半时改主意的资格。这么做的代价是你失去了对边界拒绝"再核对一次"的能力,但收益是 worker 现在是在对着固定批评做修改,而不是在追一个移动的批评。这是最便宜的修复,而且消除了一整类病态振荡。

采样并锚定。 第一轮就把验证器并行跑 k 次去评第一稿,取多数判决和一个综合理由,把循环剩下的部分锚定到这一个判断上。你在前面付一点点 ensemble 成本,换来后续所有迭代都有一个稳定的靶。验证器的方差被吸收到第一轮里,而不是被涂抹到每一轮上。

分歧时上交裁判。 worker 和 verifier 照旧跑,但当 worker 已经修改两次而 verifier 仍然拒绝时,升级到第三个模型——一个 prompt 不同的裁判,或者一个更强的基础模型——它的判决是终审。这个裁判不在循环里。它是循环的下匝道。这把一个可能无界的振荡变成一个有界的三步流程,并且有保证的终止状态。

先把 spec 写出来再迭代。 在 worker 写任何东西之前,让 verifier 把接受标准发出来,作为一个显式的、结构化的产物——一份清单、一份评分量表、一份会触发拒绝的失败模式列表。把这份产物在整个循环里锁死。worker 现在是在对着一份稳定的 spec 做修改,而后续轮次的 verifier 是在对照它在第一轮发布过的同一份 spec 做检查,而不是每一轮重新推导一遍标准。这最接近人类 review 的工作方式:reviewer 先写需求,然后对照需求来判,而不是对照一种每轮都在更新的"感觉"。

注意这些模式有什么共同点。它们都打破了 worker 的行为和 verifier 的标准之间的逐轮耦合。它们都把验证器的随机性变成一次性成本,而不是每次迭代都付一份。它们都给循环一个能保持静止足够久、让"满意"成为一个有意义的状态的满足曲面。

没人真的算过的那笔成本账​

一个迭代上限为五、每轮拒绝率为六成的 verifier 循环,平均每个请求要花掉大约四个完整的 prompt-completion 周期,而且 prompt 每一轮都在长,因为 trace 在累积。朴素实现会在每次调用时把整个修改历史重发一遍,这意味着第五轮的输入 token 数大概是第一轮的五倍。再乘以每轮两个模型(worker 和 verifier),你为一个用户只看一次的输出付了十次模型调用,以及一个关于迭代次数二次增长的输入成本。在难任务类目下,每轮拒绝率更高,你在大部分请求上都会撞到上限,你的每个交付产物的有效成本不再是平均成本,而是上限次数乘以每轮成本。

这就是那些"自主"代理舰队周末账单 4,200 美元、月账单 87,000 美元故事背后的数学。验证器循环是今天生产代理架构里通往失控账单最干净的一条路,因为它有一个性质:系统看起来越有用(修改越多、核对越多、越尽职),它就越贵。除了迭代上限之外没有任何天然的断路器,而上限——如前所述——同时也是那个正在掩盖质量失败的东西。

成本仪表盘和质量仪表盘在告诉你关于同一个循环的不同谎言。成本仪表盘说循环昂贵但有界。质量仪表盘说置信度在上升。两者都没有告诉你:在难样例上,上限正在触发,而你在用户不知道的情况下交付了被拒绝的输出。

把收敛率当作一等公民的 eval 指标​

这种立场所要求的 eval 纪律,大多数团队都跳过了。搭一个小的 worker-critic 配对基准,故意做得对抗性强:那种 worker 和 critic 对"什么算好"的先验不一样的任务,那种 critic 的评分量表欠规范到两次 roll-out 会互不一致的任务,那种 worker 的自然风格会触发 critic 挑刺的任务。把循环跑通端到端。不光测最终接受率,还要测两件事。

一:循环撞上限的频率有多高?在你真实流量分布上,撞上限率超过 10% 或 20%,就是系统在告诉你它在你输入的相当一片子集上不收敛。把那一片当作它自己的产品问题,而不是当作长尾来处理。

二:跨 roll-out,最终输出的每任务方差有多大?同一个任务跑十次。如果循环在向质量收敛,十个 final 在实质上应当相似。如果它们差别很大——不同的结论、不同的建议、不同的代码——循环就不是在收敛;它每次都在从一个不稳定的接受区域里挑一个不同的点。用户看见的产物在那个区域里实际上是随机的,而你基于单次 roll-out 的 eval 在测一个你从未刻画过的分布里的一份样本。

大多数团队这两项都不测,因为架构本身呈现出的严谨外观——我们有 worker 也有 verifier,看那张图——已经替代了证明这种严谨真能兑现的纪律。

精修循环不是一个质量原语​

最深的那个架构觉悟是最难咽下去的。一个精修循环,本身,不是一个质量改进原语。它是一个没有收敛保证、由预算强制终止、接受标准跨调用漂移、最终输出由 tiebreaker 而不是由产物自身任何属性选定的搜索过程。把它当作一个质量门,和把测试运行器里一个五分钟的 timeout 当作"代码正确"的证据,是同一个错误。

只有当满足曲面独立于被评判的代理而保持稳定时,这个循环才会成为一个质量原语。那是循环周围的系统的性质——验证器冻结、spec 锁定、裁判升级、收敛率 eval——而不是循环默认就有的性质。worker-critic 循环默认的性质是:在产出进展的表象的同时消耗预算。

先把曲面建出来,再信任循环能在它上面找到不动点。一个团队上线了"迭代到满意为止"却没证明那个满足曲面是稳定的,他们交付的就是一次对极值可能根本不存在的空间的搜索——而那个上限,是阻止这次搜索永远跑下去的唯一东西,这意味着上限,而不是 verifier,才是真正决定你用户最后拿到什么的仲裁者。