大模型提示词工程核心参数调优：temperature、top_p等采样参数详解

先聊个我自己的翻车现场。前阵子帮朋友调一个内容分类的提示词任务，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_penalty，Anthropic的temperature、top_p、top_k、max_tokens、stop_sequences，以及本地开源模型框架里五花八门的采样配置。

这一区分看起来非常简单，但我见过太多人把"7B模型"和"temperature=0.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。

数学上很简洁，但直觉上很多人理解反了。我经常跟人讲：temperature=0不是"最聪明的模型"，它是"最保守的模型"，每次只选模型认为最可能的那个词。在代码生成、JSON格式化输出这类要求稳定性的场景，把temperature调低，效果立竿见影。而在头脑风暴、创意文案场景，稍微调高一点，模型才敢说一些概率不高的"怪话"，才会给你意外的灵感。

2.2 分场景的temperature设置参考

没有绝对标准，但下面这组值是我在多个项目里反复验证过、适合大多数任务作为起点的参考：

这只是起点，具体还要结合prompt本身的强度和模型风格来微调。比如同样的分类任务，如果prompt里的类别定义写得模棱两可，那即使temperature调到0，模型也可能在边界类别上反复横跳；如果prompt写得非常具体并给了足够多的示例，temperature稍微高一点也问题不大。

我实测下来的体感是：temperature在0.3以下时，即使是创意型模型，输出也比较"正经"；到1.2以上，发散明显增强，但也开始容易出现逻辑断裂、前后矛盾。所以做生产级应用时，我一般从0.7起步，再按任务往下压，而不是一上来就追求0或者满格。

2.3 temperature调不动的几种情况

有些时候你会发现调temperature几乎没效果，这时候不必怀疑参数坏了，通常是这几个原因导致的。

第一，概率分布先天就很集中。如果某个token的概率极高（比如0.95以上），其他token再怎么放大，采样结果基本都是它，temperature的影响被稀释了。比如让模型回答"1+1="，它算出"2"的概率可能接近1，temperature设成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个里按归一化后的概率随机选。K=50意味着把候选范围限制在模型认为最可能的50个词内。

top_k的优点是计算简单、直觉清晰，但缺陷也很明显：K是固定的，可不同上下文的概率分布形状完全不一样。有些上下文里，模型认为前50个token都有一定可能，这时top_k可以保留足够的候选多样性；但在另一些上下文里，前5个token的概率加起来就占了95%，剩下45个全是概率极低的"垃圾词"，这时top_k会强行把垃圾词也拉进来，反而增加了输出跑偏的风险。

Hugging Face的transformers库默认top_k=50，但这并不代表这个值适合所有任务。很多刚接触开源模型的人直接用默认配置跑，发现输出怪怪的，其实就是因为默认采样配置是"通用值"，根本不是你手头任务的最优值。

3.2 top_p：动态调整候选范围，核采样的核心思路

top_p和top_k最大的不同在于，它按累计概率截断，而不是固定候选数量。具体做法是把候选token按概率从高到低排序，从概率最高的开始累加，一直累加到累计概率达到p，然后用这批token重新归一化再采样。p=0.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当作"安全护栏"来用。如果发现某个模型在temperature=0.8时输出偶尔飘到离谱的方向，我会把top_p设为0.9或者0.85，相当于在创意和平稳之间加一道过滤网。

两者同用的方式也不是绝对不行，只是你需要意识到它们的优先级。一个我常用的参考配置是temperature=0.7搭配top_p=0.9；若要更稳定，就把temperature降到0.5，而不是同时把top_p压到0.7。原因是我希望top_p只负责兜底，不负责压缩创意空间，真正的"创造力度"由temperature来管。

另外，如果你用的是开源模型框架（比如vLLM、SGLang、ollama），top_k、top_p、temperature通常都会暴露出来可调，这时不要照搬OpenAI的默认值，最好先看模型卡里的recommended sampling parameters。不同模型在训练时的采样假设不同，有些模型是在temperature=0.7、top_p=0.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_penalty=1.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}。初始设定是temperature=1.0，top_p=1，跑下来发现三个问题：类别名偶尔被同义替换、confidence的值分布不自然、个别轮次多输出了解释文本。

我先做两件事：把temperature从1.0降到0.2，同时把stop设置为["}"]来禁止模型输出多余内容。结果类别名错误明显减少，confidence分布也集中了。随后我在评估集上微调，最后收敛到temperature=0.1，top_p=0.8，max_tokens=80（每条答案实际输出约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上，结果输出风格大变。原因是它们的词汇表和训练采样策略不同，同一个temperature=0.7，在不同模型上体现的"温度感"完全不一样。所以如果换了模型，别偷懒，花半天重新评估一次参数是值得的。

还有一个小技巧：如果你的平台支持seed，建议在实验阶段固定seed，这样同一个参数配置可以复现完全一样的输出，方便比较参数之间的差异。如果不支持seed，那就在相同参数下跑多轮取"通过率"，而不是只看单次输出。热搜词里提到"真实参数生成""参数校准"，其实说的就是这回事——让参数组合的调整过程有据可循，而不是靠抽卡式的运气。

我在实际迭代参数的过程中最深的一个体会是：参数不是一个一个单独调的，而是为任务的每个失败模式找对应的旋钮。先定位问题出在哪，再去动那个参数，比一次把所有参数全部改成某个"网上推荐的最优值"靠谱得多。每次只动一个变量，记录前后结果，你的调参经验就能像滚雪球一样积累起来，而不是永远停留在"上次碰巧调好了，这次不知道改了什么又坏了"的玄学状态。