AI助手语音交互中实时多模态语音模型替换ASR-LLM-TTS 链路可行性分析

[gac0812]

AI助手语音交互中实时多模态语音模型替换ASR-LLM-TTS 链路可行性分析

1. 结论摘要

将 Timeflow 原有的“ASR 转写 → 文本大模型 → 工具调用 → TTS 合成 → 前端播放”链路，替换为“实时多模态模型持续接收音频 → 模型判断并调用工具 → 流式返回文本与音频”的方案，在技术上可行。如果后期开发过程中出现对话延迟较高等问题，可以考虑采用该方案，
经demo测试该方案延迟可以忽略不计

适合采用局部替换，而不是把全部语音相关能力一次性迁移：

• 只替换 assistant 中的实时对话链路，包括收音、轮次判断、意图理解、工具调用、助手回答和插话打断。
• 保留 assistant 作为唯一日程写入入口，模型不得绕过草稿确认直接写数据库。
• 保留后端工具网关，模型只提出工具调用，后端负责鉴权、参数校验、数据库访问、幂等和审计。
• 保留 reminder 的“服务端提前合成提醒音频 → 客户端缓存 → 触发时播放 → 播完删除”流程。
• 保留客户端地理编码、日程不变量校验和离线日程抽取方案。
• 结构化数据仍由后端 Schema 和领域规则校验，不能把模型输出直接当成可信数据。

综合判断：

维度	判断
技术可行性	高，官方实时 API 已支持流式音频和 Function Calling
与当前架构兼容性	中高，现有 port 分层有利于替换，但前后端会话协议需要同步调整
延迟收益	明显，预计可减少独立 ASR、LLM、TTS 串行等待
结构化数据可靠性	可控，但必须继续由后端校验和归一化
生产风险	中等，主要在连接稳定性、工具幂等、打断状态、成本和供应商依赖
推荐结论	先完成只读工具 POC，通过验收后灰度替换，旧链路保留为降级通道

国内模型优先候选为阿里云 qwen3.5-omni-plus-realtime；对延迟和成本更敏感时可评估 qwen3.5-omni-flash-realtime。OpenAI Realtime API 可作为另一候选实现。用户提出的 gpt-realtime-2.1 应视为候选模型标识，正式接入前必须以项目账户实际可用的公开模型 ID 为准。

---

2. 分析范围

2.1 本次要替换的内容

本次只分析实时对话相关能力：

1. 麦克风音频流上传。
2. 说话开始、结束和轮次判断。
3. 用户插话时停止助手播报。
4. 多轮上下文维护。
5. 查询日程、生成草稿等工具调用。
6. 助手回复的文本留痕与实时音频播放。
7. 网络中断、模型失败时的会话恢复和降级。

2.2 本次不替换的内容

1. 不修改客户端提醒触发规则。
2. 不使用实时模型生成需要提前缓存的提醒音频。
3. 不改变地点解析仍在客户端完成的边界。
4. 不取消日程草稿确认步骤。
5. 不允许模型直接访问数据库或执行任意 SQL。
6. 不替换本地 ASR、本地模型和离线日程抽取能力。
7. 不改变现有 feature 之间零 import、跨 feature 由 app/ 编排的架构规则。

---

3. 两种方案定义

3.1 原方案：传统串行语音链路

flowchart LR
    A["用户语音"] --> B["ASR 转写"]
    B --> C["文本大模型理解"]
    C --> D["后端工具网关"]
    D --> E["数据库或外部服务"]
    E --> C
    C --> F["生成文本回答"]
    F --> G["TTS 合成"]
    G --> H["前端播放"]

Loading

原方案把语音识别、意图理解、工具调用和语音合成拆成独立阶段。每一层都容易单独替换和测试，但用户必须等待多个阶段串行完成。

3.2 新方案：实时多模态对话链路

flowchart LR
    A["用户连续语音"] <--> B["实时多模态会话"]
    B --> C["结构化工具调用"]
    C --> D["Timeflow 后端工具网关"]
    D --> E["数据库或外部服务"]
    E --> D
    D --> B
    B --> F["流式文本和音频"]
    F --> G["前端即时播放"]

Loading

新方案用一个长连接会话承载音频输入、转写事件、模型推理、工具调用和流式回答。ASR 与 TTS 不再作为用户可感知的独立串行步骤，但后端工具和业务规则仍然独立存在。

---

4. 核心对比

对比项	原方案：ASR + LLM + TTS	新方案：实时多模态模型
交互方式	用户说完后依次处理	持续传输音频，实时检测轮次
首次语音响应	经过 ASR、LLM、TTS 多段串行等待	模型直接流式产生回答音频
插话打断	需要自行同步录音、TTS 和播放器状态	实时会话原生支持度更高，但客户端仍需实现停止播放和清理缓冲
工具调用	文本模型输出工具请求，后端执行	实时模型在同一会话中输出 Function Call，后端执行
结构化数据	文本模型可单独按 Schema 生成和重试	工具参数是结构化数据，但仍需后端校验；不要让语音回答承担协议职责
调试定位	ASR、LLM、TTS 可分别记录和回放	事件流更复杂，需要统一 trace、turn 和 tool_call 标识
组件替换	各组件可以独立更换供应商	对实时模型和协议的依赖更强
弱网表现	单次 HTTP 失败容易重试，但总耗时长	长连接对抖动更敏感，需要重连、缓冲和会话恢复
成本结构	分别计算 ASR、LLM、TTS 成本	按实时音频、文本和上下文 Token 计费，长会话历史可能持续累积
离线能力	可以切换本地 ASR、模型或 TTS	云端实时会话本身不可离线
供应商迁移	标准接口较多，迁移相对容易	音频事件、VAD、工具事件和鉴权方式存在供应商差异
最适合场景	结构化任务、后台处理、可容忍等待	连续语音、多轮追问、快速问答、允许用户插话

原方案的主要优势是可控、可观测、易拆分；新方案的主要优势是低延迟和更自然的轮次交互。新方案不是简单替换一个 TTS 接口，而是替换 assistant 的整条在线会话传输方式。

---

5. 关键能力可行性

5.1 实时语音输入与流式播报

可行。

Qwen3.5-Omni-Realtime 官方支持 WebSocket、WebRTC 和 AOQ 接入，可持续接收音频并流式返回文本和音频。官方示例中的输入是 16 kHz PCM，输出是 24 kHz PCM。当前 Timeflow 目标结构已经规划 16 kHz PCM 录音器，因此输入侧方向兼容；输出侧需要验证 AudioPlayer 的 24 kHz 流式缓冲和打断行为。

接入方式建议分两步：

阶段	接入方式	原因
POC	客户端 → Timeflow WebSocket → 实时模型 WebSocket	复用现有会话层，API Key 保留在服务端，最容易接入工具网关和日志
延迟优化	评估客户端 WebRTC/AOQ 直连媒体，控制事件仍经后端	减少音频中转，但必须先解决短期凭证、工具回调和移动端兼容性

客户端不得内置长期供应商 API Key。若使用直连模式，必须由后端提供供应商明确支持的短期凭证或会话授权；如果供应商没有满足要求的机制，则继续由后端中转。

5.2 调用自定义工具查询数据库

可行，但执行权必须在 Timeflow 后端。

以“帮我查一下明天的日程”为例：

sequenceDiagram
    participant U as 用户
    participant R as 实时模型
    participant G as Timeflow 工具网关
    participant DB as 日程数据库

    U->>R: 帮我查一下明天的日程
    R->>G: list_schedules(from, to, timezone)
    G->>G: 鉴权、Schema 校验、权限检查
    G->>DB: 查询当前用户日程
    DB-->>G: 结构化日程列表
    G-->>R: tool_result
    R-->>U: 明天有三项日程……

Loading

建议只向模型开放业务级工具：

工具	类型	约束
list_schedules	只读	后端根据登录态固定 user_id，模型不能指定其他用户
get_schedule_detail	只读	校验日程归属
build_schedule_draft	无副作用	只生成草稿，不写数据库
confirm_schedule_draft	写入	必须携带用户确认后生成的一次性确认凭证和幂等键

不应开放 execute_sql、任意 HTTP 请求或直接 create_schedule 之类绕过确认流程的工具。

5.3 是否能够“边说边查”

条件成立时可以，但不能把它理解为用户刚开口就一定执行数据库查询。

实时模型可以在用户说话时持续接收音频并形成中间理解。是否在用户尚未结束时发出工具调用，取决于 VAD、模型判断和供应商事件机制。为了避免把“明天”误听成“下周一”，建议采用分级策略：

1. 只读、可取消、无隐私扩散的查询允许提前预取。
2. 查询参数稳定前不向用户展示最终结果。
3. 创建、修改、删除日程必须等用户完整表达并再次确认。
4. 用户插话改变条件时，取消旧查询或丢弃旧结果。
5. 每个工具结果绑定 turn_id，过期轮次的结果不得进入当前回答。

因此，新方案可以让“理解语音”和“准备查询”部分重叠，但最终速度仍受数据库和外部服务耗时影响。模型不能在查询结果返回前可靠播报最终答案。

5.4 只在需要时播报，其余返回结构化数据

可行，推荐由后端策略决定输出模式，而不是完全交给模型自由选择。

Qwen 实时会话支持配置仅文本输出，或文本与音频同时输出。Timeflow 可以按场景使用以下策略：

场景	模型输出	前端行为
普通对话、追问、查询摘要	文本 + 音频	展示文字并播放音频
工具调用和工具结果	结构化事件	不播报
日程草稿	ScheduleDraft 数据 + 简短语音	展示草稿卡并提示用户确认
后台同步或内部状态更新	结构化数据或纯文本事件	不播报
错误恢复	标准错误数据；必要时附简短语音	UI 展示明确错误，不伪造成功

无论采用哪家实时模型，都不应把模型生成的 JSON 直接写入数据库。工具参数和结构化结果必须经过：

JSON 解析
  → Schema 校验
  → 用户权限检查
  → 日期、时区和字段归一化
  → Schedule 领域不变量校验
  → 用户确认
  → 幂等写入

---

6. 延迟分析

以下数值是用于设计 POC 的工程预算，不是供应商 SLA。最终结论必须在目标网络、目标手机和真实后端上测量。

6.1 原方案的延迟组成

阶段	参考耗时
等待停顿并确认语音结束	300–1,000 ms
ASR 生成最终文本	200–800 ms
大模型理解并决定工具	400–1,500 ms
数据库或普通内部工具	50–800 ms
大模型组织最终回答	300–1,200 ms
TTS 生成首段可播放音频	300–1,000 ms
传输、解码和播放器缓冲	100–400 ms

从用户停止说话到听见首段回答，简单回答通常可按约 1.3–4.7 秒预算；包含一次数据库查询时约 1.7–5.5 秒。若 ASR、模型或 TTS 冷启动，延迟还会增加。

6.2 新方案的延迟组成

阶段	参考耗时
VAD 确认轮次或语义停顿	200–800 ms
模型产生首个文本、工具或音频事件	200–800 ms
数据库或普通内部工具	50–800 ms
工具结果返回后产生首段音频	200–800 ms
播放器缓冲	50–250 ms

长连接已预热时，简单回答可按约 0.5–2.0 秒预算；包含一次数据库查询时约 0.8–3.0 秒。主要收益来自取消独立 ASR 和 TTS 的串行排队，以及允许转写、理解和部分查询准备重叠。

新方案无法消除以下延迟：

• 用户表达本身所需时间。
• VAD 为避免抢答而等待的停顿时间。
• 数据库、地图、天气等真实工具耗时。
• 弱网重传、连接重建和移动系统音频缓冲。