超参数幻觉:为什么 Temperature 和 Top-P 应该最后才调
当 LLM 的输出感觉不对劲时,工程师会本能地去调 temperature。这是调试手册里最早的动作之一——调低它以获得更强的一致性,调高它以获得更多创意。这感觉很有效,因为改动简单且效果立竿见影。但这几乎从来都不是正确的做法。
Temperature 和 top-p 只是输出质量最后 10% 的因素,而不是前 90%。真正决定模型成败的变量是上下文质量、指令清晰度和模型选择——依次排列。在一个有问题的提示词之上再调整采样参数,就像给一道还没煮熟的菜调味一样。根本问题并没有消失。
Temperature 实际上控制什么(以及它不能控制什么)
Temperature 是在 softmax 操作之前应用于模型 logits 的一个标量:softmax(z_i / T)。当 T < 1 时,它会锐化 概率分布,让最高概率的 token 更加占主导。当 T > 1 时,它会平坦化分布,让低概率 token 也有机会被选中。Top-p(核采样)的工作方式有所不同——它从累积概率超过某个阈值的最小 token 集合中采样——但效果类似:控制采样步骤中的方差。
这两种操作有一个共同点:它们都发生在模型已经完成全部工作之后。到采样运行时,模型已经对你的上下文完成了注意力计算,遵循(或未能遵循)了你的指令,并生成了下一个 token 的概率分布。Temperature 不会改变模型的理解。它只改变模型从已计算好的结果中随机选取的方式。
研究证实了这一直觉。在 0.0–1.0 范围内调整 temperature 对问题解决性能没有统计显著的影响。效果在 temperature 超过 1.0 时才变得明显,此时幻觉风险急剧上升,不同模型在不同阈值下表现出负面效应。在大多数从业者实际使用的范围内,temperature 对质量几乎没有影响——只影响方差。
优先级层次:上下文、清晰度,然后才是采样
真正能提升质量指标的变量,按大致影响顺序排列:
1. 上下文质量。 关于"上下文腐化"的研究表明,即使检索完美,随着上下文长度在模型声称的窗口范围内增加,模型性能会下降 13.9%–85%。模型无法过滤不相关内容——多余的 token 会将关键信息推出有效注意力范围。这意味着你的检索策略和上下文剪枝远比任何采样参数重要。如果你的输出不一致或偏离主题,最可能的原因是上下文噪声,而不是 temperature。
2. 指令清晰度。 在受控评估中,直接、具体的提示词比模糊的提示词产生的正确答案多 2.5 倍。仅靠提示工程——不换模型、不改其他参数——带来的准确率提升在不同任务上记录为 40%–156%。有从业者案例研究仅靠重写提示词就将准确率从 17% 提升到 91%。单独添加输出格式约束使准确率提升了约 15%。这些都不是边际收益。
3. 模型选择。 选择适合任务的正确模型,胜过在错误模型上进行任何超参数优化。2025–2026 年开源与闭源模型之间的收敛使这一选择更加关键,而非更少:各层级之间的性能差距已经缩小,但任务契合度的差距——将模型能力与你问题特定的推理或格式要求相匹配——并没有缩小。
4. 少样本示例。 上下文中的示例在各种模型规模下都能带来稳定的改进,尤其对于较小模型处理结构化任务效果显著。增益很快趋于平缓(从 1-shot 到 5-shot 的提升通常远不如从 0-shot 到 1-shot 的提升),但单个示例带来的基础改进是可靠的。在调优层次中,这排在 temperature 之上。
5. 采样参数。 到这一步,如果你的提示词清晰、上下文干净、模型选择合适,你就已经解决了结构性问题。Temperature 和 top-p 现在才是合法的校准工具——对确定性任务收窄方差,对生成性任务放宽约束。但它们作用于的是残余误差,而不是核心故障。
在调任何参数之前先诊断故障
"调 temperature"背后更深层的错误是跳过了诊断。输出失败有不同的原因,每种原因有不同的修复方法——而且没有一种方法是调整采样配置。
PRISM 故障分类法识别出四种主要故障模式:
- 知识提取失败: 模型没有这个信息。任何提示工程或采样更改都无法凭空制造事实。修复:添加上下文,使用 RAG,或切换到训练覆盖更广的模型。
- 知识记忆失败: 模型学到了这个信息,但无法可靠地检索它。修复:检索增强,在提示词中更明确地锚定。
- 推理错误: 模型拥有事实但无法正确组合它们。修复:思维链提示,将多步推理分解为明确的步骤,或使用推理能力更强的模型。
- 指令遵循错误: 模型有正确的知识和推理,但违反了你的明确约束(产生错误格式、错误长度、错误语气)。修复:更清晰的格式说明,输出 schema 定义,通过工具调用强制结构化输出。
调整 temperature 对上述任何一种情况都没有帮助。它是在"对还是错"这个基础之上的方差旋钮。如果模型因为结构性原因而失败——缺少知识、推理出错、忽略指令——改变 temperature 只会改变它错得多么自信,而不会改变它是否正确。
在调任何超参数之前,先确认你实际上遇到的是哪种故障模式。将 temperature 设为 0 运行你的提示词,确定性地检查故障。这是你的基准。方差是次要问题,只有在诊断了故障模式之后才去考虑。
正确的调优顺序
这是有经 验的团队遵循的顺序,按预期 ROI 排列:
1. 先诊断故障类型。 使用固定的确定性设置(temperature = 0)来精确隔离问题所在。对其分类:输出是事实性错误、结构性错误、相关性错误,还是格式错误?类别决定修复方法。
- https://learnprompting.org/docs/intermediate/configuration_hyperparameters
- https://arxiv.org/html/2402.05201v1
- https://research.trychroma.com/context-rot
- https://arxiv.org/html/2510.05381v1
- https://wandb.ai/wandb_fc/learn-with-me-llms/reports/Going-from-17-to-91-Accuracy-through-Prompt-Engineering-on-a-Real-World-Use-Case--Vmlldzo3MTEzMjQz
- https://medium.com/@mr.bharatpatidar/how-i-used-prompt-engineering-to-improve-llm-accuracy-by-40-with-real-examples-c73a2e5750e7
- https://arxiv.org/html/2604.16909v2
- https://neptune.ai/blog/hyperparameter-optimization-for-llms
- https://deepchecks.com/hyperparameter-optimization-llms-best-practices-advanced-techniques/
- https://arxiv.org/html/2312.00949v2
- https://arxiv.org/html/2510.24021
- https://www.ibm.com/think/topics/llm-temperature
- https://sureprompts.com/blog/llm-temperature-sampling-complete-guide-2026
- https://thenewstack.io/context-engineering-going-beyond-prompt-engineering-and-rag/
- https://arxiv.org/pdf/2407.01082
