大模型输出为什么会重复：temperature、top_p 与停止条件的排查边界

线上问答接口突然把同一句话刷了十几遍，第一反应往往是把 temperature 往上调。但如果重复来自客户端重试、流式片段重复拼接，调采样参数只会把真正的问题藏起来。排查时应先确认请求只发了一次，再把生成参数和停止条件分开验证。

大模型输出重复通常有三条边界：请求或流式结果被重复处理、采样范围过窄导致生成循环、停止条件没有覆盖实际输出格式。先确认链路，再调整参数。

先判断重复发生在请求链还是生成阶段

把现象分成两类，结果会完全不同。若服务端日志只有一条请求，而浏览器显示两遍，重点看 SSE 读取游标、重连逻辑和前端状态合并。若服务端确实收到多次相同请求，再看幂等键、超时重试和网关策略。

建议给每次生成记录一个 request_id，同时记录模型名、输入摘要、采样参数和输出结束原因。相同 request_id 的片段只能按序号追加一次；重连时从最后确认的序号继续，不要把整段历史重新插入消息框。

{
  "request_id": "req-demo-001",
  "temperature": 0.2,
  "top_p": 0.9,
  "stop": [""]
}

temperature 和 top_p 分别改变什么

temperature可以理解为对候选概率分布的平滑程度：较低时更倾向高概率词，适合格式稳定的输出；较高时变化更多，但也可能让本来就窄的上下文更容易跑偏。它不是“去重开关”。

top_p则限制每一步参与采样的候选累计概率范围。范围收得太窄，模型可能反复选择同一条高概率路径；范围放宽后，重复现象未必消失，却可能引入更多无关内容。实际调试时固定一个参数，只改变另一个。

可以用四组短输入做小矩阵：固定提示词，分别记录 temperature、top_p、输出长度和结束原因。不要只凭一条回答下结论，至少比较多次相同请求的重复率。

停止条件要对准真实输出边界

如果应用要求模型在输出 JSON 后结束，停止序列应与协议中确实会出现的标记一致，例如约定的 。模型没有产生这个序列时，stop不会主动截断；把自然语言描述写进停止列表，也不能保证模型理解它是控制信号。

还要核对服务端返回的结束原因。正常停止、长度上限和异常中断应该分开统计。若每次都撞到长度上限，先缩短上下文或降低输出预算；若结束原因正常但页面重复，回到请求链检查拼接。

一套不容易误判的最小排查顺序

1. 核对请求次数：按 request_id 汇总网关、应用和模型侧日志，确认是否真的只生成了一次。
2. 核对片段顺序：给每个流式片段保留序号，发现重复序号时丢弃重放片段。
3. 固定输入：锁定模型、提示词、输入长度和输出上限，只调整 temperature 或 top_p 其中一个。
4. 检查停止原因：把正常停止、长度上限、取消和网络断开分别计数。
5. 复测边界：用短答案、结构化答案和长答案各跑一组，确认修复没有把截断问题变成空响应。

常见误区与安全边界

把两个采样参数一起改到极端，会失去可比较的基线；看到重复就盲目提高随机性，也可能破坏 JSON 格式。另一个常见误区是只看页面文本，不看原始响应：前端重连后的重复插入，和模型本身重复生成，在页面上很像。

生产环境还应保留输入摘要而不是完整敏感内容，记录参数和结束原因即可复盘。对自动执行工具的回答，重复输出不能直接触发两次副作用操作，必须先经过请求幂等和工具调用状态校验。

相关问题

只降低 temperature 能解决重复吗？

不一定。它只能改变采样倾向，无法修复重试、片段重复或停止标记不匹配。

temperature 和 top_p 要一起调吗？

排查阶段不建议。先固定一个参数，只调整另一个，才能知道变化来自哪里。

输出撞到长度上限是不是重复问题？

两者可能同时出现，但应先看结束原因和原始片段。长度上限需要处理上下文或预算，不能仅靠停止序列解决。

流式重连怎样避免把答案插入两次？

为片段保留单调序号和 request_id，客户端只接受尚未确认的序号，并在最终状态后停止追加。

小结

处理重复输出时，先分辨链路重放和模型生成，再用固定输入做单变量对照。采样参数负责候选选择，停止条件负责约定边界，幂等和片段序号则负责让一次生成只落到页面一次。