大模型流式输出为什么会重复半句：增量拼接、UTF-8 边界与结束标记

聊天窗口里偶尔多出半句，最容易误判成模型“重复生成”。实际排查时，先看客户端是不是把同一个增量块消费了两次，再看 UTF-8 解码是否跨字节边界，最后确认结束事件有没有被当成正文追加。只要这三个边界分开，问题通常能在网络日志和拼接日志里定位。

流式文本应当只追加每个新到的增量片段；事件边界负责拆消息，UTF-8 解码器负责拼字符，结束标记只负责收尾，三者不能互相替代。

重复半句通常出在哪个环节

一次流式请求至少经过服务端生成、传输分帧、客户端解析、文本拼接和界面渲染五个环节。模型返回的是增量片段，不是每次都从头开始的完整答案；客户端如果把“当前累计文本”再次追加，就会出现整句或半句重复。

另一个常见误区是把网络读取次数当成消息次数。一次读取可能包含半个事件，也可能包含多个事件。SSE 的消息以空行分隔，事件正文使用 UTF-8 编码，这两个事实决定了“读取一次就解析一次”并不可靠。

先核对增量块，再检查拼接状态

给每个请求保留可追踪的消费记录

日志至少保留请求标识、事件序号、事件类型、增量文本长度和累计长度。不要默认文本内容可以去重，因为模型可能合法地产生连续相同词语；更可靠的判断是同一请求、同一序号是否被处理两遍。

让状态机只有一个追加入口

把流式消费拆成“收帧、解析、追加、收尾”四个小阶段，界面层只订阅累计文本，不再自己读取网络流。追加函数接收单个增量片段，并在同一请求上下文中记录已处理的事件序号。重连或重试时生成新的请求标识，不能把旧请求的序号表直接沿用。

这里别急着加“去重半句”的字符串算法。它会误删真实重复词，也无法修复事件重复消费。先把重复出现的序号和调用次数对上，通常更快。

UTF-8 边界为什么会制造看似重复的文字

中文字符通常由多个 UTF-8 字节组成，而网络读取可以在任意字节处截断。如果每次读取都立即转换成字符串，半个字符可能被替换符吞掉；后续补齐后又被重新解码，日志看起来就像字符回跳、重复或缺失。

正确做法是让解码器保存未完成的字节，等下一段到达后再组成完整字符。事件解析也要独立于字符解码：先按 SSE 的事件边界拿到完整 data 字段，再把字段内容交给 JSON 解析和增量文本处理。不要把“一个 TCP 读取”“一个 SSE 事件”“一个 UTF-8 字符”当成同一件事。

结束标记只负责收尾，不负责补正文

不同服务的事件名称和结束信号可能不同，但消费原则一致：普通增量事件进入拼接，完成事件更新状态，错误事件进入错误分支，心跳或注释帧不改变正文。收到完成信号后，关闭读取循环并做一次累计长度核对。

如果服务同时提供最终文本和增量片段，二者只能选一种作为正文来源。把最终文本再追加到已经拼好的增量文本后面，正是“最后半句重复”的高频来源。

一张表完成回归验收

修复后不要只点几次发送按钮。至少覆盖短中文、连续标点、空增量、正常结束、网络中断和重试六种情况；每次都核对事件序号、累计字符数和最终状态。若页面显示正常但日志中的追加次数多于增量事件数，问题仍然没有真正关闭。

• 同一请求的同一增量事件只出现一次追加记录。
• 跨读取边界的中文字符不会出现替换符或回跳。
• 完成事件不会改变正文内容，只改变请求状态。
• 中断和重试会生成清晰的新请求标识，不污染旧会话。

相关问题

为什么网络读取一次不能直接转成一句话？

读取边界由传输层决定，可能截断事件或 UTF-8 字符；必须先完成事件和字符层的组装。

能不能用字符串替换删掉重复半句？

不建议。连续相同词语可能是合法输出，应该根据请求标识和事件序号修复重复消费。

完成事件还要不要追加文本？

只有当协议明确把完成事件定义为新的正文片段时才追加；常见设计是完成事件只表示收尾。

把排查顺序固定下来

遇到流式输出重复，先对齐请求标识和事件序号，再确认事件帧与 UTF-8 解码是否分层处理，最后检查完成事件和最终文本是否被二次追加。这个顺序能把“模型问题”的猜测，收敛成几条可以复现、可以回归的客户端证据。