temperature 与 top_p 怎么调：生成参数的作用与调整顺序

把同一个问题交给生成式 AI，得到的回答往往每次措辞都不同。有人会说「把 temperature 调低就稳定了」，也有人提到 top_p，但这两个参数究竟改变了什么，光看名字很难判断。这篇教程要解决的问题是：temperature 和 top_p 各自作用在生成的哪一步、分别改变什么、以及在动手调参之前应该先确认哪些事。适合已经能调用模型接口、但输出忽好忽坏、想搞清楚该动哪个旋钮的开发者与提示词维护者。文中不提供「万能推荐值」——合适的取值范围取决于用途，需要自己用对比实验确定。

准备工作

要跟着本文做对比实验，先准备下面几样东西。

一个可调用的模型接口：能通过 API 或本地推理框架发送请求，并且请求参数里能指定 temperature、top_p 之类的生成选项。具体参数名与可用性以所用模型和服务的当前文档为准。
该模型的生成参数说明：确认它支持哪些采样参数、各自的默认值是多少、有没有取值范围限制。不同模型、不同服务商对同一参数的支持程度并不一致，有的只支持其中一个，有的两个都不开放。
一组代表性输入：从实际业务里挑几条有代表性的问题，数量不必多，但要覆盖你真正在意的场景，而不是随手找一句测试话。
一份期望回答的条件清单：用短句写清楚「什么样的回答算合格」，例如「事实与给定资料一致」「输出为指定格式」「长度在某个范围内」「措辞不要每次都变」。这份清单是后面判断调参有没有用的依据。
记录方式：能保存每次请求的输入、参数、完整输出。只凭印象比较，很容易把随机波动当成调参效果。

另外要提前明确一点：生成参数不是回答质量的保证装置。它不负责补充知识，也不负责核对事实。凡是需要准确性的处理，输入资料、输出格式约束、结果校验和人工复核都要另行安排。

操作步骤

第一步：理解模型是怎么挑下一个词的

生成式模型写句子时，并不是先想好整段话再吐出来。它接收到目前为止的上下文，为「下一个 token」（token 是文字或词的一部分这类单位）的每个候选打一个概率，然后从这些候选里挑一个，接到已有文本后面，再重复这个过程。

为了说明方便，假设输入是「早上的饮料是」，模型给出的候选概率如下（这组数字是示意用的，不是任何真实模型的输出）：

下一个候选	示意概率
咖啡	50%
茶	30%
水	15%
其他	5%

关键在于：排在最上面的候选并不是唯一正确答案。从这堆候选里怎么挑，决定了同样的输入为什么会生出不同的句子。整个流程可以概括成一条链：

输入文本 → 给下一个候选打概率 → 从候选中挑选 → 追加到文本 → 回到第一步

生成参数作用的位置，就在「从候选中挑选」这一步。

第二步：搞清 temperature 改变的是什么

temperature 调整的是候选之间概率差距的大小。可以把它想成改变抽奖时各奖项中奖难易程度的旋钮，而不是给菜加调料。

调低：选择更容易集中在原本概率就高的候选上。
调高：原本概率偏低的候选也更容易被选中，表达更容易变得多样。

用上面那张示意表来说，低设置下更容易落到「咖啡」，高设置下「茶」和「水」被选中的机会也会上升。

这里有两个常见误解需要澄清：

它不会给模型增加新知识，也不做事实核对。把 temperature 调低，如果原本概率最高的那个候选本身就是错的，错误照样会留下来。
调低不等于每次输出都一模一样。模型实现、服务商的具体处理、输入内容、其他设置都会影响实际行为，不能指望调一个参数就得到完全确定的输出。

第三步：搞清 top_p 改变的是什么

top_p 的做法是：把候选按概率从高到低排列，只保留累计概率刚好达到指定值的最小候选集合，其余候选直接排除在抽选之外。这个方法也叫 nucleus sampling（核采样）。

还是用那张示意表。如果设 top_p = 0.8，从高往低累加：「咖啡」50% 加上「茶」30% 正好到 80%，于是保留这两个候选，「水」和「其他」被移出候选池。至于保留下来的候选里最终选中哪一个，是另一回事。

两者的区别可以对照着看：

设置	主要改变的东西	容易观察到的变化
temperature	候选之间的概率差距	表达波动的幅度变化
top_p	留在抽选里的候选范围	概率很低的候选被排除

需要说明的是，上面这套解释是为了帮助理解机制而做的简化。两个参数同时使用时先处理哪个、各自覆盖到什么范围，不同实现并不相同；有些模型甚至不允许指定其中一个或两个都不开放。动手之前，先查所用模型的当前文档确认支持情况与默认值。

第四步：调参之前，先把「失败」分类

输出不符合预期时，第一反应就去动参数，往往会让原因变得难以追踪。更稳的做法是先判断这属于哪一类问题，再决定要不要碰生成参数。

遇到的困扰	应该先确认的事
回答格式每次都不一样	指令里有没有明确写出输出格式；如果是给程序消费的，能不能改用结构化输出
事实说错了	有没有把依据资料或检索结果一起传进去；来源能不能核对
太长或中途被截断	长度指令是否合适；输出 token 上限是否设得够
只有措辞在飘	是不是在用同一个模型、同一份输入做比较；这种波动对你的场景算不算问题

这张表的意义在于：格式问题通常靠把格式要求写清楚或改用结构化输出解决，事实问题靠提供可核对的资料解决，长度问题靠调整长度指令和输出上限解决。只有确认问题确实出在「挑选候选」这一步时，调 temperature 或 top_p 才有意义。

第五步：一次只改一个变量做对比

确认需要调整之后，按下面的顺序做对比，改动带来的效果才追得清楚。

准备几条有代表性的问题，并把期望的回答条件用短句写下来。
固定同一个模型、同一份输入、同一个输出上限，先记录默认设置下的结果。
在模型支持的设置里只改一个，用同样的问题再跑一遍。
按条件逐项检查：事实对不对得上、格式有没有守住、有没有多余的波动。
如果看起来变好了，换几条贴近实际用途的输入再验证一遍。

最后一步容易被跳过。单个问题上的改善很可能只是偶然，只有在一批贴近真实用途的输入上都站得住，才值得把参数固定下来。

一个完整示例

下面用一个虚构的客服摘要场景，把上面的流程串一遍。场景是：把一段用户反馈压缩成一句话摘要，要求包含问题类型和情绪倾向，供内部看板使用。

第一步，写清期望条件。

输入：一段用户反馈原文
输出要求：
  1. 一句话，不超过 40 字
  2. 必须包含「问题类型」和「情绪倾向」两个要素
  3. 不添加原文没有的信息
  4. 同一段原文多次运行，措辞差异不影响看板阅读即可

第二步，准备代表性输入。从真实反馈里挑几条，覆盖不同的问题类型和情绪，例如物流延迟、功能报错、咨询使用方法、表扬。不要只挑一条最典型的。

第三步，记录默认设置下的结果。用同一个模型、同一份输入、同一个输出上限跑一遍，把输入、参数、完整输出都存下来。这一步是后面所有比较的基准，不能省。

第四步，只改一个参数。假设默认设置下摘要的措辞波动较大，但格式和事实都没问题——按第四步的分类表，这属于「只有措辞在飘」。此时可以只调整 temperature，其他设置保持不动，用同一批输入再跑一遍。如果所用模型不支持该参数，就换用另一个支持的参数，或者接受这种波动。

第五步，逐项核对。把两轮结果并排看，逐条对照第一步写下的四个条件：长度有没有超、两个要素是否都在、有没有编造原文没有的内容、措辞波动是否降到了可接受的程度。

第六步，扩大验证。如果调整后确实更稳，再补几条之前没参与调试的输入跑一遍。只有在新输入上同样成立，才把参数写进正式配置。

这个例子里没有出现任何具体数值，这是有意的。合适的取值取决于用途：需要多大程度的多样性、能容忍多大的波动，不同场景差别很大，没有通用推荐值。数值应当由自己的对比实验得出，并以所用模型当前文档中的取值范围为准。

注意事项

参数不保证事实正确。temperature 和 top_p 都不做知识补充和事实核对。对准确性要求高的处理，必须另外安排输入资料、输出校验和人工确认。
调低不等于输出完全确定。受模型实现、服务商处理、输入和其他设置影响，同一输入仍可能产生不同结果。
两个参数的处理顺序因实现而异。同时使用时的先后关系与覆盖范围没有统一标准，不要照搬别处的经验值。
并非所有模型都开放这两个参数。有的只支持其中一个，有的两个都不支持。动手前先确认所用模型的支持情况与默认值。
不要一次改多个设置。同时改动多个变量，事后无法判断是哪一个起了作用。
不要用单个问题下结论。一条输入上的改善可能只是偶然，需要在贴近实际用途的一批输入上验证。
先分类再调参。格式、事实、长度这三类问题各有对应的处理手段，把它们当成采样参数问题去调，通常解决不了。
价格、配额、参数取值范围与默认值都可能变动，请以所用模型和服务商官网的当前信息为准。

把上面这些串起来，核心就一句话：生成参数管的是「从候选里怎么挑」，不管「挑出来的内容对不对」。先分清失败属于哪一类，把评价条件写下来，再固定其他变量、一次只动一个设置去比，才可能得到对自己场景真正有用的取值。