Wiki Notes

Appearance

语音模型专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在做语音助手、会议转写、呼叫中心、语音陪练、无障碍朗读、电话机器人、音频检索和实时语音交互的产品、研发与平台工程同学

语音系统经常给人一种错觉：

  • 输入是声音，输出还是模型结果，所以只是文本系统外面多包了一层音频

真实项目里，这个理解通常会很快失效。

因为语音系统和文本系统最大的区别在于：

  • 输入是连续流，不是离散表单
  • 用户会停顿、打断、重复、改口
  • 延迟对体验影响更直接
  • 噪声、口音、回声、设备差异会不断扰动整条链路

根据 2026-07-09 复核可访问的 OpenAI Audio and speech 与 Realtime and audio 当前官方资料，可以先建立一个关键共识：

  • 语音系统真正要解决的不是“会不会转写或说话”，而是怎样把音频输入、会话控制、工具调用、延迟预算、连接方式和评测闭环接成一套稳定体验。

1. 先把语音系统拆成四类任务 ​

OpenAI 当前 Audio and speech 指南把音频应用拆成几种核心模式：

  • audio input
  • audio output
  • text transcript
  • realtime session

结合工程实践，常见任务可以拆成四类：

1.1 Speech to Text ​

适合：

  • 字幕
  • 会议纪要
  • 电话录音分析
  • 搜索与检索

1.2 Text to Speech ​

适合：

  • 播报
  • 配音
  • 语音回复
  • 无障碍朗读

1.3 Speech to Speech ​

适合：

  • 语音助手
  • 实时客服
  • 口语陪练
  • 设备语音交互

1.4 Speech Translation ​

适合：

  • 同传
  • 双语客服
  • 跨语种陪练

如果这几类任务一开始没有拆开，后面很容易发生链路混乱。

2. request-based、realtime session 和“给现有聊天加音频”不是一回事 ​

OpenAI 当前文档已经把音频路线拆得很清楚：

  • request-based audio APIs
  • realtime sessions
  • multimodal chat completions

这三个入口解决的问题不一样。

2.1 更适合 request-based ​

适合：

  • 音频文件转写
  • 批量字幕
  • 会议录音离线处理
  • 文本转语音播报

特点：

  • 输入边界清楚
  • 可接受稍高时延
  • 更容易重试、回放和审计

2.2 更适合 realtime ​

适合：

  • 实时语音助手
  • 低延迟电话机器人
  • 连续翻译
  • 边说边转写

特点：

  • 输入是持续流
  • 需要会话状态
  • 用户随时可能打断
  • 时延直接影响主观自然度

2.3 “给现有文本聊天加音频”更像增量改造 ​

OpenAI 当前 Audio and speech 文档还明确提到：

  • 如果你已有基于聊天的文本应用，也可以给它加音频输入输出
  • 当前这类音频聊天模式要用支持音频的 chat 模型

这条路线更适合：

  • 现有文本客服加语音入口
  • 已有知识助手补语音输入
  • 先验证语音入口，而不是先做完整 voice agent

一句话理解：

  • 有完整文件就偏 request-based，有持续说话就偏 realtime，只是给现有聊天补音频则更像现有聊天流的模态扩展。

3. 语音系统的核心链路不是一条，而是四条 ​

3.1 转写链路 ​

text
Audio
 -> preprocess
 -> transcription
 -> punctuation / formatting
 -> domain normalization
 -> storage / search

3.2 语音对话链路 ​

text
Microphone
 -> VAD / turn detection
 -> transcription or speech reasoning
 -> LLM / tools
 -> response planning
 -> speech generation
 -> playback

3.3 翻译链路 ​

text
Live audio
 -> streaming ingest
 -> translation session
 -> translated audio / transcript deltas
 -> operator or user playback

3.4 语音运营链路 ​

text
Audio session
 -> transcript + events
 -> QA / safety review
 -> metrics / cost / latency analysis
 -> improvement loop

很多系统只关注第二条链路，却忽略第一、第三和第四条，最后就会出现：

  • 体验问题很难定位
  • 真实错误没法复盘
  • 无法知道问题在转写、推理、翻译还是播放

4. realtime 里其实又分三种 session，不要全混成“语音对话” ​

这是当前官方资料里最值得先补进团队心智的一点。

OpenAI 当前 Realtime and audio 把 realtime 至少拆成三种：

  • voice-agent session
  • translation session
  • transcription session

4.1 voice-agent session ​

更适合：

  • 助手需要回应用户
  • 助手需要调工具
  • 助手要维护会话状态

这类 session 走标准 Realtime conversation lifecycle。

4.2 translation session ​

更适合：

  • 应用只想持续翻译说话人内容
  • 不需要标准 assistant turn 生命周期

OpenAI 当前文档明确说明：

  • translation session 是连续型的
  • 不使用普通 assistant turn 生命周期
  • 不该等 response.create
  • 也不该等客户端先 commit 一个用户 turn 再开始翻译

这意味着翻译系统和普通 voice agent 根本不是一个状态机。

4.3 transcription session ​

更适合：

  • 你只想拿 live transcript deltas
  • 不需要模型生成 spoken response

OpenAI 当前文档明确建议：

  • 如果要 streaming transcript deltas，用 realtime transcription session
  • 如果是文件上传、request-based transcription 或偏 diarization 的工作流，则回到 speech-to-text 路线

4.4 一个最容易踩的坑 ​

很多团队会把：

  • 实时字幕
  • 实时翻译
  • 语音助手

都挂在一套“会话机器人”框架上。

但这三者的：

  • turn lifecycle
  • 触发时机
  • 工具能力
  • 结果形态

都不一样。

5. 连接方式应该按媒体捕获位置来选，不要按“谁更高级”来选 ​

OpenAI 当前 realtime 文档把连接方式拆成：

  • WebRTC
  • WebSocket
  • SIP

5.1 WebRTC ​

更适合：

  • 浏览器
  • 移动端
  • 直接采集或播放音频的前端客户端

如果你的应用是在用户设备上直接采音、播音，这通常是最自然的路线。

5.2 WebSocket ​

更适合：

  • 你的服务端已经拿到了原始音频流
  • 有媒体流水线、worker、呼叫系统或广播 ingest

这类场景里，WebSocket 往往比前端直连更贴近系统真实边界。

5.3 SIP ​

更适合：

  • telephony voice agents

但当前官方资料也提醒：

  • 在 translation 或 transcription 上使用 SIP 前，要先确认模型支持

5.4 更实用的选型口诀 ​

  • 浏览器 / 手机直采直放：WebRTC
  • 服务端媒体流水线：WebSocket
  • 电话系统：SIP

6. Realtime 不是只管低延迟，还要管凭证、标识和 GA 事件模型 ​

很多团队把 Realtime 工程理解成“接上 WebRTC 就完了”，这远远不够。

6.1 前端接入通常要走 ephemeral credentials ​

OpenAI 当前 GA 文档明确要求：

  • 浏览器或移动端客户端应通过 POST /v1/realtime/client_secrets 创建短期凭证
  • WebRTC 会话走 /v1/realtime/calls

这意味着：

  • 不应该把长期 API key 暴露到前端

6.2 safety identifier 很值得尽早接入 ​

OpenAI 当前文档明确建议：

  • 如果应用识别具体终端用户，应在 Realtime 请求里带稳定、隐私保护的 safety identifier

这对企业系统的价值很实际：

  • 风险定位更容易收敛到单个用户
  • 更适合做 abuse 监控和追责

6.3 这个标识不会自动从别的接口继承 ​

官方资料还明确提醒：

  • 它不会从别的 Responses API 请求自动继承到 Realtime session

也就是说：

  • 你如果别处已经传了 safety_identifier，在 Realtime 里还得单独传

6.4 GA 事件模型也不能忽略 ​

OpenAI 当前 GA 迁移说明提到：

  • 要设置 session.type
  • 输出音频配置移到 session.audio.output
  • 要使用新的 response delta 事件名称

这说明很多“前端怎么听”“后端怎么记事件”的代码，在 GA 之后都不能继续沿用旧 beta 心智。

7. STT 的难点根本不只是 WER ​

很多团队一说语音转写，就只盯：

  • WER

但企业里更常影响可用性的，往往包括：

  • 专有名词
  • 品牌词
  • 人名地名
  • 数字、金额、编号
  • 中英文混说

7.1 企业里更该单独测的几类词 ​

例如：

  • 产品型号
  • 客户名
  • 组织名
  • SKU
  • 数字串
  • 业务术语

7.2 转写结果不一定直接给用户看 ​

很多场景下，转写结果还会进入：

  • 检索
  • 总结
  • 工单分类
  • 审批建议

所以转写错误的后果可能会被后续链路放大。

7.3 realtime transcription 还有“延迟-质量”拨盘 ​

OpenAI 当前 Realtime and audio 文档明确说明：

  • gpt-realtime-whisper 给的是可控延迟
  • 更低 delay 会更早给 partial text
  • 更高 delay 往往能提升 transcript 质量

这意味着生产里更像真实的问题不是：

  • “能不能实时转写”

而是：

  • 你想要更早 partial，还是更稳 final

7.4 生产默认值一定要在真实音频上选 ​

官方资料也明确提醒要用真实条件测试：

  • 目标语言
  • 口音
  • domain vocabulary

如果只在安静实验室音频上调参数，线上几乎一定会出偏差。

8. TTS 的质量不只是“声音好不好听” ​

很多人第一次做 TTS 时，最先关注的是：

  • 声音自然不自然

但产品上更重要的常常还有：

  • 发音稳定性
  • 术语准确性
  • 语速
  • 情绪
  • 可懂度
  • 首包延迟

8.1 什么叫“声音好听但产品不可用” ​

常见情况包括：

  • 读数字和专有词总出错
  • 情绪不合适
  • 太慢或太快
  • 生成太慢，实时场景完全不可用

8.2 不同产品要的不是同一种 TTS ​

例如：

  • 会议播报要清晰与稳定
  • 客服机器人要自然与低延迟
  • 内容配音要更强风格控制

所以不要把所有 TTS 需求都当成一个任务。

8.3 当前官方路线还强调“可流式返回” ​

OpenAI 当前 Audio and speech 文档明确说明：

  • speech generation 可以边生成边回流音频

这对工程的启发很直接：

  • 不是所有 TTS 都应该先整段生成完再播

9. speech-to-speech 的关键不是“把 STT 和 TTS 串起来” ​

OpenAI 当前音频文档明确把 speech-to-speech 定义为：

  • 模型在一个低延迟 session 里同时听、推理、说

这和“先 STT、再文本推理、再 TTS”的链路虽然相关，但心智不一样。

9.1 speech-to-speech 更适合哪些场景 ​

  • conversational voice agents
  • 实时客服
  • 需要工具调用的口语交互
  • 需要维护 session state 的连续对话

9.2 当前官方给的一个很重要建议 ​

OpenAI 当前 realtime 文档明确建议：

  • 对多数生产 voice agents，reasoning.effort 先从 low 开始
  • 再根据延迟容忍度和任务复杂度逐步上调

这条建议很重要，因为很多团队一上来就把“更强 reasoning”理解成“更好语音体验”，但语音场景里延迟往往先把体验打垮。

9.3 语音里“先开口”通常比“想很久再说”更关键 ​

所以更常见的稳态策略是：

  • 低 effort 起步
  • 先保证 turn feedback 快
  • 再逐步加复杂度

10. 实时语音的本质是延迟预算和 turn 状态管理 ​

Realtime 语音的难点往往不只是“模型能说”，而是：

  • 用户在多快时间内感到系统“像在和我对话”

10.1 建议先拆预算，而不是先选模型 ​

常见预算层包括：

  • 采集缓冲
  • VAD / turn detection
  • 识别或理解
  • 工具调用
  • 语音生成
  • 播放

10.2 首次可感知响应比总时长更影响主观体验 ​

因为用户通常更敏感的是：

  • 系统多久开始回应

而不是：

  • 最终整段语音总共多长

10.3 translation session 更是连续流，不要拿普通 assistant turn 去套 ​

OpenAI 当前文档明确写到：

  • translation session 不用普通 assistant turn lifecycle
  • 不要等 response.create
  • 不要等客户端 commit user turn 再开始翻译

所以翻译链路的状态机设计，不该照搬 voice agent。

11. 会话控制比模型本身更容易把体验做差 ​

很多语音体验问题根本不是模型太弱，而是会话控制没设计好。

11.1 Turn detection ​

需要解决：

  • 什么时候算用户说完
  • 多久开始回应
  • 停顿是结束还是继续想说

11.2 Interruption ​

需要解决：

  • 用户打断时是否立刻停播
  • 之前已计划的回答如何取消
  • 是否要保留已执行的工具结果

11.3 Session state ​

需要解决：

  • 会话历史如何延续
  • 哪些中间状态要保留
  • 哪些状态在租户 / 用户切换后必须失效

11.4 事件对象最好单独标准化 ​

更像生产系统的语音会话日志，至少可以保留：

  • session_id
  • turn_id
  • audio_chunk_count
  • vad_boundary_count
  • barge_in
  • tool_wait_ms
  • first_audio_delta_ms
  • final_task_status

这也是为什么 realtime 语音的系统工程难度往往高于同等复杂度的文本助手。

12. 语音系统里的工具调用要更保守 ​

语音比文本更容易误触发，因为：

  • 识别有误差
  • 用户可能改口
  • 对话更连续

所以语音系统里对工具调用通常要更保守。

12.1 低风险自动执行 ​

适合：

  • 只读查询
  • 一般性检索
  • 无副作用摘要

12.2 中风险二次确认 ​

适合：

  • 外发消息
  • 预约调整
  • 表单提交

12.3 高风险必须审批 ​

适合：

  • 转账
  • 改权限
  • 导出敏感数据
  • 删除记录

语音系统里，用户听到确认与真正执行之间的边界一定要做得比文本更清楚。

13. 语音任务怎么评测才像生产系统 ​

13.1 转写类 ​

适合看：

  • WER / CER
  • 术语识别正确率
  • 数字与专有词准确率
  • final transcript 稳定性

13.2 语音生成类 ​

适合看：

  • 自然度
  • 可懂度
  • 发音一致性
  • 首包延迟

13.3 实时交互类 ​

适合看：

  • turn 成功率
  • interruption 成功率
  • 首次响应时延
  • 任务完成率
  • tool wait 期间沉默过长比例

13.4 运营类 ​

企业里更值得额外看：

  • 人工转接率
  • 误触发率
  • 成本
  • 故障回放覆盖率
  • safety identifier 覆盖率

13.5 发布门禁最好至少分三层 ​

  • 必过门禁：高风险动作确认、误执行率、工具越权
  • 软门禁：平均延迟、首包延迟、人工转接率
  • 观察门禁：新口音、新噪声场景、新设备类型

14. 企业里更常见的失败模式 ​

14.1 只做 Demo 环境，不测真实噪声 ​

上线后通常会立刻暴露：

  • 口音
  • 麦克风质量
  • 环境噪声
  • 回声

14.2 把实时语音当成文本系统加一层 ASR/TTS ​

这样最容易忽略：

  • turn detection
  • interruption
  • 延迟预算
  • 连接方式和会话凭证

14.3 把翻译、转写、voice agent 混成同一条 session 状态机 ​

这会让：

  • 生命周期
  • 事件模型
  • 工具策略

一起变乱。

14.4 高风险动作没有二次确认 ​

语音系统里这是非常危险的设计。

14.5 不记录会话事件 ​

这样出问题时很难知道：

  • 是识别错了
  • 决策错了
  • 还是播放和打断错了

15. 语音系统的实践建议 ​

15.1 先区分离线和实时 ​

不要试图用一条链同时解决全部场景。

15.2 先区分 voice-agent、translation、transcription 三种 session ​

不要继续用“实时语音”一个词概括全部产品。

15.3 先建术语表和高风险词表 ​

企业语音项目里，这往往比“再换个模型”更快改善体验。

15.4 先定延迟预算 ​

没有预算就很难知道该优化哪一层。

15.5 先想清人工兜底 ​

尤其在客服、审批、电话机器人场景里，人工接管不是可选项。

15.6 前端直连场景先把短期凭证和安全标识接好 ​

否则很容易后补时改动一大片接入链路。

16. 推荐搭配阅读 ​

17. 重点官方资源 ​

以下资源在 2026-07-09 复查时可访问：