大模型流式输出为什么会重复片段：增量拼接、断线续传与去重边界

线上聊天接口偶尔把半句话重复一遍，最容易先怀疑模型不稳定。实际排查时，重复内容往往来自客户端把“累计快照”当成“新增片段”拼接，或者断线重连后没有处理事件重放。先把每次收到的事件编号、累计长度和最终文本长度记下来，通常几分钟就能看出重复发生在哪一层。

先把重复现象量化：不是所有重复都来自模型

先在客户端记录四个字段：event_id、事件类型、这一事件携带的文本长度，以及当前拼接缓冲区长度。假设服务端连续返回 你、好、，今天，客户端最终长度应当接近三段文本长度之和；如果每个事件都带着从开头到当前位置的完整快照，直接追加就会得到“你你好你好，今天”。

建议把重复率定义成一次请求中重复字符数除以最终字符数，并同时记录重连次数。重复率只在同一请求内比较，不能拿不同提示词、不同模型或不同温度的自然重复当作故障证据。

两个假设：增量拼接错误，还是断线事件被重放

排查顺序可以从最便宜的验证开始。第一种假设是 SDK 回调给的是累计文本，但业务层又调用了 append；第二种假设是连接中断后，服务端从上一个确认点重放了几条事件，而客户端只把连接当成全新会话。

这两类问题的日志形状不同：前者通常从第一条事件就持续偏长，后者往往在某个重连时间点出现一段完全相同的事件 ID 或文本前缀。把连接序号和事件序号放在同一行日志里，比打印完整回答更容易保护用户内容。

log.info("stream event request={} conn={} event={} mode={} deltaLen={} totalLen={}",
    requestID, connectionNo, eventID, payloadMode, delta.length(), buffer.length());

改动点：把事件处理改成可重复执行

事件处理器要先判断事件语义，再决定覆盖还是追加。若协议提供唯一事件 ID，就把最近处理过的 ID 放入请求级集合；若只有游标，就保存“最后确认游标”，重放事件只更新确认位置，不再次写入缓冲区。

switch event.Mode {
case "delta":
    if seen(event.ID) { return }
    buffer.WriteString(event.Text)
    markSeen(event.ID)
case "snapshot":
    buffer.Reset()
    buffer.WriteString(event.Text)
}
ack(event.Cursor)

这里的 seen 只应覆盖当前请求或当前响应流，不能做成无限增长的全局集合。请求结束后释放它；需要跨重连恢复时，保存的是服务端定义的游标，不是把全部文本再次发给服务端。

压测方法：固定回答、故意制造断线，再看三组指标

为了让结果可比，先固定模型、输入、采样参数和测试回答，然后在第 3、8、15 个事件后分别模拟连接中断。每种场景至少跑 30 次，记录最终文本哈希、重复率和重连后的首个事件 ID。人工阅读一两次只能发现明显问题，不能证明幂等逻辑覆盖了所有重放位置。

可以把验收结果整理成三列：无断线时重复率必须为零；断线重连时最终文本哈希应与无断线基线一致；重复事件计数可以增加，但实际写入缓冲区的事件计数不能增加。若服务端本身每次重试都会生成新内容，就不能强行要求哈希一致，而应比较协议允许的结果边界。

结果怎么看：先定位重复发生的层，再决定修复位置

如果网络抓包中的事件文本没有重复，而页面显示重复，问题在 SDK 适配或前端状态更新；如果抓包已经重复，先看事件 ID 是否重复。相同 ID 重复出现，优先做幂等；不同 ID 却携带相同文本，则要确认协议定义的是增量还是快照，不能只靠字符串相等判断。

页面层还要避免“全量快照 + 增量追加”混用：React、Vue 或原生 DOM 更新都应明确一个唯一数据源。服务端推送累计快照时直接替换展示值，推送 delta 时才追加，提交按钮和重试按钮也要共享同一个请求状态。

边界条件：哪些重复不能简单删除

“哈哈”“非常非常重要”或代码中的连续字符可能是模型有意生成的内容。用正则删除连续片段，会把正常答案改坏。断线期间如果用户重新提交了一次请求，两个请求的文本也不能在客户端合并；应使用请求 ID 区分，并在界面上明确当前显示的是哪一次响应。

安全上不要把完整提示词、回答内容和访问凭据写进调试日志。事件 ID、长度、哈希和状态码足以定位大多数拼接故障；生产环境需要对日志字段脱敏，并设置保留时间。

相关问答

为什么只在网络差时出现重复？

网络抖动会触发重连或事件重放，把平时隐藏的幂等缺口暴露出来。先比较重连前后的事件 ID 和游标，不要直接修改文本。

能不能按文本前缀去重？

只能作为特定协议的兜底策略，不能替代事件 ID 或游标。自然语言本身可能重复，前缀匹配容易误删。

如何判断服务端返回的是快照还是增量？

查看实际 SDK 或接口文档，并用三个短事件做实验：若第二个事件包含第一个事件内容，通常是快照；否则更接近增量，但最终仍以协议定义为准。

小结

流式输出重复的核心不是“把重复文字删掉”，而是先确认事件语义，再让覆盖、追加和重连恢复分别拥有清晰的边界。把事件 ID、游标、连接序号和最终文本哈希纳入测试，才能在模型、网络和前端状态同时变化时，仍然知道哪一层出了问题。