Gemini转录末尾吞词：补2秒静音找回3个词

摸鱼小队长 内容创作者 2026-11-03 192 阅读

2026 年 8 月 26 日，Google 推出 Gemini 3.5 Transcribe，把语音转文字从”听打”做成带整理的转录；到 10 月 31 日晚，它在 Google AI 开发者论坛上攒出一个很具体的投诉：音频结尾没有静音垫子时，模型会吞掉最后 2–3 个词。同帖给出的兜底办法是——尾部补 2 秒静音，文字就完整了。

为什么是现在值得看：这个模型正被推进 Android 版 Gboard 的 Rambler、macOS 版 Gemini 的”Speak to Window”，Chrome 侧也预告了集成（INSIDE，2026-08-26）。而 Google 同期对外的口径是：预录音频字词错误率仅 2.6%，最终转录速度改善 70%（Google 引用 Artificial Analysis 数据，INSIDE 转述）。在这个精度叙事下，末尾整段丢掉 2–3 个词属于另一类故障：不是听错字，是根本没写出来。放到语音输入场景，这正是最容易让人重复说一遍、又永远补不回来的那种失败。

下面凡标注”我的推算”的，是我依据帖子里的公开数字或公开代码路径算出来的，不是官方结论；其余事实均出自文末链接原文。

症状比想象中窄：两个长文件、一个短片段

发帖人 linohype 给出的测试条件相当具体：241 秒和 260 秒的德语 MP3，单声道、64 kbit/s、44.1 kHz，解码无报错，说话内容一直延续到文件末尾。转录结果缺最后 2–3 个词，最后一句从中间被切断，verbatim（忠实转录）与 smart（智能整理）两种模式”切在完全相同的那个词上”。

三个排除性证据值得单独拎出来，因为它们把问题从”你的环境有毛病”推回到模型侧：

一是稳定复现。同一文件两次独立运行，断在同一处，不是随机抖动。

二是排除了客户端解析问题。原始 interaction 里只有一个 model_output 步骤、一个文本内容项，状态为 completed，缺的词在整个响应体里根本不存在。

三是整段音频确实都被处理了。帖子给出的输入量是”全长约每秒 25 个 token”，260 秒对应 6500 个音频 token。

测试条件 结果
241 s 德语 MP3，说话延续到结尾 末尾缺 2–3 个词
260 s 德语 MP3，说话延续到结尾 末尾缺 2–3 个词
同一文件截取 21 s 片段 完整，加不加尾部静音都一样
同一文件尾部补 2 s 静音 完整
gemini-2.5-flash 转同一文件 完整

补静音的对照实验：两条命令加一次校验

兜底思路很朴素：在音频流末尾接一段静音，让”语音结束”这个边界不与文件结束重合。下面这段命令按帖子描述的做法复现”追加 2 秒静音”，输出再喂给转录接口：

# 追加 2 秒静音（常规做法，会重新编码）
ffmpeg -i input.mp3 -af "apad=pad_dur=2" -ac 1 -ar 44100 output_padded.mp3

# 顺带检查文件时长是否真的多了 2 秒
ffprobe -v error -show_entries format=duration -of csv=p=0 output_padded.mp3

需要说清一处口径差异：帖子里强调的是”追加静音 MP3 帧、原音频不重新编码”，而上面这条 ffmpeg 命令会整体重编码。为了对齐帖子的结论，下面用一个只看尾部词数的脚本做对照，而不是肉眼比：

# 对比原始版与补静音版的转写结尾（对照帖子里的两个 interaction 结果）
def tail(text, n=8):
    return " ".join(text.strip().split()[-n:])

a = tail(open("transcript_original.txt", encoding="utf-8").read())
b = tail(open("transcript_padded.txt", encoding="utf-8").read())
print("原始 :", a)
print("补静音:", b)
print("尾部一致:", a == b)

如果原始版的末尾停在半句话上，而补静音版多出完整结尾，就复现了帖子里的现象。

另一个可复算的自查点是 token 密度。帖子公开的数字是约每秒 25 个音频 token、260 秒对应 6500 个，所以：

# 按帖子的公开密度做 sanity check（这是按公开数字推算，不是官方阈值）
DUR=260
echo "预期音频 token ≈ $((DUR * 25))"

如果你的调用返回的输入 token 数与”音频时长 × 25″大致相当，说明整段音频确实进了模型，问题不在上传环节；这比反复重传文件要省事。

另一类”没转出来”：OpenAI 兼容代理会整段静默丢弃

2026 年 9 月 9 日，CLIProxyAPI 项目的 issue #5722 记录了完全不同形态的一次丢失。该项目在 Gemini → OpenAI chat-completions 响应转换器里只处理 text、functionCall、inlineData 三种 part，而 gemini-3.5-transcribe 把转录结果放在独立的 audioTranscription part 里。转换后 choices[0].message.content 是空字符串，completion_tokens 为 0；流式（streamGenerateContent?alt=sse）形状相同、结局相同。

复算这一步并不需要自己造数，只要顺着公开的代码路径走一遍：

模型侧输出 parts = [ audioTranscription(text) ]
转换器已实现的分支 = { text, functionCall, inlineData }
→ audioTranscription 未命中任何分支
→ content = "" 且 completion_tokens = 0
调用路径 模型是否转出了文本 客户端看到什么
直接走 Gemini API（Files + Interactions） 转出 正常的文本内容项
经 OpenAI 兼容端点 /v1/chat/completions 转出 空字符串、0 token
经 OpenAI 兼容端点流式 转出 空 delta

按这个复算可以推出一个操作性结论（我的推算）：遇到”HTTP 200、但内容为空”的工单，先怀疑协议转换层有没有把 audioTranscription part 映射成文本 part，而不是先怀疑模型能力、额度或网络。

两种”缺字”别混成一件事

同一社区里同时存在几种外观相似、机理不同的故障，值得分开看。官方论坛挂着 2026-08-28 的 “Gemini-3.5-transcribe returns empty transcription (HTTP 200, zero output tokens) on all documented REST paths”，2026-08-04 的 “gemini-3.5-live-translate-preview consistently truncates the last words of translated audio output”，以及 10 月关于 Gemini-3.8-flash-tts 尾音毛刺的主题。这些说明”末尾出不来字”在 Google 的音频模型线上不是孤例。

但它们不是同一个 bug：论坛主帖里的末尾缺词只出现在长文件上，补静音即可恢复；CLIProxyAPI 那个属于协议层整段丢失，与文件长短无关；实时转录则是另一回事——GitHub 上 DevEmperor/DictateKeyboard 的 issue #372 记录了停止录音时最终几个词经常缺失，那属于流式尾帧处理，与离线文件末尾截断不是同一条路径。

还有一个容易被忽略的跨源矛盾：按 INSIDE 的报道，smart 模式无法与逐字时间戳、说话者识别同时使用，想拿到时间戳就必须切回 verbatim。但论坛主帖明确写了两种模式”切在完全相同的那个词上”——也就是说，换模式解决不了末尾截断，指望靠降级到 verbatim 兜底的用户可以省一次折腾。

官方口径与实测之间的盲区

Google 对外主推的是 2.6% 的预录音频字词错误率、85 种以上语言自动识别、最多 3 名说话者标注、最多 1000 个自定义词汇（ectimes，2026-08-30，中文社区视角转述）。这些指标和能力都成立，但它们衡量的是”听错了多少字”，不是”尾部有没有被切掉”。

按我的理解，这类指标对系统性末尾截断天然不敏感：被切掉的词不作为错字计入错误率，而是干脆不在输出里。这意味着官方给出的精度数字和你手上的”最后一句少几个词”可以同时为真，不构成矛盾，别用 2.6% 去反驳用户报告，反过来也别拿用户报告去否定整体精度。

截至 2026 年 10 月 31 日晚 8:32 发帖，回复区只有一位 11 月 1 日凌晨 5:23 的用户要求提供代码和输入以便复现，尚未看到官方工程师给出的结论。帖子同时贴出了两组 interaction ID：原文件（缺词）与补静音（完整），任何拿到同一文件的人都能复现同一结果——这也是它比口头抱怨更有价值的原因。

对使用者的边界判断

如果你的语音输入或批量转录流水线用了 Gemini 3.5 Transcribe，最省事的做法是在客户端侧统一给音频补一段尾部静音，成本是几毫秒音频加一次 ffmpeg 调用；如果你走的是 OpenAI 兼容协议，先查转换层有没有处理 audioTranscription part。这两条都是我的经验判断，不是官方说法，官方尚未就这个现象发布修复说明或变更记录。

参考来源

# AI# 知识

评论区

0 条评论

登录后可评论。

摸鱼小队长 192 阅读