Wiki Notes

Appearance

03. 实时语音、转写与语音助手架构 ​

版本：v1.1

最后更新：2026-07-09

适用对象：要做语音转写、实时问答、语音助手、电话机器人、同声翻译、会议陪练的产品、研发、平台和交付同学

很多团队一提到“语音 AI”，脑子里只有一个问题：

  • 模型能不能听懂、能不能说出来。

但按 2026-07-09 可访问的 OpenAI Audio and speech、Speech to text、Text to speech、Realtime and audio、Realtime transcription、Realtime translation、Voice agents、Using realtime models、Managing costs for Realtime，以及 Google Gemini Live API capabilities 官方资料来看，真正决定系统成败的往往不是“会不会说”，而是：

  • 你做的到底是单次音频处理、持续转写、实时对话，还是带工具和状态的语音助手。

1. 先把四类语音系统分开 ​

1.1 单次音频处理 ​

典型任务：

  • 上传录音转写
  • 会议录音摘要
  • 音频质检
  • 播报合成

这类系统通常更像请求式任务：

  • 输入边界清晰
  • 可以异步
  • 更适合重试和回放

1.2 实时转写 ​

典型任务：

  • 会议字幕
  • 电话实时转写
  • 直播字幕

重点更偏：

  • 持续流
  • 时延预算
  • 断句和 partial 结果

1.3 实时语音对话 ​

典型任务：

  • 陪练
  • 语音问答
  • 同声翻译式互动

重点更偏：

  • 打断
  • turn 切换
  • 语气和自然度
  • 会话状态

1.4 语音助手或电话代理 ​

典型任务：

  • 语音客服
  • 电话机器人
  • 可调工具的语音 Agent

这类系统已经不只是语音问题，而是：

  • 语音 + 状态机 + 工具调用 + 安全审批 + 运营监控

2. 为什么 request-based audio 和 realtime 不能混着想 ​

OpenAI 当前把 Audio and speech 和 Realtime and audio 拆开写，本身就说明这是两套不同心智。

2.1 request-based 更像批任务 ​

更适合：

  • 上传音频再转写
  • 文本转语音播报
  • 后台批量生成

它的优点是：

  • 边界清楚
  • 好重试
  • 成本更稳定

2.2 realtime 更像持续会话 ​

更适合：

  • 即时问答
  • 连续对话
  • 互动翻译
  • 需要打断和恢复的语音场景

它的难点是：

  • 连接持续存在
  • 中途事件很多
  • 用户会打断
  • 模型、语音和工具会一起推进

2.3 最容易犯的错 ​

很多团队把“会议转写”和“语音助手”放进一套链路，结果通常会遇到：

  • 延迟目标互相冲突
  • 状态管理混乱
  • 成本难控
  • 体验不自然

3. 语音系统先选哪一条路线 ​

3.1 只需要拿到文本 ​

如果你的目标是：

  • 会议纪要
  • 字幕
  • 录音检索
  • 质检抽查

优先更像：

  • 转写系统

这时关键是：

  • 准确率
  • 术语
  • 说话人区分
  • 批量吞吐

3.2 需要低延迟自然交互 ​

如果你的目标是：

  • 语音陪练
  • 客服问答
  • 陪伴式对话

优先更像：

  • 实时语音对话系统

这时关键是：

  • turn detection
  • interruption
  • 首响应延迟
  • 连续状态

3.3 需要边说边调用工具 ​

如果你的目标是：

  • 语音助手下单
  • 电话机器人查单
  • 语音操作后台系统

优先更像：

  • 语音 Agent

这时关键不再只是语音，而是：

  • 工具权限
  • 会话状态
  • 高风险动作审批
  • 失败补偿

4. Realtime 架构里最重要的五个分界 ​

4.1 连接方式 ​

OpenAI Realtime and audio 与 Voice agents 官方资料本身就强调：

  • 客户端实时体验
  • 会话状态
  • 凭证和连接方式

是语音系统的核心部分。

更实用的原则通常是：

  • 终端实时互动优先考虑真正面向实时媒体的连接方式。
  • 服务端中转或后台编排优先考虑更易控制的服务端连接。

4.2 凭证边界 ​

实时语音不是普通 API key 直接下发给前端的场景。

更稳的做法通常是：

  • 后端签发短期会话凭证
  • 客户端只拿临时权限
  • 高风险工具仍走服务端审批

4.2.1 sideband 连接最好单独保留在服务端 ​

OpenAI 当前 Voice agents 文档明确把 sideband 当成实时语音系统的一层正式能力来讲，这个点非常关键。

因为很多语音助手真正敏感的并不是：

  • 用户音频本身

而是：

  • 工具调用
  • 业务策略
  • 审批逻辑
  • 内部指令

更稳的做法通常是：

  • 客户端负责实时媒体
  • 服务端保留 sideband 连接，负责工具、策略和观察

这样你可以把：

  • prompt 更新
  • tool choice
  • 审批请求
  • 会话监控

都留在服务端，而不是暴露给前端实时链路。

4.3 turn detection / VAD ​

语音系统最影响体验的往往不是模型答案，而是：

  • 什么时候该认为用户说完了
  • 什么时候允许模型开口
  • 用户打断后是否能顺滑停住

OpenAI 当前把 Voice activity detection 单列出来，本身就说明 VAD 不是一个小参数，而是交互边界。

4.3.1 VAD 最好当成产品参数，而不是模型参数 ​

OpenAI 当前 Voice activity detection 文档里，像 idle_timeout_ms、prefix_padding_ms、silence_duration_ms 这类配置都已经是正式调参对象。它说明：

  • VAD 不是开或关
  • 它更像一组会直接改变用户体验的交互参数

举例来说：

  • idle_timeout_ms 更影响系统什么时候主动接话或追问
  • prefix_padding_ms 会影响截取到的起始语音是否完整
  • silence_duration_ms 会影响系统对“用户说完了”的判断

这意味着更稳的团队做法通常不是：

  • 工程里写死一组 VAD 配置

而是：

  • 按场景维护 VAD preset

例如：

  • 电话客服一套
  • 陪练一套
  • 会议旁听一套
  • 翻译助手一套

4.4 interruption 与恢复 ​

用户一打断，系统要回答几个问题：

  1. 上一段语音是否立即停。
  2. 当前工具调用是否继续。
  3. 是否保留上一轮上下文意图。
  4. 如何把没说完的话收住。

这一步处理不好，再强的模型也会显得“不会聊天”。

4.4.1 session 生命周期最好显式建模，而不是把实时会话当无限连接 ​

OpenAI 当前 Realtime and audio / Voice agents 文档都已经把 session 当成明确对象来设计，当前正式说明里包括：

  • session 可以更新
  • 实时会话有明确生命周期
  • 当前常见 session 时长心智是 60 分钟量级，而不是永远不断线

这意味着实时语音系统更稳的做法通常是：

  • 会话建立
  • 会话更新
  • 会话轮替
  • 会话收尾

都显式落在状态机里。

否则一到下面这些场景就会乱：

  • 长通话超过单 session 时长
  • 中途换工具策略
  • 断线重连后上下文要不要延续
  • 会话结束后哪些状态要持久化

4.5 工具调用时机 ​

一旦实时语音接工具，就要明确：

  • 是先口头确认再调工具
  • 还是先静默查数据再回答
  • 哪些动作必须人工确认

这和文本 Agent 的风险边界是同一类问题，只是语音场景更难发现错误。

5. 转写系统和语音助手的状态设计完全不同 ​

5.1 转写系统更像流式记录器 ​

它更关注：

  • partial / final 文本
  • 术语识别
  • 说话人切换
  • 丢包补偿

5.1.1 时间戳粒度和置信信息最好直接进入转写产物对象 ​

OpenAI 当前 Speech to text 官方文档已经把这些能力单独暴露出来：

  • timestamp_granularities
  • segment / word 粒度
  • logprobs

这说明转写产物最不该只留一段纯文本。

更稳的转写对象通常至少会带：

  • final transcript
  • segment timestamps
  • 关键字或词级 timestamps
  • 低置信词标记
  • 术语词典命中情况

这样你后面才能真正支持：

  • 点句子回音频时间轴
  • 对低置信词单独复核
  • 对术语错误做针对性修正
  • 对 partial / final 差异做运营分析

5.2 语音助手更像持续会话机 ​

它更关注：

  • 谁在说
  • 什么时候轮到谁说
  • 当前意图是否完成
  • 工具调用是否结束
  • 下一句是否需要澄清

5.3 为什么“转写正确”不等于“对话自然” ​

因为对话体验还取决于：

  • 停顿节奏
  • 打断是否自然
  • 工具等待时的话术
  • 上下文是否延续

所以语音助手的验收不能只看转写字对不对。

6. 语音系统的典型产品路线 ​

6.1 录音转写与摘要 ​

适合：

  • 会议
  • 访谈
  • 售后录音

重点补：

  • 长音频分段
  • 时间戳
  • 术语词表
  • 说话人和段落整理

6.2 实时字幕与旁听 ​

适合：

  • 会议字幕
  • 直播转写
  • 通话辅助

重点补：

  • partial 稳定性
  • 终稿修正
  • 延迟预算
  • 异常恢复

6.3 语音问答与陪练 ​

适合：

  • 教学陪练
  • 面试训练
  • 语言练习

重点补：

  • interruption
  • 角色语气
  • 回答长度
  • 多轮状态

6.4 语音助手与电话 Agent ​

适合：

  • 查单
  • 导航
  • 客服
  • 操作执行

重点补：

  • 工具权限
  • 审批边界
  • 日志留存
  • 会话复盘

7. 语音系统更像事件流，而不是简单问答 ​

一条更实用的心智通常像这样：

text
Audio In
 -> Turn Detection / VAD
 -> Realtime Session State
 -> Transcription / Reasoning / Tool Decision
 -> Speech or Text Response
 -> Interruption / Resume / Audit

7.1 输入层 ​

重点看：

  • 采样率
  • 噪声
  • 麦克风环境
  • 音频切片

7.2 状态层 ​

重点看：

  • 当前谁在说
  • 当前轮次是否结束
  • 是否进入工具等待
  • 是否允许模型继续说

7.3 工具层 ​

重点看：

  • 哪些查询可自动做
  • 哪些写操作要确认
  • 返回结果是否适合直接朗读

7.4 输出层 ​

重点看：

  • 回答长度
  • 语速与停顿
  • 中断时如何收束
  • 是否需要文本同步显示

7.5 输出层最好把“听觉产物”和“阅读产物”分开设计 ​

很多团队做语音助手时，只关注：

  • 模型说了什么

但真实系统里，至少有两种不同的输出对象：

  1. audio output 面向耳朵，关注语速、停顿、情绪、音色、时长。
  2. text companion output 面向屏幕，关注可读性、可复制、可审计、可搜索。

OpenAI 当前 Text to speech 官方文档已经把：

  • voice
  • audio format
  • instructions

都当成正式参数来设计。这说明输出层并不是“把文本转成声音”这么简单。

更稳的语音产品通常会单独决定：

  • 哪些回答必须同时显示文字
  • 哪些高风险动作必须先文字确认
  • 哪些长回答应该改成短语音 + 长文本卡片

这会比“全部直接朗读”自然得多，也更安全。

8. 评测语音系统不能只看 WER ​

转写系统当然可以关心识别质量，但如果要做语音对话或语音助手，评测层次要更多。

8.1 转写类更适合看 ​

  • 词错误率趋势
  • 术语识别正确率
  • 时间戳稳定性
  • final 修正质量

8.2 实时互动类更适合看 ​

  • 首响应延迟
  • interruption 恢复成功率
  • 轮次切换自然度
  • 用户重复率

8.3 工具型语音助手更适合看 ​

  • 查询动作成功率
  • 高风险动作确认命中率
  • 工具等待期间用户流失率
  • 人工接管率

8.4 运营层更适合补 ​

  • 会话时长
  • 丢包或断线率
  • 重连成功率
  • 单会话成本

8.5 语音评测集最好强制包含“噪声、弱网、口音、抢话”坏样本 ​

很多团队只在理想环境里测语音：

  • 安静房间
  • 标准普通话
  • 稳定网络
  • 单人单轮对话

这会让系统上线后很容易翻车。

更稳的最小语音评测集通常应该故意包含：

  • 背景噪声
  • 弱网或丢包
  • 口音重和语速快
  • 用户中途改口
  • 用户抢话打断
  • 工具等待期间再次追问
  • 电话场景的压缩音质

因为真实语音系统最难的，往往不是：

  • 模型会不会说

而是：

  • 信号很脏时还能不能保持节奏和状态

9. 成本和安全为什么不能后置 ​

9.1 实时成本不是普通文本成本的简单放大 ​

OpenAI Managing costs for Realtime 官方资料明确把实时成本单独拿出来，说明：

  • 音频输入
  • 文本推理
  • 音频输出
  • 持续会话

会一起影响预算。

9.2 语音链路更容易碰到隐私问题 ​

因为它天然会带来：

  • 录音留存
  • 电话录音合规
  • 用户敏感信息口述
  • 背景音暴露

9.3 语音助手接工具时更容易发生“用户没意识到就执行了” ​

所以对高风险动作，更稳的路径通常是：

  • 文本或语音二次确认
  • 服务端策略拦截
  • 审批和审计留痕

9.4 留存策略最好把原音频、转写文本、事件流和工具日志分开 ​

很多团队一说语音合规，只想到：

  • 要不要录音

但真实系统里通常至少有四类不同资产：

  1. 原始音频
  2. 转写文本
  3. Realtime 事件流
  4. 工具调用与审批日志

它们的敏感度、保留价值和成本都不一样。

更稳的做法通常会分别定义：

  • 原音频留多久
  • 文本转写留多久
  • partial / final 事件要不要全量保
  • 工具执行日志和审批记录留多久

这样你才能同时兼顾：

  • 调试
  • 合规
  • 成本
  • 事故追责

10. 最容易踩的坑 ​

  • 把转写系统和语音助手共用一套架构。
  • 没有定义打断和恢复策略。
  • 工具执行结果直接朗读，不做摘要或确认。
  • 只测安静环境，不测真实噪声和弱网。
  • 只盯着识别正确率，不看会话完成率和用户体验。
  • VAD 参数写死一套，不按电话、陪练、字幕等场景分流。
  • 只留最终文本，不留时间戳、低置信词和事件流。
  • 前端直连实时工具，不保留服务端 sideband 控制面。

11. 推荐搭配阅读 ​

12. 重点官方资源 ​

以下资源在 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：

13. 什么时候该跳到别的目录 ​