Temperature 与 Top-P（采样参数）
控制 LLM 输出随机性的两个核心参数：Temperature 调节概率分布的平坦度，Top-P 限制候选词范围。
什么是 Temperature 和 Top-P
Temperature 和 Top-P 是控制 LLM 输出随机性的两个参数。它们决定了模型在生成文本时"有多保守"或"有多创造性"。
- Temperature — 调整概率分布的平坦度，值越高输出越随机
- Top-P（核采样） — 只从累积概率超过 P 的候选词中选，限制选择范围
Temperature 详解
原理
模型在每一步预测下一个 token 时，会计算所有可能 token 的概率。Temperature 通过调整 logits（概率前的分数）来改变分布形状：
调整后概率 = softmax(logits / temperature)
- Temperature = 1.0：原始概率分布不变
- Temperature < 1.0：概率分布变"尖锐"——高概率词更高、低概率词更低 → 更确定
- Temperature > 1.0：概率分布变"平坦"——各词概率更均匀 → 更随机
- Temperature = 0：完全贪心——永远选概率最高的词
实际效果
| Temperature | 效果 | 适用场景 |
|---|---|---|
| 0 | 完全确定性，每次回答相同 | 代码生成、数据抽取、事实问答 |
| 0.3 | 高度确定，偶尔有变化 | 代码审查、文档摘要 |
| 0.7 | 平衡（大多数 API 默认值） | 通用对话、问答 |
| 1.0 | 较有创造性 | 文案写作、头脑风暴 |
| 1.5+ | 高度随机，可能出现乱码 | 创意写作（慎用） |
示例
同一个 prompt "写一首关于秋天的诗"：
- Temp 0：每次生成完全相同的诗
- Temp 0.7：每次不同的诗，但风格相似
- Temp 1.5：每次差异巨大，可能出现非常规表达
Top-P 详解
原理
Top-P（nucleus sampling，核采样）不是调整概率分布，而是限制候选范围：
- 把所有候选 token 按概率从高到低排序
- 累积概率，直到达到 P 值
- 只从这些 token 中采样
P = 0.9 → 只从累积概率达 90% 的最可能 token 中选
P = 0.1 → 只选概率最高的极少数 token
P = 1.0 → 不限制，所有 token 都可能被选
实际效果
| Top-P | 效果 | 适用场景 |
|---|---|---|
| 0.1 | 非常保守 | 代码生成、事实问答 |
| 0.5 | 较保守 | 文档摘要、分类 |
| 0.9 | 平衡（默认） | 通用对话 |
| 1.0 | 不限制 | 创意写作 |
min_p：新一代采样
2024 年后流行的第三个参数，部分开源推理框架（vLLM / llama.cpp / SGLang）和一些 API 已支持。
思路：top-p 在"概率分布很尖"时会留太多噪音 token；min_p 设一个相对阈值——只要 token 的概率不低于「最高概率 token × min_p」就保留。
min_p = 0.05 表示：保留所有概率 ≥ 0.05 × max_prob 的 token
实测在创意写作场景，min_p=0.05~0.1 比 top_p=0.9 输出质量更稳定（既不过度保守也不会跑飞）。新模型推理时可以试试。
seed 与确定性
Temperature=0 不等于 完全确定性。同一个 temperature=0 的请求，OpenAI / Anthropic 多次跑结果有时仍不同——浮点运算非确定性 + batch 调度差异导致。
要更稳的复现，可以传 seed：
# OpenAI
client.chat.completions.create(
model="gpt-5", temperature=0, seed=42, ...
)
# 响应里会带 system_fingerprint，相同 fingerprint + seed 才能保证完全一致
注意：
seed是 best-effort，模型升级 / 基础设施变动会让 fingerprint 变- Anthropic / Google 早期不支持 seed，新版本逐步加入
- 真的要 100% 确定性（比如单元测试），用 mock 替代 LLM 调用
怎么搭配使用
一般原则
不要同时调两个。OpenAI 官方建议：要么调 Temperature，要么调 Top-P，不要同时改。
推荐配置
| 场景 | Temperature | Top-P | 理由 |
|---|---|---|---|
| 代码生成 | 0 | 1 | 完全确定，代码不应有"创意" |
| 代码审查 | 0.2 | 1 | 高度确定，偶尔看不同角度 |
| 数据抽取 | 0 | 1 | 严格按格式输出 |
| 工具调用（Function Calling） | 0 ~ 0.2 | 1 | 见下节 |
| 客服 Bot | 0.5 | 0.9 | 适度变化，但不跑题 |
| 通用对话 | 0.7 | 1 | 平衡 |
| 文案写作 | 0.9 | 1 | 需要创意 |
| 头脑风暴 | 1.2 | 1 | 越发散越好 |
各平台默认值
| 平台 | 默认 Temperature | 默认 Top-P | 备注 |
|---|---|---|---|
| OpenAI API | 1.0 | 1.0 | — |
| Anthropic API | 1.0 | 1.0 | — |
| Google Gemini | 1.0 | 0.95 | — |
| DeepSeek API | 1.0 | 1.0 | 官方文档建议代码 0.0 / 通用 1.3 |
| 国内 GLM | 0.95 | 0.7 | — |
踩坑：很多人以为默认是 0.7，其实主流大厂默认是 1.0。如果你的应用想要保守输出，必须显式设置，不要假设默认值。
推理模型为什么不建议改 temperature
GPT-5 reasoning、Claude Opus 4 thinking、DeepSeek-R1、o3 等推理模型，官方都建议保持默认 temperature=1.0：
- 推理模型的思维链本身依赖概率采样的多样性来"探索"不同解法
- 强制 t=0 会让推理路径单一，反而降低复杂问题的成功率
- 思维链长度 × 低多样性 = 容易陷入死循环
对推理模型，控制输出应该靠 prompt 描述目标和约束，而不是调采样参数。
温度对 Function Calling 稳定性的影响
工具调用场景，temperature 影响很关键：
| Temperature | 影响 |
|---|---|
| 0 | 工具选择最稳定，参数提取准确率最高 |
| 0.2 | 几乎和 0 一样，偶尔在多个相近工具间选 |
| 0.7 | 模型可能"灵活"地选不太对的工具、参数飘 |
| 1.0+ | 工具调用稳定性显著下降，生产慎用 |
经验：所有工具调用场景，先把 temperature 设 0 验证基线效果，再视情况微调。别用默认 1.0 直接上工具调用，调试起来很痛苦。
常见误区
误区 1: "Temperature = 0 就不会出错"
Temperature = 0 只保证（接近）确定性，不保证正确性。模型可能每次都"确定地"给出错误答案。
误区 2: "调高 Temperature 模型更聪明"
Temperature 调高只是让输出更随机，不会让模型变聪明。高 Temperature 反而可能导致逻辑混乱。
误区 3: "Top-P 和 Temperature 效果一样"
不完全一样。Top-P 是硬截断（低概率词完全排除），Temperature 是软调整（低概率词概率降低但不为 0）。
误区 4: "推理模型也要 temp=0"
错。推理模型靠思维链探索，强制 0 会让它失去推理多样性，反而表现下降。
误区 5: "改 temperature 可以解决幻觉"
只能轻微缓解。幻觉的根本解法是 RAG + grounded generation，不是调采样参数。
延伸阅读
- 输出控制：Prompt Engineering
- 工具稳定性：Function Calling
- 幻觉缓解：Hallucination