推理参数与解码策略

• 理解三个采样参数的作用
• 理解联合调参
• 理解任务差异的推荐配置

机理：temperature 控制采样分布的"平滑度"——高温度让低概率 token 更可能被选（更随机、更多样），低温度更集中于高概率（更确定）；top_p（核采样）截断只从累计概率达到 p 的 token 中采样，去掉长尾低概率 token；top_k 只从概率最高的 k 个 token 中采样。联合调参：temperature 与 top_p 常一起用（都低=更确定，都高=更多样），top_k 是硬截断。任务推荐：代码生成——低 temperature（0~0.3）+ 低 top_p，追求确定与正确；创意写作——高 temperature（0.7~1.0）+ 高 top_p，追求多样与新颖；结构化抽取——接近 0 的 temperature + top_p，追求格式与确定。三者相互配合，需按任务平衡"多样性 vs 确定性"。核心是"temperature 控制随机性、top_p 去长尾、top_k 硬截断，按任务调低/高搭配"。

三个参数都控制"采样随机性"，但方式不同。任务要求"确定性"（代码/结构化）用低值，要求"多样性"（创意）用高值。联合而非单独调。

• 理解 max_tokens 与 stop 序列
• 理解截断检测
• 能设计续写

max_tokens 限制输出 token 上限，stop 序列指定模型停止生成的标记（遇到即停）。截断检测：当输出的 finish_reason 为 length（达到 max_tokens）而非 stop，说明被硬截断；stop 序列触发的正常结束则 finish_reason 为 stop。续写策略：检测到 length 截断时，把已生成内容作为 assistant 历史回填，继续请求生成剩余部分，直到自然结束或达到轮次上限；对 stop 序列，确认不是"误停"（stop 序列出现在内容中）再决定。续写要避免重复上下文、设置轮次上限防死循环。核心是"用 finish_reason 区分截断与正常结束，length 截断用续写回填上下文处理，stop 序列正常结束"。

截断检测的关键是 finish_reason（length vs stop）。续写要回填已生成内容、设上限。stop 序列是"正常结束信号"，与截断不同。

• 理解两种惩罚机制差异
• 理解适用场景
• 理解过度惩罚的退化

机制差异：repetition_penalty（重复惩罚）——对已出现过的 token 施加固定惩罚（无论出现几次），惩罚力度固定；frequency_penalty（频率惩罚）——按 token 出现的次数累加惩罚，出现越多惩罚越大。适合场景：repetition_penalty 适合抑制"某 token 一出现就重复"的机械重复；frequency_penalty 适合抑制"高频重复"，更适合长文本中控制重复的多样性。过度惩罚的退化：惩罚过强会导致——模型为避免重复而过度回避常用词，产生词穷、表达生硬、语句怪、甚至出现与语义不符的替代词；frequency_penalty 过强会让模型刻意避开必要重复的词（如"的""是"），导致句子不通顺；过度惩罚还可能降低连贯性与质量。核心是"固定惩罚管'一出现就重复'、频率惩罚管'高频重复'，过度惩罚会导致词穷与表达异常"。

两种惩罚机制维度不同：固定 vs 累加。场景上一种管机械重复、一种管高频。过度惩罚会引发"为了不重复而扭曲表达"的退化。

• 理解 min_p 原理
• 理解与 top_p 的差异
• 理解优劣势

top_p：从累计概率达到 p 的 token 集合中采样，阈值是"动态累计"的——当分布很均匀时集合大，很集中时集合小。min_p：设定一个"绝对下限比例"（基于最高概率 token），只从概率 ≥ max_prob × min_p 的 token 中采样——阈值是"相对最高概率"的绝对下限。差异：top_p 的集合大小随分布形态变化，可能在分布均匀时引入过多低概率 token；min_p 固定"相对最高概率"的下限，更稳定地排除低概率 token。为何在某些模型上优于 top_p：min_p 在需要"既保留多样性又有一定确定性"时更稳——它不会像 top_p 在分布均匀时过度扩大集合，也不会在分布集中时过度收缩，且对参数选择更鲁棒。核心是"top_p 用累计比例动态截断、min_p 用相对最高概率的绝对下限截断，min_p 在稳定排除低概率 token 上更稳健"。

两者都截断低概率 token，但机制不同：top_p 按累计、min_p 按相对最高概率。min_p 的"绝对下限"对分布形态更鲁棒，因此某些模型上效果更好。

• 理解约束解码与原生 Structured Outputs
• 理解格式保证、延迟、成本差异
• 能设计选型

约束解码（grammar-based sampling）：用 GBNF/JSON Schema 约束模型"只能生成合法 token"，在本地/自部署上实现，格式保证强（解码阶段强制合法），延迟略增（约束计算），成本可控（无额外 API 费用），但需自建与维护。Provider 原生 Structured Outputs：Provider 内置的保障（如严格 JSON mode），调用简单、格式保证强，延迟与成本由 Provider 定价（可能略高或计费），依赖 Provider 能力。差异：约束解码——自建、可控、适自部署、无额外费；原生 Structured Outputs——省事、内置、依赖 Provider、可能计费。选型：自部署/需完全可控/不想依赖 Provider 用约束解码；用商用 API 且要求极简用原生 Structured Outputs；也可组合（原生为主，约束解码兜底）。核心是"约束解码自建可控、原生 Structured Outputs 省事内置，按部署形态与成本选型"。

两者都保证格式，区别在"谁实现"与"成本"。约束解码自建免费可控，原生内置省事但依赖 Provider。选型看部署形态与对 Provider 的依赖。

• 理解结构化输出与解码约束
• 理解结合方式
• 能设计减少格式错误

结合：结构化输出（JSON Mode/Function Calling）要求模型输出合法 JSON/工具调用；解码约束（grammar/schema）在解码阶段强制模型只能生成符合 schema 的 token，从源头杜绝格式错误。结合方式：用 JSON Schema 约束解码——解码时强制生成合法 JSON 结构（键名、类型、嵌套），保证格式正确；工具调用用 schema 约束参数格式；对"必需字段"用约束强制（缺失则解码失败重试）。结合后，格式错误大幅减少（解码阶段就合法），剩余错误是"语义错误"（值不对）而非"格式错误"，再用校验与重试处理。核心是"约束解码在解码阶段强制格式合法，JSON Mode/Function Calling 定义结构，两者结合消灭格式错误，只留语义校验"。

约束解码"从源头保证格式"，JSON Mode"定义结构"，结合后格式错误在解码阶段即被消除。剩余只需做语义校验与重试。

• 理解流式与解码参数的交互
• 理解流式稳定性问题
• 能设计评估

流式输出按 token 增量返回，需在前端拼接；解码参数影响流式稳定性：半截 token——多字节 UTF-8 字符可能被拆到多个增量中（增量含半个字符），需缓冲拼接；重复段——高 temperature 或惩罚不足时流式可能重复输出段；截断恢复——流式中间若被截断（长度/网络），续写需恢复。评估：对参数组合跑流式，检查——增量字节是否可正确拼接（无乱码）、有无重复段、截断后能否恢复、流式首 token 延迟与稳定性。稳定性：用低 temperature/固定 seed 减少重复；用缓冲处理半截 token；截断恢复用"已生成内容回填续写"。核心是"流式需处理半截 token（缓冲拼接）、重复段（采样控制）、截断恢复（回填续写），并评估参数组合下的增量稳定性"。

流式稳定性的三个问题：半截 token（编码）、重复段（采样）、截断恢复（状态）。参数与流式交互需评估，并针对三点做缓冲/采样/回填处理。

• 理解评估集驱动的调参
• 理解参数搜索
• 能设计评选定参

方法：用评估集+参数网格搜索确定推荐区间，而非凭经验——对 temperature/top_p 在候选值（如 temp ∈ {0, 0.2, 0.5, 0.7}）上组合，在固定评估集上跑，测结构化任务指标（Schema 通过率、字段准确率、抽取正确率），选出指标最优且稳定的参数区间。原则：结构化任务趋向"低 temperature（0~0.3）+ 低 top_p"以保确定，但具体值用数据验证——在评估集上对比不同参数下的准确率与稳定性，选"准确率高且波动小"的区间。同时验证：低参数是否已足够（0 是否必要）、是否需约束解码。核心是"用评估集上做参数网格搜索，按准确率/稳定性选区间，而非凭经验"。

参数选择应数据驱动。结构化任务通常低 temperature/top_p，但具体区间用评估集网格搜索验证，选"准确高 + 波动小"的组合，避免凭经验或过度保守。

• 理解 temperature=0 的局限
• 理解确定性输出不可保证的原因
• 能设计可复现

temperature=0 不保证完全确定：一是采样实现——即使 temperature=0，部分实现仍可能引入随机（如 top_p 内部的采样、softmax 的数值差异、后端并行）；二是后端/版本——模型版本升级、推理实现、tokenizer 变化都会改变输出；三是并发/批处理——并行场景下实现可能引入非确定性。因此同一请求仍可能返回不同结果。提升可复现性：固定 seed（使随机源确定）、固定 temperature/top_p/模型版本、固定输入与上下文、用确定性的输出（如缓存复用）。但即便全部固定，Provider 后端变化仍可能漂移，需接受"提高概率而非绝对保证"。核心是"temperature=0 不保证绝对确定（实现/版本/后端会引入差异），用 seed+固定参数+版本+缓存提升可复现性"。

temperature=0 只是"降低随机"，不是"排除随机"。实现细节、版本、后端都会引入非确定性。可复现靠固定 seed、参数、版本并接受残余漂移。

• 理解 logit_bias 原理
• 理解应用与限制
• 理解风险

logit_bias：在采样前对指定 token 的 logit 加偏置，改变其被选中的概率——可用来"推高"想要的 token（如强制输出特定符号、格式标记）或"压低"不想要的 token（如禁止某词）。工程应用：修正格式习惯（如强制输出 JSON 的引号/花括号）、引导特定术语、抑制禁用词。限制：一是 token 级——需按 tokenizer 的 token id 偏置，一个词可能拆成多个 token，需偏置所有相关 token；二是影响采样——偏置可能破坏自然语言流畅性，导致生硬；三是按 token 偏置难以表达"语义级"约束。风险：过度偏置导致输出不自然、格式与语义冲突；token id 随 tokenizer 变化，需维护映射；偏置与约束解码/structured output 有重叠，可能冲突。核心是"logit_bias 按 token 加偏置修正格式/术语习惯，但限制在 token 级、需维护 token id 映射、过度偏置伤流畅性"。

logit_bias 是"token 级干预"，适合微调格式/术语，但粒度粗（token 而非语义）、需维护 token id、易伤流畅性。复杂约束应优先用约束解码/结构化输出。

• 理解输出 token 计费
• 理解 max_completion_tokens 的作用
• 能设计成本控制

输出 token 计费：输出按 token 计价（通常比输入贵），输出越长成本越高；max_tokens 限制输出长度上限，因此直接影响成本与延迟（输出越长生成越慢、越贵）。max_completion_tokens（部分 Provider 的完整输出上限，含思考 token）——显式限制总输出长度，防止推理模型思考链过长导致成本失控。控制成本与延迟：按任务设定合理 max_tokens/max_completion_tokens 上限（避免默认无限）；对推理模型设 max_completion_tokens 限制思考+输出总量；监控输出长度分布，异常超长告警。注意：max_tokens 过小会截断（finish_reason=length），需平衡。核心是"输出越长越贵越慢，用 max_tokens/max_completion_tokens 限制输出上限（含思考）控制成本与延迟"。

输出成本与长度成正比，控制成本的关键是"设输出上限"。max_completion_tokens 对推理模型尤其重要（限制思考+输出），防止超长思维链失控。

• 理解评测可复现的条件
• 理解参数漂移的污染
• 能设计评测规范

回归评测必须固定 seed/参数/模型版本：因为评测要对比"模型/Prompt 变化"对质量的影响，若 seed/参数/版本不固定，输出差异可能来自采样随机或版本变化，而非被评测的变更——导致"假阳性/假阴性"。参数漂移污染对比实验：同一评测集，若 temperature 变了、seed 不固定、或模型版本升级，输出的质量差异就无法归因于"被对比的变更"，对比结果失真。评测规范：固定 seed、固定 temperature/top_p 等全参数、固定模型版本与 tokenizer、固定输入顺序；用多 seed 重复取平均（减少随机）并报告波动；任何参数/版本变更都记录在评测环境指纹中。核心是"固定 seed/参数/版本才能让评测归因于变更，参数漂移会污染对比实验"。

评测的"对照"要求"除被对比项外都固定"。参数/seed/版本漂移会让差异无法归因，污染对比。固定环境 + 多 seed 平均 + 记录指纹。

• 理解 logprobs 的应用
• 理解置信度与软标签
• 能设计应用

logprobs 应用：置信度评估——对生成/分类结果的 token 概率求平均/取最小，作为置信度信号，低置信触发拒答、复核或升级；分类任务软标签——分类时用各候选类别的 logprob 归一化成概率分布，作为"软标签"（而非硬选一个），供下游决策（如加权、阈值、多分类置信度）。场景：路由决策（低置信升级）、质检（量化置信分布）、多分类置信度（软标签用于下游融合）。注意：logprobs 是"模型对自身输出的概率"而非"事实正确率"，需结合校验；Provider 支持差异需查能力矩阵。核心是"logprobs 用于置信度评估（拒答/复核/升级）与分类软标签（概率分布），但作为置信信号而非正确性指标"。

logprobs 把"模型的概率"显式化，可用于置信度与软标签。但它是"自评概率"非"正确性"，需结合校验，且受 Provider 支持限制。

• 理解 beam search 与采样
• 理解 API 暴露差异
• 理解自部署实现成本

beam search 与采样是两种解码策略：beam search 维护多个候选序列（beam），选整体概率最高的，更确定但计算量大、易重复；采样从概率分布随机选 token，更多样但随机。商用 API 很少同时暴露：一是实现复杂且维护两套解码逻辑成本高；二是大多数 API 场景用采样（配合温度等）即可，beam search 的收益有限且与采样参数体系冲突；三是产品定位通常只提供一套主流解码。自部署差异：实现成本——beam search 需管理 beam 候选、显存与计算开销大，采样实现简单；适用场景——beam search 适合"需要确定、可度量最优"的任务（如翻译、受控生成），采样适合"多样、创意、交互"任务。核心是"beam 确定但贵、采样多样但随机，API 多只暴露采样，自部署可按任务选 beam 或采样"。

beam search 偏"确定/最优"但计算重，采样偏"多样"但随机。商用 API 为简化只暴露一套（采样），自部署可按任务选择。差异在计算成本与适用性。

• 理解 seed 的作用
• 理解可复现生成
• 理解回归测试

seed 固定随机数生成器的初始状态，使"同一请求 + 同参数 + 同模型版本"的采样序列确定，从而可复现输出。用于可复现生成：对关键、需要一致性的输出，固定 seed + 固定 temperature/top_p + 固定版本，使重复请求得到相同结果；用于回归测试：回归评测固定 seed，让同一输入在代码变更前后得到可比较的输出，从而判断"变更是否影响行为"（排除采样随机干扰）。注意事项：seed 只在"同版本 + 同实现"下有意义，跨 Provider/版本不保证一致；seed 提高可复现但非绝对（后端漂移）；回归测试可固定多个 seed 取平均。核心是"seed 固定随机源使同请求可复现，用于可复现生成与回归测试（固定版本+参数）"。

seed 是"可复现的开关"，配合参数与版本固定。用于生产可复现输出与回归测试排除随机干扰。但跨版本不保证，需固定环境。

• 理解流式增量渲染
• 理解解码参数与流式
• 理解中断恢复

流式增量渲染：前端按 token 增量接收并渲染，需处理半截 UTF-8 字符（缓冲拼接后再渲染）、markdown 增量（分块渲染需兼容）、实时更新。解码参数结合：低 temperature 减少流式重复/抖动，让增量渲染更稳定；固定参数减少流式内容突变。中断恢复：流式被中断（网络/超时/截断）时——记录已接收内容，用"已生成内容回填"续写请求，继续生成剩余部分；或检测到截断（finish_reason=length）触发续写；前端显示"已生成部分 + 继续生成状态"。核心是"流式前端做缓冲拼接、markdown 增量渲染，结合低温度稳采样，中断时用已生成内容回填续写恢复"。

流式渲染要处理半截编码与增量更新，解码参数（低温度）稳采样，中断恢复靠"已生成内容回填续写"。三者结合保证流式体验。

• 理解多模态解码参数
• 理解治理与回归
• 能设计参数治理

多模态生成参数与文本不同：图像——采样步数（步数多质量高但慢）、引导系数（guidance scale，控制与提示一致性）、温度（扩散采样）；语音——温度、采样率、时长等。治理：把多模态参数与文本参数分开管理——不同参数集、不同默认值、不同评估；为每个模态定义参数 schema 与版本；多模态受影响于"步数/引导/温度"等，需单独调参。回归：多模态质量评估用多模态指标（图像质量、一致性、语音清晰度），回归测试固定各模态参数版本，用评估集对比；与文本参数分开回归，避免相互污染。核心是"多模态参数（步数/引导/温度）与文本参数分开治理，各自 schema 与评估集，单独回归"。

多模态生成参数体系与文本不同，且各自独立。治理要分开——参数 schema、默认值、评估、回归都按模态隔离，避免混用。

• 理解参数随版本失效
• 理解重新校准
• 理解质量漂移监控

参数随版本失效：模型版本升级后，原参数（temperature、top_p、惩罚等）的语义/效果可能变化，导致质量漂移（如原温度现在偏随机或偏保守）。重新校准：模型升级后，用评估集重新做参数网格搜索，校准到新版本的最优参数区间；不沿用旧参数假设。监控：对参数效果设监控——用评估集/影子流量对比"升级前后同参数的质量指标"，检测漂移；监控输出质量指标（准确率、格式通过率、多样性）变化，异常告警；参数变更与版本变更都记录，便于归因。核心是"模型升级后解码参数需用评估集重新校准，监控参数效果漂移与质量指标变化"。

参数是"绑定模型版本"的，升级即可能失效。重新校准（评估集网格搜索）+ 监控（质量指标漂移检测）缺一不可，避免沿用旧参数导致质量下降。

• 理解参数跨 Provider 差异
• 理解契约测试
• 能设计对齐

参数语义差异：temperature 的默认值、作用范围（是否影响思考 token）、支持范围、与 top_p 的交互在各 Provider 不同；如某 Provider 默认 temperature 高、某 Provider 默认 0，或某 Provider 的 temperature 不作用于部分 token。契约测试对齐：为每个 Provider 定义"参数语义契约"——声明默认值、取值范围、作用范围、与其它参数的交互；用契约测试验证"传入统一参数，各 Provider 的请求体/参数实际值正确"；对"语义不同"的参数做归一化映射（如把内部的"确定性档位"映射到各 Provider 的 temperature）。契约测试锁定"统一参数 -> 各 Provider 参数"的映射，防止假设与实际不符。核心是"参数跨 Provider 语义不同，用契约测试锁定'统一参数到各 Provider 参数'的映射与默认值/作用范围"。

参数在 Provider 间语义不同（默认值、作用范围），不能假设"同参数同效果"。契约测试把映射锁死，暴露差异，保证归一化正确。

• 理解批处理参数统一
• 理解截断与重试
• 理解与在线差异

批处理参数统一：离线批量大量请求用同一组参数（统一 temperature/top_p/max_tokens），保证结果一致可比；对需要不同参数的请求按任务分组，组内统一。截断处理：批量中输出超长被截断，记录并重试（调大 max_tokens 或续写），或按任务分批处理避免单次超长。重试：批量重试成本低（延迟不敏感），失败请求可完整重试，用幂等去重。与在线差异：在线——延迟敏感，参数按实时预算（低温度、有限重试），追求即时响应；离线——延迟不敏感，可用批处理折扣、更大重试、更精细参数调优，追求吞吐与成本。核心是"批处理统一参数、延迟不敏感可扩展重试与截断处理，利用批处理折扣；在线追求即时响应、参数按实时预算"。

离线批量与在线推理的差异在"延迟 vs 吞吐成本"。批量统一参数、可大重试、用折扣；在线参数按实时预算、有限重试。截断分别处理。