确定性预算：将随机性视为按层面的分配，而非全局开关

Temperature 之争是 AI 工程中最具宗教色彩的争论，也是最没效率的争论之一。每个团队都会形成两个阵营：决定论者希望将所有地方的 Temperature 都固定为 0，因为他们无法调试不稳定的系统；而创意论者则希望调高它，因为这样输出结果感觉更“有灵性”。两者都错了，因为他们都在错误的层面上回答这个问题。Temperature 不是一个全局设置。它是一项预算——就像任何预算一样，它应该被分配，而不是被宣告。

高效的框架很简单：系统中每个模型调用都有其目的，随机性要么在那个层面（surface）发挥作用，要么就不该存在。决定下一个调用哪个工具的规划器（planner）无法从变化中获益；选错一个工具就是调试噩梦，而且没有任何创意上的好处。如果一万个用户看到的摘要措辞都一模一样，那么为他们总结搜索结果的响应合成层很快就会显得呆板——SEO 团队最终会标记这些样板内容。一个让模型提出备选方案供人类选择的头脑风暴层，在 Temperature 为 0 时表现反而 更糟；多样性本身就是其核心功能。

如果你无法清晰地说明随机性在特定调用位置的作用，你就不应该为此付费。

层面图谱：随机性在何处发挥价值

第一个实际行动是停止将你的系统视为“对 LLM 的调用”，而是将其视为一系列截然不同的“层面（surfaces）”，每个层面都有其特定的随机性目的。一个有用的分类法如下：

• 路由（Routing）。 模型从 N 个选项中选择一个——一个工具、一个子智能体或工作流中的一个分支。Temperature 应该是 0（或尽可能接近提供商允许的最小值）。这里的差异性纯粹是成本：一个不稳定的路由器会产生跨越三个日志和四个工程师的调试追踪。
• 解析（Parsing）。 模型被要求提取结构化字段、规范化数值或输出 JSON。Temperature 应该是 0。结构化输出调用中的任何非零设置都是一个潜在的错误，其唯一的表现形式就是两个月后出现不稳定的解析器。
• 合成（Synthesis）。 模型根据检索到的上下文进行总结、改写或撰写响应。Temperature 0.2–0.5 通常是合适的。这个范围既能保证对源内容的忠实度，又能避免在成千上万个相同查询中出现机器人般的复制粘贴感。
• 生成（Generation）。 模型生成完整的创意输出——营销文案、文章大纲、代码骨架。Temperature 0.5–0.8。其任务是实现合理的差异化；纯粹的贪婪解码（greedy decoding）会让作品变得平庸乏味。
• 探索（Exploration）。 模型提出备选方案供人类选择，运行 N 个样本以实现自洽性（self-consistency），或为下游选择器提供素材。Temperature 0.7+ 并采用有意的采样。多样性就是全部意义；如果像对待路由调用那样对待这些调用，就会让“AI 头脑风暴”功能感觉像是一个套着聊天机器人外壳的同义词词典。

请注意，“创意写作”并未作为一个单独的类别出现在此列表中。营销文案和头脑风暴层面从外部看似乎相同，但具有不同的随机性目的——前者希望在不同用户之间产生合理的差异化输出，后者则希望在单个用户的会话中产生有意的多样化备选方案。将两者混为一谈是最常见的偏差。

解析层面：非零 Temperature 即 Bug

对于解析层面，规则是明确的：如果响应将由代码解析，Temperature 应该为零。从业者对此争论不休，因为他们听过一些违反直觉的结论，即对于某些复杂的、包含多个部分的 schema，少量的 Temperature 实际上能提高字段完成率——严格的贪婪解码器可能会在所有字段输出之前就提前终止，尤其是当 Prompt 包含许多部分时。

面对这种情况，正确的做法是修复 schema 或 Prompt，而不是调高 Temperature。非零的解析器 Temperature 只是解决了表象，却制造了另一个问题：现在你的结构化输出是非确定性的，这意味着你的下游解析器必须处理更广泛的输入，从而导致测试不稳定、间歇性回归，以及一类只在没有工程师盯着的生产环境中才会出现的 Bug。用采样来解决“模型截断字段”的问题，是把一个确定性问题变成了概率性问题。

当确实无法修复 schema 或 Prompt 时——例如由于供应商 JSON 模式、缺乏约束解码、复杂的多个部分输出——正确的做法是将调用封装在“带有验证的重试（retry-with-validation）”中，而不是调高 Temperature。重试产生的是一个收敛于确定性结果的确定性调用；而调高 Temperature 产生的是一个无处收敛的概率性调用。

鲜有人提及的成本视角

更高的 Temperature 与更长的输出相关联，因为模型会变得漫无边际。一个在 0.9 Temperature 下运行的“创意”合成层，比在 0.3 下运行的相同层消耗的输出 Token 要多得多，而且在留存评估（held-out eval）中测得的质量并没有提升。这是从业者在成本模型中很少体现的成本视角，因为它跨越了两个团队的边界：Prompt 团队负责质量，平台团队负责 Token，而 Temperature 与输出长度之间的关联恰恰处于这个真空地带。

让这种关联变得可见。绘制每个层面的输出长度与 Temperature 的关系图。你会发现至少有一个层面模型处于漫游状态——通常是头脑风暴或合成调用，有人为了解决质量问题曾调高过 Temperature，但在重写 Prompt 后却从未将其重置。将该层面的 Temperature 从 0.9 降至 0.5，通常可以在不产生可衡量质量下降的情况下，削减 20–30% 的输出 Token。每月数百万次的调用叠加起来，仅仅通过一个配置更改就能省下真金白银。

相反的一面，更廉价的操作则更有趣。在路由调用中调高 Temperature 在即时 Prompt 成本上是“免费”的——相同的输出长度，相同的输入长度——但成本会体现在下游：当调用了错误的工具且智能体不得不回退时产生的重试流量。昂贵的随机性，是那种在调用处毫无成本，但在系统层面代价巨大的随机性。

采样方差污染了你的评估集

加载中…