采样参数继承：当 0.7 的温度从规划器泄露到验证器时

一个在 8% 的情况下会推翻自己答案的验证器（verifier）并不是一个表现不稳定的模型。这是一个由于框架默认采用继承机制而进入生产环境的采样配置 Bug。规划器（planner）需要 temperature=0.7 来头脑风暴子任务的分解。而验证器 —— 其全部工作就是针对答案是否符合评分标准给出低方差的“是”或“否” —— 却是通过同一个 harness 调用实例化的，并默默地沿用了相同的温度设置。没有人故意这么设置。甚至根本没有人去设置它。

这是你的技术栈中最昂贵却无人认领的参数。它在调用树中不断累积：验证器上方的总结器、下方的结构化输出提取器，以及包裹整个流程的重试循环，都像使用全局变量一样沿用着规划器的“保持创意”旋钮。这笔账会同时体现在三个地方：评估的不稳定性、Token 支出，以及资深工程师花半天时间对一个结果发现根本不是退化的“性能退化”进行二分法排查。

那些看似合理实则不然的继承模式

大多数智能体（agent）框架将模型配置作为构造函数参数暴露给单个客户端对象，然后将该客户端在调用树中传递。规划器智能体、验证器智能体和结构化输出提取器各自获得对同一个客户端的引用，这意味着它们都获得了相同的 temperature、top_p 和种子（seed）默认值。这种模式很方便 —— 你只需在应用程序的边缘配置一次模型 —— 而方便正是它在你不再需要它之后仍能长期存在的原因。

问题在于，“模型”并不是一个单一的角色。一个现代智能体至少包含四个不同的“发言者”，每个角色都有不同的采样需求：

• 规划器（Planner）：提议备选分解方案的规划器受益于多样性。0.6–0.9 范围的温度能产生多样性，让验证器可以从多个候选方案中选出优胜者。
• 验证器（Verifier）：根据标准对候选方案进行评分的验证器必须接近确定性。最近的研究表明，LLM 作为裁判（LLM-as-judge）的自洽性在 temperature=0.1 左右达到峰值，而不是 0.0，但任何超过 0.3 的设置都会引入翻转率（flip-rates），从而破坏验证步骤的价值。
• 总结器（Summarizer）：为下一步压缩工具输出的总结器需要一条中间路线：既要有足够的确定性以保证可重复性，又要有足够的灵活性来处理不寻常的措辞，而不至于截断为固定模板。
• 结构化输出提取器（Structured-output extractor）：为下游代码生成 JSON 对象的提取器需要 temperature=0 以及语法受限解码。除此之外的任何设置都会导致解析失败，重试循环会将 1% 的错误率转化为 1% 的尾部延迟峰值。

当继承成为默认行为时，所有四个角色都会获取规划器的设置。测试框架实现者的心理模型 —— “我配置了模型” —— 与运行时的现实并不相符。验证器并没有针对验证任务进行配置；它被配置成了最近一个调用者所需的模式，而最近的调用者通常需要的是创意。

为什么验证器的 Temperature 0 也不是标准答案

在第一次事故之后，人的本能是将验证器覆盖为 temperature=0 并认为 Bug 已修复。这只对了一半。温度为零是正确的“意图”，但最近关于 LLM 裁判的研究从两个具体方面使实现变得复杂。

首先，在现代推理系统中，temperature=0 并不能产生完全确定性的输出。服务端的批处理合成（Batch composition）改变了浮点运算的顺序，进而改变了 logit 值，即使在贪婪采样时也可能导致概率最高的 Token 发生翻转。“1000 次运行，1000 个不同的答案”效应已被详尽记录，而最近关于批处理不变内核（batch-invariant kernels）的研究表明，解决此问题的代价约占吞吐量的 60%。对于大规模运行的验证器来说，这就是你能达到的 SLO 与无法达到的 SLO 之间的区别。

其次，即使采样在数学上是贪婪的，单次样本评估也是脆弱的。每次调用仅给出一个“是/否”结果的裁判捕捉到了分布的众数，但没有告诉你任何关于分布离散度（spread）的信息。那些严肃对待这一问题的论文 —— 即那些在多个温度下运行相同比较并计算翻转次数的论文 —— 发现裁判的最佳温度更接近 0.1 而非 0。因为轻微带噪的采样能暴露模型信念确实处于 51/49 的情况，而这些情况应该被标记出来，而不是默默地倾向于其中一方。

正确的验证器配置不是“温度为零”。而是“低温度、多次采样，并在生产环境中观察翻转率指标”。如果翻转率超过阈值（例如 5%），验证器会升级到更强大的模型或人工审核。这将采样参数从一个你设置一次就了事的旋钮，变成了一个你可以观察的信号。

将按角色划分的采样配置作为框架原语

架构层面的修复方案是停止将采样参数视为模型客户端配置，而开始将其视为角色配置。一个角色配置集（Role Profile）捆绑了 temperature、top_p、presence_penalty、frequency_penalty、max_tokens、可选的 seed，以及与结构化输出配套的语法或 schema 约束。当调用方调用 planner（规划器）时，它向框架请求的是 planner 配置集，而不是模型客户端。

加载中…