实时语音交互应用对语音转文本ASR的要求通常比离线录音转写更难满足。以 Gemini 3.5 Transcribe 为代表的面向实时语音交互的高精度语音转文本模型核心目标是在用户说话过程中同步返回文本并将延迟控制在对话可接受的范围内。这个概念听起来简单但真正落地时开发者要处理的不只是一个模型好不好用而是整条链路麦克风采集、音频编码、网络传输、流式接口、结果解析、异常恢复和延迟优化。任何一个环节出错最终表现都会是识别不准、响应卡顿或者直接连接失败。这篇文章会围绕这类实时语音转文本模型从技术原理讲到最小可运行示例再给出延迟优化、问题排查和生产落地建议。读者对象是正在做语音助手、实时字幕、会议转写、客服质检或语音交互类应用的开发者。阅读后你应该能独立设计一套实时语音转文本接入方案并在出现问题时知道从哪里开始排查。1. 实时语音转文本的技术主线从音频流到文本流1.1 离线转写与实时流式识别的本质区别离线语音转写通常把整段录音一次性提交给模型模型听完所有内容后再给出完整文本。它的优势是能利用整句甚至整段上下文做语言模型重打分所以很多离线转写服务的准确率表现得很好。但它的缺点也很明显必须等待用户说完再等待模型处理完整音频延迟通常在几秒甚至几十秒级别。实时流式识别则不同。它要求在用户说话的过程中持续接收音频分片每接收一部分就输出一部分识别结果。输出又分为两种部分结果partial result表示当前已经识别出来的临时文本会随着后续音频输入不断更新。最终结果final result表示一句话已经结束文本不会再被修改。这种设计是实时交互的基础。语音助手需要在用户还没说完时就理解意图实时字幕需要在说话人开口后很快显示文字会议纪要系统需要边开会不会让转写结果落后太多。Gemini 3.5 Transcribe 这类面向实时语音交互的模型强调的正是流式输入、增量输出和低延迟三个能力。离线转写和实时流式识别的差异可以用下面的表格快速对照对比维度离线转写实时流式识别输入方式完整音频文件或整段音频流短时间内持续到达的音频分片输出时机全部处理完成后输出边输入边输出可分阶段修正延迟特点秒级到分钟级毫秒级到数百毫秒上下文利用可使用整句、整段上下文通常依赖有限历史上下文和缓存典型场景录音转写、质检归档语音助手、实时字幕、会议转写失败影响可重试整段任务需要处理断流、乱序和连接中断实时识别并不等于模型必须放弃精度。它只是在“精度”和“延迟”之间增加了约束条件不能因为想等更多上下文就让用户一直等待。实现高精度实时识别通常依赖声学模型、语言模型、上下文缓存和流式解码策略的配合。作为接入方开发者并不需要深入训练细节但需要理解接口中 partial、final、timestamp 等字段的含义否则很容易把实时服务当成离线服务用导致高延迟。1.2 高精度在实时场景下意味着什么高精度并不是一个简单的“准确率”数字。在实时语音交互场景中用户对精度的感知来自多个方面文字是否准确特别是人名、地名、产品名、数字和英文缩写。标点符号和断句是否符合阅读习惯。识别结果是否随说话内容实时更新还是长时间没有反应。一句话结束后最终结果是否会把之前的部分结果修正过来。时间戳是否准确能否对齐到说话人的某个词语。对实时系统而言高精度还意味着上下文连贯。比如用户先说“我要订一张明天去北京的票”后半句说“早上八点的”模型必须知道“早上八点”是航班时间而不是重新理解一句独立的话。如果模型没有维护上下文状态就会出现后半句识别正确但语义不合逻辑的情况。这也解释了为什么接入实时语音转文本模型时不能简单地把每个音频分片单独送进模型。很多模型服务要求调用方保持同一个会话或者由服务端自己维护上下文窗口。开发者在设计接口时要保证音频分片是按顺序到达的并且在合适时机发送“断句”或“结束”信号让模型知道一句话已经说完。1.3 实时语音交互的完整调用链路在集成 Gemini 3.5 Transcribe 这样的模型前先画一遍完整的调用链路能帮助后续排查问题。一条最简单的实时语音转文本链路如下麦克风采集 - 音频编码/转码 - 网络传输 - 服务端接收缓冲 - 流式语音识别引擎 - 后处理 - 文本结果回传 - 客户端展示每个环节都有独立的延迟来源和故障模式。采集端的回声、底噪、采样率设置会影响输入质量网络传输中的抖动和丢包会影响音频连续性服务端缓冲策略决定了多久调用一次模型模型推理速度决定了结果返回速度后处理是否复杂又会影响最终输出延迟。很多项目只盯着“模型准确率”却忽略了整条管道的稳定性。实际开发中最常见的问题往往不是模型本身不够好而是音频格式不对、分片不合理、连接断开了没有重连、结果不会解析。把这条链路拆开看是解决实时语音转文本问题的最好起点。2. 接入前的环境准备音频参数和传输协议2.1 先确定音频格式16kHz 单声道 PCM 是语音识别的通用入口语音识别模型对输入音频格式通常有明确要求。虽然不同服务支持的范围不同但 16kHz 采样率、16-bit 位深、单声道、PCM 编码是一个覆盖面很广的通用配置。原因在于16kHz 已经覆盖了人类语音的绝大部分频率范围而 16-bit PCM 是各大平台和音频库都支持的基础格式转换开销最小。接入前需要先确认客户端采集到的音频是什么格式。比如浏览器端的 Web Audio API 可能输出 32-bit float 的 PCMiOS 和 Android 原生采集通常是 16-bit PCM 或 AACVoIP 系统里可能是 Opus。如果采集格式和模型接口要求不一致必须在客户端或服务端增加转码步骤。音频参数推荐值原因采样率16000 Hz覆盖语音主要频谱兼顾带宽和识别精度位深16-bit大多数 ASR 服务默认接受 16-bit PCM声道数1单声道多声道对语音识别没有帮助反而增加数据量编码PCM 裸流或 WAV便于实时分片不需要解码整个容器格式字节序little-endianPC 和移动端主流架构默认小端序需要注意的是不要直接拿 MP3 或 AAC 压缩流去做实时识别。压缩格式虽然节省带宽但引入解码延迟和编码损失而且很多流式接口要求固定编码格式的二进制分片。如果客户端只能采集到 Opus可以在服务端准备 Opus 解码转成 PCM 后再送进识别模型。注意接入前先用一段固定音频文件测试确认采样率、位深、声道和字节序都匹配再开始调麦克风。否则大概率会浪费时间排查“模型不识别”的问题。2.2 音频分片、静音检测和端点检测实时语音转文本不是把一整段音频一次性扔给模型而是把连续音频拆成一个个小分片。分片大小直接影响首字延迟。分片太小网络请求和调度开销变大分片太大用户说完第一句话后要等很久才能看到结果。常见的分片范围是 20ms 到 100ms。按 16kHz、16-bit、单声道计算100ms 的音频数据量是16000 采样/秒 * 2 字节/采样 * 0.1 秒 3200 字节也就是说每收到 3200 字节 PCM就基本可以打包发给服务端一次。但在发送之前通常还要做静音检测。如果不做任何检测环境噪音、键盘声、空调声都会被送入模型既增加请求量也可能让模型产生误识别。最简单的方法是计算音频 RMS 能量低于阈值就认为是静音。import audioop def is_speech(frame, sample_width2, threshold300): # frame 是 PCM 字节串sample_width 是每次采样字节数 rms audioop.rms(frame, sample_width) return rms threshold这里的 threshold 需要根据实际使用环境调整。安静办公室可能 100 就够了嘈杂商场可能需要 800 甚至更高。更可靠的方案是使用专门的 VAD语音活动检测库比如 WebRTC VAD 或 Silero VAD。它们通过神经网络或统计模型判断语音概率比单纯能量阈值更稳定。端点检测Endpointing则用于判断一句话什么时候说完。常见策略是检测到静音超过一定时间后生成一个断句信号。断句信号可以是 WebSocket 文本帧如{type: end_of_segment}服务端收到后触发 final 结果输出。如果缺少这一步模型会把连续两句话当成一句长句识别结果和语义都会受影响。2.3 WebSocket 和 HTTP 流式上传的选择实时语音转文本需要同时做两件事持续上行音频数据持续下行识别结果。HTTP 的传统请求-响应模型并不适合这种双向持续通信。虽然可以使用 HTTP Chunked 上传做流式请求但服务端想中途把识别结果推给客户端并不自然通常还需要客户端再轮询另一个接口。WebSocket 是更常见的选择。它能在一条长连接中同时传输二进制音频帧和文本控制帧天然适合实时语音场景。音频数据发成二进制帧控制命令如 reset、end_of_segment 发成文本帧识别结果通过文本帧返回结构清晰。对比维度WebSocketHTTP 流式上传连接方式长连接双向通信请求-响应适合单向上传音频上行二进制帧持续发送HTTP body 分段写入结果下行通过同一连接实时返回需要轮询或额外推送通道实时性较好一般实现难度中等中等适合场景实时交互、双向流对延迟不敏感的上传任务如果音视频服务已经使用了成熟的 RTC 协议也可以考虑在 RTC 数据通道上传输音频帧再额外使用 WebSocket 接收识别结果。但在大多数业务系统中WebSocket 已经足够而且生态成熟各种语言都有稳定库可选用。3. 最小可运行示例用 WebSocket 接收音频并返回识别文本这一节构造一个最小可运行示例用来演示实时语音转文本的完整数据流。示例使用 Python 的 websockets 库搭建服务端和客户端客户端通过 PyAudio 采集麦克风音频通过 WebSocket 发送 PCM 二进制数据服务端收到音频后调用一个占位转写函数再把结果返回给客户端。实际接入 Gemini 3.5 Transcribe 时只需要把占位的transcribe_audio_chunk函数替换成真实模型 SDK 或 HTTP API 调用即可。示例的目的不是模拟真实模型效果而是让开发者先跑通“采集 - 上行 - 识别 - 返回”的链路后面再按模型文档调整参数。3.1 项目结构与依赖示例只需要两个文件realtime-asr-demo/ ├── server.py └── client.py依赖建议使用 Python 3.10 及以上版本。安装依赖pip install websockets pyaudio如果不需要麦克风采集只想用音频文件测试客户端逻辑可以不安装 PyAudio改用wave读取 WAV 文件并模拟发送。但下面的示例会使用 PyAudio因为实时麦克风采集更能说明问题。3.2 服务端接收二进制音频并调用转写服务服务端主要做三件事接受 WebSocket 连接、接收二进制音频分片、调用转写函数并返回结果。import asyncio import json import websockets def transcribe_audio_chunk(pcm_bytes: bytes) - dict: # 实际项目中在这里调用 Gemini 3.5 Transcribe 或其它真实模型接口。 # 返回 dict 至少包含 text 和 is_final 字段。 return { text: 这是一条测试转写结果, is_final: True, } async def handler(websocket): buffer b print(client connected) try: async for message in websocket: if isinstance(message, bytes): buffer message # 100ms 音频数据约为 3200 字节 if len(buffer) 3200: result transcribe_audio_chunk(buffer) buffer b await websocket.send(json.dumps(result, ensure_asciiFalse)) else: # 文本帧作为控制信号 if message reset: buffer b await websocket.send(json.dumps({ text: , is_final: True, }, ensure_asciiFalse)) except websockets.ConnectionClosed: print(client disconnected) finally: print(handler done) async def main(): async with websockets.serve(handler, 127.0.0.1, 8765): await asyncio.Future() if __name__ __main__: asyncio.run(main())这里的transcribe_audio_chunk是占位实现返回固定文本。真实接入时它可能返回当前分片的部分结果一句话结束后的最终结果包含start_ms、end_ms的时间戳带置信度的候选文本列表。示例里每收到 3200 字节就把整个 buffer 清空这是一个简化行为。真实模型如果支持流式识别那么服务端应该把 PCM 分片持续发送给模型 API而不是按固定字节清空。如果模型只支持整段识别那么需要等待一句话结束信号才提交处理并保留前文上下文。后面排错章节会再讨论这个问题。3.3 客户端用麦克风采集音频并实时发送客户端使用 PyAudio 采集麦克风音频按 100ms 分包通过 WebSocket 发送给服务端然后等待识别结果。import asyncio import json import pyaudio import websockets FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 CHUNK 1600 # 100ms 音频 async def run(): p pyaudio.PyAudio() stream p.open( formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK, ) async with websockets.connect(ws://127.0.0.1:8765) as ws: print(start speaking...) try: while True: data stream.read(CHUNK, exception_on_overflowFalse) await ws.send(data) try: reply await asyncio.wait_for(ws.recv(), timeout1.0) result json.loads(reply) if result.get(is_final): print(result.get(text)) except asyncio.TimeoutError: pass except KeyboardInterrupt: print(stop) finally: stream.stop_stream() stream.close() p.terminate() asyncio.run(run())代码中有几个关键点CHUNK 1600表示每帧采样 1600 个采样点长度为1600 / 16000 * 1000 100ms。stream.read是阻塞式读取默认攒够 1600 个采样点才返回。wait_for设置 1 秒超时避免客户端一直在等待服务端返回。客户端没有做静音检测所以会持续发送环境噪音。生产环境应在发送前加入 VAD 判断。如果没有麦克风设备可以先用 WAV 文件模拟。读取文件时按同样的帧大小读取 PCM 数据并循环发送这样也能完整测试服务端链路。3.4 运行验证与预期结果先启动服务端python server.py再启动客户端python client.py正常运行时终端会出现start speaking...客户端采集到音频后发送给服务端服务端返回占位文本。客户端每次收到is_final为true的结果就会打印一行文本。预期输出类似start speaking... 这是一条测试转写结果如果没有任何输出按下面的顺序检查服务端是否打印了client connected。客户端是否打印了异常。麦克风权限是否开启设备编号是否正确。音频数据量是否达到 3200 字节服务端是否收到二进制帧。注意示例中transcribe_audio_chunk返回的是固定文本所以即使没有接入真实模型链路仍然能跑通。这正好用来验证音频采集、网络传输和消息解析是否正确避免一上来就引入模型 API 的变量。4. 延迟优化与精度调优不能只把音频丢给模型4.1 延迟分解与优化手段实时语音转文本的延迟不是单一数字而是多个环节累计的结果。可以把延迟拆成四个部分采集延迟麦克风从声音发生到返回 PCM 数据的时间。传输延迟音频分片从客户端到服务端的网络时间。推理延迟模型处理分片并返回结果的时间。回传延迟识别结果从服务端返回到客户端的时间。延迟环节常见瓶颈优化手段采集音频缓冲区过大减小 frames_per_buffer但避免太小时频繁唤醒传输分片过大、网络抖动使用 20ms-100ms 分片开启 TCP_NODELAY推理模型过大、并发不足使用流式模型开启并发池限制最大连接数回传结果解析、后处理过重先回传原始文本后处理异步或精简只看总延迟容易掩盖问题。一个常见现象是模型 API 本身只返回 200ms但客户端到服务端分片积累导致整体延迟达到 2 秒。要定位问题必须在每一段记录日志至少要记录每个分片的发送序号和时间服务端收到分片的时间模型返回结果的时间客户端收到结果的时间。有了这些数据才能判断延迟到底堆积在哪一环。不要凭感觉认为“是模型慢”有时候是网络丢包重传有时候是服务端队列积压。4.2 使用 VAD 和上下文控制降低无效请求实时语音交互中用户不可能一直说话。如果不管有没有声音都把音频发送给模型不仅浪费带宽还会增加费用和计算量。更好的方案是在客户端或服务端加入 VAD只有检测到语音时才真正把音频分片交给模型。使用 WebRTC VAD 的示意代码如下import webrtcvad vad webrtcvad.Vad(2) # 聚合等级 0-33 最激进 def process_frame(frame, sample_rate16000): if vad.is_speech(frame, sample_rate): return True return Falsewebrtcvad.Vad要求每个 frame 的长度固定为 10ms、20ms 或 30ms。如果客户端原本使用的是 100ms 分片需要先把 100ms 拆成多个 10ms 或 20ms 小帧分别判断再决定整个分片是否包含语音。这个细节很容易被忽略。上下文控制是另一个容易被忽视的点。实时模型通常会把当前会话的前文作为上下文。当用户结束一个话题开始说新话题时如果上下文不清空新句子的识别会受到旧文本影响。解决方案是通过 WebSocket 发送reset控制帧让服务端清空模型上下文。示例代码中已经包含了reset的处理逻辑真实项目里可以在客户端检测到长时间静音或用户点击“停止”时发送这个帧。部分模型还支持热词表speech adaptation phrase。把业务相关的产品名、员工姓名、地名单词加入热词表可以显著提升专有名词识别率。但热词表不是越大越好加太多反而可能干扰通用词识别。通常模型服务会限制热词数量建议只加入当前业务场景最核心的 50 到 200 个词。4.3 输出后处理标点、时间戳、数字格式化模型直接输出的文本可能不包含标点也可能把数字写成中文读法。这需要在业务层做后处理。一个通用的后处理管道包含三部分标点恢复和断句。数字、时间、货币、单位的格式化。按时间戳对齐到原文或字幕位置。一个简化版后处理类如下class TranscriptPostProcessor: def __init__(self): self.rules [ (二十五, 25), (三点五, 3.5), ] def process(self, raw_text: str) - str: text raw_text for old, new in self.rules: text text.replace(old, new) return text processor TranscriptPostProcessor() print(processor.process(今天温度二十五度)) # 今天温度25度实际项目里数字格式化需要考虑上下文不能简单替换。比如“二十五号”应该转成“25 号”而“二十五度”应该转成“25℃”。更稳妥的方案是使用规则库或让大模型做后处理但大模型会引入额外延迟需要评估是否值得。时间戳对齐也很重要。如果模型返回start_ms和end_ms客户端可以把文本按时间轴显示用于实时字幕或会议纪要。需要关注的是模型返回的时间戳是分片级别还是词级别。词级别时间戳更精确但数据量更大解析成本更高。5. 常见问题排查从现象到根因5.1 识别结果为空或乱码现象客户端正常发送音频服务端也不报错但识别结果为空或者返回的文字全是乱码。可能原因音频采样率不是模型要求的 16kHz。实际发送的是 8-bit PCM但服务端按 16-bit 解析。声道数不是单声道双声道数据交叉排列导致解码错位。字节序不匹配服务端按 big-endian 读取 little-endian 数据。网络中间层把二进制帧截断或修改。检查方式在服务端打印收到的 buffer 长度和原始字节前几位确认数据量是否符合预期。用audioop.rms计算音频能量确认缓冲区里确实有声音。用 WAV 文件分别保存发送前后的音频在本地播放对比。问题现象常见原因处理方案结果全空采样率不一致统一为 16000 Hz文字乱码字节序或位深不对统一为 16-bit little-endian声音很闷采样率低于 16kHz提高采样率或做重采样有结果但错误率高双声道未合并提取单声道后再发送5.2 实时返回延迟越来越大现象刚开始识别还正常运行几十秒后结果返回越来越慢最后可能卡死。可能原因客户端发送音频的速度超过服务端处理速度导致服务端 buffer 不断累积。服务端是串行处理一个模型请求阻塞了后续所有请求。模型 API 带宽有限频繁调用触发流控。网络中间设备限制了 WebSocket 的持续传输速率。检查方式在客户端统计每 100ms 发送一个分片的实际时间间隔。在服务端记录 buffer 长度和每次调用transcribe_audio_chunk的耗时。观察如果暂停发送音频延迟是否逐渐回落。解决方案客户端使用背压控制当发送队列积压时主动丢帧或降低采集频率。服务端把模型调用放入异步任务队列避免阻塞 WebSocket 事件循环。为模型调用设置超时时间比如 2 秒超时就直接返回错误不要无限等待。对长时间没有声音的连接主动断开释放资源。5.3 长句被截断或重复识别现象用户说了一整句话但客户端收到了两条结果或者一句话被拆成两半第二半识别错误。可能原因静音检测阈值过低用户说话过程中的停顿被误判成断句。服务端每满 3200 字节就清空 buffer导致跨分片上下文丢失。客户端发送reset的时机不对把正常语句中断了。模型不支持流式上下文但调用方没有维护历史文本。排查路径关闭 VAD确认在无断句信号情况下长句识别是否正常。在发送端打印每句话的开头时间和最终结果段的时间戳对比。检查服务端清空 buffer 的逻辑是否用固定字节阈值代替了真正的断句信号。查询模型文档确认流式接口是否要求按会话连续发送而不是每段独立识别。预防建议不要按固定字节数清空上下文。使用 VAD 和显式end_of_segment控制。如果模型支持流式接口应该持续发送音频分片由模型自行决定何时输出 final。如果不支持流式接口需要自行维护重叠窗口比如每 1 秒一个窗口相邻窗口重叠 400ms再合并结果。5.4 并发连接导致服务不稳定现象一个客户端连接时正常第二个客户端接入后服务端出现异常或者两个客户端都开始卡顿。可能原因服务端没有限制最大连接数资源被耗尽。每个连接都占用一个线程或长时间运行的协程没做隔离。模型 API 的并发配额有限多个连接同时调用触发限流。某个连接异常退出后服务端没有及时清理资源。解决方式使用asyncio.Semaphore限制最大连接数。给每个连接设置空闲超时和最大音频时长。在模型调用层使用连接池和并发限制避免单个客户端拖垮全部。每个连接的错误都要独立捕获避免异常影响其他连接。MAX_CONNECTIONS 5 semaphore asyncio.Semaphore(MAX_CONNECTIONS) async def safe_handler(websocket): async with semaphore: await handler(websocket) # 启动服务时注册 safe_handler 而不是 handler生产环境还需要加鉴权。WebSocket 连接建立时要求客户端提供 token否则直接关闭。否则任何人都可以连上来消耗模型配额造成安全问题和成本风险。6. 生产环境落地从 Demo 到可用服务的差距6.1 学习环境与生产环境的差异Demo 能跑通不代表生产环境可用。从本地 WebSocket 服务到线上语音服务需要补齐很多工程能力。差异项学习环境生产环境鉴权无必须校验 API Token 或用户身份日志简单 print结构化日志记录连接 ID、延迟、错误码监控无连接数、分片速率、模型耗时、错误率重试无断线退避重连重试幂等超时很少设置必须设置连接超时、空闲超时、模型调用超时安全本地连接需要 TLS、连接鉴权、请求频率限制容量单连接测试按并发峰值扩容限制最大连接数回滚不涉及需要备用模型或离线转写降级方案一个常见误区是上线前只测试了单连接少量音频没有压测多连接和长时间运行。语音连接往往持续几分钟甚至几小时内存泄漏和连接泄漏在短时测试中不会暴露。生产环境上线前至少要做 1 小时以上的稳定性测试同时观察内存、CPU、文件句柄和 WebSocket 连接数。6.2 上线前检查清单基于实时语音转文本项目的常见问题可以整理一份上线前检查清单[ ] 音频格式统一为 16kHz、16-bit、单声道、PCM客户端和服务端都能确认格式一致。[ ] 客户端接入 VAD静音期间不上行音频数据。[ ] 识别结果区分 partial 和 final客户端至少订阅 final 结果用于最终展示。[ ] 服务端支持reset控制帧可以在用户切换话题或结束会话时清空上下文。[ ] WebSocket 连接包含心跳机制超时未收到音频或心跳就主动断开。[ ] 客户端实现断线重连重连后自动恢复音频发送并在必要时重置模型上下文。[ ] 服务端限制最大连接数给每个连接设置音频时长上限。[ ] 模型调用设置超时和重试重试只适用于非幂等敏感结果避免重复提交。[ ] 记录结构化日志连接 ID、接收字节数、识别结果长度、模型耗时、错误信息。[ ] 后处理管道已明确数字格式化、标点、时间戳都在业务层处理。[ ] 准备降级方案模型服务不可用时切换备用模型或提示用户转离线转写。清单里的每一项都来自实际故障案例。比如“断线重连”这条很多项目在 Demo 阶段会觉得麻烦但线上网络不可能永远稳定。没有重连机制用户说话说到一半连接断开整个会话就废了。6.3 从语音转文本到实时语音交互转写只是语音交互的第一步。得到文本流之后还可以继续做意图理解、对话管理再通过 TTS 把回复说出来形成完整的语音交互闭环。这时Gemini 3.5 Transcribe 这类模型输出的时间戳和分段信息就变得更有价值。它不只是把语音变成文字还能让下游系统知道用户在什么时间说了什么从而串联起动作触发、上下文理解、回复生成等逻辑。更进一步的方向包括多语言混合识别比如中文里夹英文单词。说话人分离区分会议中谁说了哪句话。自定义热词把业务词汇加入识别词表。情感和语气识别用于客服质检和舆情分析。结合大模型做语义后处理自动生成会议纪要摘要。在真实项目中最值得记住的判断是实时语音转文本系统是一个管道不要只盯着模型的准确率。先把音频流、WebSocket 连接、分片策略、断句信号、日志监控这些基础能力做好再谈提升精度。否则模型再强也会因为输入质量差、上下文混乱、连接不稳定而用不起来。接入 Gemini 3.5 Transcribe 或任何同类实时语音转文本模型时建议从最小示例开始逐步增加 VAD、断句、热词、后处理、重连和监控。每增加一层都要验证延迟和错误率变化而不是直接一次把所有功能堆上去。这样出了问题才能明确知道是哪一层引入的。对于新手开发者最重要的练习是先跑通本文提供的 WebSocket 链路再替换真实模型接口紧接着做一次 10 分钟连续说话测试观察延迟和内存变化。做完这个测试你对实时语音转文本的理解会比只看文档深刻得多。 实时语音转文本实战：从流式识别到WebSocket接入与优化
实时语音交互应用对语音转文本ASR的要求通常比离线录音转写更难满足。以 Gemini 3.5 Transcribe 为代表的面向实时语音交互的高精度语音转文本模型核心目标是在用户说话过程中同步返回文本并将延迟控制在对话可接受的范围内。这个概念听起来简单但真正落地时开发者要处理的不只是一个模型好不好用而是整条链路麦克风采集、音频编码、网络传输、流式接口、结果解析、异常恢复和延迟优化。任何一个环节出错最终表现都会是识别不准、响应卡顿或者直接连接失败。这篇文章会围绕这类实时语音转文本模型从技术原理讲到最小可运行示例再给出延迟优化、问题排查和生产落地建议。读者对象是正在做语音助手、实时字幕、会议转写、客服质检或语音交互类应用的开发者。阅读后你应该能独立设计一套实时语音转文本接入方案并在出现问题时知道从哪里开始排查。1. 实时语音转文本的技术主线从音频流到文本流1.1 离线转写与实时流式识别的本质区别离线语音转写通常把整段录音一次性提交给模型模型听完所有内容后再给出完整文本。它的优势是能利用整句甚至整段上下文做语言模型重打分所以很多离线转写服务的准确率表现得很好。但它的缺点也很明显必须等待用户说完再等待模型处理完整音频延迟通常在几秒甚至几十秒级别。实时流式识别则不同。它要求在用户说话的过程中持续接收音频分片每接收一部分就输出一部分识别结果。输出又分为两种部分结果partial result表示当前已经识别出来的临时文本会随着后续音频输入不断更新。最终结果final result表示一句话已经结束文本不会再被修改。这种设计是实时交互的基础。语音助手需要在用户还没说完时就理解意图实时字幕需要在说话人开口后很快显示文字会议纪要系统需要边开会不会让转写结果落后太多。Gemini 3.5 Transcribe 这类面向实时语音交互的模型强调的正是流式输入、增量输出和低延迟三个能力。离线转写和实时流式识别的差异可以用下面的表格快速对照对比维度离线转写实时流式识别输入方式完整音频文件或整段音频流短时间内持续到达的音频分片输出时机全部处理完成后输出边输入边输出可分阶段修正延迟特点秒级到分钟级毫秒级到数百毫秒上下文利用可使用整句、整段上下文通常依赖有限历史上下文和缓存典型场景录音转写、质检归档语音助手、实时字幕、会议转写失败影响可重试整段任务需要处理断流、乱序和连接中断实时识别并不等于模型必须放弃精度。它只是在“精度”和“延迟”之间增加了约束条件不能因为想等更多上下文就让用户一直等待。实现高精度实时识别通常依赖声学模型、语言模型、上下文缓存和流式解码策略的配合。作为接入方开发者并不需要深入训练细节但需要理解接口中 partial、final、timestamp 等字段的含义否则很容易把实时服务当成离线服务用导致高延迟。1.2 高精度在实时场景下意味着什么高精度并不是一个简单的“准确率”数字。在实时语音交互场景中用户对精度的感知来自多个方面文字是否准确特别是人名、地名、产品名、数字和英文缩写。标点符号和断句是否符合阅读习惯。识别结果是否随说话内容实时更新还是长时间没有反应。一句话结束后最终结果是否会把之前的部分结果修正过来。时间戳是否准确能否对齐到说话人的某个词语。对实时系统而言高精度还意味着上下文连贯。比如用户先说“我要订一张明天去北京的票”后半句说“早上八点的”模型必须知道“早上八点”是航班时间而不是重新理解一句独立的话。如果模型没有维护上下文状态就会出现后半句识别正确但语义不合逻辑的情况。这也解释了为什么接入实时语音转文本模型时不能简单地把每个音频分片单独送进模型。很多模型服务要求调用方保持同一个会话或者由服务端自己维护上下文窗口。开发者在设计接口时要保证音频分片是按顺序到达的并且在合适时机发送“断句”或“结束”信号让模型知道一句话已经说完。1.3 实时语音交互的完整调用链路在集成 Gemini 3.5 Transcribe 这样的模型前先画一遍完整的调用链路能帮助后续排查问题。一条最简单的实时语音转文本链路如下麦克风采集 - 音频编码/转码 - 网络传输 - 服务端接收缓冲 - 流式语音识别引擎 - 后处理 - 文本结果回传 - 客户端展示每个环节都有独立的延迟来源和故障模式。采集端的回声、底噪、采样率设置会影响输入质量网络传输中的抖动和丢包会影响音频连续性服务端缓冲策略决定了多久调用一次模型模型推理速度决定了结果返回速度后处理是否复杂又会影响最终输出延迟。很多项目只盯着“模型准确率”却忽略了整条管道的稳定性。实际开发中最常见的问题往往不是模型本身不够好而是音频格式不对、分片不合理、连接断开了没有重连、结果不会解析。把这条链路拆开看是解决实时语音转文本问题的最好起点。2. 接入前的环境准备音频参数和传输协议2.1 先确定音频格式16kHz 单声道 PCM 是语音识别的通用入口语音识别模型对输入音频格式通常有明确要求。虽然不同服务支持的范围不同但 16kHz 采样率、16-bit 位深、单声道、PCM 编码是一个覆盖面很广的通用配置。原因在于16kHz 已经覆盖了人类语音的绝大部分频率范围而 16-bit PCM 是各大平台和音频库都支持的基础格式转换开销最小。接入前需要先确认客户端采集到的音频是什么格式。比如浏览器端的 Web Audio API 可能输出 32-bit float 的 PCMiOS 和 Android 原生采集通常是 16-bit PCM 或 AACVoIP 系统里可能是 Opus。如果采集格式和模型接口要求不一致必须在客户端或服务端增加转码步骤。音频参数推荐值原因采样率16000 Hz覆盖语音主要频谱兼顾带宽和识别精度位深16-bit大多数 ASR 服务默认接受 16-bit PCM声道数1单声道多声道对语音识别没有帮助反而增加数据量编码PCM 裸流或 WAV便于实时分片不需要解码整个容器格式字节序little-endianPC 和移动端主流架构默认小端序需要注意的是不要直接拿 MP3 或 AAC 压缩流去做实时识别。压缩格式虽然节省带宽但引入解码延迟和编码损失而且很多流式接口要求固定编码格式的二进制分片。如果客户端只能采集到 Opus可以在服务端准备 Opus 解码转成 PCM 后再送进识别模型。注意接入前先用一段固定音频文件测试确认采样率、位深、声道和字节序都匹配再开始调麦克风。否则大概率会浪费时间排查“模型不识别”的问题。2.2 音频分片、静音检测和端点检测实时语音转文本不是把一整段音频一次性扔给模型而是把连续音频拆成一个个小分片。分片大小直接影响首字延迟。分片太小网络请求和调度开销变大分片太大用户说完第一句话后要等很久才能看到结果。常见的分片范围是 20ms 到 100ms。按 16kHz、16-bit、单声道计算100ms 的音频数据量是16000 采样/秒 * 2 字节/采样 * 0.1 秒 3200 字节也就是说每收到 3200 字节 PCM就基本可以打包发给服务端一次。但在发送之前通常还要做静音检测。如果不做任何检测环境噪音、键盘声、空调声都会被送入模型既增加请求量也可能让模型产生误识别。最简单的方法是计算音频 RMS 能量低于阈值就认为是静音。import audioop def is_speech(frame, sample_width2, threshold300): # frame 是 PCM 字节串sample_width 是每次采样字节数 rms audioop.rms(frame, sample_width) return rms threshold这里的 threshold 需要根据实际使用环境调整。安静办公室可能 100 就够了嘈杂商场可能需要 800 甚至更高。更可靠的方案是使用专门的 VAD语音活动检测库比如 WebRTC VAD 或 Silero VAD。它们通过神经网络或统计模型判断语音概率比单纯能量阈值更稳定。端点检测Endpointing则用于判断一句话什么时候说完。常见策略是检测到静音超过一定时间后生成一个断句信号。断句信号可以是 WebSocket 文本帧如{type: end_of_segment}服务端收到后触发 final 结果输出。如果缺少这一步模型会把连续两句话当成一句长句识别结果和语义都会受影响。2.3 WebSocket 和 HTTP 流式上传的选择实时语音转文本需要同时做两件事持续上行音频数据持续下行识别结果。HTTP 的传统请求-响应模型并不适合这种双向持续通信。虽然可以使用 HTTP Chunked 上传做流式请求但服务端想中途把识别结果推给客户端并不自然通常还需要客户端再轮询另一个接口。WebSocket 是更常见的选择。它能在一条长连接中同时传输二进制音频帧和文本控制帧天然适合实时语音场景。音频数据发成二进制帧控制命令如 reset、end_of_segment 发成文本帧识别结果通过文本帧返回结构清晰。对比维度WebSocketHTTP 流式上传连接方式长连接双向通信请求-响应适合单向上传音频上行二进制帧持续发送HTTP body 分段写入结果下行通过同一连接实时返回需要轮询或额外推送通道实时性较好一般实现难度中等中等适合场景实时交互、双向流对延迟不敏感的上传任务如果音视频服务已经使用了成熟的 RTC 协议也可以考虑在 RTC 数据通道上传输音频帧再额外使用 WebSocket 接收识别结果。但在大多数业务系统中WebSocket 已经足够而且生态成熟各种语言都有稳定库可选用。3. 最小可运行示例用 WebSocket 接收音频并返回识别文本这一节构造一个最小可运行示例用来演示实时语音转文本的完整数据流。示例使用 Python 的 websockets 库搭建服务端和客户端客户端通过 PyAudio 采集麦克风音频通过 WebSocket 发送 PCM 二进制数据服务端收到音频后调用一个占位转写函数再把结果返回给客户端。实际接入 Gemini 3.5 Transcribe 时只需要把占位的transcribe_audio_chunk函数替换成真实模型 SDK 或 HTTP API 调用即可。示例的目的不是模拟真实模型效果而是让开发者先跑通“采集 - 上行 - 识别 - 返回”的链路后面再按模型文档调整参数。3.1 项目结构与依赖示例只需要两个文件realtime-asr-demo/ ├── server.py └── client.py依赖建议使用 Python 3.10 及以上版本。安装依赖pip install websockets pyaudio如果不需要麦克风采集只想用音频文件测试客户端逻辑可以不安装 PyAudio改用wave读取 WAV 文件并模拟发送。但下面的示例会使用 PyAudio因为实时麦克风采集更能说明问题。3.2 服务端接收二进制音频并调用转写服务服务端主要做三件事接受 WebSocket 连接、接收二进制音频分片、调用转写函数并返回结果。import asyncio import json import websockets def transcribe_audio_chunk(pcm_bytes: bytes) - dict: # 实际项目中在这里调用 Gemini 3.5 Transcribe 或其它真实模型接口。 # 返回 dict 至少包含 text 和 is_final 字段。 return { text: 这是一条测试转写结果, is_final: True, } async def handler(websocket): buffer b print(client connected) try: async for message in websocket: if isinstance(message, bytes): buffer message # 100ms 音频数据约为 3200 字节 if len(buffer) 3200: result transcribe_audio_chunk(buffer) buffer b await websocket.send(json.dumps(result, ensure_asciiFalse)) else: # 文本帧作为控制信号 if message reset: buffer b await websocket.send(json.dumps({ text: , is_final: True, }, ensure_asciiFalse)) except websockets.ConnectionClosed: print(client disconnected) finally: print(handler done) async def main(): async with websockets.serve(handler, 127.0.0.1, 8765): await asyncio.Future() if __name__ __main__: asyncio.run(main())这里的transcribe_audio_chunk是占位实现返回固定文本。真实接入时它可能返回当前分片的部分结果一句话结束后的最终结果包含start_ms、end_ms的时间戳带置信度的候选文本列表。示例里每收到 3200 字节就把整个 buffer 清空这是一个简化行为。真实模型如果支持流式识别那么服务端应该把 PCM 分片持续发送给模型 API而不是按固定字节清空。如果模型只支持整段识别那么需要等待一句话结束信号才提交处理并保留前文上下文。后面排错章节会再讨论这个问题。3.3 客户端用麦克风采集音频并实时发送客户端使用 PyAudio 采集麦克风音频按 100ms 分包通过 WebSocket 发送给服务端然后等待识别结果。import asyncio import json import pyaudio import websockets FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 CHUNK 1600 # 100ms 音频 async def run(): p pyaudio.PyAudio() stream p.open( formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK, ) async with websockets.connect(ws://127.0.0.1:8765) as ws: print(start speaking...) try: while True: data stream.read(CHUNK, exception_on_overflowFalse) await ws.send(data) try: reply await asyncio.wait_for(ws.recv(), timeout1.0) result json.loads(reply) if result.get(is_final): print(result.get(text)) except asyncio.TimeoutError: pass except KeyboardInterrupt: print(stop) finally: stream.stop_stream() stream.close() p.terminate() asyncio.run(run())代码中有几个关键点CHUNK 1600表示每帧采样 1600 个采样点长度为1600 / 16000 * 1000 100ms。stream.read是阻塞式读取默认攒够 1600 个采样点才返回。wait_for设置 1 秒超时避免客户端一直在等待服务端返回。客户端没有做静音检测所以会持续发送环境噪音。生产环境应在发送前加入 VAD 判断。如果没有麦克风设备可以先用 WAV 文件模拟。读取文件时按同样的帧大小读取 PCM 数据并循环发送这样也能完整测试服务端链路。3.4 运行验证与预期结果先启动服务端python server.py再启动客户端python client.py正常运行时终端会出现start speaking...客户端采集到音频后发送给服务端服务端返回占位文本。客户端每次收到is_final为true的结果就会打印一行文本。预期输出类似start speaking... 这是一条测试转写结果如果没有任何输出按下面的顺序检查服务端是否打印了client connected。客户端是否打印了异常。麦克风权限是否开启设备编号是否正确。音频数据量是否达到 3200 字节服务端是否收到二进制帧。注意示例中transcribe_audio_chunk返回的是固定文本所以即使没有接入真实模型链路仍然能跑通。这正好用来验证音频采集、网络传输和消息解析是否正确避免一上来就引入模型 API 的变量。4. 延迟优化与精度调优不能只把音频丢给模型4.1 延迟分解与优化手段实时语音转文本的延迟不是单一数字而是多个环节累计的结果。可以把延迟拆成四个部分采集延迟麦克风从声音发生到返回 PCM 数据的时间。传输延迟音频分片从客户端到服务端的网络时间。推理延迟模型处理分片并返回结果的时间。回传延迟识别结果从服务端返回到客户端的时间。延迟环节常见瓶颈优化手段采集音频缓冲区过大减小 frames_per_buffer但避免太小时频繁唤醒传输分片过大、网络抖动使用 20ms-100ms 分片开启 TCP_NODELAY推理模型过大、并发不足使用流式模型开启并发池限制最大连接数回传结果解析、后处理过重先回传原始文本后处理异步或精简只看总延迟容易掩盖问题。一个常见现象是模型 API 本身只返回 200ms但客户端到服务端分片积累导致整体延迟达到 2 秒。要定位问题必须在每一段记录日志至少要记录每个分片的发送序号和时间服务端收到分片的时间模型返回结果的时间客户端收到结果的时间。有了这些数据才能判断延迟到底堆积在哪一环。不要凭感觉认为“是模型慢”有时候是网络丢包重传有时候是服务端队列积压。4.2 使用 VAD 和上下文控制降低无效请求实时语音交互中用户不可能一直说话。如果不管有没有声音都把音频发送给模型不仅浪费带宽还会增加费用和计算量。更好的方案是在客户端或服务端加入 VAD只有检测到语音时才真正把音频分片交给模型。使用 WebRTC VAD 的示意代码如下import webrtcvad vad webrtcvad.Vad(2) # 聚合等级 0-33 最激进 def process_frame(frame, sample_rate16000): if vad.is_speech(frame, sample_rate): return True return Falsewebrtcvad.Vad要求每个 frame 的长度固定为 10ms、20ms 或 30ms。如果客户端原本使用的是 100ms 分片需要先把 100ms 拆成多个 10ms 或 20ms 小帧分别判断再决定整个分片是否包含语音。这个细节很容易被忽略。上下文控制是另一个容易被忽视的点。实时模型通常会把当前会话的前文作为上下文。当用户结束一个话题开始说新话题时如果上下文不清空新句子的识别会受到旧文本影响。解决方案是通过 WebSocket 发送reset控制帧让服务端清空模型上下文。示例代码中已经包含了reset的处理逻辑真实项目里可以在客户端检测到长时间静音或用户点击“停止”时发送这个帧。部分模型还支持热词表speech adaptation phrase。把业务相关的产品名、员工姓名、地名单词加入热词表可以显著提升专有名词识别率。但热词表不是越大越好加太多反而可能干扰通用词识别。通常模型服务会限制热词数量建议只加入当前业务场景最核心的 50 到 200 个词。4.3 输出后处理标点、时间戳、数字格式化模型直接输出的文本可能不包含标点也可能把数字写成中文读法。这需要在业务层做后处理。一个通用的后处理管道包含三部分标点恢复和断句。数字、时间、货币、单位的格式化。按时间戳对齐到原文或字幕位置。一个简化版后处理类如下class TranscriptPostProcessor: def __init__(self): self.rules [ (二十五, 25), (三点五, 3.5), ] def process(self, raw_text: str) - str: text raw_text for old, new in self.rules: text text.replace(old, new) return text processor TranscriptPostProcessor() print(processor.process(今天温度二十五度)) # 今天温度25度实际项目里数字格式化需要考虑上下文不能简单替换。比如“二十五号”应该转成“25 号”而“二十五度”应该转成“25℃”。更稳妥的方案是使用规则库或让大模型做后处理但大模型会引入额外延迟需要评估是否值得。时间戳对齐也很重要。如果模型返回start_ms和end_ms客户端可以把文本按时间轴显示用于实时字幕或会议纪要。需要关注的是模型返回的时间戳是分片级别还是词级别。词级别时间戳更精确但数据量更大解析成本更高。5. 常见问题排查从现象到根因5.1 识别结果为空或乱码现象客户端正常发送音频服务端也不报错但识别结果为空或者返回的文字全是乱码。可能原因音频采样率不是模型要求的 16kHz。实际发送的是 8-bit PCM但服务端按 16-bit 解析。声道数不是单声道双声道数据交叉排列导致解码错位。字节序不匹配服务端按 big-endian 读取 little-endian 数据。网络中间层把二进制帧截断或修改。检查方式在服务端打印收到的 buffer 长度和原始字节前几位确认数据量是否符合预期。用audioop.rms计算音频能量确认缓冲区里确实有声音。用 WAV 文件分别保存发送前后的音频在本地播放对比。问题现象常见原因处理方案结果全空采样率不一致统一为 16000 Hz文字乱码字节序或位深不对统一为 16-bit little-endian声音很闷采样率低于 16kHz提高采样率或做重采样有结果但错误率高双声道未合并提取单声道后再发送5.2 实时返回延迟越来越大现象刚开始识别还正常运行几十秒后结果返回越来越慢最后可能卡死。可能原因客户端发送音频的速度超过服务端处理速度导致服务端 buffer 不断累积。服务端是串行处理一个模型请求阻塞了后续所有请求。模型 API 带宽有限频繁调用触发流控。网络中间设备限制了 WebSocket 的持续传输速率。检查方式在客户端统计每 100ms 发送一个分片的实际时间间隔。在服务端记录 buffer 长度和每次调用transcribe_audio_chunk的耗时。观察如果暂停发送音频延迟是否逐渐回落。解决方案客户端使用背压控制当发送队列积压时主动丢帧或降低采集频率。服务端把模型调用放入异步任务队列避免阻塞 WebSocket 事件循环。为模型调用设置超时时间比如 2 秒超时就直接返回错误不要无限等待。对长时间没有声音的连接主动断开释放资源。5.3 长句被截断或重复识别现象用户说了一整句话但客户端收到了两条结果或者一句话被拆成两半第二半识别错误。可能原因静音检测阈值过低用户说话过程中的停顿被误判成断句。服务端每满 3200 字节就清空 buffer导致跨分片上下文丢失。客户端发送reset的时机不对把正常语句中断了。模型不支持流式上下文但调用方没有维护历史文本。排查路径关闭 VAD确认在无断句信号情况下长句识别是否正常。在发送端打印每句话的开头时间和最终结果段的时间戳对比。检查服务端清空 buffer 的逻辑是否用固定字节阈值代替了真正的断句信号。查询模型文档确认流式接口是否要求按会话连续发送而不是每段独立识别。预防建议不要按固定字节数清空上下文。使用 VAD 和显式end_of_segment控制。如果模型支持流式接口应该持续发送音频分片由模型自行决定何时输出 final。如果不支持流式接口需要自行维护重叠窗口比如每 1 秒一个窗口相邻窗口重叠 400ms再合并结果。5.4 并发连接导致服务不稳定现象一个客户端连接时正常第二个客户端接入后服务端出现异常或者两个客户端都开始卡顿。可能原因服务端没有限制最大连接数资源被耗尽。每个连接都占用一个线程或长时间运行的协程没做隔离。模型 API 的并发配额有限多个连接同时调用触发限流。某个连接异常退出后服务端没有及时清理资源。解决方式使用asyncio.Semaphore限制最大连接数。给每个连接设置空闲超时和最大音频时长。在模型调用层使用连接池和并发限制避免单个客户端拖垮全部。每个连接的错误都要独立捕获避免异常影响其他连接。MAX_CONNECTIONS 5 semaphore asyncio.Semaphore(MAX_CONNECTIONS) async def safe_handler(websocket): async with semaphore: await handler(websocket) # 启动服务时注册 safe_handler 而不是 handler生产环境还需要加鉴权。WebSocket 连接建立时要求客户端提供 token否则直接关闭。否则任何人都可以连上来消耗模型配额造成安全问题和成本风险。6. 生产环境落地从 Demo 到可用服务的差距6.1 学习环境与生产环境的差异Demo 能跑通不代表生产环境可用。从本地 WebSocket 服务到线上语音服务需要补齐很多工程能力。差异项学习环境生产环境鉴权无必须校验 API Token 或用户身份日志简单 print结构化日志记录连接 ID、延迟、错误码监控无连接数、分片速率、模型耗时、错误率重试无断线退避重连重试幂等超时很少设置必须设置连接超时、空闲超时、模型调用超时安全本地连接需要 TLS、连接鉴权、请求频率限制容量单连接测试按并发峰值扩容限制最大连接数回滚不涉及需要备用模型或离线转写降级方案一个常见误区是上线前只测试了单连接少量音频没有压测多连接和长时间运行。语音连接往往持续几分钟甚至几小时内存泄漏和连接泄漏在短时测试中不会暴露。生产环境上线前至少要做 1 小时以上的稳定性测试同时观察内存、CPU、文件句柄和 WebSocket 连接数。6.2 上线前检查清单基于实时语音转文本项目的常见问题可以整理一份上线前检查清单[ ] 音频格式统一为 16kHz、16-bit、单声道、PCM客户端和服务端都能确认格式一致。[ ] 客户端接入 VAD静音期间不上行音频数据。[ ] 识别结果区分 partial 和 final客户端至少订阅 final 结果用于最终展示。[ ] 服务端支持reset控制帧可以在用户切换话题或结束会话时清空上下文。[ ] WebSocket 连接包含心跳机制超时未收到音频或心跳就主动断开。[ ] 客户端实现断线重连重连后自动恢复音频发送并在必要时重置模型上下文。[ ] 服务端限制最大连接数给每个连接设置音频时长上限。[ ] 模型调用设置超时和重试重试只适用于非幂等敏感结果避免重复提交。[ ] 记录结构化日志连接 ID、接收字节数、识别结果长度、模型耗时、错误信息。[ ] 后处理管道已明确数字格式化、标点、时间戳都在业务层处理。[ ] 准备降级方案模型服务不可用时切换备用模型或提示用户转离线转写。清单里的每一项都来自实际故障案例。比如“断线重连”这条很多项目在 Demo 阶段会觉得麻烦但线上网络不可能永远稳定。没有重连机制用户说话说到一半连接断开整个会话就废了。6.3 从语音转文本到实时语音交互转写只是语音交互的第一步。得到文本流之后还可以继续做意图理解、对话管理再通过 TTS 把回复说出来形成完整的语音交互闭环。这时Gemini 3.5 Transcribe 这类模型输出的时间戳和分段信息就变得更有价值。它不只是把语音变成文字还能让下游系统知道用户在什么时间说了什么从而串联起动作触发、上下文理解、回复生成等逻辑。更进一步的方向包括多语言混合识别比如中文里夹英文单词。说话人分离区分会议中谁说了哪句话。自定义热词把业务词汇加入识别词表。情感和语气识别用于客服质检和舆情分析。结合大模型做语义后处理自动生成会议纪要摘要。在真实项目中最值得记住的判断是实时语音转文本系统是一个管道不要只盯着模型的准确率。先把音频流、WebSocket 连接、分片策略、断句信号、日志监控这些基础能力做好再谈提升精度。否则模型再强也会因为输入质量差、上下文混乱、连接不稳定而用不起来。接入 Gemini 3.5 Transcribe 或任何同类实时语音转文本模型时建议从最小示例开始逐步增加 VAD、断句、热词、后处理、重连和监控。每增加一层都要验证延迟和错误率变化而不是直接一次把所有功能堆上去。这样出了问题才能明确知道是哪一层引入的。对于新手开发者最重要的练习是先跑通本文提供的 WebSocket 链路再替换真实模型接口紧接着做一次 10 分钟连续说话测试观察延迟和内存变化。做完这个测试你对实时语音转文本的理解会比只看文档深刻得多。