2024 年我做一个大模型应用,里面有好几个用 LLM 的地方:一个把用户反馈分类,一个从订单文本里抽字段,还有一个给用户生成营销文案。第一版我做得很省事:不管哪个场景,我都直接调 chat.completions.create,只传 prompt,采样参数一个都不设,全用默认值。本地测了测——真不错:分类分得对,字段抽得准,文案也写得有模有样。我心里很踏实:"调大模型嘛,把 prompt 写好,调一下接口,不就行了。"可等这套东西真正上线、被反复调用,一串问题冒了出来。第一种最先把我打懵:同样一段用户反馈,同样的 prompt,我连跑三次,分类结果居然不完全一样——一会儿"投诉",一会儿"建议"。第二种最磨人:那个抽字段的功能,本该稳定输出固定格式,可它时好时坏,偶尔多个字、偶尔字段名变了样,下游解析动不动就崩。第三种最反直觉:文案功能我嫌它不够有新意,听人说"把 temperature 调高就更有创意",我一口气调到 1.8——结果它不是更有创意,而是直接开始胡说,跑题、堆砌、到后面连句子都不通顺了。第四种最隐蔽:我又听说还能调 top_p,就把 temperature 和 top_p 一起乱调了一通,结果输出更不可控了,我自己都说不清到底是哪个参数在起作用。我盯着这一连串问题想了很久才彻底想明白,第一版错在一个根本的认知上:我以为"采样参数无所谓,默认值就行;真要调,temperature 就是个'创造力旋钮',调高更聪明、调低更死板"。这句话把 temperature 当成了一个语义上的"智能开关"。可它不是。大模型生成文本,是一个字(token)一个字往外蹦的过程;每蹦一个字之前,模型都会算出一个"下一个字该是什么"的概率分布。temperature 和 top_p,根本不是什么创造力旋钮,它们是控制"拿到这个概率分布之后,到底怎么从里面挑出下一个字"的采样参数。temperature 调的是这个分布的"尖锐还是平缓",top_p 调的是"只在概率最高的那一小撮里挑、还是连长尾也算上"。不理解这套底层机制,你调的就不是创造力,而是在盲目地搅动一套你看不见的概率。真正用好大模型的采样参数,核心不是"把 temperature 当聪明程度来调",而是理解 LLM 逐 token 采样的机制、看懂 temperature 在缩放什么、看懂 top_p 在截断什么、按任务的确定性需求来配参数。这篇文章就把大模型的采样参数梳理一遍:为什么"temperature 是创造力旋钮"是错的、temperature 到底在缩放什么、top_p 和 top_k 在做什么、不同任务该怎么配参数、seed 与可复现是怎么回事,以及参数与 prompt 的关系、重复惩罚、参数评测这些把采样真正调对要避开的坑。
问题背景
先把那串问题的现象和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。
现象:一套"只写 prompt、采样参数全用默认值"的大模型调用,上线后冒出一串问题:同样的 prompt,连跑几次结果都不一样;需要稳定格式的抽取任务,输出时好时坏、下游频频解析失败;想让文案更有创意,把 temperature 调到很高,结果它直接开始胡说;听说能调 top_p,把 temperature 和 top_p 一起乱调,输出更不可控。
我当时的错误认知:"采样参数无所谓,默认值就行;temperature 就是个创造力旋钮,调高更聪明、调低更死板。"
真相:要理解 temperature 和 top_p,得先理解大模型生成文本的真实过程。大模型不是一次性"想好"一整句话再说出来的,它是一个 token(可以粗略理解成一个字或词)一个 token 地往外蹦。每蹦出一个 token 之前,模型内部会先算出一组分数(logits)——对词表里每一个可能的 token,都打一个分;这组分数经过一个叫 softmax 的运算,变成一个概率分布:下一个 token 是"的"的概率多少、是"了"的概率多少……然后,从这个概率分布里"采样"出一个 token,作为真正的输出。采样参数,管的就是最后这一步"怎么采样"。temperature 在 softmax 之前缩放那组分数:它越低,分布越尖(高概率的 token 几乎独占,输出趋于确定);越高,分布越平(本来概率很低的 token 也有机会被选中,输出更随机)。top_p 则是截断:只在"概率从高到低累加,刚好够 top_p"的那一小撮 token 里采样,把长尾的低概率 token 直接排除。所以"同样 prompt 结果不一样",是因为默认就带着随机采样;"调高 temperature 就胡说",是因为分布被压得太平,模型把概率极低的、不通顺的 token 也采了出来。这些都不是玄学,是这套采样机制的必然结果。
要把大模型的采样参数用对,需要几块认知:
- 为什么"temperature 是创造力旋钮"是错的——LLM 是逐 token 按概率采样;
- temperature——它缩放的是概率分布的尖锐程度;
- top_p 与 top_k——它们截断的是概率分布的长尾;
- 按任务配参数——确定性任务和创造性任务要的是相反的设置;
- seed 可复现、重复惩罚、参数评测这些工程坑怎么处理。
一、为什么"temperature 是创造力旋钮"是错的
先把这件最根本的事钉死:大模型不是一个"理解了你的问题、然后给出回答"的黑箱,它的生成,本质是一场逐 token 的概率游戏。每生成一个 token,它都在做同一件事:对词表里几万个候选 token 各打一个分,把分数变成概率,再从概率里挑一个。temperature 和 top_p,不作用于"它有多聪明""它多有创意"——它们只作用于最后那个"挑"的动作:是死死盯着概率最高的那个挑,还是把概率不高的也纳入考虑。把 temperature 理解成"创造力",你就会做出"调高一点让它更聪明"这种南辕北辙的操作;把它理解成"采样的随机程度",你才知道自己每一次调,到底在调什么。
下面这段代码,就是我那个"上线就飘忽"的第一版调用:
# 反面教材:不管什么任务,都只传 prompt,采样参数一个不设
from openai import OpenAI
client = OpenAI()
def classify_feedback(text):
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": f"把这条用户反馈分类为'投诉'或'建议':{text}"}],
# 没有 temperature、没有 top_p、没有 seed —— 全用默认值
)
return resp.choices[0].message.content
# 破绽一:默认 temperature 不为 0,同样输入连跑几次,结果会变。
# 破绽二:分类这种确定性任务,本不该有任何随机性。
# 破绽三:抽字段、写文案都用同一套默认参数,等于完全没区分任务。
这段代码在本地测试时表现不错,因为本地我每个功能就跑那么一两次,恰好没撞上随机性翻车的那一次,我便以为它"就是对的"。它的问题不在 prompt 上——prompt 写得没毛病——而在一个被忽略的前提:它默认"大模型对同一个输入,会给同一个输出"。可大模型默认就是带随机采样的。于是那串问题就有了解释:同样 prompt 结果不一样,是因为默认 temperature 不为 0,每次都在概率分布里重新随机采样;抽字段时好时坏,是因为这个本该 100% 确定的任务,被默认参数掺进了随机性;调高 temperature 就胡说,是因为分布被压得太平,模型把概率极低、根本不通顺的 token 也采了出来。问题的根子清楚了:用好采样参数的工程量,全在"承认 LLM 是逐 token 概率采样、采样参数决定怎么采"之后——你不按任务去配它,就只能听天由命。先从最重要的那个参数——temperature——说起。
二、temperature:它缩放的是概率分布的尖锐程度
temperature 的作用,一句话:它在 softmax 之前,缩放那组原始分数(logits),从而改变最终概率分布的"尖锐"还是"平缓"。它的取值通常在 0 到 2 之间。用一段代码把这件事演示出来,比任何文字都直观:
import numpy as np
# 模型对 4 个候选 token 算出的原始分数(logits)
logits = np.array([3.0, 1.0, 0.5, 0.2])
def softmax_with_temp(logits, temperature):
"""temperature 在 softmax 之前缩放 logits,改变分布的尖锐程度。"""
scaled = logits / temperature # 这就是 temperature 起作用的地方
exp = np.exp(scaled - np.max(scaled))
return exp / exp.sum()
# temperature 越低,分布越尖 —— 高分 token 几乎独占
print(np.round(softmax_with_temp(logits, 0.2), 3))
# -> [0.999 0. 0. 0. ] 几乎必选第一个,输出趋于确定
# temperature = 1,分布保持模型原本的样子
print(np.round(softmax_with_temp(logits, 1.0), 3))
# -> [0.79 0.107 0.065 0.048]
# temperature 越高,分布越平 —— 低分 token 也获得了不小的概率
print(np.round(softmax_with_temp(logits, 2.0), 3))
# -> [0.6 0.221 0.116 0.063] 随机性大增,可能采到差的 token
这段输出把 temperature 的真相讲透了:它从不"增加"或"创造"什么,它只重新分配概率。temperature 越低,概率越往高分 token 集中,极端情况(趋近 0)就是每次都选概率最高的那个,输出几乎完全确定;temperature 越高,概率分布被抹平,本来没什么戏的低分 token 也获得了被选中的机会——这看起来像"更有创意",但代价是"也更容易采到不通顺、不相关的 token"。这就解释了开头第三个问题:temperature=1.8 不是让模型变聪明,而是把分布压得太平,逼着它去采那些本该被忽略的烂 token,于是输出就崩了。这里的认知要点是:temperature 不是"创造力",是"对模型自身判断的信任程度"。temperature 低,意味着"我高度信任你算出的概率,你觉得哪个最好,就用哪个";temperature 高,意味着"我不那么信任这个排序,给后面的候选也留点机会"。所谓"创意",不过是高 temperature 下、低概率 token 偶尔被选中带来的副产品——它和"语无伦次"是同一个机制的一体两面,区别只在你把它调到了哪个程度。temperature 是"缩放"整个分布,而另一类参数是直接"切掉"分布的一部分——这就是 top_p。
三、top_p 与 top_k:截断概率分布的长尾
除了缩放分布,还有一种更直接的控制方式——干脆把分布里那些低概率的 token 切掉,根本不让它们参与采样。这就是 top_k 和 top_p。top_k 简单粗暴:只保留概率最高的 K 个 token。top_p(也叫 nucleus sampling,核采样)更聪明:把 token 按概率从高到低累加,加到刚好够 top_p 这个比例为止,只在这一小撮里采样。用代码演示 top_p 的截断逻辑:
import numpy as np
# 某一步,softmax 之后得到的概率分布(已从高到低排好)
probs = np.array([0.55, 0.25, 0.10, 0.06, 0.03, 0.01])
tokens = ["的", "了", "和", "是", "在", "啊"]
def apply_top_p(probs, tokens, top_p):
"""nucleus 采样:只保留累计概率刚好达到 top_p 的那一小撮 token。"""
cumulative = np.cumsum(probs)
# 找到累计概率首次达到 top_p 的位置,只留到这里
cutoff = np.searchsorted(cumulative, top_p) + 1
kept_probs = probs[:cutoff]
kept_probs = kept_probs / kept_probs.sum() # 重新归一化
return tokens[:cutoff], np.round(kept_probs, 3)
# top_p = 0.9:累加 0.55+0.25+0.10=0.90,只在前 3 个里采样
print(apply_top_p(probs, tokens, 0.9))
# -> (['的', '了', '和'], [0.611, 0.278, 0.111])
# top_p = 0.5:只有第一个 token 就够了,几乎等于必选它
print(apply_top_p(probs, tokens, 0.5))
# -> (['的'], [1.0])
top_p 的妙处在于它是自适应的:当模型很笃定(某个 token 概率极高)时,核就很小、几乎只剩那一个;当模型很犹豫(概率分散在很多 token 上)时,核会自动放大、纳入更多候选。下面这张图,把从原始分数到选出一个 token的完整采样流程串起来:
这里的认知要点是:temperature 和 top_p,是从两个不同角度控制随机性的。temperature 是"缩放"——它不删掉任何 token,只是改变大家概率的相对高低;top_p 是"截断"——它直接把长尾那批低概率 token 从候选里剔除。一个常见的实践共识是:这两个参数不要同时大幅调动,容易互相干扰、让你说不清是谁在起作用。通常的做法是固定其中一个(比如 top_p 保持默认),只调另一个。它们共同要回答的问题只有一个:这一步,我允许模型在多大的"候选范围"里去挑下一个字。参数本身讲清楚了,但真正的关键是:具体到一个任务,到底该怎么配?
四、按任务配参数:确定性任务和创造性任务,要的是相反的设置
采样参数没有一套"万能的最优值"——因为不同任务,对"随机性"的需求是相反的。这正是第一版最大的错:分类、抽取、写文案,三个需求截然不同的任务,我用了同一套默认参数。正确的做法是按任务的"确定性需求"来配。第一类是确定性任务——分类、字段抽取、是非判断、把文本转成固定格式。这类任务要的就是"同样输入永远同样输出",随机性是纯粹的有害,所以 temperature 要设成 0:
# 确定性任务:分类、抽取、判断 —— temperature 设 0,杜绝随机性
def classify_feedback(text):
"""分类任务:要的是稳定可复现,temperature 必须为 0。"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": f"把这条用户反馈分类为'投诉'或'建议':{text}"}],
temperature=0, # 关键:每次都选概率最高的 token
max_tokens=10, # 分类结果很短,顺手限制长度
)
return resp.choices[0].message.content
# 抽字段同理:要稳定的结构化输出,temperature 也设 0
def extract_order(text):
"""从订单文本抽字段:确定性任务,同样 temperature=0。"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "从文本中抽取字段,只输出 JSON。"},
{"role": "user", "content": text},
],
temperature=0,
response_format={"type": "json_object"}, # 配合结构化输出更稳
)
return resp.choices[0].message.content
第二类是创造性任务——写文案、起标题、头脑风暴、生成多样的对话。这类任务要的就是"每次不一样、有新意",可以适度调高 temperature——但关键是"适度",通常 0.7 到 1.0 就够了,绝不是越高越好:
# 创造性任务:写文案、起标题 —— 适度调高 temperature,但别过头
def write_copy(product):
"""营销文案:要多样性,temperature 调到 0.9 这个'适度'区间。"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": f"给这个产品写一句有吸引力的营销文案:{product}"}],
temperature=0.9, # 0.7~1.0 足够有新意,又不至于跑飞
# top_p 保持默认,不和 temperature 一起乱调
max_tokens=60,
)
return resp.choices[0].message.content
# 经验区间:确定性任务 temperature=0;一般对话 0.3~0.7;
# 创意生成 0.7~1.0;超过 1.2 就要警惕输出开始不通顺。
这里的认知要点是:配采样参数,第一步永远不是"调参数",而是先问自己一个问题:这个任务,我要的是"可复现",还是"多样性"?这两者是鱼与熊掌。要可复现——分类、抽取、判断——就把 temperature 钉死在 0,让它每次都走概率最高那条路;要多样性——文案、创意——就适度抬高 temperature,但心里要清楚你是在拿"稳定"换"新意",而且这个交换在 temperature 过高时会突然变成拿"稳定"换"胡言乱语"。没有最优参数,只有"和任务需求对得上"的参数。把 temperature 设成 0 之后,会引出一个让人困惑的新问题——这就要说到 seed 和可复现。
五、seed 与可复现:为什么"temperature=0 了还是会变"
把确定性任务的 temperature 设成 0 之后,你可能还会发现一个让人困惑的现象:同样的输入,绝大多数时候输出一致了,但偶尔还是会冒出一点点不一样。原因是:temperature=0 只是让"采样"这一步变得确定(总选概率最高的),但大模型的推理过程里,还有别的来源会引入极微小的不确定性(比如浮点运算、并行计算的顺序)。要追求更强的可复现性,很多 API 还提供了一个 seed 参数——固定随机种子:
# seed:固定随机种子,进一步提升输出的可复现性
def classify_stable(text, seed=42):
"""temperature=0 再加固定 seed,把可复现性拉到最高。"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": f"把这条用户反馈分类为'投诉'或'建议':{text}"}],
temperature=0,
seed=seed, # 固定种子:相同输入 + 相同 seed -> 尽量相同输出
)
# 响应里的 system_fingerprint 标识了模型后端版本,
# 它一旦变了,即使 seed 相同,输出也可能变 —— 要留意它
return {
"result": resp.choices[0].message.content,
"fingerprint": resp.system_fingerprint,
}
但要清醒地认识到:即便 temperature=0 加上固定 seed,大模型 API 给的也只是"尽力的可复现",不是"100% 保证的可复现"。模型服务端一升级(system_fingerprint 会变),同样的输入就可能给出不同输出。这件事对工程上的真正启示是:不要把你的系统正确性,建立在"大模型输出永远一字不差"的假设上。这里的认知要点是:temperature=0 和 seed,是在"尽量减少随机性",而不是在"消灭随机性"。它们能让你的确定性任务从"经常飘"变成"极少飘",但那个"极少"不会变成"绝不"。所以可复现性要分两层来做:一层是用 temperature=0 + seed 尽量稳住模型;另一层、也是更重要的一层,是在模型之外做防御——下游解析要容错,关键判断要校验,绝不假设上游永远给你一模一样的字符串。主干都讲完了,最后是几个真正用起来才会撞见的工程坑。
六、工程坑:参数与 prompt 的关系、重复惩罚与参数评测
五块设计之外,还有几个工程坑,不处理就会让你要么调错方向、要么输出有别的毛病、要么根本不知道参数好不好。坑 1:别指望用 temperature 解决"prompt 没写好"的问题。很多人发现输出不理想,第一反应是去调 temperature。但 temperature 只管"随机性",它救不了一个本身就含糊、有歧义的 prompt。输出方向不对,先改 prompt;输出方向对、只是稳定性或多样性不合适,才调采样参数。这两件事的顺序不能颠倒:
# 坑:输出不对就猛调 temperature —— 方向错了,调参数也白搭
# 正确的排查顺序:先看是"方向问题"还是"随机性问题"
def diagnose(issue):
"""输出不理想时,先分清该改 prompt 还是该调采样参数。"""
if issue in ("答非所问", "漏了要求", "格式不对", "理解错了"):
return "改 prompt:把指令写得更明确、给示例 —— 与采样参数无关"
if issue in ("同样输入结果不稳", "需要可复现"):
return "调采样:temperature 设 0"
if issue in ("输出太单调", "想要更多样"):
return "调采样:适度调高 temperature 到 0.7~1.0"
return "先确认问题属于哪一类,再决定动 prompt 还是动参数"
坑 2:输出重复啰嗦,用 frequency_penalty / presence_penalty,而不是 temperature。有时模型会翻来覆去说同样的词、同样的句式。这不该靠调高 temperature 来治(那会引入别的乱)——而该用专门的重复惩罚参数:
# 输出重复啰嗦?用重复惩罚参数,别用 temperature 硬怼
def write_diverse_copy(product):
"""frequency/presence_penalty 专治用词与话题的重复。"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user",
"content": f"为这个产品写一段介绍:{product}"}],
temperature=0.8,
frequency_penalty=0.5, # 对已高频出现的 token 加惩罚,减少用词重复
presence_penalty=0.3, # 对已出现过的 token 加惩罚,鼓励换新话题
)
# 两个参数取值一般在 0~2;调太高会为了"不重复"而硬凑生僻表达
return resp.choices[0].message.content
坑 3:确定性任务别忘了配 max_tokens 和 stop。分类、抽取这类任务,输出本就该很短。设好 max_tokens 给输出长度兜个底,用 stop 指定遇到某个标记就停止生成,既省 token、省钱,也能防止模型在结果后面画蛇添足。坑 4:参数好不好,要用一组样本量化评测,别凭一两次手感拍板。"我感觉这个 temperature 不错"是不可靠的——尤其确定性任务,稳定性必须用数据说话:同一个输入反复跑很多次,看输出到底一不一致:
from collections import Counter
# 参数好不好要量化:同一输入反复跑,统计输出的一致性
def eval_consistency(call_fn, text, runs=20):
"""把同一输入跑 runs 次,确定性任务应当几乎只有一种输出。"""
outputs = [call_fn(text) for _ in range(runs)]
counter = Counter(outputs)
most_common, count = counter.most_common(1)[0]
consistency = count / runs
return {
"consistency": consistency, # 1.0 表示 runs 次完全一致
"distinct_outputs": len(counter), # 确定性任务这里应当等于 1
"most_common": most_common,
}
# 确定性任务若 consistency 明显小于 1,说明 temperature 没设对
关键概念速查
| 概念 / 参数 | 说明 |
|---|---|
| 逐 token 采样 | LLM 每步算出概率分布,再从中采样一个 token |
| logits | 模型对词表每个 token 打的原始分数,softmax 前的输入 |
| temperature | 缩放 logits,越低分布越尖越确定,越高越平越随机 |
| top_p 核采样 | 按概率累加到 top_p,只在这一小撮候选里采样 |
| top_k | 只保留概率最高的 K 个 token 参与采样 |
| 确定性任务 | 分类、抽取、判断等,temperature 应设为 0 |
| 创造性任务 | 文案、创意等,temperature 取 0.7~1.0 适度调高 |
| seed | 固定随机种子,进一步提升输出可复现性 |
| frequency_penalty | 对高频 token 加惩罚,减少用词重复 |
| presence_penalty | 对已出现 token 加惩罚,鼓励引入新话题 |
避坑清单
- LLM 默认带随机采样,同样 prompt 连跑几次结果可能不同。
- temperature 不是创造力旋钮,它缩放的是概率分布的尖锐程度。
- 分类、抽取、判断等确定性任务,temperature 一律设为 0。
- 创意任务适度调高 temperature 到 0.7~1.0,过高会语无伦次。
- temperature 和 top_p 别同时大幅调,固定一个只调另一个。
- temperature=0 加 seed 也只是"尽量可复现",不是绝对保证。
- 下游解析要容错,别假设模型输出永远一字不差。
- 输出方向不对先改 prompt,采样参数救不了含糊的指令。
- 输出重复啰嗦用 frequency/presence_penalty,别靠调高 temperature。
- 参数好不好要用一组样本反复跑、量化评测,别凭手感拍板。
总结
回头看那串"同样 prompt 结果不一样、抽字段时好时坏、调高 temperature 就胡说、参数一起乱调更不可控"的问题,以及我后来在采样参数上接连踩的坑,最该记住的不是某一组具体数值,而是我动手前那个想当然的判断——"采样参数无所谓,默认就行;temperature 就是个创造力旋钮"。这句话错在它把一个"控制随机采样"的技术参数,理解成了一个"控制聪明程度"的语义开关。我以为调高 temperature 模型就更聪明、更有创意。可我忽略了一件事:大模型生成文本,是一个字一个字按概率采样出来的。temperature 从不让模型"更聪明",它只是改变"采样时,要不要给低概率的字一些机会"——你以为调出来的是创造力,实际调出来的,是它在通顺和胡言乱语之间滑动的那个位置。
所以用好大模型的采样参数,真正的工程量不在"给接口多传几个参数"那几行代码上。那几行,谁都会写。真正的工程量,在于你要承认"LLM 是逐 token 概率采样、采样参数决定怎么采",并据此为每一个任务想清楚它到底要什么:你要的是可复现,就把确定性任务的 temperature 钉死在 0;你要的是多样性,就给创意任务适度抬高 temperature,但守住那个不至于跑飞的上限;你想控制候选范围,就理解 top_p 在截断什么、且别和 temperature 一起乱调;你要更强的可复现,就加上 seed,同时清醒地知道它只是"尽量";输出有重复的毛病,就用重复惩罚参数对症下药、而不是去拧 temperature。这篇文章的几节,其实就是顺着这条线展开的:先想清楚"temperature 是创造力旋钮"为什么错,再讲 temperature 在缩放什么、top_p 在截断什么、不同任务怎么配、seed 与可复现是怎么回事,最后是参数与 prompt 的分工、重复惩罚、参数评测这几个把采样调扎实的工程细节。
你会发现,大模型的采样参数,和现实里"一个人做决定时有多'放飞'"完全相通。设想你让一个助理帮你做选择。temperature 调到 0,就像这个助理极度严谨、毫不冒险——你问他同一个问题一百遍,他一百遍都给你那个他认为最稳妥的答案,一字不差(这就是确定性任务要的);你把 temperature 调高一点,他就放松了些,愿意时不时给你提个不那么显而易见、但挺有意思的主意(这就是创意任务里的"适度");可你要是把 temperature 调到极高,他就彻底放飞了——不管多离谱的念头都往外蹦,前一句还在说产品文案,后一句就跑去聊天气,到最后话都说不成句(这就是 temperature=1.8 的胡说)。而 top_p,就像你事先给他划定一个"靠谱范围":你说"只在你觉得最有把握的那几个选项里挑",他再放松,也不会跳出这个圈。同样一个助理、同样一个问题,可你给他的"自由度"不同,拿到的回答就从"刻板但可靠",一路滑到"天马行空到不可用"——差别不在他聪不聪明,只在你有没有按这件事的需要,把那个"放飞程度"调到了对的位置。
最后想说,大模型的采样参数配没配对,差距永远不会在"本地把每个功能跑一两次、看着都挺好"时暴露——本地你跑的次数太少,恰好没撞上随机性翻车的那一次,你便以为"默认参数就是对的",你会觉得"把 prompt 写好、调一下接口"已经是全部。它只在真实的、同一个功能被反复调用成千上万次、下游还指望它稳定的线上环境里才显形。那时候它会用最磨人的方式给你结账:做不好,你的分类会同一条反馈一会儿一个结果,你的抽取会时不时给出一个下游解析不了的格式,你想要的创意会变成一堆不通顺的胡话;而做对了,你的确定性任务会稳稳地同输入同输出,你的创意任务会在"有新意"和"还通顺"之间待得恰到好处。所以别等"下游同事追问你的接口为什么时灵时不灵"找上门,在你写下那行 create 调用的时候就该想清楚:这个任务要的是可复现还是多样性、temperature 该是 0 还是 0.9、它会不会被随机性坑、它的输出有没有兜底——这一道道工序,我是不是都替它想过了?这些问题有了答案,你写下的才不只是一个"本地能出结果"的调用,而是一套每个任务都拿到了对的随机性、经得起反复调用的可靠大模型应用。
—— 别看了 · 2026