Temperature 是产品决策，不是模型旋钮

每当一个新的 LLM 功能上线，总会有人问："我们该用多少 temperature？"答案几乎千篇一律："不知道，留着 0.7 吧。"然后对话结束，没有人再碰这个值。

这是一个用默认值做出的产品决策。Temperature 不只是控制模型听起来有多"随机"——它决定了用户是否信任输出、是否会重新运行查询、是否感到被帮助或被淹没。把它调好比大多数团队意识到的更重要；调错了也很难诊断，因为失败的表现看起来像是模型行为差，而不是配置差。

Temperature 实际上做了什么（以及没做什么）

Temperature 在 softmax 采样步骤之前对 logit 进行缩放。低值会锐化概率分布——最高概率的 token 占主导地位，输出变得可预测。高值会使分布扁平化——更多 token 变得合理，输出更加多样。

常见的说法是"高 temperature = 有创意，低 temperature = 有事实依据"，但研究持续表明这过于简单。2024 年一项关于叙事生成的研究发现，temperature 与新颖性的相关性很弱，与连贯性或一致性没有可靠关系。另一项关于问题求解任务的研究发现，0.0–1.0 范围内的 temperature 变化对准确性没有统计显著影响。Temperature 不会让模型更聪明、更有创意或更博学。它控制的是输出方差——模型将产生的可能输出分布的扩散程度。

这个区别很重要，因为方差有直接的产品后果。方差决定了用户是否会两次看到相同的答案、是否会发现意想不到的输出、是否需要仔细阅读还是可以快速浏览，以及系统感觉是权威的还是探索性的。

为什么方差是一个产品维度

考虑基于同一个基础模型构建的两个功能：

• 合规团队的法律文件摘要工具
• 营销团队的头脑风暴工具

合规团队需要低方差。他们使用该工具来确认理解、交叉检查自己的阅读、记录决策。如果同一份文件在两次运行中产生两个不同的摘要，他们就遇到了问题。他们需要相信输出足够稳定，可以分享和引用。高方差会主动破坏功能的价值主张。

营销团队需要一些方差。他们正在尝试产生选项——他们没有考虑过的标语、角度、框架。每次给他们相同的三个标语违背了目的。对于创意工作，不可预测性不是 bug；它是创造价值的机制。

这些不是假设性差异。它们直接转化为用户行为：

• 低方差减少决策疲劳。用户得到一个强有力的答案，采取行动，然后继续前进。这提高了以效用为中心的工作流中的任务完成率。
• 高方差创造更接近可变比率强化的效果。用户再次运行功能以查看还会出现什么。这增加了探索性工作流中的参与度——以及不适合探索场景中的用户沮丧感。
• 不匹配的方差会产生一类不会出现在准确性评估中的失败：功能产生正确但感觉不对的输出。

一个每次给出略有不同摘要的合规工具最终会被标记为不可靠，即使每个输出在技术上都是准确的。一个每次给出相同三个想法的头脑风暴工具将被放弃，即使这些想法真的很好。

信任校准问题

Temperature 对产品体验最重要的影响是它对用户如何校准信任的影响。

低方差输出感觉权威。模型对某个立场做出承诺并一致地重复它。这创造了专业知识的感知——在模型可能正确的环境中（结构化提取、有据可查的 Q&A）这很有价值，在不正确的环境中（细致的判断调用、快速变化的信息领域）则很危险。

高方差输出传达不确定性。当模型在不同运行中给出不同答案时，有经验的用户将其解读为"模型不确定"。这通常更诚实，但它将认知负担转移回用户。他们现在需要评估竞争性输出，而不是接受一个。

没有一种普遍更好。问题是你的输出方差是否与你的产品对用户的认知契约相匹配。当用户问法律 AI 某条款是否可执行，而模型在三次运行中给出三个不同答案时，用户正确地得出结论说他们不能依赖它——即使"正确"答案就在那三个输出中的某个地方。当用户问创意助手要活动概念，每次会话都得到相同的三个想法时，他们正确地得出结论说这个工具没有他们希望的那么有用。

需要注意的失败模式是：你的 temperature 设置产生的方差与用户对该任务类型期望的方差之间的错配。

常见错误

不理解默认值就接受它们。 大多数 API 默认值在 0.7–1.0 左右，为通用应用程序调整。这些是合理的起点，不是特定用例的最佳设置。大多数团队从不重新审视它们。

在所有功能中使用相同的 temperature。 一个在一个共享配置文件中设置 temperature 并将该设置用于代码补全、客户支持响应和内容生成的代码库，在没有意识到的情况下做出了产品决策。这三个功能有不同的方差要求。

跨模型系列复制设置。 Temperature 校准在不同模型间并未标准化。来自 GPT-4、Claude 和 Mistral 的 token 概率分布的差异方式，使得 0.7 的 temperature 在每个模型上的行为不同。在一个模型上运行良好的设置需要在另一个模型上独立验证。

将低 temperature 视为可靠性修复。 处理不一致输出的团队经常降低 temperature，希望它能稳定行为。有时有帮助。更多时候，不一致是由模糊的提示词、不充分的上下文或知识边界违规引起的——temperature 无法解决这些问题。在一个损坏的提示词上降低 temperature 会使输出一致地损坏。

假设 temperature=0 意味着确定性。 Temperature=0 在每个步骤选择最高概率的 token，这大大减少了方差，但不能消除它。GPU 上的浮点运算是非结合性的。专家混合模型根据批次组成非确定性地路由 token。OpenAI 的文档指出系统可能会悄悄提高 temperature 以避免病理性重复循环。Temperature=0 是走向一致性的第一步，而不是保证。

设置 Temperature 的决策框架

首先对功能的主要功能进行分类：

提取和分类（文档中的实体、类别、结构化字段）：使用 0.0–0.2。正确答案存在；方差是纯噪声。

事实性 Q&A（有文献答案的问题、摘要、翻译）：使用 0.2–0.4。一些措辞变化是可接受的，但语义内容应该稳定。

对话和支持（客户服务、互动 Q&A、聊天机器人）：使用 0.5–0.7。自然语言多样性提高感知温暖度，不引入不可靠性。

有约束的生成（来自模板的电子邮件、有特定要求的代码、有风格指南的解释）：使用 0.4–0.7。足够的方差以避免机械输出；足够的约束以保持目标。

开放式生成（头脑风暴、创意写作、营销文案探索）：使用 0.8–1.2。方差就是产品。在大多数模型上超过 1.0 时注意连贯性退化。

这些范围是起点，不是规则。模型特定的校准总是比通用指导更重要。在承诺某个设置之前，在几个 temperature 设置下测试你的特定模型在你的特定输入上的表现。

正确测试 Temperature

temperature A/B 测试的核心挑战是 LLM 输出具有高固有方差，这意味着你需要比预期更大的样本量才能达到统计显著性。在运行实验之前，进行功效分析。在运行任何测试之前决定"更好"意味着什么指标——任务完成、重新运行率、满意度分数和任务用时都衡量不同的事情，可能指向不同方向。

针对代表性的真实生产输入，至少运行几个 temperature 值（0.0、0.3、0.5、0.7、0.9）。对于每个值，评估输出本身和它们产生的用户行为。衡量用户是否重新运行功能（低 temperature 上的高重新运行可能表示不信任；高 temperature 上的高重新运行可能表示功能作为选项生成器正在工作）。

一个实用的捷径：在你当前的 temperature 下生成多个输出，比较它们的语义相似性，并问问你看到的方差是否是你想让用户体验到的方差。如果输出紧密聚类，用户永远不会注意到方差。如果它们有意义地分歧，用户会注意到。

向用户展示方差

一旦你选择了为你的功能产生适当方差的 temperature，考虑是否要明确地展示这种方差。

对于某些方差是预期的且有价值的功能，展示多个候选输出通常比展示一个更好。给用户两三个选项让他们选择。这将方差从不一致转变为能力。它也改变了信任动态：不是用户可能质疑的一个权威答案，而是呈现一个选项空间并将用户定位为决策者。

对于方差存在但不应该可见的功能，以机械方式构建一致性。缓存对相同或接近相同输入的响应。使用结构化输出来约束响应的形状。添加一个验证步骤，检查当前输出是否与相似输入的最近输出有意义地偏离——如果偏离则重新生成。

对于你需要确定性的功能，构建明确的测试。不要假设 temperature=0 就足够了。记录生产输出并定期对相同查询的输出对进行采样以衡量它们是否匹配。如果不匹配，你有一个 temperature 无法解决的方差问题。

当模型更新破坏你的 Temperature 校准时

一个被低估的失败模式：当你的 LLM 提供商更新底层模型时，你的 temperature 设置的有效行为会改变。token 概率分布发生变化，意味着模型 v1 上的 temperature=0.7 与模型 v2 上的 temperature=0.7 产生不同的方差特征。

这是为什么模型升级后许多行为回归看起来莫名其妙的原因之一——提示词没有改变，temperature 没有改变，但输出分布已经改变。如果你的功能依赖于特定的方差水平，将模型升级视为重新验证 temperature 设置的触发器，而不仅仅是输出质量。

结论

Temperature 是控制用户体验的杠杆，而不仅仅是模型行为。它引入的方差塑造了信任、重新参与、决策疲劳，以及用户如何校准对你的功能的依赖。

做到这一点的团队不会将 temperature 视为可以留给默认值的技术细节。他们将其视为具有下游 UX 后果的产品选择——像任何其他产品变量一样进行测试，针对特定任务和用户上下文进行校准，并在模型发生变化时重新审视。

选择你想让用户体验的方差。然后测试你的 temperature 设置是否产生了它。