温度调到0能降事实性幻觉，但RAG回答用0.2、创意任务用0.9，一个系统里多种温度并存时，谁来保证一致性？

从采样参数到系统契约：多温度并存下的幻觉治理与一致性工程

摘要与阅读导引

把 temperature 调到 0，确实能在多数事实性问答基准上压低采样方差、减少“编造”式输出；但工程系统很少只跑一种任务。检索增强生成（RAG）常取 0.1–0.3 以换取稳定引用，创意写作与头脑风暴常取 0.8–1.0 以换取多样性，而分类、抽取、工具调用又往往要求近确定性。于是同一个产品里同时存在多个温度，问题就从“温度设多少”升级为“多个温度并存时，谁对最终输出的一致性负责”。

本文的主线是一条笔者称之为“温度契约（Temperature Contract）”的工程抽象：温度不是一个可以随手调的旋钮，而是一份显式声明——声明某条推理路径的随机性预算、证据约束强度、可复现等级与验收口径。全文围绕这条主线展开：先界定温度与幻觉的因果边界，再拆解多温度并存的四类不一致来源，随后给出分层治理架构、可操作的实施步骤、评测与回归方法，最后讨论边界条件与前沿预判。

目录

一、问题的提出：温度不是单点参数，而是系统级变量

1.1 一个真实存在的“温度拼盘”

一个中等规模的 LLM 应用，往往同时包含以下推理路径：意图识别与路由（要求稳定）、查询改写（要求稳定且可控发散）、RAG 答案合成（要求忠于证据）、结构化抽取（要求严格 JSON）、创意文案（要求多样性）、对话闲聊（要求自然）、以及若干 Agent 子任务（要求可复现以便调试）。这些路径的温度取值天然不同，常见配置如下表（表中数值为业界常见区间的归纳，非某一特定厂商的官方推荐，标注为“经验归纳”）。

这张表本身没有问题，问题在于它通常散落在代码各处：某个 prompt 模板里写死 0.2，某个前端开关暴露 0.9，某个 Agent 框架默认 0.7，某个评测脚本又统一设 0。当用户在同一次会话中先问事实、再要创意、最后触发工具时，系统实际上在多个“随机性预算”之间来回切换，而没有任何一层对“切换后的整体行为”负责。这就是本文要处理的核心矛盾。

1.2 为什么“调到 0”被过度简化了

“温度调到 0 能降幻觉”这一说法在工程圈广泛流传，其合理内核是：低温使输出分布更尖锐，降低采样到低概率 token 的机会，从而减少“看似合理但无依据”的续写。但这一说法至少省略了三个前提。第一，温度 0 并不等于确定性：在浮点运算、批处理归约顺序、并行 kernel 非确定性等因素影响下，贪心解码也可能出现微小数值差异，进而在近似并列的 logits 上翻转选择。第二，温度只作用于采样阶段，不改变模型参数中已经存在的错误知识；如果证据缺失，低温只会让模型“更自信地重复同一个错误”。第三，低温会牺牲多样性，在需要多候选、多视角的任务上直接损害效用。

本文评述：把“降温”当作幻觉治理的主要手段，本质上是把生成阶段的方差误认为错误的全部来源。幻觉至少可分解为知识缺失、检索失败、证据误读、指令冲突与解码漂移五类，温度只对最后一类有直接作用。因此“温度调到 0”是一个必要但不充分的工程动作，它必须与证据约束、验证器、评测口径一起构成契约，才具备可辩护性。

二、机制拆解：温度到底改变了什么，又没改变什么

2.1 从 logits 到 token：温度的数学位置

在标准自回归解码中，模型对词表输出 logits 向量 z，温度 T 作用于 softmax 之前：

p_i(T) = exp(z_i / T) / Σ_j exp(z_j / T)

T → 0+   : 分布趋于 one-hot，等价于 argmax（贪心）
T = 1    : 原始分布
T > 1    : 分布被压平，长尾概率上升

需要强调，温度改变的是相对概率形状，不改变 logits 的排序。因此当 top-1 与 top-2 的 logit 差距远大于数值噪声时，降温到 0 与 0.1 的行为几乎一致；而当差距很小时，温度的小幅变化就可能改变选择。这解释了一个常见现象：某些任务上 0 与 0.2 的评测差异在置信区间内不可区分，另一些任务上却差异显著——差异大小取决于该任务决策边界的“logit 间隙”分布。

工程上还常配合 top-p（nucleus）与 top-k。三者并非独立：top-p 先截断长尾，温度再重塑剩余分布。若先设 top-p=0.9 再设 T=0.2，实际有效候选集已被截断，温度的作用被部分“预支”。因此讨论“0.2 是否合适”时，必须同时声明 top-p、top-k、repetition penalty 等参数，否则结论不可迁移。这一点在多个开源推理框架的采样实现中均有体现，可参考 Hugging Face Transformers 的生成配置文档（transformers 文本生成配置）与 vLLM 的采样参数说明（vLLM SamplingParams）。

2.2 温度与幻觉：相关而非因果的全部图景

已有大量工作讨论解码策略与事实性的关系。DoLa 通过对比不同层 logits 的差异来放大事实性信号（Chuang 等，2023，arXiv:2309.03883）；inference-time intervention 在特定注意力头上做干预以提升真实性（Li 等，2023，arXiv:2306.03341）；而 SelfCheckGPT 则从采样一致性角度检测幻觉（Manakul 等，2023，arXiv:2303.08896）。这些工作共同指向一个判断：事实性主要由知识表征与证据条件决定，解码策略是二阶修正。

笔者认为，把温度与幻觉的关系表述为“低温降幻觉”过于粗糙，更准确的表述是：低温降低采样引入的方差型错误，但对系统性知识错误无效，甚至因为“更自信”而放大其危害——模型在低温下更倾向于给出单一、笃定但错误的答案，用户更难通过多候选发现异常。这一判断对系统设计的直接含义是：低温必须与“可验证的证据链”和“不确定性外显”配套，否则只是把随机错误换成了确定性错误。

2.3 RAG 场景下温度的特殊性

RAG 把外部证据注入上下文，理论上应显著降低知识缺失型幻觉。但 RAG 引入了新的失败面：检索未命中、证据相互冲突、证据与参数知识冲突、以及模型对证据的“过度概括”。在 RAG 中，温度的作用对象从“开放续写”变为“受约束的整合”，因此低温的价值主要体现在两点：一是减少对证据的“创造性改写”，二是提高引用与结论之间映射的稳定性。但低温并不能解决“证据本身错误”或“检索遗漏关键段落”的问题。

RAG 原始工作（Lewis 等，2020，arXiv:2005.11401）确立了“检索器—生成器”联合框架；后续的 FiD、REALM、Atlas 等沿不同路线优化。工程实践中，RAG 答案合成的温度常取 0.1–0.3，这一区间并非来自某篇论文的硬性结论，而是“稳定性”与“语言自然度”之间的经验折中（经验归纳，非官方标准）。本文评述：RAG 的温度选择应当由“证据覆盖率”与“答案可验证性”共同决定，而非固定常数；当检索置信度高、证据片段完整时，可以适当提高温度以改善表达；当证据稀疏或冲突时，应进一步降温并强制外显不确定性。

三、多温度并存的四类不一致来源

3.1 参数层不一致：同名不同义

不同框架、不同厂商 API 对 temperature 的实现细节并不完全一致：有的在 logits 上直接缩放，有的先做 top-k 再缩放，有的对重复惩罚的顺序不同；部分 API 在 T=0 时走特殊分支（直接贪心），部分仍走采样并做极小温度近似。这意味着“0.2”在两个组件里可能对应不同的有效分布。参数层不一致是最隐蔽的一类，因为它不会报错，只会在长尾样本上表现为难以复现的行为差异。

可操作的缓解方式是建立“参数语义映射表”：对每个接入的模型/框架，记录其温度实现、截断顺序、默认 top-p、是否支持 seed、T=0 的特殊行为，并在网关层做归一化。下表给出一个映射表的字段设计示例（字段为工程建议，非某框架官方规范）。

3.2 编排层不一致：温度在链路中被覆盖

在多步链路中，温度常被“就近覆盖”：路由节点设 0，改写节点设 0.4，合成节点设 0.2，但如果某个中间件或 SDK 在调用时统一注入默认值，前面的设置就失效。更常见的是 Agent 框架中的“全局默认温度”与“节点级温度”冲突，最终生效的取决于调用顺序而非设计意图。这类问题的本质是配置优先级没有显式化。

笔者认为，编排层应当采用“就近声明 + 显式继承”的规则：每个节点必须显式声明温度或显式声明“继承上游”，禁止隐式默认；网关层负责在调用前校验声明完整性，缺失即拒绝执行并记录。这一规则看似繁琐，但能把大量“玄学不一致”转化为可定位的配置错误。

3.3 评测层不一致：用 0 评测、用 0.2 上线

这是最容易被忽视、后果最严重的一类。评测脚本为了可复现，常统一设 T=0；而线上为了体验，RAG 用 0.2、创意用 0.9。于是评测报告中的事实性指标无法代表线上行为：低温评测低估了采样方差带来的引用错配，高温创意路径又完全不在评测覆盖内。更麻烦的是，多温度系统的整体指标不是各路径指标的简单加权，因为用户会话是跨路径的，前一步的漂移会改变后一步的输入分布。

本文评述：评测口径必须与线上口径“同温同参”。如果线上 RAG 用 0.2，评测就必须在 0.2 下做多次采样并报告分布，而不是在 0 下取单次结果。否则所谓“一致性”只是评测环境的一致性，不是系统行为的一致性。这一点在近年的 LLM 评测讨论中被反复提及，可参考 HELM 的标准化评测思路（Liang 等，2022，arXiv:2211.09110）。

3.4 体验层不一致：用户感知的“人格漂移”

同一会话中，事实问答的严谨语气与创意任务的发散语气若切换生硬，用户会感知为“人格漂移”。这不只是文风问题，还涉及事实口径：创意路径在高温下可能生成与品牌事实不符的表述，若这些表述被后续事实问答引用（例如被写入会话记忆），就会污染整条链路。因此体验层的一致性需要“风格契约”与“事实契约”分离：风格可以随任务变化，事实口径必须全局统一。

四、温度契约：分层治理架构与操作路径

4.1 契约的四个要素

笔者提出的“温度契约”包含四个要素，缺一不可：随机性预算（该路径允许的采样方差上限）、证据约束强度（是否强制引用、是否允许参数知识补全）、可复现等级（是否要求同 seed 同输出、是否允许跨批次差异）、验收口径（用何种指标、在何种温度与采样次数下判定通过）。四要素共同构成一份可审计的声明，而不是一个孤立的数字。

这一抽象的价值在于：它把“温度设多少”这个无法直接回答的问题，转化为“这条路径需要什么样的随机性预算与证据约束”这个可以讨论的问题。一旦契约显式化，多温度并存就不再是混乱，而是受控的多样性。

4.2 分层架构：网关、编排、节点、验证器

建议采用四层架构。第一层是采样网关，负责参数归一化、契约校验、seed 管理与调用日志；第二层是编排器，负责节点级温度声明与继承规则、跨路径状态传递；第三层是节点，即具体的 prompt 与模型调用；第四层是验证器，对输出做证据对齐、格式校验与不确定性标注。四层之间通过契约对象传递，而非散落的参数。

contract = {
  "path": "rag.answer",
  "temperature": 0.2,
  "top_p": 0.9,
  "seed": "session-scoped",
  "evidence_policy": "cite-required",
  "reproducibility": "same-seed-same-output",
  "acceptance": {"faithfulness_min": 0.9, "samples": 5}
}
# 网关校验：字段齐全 + 温度在路径白名单内 + 验收口径与线上一致
# 编排器：节点未声明则拒绝执行，禁止隐式默认

上述伪代码为工程示意，非某框架的真实 API。关键在于“缺失即拒绝”这一策略：它把配置不一致从运行时玄学变成启动期错误，大幅降低排查成本。

4.3 操作路径：从现状盘点 to 灰度上线

落地可分五步。第一步，盘点：扫描代码与配置，列出所有温度设置点及其生效优先级，产出“温度地图”。第二步，归类：按任务类型把路径归入“确定性”“受约束生成”“开放生成”三类，分别设定预算区间。第三步，契约化：为每条路径编写契约对象，补齐证据策略与验收口径。第四步，验证：在契约温度下做多次采样评测，建立基线分布而非单点值。第五步，灰度：先在小流量上对比契约化前后的行为差异，确认无回归后再全量。

每一步都应有可交付物：温度地图、分类表、契约清单、基线报告、灰度对比报告。这些交付物本身就是“谁负责一致性”的答案——不是某个人，而是一套可审计的流程与产物。

4.4 一个具体的 RAG 合成节点示例

以 RAG 答案合成为例，契约化后的节点行为可以这样设计：检索返回若干片段并附带相关性分数；若最高分低于阈值，节点降温至 0.1 并强制输出“证据不足”提示；若片段间存在冲突，节点降温并列出冲突点而非强行综合；若证据充分，允许 0.2–0.3 以改善表达。验证器随后检查每个结论句是否有对应引用，未对齐的句子被标记或剔除。

本文评述：这一设计的要点不是“0.2 这个数字”，而是“温度随证据状态动态调整”这一机制。它把温度从静态超参变成证据条件的函数，从而在保持整体一致性的同时允许局部弹性。这与自适应推理、动态计算的思想一脉相承，但在工程上更易落地，因为它只依赖检索分数与冲突检测，不要求模型内部可解释性。

五、评测与回归：如何证明“一致性”真的成立

5.1 指标设计：从单点到分布

多温度系统的一致性评测应至少包含三类指标。第一类是路径内稳定性：同一输入在契约温度下多次采样的输出一致率、引用一致率、格式合法率。第二类是跨路径一致性：同一事实在事实路径与创意路径中被表述时，关键实体与数值是否一致。第三类是会话级一致性：跨轮次的事实口径是否漂移。三类指标分别对应参数层、编排层、体验层的不一致来源。

评测方法上，建议采用“固定 seed 多次采样 + 分布报告”，而非单次结果。对于事实性，可结合人工标注与自动校验（如引用对齐、实体一致性检查）；对于创意性，可用多样性指标（如 distinct-n）与人工偏好共同评估。需要注意的是，自动指标本身也有误差，应报告置信区间而非单点值。

5.2 回归策略：契约变更即回归

把契约对象纳入版本管理，任何字段变更都触发对应路径的回归测试。回归集应覆盖：边界样本（检索低分、证据冲突）、长尾样本（罕见实体、多语言）、以及跨路径会话样本。回归报告应展示变更前后的分布对比，而非仅通过/失败二值。

笔者认为，一致性不是一次性达成的状态，而是持续维护的过程。温度契约的真正价值在于它把“维护”变成了可执行的工程动作：每次变更都有明确的契约差异、明确的回归范围、明确的验收口径。没有契约，一致性就只能靠个人经验与事后救火。

5.3 可观测性：把温度写进日志

建议在调用日志中记录：路径标识、契约版本、实际生效温度、top-p、seed、采样次数、验证器结果。这样当线上出现事实性投诉时，可以快速定位是契约设计问题、实现偏差还是证据问题。可观测性不是附加项，而是契约可审计的前提。

六、边界条件、常见误区与局限

6.1 温度契约不解决什么

必须明确边界：温度契约不能修复错误的知识、不能弥补检索系统的缺陷、不能替代人工审核高风险场景。它解决的是“多温度并存下的行为一致性”，而非“模型是否正确”。把契约当作幻觉治理的万能药，是对其定位的误读。

6.2 常见误区

误区一：认为 T=0 完全确定。实际上浮点非确定性、批处理差异、硬件差异都可能导致微小漂移，严格可复现需要固定 seed、固定批大小、固定 kernel 甚至固定硬件。误区二：认为低温一定更安全。低温可能放大“自信的错误”，在证据缺失时尤其危险。误区三：认为统一温度就能一致。统一温度会牺牲任务适配性，且无法解决编排层覆盖问题。误区四：忽视 top-p 与温度的耦合。只调温度不调 top-p，效果可能被截断掩盖。

6.3 局限与开放问题

当前实践仍缺乏跨厂商的温度语义标准，契约对象在不同框架间迁移需要人工映射；动态温度调整的效果依赖检索分数与冲突检测的准确性，而这些组件本身也有误差；会话级一致性的评测成本较高，难以高频回归。这些都是后续工作需要补齐的环节。

七、结论与展望

回到标题的问题：一个系统里多种温度并存时，谁来保证一致性？笔者的回答是：由“温度契约”这一工程抽象来保证，由采样网关、编排器、节点与验证器四层共同执行，由与线上同口径的评测与回归来证明。温度不是孤立旋钮，而是随机性预算的声明；一致性不是某个数字，而是契约、实现与验收三者的对齐。

展望未来，随着推理系统走向多智能体、多工具、多模态，随机性预算的管理只会更复杂。笔者预计会出现两类演进：一是标准化的“采样契约”描述格式，使跨框架迁移成为配置转换而非人工映射；二是运行时自适应机制，根据证据状态、任务类型与用户反馈动态调整预算，并在日志中留下可审计轨迹。无论哪种演进，核心思想不变：把隐式的随机性变成显式的契约，让一致性成为可设计、可验证、可维护的工程属性，而不是事后祈祷的结果。

八、主要参考文献与拓展资源

以下列出 9 篇主要参考文献，均为公开可查的论文或官方文档；文中提及的数据集与评测细节请以原始文献为准。涉及数据集的预处理说明：本文未直接使用新数据集，所引基准的预处理以其原始论文描述为准，读者复现时应核对版本与划分。

1. Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，2020，arXiv:2005.11401。
2. Chuang 等，DoLa: Decoding by Contrasting Layers Improves Factuality，2023，arXiv:2309.03883。
3. Li 等，Inference-Time Intervention: Eliciting Truthful Answers from a Language Model，2023，arXiv:2306.03341。
4. Manakul 等，SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection，2023，arXiv:2303.08896。
5. Liang 等，Holistic Evaluation of Language Models (HELM)，2022，arXiv:2211.09110。
6. Ji 等，Survey of Hallucination in Natural Language Generation，ACM Computing Surveys，2023。
7. Hugging Face Transformers 文本生成配置文档，链接。
8. vLLM 采样参数文档，链接。
9. OpenAI Cookbook 中关于可复现性与 seed 的实践说明，链接。

拓展学习建议：可结合 LangChain 的表达式语言与回调机制理解编排层参数传递（LangChain LCEL 文档），并结合相关技术讲座视频加深对采样与解码的理解（检索示例）。