同一句话调用大模型做意图分类,有时分对、有时分错,复现 bug 时还死活复现不出来,我查到底才发现是 temperature 把随机性引了进来:一次 LLM 采样参数设置不当的深度复盘

那个 bug 是测试同学反复说"这个分类时灵时不灵、我复现不了"才暴露的:我们用大模型(LLM)做一个意图分类——把用户输入归类到"查询订单/申请退款/咨询客服"等几个固定意图之一。功能大体能用,可线上总有偶发的分错:同样一句"我要退钱",大部分时候正确分到"申请退款",但偶尔会分到"咨询客服";更让人崩溃的是,测试同学拿着出错的那句话去复现,跑了好几次又每次都对了,bug "自己好了"。我对着这个"薛定谔的分类"查了好久,才看明白,后背发凉:问题出在我调用 LLM 时的一个采样参数 temperature(温度)上。我图省事用了 API 的默认值(往往是 0.7、1.0 这种偏高的值)。而 temperature 控制的,正是模型输出的"随机性":它越高,模型在生成每个 token 时,就越倾向于"不总是选概率最高的那个",而是带点随机地从多个候选里采样;这正是它"有创造性、有多样性"的来源,但也意味着"同样的输入,每次输出可能不同"。对于聊天、写作这种要多样性的任务,高 temperature 是好事;可我这是意图分类——一个需要"确定、稳定、可复现"的任务,我却给它配了个带随机性的高 temperature,于是同一句话,模型偶尔就"掷骰子掷偏了",采样到了一个不那么靠谱的答案,分错了类。问题的根,是我没理解 temperature 的作用,给一个"需要确定性"的任务用了"引入随机性"的高 temperature——还因这随机性导致 bug 难以复现。这篇就把这次"采样参数设置不当"的坑,从头到尾复盘一遍。

故障现场:确定性任务却用了高 temperature

问题在于给一个需要确定输出的分类任务,用了引入随机性的默认高 temperature:

# ✗ 出问题的代码: 分类任务用了默认(偏高)的 temperature
def classify_intent(user_input: str) -> str:
    resp = client.chat.completions.create(
        model="gpt-4",
        messages=[
            {"role": "system", "content": "把用户输入分类到: 查询订单/申请退款/咨询客服。只输出类别名。"},
            {"role": "user", "content": user_input},
        ],
        # ✗ 没设 temperature → 用默认值(常见默认0.7~1.0, 偏高, 有随机性)
    )
    return resp.choices[0].message.content

# 现象:
# - 同一句"我要退钱": 大部分时候→"申请退款"(对), 偶尔→"咨询客服"(错);
# - 测试复现时跑几次又都对了 → bug"自己好了"、难以复现;
# - 这是典型的"非确定性"行为: 同样输入, 输出会变。

# 为什么? temperature 控制输出的随机性:
# - LLM生成每个token时, 会算出"下一个token的概率分布"(哪个词更可能);
# - temperature=0: 永远选概率最高的那个token → 输出【确定、可复现】(同输入同输出);
# - temperature越高(如0.7/1.0): 越倾向于"带随机地从高概率的几个里采样", 不总选最高的;
#   → 引入随机性 → 同样输入, 每次输出可能不同 → 有创造性/多样性, 但【不确定、不可复现】。
# - 对"分类"这种确定性任务: 这随机性纯属有害 → 偶尔采样到次优答案 → 分错。

# 补充: 即使temperature=0, 也不100%保证完全确定(浮点/并行/模型更新等仍可能有极小差异),
#       但它已是"尽可能确定"的设置, 对分类/提取等任务必须用。

# 关键: temperature控制LLM输出的随机性; 确定性任务(分类/提取/结构化输出)用了默认的高temperature,
#       会让同样输入产生不同输出(偶尔分错), 且随机性导致bug难复现 —— 任务性质和采样参数不匹配。

第一次定位到"是 temperature 在给我的分类掺随机性"时,我又懊恼又恍然:"我一直把 LLM 当成一个'输入啥就稳定输出啥'的函数,完全没意识到它默认是带随机性的,更没想到这随机性能让我的分类时对时错、还让 bug 复现不出来。"这个坑最折磨人的地方在于:它偶发且难复现——正因为是随机的,你去复现时它很可能又"碰巧对了",让你怀疑人生、甚至以为是别的原因;而"难复现"恰恰是它的症状本身(随机性的直接体现),却最容易把排查引向歧途。下面就来拆解,temperature 等采样参数到底怎么回事、该怎么配。

第一件事:搞懂 temperature 等采样参数的作用

我顺着这次事故,把 LLM 的采样参数和"确定性 vs 随机性"彻底理清了。

LLM 的 temperature / top_p 等采样参数到底控制什么?

【核心: LLM本质是"按概率分布采样下一个token"; temperature控制采样的随机性; 确定性任务用temperature=0, 创造性任务才调高】

1. LLM 生成的本质: 按概率采样
   - 模型每生成一个token, 都先算出"下一个token的概率分布"(每个候选词的可能性);
   - 然后"按某种策略"从这个分布里选一个 → 采样参数控制的就是这个"选的策略"。

2. temperature(温度): 控制随机性的强弱
   - temperature=0: 贪心, 永远选概率最高的token → 【确定性】, 同输入同输出, 可复现;
   - temperature适中(0.7): 按概率带随机地采样, 高概率的更可能被选, 但低概率的也有机会;
   - temperature高(1.0+): 更平、更随机, 输出更多样、更"发散"(也更可能跑偏/胡说);
   - 直觉: temperature像"创造性/放飞程度"的旋钮, 越高越天马行空、越不可预测。

3. top_p(核采样)/top_k: 另一种控制采样范围的方式
   - top_p=0.9: 只从"累积概率前90%"的候选里采样(砍掉长尾低概率词);
   - top_k=k: 只从概率最高的k个候选里采样;
   - 它们和temperature配合, 共同决定采样的随机程度。

4. 任务性质决定参数:
   - 【需要确定性/准确性】的任务: 分类、信息提取、结构化输出、SQL/代码生成、是非判断
     → temperature=0(或很低)! 要的是"稳定、可复现、选最可能的正确答案";
   - 【需要多样性/创造性】的任务: 闲聊、写作、头脑风暴、文案生成
     → temperature适当高(0.7~1.0), 要的是"有变化、不千篇一律"。

5. 本文的错: 任务性质和参数不匹配
   - 意图分类是【确定性任务】, 却用了默认的高temperature(随机性) → 偶尔采样到次优 → 分错+难复现。

6. 额外好处: temperature=0 让结果可复现 → 便于测试、调试、回归
   - 随机输出难测试(同输入不同输出, 断言怎么写?); 确定输出才好做测试和复现。

一句话: LLM按概率采样下一个token, temperature控制采样的随机性(0=确定选最高、越高越随机发散);
   分类/提取等确定性任务必须用temperature=0(稳定可复现), 闲聊/创作等才调高; 任务性质决定采样参数。

这套认知,是整个坑的根。LLM 生成的本质:按概率采样——每生成一个 token 都先算出概率分布,再"按某种策略"选一个,采样参数控制的就是这个策略。temperature 控制随机性:=0 贪心永远选概率最高的(确定、同输入同输出、可复现);适中(0.7)带随机采样;高(1.0+)更随机更发散(也更易跑偏);像"创造性/放飞程度"的旋钮。top_p/top_k:另一种控制采样范围的方式,和 temperature 配合。任务性质决定参数:需要确定性的任务(分类、提取、结构化、SQL/代码、是非判断)用 temperature=0;需要多样性的任务(闲聊、写作、头脑风暴)才调高。本文的错:意图分类是确定性任务却用了默认高 temperature→偶尔采样到次优→分错+难复现。额外好处:temperature=0 让结果可复现、便于测试调试。一句话:LLM 按概率采样下一个 token,temperature 控制采样的随机性(0=确定选最高、越高越随机发散);分类/提取等确定性任务必须用 temperature=0,闲聊/创作等才调高;任务性质决定采样参数。

第二件事:正解——确定性任务用 temperature=0,并配合其他稳定手段

搞懂了原理,正解就清晰了:给分类、提取这类确定性任务设 temperature=0;同时用约束输出格式、给清晰的类别定义和示例、校验输出等手段进一步稳住;别依赖默认值。

# ====== 正解一: 确定性任务设 temperature=0 ======
def classify_intent(user_input: str) -> str:
    resp = client.chat.completions.create(
        model="gpt-4",
        messages=[
            {"role": "system", "content": (
                "把用户输入分类到以下类别之一, 只输出类别名, 不要其他内容:\n"
                "- 查询订单: 用户想查看订单状态/物流/详情\n"
                "- 申请退款: 用户想退款/退货/退钱\n"
                "- 咨询客服: 其他咨询/投诉/人工\n"
            )},
            {"role": "user", "content": user_input},
        ],
        temperature=0,        # ★ 关键! 确定性任务设0, 稳定、可复现、选最可能的正确答案
    )
    return resp.choices[0].message.content.strip()
# → temperature=0后, 同样的"我要退钱"每次都稳定分到"申请退款", 不再偶发分错、可复现。

# ====== 正解二: 配合"约束输出 + 校验"进一步稳住 ======
VALID = {"查询订单", "申请退款", "咨询客服"}
def classify_safe(user_input: str) -> str:
    result = classify_intent(user_input)
    if result not in VALID:           # ★ 校验: LLM输出不在合法集合里(幻觉/格式偏差)
        return "咨询客服"             # 兜底到一个安全的默认类别(或走人工/重试)
    return result

# ====== 让确定性LLM任务更稳的组合手段 ======
# 1. temperature=0(或最低): 去掉随机性, 这是地基;
# 2. 清晰的指令和类别定义: 每个类别给明确定义/边界/例子(few-shot), 减少模型"理解偏差";
# 3. 约束输出格式: 明确"只输出类别名"; 或用function calling/JSON mode/结构化输出(同357篇);
# 4. 校验输出 + 兜底: 输出不在合法集合就兜底/重试, 别盲信LLM一定按要求来(它仍可能幻觉);
# 5. 评测集 + 回归: temperature=0可复现, 建一个标注好的评测集, 改prompt/换模型后跑回归看准确率;
# 6. 必要时多次投票: 关键场景可调用多次取多数(但temperature=0时多次相同, 多样性投票需略升temperature)。

# ====== 选参数的原则 ======
# 问自己: "这个任务, 我要的是'稳定一致的答案', 还是'有变化有创意的答案'?"
#   - 要稳定一致(分类/提取/判断/SQL/计算) → temperature=0;
#   - 要有变化创意(闲聊/写作/起名/头脑风暴) → temperature 0.7~1.0;
#   - 别用默认值"蒙", 显式地按任务设置。

# 核心: 确定性任务(分类/提取/结构化)显式设 temperature=0(稳定可复现), 再配合清晰指令、
#   约束输出、校验兜底、评测回归; 按"要稳定还是要创意"显式选采样参数, 别用默认值蒙。

修复的核心,是"按任务性质显式设 temperature,确定性任务设 0"。正解一:确定性任务设 temperature=0——同样的输入每次稳定输出、可复现,不再偶发分错。正解二:配合约束输出+校验——输出不在合法类别集合就兜底/重试,别盲信 LLM 一定按要求来(仍可能幻觉)。让确定性 LLM 任务更稳的组合:temperature=0 是地基、清晰的类别定义和示例(few-shot)、约束输出格式(JSON mode/结构化)、校验输出+兜底、用可复现的评测集做回归。选参数的原则:问"我要稳定一致的答案,还是有变化有创意的答案?"——要稳定就 temperature=0,要创意才调高,别用默认值蒙。归根结底:确定性任务(分类/提取/结构化)显式设 temperature=0(稳定可复现),再配合清晰指令、约束输出、校验兜底、评测回归;按"要稳定还是要创意"显式选采样参数,别用默认值蒙。

第三件事:LLM 应用开发中其他常见的坑

排查后我把 LLM 应用开发中其他容易踩的坑也系统梳理了一遍。

LLM 应用开发的其他常见坑

# 1. 采样参数不当(本文): 确定性任务用高temperature→输出不稳。→ 分类/提取用temperature=0。

# 2. 盲信LLM输出格式/内容(同357篇): 不校验, 幻觉/格式偏差直接用。→ 校验+兜底+结构化输出。

# 3. 上下文窗口超限: 输入太长被静默截断, 丢了关键信息。→ 控制长度/分块/摘要。

# 4. 没有超时/重试/限流: LLM调用慢或失败拖垮请求(同355篇)。→ 超时+重试+降级。

# 5. 成本失控: 每次都调最贵的模型/不缓存重复请求。→ 缓存、按需选模型、控token。

# 6. prompt里塞了不可信的用户输入: 可能被注入扰乱指令。→ 隔离/限定用户输入的作用域。

# 7. RAG检索质量差(同345篇): 召回不准/chunk切坏, 喂给LLM的上下文就错。→ 优化检索与分块。

# 8. 没有评测/全靠人工感觉: prompt改了不知道变好变坏。→ 建评测集, 量化准确率。

# 共同根源: LLM是个"概率性的、不确定的、可能出错的"组件, 不是传统的确定性函数;
#   把它当成"输入啥就稳定正确输出啥"的可靠函数来用, 就会在它的"不确定性/会犯错"上踩坑。

# 核心: 把LLM当"概率性、会变、会错"的组件对待 —— 确定性任务关掉随机(temperature=0)、
#   不盲信输出(校验兜底)、控成本与上下文、加超时重试、用评测量化; 用工程手段驯服它的不确定性。

排查让我把 LLM 应用开发的其他坑也梳理清了。一、采样参数不当(本文)。二、盲信 LLM 输出(校验兜底)。三、上下文窗口超限。四、没有超时/重试/限流。五、成本失控。六、prompt 里塞不可信用户输入。七、RAG 检索质量差。八、没有评测全靠感觉。它们的共同根源是:LLM 是个"概率性的、不确定的、可能出错的"组件,不是传统的确定性函数;把它当成"输入啥就稳定正确输出啥"的可靠函数来用,就会在它的"不确定性/会犯错"上踩坑。核心是:把 LLM 当"概率性、会变、会错"的组件对待——确定性任务关掉随机(temperature=0)、不盲信输出(校验兜底)、控成本与上下文、加超时重试、用评测量化;用工程手段驯服它的不确定性。下面这张图,是这次采样参数坑的成因与解法:

第四件事:低 temperature vs 高 temperature 对比表

这次踩坑后,我把不同 temperature 的特性和适用场景对比成一张表。

这张表把 temperature 的两端钉清了。核心是:temperature 本质是一个"确定性 ↔ 创造性"的权衡旋钮——调低,换来"稳定、可靠、可复现",代价是"少了变化";调高,换来"多样、有创意",代价是"不可预测、可能跑偏";没有"最好的 temperature",只有"最适合当前任务的 temperature"。它给我的最大启发是:"确定性"和"创造性/多样性"在很多系统里是一对需要权衡的矛盾——你想要可靠可复现,往往就得牺牲变化;你想要灵活有创意,往往就得接受不可预测;关键不是"追求其中一极",而是"认清当前任务到底更需要哪一个, 然后把旋钮调到匹配的位置"。这给了我一种使用一切"可调参数/可配置项"的清醒:面对一个参数(temperature、缓存时间、超时、重试次数、一致性级别),不要用默认值蒙、也不要追求某个"万能最优值"——而要理解它调节的是"哪两种诉求之间的权衡",再结合"当前场景更看重哪个诉求"去显式设定;"理解参数背后的权衡、按场景诉求显式调节",是用好一切可配置系统的关键,而非把选择权交给默认值。认清 temperature 是确定性与创造性的权衡旋钮、按任务诉求显式调节而非用默认值——是这个坑带给我的认知。

第五件事:这次事故暴露的"非确定性 bug 的隐蔽性"

这次让我反思更深一层:这个 bug 之所以难缠,是因为它是"非确定性"的——时有时无、难以复现。我把"确定性 bug"和"非确定性 bug"对比成表。

这张表道出了这类 bug 的可怕。核心是:这个 bug 难,难在它的"非确定性"——"时对时错、难以复现"让它极难定位:你抓着出错的 case 去查,它却"碰巧又对了",让你误以为是偶然、是环境、是别的原因;而破解它的钥匙,是意识到"同样输入却不同输出"本身就是一条强烈的线索——它在喊"这里有不确定性的来源!",然后去定位那个来源(这次是 temperature)。它给我的深刻启发是:当一个 bug 表现出"时有时无、难以复现"时,这不是"玄学",而是一个明确的信号——"系统里某处引入了'不确定性'";排查它,要从"看逻辑对不对"转向"找哪里引入了不确定性"——常见的来源就那么几类:随机数、并发/竞态、时序/时间依赖、未初始化、外部状态变化、(LLM 这种)概率性组件;"把'难复现'本身当成线索, 去追查不确定性的源头",是攻克这类玄学 bug 的正确姿势。这给了我一种面对偶发问题的方法论:遇到"偶发、难复现"的问题,第一反应不是"多跑几次碰碰运气"或"当成偶然忽略",而是系统地排查"这条路径上, 有哪些可能引入不确定性的因素?"——并设法把它们"钉死"(如把随机种子固定、把 temperature 设 0、把并发串行化)来稳定复现;"用'消除不确定性'的思路, 把偶发 bug 变成稳定可复现的 bug",是解决它的第一步、也是关键一步。认清难复现是不确定性的信号、追查并钉死不确定性源头——是这个 temperature 坑带给我的认知。

第六件事:调用 LLM 前,我现在的自检习惯

现在每当我要调用 LLM 完成一个任务,我都会先按这张图问自己:

这张图的精髓,是"先按'要稳定还是要创意'显式设 temperature,确定性任务必设 0"。要稳定一致temperature=0、要创意调高、输出被程序用约束+校验+兜底,绝不用默认值蒙。这套习惯,让我从"调 LLM 不管参数直接用默认"变成了"先想任务要稳定还是要创意、显式设采样参数"——核心始终是:确定性任务(分类/提取/结构化)显式设 temperature=0 去掉随机性保证稳定可复现,创造性任务才调高,别用默认值蒙、别盲信 LLM 输出。

我立下的几条规矩

这场"分类时对时错、bug 还死活复现不出来"的事故,换来了我用 LLM 开发时,刻进骨子里的几条铁律:

1. LLM 是概率性组件,默认带随机性,不是确定性函数。这是用它的前提认知。
2. temperature 控制输出的随机性:0 最确定可复现,越高越随机发散。
3. 分类/提取/判断/SQL 等确定性任务,显式设 temperature=0。别用默认值。
4. 闲聊/写作/头脑风暴等需要多样性的任务,才把 temperature 调高。
5. 输出被程序使用的,要约束格式 + 校验 + 兜底。别盲信 LLM 一定按要求来。
6. temperature=0 让结果可复现,便于建评测集做回归。prompt 改动能量化对比。
7. 偶发、难复现的 bug,先去找"哪里引入了不确定性"。难复现本身就是线索。

写在最后

回头看,这场由"一个没设的 temperature 默认值"引发的、分类时对时错的事故,真正教给我的,远不止"分类任务设 temperature=0"这一个技巧。它让我对"当我们引入一种'和过去范式不同的新东西'(这里是概率性的 LLM)时, 不能继续用'旧东西的心智模型'(确定性的函数)去想当然地使用它",有了一次刻骨的体会。我栽跟头,是因为我用对待"传统函数"的心智模型,去对待一个"概率性的大模型"——在我过去的整个编程经验里,"调用一个函数,输入相同,输出就一定相同"是天经地义的公理;于是我下意识地假设"调用 LLM 做分类,同样的输入就该有同样的输出",压根没去想"它默认是带随机性的、同样输入会给不同输出";我把一个本质上是"概率采样器"的东西,当成了"确定性函数"来用,于是被它的随机性结结实实地绊了一跤。这让我领悟到一个关于"新范式与旧心智"的深刻认知:每当一种范式不同的新技术出现(概率性 AI 之于确定性程序、异步之于同步、分布式之于单机、不可变之于可变),最大的陷阱往往不是"新技术本身有多难",而是"我们会不自觉地用旧范式的心智模型和假设, 去套用这个新东西"——而那些旧假设(如"同输入同输出"),在新范式里可能根本不成立;"用旧地图, 走新大陆",必然迷路。这给了我一种拥抱新技术时的根本清醒:学习/使用一种"范式不同"的新技术时,要做的第一件事,是主动地问"这个新东西, 它的'基本性质/行为假设', 和我熟悉的旧东西有什么根本不同?我有哪些'想当然的假设'在这里是不成立的?"——对 LLM, 就是认清"它是概率的、会变的、会错的", 而非确定可靠的函数;"为新范式更新自己的心智模型、识别并丢弃不再成立的旧假设",是真正驾驭一项新技术、而非用旧思维误用它的关键。认清新范式不能用旧心智去套、主动更新心智模型识别失效的旧假设——这,是我用一次 temperature 的事故,换来的、关于 LLM 应用、也关于如何拥抱范式不同的新技术的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次用 LLM 做分类、提取这类任务时,顺手把 temperature 设成 0、并记住"它是个会掷骰子的概率组件",那我对着那个"薛定谔的分类"排查的这段时间,就值了。

—— 别看了 · 2026