先聊个我自己的翻车现场。前阵子帮朋友调一个内容分类的提示词任务prompt写得自认为很细角色设定、输出格式、示例、边界情况全给了结果跑出来的结果还是七零八落——不是漏分类就是在给的格式里自己造字段。朋友看了半天说你是不是没调参数我这才意识到在那之前我对提示词工程的理解一直是提示词本身才是王其他都是借口结果被现实狠狠教育了一课。后来我把同一条prompt在不同参数下跑了十几遍发现参数对角色的塑造作用很多时候比prompt里多写两句话更直接。而且越是做提示词工程越会发现真正决定复杂任务上限的往往是这些藏在请求体里的数字——temperature、top_p、top_k、max_tokens、frequency_penalty、presence_penalty。这篇文章想聊的就是这几个参数。我会把每个参数的底层逻辑、适用场景、调参边界和踩坑经历都讲透最后给出一套我自己在项目中验证过的可复现调参流程。不管你是刚接触大模型的提示词新手还是已经写过几百条prompt但一直凭感觉调参数的老手这篇应该都能给你一些新的抓手。1. 先澄清一个常见误区提示词工程的参数到底指哪一类1.1 模型参数与推理参数两套完全不同的东西很多人经常把模型参数和提示词工程的参数混着说。模型参数是指神经网络训练完以后固化下来的权重比如70B参数13B参数里的那个B指的是模型权重数量这个在训练阶段就确定了你没法通过API去改。提示词工程里要调的参数是推理inference阶段的采样参数也叫生成参数、解码参数、推理超参数。它们是每一次API请求时你可以在请求体里显式指定的选项比如OpenAI的temperature、top_p、max_tokens、frequency_penalty、presence_penaltyAnthropic的temperature、top_p、top_k、max_tokens、stop_sequences以及本地开源模型框架里五花八门的采样配置。这一区分看起来非常简单但我见过太多人把7B模型和temperature0.7放在同一句话里讨论讨论半天讨论的不是一个层面的问题。简单说模型参数决定这个模型知道多少推理参数决定它在回答时怎么选词。前者的变化需要重新训练模型后者的变化只需要改一个请求字段这就是提示词工程能发挥巨大作用的空间所在。1.2 参数真正作用的位置next token prediction的最后一步大模型的生成过程本质上是一个反复预测下一个token的循环。每一次预测模型会为词表里的每个token打一个原始分数logits然后通过一个softmax函数把这个分数转成一个概率分布。模型参数决定的是这个概率分布的形状而采样参数决定的是给定这个概率分布之后最终挑哪个token。可以把这理解成一个阅卷老师做选择题模型参数是老师的知识储备采样参数是老师在批卷时的宽松程度。同一个老师可以给A卷答案改得很松也可以改得很严完全取决于批卷规则也就是我们设置的各类采样参数。理解这个以后你就会明白为什么参数这么重要提示词再精妙最终生成的内容还是要经过采样这一关。prompt把回答方向框得再好如果采样时选了一个概率并不高的token输出照样会偏。反过来参数设置得当甚至能在一定程度上弥补prompt表述不清的问题——虽然我个人不建议用参数去救烂prompt两者配合才是正路。1.3 为什么说这组参数是通用语言还有一个值得注意的点这组采样参数几乎是所有主流大模型平台的通用语言。不管你在用OpenAI的GPT系列还是Anthropic的Claude系列又或者是本地部署的Llama、Qwen、DeepSeek它们在推理时都遵循同一个基本逻辑——从概率分布里采样生成。虽然不同平台的参数名有细微差异比如有的叫repetition_penalty有的叫frequency_penalty但底层的数学思想高度一致。这意味着你在一套体系上建立的调参经验换到另一个模型上虽然需要重新验证数值但排查问题的思路可以完全复用。这也是我为什么建议每个做提示词工程的人都把这组参数吃透——它相当于大模型应用开发的底层API无论上层封装怎么变只要还在做生成式AI就绕不开它。2. Temperature从softmax说起为什么它是确定性与发散性的总闸门2.1 temperature的真实作用机制temperature是提示词工程里出镜率最高的参数因为它最直观。OpenAI的API里它默认是1.0数值范围通常是0到2新模型可能略有不同。它影响的是softmax公式里的温度缩放项。完整解释是这样的模型给每个token打出一个原始分数logits之后先除以temperature再送进softmax转换成最终概率。当temperature小于1时logits之间的差距被放大概率分布变得尖锐高概率token更加突出大于1时差距被压缩概率分布变平原本低概率的词也有机会被选中等于0时相当于退化成贪心解码——每次都直接选概率最高的那个token。数学上很简洁但直觉上很多人理解反了。我经常跟人讲temperature0不是最聪明的模型它是最保守的模型每次只选模型认为最可能的那个词。在代码生成、JSON格式化输出这类要求稳定性的场景把temperature调低效果立竿见影。而在头脑风暴、创意文案场景稍微调高一点模型才敢说一些概率不高的怪话才会给你意外的灵感。2.2 分场景的temperature设置参考没有绝对标准但下面这组值是我在多个项目里反复验证过、适合大多数任务作为起点的参考任务类型参考temperature理由代码生成/修复0.1-0.3结果必须可复现、语法稳定数据抽取/分类/格式化0-0.3要求输出严格遵守格式翻译/摘要0.3-0.5兼顾准确度与自然度客服话术/邮件润色0.5-0.7需要自然但不过分发散内容创作/营销文案0.7-1.0需要一定的词句多样性头脑风暴1.0-1.2追求非常规组合可事后人工筛选这只是起点具体还要结合prompt本身的强度和模型风格来微调。比如同样的分类任务如果prompt里的类别定义写得模棱两可那即使temperature调到0模型也可能在边界类别上反复横跳如果prompt写得非常具体并给了足够多的示例temperature稍微高一点也问题不大。我实测下来的体感是temperature在0.3以下时即使是创意型模型输出也比较正经到1.2以上发散明显增强但也开始容易出现逻辑断裂、前后矛盾。所以做生产级应用时我一般从0.7起步再按任务往下压而不是一上来就追求0或者满格。2.3 temperature调不动的几种情况有些时候你会发现调temperature几乎没效果这时候不必怀疑参数坏了通常是这几个原因导致的。第一概率分布先天就很集中。如果某个token的概率极高比如0.95以上其他token再怎么放大采样结果基本都是它temperature的影响被稀释了。比如让模型回答11它算出2的概率可能接近1temperature设成1.5它也不太可能回答3。第二prompt把输出空间框得太死。如果你的prompt要求模型只能从A、B、C三个选项里选一个相当于把候选逻辑压缩得很小temperature能发散的余地就非常有限。这个案例我在后面调参部分会详细展开。第三结构化输出约束。比如你要求必须输出JSON且字段完全固定模型在结构token如花括号、引号、冒号上的分布本来就极端集中temperature只对内容词有一点点影响。这不是bug是分布本身决定了随机性的天花板。想验证temperature有没有生效最好的做法是拿同一句开放式的prompt跑5到10次观察输出差异。如果差异太小不是模型坏了是你的分布被限制得太死。这时候与其继续调大temperature不如回头检查prompt是不是给得太死板。3. top_p和top_k两种截断采样该信累加概率还是固定名额3.1 top_k只看概率最高的K个候选top_k的思路很直接每次只从概率最高的K个token里采样其余的全部排除然后再在这K个里按归一化后的概率随机选。K50意味着把候选范围限制在模型认为最可能的50个词内。top_k的优点是计算简单、直觉清晰但缺陷也很明显K是固定的可不同上下文的概率分布形状完全不一样。有些上下文里模型认为前50个token都有一定可能这时top_k可以保留足够的候选多样性但在另一些上下文里前5个token的概率加起来就占了95%剩下45个全是概率极低的垃圾词这时top_k会强行把垃圾词也拉进来反而增加了输出跑偏的风险。Hugging Face的transformers库默认top_k50但这并不代表这个值适合所有任务。很多刚接触开源模型的人直接用默认配置跑发现输出怪怪的其实就是因为默认采样配置是通用值根本不是你手头任务的最优值。3.2 top_p动态调整候选范围核采样的核心思路top_p和top_k最大的不同在于它按累计概率截断而不是固定候选数量。具体做法是把候选token按概率从高到低排序从概率最高的开始累加一直累加到累计概率达到p然后用这批token重新归一化再采样。p0.9的意思是只在模型认为概率合计占90%的token里选。这样候选数量是动态的——分布尖锐时候选少分布平滑时候选多。这正是top_p比top_k更适合大多数任务的原因。top_k是固定海选人数不管选手实力差距多大都要选满top_p是按成绩线划线成绩好的多选差的踩线就淘汰。这也是为什么很多大模型API把top_p和temperature并列为主采样参数而把top_k当作可选或默认后台值。OpenAI在文档里专门提过一句建议只调整temperature或top_p中的其中一个不要同时改动两个。原因在于它们本质都是改变采样随机性的手段叠着调容易产生温度很高但核很小或者温度很低但核很大之类的失控状态参数之间互相打架最后很难定位输出差异到底来自哪里。3.3 我实际调参的做法和建议我的习惯是优先用temperature控制整体发散程度把top_p当作安全护栏来用。如果发现某个模型在temperature0.8时输出偶尔飘到离谱的方向我会把top_p设为0.9或者0.85相当于在创意和平稳之间加一道过滤网。两者同用的方式也不是绝对不行只是你需要意识到它们的优先级。一个我常用的参考配置是temperature0.7搭配top_p0.9若要更稳定就把temperature降到0.5而不是同时把top_p压到0.7。原因是我希望top_p只负责兜底不负责压缩创意空间真正的创造力度由temperature来管。另外如果你用的是开源模型框架比如vLLM、SGLang、ollamatop_k、top_p、temperature通常都会暴露出来可调这时不要照搬OpenAI的默认值最好先看模型卡里的recommended sampling parameters。不同模型在训练时的采样假设不同有些模型是在temperature0.7、top_p0.9下评估出来的你按这个设置更能复现它的最佳表现。这一点很容易被忽视却非常影响实际效果。4. max_tokens与stop生成长度管理里那些话没说完和停不下来的坑4.1 先把token和字数的换算搞明白max_tokens限制的是本次生成最多输出多少个token。注意不是多少个汉字也不是多少个字符。token是模型处理文本的最小单位一个英文单词通常1到2个token一个汉字在多数中英文混合模型里可能需要1到2个token复杂字形甚至占更多。我发现很多人在这里踩坑要求模型输出500字max_tokens却只给了100结果模型每次写到一半就被强制截断末尾缺词、缺标点、甚至JSON被腰斩。这个现象在热搜词里对应的就是参数不足——大多数人第一反应是prompt写得不好实际上就是max_tokens给少了。我的经验是在做中文任务时token数大致按汉字的1.3到1.7倍估算比较稳。比如你要模型输出一个200字左右的总结max_tokens保守起见设400。如果任务需要模型输出JSON且包含大量字段名这个倍率还得再往上加因为英文字段名、标点、空格都在消耗token。稳妥做法是先设一个较大值跑一轮看实际消耗的completion_tokens是多少然后在这个数上乘1.2作为后续上限。4.2 stop sequences让模型在正确的位置停下来stop sequences是提示词工程里最被低估的参数之一。它是一组字符串模型生成过程中一旦输出中包含其中任意一个字符串立即停止生成。这个机制对结构化的任务特别友好。比如你要模型输出JSON可以让它在遇到某个结束标记时停下来防止它画蛇添足地补一段markdown解释。我实际做过的一个案例多轮对话Agent里我要求模型每次输出完一个工具调用标记后立刻停住不能继续说接下来我将……这类话。做法很简单在stop里加上工具调用的结束符输出格式一下子就稳定了。效果立竿见影甚至比很多人在prompt里反复强调不要输出多余内容要管用得多。用stop的时候有几个坑必须提醒stop是精确字符串匹配大小写敏感STOP和stop是两个不同的字符串。很多模型会输出小写的stop如果你只传了大写它不会停止。中英文标点不同如果你想在句号处停住中文文本里要传。而不是.否则匹配不到。stop不应该设太短比如你设\n作为stop那么任何换行都可能中断生成包括代码里的换行后果可以想象。OpenAI的stop最多传4个字符串记得把最可能出现的结束标记都列上比如多轮对话的User:和Assistant:要同时传。4.3 别把max_tokens设得过大max_tokens设太小会截断那设大一点总行了吧这同样是个误区。计费是按实际生成token数算的你设了4000模型每次只生成300倒没什么损失但如果你的任务允许模型自由发挥设很大它真的会继续编直到用完为止。这不仅费钱还容易输出大量车轱辘话把关键信息淹没在废话里。另外max_tokens还间接影响模型被截断语料的风险。当一个任务要求模型输出一段结构完整的内容时如果max_tokens设得比实际需求小太多输出会在半句被截断模型不会自动补上结尾。所以在正式类任务上我的习惯是先测一轮真实长度再决定上限在开放式任务上反而会故意设小一点逼模型给精炼回答同时在prompt里明确回答控制在X字以内。这个组合拳比单靠max_tokens控制长度更有效。5. frequency_penalty与presence_penalty两个被低估的防复读调节器5.1 名字容易搞混作用机制也不一样这两个参数在OpenAI的API里都有范围通常在-2到2之间默认0。presence_penalty的作用是某个token只要在文本中出现过就在这一步的评分逻辑里给它一点负向影响frequency_penalty的作用是某个token出现的次数越多负向影响越大按出现频率等比生效。用大白话解释presence_penalty管的是出现没出现过只要对话里已经出现过的词后续再出现的可能性就会被压低从而推动模型换一个词frequency_penalty管的是出现了多少次重复越多压得越狠促使模型避免复读。直观理解就是presence_penalty是别说同一个词frequency_penalty是别老把那几个词翻来覆去说。这两个参数在代码生成、分类、抽取这类稳定型任务里我几乎不调保持0。因为这类任务需要模型严格按预定义类别和格式输出引入多样性惩罚反而可能让它跳过本该输出的类别名换成一个同义词这恰恰破坏了格式约定。很多人在分类任务里发现模型偶尔把退款输出成退钱以为prompt写得不够好其实可能就是因为之前调高了presence_penalty模型为了避开已出现的词才自己换了说法。5.2 实际场景什么时候加、加多少真正要用到这两个参数的是开放式生成任务。写文案、写段落时如果模型输出出现总而言之众所周知值得注意的是这类高频套话把presence_penalty调到0.3到0.6重复出现的套话会被轻微影响文字风格会自然很多。做长文本生成时如果模型开始复读已经用过两次以上的词组比如至关重要不禁让人深思反复出现frequency_penalty调到0.5左右能明显减少这种复读。多轮对话中如果模型总是在回答里带出用户刚才的原话presence_penalty也能缓解。还是那句话这两个参数都是改采样概率分布的手段所以别调太大。超过1.0之后模型为了躲避重复会刻意用一些生僻词或者病句来凑数出现一种生硬地换词的诡异风格。这在英文模型里尤其明显很容易把正常的连接词都换掉导致逻辑连接变弱读起来比复读还难受。5.3 在中文任务上的一点实测分享中文和英文在惩罚参数上的体验很不一样。英文有丰富的同义替换模型可以换着花样说中文模型在惩罚过高时更容易出现词不达意或干脆停机的现象因为可选的高质量近义词其实没有想象中多。我自己在中文新闻摘要任务上试过frequency_penalty1.0摘要里出现了大量从未见过的生僻表达读起来非常别扭。后来降到0.3自然的措辞就回来了。另外提醒一句如果同时调了temperature和这两个惩罚参数你会发现输出方差很大很难判断是哪个参数引起的。建议每次只动一个参数尤其是先在temperature和top_p之间选定组合再考虑要不要碰惩罚参数。调参最忌讳的就是同时改四五个旋钮出了问题根本没法定位。6. 参数组合配置不是玄学一组可复现的调参方法与实测记录6.1 用小型测试集替代单条prompt试感觉大多数人调参是拿一两条prompt跑一下觉得看起来不错就定下来了。这种做法最大的问题是样本太小很可能你看到的不错只是偶然的一次正采样。我在实际项目中总结了一个更稳的流程每次做新任务都会走一遍第一步把任务的核心场景抽成一个10到20条的评估集要求覆盖正常、边界、异常三种情况。这个评估集用一次之后就不变了作为固定的测试基准。第二步固定prompt完全不变只改一个参数在评估集上跑一轮人工或半自动判断每一轮结果的合格还是不合格。合格的标准要在跑之前就定清楚比如类别名是否在预设列表内JSON是否合法关键信息是否齐全。第三步画一个简单的参数-通过率对照表找到通过率最高的区域再在这个区域里细调。这个方法听起来朴素但在真实项目中比凭感觉高效得多而且能让你客观记住哪些参数对该任务影响大哪些几乎无感。比如有的任务对temperature非常敏感0.3到0.7之间通过率差异巨大有的任务则很钝从0到1.0输出都差不多这时候就别再花时间精调temperature了。6.2 一个真实的调参记录客服意图分类举个我最近做的例子。任务是客服消息的意图分类共8个类别prompt要求模型返回JSON格式{intent: ..., confidence: 0.xx}。初始设定是temperature1.0top_p1跑下来发现三个问题类别名偶尔被同义替换、confidence的值分布不自然、个别轮次多输出了解释文本。我先做两件事把temperature从1.0降到0.2同时把stop设置为[}]来禁止模型输出多余内容。结果类别名错误明显减少confidence分布也集中了。随后我在评估集上微调最后收敛到temperature0.1top_p0.8max_tokens80每条答案实际输出约40 token没有加惩罚参数。这个组合在20条评估集上通过率从最初的65%提到95%。这个案例里每一个参数都对应一个明确的问题temperature解决类别名漂移stop解决多余输出top_p充当最后一道保险。调参不是把数值抄一个最优解而是为任务里的每个失败模式找到对应的旋钮。6.3 不同平台的参数差异别把一套配置到处搬最后这点很重要。OpenAI、Anthropic、Google Gemini、本地开源模型框架对参数的支持和默认值不完全相同。比如Anthropic的官方文档建议如果关闭temperature可以通过改变top_p和top_k来实现一定随机性而OpenAI的某些API不支持top_k新推出的Responses API也调整了部分参数命名。本地开源模型如果通过Hugging Face transformers推理temperature、top_p、top_k、repetition_penalty都是模型配置里的常见项其中repetition_penalty和frequency_penalty作用类似但实现机制有差别——它是直接对重复的token进行统一调控而不严格基于频率计数。我自己吃过一个亏把在Qwen模型上调好的参数原样搬到了OpenAI的gpt-4o-mini上结果输出风格大变。原因是它们的词汇表和训练采样策略不同同一个temperature0.7在不同模型上体现的温度感完全不一样。所以如果换了模型别偷懒花半天重新评估一次参数是值得的。还有一个小技巧如果你的平台支持seed建议在实验阶段固定seed这样同一个参数配置可以复现完全一样的输出方便比较参数之间的差异。如果不支持seed那就在相同参数下跑多轮取通过率而不是只看单次输出。热搜词里提到真实参数生成参数校准其实说的就是这回事——让参数组合的调整过程有据可循而不是靠抽卡式的运气。我在实际迭代参数的过程中最深的一个体会是参数不是一个一个单独调的而是为任务的每个失败模式找对应的旋钮。先定位问题出在哪再去动那个参数比一次把所有参数全部改成某个网上推荐的最优值靠谱得多。每次只动一个变量记录前后结果你的调参经验就能像滚雪球一样积累起来而不是永远停留在上次碰巧调好了这次不知道改了什么又坏了的玄学状态。