同一个Prompt一字不改地跑三次返回三种答案这事儿你多半遇到过。第一次还是正经回答第二次换了个角度第三次直接开始自由发挥。很多人第一反应是我Prompt写得不行再试几次发现还是变于是开始怀疑模型有“性格”甚至觉得平台在“抽风”。先别急着改需求这个现象背后有明确的数学原理和工程细节而且绝大多数情况下是可以被控制的。这篇文章不讲玄学。我会从模型生成机制讲清楚“为什么变”再把temperature、top-p、seed这些参数逐个拆开最后用一套完整实操过程告诉你怎么让程序化调用稳定得像个普通函数。适合正在做AI应用、用API做自动化、或者在对话产品里被“随机性”折磨的开发者和爱好者。看完你至少能学会判断哪些变量你说了算哪些变量是平台说了算以及怎么把“随缘”变成“可控”。1. 先接受一个事实大模型天生就是个概率机器1.1 模型选词不是“查标准答案”而是“掷骰子”很多人默认问大模型同一个问题就应该拿到同一个标准答案。这其实是对生成机制的误读。大模型在生成文本时并不是先想好一整段“标准答案”再写出来而是逐token地预测下一个字。每一步模型都会对词表里几万个候选token分别打一个分再把分数转换成一个概率分布。它给每一个可能的token都分配了一个“中奖概率”然后从这组概率里抽一个作为下一个token。这个“抽”字是关键。默认情况下很多模型接口用的是采样方式也就是真的在按概率随机抽取而不只是选概率最大的那一个。用一个不太贴切但很好懂的类比考试时让你做一道选择题你有70%把握选A、20%选B、10%选C如果要求你“随机蒙一个”三次可能蒙出三个不同答案。模型每次生成的差异本质上就是它在每个位置都重复着类似的“随机抽取”。这也解释了为什么输出的差异通常不是“整体重写”而是“局部漂移”。开头几句往往高度一致越往后越容易分岔因为每一次选词产生的差异又会作为下一次预测的输入把两条路径越推越远。很多人感觉“同一句话每次都不一样但好像又没有完全不一样”根源就在这里。1.2 温度和采样参数你手里最直接的“随机性开关”最常被提到的参数是temperature。它的作用是调整概率分布的“尖锐程度”。softmax公式里会除一个Tp_i exp(z_i / T) / Σ exp(z_j / T)。T越小高分token的优势越突出概率分布越集中在少数高概率token上T越接近0模型越倾向于每次都选概率最高的token输出就越保守。T越大分布被摊平低概率token被选中的机会变大输出就越跳脱。T等于0时实现上基本退化成argmax每次直接选概率最大的token。除了temperature还要注意top_p和top_k这类截断策略。top_p是从高概率往低概率累加只保留累积概率达到p的那部分token作为候选丢掉尾部可能生成“怪话”的tokentop_k则是硬性保留概率最高的K个token。它们本身不直接决定“随机多少”但决定了模型在多大范围内随机。另外还有frequency_penalty和presence_penalty这类惩罚项它们会改写logits前者按出现次数打压已经说过的词后者只要出现过就压一次。这两者对控制重复率很有效但也直接改变了最终概率分布是影响稳定性的重要来源。还有一个容易踩的点不同平台的默认参数差别很大。有的对话产品默认temperature在0.7到1.0左右还额外开了presence_penalty这种情况下输出必然是“活”的。你拿一个默认参数的对话网页去反复测试同一句话得到的当然是连续漂移的记录。我发现不少朋友拿着聊天网页的输出来质疑某个自动化接口不稳定其实两者连参数都不是同一套结论自然站不住。2. 参数明明一样输出还是变这些“隐形变量”更值得查2.1 你以为的“一模一样”在Token层面可能并不同很多人做复现测试时是在界面上手动复制同一个问题或者用脚本传同一个字符串。但模型看到的输入和你在屏幕上看到的文本中间还隔着一层tokenizer。全角半角、末尾空格、换行符、系统帮你加在Prompt前后的隐藏字符串都可能被拆分成不同的token序列。对模型来说这些是不同的输入输出不同再正常不过。我排查过一个案例同一个请求只是因为拼接时多了一个换行符结果就从基本稳定变成了明显漂移。还有一个特别容易忽略的变量请求里塞了请求时间、随机编号、用户ID这些动态字段。有时候是框架自动加的trace信息有时候是你在Prompt模板里不自觉地引入了“当前时间xxx”。这些字段只要进入了上下文就等于每次输入都在变。要测稳定性就得先把所有动态内容从输入里剔除干净再去看模型本身的波动。多轮对话场景的稳定性问题更隐蔽。如果上一轮的模型输出被保留为下一轮的上下文那么上一轮回答不同下一轮拿到的上下文就不同误差会持续累积。你以为是在重复测同一个Prompt实际上每轮的“历史”都不一样。做对比测试的时候尤其要警惕这种上下文污染否则你测出来的差异可能是多个变量叠在一起的结果。2.2 服务端的“变量”版本更新、非确定性计算接下来是你控制不了的部分。商用大模型接口背后是持续迭代的服务模型权重可能在你不知道的时候被替换成新版本或者同一个模型名下的推理服务在后台调整了量化方式、batch策略、缓存策略。只要模型本身的权重或推理路径变了同样的Prompt加同样的参数输出分布就会整体移动。这不是玄学而是服务端版本管理的问题。对依赖外部接口的项目来说这个因素迟早会找上门。GPU上的浮点计算还有另一层非确定性。矩阵乘法在并行reduce时浮点数累加的顺序可能因为batch大小、当前负载情况而改变产生极小但真实存在的数值差异。正常情况下这种差异微乎其微但如果两个token的概率本来就非常接近一点点误差就可能让“随机抽取”的结果翻转。所以有些平台会在文档里明确写即使固定seed结果也只能保证“高度一致”不保证“逐token完全一致”。2.3 T0也翻车聊聊“绝对稳定”的边界很多人把T0当成万能锁设了之后发现输出还是会变于是开始骂平台。先别急。T0在大多数实现里确实会变成贪心解码也就是永远选概率最高的token这能让输出基本确定。但有两个例外需要注意第一如果平台同时开了penalty概率分布会被持续改写贪心选择的结果也会跟着变第二如果平台用了beam search或其他复杂解码策略即使T0也不一定是简单的argmax。换句话说你只设了一个参数并不能代表整个解码链路都是“确定性”的。更现实的情况是当两个候选token概率无限接近时服务端一丁点数值漂移就可能导致选边不同。所以T0能压制大多数不稳定因素但不要把它理解为“绝对保证”。真正追求可复现的时候我的习惯是同时满足三个条件temperature0或接近0、penalty全部关闭、输入字符串逐字节一致。至于固定seed是进一步的保险而不是必要条件。3. 给输出上锁从对话场景到程序化调用的稳定性方案3.1 先分场景你要的是“确定性”还是“多样性”在讨论参数之前先回答一个产品问题你的场景到底需不需要每次一致对话产品如果每次回复都一模一样用户会觉得这是个假AI但程序化调用如果每次结果都不同下游业务根本没法接受。需求不同参数策略完全相反。对话场景我一般保留temperature在0.7到1.0甚至故意加一点penalty去减少重复自动化任务则反过来把temperature往低处压能0就0并且关掉所有增加多样性的参数。还有一种中间情况写作辅助、头脑风暴这类工具既要稳定又不希望完全死板。我的建议是给用户提供一个“随机性滑杆”底层就是temperature三档比如0.3、0.7、1.0再在前端明示“调整这个参数会让结果不同”。很多产品把这个选项藏起来用户才会觉得“模型怎么每次都不一样”进而对产品产生不信任。3.2 四步锁随机参数、seed、格式约束、后处理如果你的任务就是要一个稳定输出我推荐按下面四步来做。第一步把temperature设为0或0.1把frequency_penalty和presence_penalty全设为0。这一步能消灭大部分随机性。第二步如果平台支持seed参数就固定一个整数。seed固定了随机数发生器的初始状态在相同输入和相同概率分布下采样结果就能复现。注意固定seed的同时temperature也要保持一致否则seed的实际意义不大。第三步在Prompt层面给输出划定范围。最有效的方式是few-shot示例加明确格式要求。比如让模型只输出JSON并给出字段枚举或者让它只能从给定列表里选一个答案。这相当于把概率分布的可选择范围大幅收窄即使模型内部还有一点随机性也翻不出这个圈子。下面是一个在项目里实际用过的Prompt结构请对下面的客服工单进行分类只能从候选类别中选择一个并输出JSON {category: 退款 | 发票 | 物流 | 其他} 候选类别定义 - 退款涉及退钱、退款申请、金额退回 - 发票涉及开票、发票抬头、税号 - 物流涉及发货、签收、快递进度 - 其他以上都覆盖不到的情况 工单内容昨天买的商品申请退款商家让我先寄回去运费谁来出 参考示例 {category: 退款}请求参数固定成下面这样{ temperature: 0, top_p: 0.1, frequency_penalty: 0, presence_penalty: 0, seed: 42, max_tokens: 128 }这一步在大部分平台上都能直接传参参数名可能叫temperature、temp或别的名字含义都一样。如果你用的SDK版本较老默认值往往不是0记得在每次请求里显式传值不要依赖服务端默认值。我另外提醒一句有的平台对seed的语义解释不同有的要求seed配合temperature同时生效有的文档里直接声明“即使固定seed也不保证结果完全一致”。这类平台就别指望它做严格复现了直接用低temperature加格式约束反而更实在。核心思想就一句话把能关的多样性开关全关掉让生成尽可能退化成贪心解码。第四步是后处理兜底。无论前面怎么约束模型偶尔还是可能输出格式不合法或者不在枚举列表里的内容。这时候不能直接报错要用正则或枚举匹配去纠正实在解析不了再走一次重试。很多项目把这一步省略结果10%的请求因为一个多余的反引号挂掉稳定性直接崩了。后处理看起来不酷却是稳定系统里最结实的一道保险。3.3 多个样本投票把“不稳定”变成可用的稳定性有些任务没有标准答案或者模型即使T0也仍会漂移。这时候可以用工程方法把随机性转化为优势多次采样然后按规则投票。比如让模型生成N次结果去掉完全相同的统计每个答案出现的次数取多数或者让模型同时输出“理由”和“结论”再按理由的可信度排序。这套思路在质量评估、内容评审、分类打标的场景很管用本质上是拿多次采样的多样性来对冲单次采样的随机性。具体操作上不要盲目把N设得很大。N取3到5通常就够了N越大成本越高边际收益下降很快。投票规则也要提前定死不要用“人工看着挑”否则又回到了不稳定。如果输出是结构化文本可以先归一化再统计如果是自然语言可以用语义相似度或者让另一个模型做裁决。注意这类方案只适合离线或延迟不敏感的场景实时接口直接用低温度更省事。4. 实操记录一个客服分类项目从“乱答”到“可复现”的折腾过程4.1 排查起点这个不稳定对业务是致命的某开发者A同学接了一个客服工单自动分类的活上游系统每天把大量工单推到接口里要求自动判断这是“退款”、“发票”、“物流”还是“其他”。需求方上来就提了硬性要求同一个工单无论什么时候重测分类结果必须一致。A同学一开始没当回事觉得大模型接口加个Prompt不就行了。结果联调第一天就翻车同一个工单跑了三次一次“退款”一次“发票”一次“其他”。这个项目后来我作为技术顾问参与排查整个过程很有代表性。4.2 三次调整参数、Prompt结构、输出约束第一轮调整只动参数不改Prompt。当时接口的默认temperature是0.7还开着presence_penalty。先把temperature降到0penalty全部关掉同时固定了seed。实测下来绝大多数工单确实稳定了但还有一小部分工单在两个相近类别之间摇摆比如“退款”和“发票”会因为都提到“钱”而被误判。这说明参数只能压住随机性压不住语义本身的模糊。这轮调整的价值是帮我们把“随机性”和“准确率”两个问题拆开后面修Prompt时才不会混在一起调。第二轮调整在Prompt上下工夫。原来的Prompt就是一句“请判断工单属于哪个类别”类别名后面只有一个冒号和一句说明。我们改成先枚举四个候选类别每个都给出明确的判定规则再给两条few-shot示例一条标准答案一条容易被绕进去的干扰项最后要求只输出一个JSON字段。这里的关键是把选择空间从“开放式”变成“穷举式”模型就没多少自由发挥的余地了。第三轮是后处理。即使做了前两步偶尔还是会出现输出里带着解释、或者category字段不在枚举里的情况。于是加了一道校验解析JSON失败就重试一次仍失败就归为“其他”枚举匹配时用模糊匹配兜底比如“退款”写成“退 款”也能对齐。三轮做完再跑同一个测试集稳定性和分对率都明显上来了。4.3 用数据说话一致性是怎么一步步涨上去的我挑了一批固定数量的测试工单每条工单重复调用固定次数统计“完全一致”的比例和“正确率”。下表是三个阶段的数据数字来自当时项目里的实测记录阶段处理方式同工单重复调用一致性分类正确率基线默认参数 一句话Prompt约72%88%第一轮T0、penalty关闭、seed固定约91%89%第三轮参数 结构化Prompt 后处理99.2%96.1%注意看从基线到第一轮一致性涨了将近20个百分点但正确率几乎没动。模型只是从“随机选一个看起来合理”变成了“稳定选一个看起来合理”。真正让正确率大幅提升的是Prompt结构调整和后处理。这个顺序很关键先锁参数再修语义最后做兜底每一步解决的问题都不一样。4.4 过程里踩过的坑值得你提前避开列几条当时真实踩过的坑。第一测试脚本里带了一个动态生成的请求ID每次都不同排查了大半天最后把请求体逐字节对比才发现。第二有一个类别的few-shot示例本身写得有歧义模型很稳定地“学歪了”这不是随机性问题是样本问题。第三某天线上结果突然又飘了查了很久才确定是平台侧模型权重更新之前调好的Prompt在新权重上行为出现了变化。这个事提醒我凡是依赖外部API的稳定性项目都要在日志里记录model版本并且常备一个固定的benchmark集每次改动后都跑一遍。5. 常见问题速查稳定输出的排查清单5.1 现象、原因、解决方式速查表下面这张表是我日常排查几乎每天都会用到的先对号入座再动手比瞎调参数快得多。表的思路是先看现象再想原因不要一上来就怀疑模型很多问题其实出在你自己那边的配置或输入上。列得比较粗但覆盖面基本够日常开发用了。如果你遇到的问题不在这张表里往往意味着你手上的变量组合比较特殊这种情况建议直接跳到下一节的五步排查顺序从头捋一遍。现象可能原因解决方案同一Prompt在对话网页上反复试回答漂移对话产品默认temperature偏高、开了随机性别用网页对比改用API并锁参数API设置T0后仍有少量变化penalty未关、seed未固定、平台非确定性关闭penalty、固定seed、输入字符串逐字节一致某天开始所有结果都变了服务端模型版本更新记录model版本用benchmark集回归多轮对话中同样的问题越答越偏历史上下文累积污染新起会话清空历史或只保留关键记忆输出格式五花八门Prompt没约束格式模型自由发挥加JSON模式、few-shot示例、后处理校验偶尔输出截断、不完整max_tokens或stop序列配置不当调大max_tokens设置stop序列表格最后一行经常被忽略。很多稳定性问题根本不是“随机”而是输出被截断在奇怪位置导致看起来像“答非所问”。排查的时候把max_tokens、stop、reasoning相关的参数都翻一遍能省很多时间。要是发现输出长度刚好卡在某个上限那基本就是截断问题直接调大上限或者给一个明确的结束符问题就消失了。这类问题有个特征同一个Prompt前面部分很稳定只有结尾突然断了或者是同一个句子每次断的位置不同。遇到这种先别去动temperature十有八九是长度或停靠设置的问题。5.2 我固定的五步排查顺序我自己在项目里固定了一套排查顺序每次碰到“输出不稳定”都照着过一遍基本不会漏。第一步确认输入完全一致把请求体导出来逐字节对比重点看空格、换行、动态字段。第二步确认参数完全一致temperature、top_p、top_k、penalty、seed全列出来登记。第三步确认上下文一致特别是多轮场景把tokenizer之后的内容拿来对比。第四步确认模型版本一致看日志里的模型名和版本号跟平台确认有没有更新。第五步确认服务端策略比如是否走负载均衡、是否命中不同的推理通道。前四步在应用层都可控第五步只能靠记录和协商。这个顺序背后有一个原则从成本最低、最可控的变量开始锁。大多数不稳定问题走到第二步就解掉了走到第四步还没解决的基本跟你的代码无关而是上游版本问题。如果你跳过前四步直接去重写Prompt很容易把一个本来不需要改的东西改坏越改越乱。最后分享一点个人体会。“同一个Prompt每次回答不一样”这件事真相往往分三层。第一层模型本来就是概率机变是正常的不变才需要额外配置。第二层你以为锁住的变量很可能因为token、上下文、版本这些细节并没有真正锁住。第三层真正稳定的系统从来不是靠某一个参数而是靠“低温度 结构化Prompt 后处理”这套组合拳。再补一个习惯上线前固定一批有代表性的测试样本跑一遍记下基线。之后无论谁说“结果变了”都能快速判断是代码改动还是上游变化。这个习惯帮我躲过不少次深夜排查。