语音转文本模型落地实时语音交互：从原理到工程实践

在做实时语音交互类项目时，最让人头疼的问题通常不是“录音”，而是“录音明明很清楚，转成文字之后却乱七八糟”。模型选型、音频格式、流式传输、延迟控制、断句策略……任何一个环节出了问题，整个交互体验都会崩掉。近期 Gemini 3.5 Transcribe 这类面向实时语音交互的高精度语音转文本模型陆续发布，又一次把“语音转文本”推到了技术热点的中心。

本文不打算复述发布会，也不去堆参数表，而是围绕“如何把语音转文本模型落地到实时语音交互系统”这条主线，从核心原理、系统架构、环境准备、代码实现、常见排错到工程最佳实践，完整梳理一遍。无论你是刚开始接触智能语音的新手，还是正在做语音助手、会议纪要、客服质检、实时字幕的后端工程师，这篇教程都能给你一套可以直接参考的落地思路。

1. 语音转文本模型：为什么值得关注

1.1 什么是语音转文本

语音转文本（Automatic Speech Recognition，ASR）指的是把人类说话的音频信号转换成对应文字的技术。它并不是一个新概念，早年的电话语音导航、语音输入法都是它的应用，但过去很长一段时间里，ASR 受限于模型能力和算力，识别准确率在噪音环境、口音变化、专业词汇面前并不理想。

近几年，随着深度学习和大规模预训练模型的发展，语音转文本模型的能力有了明显跃升。Gemini 3.5 Transcribe 这类新一代模型，在“高精度”和“实时性”两个方向上同时做了优化，使得语音转文本不再只是离线录音后的“慢速处理”，而是可以嵌入到实时交互链路的“在线能力”。

项目中常见的语音转文本场景包括：

• 语音助手：用户说话后，系统需要快速把指令转成文本，再交给 NLP 模块理解。
• 实时字幕：会议、直播、视频剪辑中，边说话边生成字幕。
• 客服质检：将坐席与客户的通话转写成文本，再去做关键词分析。
• 会议纪要：多人发言场景下，自动分离说话人并生成纪要文本。
• 语音输入：输入法、编辑器中的语音转文字。
• 语音搜索：直接把语音查询转成文本后走搜索链路。

1.2 实时语音交互与离线转写有什么不同

传统的语音转文本通常是“先录音，后转写”。用户说完一整句话，系统拿到完整音频文件，再调用模型输出结果。这种方式适合离线场景，但对实时交互来说并不友好，因为用户说完话到看到结果之间，存在明显的等待时间。

实时语音交互的典型体验是：用户说话的同时，文字在屏幕上逐步生成，或者系统在用户停顿的瞬间就能给出反馈。这要求语音转文本模型具备“流式处理”能力，也就是边接收音频边输出中间结果，而不是等所有音频都到达后才开始识别。

Gemini 3.5 Transcribe 发布时强调的“面向实时语音交互”，本质上就是要在以下三个方面取得平衡：

• 低延迟：从用户发声到文字出现，延迟需要控制在几百毫秒到一两秒内。
• 高精度：不能因为追求速度而大幅牺牲识别准确率。
• 稳定性：在断续语音、背景噪声、多人插话等复杂环境下仍能正常工作。

理解了这个区别，再看后续的系统设计和代码实现，就会清晰很多。

2. 语音转文本的核心原理

2.1 从模拟声音到数字化音频

声音在物理上是一种连续的振动波，计算机无法直接处理这种模拟信号，必须通过采样把它变成离散的数字信号。采样率（Sample Rate）决定了每秒采集多少次声音样本，常见的语音采样率有 8000Hz、16000Hz、44100Hz、48000Hz。

对于语音识别来说，16000Hz 是一个很常用的标准。因为人说话的语音能量主要集中在 300Hz 到 3400Hz 之间，16kHz 采样率足以保留语音识别所需要的大部分频率信息，同时数据量比 48kHz 小很多，有利于降低传输和计算成本。

音频的另一个重要属性是位深（Bit Depth），它决定每个采样点的数值精度。常见的位深是 16bit，取值范围为 -32768 到 32767。语音识别场景中，16bit 单声道（Mono）16kHz 采样率几乎属于“标准配置”，很多 ASR 服务甚至会直接要求传入这种格式的音频。

# 使用 ffmpeg 查看音频基本信息 ffprobe sample.wav

输出中可以看到采样率、声道数、位深等关键信息。如果模型要求 16kHz 单声道，而本地音频是 48kHz 双声道，就需要先做重采样和声道合并。

# 将任意音频转换为 16kHz 单声道 WAV ffmpeg -i input.mp3 -ar 16000 -ac 1 -y sample.wav

2.2 VAD：语音活动检测

一段音频里并不是所有时间都有人在说话。在实时语音交互中，如果模型对整段静默也进行识别，会浪费算力，也可能产生大量空结果。VAD（Voice Activity Detection）的作用就是判断当前音频片段中是否包含有效语音。

在实际系统中，VAD 通常有两种实现方式：

• 传统信号处理方式：通过对短时能量、过零率、频谱特征设置阈值来判断是否有人说话。
• 模型方式：使用专门的 VAD 模型，输出每一帧的语音概率。

VAD 在实时语音交互中的作用非常关键，它是“一句话什么时候开始、什么时候结束”的基础。只有判断出语音端点，系统才能决定何时把音频分片发送给识别引擎，以及何时结束本次识别并返回最终结果。

下面是一个基于短时能量的简单 VAD 示例，它把音频按块计算 RMS（均方根）能量，能量低于阈值的块被视为静音。

# file: simple_vad.py import numpy as np import wave def read_wav(path): with wave.open(path, "rb") as wf: sample_rate = wf.getframerate() channels = wf.getnchannels() sampwidth = wf.getsampwidth() frames = wf.readframes(wf.getnframes()) if sampwidth == 2: audio = np.frombuffer(frames, dtype=np.int16) else: raise ValueError("当前示例仅支持 16bit 音频") # 双声道取单声道 if channels == 2: audio = audio.reshape(-1, 2).mean(axis=1).astype(np.int16) return sample_rate, audio def rms_energy(data): if len(data) == 0: return 0.0 return float(np.sqrt(np.mean(data.astype(np.float32) ** 2))) sample_rate, audio = read_wav("sample.wav") block_size = int(sample_rate * 0.03) # 每块 30ms threshold = 500.0 for i in range(0, len(audio), block_size): block = audio[i:i + block_size] energy = rms_energy(block) if energy > threshold: print(f"第 {i // block_size:04d} 块: 有语音, RMS={energy:.1f}") else: print(f"第 {i // block_size:04d} 块: 静音, RMS={energy:.1f}")

2.3 声学模型、语言模型与解码

一个完整的语音转文本系统，可以粗略拆成几个部分：

• 声学特征提取：把音频信号转成模型可用的特征序列，常见的有 Mel 频谱、MFCC 等。
• 声学模型：学习“音频特征”到“音素或字符”之间的映射。
• 语言模型：根据上下文，判断哪些词更可能被说出来。
• 解码器：综合声学模型和语言模型的概率，找到最优的文字序列。

在现代端到端语音识别模型中，声学模型、语言模型和解码器往往被融合在一个大型神经网络中，用户直接输入音频，模型输出文本。这种端到端方式省去了很多中间步骤，也让识别效果更容易优化。

Gemini 3.5 Transcribe 这类模型之所以能做到“高精度”，很大程度上就是因为它利用了大规模数据训练，对噪声、口音、语速变化和上下文语义有更强的建模能力。这也是为什么它比传统语音识别方案更适合复杂的实时交互场景。

2.4 流式识别与非流式识别

非流式识别在线下很好理解：把整段音频送入模型，一次返回完整结果。流式识别则要在音频还不完整的情况下，持续输出“临时结果”，并在音频结束后输出“最终结果”。

流式识别常用两种策略：

• 固定间隔发送：每隔 100ms 或 200ms 发送一小块音频，模型根据已收到的音频增量返回结果。
• 端点驱动发送：先用 VAD 检测语音开始和结束，只在有效语音期间发送音频。

在实际项目中，这两种策略经常结合使用。VAD 负责判断说话状态，实时音频流则按照固定大小分块发送给模型。为了便于理解，后面的代码演示中我会用“预录制的 PCM 文件模拟实时音频分片发送”的方式来讲解 WebSocket 流式调用。

3. 实时语音交互的整体架构

3.1 一条典型的实时语音转写链路

从用户说话到语音转文本模型返回结果，中间通常要经过以下环节：

1. 麦克风采集音频。
2. 对音频做预处理：重采样、降噪、静音检测。
3. 将音频分片，通过 WebSocket 或 HTTP 流式接口发送给 ASR 服务。
4. 服务端模型边接收音频边识别，返回临时结果或最终结果。
5. 客户端把结果显示在界面上，或交给下游业务逻辑。

这里非常关键的一点是：语音转文本模型虽然负责“听懂声音”，但它并不能单独决定整个系统的体验。如果音频采集端采样率不对，或者分片大小不合理，再好的模型也发挥不出效果。

3.2 时延从哪里来

实时语音交互最关注的指标是“端到端时延”，也就是从用户开口到系统看到文字之间的时间差。这个时延通常由几部分叠加而成：

• 采集时延：麦克风把声音变成数字信号需要时间。
• 预处理时延：重采样、降噪、VAD 判断需要时间。
• 传输时延：音频数据从客户端传到服务端需要时间。
• 排队时延：服务端并发高时，请求可能需要排队。
• 模型推理时延：模型生成文本需要时间。
• 网络返回时延：结果从服务端回到客户端需要时间。

在实际项目中，我们不可能把每段时延都降到零，但可以通过合理设计控制总时延。比如客户端使用 WebSocket 长连接，避免反复创建连接；分片大小设置成 100ms 到 200ms，既不会太碎导致网络开销过大，也不会太大导致首字返回太慢。

3.3 云端 API 与本地部署如何选

Gemini 3.5 Transcribe 这类模型如果在云端以 API 的形式提供，使用起来很方便，客户端只需要接入服务即可。但在实时语音交互场景中，是否选择云端 API 要考虑几个因素：

• 延迟要求：如果业务要求极低延迟，云端网络往返可能成为瓶颈。
• 数据隐私：医疗、金融等场景下，语音数据不能传到外部服务，需要私有化部署。
• 成本：实时流式识别持续产生费用，需要评估成本。
• 并发能力：语音交互往往是长连接，服务端需要支撑大量并发流。

如果选择本地部署开源语音模型，则需要自己有 GPU 资源和模型服务化能力。如果选择 Gemini 3.5 Transcribe 这类商业模型 API，则要重点研究官方提供的流式接口、鉴权方式、音频格式要求和配额限制。

无论选择哪种方案，工程的接入模式都大同小异：先准备音频，再调用识别服务，最后处理返回的文本结果。

4. 环境准备与版本说明

4.1 运行环境

本文的示例代码以 Python 为主，可以在 Windows、Linux、macOS 上运行。建议使用 Python 3.9 及以上版本。

示例中用到的主要依赖：

• requests：用于发送 HTTP 请求，调用离线语音转文本接口。
• websockets：用于建立 WebSocket 连接，演示实时流式语音转文本。
• sounddevice：用于读取麦克风音频。
• numpy：用于音频数据处理。
• ffmpeg：用于音频格式转换和参数查看，属于外部命令行工具。

安装 Python 依赖：

pip install requests websockets sounddevice numpy

ffmpeg 需要单独安装，具体安装方式根据操作系统不同而不同。安装完成后，可以用下面的命令验证：

ffmpeg -version

4.2 音频文件准备

为了后文演示，我们需要准备一个测试音频。可以使用麦克风录制，也可以用 ffmpeg 从其他音视频中截取。

# 使用系统麦克风通过 ffmpeg 录制 5 秒音频 ffmpeg -f avfoundation -i ":0" -t 5 -ar 16000 -ac 1 -y mic.wav

注意，上面命令中的avfoundation是 macOS 的采集方式；Windows 下可以用dshow，Linux 下可以用alsa。如果录制不方便，也可以直接下载一些开源语音测试音频。

这里需要特别说明：不同操作系统、不同版本的 ffmpeg 采集参数差异较大。本文重点演示的是“拿到音频之后”的处理流程，录制命令需要根据你的实际环境调整。

4.3 关于模型 API 的说明

本文中出现的 REST 地址、WebSocket 地址、鉴权 Header、返回字段均为演示用途，用于说明语音转文本服务的通用接入模式。如果你要接入 Gemini 3.5 Transcribe，或者接入其他任意 ASR 服务，请以官方文档提供的接口地址、请求格式和鉴权方式为准。

不同语音转文本服务的差异主要集中在：

• 音频编码格式：有的接受 WAV，有的接受 FLAC，有的接受裸 PCM。
• 采样率要求：常见的是 16kHz，但也可能要求 8kHz 或 48kHz。
• 语言参数：中英文混合场景可能需要单独设置语言。
• 返回结果：有的返回 JSON，有的返回纯文本，有的支持词级时间戳。

因此，务必先阅读官方接入文档，再修改示例代码。

5. 完整实战案例：接入语音转文本服务

5.1 创建项目结构

先创建一个项目目录，并按下面的结构组织文件：

asr-demo/ ├── transcribe_file.py # 离线文件转写示例 ├── stream_websocket.py # WebSocket 流式转写示例 ├── mic_record.py # 麦克风采集音频示例 ├── sample.wav # 测试音频 └── sample.pcm # 测试音频的 PCM 格式

项目结构不需要太复杂，重点是区分“离线文件转写”和“实时流式转写”两种调用方式。

5.2 检查音频参数

无论使用哪种调用方式，第一步都应该确认音频参数是否满足服务要求。使用 ffprobe 可以快速查看：

ffprobe sample.wav

重点看以下字段：

• sample rate：采样率，常见要求是 16000 Hz。
• channels：声道数，通常要求单声道。
• bit depth：位深，通常要求 16 bit。

如果不满足要求，用 ffmpeg 转换。

# 先查看源文件信息 ffprobe input.mp3 # 统一转换为 16kHz、16bit、单声道 WAV ffmpeg -i input.mp3 -ar 16000 -ac 1 -sample_fmt s16 -y sample.wav

5.3 离线文件语音转文本

很多场景并不要求实时，比如离线录音转写、批量音频质检，用简单的 HTTP 接口就能完成。

下面是一个通用的 HTTP 文件转写示例，使用requests发送音频文件并接收识别结果。

# file: transcribe_file.py import requests # 演示用接口地址，实际使用时替换为目标 ASR 服务的真实地址 ASR_URL = "https://your-asr-endpoint.example.com/v1/transcribe" API_KEY = "your-api-key" AUDIO_FILE = "sample.wav" headers = { "Authorization": f"Bearer {API_KEY}", } # 以 multipart/form-data 方式上传音频 with open(AUDIO_FILE, "rb") as f: files = {"file": (AUDIO_FILE, f, "audio/wav")} data = {"language": "zh", "enable_punctuation": "true"} resp = requests.post(ASR_URL, headers=headers, files=files, data=data, timeout=30) if resp.status_code == 200: result = resp.json() print("识别文本:", result.get("text")) print("置信度:", result.get("confidence")) else: print("请求失败:", resp.status_code, resp.text)

这段代码的核心逻辑并不复杂：

• 把音频文件作为 multipart 表单字段上传。
• 通过language参数指定语言。
• 通过enable_punctuation请求输出带标点的文本。
• 解析 JSON 响应，提取结果。

实际接入时，最需要调整的是接口路径和参数名。有的服务要求把音频进行 Base64 编码放在 JSON body 中，有的服务要求使用audio字段而不是file字段，这些都要以官方文档为准。

5.4 WebSocket 实时流式语音转文本

实时语音交互更常用的是 WebSocket 接口。客户端与服务端建立长连接后，一边发送音频分片，一边接收临时识别结果。

下面这个示例使用预录制的 PCM 文件模拟实时音频流，目的是演示流式调用的完整流程。

# file: stream_websocket.py import asyncio import json import websockets # 演示用 WebSocket 地址，实际使用替换为目标 ASR 服务的真实地址 WS_URL = "wss://your-asr-endpoint.example.com/v1/stream" API_KEY = "your-api-key" SAMPLE_RATE = 16000 BYTES_PER_SAMPLE = 2 # 16bit CHUNK_MS = 200 # 每个分片 200ms CHUNK_BYTES = SAMPLE_RATE * BYTES_PER_SAMPLE * CHUNK_MS // 1000 async def process_result(ws): """循环接收服务端返回的识别结果""" async for message in ws: result = json.loads(message) result_type = result.get("type") if result_type == "partial": print("临时结果:", result.get("text")) elif result_type == "final": print("最终结果:", result.get("text")) break async def main(): headers = { "Authorization": f"Bearer {API_KEY}", } async with websockets.connect(WS_URL, additional_headers=headers) as ws: # 1. 发送开始帧，携带音频参数 start_message = { "type": "start", "format": "pcm", "sample_rate": SAMPLE_RATE, "channels": 1, "language": "zh", } await ws.send(json.dumps(start_message)) # 2. 按固定分片大小发送音频 with open("sample.pcm", "rb") as f: while True: chunk = f.read(CHUNK_BYTES) if not chunk: break await ws.send(chunk) # 模拟实时音频的发送节奏 await asyncio.sleep(CHUNK_MS / 1000) # 3. 发送结束帧 end_message = {"type": "end"} await ws.send(json.dumps(end_message)) # 4. 等待最终结果 await process_result(ws) asyncio.run(main())

这段代码需要重点解释几个设计细节：

首先，start帧是很多流式语音转文本服务的通用约定，用来在开始音频传输前通知服务端“我即将发送什么格式的音频”。采样率、声道数、位深必须提前告诉服务端，否则真实音频和参数不匹配，识别结果就会出现大量乱码。

其次，分片大小CHUNK_MS = 200是一个折中值。200ms 的音频数据量不大，网络开销可以接受；同时不会像 10ms 分片那样产生大量小请求。实际项目中，100ms 到 300ms 都是常见区间，需要根据服务端要求和网络质量调整。

最后，await asyncio.sleep(CHUNK_MS / 1000)是为了模拟真实录音的节奏。真实场景中，麦克风每采集到 200ms 音频就会发送一次，不会一次性把整个文件发完。

5.5 麦克风实时采集并保存音频

前面两个示例都是处理已有的音频文件。在真实实时语音交互中，还需要从麦克风采集音频。下面代码使用sounddevice录制 5 秒音频，并同时保存为 PCM 和 WAV 格式。

# file: mic_record.py import sounddevice as sd import numpy as np import wave SAMPLE_RATE = 16000 CHANNELS = 1 DURATION = 5 print("开始录音，请说话...") audio = sd.rec( int(DURATION * SAMPLE_RATE), samplerate=SAMPLE_RATE, channels=CHANNELS, dtype="int16", ) sd.wait() print("录音结束") # 保存为裸 PCM 文件，适合流式接口直接读取 audio.tofile("mic.pcm") # 保存为 WAV 文件，带文件头，方便播放与检查 with wave.open("mic.wav", "wb") as wf: wf.setnchannels(CHANNELS) wf.setsampwidth(2) # 16bit = 2 字节 wf.setframerate(SAMPLE_RATE) wf.writeframes(audio.tobytes()) print("已保存 mic.pcm 和 mic.wav")

实际接入流式转写时，思路是把sd.rec换成sd.InputStream，在回调函数中直接把音频帧写入 WebSocket。但这样做会把音频采集、网络传输、异步调度耦合在一起，代码复杂度会上升不少。本文先用录制保存的方式把链路打通，理解整体流程后再逐步换成真正的实时流式采集。

如果希望看到实时效果，可以先运行mic_record.py录制一段语音，然后用 ffmpeg 转成 sample.pcm，再调用stream_websocket.py的流程来发送。

# 将录制好的 WAV 转为 16kHz 单声道 PCM ffmpeg -i mic.wav -f s16le -ar 16000 -ac 1 -y sample.pcm

5.6 运行与验证

先运行麦克风录制：

python mic_record.py

录制完成后，检查文件：

ffprobe mic.wav file mic.pcm

再运行离线转写：

python transcribe_file.py

如果接口地址和鉴权都正确，会输出识别文本和置信度。如果返回 401，说明鉴权有问题；如果返回 400，通常是音频格式或请求参数不符合接口要求。

流式转写示例需要先把音频转成 PCM：

python stream_websocket.py

这里要注意，stream_websocket.py会按照 200ms 的节奏发送音频。如果文件较长，运行时间也会相应变长，这是正常的，因为它模拟的是“实时”播放音频。如果只想快速验证接口，可以把CHUNK_MS调大，或者去掉asyncio.sleep，但这会破坏实时模拟的意义。

6. 常见问题与排查思路

语音转文本在落地过程中，最容易踩的坑集中在音频格式、接口协议、实时性和识别效果四个方面。

以下是几个实际项目中最常遇到的问题和解决细节。

6.1 有录音但服务端识别为空

如果确认录音文件有声音，但服务端返回空文本，优先检查两个地方：

第一，音频是否真的被发送到了服务端。很多 SDK 在静音检测阶段会把内容过滤掉，导致服务端收到的全是静音数据。可以先关闭 VAD 看看是否恢复正常。

第二，采样率是否匹配。假设服务端要求 16kHz，实际发送的是 48kHz 音频，但没有在参数中声明正确采样率，服务端按照错误参数解码，就会得到非常奇怪的结果。

6.2 WebSocket 发送 PCM 文件时需要注意什么

千万不要直接发送 WAV 文件。WAV 文件开头有 44 字节的文件头，包含采样率、声道数等信息。如果直接发送 WAV，服务端会把这 44 字节也当作音频数据解码，识别结果从开头就开始混乱。正确做法是只发送原始音频数据，也就是去掉文件头的 PCM 数据。

上面的示例中使用ffmpeg -f s16le输出 PCM 文件，s16le表示“有符号 16bit 小端字节序”，这正是大多数 ASR 服务要求的 PCM 格式。

6.3 实时场景下“结果出得太慢”怎么办

首字时延是实时语音交互最敏感的指标之一。如果发现结果出得太慢，可以从几个方向优化：

• 减小分片大小，从 200ms 降到 100ms，让音频更早到达服务端。
• 检查是否开启了“中间结果”功能。部分服务端默认只在音频结束后返回最终结果，需要显式开启临时结果回调。
• 使用就近的服务接入点，降低网络往返时延。
• 如果服务支持本地部署，把模型部署在离客户端更近的机房。

7. 最佳实践与工程建议

7.1 统一音频处理管线

在团队协作中，最怕的是“每个客户端上传的音频格式都不一样”。Android 可能采集 16kHz PCM，iOS 可能采集 48kHz AAC，浏览器可能采集 Opus。如果这些音频直接发给服务端，服务端就需要分别处理，非常容易出错。

建议的做法是：在客户端统一做一次音频格式转换，或者在服务端统一设置音频预处理组件，把输入音频全部转成 16kHz、16bit、单声道 PCM，再进行后续识别。这样，语音转文本模型只需要面对一种稳定的输入格式，识别效果和稳定性都会更好。

7.2 把服务调用封装成独立模块

不要把语音转文本的调用逻辑散落在业务代码中。建议封装成一个独立的 ASR 客户端模块，对外提供两个方法：

• transcribe_file(audio_path)：离线文件转写。
• start_stream()：返回一个可发送音频数据的流式对象。

这样做的优点很明显：后续切换模型服务商、升级接口版本、修改音频参数，只需要改动 ASR 客户端模块，业务层完全无感。

# file: asr_client.py class ASRClient: def __init__(self, api_key, endpoint): self.api_key = api_key self.endpoint = endpoint def transcribe_file(self, audio_path): # 离线文件转写实现 pass def start_stream(self, sample_rate=16000, channels=1): # 返回一个流式会话对象 pass

在团队合作中，这样设计还能方便编写单元测试和 Mock 数据，即使没有真实 ASR 服务，也可以先用假数据把业务链路跑通。

7.3 重视超时、重试与降级

语音转文本服务属于外部依赖，随时可能因为网络波动、服务端过载而不可用。生产环境必须有超时控制和重试机制，但也要注意重试不能造成雪崩。

一个相对稳妥的策略是：

• 短超时：单次请求设置合理的超时时间，比如离线转写 30 秒，流式连接 60 秒无消息则断开。
• 有限重试：对于幂等的转写请求，可以重试 1 到 2 次。
• 熔断降级：当错误率连续超过阈值时，直接暂停调用语音转文本服务，返回提示信息，而不是让请求全部超时。

7.4 数据安全与合规

语音数据往往包含用户的个人信息、商业机密，甚至医疗健康信息。在接入 Gemini 3.5 Transcribe 或任何云端语音转文本服务时，都要仔细阅读服务方的数据处理条款。

工程上至少要做到：

• 最小权限：只申请必要的接口权限，API Key 不要直接写死在客户端代码中。
• 数据脱敏：如果可能，在发送前对音频中的人名、身份证号、银行卡号等敏感信息做脱敏处理。
• 加密传输：使用 HTTPS 或 WSS，不使用明文 HTTP/WS。
• 合规授权：收集用户语音前，在产品和协议层面获得用户明确授权。
• 日志脱敏：识别结果文本中可能包含敏感信息，写日志时不要完整打印，或对敏感字段做替换。

7.5 使用热词与自定义词汇提升精度

很多语音转文本服务支持“热词”功能，也就是在识别时倾向于输出你指定的一组词。比如一家医疗公司希望准确识别药物名称，一家游戏公司希望识别游戏术语，都可以通过热词表实现。

热词表的维护策略：

• 提取历史识别错误中出现的高频词。
• 将产品中的专业名词整理成词表。
• 定期分析识别结果，持续补充和清理热词。

热词不是越多越好。热词过多、权重过高，可能会导致模型过度偏爱热词，把普通词语错误地识别成热词。需要结合实际效果反复调优。

7.6 监控和日志

实时语音交互系统的稳定性，很大程度上依赖完善的监控体系。建议至少关注以下指标：

• 平均识别时延：从音频发送到最终结果返回的时间。
• 首字时延：用户说话到第一个临时结果出现的时间。
• 连接成功率：WebSocket 连接建立的成功率。
• 错误码分布：401、403、400、408、429 等错误码的占比。
• 并发连接数：当前活跃的流式识别连接数量。
• 识别结果长度分布：用于发现异常的空结果或超长结果。

日志方面，不要只记录“成功”和“失败”，要记录请求 ID、音频时长、采样率、分片数、时延、返回文本片段等上下文信息，方便排查问题。

8. 总结与学习路线

通过本文，我们完成了从语音转文本原理到实时语音交互系统落地的完整梳理。

你可以看到，像 Gemini 3.5 Transcribe 这样的高精度语音转文本模型，虽然把“识别”的难度降低了很多，但真正决定一个实时语音交互系统好不好的，往往是音频格式处理、分片策略、WebSocket 长连接管理、VAD 端点检测、异常处理这些工程细节。

如果接下来想继续深入，我建议按照下面的路线实践：

1. 先跑通文中的离线文件转写和流式转写示例，理解两种调用方式的差别。
2. 把mic_record.py改成真正的实时麦克风流式采集，通过 WebSocket 发送音频并返回结果。
3. 接入具体的 ASR 服务，阅读官方文档，把示例代码中的 URL、鉴权字段、返回字段替换成真实配置。
4. 研究 VAD 端点检测，实现“用户停顿后自动结束一句话”的交互体验。
5. 设计并发和降级方案，让语音识别服务在真实生产环境下稳定运行。
6. 如果有条件，再接触训练和微调，尝试在垂直领域提升模型精度。

在整个过程中，优先关注识别时延、音频格式规范和数据安全三个风险点。任何一个地方出了问题，都可能让用户觉得“这个语音助手很笨”。

如果你想把这篇文章收藏备用，建议重点记住两个文件：transcribe_file.py和stream_websocket.py。前者是离线场景的万能模板，后者是实时场景的核心骨架。把它们变成你自己的工程模板，后续接任何语音转文本服务都会快很多。