概率、采样与 Temperature
从上下文预测下一个 Token
上一章介绍了 Token。模型生成文字时，会根据当前上下文，为下一步可能出现的 Token 计算一个概率分布，再按照所使用的解码策略选择其中一个。
假设当前文本是：
I love为了帮助理解，我们可以虚构一个简化的候选列表：
you 30%
this 18%
music 12%
it 8%
...模型选择一个 Token 后，会把它加入上下文，再预测下一个 Token。这个过程不断重复，直到生成结束标记、达到输出限制，或者由系统以其他方式停止。
候选词和百分比只是教学示意。真实模型通常在更大的词表上计算分布，而且概率会随上下文、模型和系统设置变化。
概率不是 tokenizer 预先写好的
Tokenizer 的工作是把文本与 Token ID 相互转换。它不会在切分文本时给每个 Token 分配一个永久不变的“回答概率”。
下一 Token 的概率由模型在生成时根据当前上下文计算。同一个 Token 放在不同句子里，概率可能完全不同。例如，“苹果”出现在水果清单和科技新闻中，后续更可能出现的内容就不一样。
为什么相同问题可能得到不同答案？
许多生成流程会进行采样，而不是永远选择分数最高的 Token。一次选择发生变化，后面的上下文也会变化，最终答案就可能沿着不同路径继续生成。
除此之外，结果还可能受到以下因素影响：
- 所选模型或模型更新；
- 系统指令和对话历史；
- temperature、top_p 等采样设置；
- 工具返回的数据和检索结果；
- 服务端实现带来的非确定性；
- 产品对请求所做的其他处理。
因此，“输入文字看起来一样”不一定意味着完整请求和运行条件完全相同。
Temperature 的作用
Temperature 是一些模型接口提供的采样参数。直观地说，它会调整候选 Token 分布的平坦程度：
- 较低的 temperature 通常让高概率候选更占优势，输出更集中；
- 较高的 temperature 通常让更多候选有机会被选中，输出更多样，但也可能更不稳定。
它不是模型的“创造力开关”，也不会让事实自动变得更正确。对于需要稳定格式、分类或信息提取的任务，通常更重视一致性；对于头脑风暴，可以允许更多变化。两种场景都需要验证结果。
不要把 temperature 设为某个值就当成质量保证。即使使用较低设置，输出也不一定完全可重复；不同模型和接口支持的参数也可能不同。
不要猜 ChatGPT 网页版的固定参数
面向普通用户的聊天产品通常不会公开或允许调整每一次生成所使用的全部采样设置。因此，不应把未经官方确认的数值写成“ChatGPT 网页版默认 temperature”。
开发者通过 API 使用模型时，应查看该模型和接口的当前文档：
- 是否支持 temperature；
- 参数允许的范围；
- 是否建议与 top_p 同时调整；
- 推理模型是否有不同的控制方式；
- 怎样通过固定模型版本、评测或其他设置提高一致性。
怎样选择设置？
不要先寻找一个适用于所有任务的数字。可以用一小组真实样本做对比：
- 明确任务的验收标准，例如事实正确、字段齐全或文案多样；
- 固定其他变量，只改变一个参数；
- 多次运行相同样本；
- 记录成功率、错误类型和人工修改成本；
- 根据结果选择设置，并在模型或提示更新后重新评测。
对于严格业务流程，程序校验、Schema、工具权限和人工审核，通常比单独调整 temperature 更重要。
本章小结
- 模型会根据当前上下文预测下一 Token 的概率分布；
- 概率由模型在生成时计算，不是 tokenizer 为 Token 写好的固定属性；
- 采样会让相同问题产生不同结果；
- temperature 通常影响输出分布的集中或多样，但不保证正确或可重复；
- 具体参数必须以目标模型和接口的当前官方说明为准；
- 真实任务应该通过样本和验收标准评测，而不是依赖一个“最佳参数”。
理解随机性以后，我们就能更合理地看待模型输出：把它当作需要检查的候选结果，而不是每次都完全相同的数据库查询。
