更新于
按任务类型设置 LLM temperature 速查表
temperature 的原理不再重复讲（原理和 top_p 的关系见下方相关阅读），本文只做一件事：给出一张能直接照抄进项目配置文件的速查表，按任务类型分类，省去每次都要重新试错的时间。
一、速查表
| 任务类型 | 推荐 temperature | 推荐 top_p | 备注 |
|---|---|---|---|
| 代码生成 / 补全 | 0.1–0.3 | 0.9–0.95 | 追求语法正确性，过高会引入不存在的 API |
| 结构化输出（JSON/XML 抽取） | 0 | 1.0 | 优先用 schema 约束而不是靠低温度硬保证格式 |
| SQL / 正则等强规则生成 | 0 | 1.0 | 错误容忍度极低，务必设为确定性输出 |
| 客服问答 / FAQ 机器人 | 0.2–0.4 | 0.9 | 需要稳定、可预测，避免答非所问 |
| 文档摘要 | 0.3–0.5 | 0.9 | 略高于纯问答，允许语言表达上的多样性 |
| 翻译 | 0.2–0.3 | 0.9 | 准确度优先，过高的多样性反而降低忠实度 |
| RAG 问答（基于检索片段回答） | 0.1–0.3 | 0.9 | 希望模型贴紧检索到的原文，减少发挥 |
| Agent / 工具调用（Function Calling） | 0–0.2 | 0.9 | 工具参数出错会导致整个链路失败，务必偏低 |
| 分类 / 打标签任务 | 0 | 1.0 | 本质是判别任务，不需要随机性 |
| 创意写作 / 文案脑暴 | 0.7–1.0 | 0.9–1.0 | 需要多样性和”意外感”，可适当调高 |
| 头脑风暴多个方案 | 0.8–1.2 | 0.95 | 配合 n（多次采样）一起用效果更好 |
| 数据合成 / 增强训练样本 | 0.7–0.9 | 0.9 | 需要覆盖多种表达变体，避免生成结果同质化 |
| 单元测试用例生成 | 0.4–0.6 | 0.9 | 略高于普通代码生成，鼓励覆盖边界情况 |
基本原则：判别类、抽取类、格式敏感类任务用低温；生成类、发散类、需要多样性的任务用高温。拿不准就从表里最接近的场景抄一个初始值，再按实际输出微调 0.1–0.2。
二、各家 API 的特殊限制
不同厂商对这个参数的支持有细节差异，直接套用别家的配置可能会报错或不生效：
- OpenAI 推理模型（o 系列 / GPT-5 thinking 模式）：不支持自定义
temperature，传参会被忽略或报错，模型内部固定使用确定性程度较高的采样策略 - Anthropic Claude：官方建议
temperature和top_p二选一调整，不要同时改动两个参数，避免采样策略叠加导致行为难以预测 - Google Gemini：默认
temperature略高于 OpenAI 和 Anthropic 的默认值，如果是从其他家 API 迁移过来又没有显式设置该参数，实际生成结果可能会比预期更发散 - 开源模型（Llama、Qwen 等自部署）：部分推理框架（如 vLLM）的
temperature=0实现方式是内部转换成贪心解码，个别版本存在数值精度导致的输出不完全确定的已知问题，追求严格确定性建议同时固定随机种子
三、一个容易被忽视的细节：temperature=0 不等于绝对确定
很多人以为把 temperature 设为 0 就能保证同样的输入永远得到完全一样的输出，但实际上：
- 多数云端 API 出于批处理和硬件层面的浮点数精度问题，即使
temperature=0也可能在极少数情况下出现字符级别的细微差异 - 如果任务对逐字节确定性有强需求（比如需要做输出结果的哈希对比缓存），不要只依赖
temperature=0，最好在业务层加一层结果缓存或增加重试后的一致性校验
四、实战建议：从生产环境配置反推
与其纠结”理论上应该设多少”，不如参考实际生产系统里常见的做法：
- Agent 类产品（工具调用密集）几乎清一色把 temperature 设到 0–0.1，因为一次工具参数解析错误的代价远高于回答略显生硬
- 面向 C 端的聊天助手，多数产品把默认值设在 0.5–0.7 之间，在”够聪明”和”不啰嗦跑题”之间取平衡
- 内容生成类工具（营销文案、社媒配文）普遍给用户暴露一个”创意程度”滑块，底层直接映射到 0.3–1.0 的 temperature 区间
五、相关阅读
不同任务切换不同模型和参数配置时，通过 YoTradeApi 一个统一的 API 入口即可调用 Claude、GPT、Gemini 等模型，不用为每家单独维护密钥和计费。