Wiki Notes

Appearance

07. LLM 参数与采样控制 ​

版本：v1.1

最后更新：2026-07-08

适用对象：需要把大模型从“能跑起来”推进到“效果稳定、成本可控、延迟可管、输出可约束”的产品、应用研发、平台工程与评测同学

很多团队一说“调参”，第一反应就是：

  • 把 temperature 从 0.7 改成 0.2
  • 看回答是不是更稳了
  • 如果还不稳，再继续试几个数字

这在 Demo 阶段也许够用，但在真实系统里，参数控制不是为了“碰运气调到满意结果”，而是为了把模型行为压进一个更可预测、更可评测、更容易运营的区间。

这页的重点不是罗列所有字段，而是回答四个更实用的问题：

  1. 常见参数到底分别在控制什么
  2. 哪些参数适合做主旋钮，哪些只适合谨慎微调
  3. 不同厂商和不同模型为什么不能照搬同一套参数习惯
  4. 怎样把调参从个人经验变成团队可复现的工程流程

1. 为什么参数不是“调参玄学” ​

线上 LLM 系统真正关心的不是“这次回答看起来聪不聪明”，而是下面几件事：

  • 输出是否稳定
  • 结构化结果是否容易落库或驱动下游动作
  • 工具调用是否更少乱跳
  • 长任务是否更容易被截断
  • 成本和时延是否有边界
  • 版本切换后是否可复测、可对比

所以参数控制的本质不是“给模型加点魔法”，而是：

  • 给任务行为设边界
  • 给成本和时延设预算
  • 给评测和回归创造可比性

一句话理解：

  • 参数的目标不是把模型调得更像人，而是把任务行为调到更像系统。

2. 先把参数分成四层 ​

2.1 采样层参数 ​

这类参数控制“模型怎么选下一个 token”：

  • temperature
  • top_p
  • top_k
  • 部分旧接口里的 frequency_penalty
  • 部分旧接口里的 presence_penalty
  • 少数接口里的 logprobs

它们最直接影响：

  • 输出发散程度
  • 语言风格波动
  • 重复率
  • 多样性

2.2 生成预算层参数 ​

这类参数控制“能说多长、何时停、停在哪里”：

  • max_output_tokens / max_tokens
  • stop
  • Structured Outputs 对输出形状的约束

它们最直接影响：

  • 成本
  • 延迟
  • 截断风险
  • 下游解析成功率

2.3 推理与执行层参数 ​

这类参数不一定直接影响文风，但会影响“模型为任务投入多少推理预算”：

  • OpenAI reasoning.effort
  • OpenAI text.verbosity
  • 一些厂商的 thinking / effort / reasoning 预算配置

它们更像任务控制器，而不是传统采样旋钮。

2.4 工作流层参数 ​

这层常被忽略，但在生产里反而最关键：

  • 是否流式返回
  • 是否保留上下文状态
  • 是否允许工具调用
  • 工具定义的数量与粒度
  • 是否启用结构化输出
  • 是否缓存静态前缀

很多人把“系统不稳”误以为是采样问题，实际根因常在这层。

3. 最常见的参数到底怎么理解 ​

3.1 temperature ​

temperature 控制采样分布的平滑程度。直觉上可以理解为：

  • 越低：越保守、越容易收敛到高概率 token
  • 越高：越发散、越容易出现不同表达和不同路径

适合低温起步的任务：

  • 分类
  • 抽取
  • 结构化生成
  • 工具参数生成
  • 审批建议
  • 运维诊断摘要

适合保留一定温度的任务：

  • 文案改写
  • 创意脑暴
  • 多候选方案生成
  • 开放式长文写作

实用建议：

  • 如果任务目标是“稳定复现”，先从低温开始
  • 如果任务目标是“多样候选”，再逐步提高
  • 不要把高温当成“变聪明”的手段，它更常带来波动，而不是能力跃升

很多业务里最有用的经验不是“找到一个完美温度”，而是：

  • 先明确这是稳定性任务，还是多样性任务

3.2 top_p ​

top_p 是 nucleus sampling，意思是：

  • 不按固定数量截断候选
  • 而是保留累计概率达到阈值的一组 token

它适合做精细采样裁剪，但在工程上通常有个更稳妥的习惯：

  • temperature 和 top_p 最好只把一个当主旋钮

原因很简单：

  • 两者都在改采样分布
  • 同时大幅调整时，很难知道到底是哪一个在起作用

建议：

  • 大多数团队先固定 top_p
  • 只微调 temperature
  • 只有在明确需要控制长尾采样时，再动 top_p

3.3 top_k ​

top_k 的含义是：

  • 每一步只在概率最高的前 k 个 token 中采样

它在一些厂商接口里很常见，但并不是所有主流模型接口都会把它作为推荐主参数。

实用理解：

  • top_k 更像硬裁剪
  • top_p 更像按概率质量裁剪

如果你在做跨厂商平台，必须接受一个现实：

  • 参数名相似，不代表语义权重和推荐用法相同

比如当前公开文档里：

  • Google Gemini 生成配置里常见 temperature、topP、topK
  • Anthropic 新一代部分模型则明确不接受非默认的 temperature、top_p、top_k

所以：

  • 跨模型调参不要抄配置文件，要先看目标模型是否真的支持

3.4 max_output_tokens / max_tokens ​

这是最容易被低估、也最应该优先控制的参数之一。

它控制的不是“文风”，而是预算：

  • 最长可见输出
  • 部分模型里也间接约束推理预算总消耗
  • 截断风险
  • 单次请求上限成本

OpenAI 当前 reasoning 文档明确提到：

  • max_output_tokens 约束的是总生成 token，里面可能包括 reasoning token、可见输出 token 和格式 token

这意味着一个很容易踩的坑：

  • 你以为只是在限制“回答长度”
  • 实际上可能把推理空间也卡死了

表现通常是：

  • 响应状态变成 incomplete
  • 甚至在还没给出可见答案前就耗尽预算

建议：

  • 先按任务类型给出默认上限
  • 再在日志里监控哪些请求频繁逼近上限
  • 把“经常截断”当成协议与任务设计问题，而不是单纯继续放大 token 上限

3.5 stop ​

stop 的作用是：

  • 遇到某些分隔符或模式就停止生成

适合场景：

  • 老式模板拼接
  • 少量定界输出
  • 兼容遗留文本协议

不适合场景：

  • 你已经在用 JSON Schema
  • 你已经在用函数调用
  • 你已经能明确区分输出层和工具层

因为这时更好的做法不是“靠停词收尾”，而是：

  • 用结构化协议直接定义边界

3.6 text.verbosity ​

这是当前 OpenAI 文档里非常实用、但很多团队还没建立习惯的控制项。

它解决的不是“模型会不会做”，而是：

  • 模型会说得多详细

适合场景：

  • 用户界面需要更短、更利落的答案
  • 评测需要避免模型过度展开
  • 工具链前置总结不希望写成长文

一个常见误区是：

  • 以前用 prompt 里大量写“请简洁一点”

现在更实用的做法往往是：

  • 把“输出详细度”从 prompt 文案挪到显式参数

这样更容易复用、版本化和评测。

3.7 reasoning.effort ​

OpenAI 当前官方文档把 reasoning.effort 描述为：

  • 指导模型在任务上投入多少思考量

模型相关的可选值可能包括：

  • none
  • minimal
  • low
  • medium
  • high
  • xhigh

要点不是背枚举，而是理解它解决的问题：

  • 复杂推理要不要给更多预算
  • 成本与时延是否值得换更高质量
  • 工具密集工作流里是否需要更稳的规划

更重要的是它带来的工程影响：

  • reasoning token 会占总预算
  • 低预算下可能提前 incomplete
  • 你需要监控使用量结构，而不是只看最终答案长度

3.8 seed 与复现 ​

如果你还在做批量评测、回归测试或参数实验，复现能力非常重要。

OpenAI 的 advanced usage 文档提到：

  • 可以使用 seed 增强“多数情况下”的可复现性
  • 还要结合 system_fingerprint 观察平台侧配置变动

这件事的正确预期是：

  • seed 不是绝对确定性
  • 它是帮助你做对比实验的工程工具

所以更合理的用法是：

  • 在离线评测、A/B 对比、回归复测里使用
  • 在用户侧实时交互里，不要迷信“只要设 seed 就一定完全一致”

3.9 惩罚类参数与重复控制 ​

在一些接口里，你会看到：

  • frequency_penalty
  • presence_penalty

它们主要用于降低重复、改变重复 token 的继续出现概率。

但在现在的生产实践里，它们并不是所有团队的常用主旋钮，因为很多重复问题并不来自采样，而是来自：

  • 上下文脏了
  • 工具回填重复
  • 模型被要求“逐步解释”太多次
  • 输出协议没收紧

所以顺序要反过来：

  1. 先查协议、上下文和状态机
  2. 再决定要不要用惩罚参数抑制重复

4. 不同厂商为什么不能照搬同一套参数 ​

这一点非常重要，因为“同名字段”不等于“同样推荐使用”。

4.1 OpenAI 当前更强调显式工作流参数 ​

从当前 OpenAI 文档可以看到，生产里越来越重要的是：

  • reasoning.effort
  • text.verbosity
  • max_output_tokens
  • Structured Outputs
  • function calling
  • conversation state

也就是说，OpenAI 现在很多“稳定性问题”更适合靠：

  • 结构化输出
  • 工具协议
  • 状态续接
  • reasoning 预算控制

而不只是采样参数。

4.2 Anthropic 新一代部分模型对传统采样参数更保守 ​

Anthropic 当前公开文档明确写到：

  • Claude Opus 4.7 及以后模型，包括 Claude Opus 4.8，不支持把 temperature、top_p、top_k 设置为非默认值
  • Claude Sonnet 5 也有同样的限制

这说明一个趋势：

  • 不是所有“强模型”都鼓励开发者频繁手调采样
  • 有些模型更希望你通过 prompt、schema、工具设计来控制行为

4.3 Gemini 保留了较典型的生成配置思路 ​

Google Gemini 当前文档仍广泛使用：

  • temperature
  • topP
  • topK
  • maxOutputTokens
  • response_json_schema
  • function calling

并且 Gemini 3 文档明确提到：

  • Structured Outputs 可以和 tools 结合使用

所以如果你在做多供应商网关，最稳妥的做法不是定义“一套全局调参模板”，而是：

  • 定义一套平台抽象层
  • 再为每个供应商维护适配映射和默认值

5. 不同任务的默认参数策略 ​

下面这张表更接近“生产默认值思路”，而不是固定公式：

任务类型推荐策略重点关注
分类 / 抽取 / 审批建议低温起步，优先结构化输出，严格长度上限稳定性、解析成功率
工具参数生成低温，能用 schema 就不用纯文本约束参数正确率、重试率
RAG 问答先控上下文质量，再微调温度引用忠实度、幻觉率
客服回复低到中等温度，必要时单独控 verbosity风格一致性、拒答边界
长文改写 / 创意写作中等温度，可保留一定多样性多样性、语气自然度
复杂推理 / 代码修复先调 reasoning effort，再看输出上限解决率、耗时、预算
Agent 工作流低温 + 明确工具协议 + 控制状态续接工具正确率、回环次数
批量评测固定配置，必要时使用 seed可复现性、统计可比性

核心结论：

  • 稳定性任务优先收紧协议
  • 多样性任务才重点谈采样空间

6. 参数联动里最容易踩的坑 ​

6.1 一次改太多参数 ​

最典型的错误是同时改：

  • temperature
  • top_p
  • max_output_tokens
  • prompt
  • schema
  • 模型版本

最后结果好坏都有了，但你根本不知道是谁造成的。

改法应该是：

  • 一次只动一类因素
  • 把模型、prompt、schema、工具定义、参数分开管理版本

6.2 用采样参数掩盖协议问题 ​

常见假象：

  • 工具参数老错，于是继续降温
  • JSON 老解析失败，于是继续降温
  • 多轮状态错乱，于是继续降温

但真实问题往往是：

  • 工具 schema 太松
  • 输出协议没版本
  • 历史上下文混入旧结果
  • 失败状态没有闭环

低温只能减少波动，不能替你补协议。

6.3 长任务不设长度上限 ​

不设上限时，常见后果是：

  • 费用不可控
  • 生成拖得很慢
  • 用户界面被长文淹没
  • 工具前置摘要越来越长，反过来拖垮下一轮

建议：

  • 面向用户显示的答案单独控长度
  • 面向工具或下游系统的结构化输出再单独控 schema

6.4 只看可见输出，不看总 token 消耗 ​

尤其在 reasoning 模型里，这个坑很常见。

你看到的回答也许只有两百字，但后台可能已经消耗了大量推理 token。

所以监控里至少要区分：

  • 输入 token
  • 输出 token
  • reasoning token
  • 缓存命中情况

6.5 用更高 effort 弥补脏上下文 ​

如果上下文本身已经错误、冲突或过长，那么提高 effort 往往只是：

  • 让模型更认真地在脏数据里推理

它不一定更准，只会更贵、更慢。

7. 参数与 Structured Outputs、工具调用的关系 ​

一旦进入结构化输出和工具调用场景，参数思路要发生变化。

7.1 结构化任务里，稳定性往往比“文采”重要 ​

例如：

  • 订单审批
  • 风险标签分类
  • SQL / API 参数生成
  • 提取字段落库

这类任务里，更重要的是：

  • 是否命中 schema
  • 是否遗漏 required 字段
  • 是否生成非法枚举

所以优先顺序通常应当是：

  1. 先用 Structured Outputs 或函数 schema 定义边界
  2. 再用低温减少波动
  3. 最后才考虑更细的采样优化

7.2 工具调用最怕“似是而非” ​

工具参数生成不是文学创作。

你更怕的是：

  • 参数名看起来像对的，其实含义错了
  • 模型凭想象补了一个不存在的字段
  • 缺少 required 字段，调用失败

这时调参重点不在“更会说”，而在：

  • 更遵守 schema
  • 更少多余字段
  • 更少无意义重试

7.3 高 effort 不等于更适合所有工具流 ​

复杂 Agent 里，提高 reasoning.effort 可能帮助规划，但也可能带来：

  • 更高延迟
  • 更高 token 消耗
  • 在简单任务上性价比变差

所以对工具流的推荐做法是：

  • 先按任务类别分路由
  • 简单任务低 effort
  • 难任务再升级
  • 不要所有请求一刀切开高档

8. 怎么把调参变成可评测工作 ​

8.1 先冻结非参数因素 ​

做参数实验前，先固定：

  • 模型版本
  • prompt 版本
  • schema 版本
  • 工具定义版本
  • 检索配置版本

否则实验结论不可信。

8.2 准备最小但覆盖业务风险的样本集 ​

不要只挑“好看的成功案例”。

应该覆盖：

  • 正常样本
  • 边界样本
  • 长上下文样本
  • 工具失败样本
  • 多轮续接样本
  • 高风险审批样本

8.3 记录不只是“主观好不好” ​

建议同时看：

  • 任务成功率
  • 结构化解析成功率
  • 工具调用正确率
  • 平均输出长度
  • 平均总 token
  • P50 / P95 延迟
  • 截断率
  • 重试率
  • 人工兜底率

8.4 建立“默认参数档位” ​

比起追求每个任务独一无二的参数，更实用的做法是建立档位：

  • stable_extract
  • support_reply
  • creative_write
  • agent_low_cost
  • agent_high_reasoning

这样团队更容易复用，也更容易灰度。

9. 企业里更实用的几条结论 ​

9.1 多数业务任务默认更适合低温起步 ​

因为大多数业务不是要“更有灵感”，而是要：

  • 更稳
  • 更少误触发
  • 更容易回归

9.2 想省钱，优先看输出长度和路由 ​

真正最常见的成本大头往往不是：

  • temperature 调高了点

而是：

  • 输出太长
  • 所有请求都走高价高推理模型
  • 上下文重复塞入
  • 工具失败后无限重试

9.3 想提速，优先看任务拆分和上下文压缩 ​

提速往往更有效的动作是：

  • 减少无关上下文
  • 缩短输出目标
  • 先分类再路由
  • 把复杂长链拆开

而不是单独迷信某个采样参数。

9.4 想提稳，优先看协议设计 ​

真正让系统稳定的往往是：

  • 明确输入层次
  • 明确输出 schema
  • 明确工具协议
  • 明确失败状态
  • 明确续接方式

参数只是最后一层细调。

10. 建议和哪些专题一起看 ​

11. 重点官方资料 ​