非确定性与输出复现
temperature=0 只是每步取最高概率路径，不保证逐字复现；真正的稳定性靠结构化约束与语义断言。
为什么重要
把复现寄托在采样参数上，评估和回归测试就会随机失败；弄清非确定性来源，才能设计可测试、可上线的 LLM 功能。
核心原理
入门条目“温度与采样”讲过 temperature=0 是尽量走最高概率路径（贪心解码）；进阶的事实是，即便如此，同一输入两次调用仍可能逐字不同，因为计算过程没有被冻结。差异有三个来源：浮点——GPU 并行求和顺序不固定，softmax 对末位差异敏感，两个概率几乎并列的候选会因此换序；批处理——服务端把你的请求与别人拼批，批大小会改变归约结果，你的输出受别人流量影响；推理栈——内核、驱动、量化与服务端版本持续演进，云厂商不向你冻结。seed 参数的边界同样要认清：它只在同一厂商、同一实现版本内尽量复现采样路径，不跨版本、不跨厂商担保，也盖不住浮点与拼批差异——当调试辅助用，不当接口契约。工程对策是把“必须一致”从参数转移到结构：用结构化输出把必须一致的字段变成 Schema 约束；评估写语义断言（字段相等、标签合法、引用存在）而非整段精确匹配；快照测试对自由文本留容忍度，真正要逐字确定的规则放进代码执行。
工程实现
- temperature=0 与 seed 当调试辅助，不当稳定性契约
- 必须一致的字段用 Schema 约束生成
- 评估断言写语义条件，不做整段文本精确匹配
- 记录模型与推理栈版本，复现问题先对齐版本
展开说明
工单抽取用 Schema 约束为 category、priority 两个枚举字段后，temperature=0 下字段基本稳定；同一 Prompt 的自由文本理由仍可能换说法，评估只断言字段与枚举合法性——prompt-debugger 的回归报表就是按 Schema 通过率与业务通过率分别统计，而不是比对整段文本。
常见误区
- temperature=0 后断言两次调用逐字相等
- 以为 seed 能跨模型版本、跨厂商复现
- 回归测试对整段自由文本做精确 diff，流水线随机失败
面试怎么说
temperature=0 是贪心解码，不保证逐字复现：浮点求和顺序、服务端拼批和推理栈版本都会扰动末位概率；seed 只在同一实现内尽量复现采样。工程上把稳定性上移——结构化输出锁定必须一致的字段，评估用语义断言，快照测试留容忍度。