企业官网建设流程全解析

我到现在还记得那个下午。某个客服知识库机器人上线测试，用户问“你们支持哪些支付方式”，模型一本正经地答了一长串，里面凭空多出一句“目前暂不支持花呗分期，建议使用银行卡快捷支付，单笔限额五万元”。可我们的产品压根没有这个选项。更离谱的是，在另一个SQL生成任务里，模型会引用完全不存在的表名和字段名，报错率一度高到没法看。我当时的第一反应是换更大参数的模型，换完依然翻车。后来一个做推理优化的同事瞄了一眼调用代码，问我：temperature是不是用的默认值？我低头一看，确实从没调过，默认0.7。改到0.2之后，同一个模型、同一个prompt，立刻正常了大半。这件事之后，我把温度系数（Temperature）彻底研究了一遍，从数学公式到业务场景都做了实测。这篇文章就当一次完整复盘，适合正在做大模型应用、整天被API输出稳定性折磨的开发者，也适合那些想搞明白“为什么调低温度就没那么聪明了”的产品同学。

1. 一次糟糕的SQL生成事故，逼我去正视Temperature的作用

1.1 事故现场：模型一本正经地编造字段名

当时我在做一个小型数据分析平台，核心功能是让用户用自然语言问问题，后端调用大模型把问题转成SQL，再去查真实的业务库。一开始效果挺好，简单查询基本能对。但某天测试同学丢过来一个case：用户问“上个月每个区域贡献排名前五的商户有哪些？”，模型生成的SQL里出现了一个叫regional_rank的字段，还用了ROW_NUMBER() OVER (PARTITION BY region_name ORDER BY revenue DESC)这种看起来很合理的写法。问题是，表结构里根本没有regional_rank这个字段，revenue也不叫revenue，而是叫gmv。

这种错误最坑的地方在于：它太像真的了。如果不对照数据库表结构，光看SQL语句几乎看不出问题。我一开始怀疑是模型版本太老，花了大半天去换模型，从轻量版换到中大型版本，再把上下文里塞上完整的表结构说明，结果依然会偶发出现编造字段的情况。后来同事提醒我看看采样参数，我才发现所有请求用的都是API默认的temperature=0.7。把温度降到0.2之后，同样的表和prompt，连续跑了几十条，再没出现过编造字段的问题。

1.2 为什么默认值不一定适合你

很多大模型API文档里，temperature的默认值写着0.7、1.0这种“通用值”，这其实是服务商在“创意对话”类任务上平衡出来的经验值。它既不会让回答太死板，也不会太疯，适合通用的闲聊。但生产环境里的任务往往是高度约束的，比如SQL生成、信息抽取、客服口径回答，这时候0.7的默认值会带来明显的长尾风险，因为模型每次采样时有相对较高的概率选中那些“不太确定但语法上合理”的token。

这件事还让我意识到一个坑：很多东西不是模型不行，而是采样参数没对齐。换模型之前，先花半小时看一下当前请求到底用了什么temperature、top_p、top_k，往往能省下大量时间。那次事故之后，我把所有内部项目的API调用都加上了显式的采样参数，禁止再依赖服务商默认值，因为“默认值”在不同版本、不同模型上可能不一样，隐性迁移会让你排查问题的时候完全摸不着头脑。

2. Temperature在数学上改了什么：softmax分布被拉伸或压平

2.1 softmax公式与Temperature的位置

大模型每次生成下一个token时，网络会给词表里的每个候选token打一个分数，这个分数叫logit，可以理解成模型对“该不该选这个词”的原始偏好。但logit不能直接作为概率使用，因为它可能是很大的正数，也可能是负数，直接比较不方便。于是模型会套一层softmax函数，把一组logit转换成一组和为1的概率值。

Temperature就插在softmax里面。标准的softmax长这样：对每个候选token，计算exp(logit_i)，再除以所有候选token的exp之和。加了温度T之后，每个logit会先除以T再取指数，变成exp(logit_i / T)。当T=1时，公式和原始softmax一样；当T<1时，logit之间的差距被放大；当T>1时，logit之间的差距被缩小。换句话说，Temperature并不直接“增加随机性”，它改变的是概率分布的尖锐程度。

2.2 一个数字例子：同一个logit分布，三种温度

我拿一个虚构的简单场景来说明。假设某个位置模型给四个候选token打出的logit分别是2.0、1.0、0.0、-1.0，我们分别用T=0.5、T=1.0、T=2.0来计算最终概率：

大家看T=0.5那一列，最高分的token A几乎垄断了采样概率，模型基本不会选到其他词。而在T=2.0那一列，原本微弱的token C、token D也有了一成左右的概率被采样到。这解释了很多现象：为什么代码生成任务温度一高就容易冒出来奇怪的函数名，为什么客服机器人温度一高就擅自承诺不存在的售后政策——那些“奇怪”的token其实一直都在候选列表里，只是温度高了之后它们被采中的概率从百分之几变成了百分之十几。

2.3 常见误解修正

网上很多说法把Temperature解释成“随机性开关”，说温度越高模型越随机，温度越低越确定。这个说法方向对，但不够准确，容易误导调参。更准确的理解是：Temperature控制的是模型对“低置信备选答案”的容忍度。低温度让模型倾向于走它最熟悉、训练数据里最常见的路径，高温度则把更多低概率路径放进采样池子，让模型有机会“另辟蹊径”。

这里还有一个容易忽略的点：Temperature影响的是推理阶段的采样概率，它不会改变模型内部的参数和知识。你不可能通过调高温度让模型突然学会它本来不会的知识，高温度带来的“创造力”其实是在有限的知识边界里换一种路径表达。如果一个领域模型本身就不会，温度再高，产出的也只是看似流畅的胡编。理解了这一点，你就不会在核心业务里把温度当成万能创意开关。

3. 同一段Prompt在不同温度下的实测输出对比

3.1 代码任务：低温是保命符，高温是幻觉温床

我用某主流商用大模型做过一组对比测试，prompt是“用Python写一个函数，判断字符串是否为回文”。T=0.2时，它稳定输出双指针版本或切片反转版本，代码干净，还有一行简单注释。T=0.7时，偶尔会多出一些没必要的类型标注，有时还会引入from typing import List这种跟问题无关的导入。T=1.5时，输出开始变得华丽，例如用递归加reversed再拼接，逻辑虽然能跑但明显绕路，甚至还有一次生成了名为isPalindromicCheck的奇怪函数命名。

代码任务的特殊性在于：正确答案通常只有少数几种优雅写法，而错误答案有无限多种。高温会让模型在错误空间里自由探索，这对代码生成是非常危险的。所以凡是涉及生成代码、SQL、正则表达式、配置文件，我基本都会把温度压到0.2以下。如果模型本身能力差，低温会让代码风格死板一些，但至少不会编造API。

3.2 客服场景：一次越权承诺引发的客诉

另一个测试是客服问答。prompt是“客户说：订单显示已签收但我实际没收到，请生成回复话术”。T=0.2时，模型会输出类似“您好，非常抱歉给您带来困扰，我们正在为您核实物流信息，请在24小时后关注更新”的标准话术，全程没有额外承诺。T=0.7时，模型开始自行添加“我们会安排专员重新补发”“如仍未收到将为您全额退款”这类内容。从语言流畅度角度看，T=0.7的回复更“贴心”，但从业务合规角度就是事故。

客服场景真正需要的是口径一致。客户可能拿你的回复截图留证，一句“我们会全额退款”如果不在授权范围内，后续处理非常被动。我在多个客服项目里最后的统一做法是：生成回复用T=0.2以下，同时再加上规则层面的敏感承诺词拦截，双保险。宁可回得机械一点，也不能让模型随便承诺。

3.3 创意文案：温度太低太无聊，太高又不知所云

我也试过创意文案任务，prompt是“为一个冷萃咖啡产品写三条slogan”。T=0.2时，输出三条极其安全的句子：“冰爽冷萃，新鲜每一杯”“醇厚口感，冷萃精华”“提神醒脑，冷萃之选”。不能说错，但放到市场上毫无记忆点。T=0.9时，出现了“把夏天锁进冰凉的杯子里”“冷萃不加班”这类明显更有画面感的表达。T=1.8时，输出变成了“咖啡从不说话，但冰块记得一切”这种看起来文艺但完全不知道在说什么的东西。

这组对比给我最大的启发是：高温度不等于高质量创意，它只是把更多低概率候选token放开。如果模型训练语料里本身积累了大量优质品牌文案，高温度可以帮你探索到更有趣的组合；如果模型本身缺乏这类表达储备，高温度只会让输出更碎片化、更不知所云。所以在创意任务里，我通常的做法是T设到0.9到1.0之间，一次多生成几条，人工挑选，而不是把温度拉到极端值去赌一次输出。

4. Temperature和top_p、top_k的联合调参：三个旋钮一起转才稳

4.1 三个参数各自管什么

很多初学者只知道调temperature，忽略了top_p和top_k，这会导致调参效果不稳定。这三个参数实际是在不同环节约束采样：

• top_k：先把概率最高的一批token截出来，只保留前K个，其余全部按0处理。K越小，越保守。
• top_p：把所有token按概率从高到低排序，依次累加概率，直到累计值超过p，剩下的token被砍掉。它是个动态截断，p越小，候选池越窄。
• temperature：对截断后剩下来的token重新进行概率缩放，改变它们之间的相对差距。

我推荐用一个类比来记：top_k像“海选只保留前50名”，top_p像“再按实力从高到低数人头，数到覆盖90%为止”，temperature则是“给选手成绩乘个系数，决定第一名跟最后一名之间的差距有多大”。三者共同决定最后从哪个范围里采样，而不是temperature单独决定一切。

4.2 联合叠加的关键逻辑

需要注意执行顺序和叠加效果。通常是先做top_k和top_p的截断，得到一个动态缩小的候选token集合，再在这个集合上应用temperature调整概率，最后按概率采样。因此如果你把top_p设得非常小，比如0.01，那么候选token基本只剩最高分那一个，temperature再高也很难产生多样性。反过来，如果top_k设成200且不限制，候选池很大，即使temperature=0.3，长尾里那些低概率token也还是有一点点被采到的可能，只是概率很低。

另外还要留意不同API的默认值差异。有些服务商默认top_p=1，也就是不截断，所有token一视同仁参与温度缩放；有些服务商默认top_p=0.95，长尾被砍掉一小部分。所以很多人复现别人的参数时，只抄temperature，不抄top_p，跑出来的效果千差万别，这是非常常见的问题。

4.3 我常用的联合配置表

这套配置不是绝对的，它依赖于模型能力和任务描述质量。如果你换了一个模型，建议照着这个区间重新跑一次对比，而不是无脑沿用。调参的关键是：每次只动一个变量，记录输出，再动下一个，否则你根本分不清是哪项改动带来了变化。

5. 不同业务场景的温度配置表与我的实测建议

5.1 稳定压倒一切的高约束场景

客服机器人和内容审核是最典型的高约束场景。这类任务出错成本高，用户咨询的是真实订单、真实政策，模型一句自作主张就可能引发客诉。我测下来，客服回复话术T=0.2到0.3之间最合适，top_p控制在0.3左右，候选池收窄，话术基本稳定。但这里有个反直觉的点：T不要直接压到0.0。T=0.0时模型会百分百走概率最高的路径，一旦那条路径是“对不起，我不理解您的问题”，那用户换个说法问同样的问题时，模型就会反复陷入同一个死循环。保留0.2左右的温度，至少给模型留下一点换一种措辞回答同一个问题的机会。

信息抽取和数据标准化也是类似逻辑，T=0.0到0.2之间，输出格式要严格，字段值不要自由发挥。我实际遇到过一个案例：用T=0.7抽取出证照号码的时候，模型偶尔会把号码里的“0”改成“O”，肉眼很难发现，但下游系统校验直接失败。低温配合正则约束才能解决。

5.2 需要一定多样性但不能失控的任务

通用写作、邮件润色、演讲稿扩写这类任务，T在0.5到0.7之间比较舒服。太低了文字容易变成“正确的废话”，每个句子都对但放在一起毫无风格；太高了则开始出现前后矛盾的表达。我试过用T=0.9写会议纪要，模型输出里竟然出现了“这个问题我们下周再说”这种口语化句子，非常适合口头场合，但不适合作为正式纪要。所以在半约束场景里，我会先确定“哪些维度绝对不能变”，比如结论、数字、负责人，再把温控控制在0.6左右，让措辞有一定弹性就好。

5.3 真正需要发散的任务：靠多次采样和人工挑选

头脑风暴、营销文案、标题生成这类任务，核心目标不是“一次就对”，而是“提供足够多的备选”。我的做法是把T放到0.9到1.2之间，prompt里明确要求“请给出20个答案”，然后一次跑多次生成，最后人工筛掉离谱项。高温度下的多样性是相对廉价的，真正值钱的是筛选判断。我还见过一些团队做“温度退火”，开头用高温度探索各种方向，后半段逐步降低温度，让输出收敛到可读状态，这在长文本生成里更复杂，但对某些创意场景是值得尝试的进阶玩法。

5.4 复杂推理任务：低温不是“草稿纸”

最后要特别说一个误区：很多人以为推理任务温度越低越好，因为需要确定性。但我在数学题和逻辑推理任务里试过，T=0.0时模型如果第一步就走上了错误路径，它会非常自信地沿着错误路线一直推下去，反而比高温度更难纠正。T=0.3到0.5左右，配合few-shot思维链示例，模型有机会在中间步骤做“微小偏移”，有时反而能绕回正确方向。当然，这种收益很有限，不要指望温度解决推理能力问题，推理正确率的核心还是模型能力和prompt设计。

6. 调温度踩过的几个坑和一个可复用的扫描排查方法

6.1 坑一：忘记固定seed，导致对比结果失真

有段时间我在反复调一个文本分类任务，T=0.7时测了三次，三次结果都不一样，我还以为是模型不稳定。后来才发现，自己根本没固定随机种子。大模型采样过程本身是带随机性的，同样的T，不同次生成结果不同是正常现象。要做对比评测，要么固定API支持的seed参数，要么同一个配置跑多次看分布，而不是拿单次输出下结论。这个坑特别容易在团队协作里出现：A同学测的是随机结果中的好运气，B同学测的是随机结果中的坏运气，两个人对同一个参数的判断完全相反。

6.2 坑二：只调温度，不看API的默认top_p

很多服务的采样参数是“全家桶”，你只改temperature，top_p可能还是1.0。这意味着长尾token完全没被截断，温度稍高一点，那些极低概率的怪词也有机会冒出来。所以我每次接入新模型的API，第一件事是拉出默认参数列表，看清楚top_p、top_k、presence_penalty、frequency_penalty的默认值，再做调整。只抄别人博客里的temperature是没用的，因为你不知道别人的默认池子长什么样。

6.3 坑三：把低温度当成“正确”的保险丝

低温度能避免随机漂移，但它不能保证正确。模型如果本身能力不足，低温度只是让你稳定地得到错误结果。我经历过一次促销文案生成，T=0.2时模型每次都把折扣率写成“满300减50”，实际上活动是“满500减80”，它稳定地错，不给你任何“偏离正确路径”的偶然性。低温保的是确定性，不是保accuracy。解决正确性问题，要先从prompt、few-shot、知识库检索这些方向下手，最后才谈采样参数。

6.4 一套可复用的温度扫描方法

踩过几次坑后，我沉淀了一套相对靠谱的排查流程，现在每次换模型、换prompt、换业务场景都会跑一遍。具体做法是这样：固定同一条代表性prompt，如果有seed参数就固定seed，如果没有，每个温度下连续生成10次，然后比较五个指标。

我通常扫描T=0.0、0.2、0.5、0.7、0.9、1.2这六个点，生成一个简单表格，选“业务指标最高、越界率可接受”的那个点。以我之前某个SQL任务为例，T=0.2时通过率最高且越界率为0；T=1.2时偶尔出现风格花哨但能跑的SQL，业务风险可控，但review成本高了，最后还是选0.2。这个脚本我现在一直保留，每次模型服务商更新版本、调整默认参数后，我也会重新扫一遍。

6.5 我现在的调参习惯

如今我接手一个新任务，不会上来就问“温度调多少”，而是先问三个问题：这个任务最不能接受的错误是什么，是胡说八道还是过于死板？输出是否需要用户多次请求保持一致？如果生成结果明显不对，我能不能用规则强制拦截？这三个问题的答案基本能帮我框定一个合适的温度区间。然后再跑一遍温度扫描，用数据确认。模型能力再强，采样参数没配对，生产环境照样会给你意外“惊喜”。

如果你也正在被模型输出不稳定折磨，不妨先跑一遍温度扫描，再决定要不要换模型。很多时候，问题不在模型大小，而在你根本没认真看过采样参数。