AI 大模型故障：同样的问题回答不稳定：temperature 参数该降到 0.2 还是调高

一、问题的真实边界：什么叫“回答不稳定”

在讨论 temperature 之前，必须先定义“不稳定”。工程现场至少有四种被混为一谈的现象：

1.1 语义等价但措辞不同

模型三次都答“北京”，但一次说“中国的首都是北京”，一次说“北京”，一次说“首都为北京”。这类差异对用户几乎无感，却会让基于字符串匹配的自动化测试大面积飘红。本文评述：把这类差异当成故障，是评测口径的问题，不是模型的问题。

1.2 语义冲突

同一问题一次答“可以”，一次答“不可以”。这是真正需要处理的故障，通常来自采样在决策边界附近的抖动，或上下文里存在互相矛盾的线索。

1.3 格式漂移

JSON 字段名大小写不一致、多出一个 markdown 代码块围栏、日期格式在 2024-01-01 与 Jan 1, 2024 之间跳变。这类问题对下游解析器是致命的，但根因往往不在 temperature，而在 prompt 约束强度与解码约束（如 JSON mode、grammar-constrained decoding）。

1.4 长尾幻觉

十次里九次正确，第十次编造了一个不存在的引用。这类低频故障最危险，因为它不会被小样本测试捕获，却会在生产环境里持续制造事故。

这四类现象对应完全不同的成因与处置手段。把它们统一归因于“temperature 太高”，是当前大模型工程中最常见、代价也最高的误诊之一。

二、方差预算：把不稳定性拆成五项

笔者借用并改造了分布式系统里“误差预算”（error budget）的思路，提出方差预算（variance budget）框架：一次生成的总输出方差，可以近似分解为五个来源。这个分解不是严格的数学恒等式，而是一个工程诊断工具——它的价值在于让每一类方差都可被单独观测、单独压制。

这个表格是全文的分析主线。接下来的每一节，都在回答同一个问题：你观察到的抖动，落在哪一行？

本文评述：很多团队把 80% 的调参时间花在第一行，而生产事故的根因往往在第二、三行。这不是能力问题，而是可观测性问题——采样随机性肉眼可见，数值非确定性却需要专门实验才能暴露。

三、temperature 到底在做什么：从 softmax 到 logits 缩放

3.1 数学定义

给定模型输出的 logits 向量 z，标准 softmax 为：

p_i = exp(z_i) / Σ_j exp(z_j)

带温度 T 的变体：
p_i(T) = exp(z_i / T) / Σ_j exp(z_j / T)

T → 0 时分布退化为 argmax（贪心）；T = 1 时是模型原始分布；T > 1 时分布被压平，低概率 token 获得更多机会。这是教科书结论，但工程上真正重要的是它的二阶效应。

3.2 温度对熵的非线性影响

温度对输出分布熵的影响不是线性的。当 logits 本身已经非常尖锐（例如事实型问答中正确答案的 logit 远高于其他），把 T 从 1.0 降到 0.5 可能几乎不改变输出；而当 logits 接近平坦（例如开放式创意任务），同样的降温会剧烈改变采样结果。这意味着：同一个 temperature 值，在不同任务、不同 token 位置上的实际效果差异极大。

2024 年多项关于解码策略的研究指出，固定全局温度是一种粗糙的近似。模型在不同生成阶段的置信度分布差异显著——开头几个 token 通常高度确定，中段展开时不确定性上升，结尾收敛时又趋于确定。本文评述：这解释了为什么“全局降温”常常在压掉中段抖动的同时，也让开头结尾变得僵硬、重复。

3.3 为什么降到 0.2 有时反而更不稳定

这是本文最想强调的反直觉现象。它有三个可解释的机制：

1. 数值精度放大：当 T 很小时，z_i / T 的数值被放大，浮点误差在 exp 运算中被同步放大。在 fp16 推理下，这可能导致本应相同的 logits 产生不同的 argmax。
2. 重复与退化：低温使模型反复选择同一个高概率 token，触发重复惩罚后又被推向次优 token，形成振荡。
3. 与 top-p 的耦合：低温下分布尖锐，top-p 截断的候选集急剧缩小，一旦截断边界附近的 token 因数值误差互换，输出就会跳变。

换句话说，低温降低的是“采样熵”，但不必然降低“输出方差”。当方差主要来自数值非确定性时，降温甚至可能因为放大了数值敏感性而适得其反。

四、被忽视的元凶：数值非确定性与批处理耦合

4.1 浮点归约顺序问题

GPU 上的矩阵乘法、softmax 归一化、LayerNorm 都涉及大规模求和。浮点加法不满足结合律，(a+b)+c ≠ a+(b+c) 在有限精度下成立。cuBLAS、FlashAttention 等库会根据 batch size、序列长度、硬件型号选择不同的归约策略（split-K、tree reduction 等），导致同一输入在不同批次配置下得到数值上略有差异的 logits。

这些差异通常在 1e-3 到 1e-5 量级，肉眼不可见。但当模型处于决策边界——两个候选 token 的 logit 差小于这个量级——采样结果就会翻转。

4.2 批处理耦合实验

一个可复现的实验设计：

上表为模拟数据，用于说明实验设计思路，具体数值随模型、硬件、推理框架不同而变化。读者应在自己的环境中复现。本文评述：如果你的服务是动态 batching 的，那么“同一问题”在不同时刻实际上走的是不同的计算路径——这才是很多线上“偶发不一致”的真正来源。

4.3 推理框架层面的缓解

主流推理框架（vLLM、TensorRT-LLM、SGLang）都提供了一定程度的确定性选项，但代价通常是吞吐下降。工程上需要在“可复现”与“高吞吐”之间做显式取舍，而不是默认后者然后抱怨前者。

五、解码策略的交互：top-p、top-k、min-p 与重复惩罚

5.1 采样管线的实际顺序

大多数框架的采样顺序是：logits → 重复惩罚 → 温度缩放 → top-k 截断 → top-p 截断 → 归一化 → 采样。顺序不同，结果差异巨大。很多“调 temperature 没用”的案例，真实原因是温度缩放发生在截断之后，或者重复惩罚在温度之前改变了分布形状。

5.2 top-p 与 temperature 的耦合曲线

当 temperature 降低时，分布变尖，达到相同 top-p 阈值所需的累积概率对应的候选集变小。这意味着降温会自动收紧 top-p 的有效候选集，两者不是独立旋钮。只调其中一个，往往得到非预期的组合效果。

5.3 min-p：2024 年后的新选项

min-p 采样以“最高概率 token 的概率乘以一个阈值”作为截断线，相比 top-p 更能适应分布尖锐度的动态变化。在高温下它保留更多候选，在低温下自动收紧。本文评述：min-p 的价值在于把“候选集大小”从绝对概率阈值改为相对比例，从而与 temperature 解耦得更彻底，这对稳定性调参是有利的。

六、诊断流程：五步定位方差来源

以下流程可直接落地为排查清单。每一步都设计为“可证伪”——如果结果不符合预期，说明方差来源判断有误，需要回到上一步。

第一步：固定 seed，重复 N 次

如果同 seed 同参数下输出仍不同，方差一定来自数值非确定性或批处理耦合，与 temperature 无关。此时调温度是无效劳动。

第二步：batch size 对照

分别用 batch=1 和 batch=8 跑同一批 prompt，比较输出一致率。若 batch=1 一致而 batch=8 不一致，问题定位在批处理。

第三步：logprob 漂移检测

记录每个生成 token 的 logprob。若同一输入两次运行的 logprob 差异超过 1e-3，说明数值层已经不稳定；若 logprob 一致但采样结果不同，问题在采样器实现。

第四步：温度扫描

在 T ∈ {0, 0.2, 0.5, 0.7, 1.0, 1.2} 上各跑 20 次，统计语义一致率。注意观察是否存在“低温反而更抖”的区间。

第五步：语义评测校准

用语义相似度或 LLM-as-judge 替代字符串匹配，重新计算一致率。很多“不稳定”会在此步消失。

笔者认为：这五步的顺序不能颠倒。先排除数值与批处理因素，再谈采样参数，否则会陷入“调了参数好像好一点但又说不清为什么”的循环。

七、调参路径：降到 0.2 还是调高，分场景决策表

回到标题的问题。答案不是二选一，而是取决于任务类型与方差来源。以下是可直接套用的决策表。

注意最后一行：有些场景下“不稳定”是特性而非缺陷。数据增强、红队测试、创意发散都需要模型给出不同答案。把这类场景的 temperature 压到 0.2，等于自废武功。

7.1 一个常被忽略的技巧：分段温度

对长文本生成，可以在不同阶段使用不同温度：开头（确定主题）用低温，中段（展开内容）用中温，结尾（收敛结论）回到低温。部分推理框架已支持按 token 位置或按步骤动态调整采样参数。本文评述：这是把“方差预算”从静态分配变为动态分配的自然延伸，值得在自研推理栈中优先实现。

八、评测口径：如何科学地衡量“稳定性”

8.1 三个层次的一致性指标

1. 字面一致率：完全字符串匹配。简单但对语义等价不友好，适合结构化输出。
2. 语义一致率：用嵌入模型计算余弦相似度，或用 NLI 模型判断蕴含关系。适合开放问答。
3. 决策一致率：只比较关键字段或最终结论。适合分类、抽取、判断题。

选择哪个指标，取决于业务对“不一致”的容忍边界。用错指标会让团队把大量精力浪费在无意义的优化上。

8.2 样本量与置信区间

用 10 次采样估计一致率，置信区间宽得没有意义。若目标是把一致率从 90% 提升到 95%，至少需要数百次采样才能区分。工程上建议：先用 50 次做粗筛，确认有改善后再用 500 次做验证。

8.3 LLM-as-judge 的偏差

用大模型做一致性裁判时，裁判模型自身也有采样方差。缓解方法：裁判用 temperature=0、固定 seed、并在 prompt 中给出明确的判定标准与示例。本文评述：用不稳定的裁判去评测不稳定的被测对象，是评测设计中的经典陷阱。

九、前沿预判：推理模型与自适应采样

9.1 推理模型的温度悖论

2024 年后出现的一批“推理模型”在生成最终答案前会先产生一段思维链。这类模型对 temperature 的敏感度与常规模型不同：思维链阶段需要一定多样性以避免陷入错误路径，而最终答案阶段需要收敛。多家厂商的官方建议是推理阶段使用较高温度、答案阶段使用较低温度，或干脆在推理阶段使用贪心+多次采样投票。

9.2 自适应温度

学术上已有工作探索根据当前分布的熵动态调整温度：熵高时降温，熵低时升温。这本质上是把“方差预算”做成闭环控制。本文评述：这类方法在理论上优雅，但工程上引入了新的超参数与不稳定性来源，短期内更适合研究而非生产。

9.3 确定性推理的回归

随着合规与审计需求上升，“可复现推理”正在从nice-to-have变成硬需求。可以预见，推理框架会在未来一两年内提供更细粒度的确定性开关，而 temperature 的角色会进一步退化为“多样性旋钮”，而非“稳定性开关”。

十、工程落地清单与代码骨架

10.1 落地清单

• 为每个任务显式声明 temperature / top-p / min-p / seed，写入配置文件而非散落在代码里。
• 对事实型任务开启确定性推理模式，接受吞吐损失。
• 建立“同 seed 复现测试”作为 CI 的一部分。
• 线上记录每次请求的采样参数与 logprob 摘要，便于事后归因。
• 评测用语义一致率而非字符串匹配，裁判模型固定 seed。
• 对创意型任务，明确把“多样性”写进验收标准。

10.2 评测脚本骨架

import hashlib
from collections import Counter

def run_once(client, prompt, temperature, top_p, seed):
    resp = client.chat.completions.create(
        model="your-model",
        messages=[{"role": "user", "content": prompt}],
        temperature=temperature,
        top_p=top_p,
        seed=seed,
        logprobs=True,
    )
    return resp.choices[0].message.content

def consistency(prompt, n=50, temperature=0.7, top_p=0.9):
    outs = [run_once(client, prompt, temperature, top_p, seed=42)
            for _ in range(n)]
    hashes = [hashlib.md5(o.encode()).hexdigest() for o in outs]
    counter = Counter(hashes)
    top_ratio = counter.most_common(1)[0][1] / n
    return top_ratio, counter

# 温度扫描
for t in [0.0, 0.2, 0.5, 0.7, 1.0, 1.2]:
    ratio, _ = consistency("你的测试问题", n=50, temperature=t)
    print(f"T={t}: 主答案占比={ratio:.2%}")

这段骨架刻意保持简单，便于嵌入现有测试框架。真实使用时建议把语义相似度替换掉 md5 哈希，并加入 logprob 漂移记录。

10.3 拓展学习资源

• Hugging Face 官方博客关于生成策略的系列文章：huggingface.co/blog/how-to-generate
• vLLM 文档中关于采样参数与确定性推理的说明：docs.vllm.ai
• OpenAI Cookbook 中关于可复现输出的讨论：cookbook.openai.com
• min-p 采样原始讨论与实现：github.com/menhguin/minp_paper

结语

“降到 0.2 还是调高”这个问题本身，隐含了一个错误假设：temperature 是稳定性的总开关。本文的全部论证都指向相反的结论——temperature 只是方差预算中的一个分配项，且往往不是最大的那一项。先做诊断，再调参数；先消除数值与批处理非确定性，再讨论采样策略。这条路径比任何单一参数值都更接近“稳定”。