温度与随机性 | 大模型 | 做产品

温度与随机性

它不是心情不定，是每一步都在按概率抽签。这个抽签动作是被设计出来的，而且你可以关掉。

你会遇到的现象

• 同一个提示跑两次，一次格式完美，一次多了一句废话

• demo 的时候好好的，演示给老板看就翻车

• 你在做批量处理，一千条里有三十条格式不对，找不出规律

随机性从哪一步来

模型每生成一个 token，都会先算出一整张候选表：词表里每个 token 各有多大概率。到这一步为止，一切都是确定的——同样的输入，算出来的分布就是同一张。

随机性出现在下一步：**从这张表里抽一个。**不是取最大值，是抽。概率 62% 的那个 token 大概率被抽中，概率 18% 的那个也有它的机会。一旦抽中的不是最常见那个，后面整句话都会顺着这个新方向长下去。

所以偏差是会放大的。一次生成几百个 token，就是几百次抽签，只要有一次抽出了不一样的，后面的分布就全变了。这也解释了为什么越长的输出越不稳定。

顺带说清楚一件事：即使把随机性完全关掉，同一个提示也不保证百分百逐字相同。批处理的并发情况、浮点计算的顺序、服务端的版本更新，都会带来微小差异。**调到 0 是「几乎一致」，不是「加密级的一致」。**要真正的一致，得由你自己缓存结果。

两个旋钮

参数在做什么调它的效果 temperature把整张概率表压平或拉尖越高越敢用冷门候选，越低越死板 top-p只保留累计概率靠前的一小撮候选直接砍掉长尾，防止抽到离谱的 top-k只保留概率最高的 k 个候选同上，但用固定个数切 seed固定抽签用的随机数让同样的输入尽量复现同样的输出

前两个不要同时大改。常见做法是固定 top-p，只调温度；或者反过来。两个一起动，出了问题你分不清是谁的责任。

• **温度是「敢不敢用冷门词」。**调低，它只在最有把握的几个候选里选，输出保守、重复、安全。调高，长尾候选被抬起来，说法更新鲜，但胡说的概率同步上升。创造力和可靠性在这里是同一个旋钮的两端，没有两全。

• **top-p 是「先划一条线」。**它把候选按概率从高到低排，累加到设定的比例就停，后面的全不要。好处是无论分布多平，都不会抽到那些明显不该出现的选项。做产品时，它比温度更适合当安全阀。

• **不是所有接口都给你这些旋钮。**一些新的推理型模型不接受温度参数，或者接受了也不起作用。选型的时候要确认一下，别把方案建在一个调不动的参数上。

什么时候调到 0

判断标准只有一条：**这个任务有没有唯一正确答案。**有，就调到 0；没有，才留一点随机。

场景建议原因 抽取字段、分类打标0答案唯一，任何波动都是错误 输出结构化 JSON0格式必须每次都一样 代码生成、SQL 生成0 – 0.2能跑通比写得漂亮重要 翻译、改写、摘要0.3 – 0.5要准，但允许一点措辞自由 写文案、起标题0.7 – 1.0要的就是不一样的几个版本 头脑风暴、发散想点子1.0 以上离谱的那几个反而有用

一个产品里往往同时有好几类调用，不该共用一套参数。把「抽字段」和「起标题」用同一个温度跑，两边都不会好。

还有两条实操上的提醒。**第一，先别急着调温度。**大多数「输出不稳定」其实是提示写得太松：没给格式、没给例子、没说不许做什么。把这些补上，稳定性的提升远大于把温度从 0.7 调到 0.3。

**第二，稳定性最终还是要靠校验兜底。**温度 0 只是让它更可能给出同一个答案，不代表那个答案一定对、一定合法。凡是要进下游系统的输出，都要做一次格式校验，不合格就重试或降级。把随机性当成一个必然存在的事实来设计，而不是当成一个可以调没的 bug。

判断标准只有一条：这个任务有没有唯一正确答案

有唯一答案 怎么答都行

0 0.2 – 0.3 0.7 0.9 +

抽字段 分类打标 知识问答 摘要 文案改写 对话回复 起标题 头脑风暴

把「抽字段」和「起标题」用同一个温度跑，两边都不会好。

但先别急着调温度 大多数「输出不稳定」其实是提示写得太松 没给格式、没给例子、没说不许做什么

调到 0 也不等于确定 并发、浮点顺序、服务端版本都会带来微小差异 要真正一致，得由你自己缓存结果

创造力和可靠性在温度这个旋钮上是同一根轴的两端，没有两全。所以正确的做法不是找一个「最好的温度」，是按调用类型分开配。

接着看

大模型的运作原理 抽签这个动作发生在哪一步，以及为什么它会被后面几百步放大。

幻觉产生的原因 温度调高之后先出问题的地方。为什么这件事只能防不能修。

先规格后代码 「先别急着调温度」的落地：把要求写清楚，比调参数管用得多。