在AI应用开发的语境下,ASR、LLM、TTS 状态指的是这三个核心模块在实时语音交互系统中的工作状态/生命周期状态

简单来说:ASR在“听”,LLM在“想”,TTS在“说”。它们的状态流转构成了完整的语音对话闭环。


 先分清三个模块

模块 全称 功能 类比
ASR 自动语音识别 语音 → 文字 耳朵(听)
LLM 大语言模型 文字 → 思考 → 文字 大脑(想)
TTS 文本转语音 文字 → 语音 嘴巴(说)

 三个模块的“状态”详解

在实时语音交互场景中,每个模块都有多个状态,这些状态共同决定了系统的用户体验(如响应速度、打断能力、流畅度)。

1️⃣ ASR 状态(“听”的过程)

状态 说明 用户感知
IDLE(空闲) 未检测到语音输入,等待唤醒 静默
LISTENING(监听中) 正在实时采集音频流,VAD(语音活动检测)判定“有人在说话” 麦克风图标闪烁
PROCESSING(处理中) 音频采集结束,正在进行语音识别(将语音转为文本) “正在识别…”
ERROR(错误) 识别失败(如网络超时、音频格式不支持) “没听清,请再说一遍”
TIMEOUT(超时) 用户说话时长超过设定阈值(如10秒未结束) 自动停止监听,进入下一步

关键指标:ASR的“实时率”(RTF)——处理1秒音频需要多少秒。RTF < 1 才能做到实时。

2️⃣ LLM 状态(“想”的过程)

状态 说明 用户感知
IDLE(空闲) 没有请求,等待输入
THINKING(思考中) 已收到ASR文本,正在调用LLM生成回复(可能正在流式输出) “正在思考…” / 正在生成文字
STREAMING(流式输出中) LLM正在逐个Token输出回复内容(边生成边发送) 文字逐字出现 / 语音正在合成
FALLBACK(降级) 主模型不可用,切换到备选模型或规则回复 “我换个方式回答你”
ERROR(错误) LLM调用失败(如API Key无效、配额耗尽) “我暂时无法回答,请稍后再试”

关键指标TTFT(Time To First Token) —— 从发送请求到收到第一个Token的时间。TTFT越短,用户觉得系统“反应越快”。

3️⃣ TTS 状态(“说”的过程)

状态 说明 用户感知
IDLE(空闲) 没有合成任务
SYNTHESIZING(合成中) 正在将LLM返回的文本合成为音频 “正在生成语音…”
PLAYING(播放中) 合成好的音频正在从扬声器播放 听到语音回复
INTERRUPTED(被打断) 用户中途说话,触发了VAD,当前播放被暂停/终止 语音戛然而止(关键体验点)
ERROR(错误) 合成失败(如文本包含不支持的字符、音色不可用) 仅显示文字,无语音

关键指标:TTS的“首包延迟” —— 从收到文本到发出第一个音频包的时间。低于300ms才能有“流畅对话”感。


🔄 完整状态流转图(一次语音交互)

用户说话
    ↓
【ASR】IDLE → LISTENING(采集音频)→ PROCESSING(识别文字)→ 返回文本
    ↓
【LLM】IDLE → THINKING(调用大模型)→ STREAMING(流式输出文字)
    ↓
【TTS】IDLE → SYNTHESIZING(合成语音)→ PLAYING(播放语音)
    ↓
用户听到回复 → 系统回到 IDLE(等待下一轮)

🚨 生产环境中的“状态陷阱”

问题 现象 解决方案
状态不同步 前端显示“正在听”,后端已经在“想”了 用Event-Driven架构,每个状态变化都下发事件
打断处理 TTS正在播放时用户插话,系统不理睬 设计“打断检测”机制:VAD检测到新语音时,立即停止TTS并重置ASR
超时兜底 用户一直不说话,ASR卡在LISTENING 设置静音超时(如2秒)和总时长超时(如30秒)自动终止
LLM慢导致体验差 TTFT > 2秒,用户感觉“卡住了” 前置“正在思考”动画 + 流式输出 + 预估剩余时间
TTS音频还没播完,LLM下一句就来了 多个TTS请求堆积 TTS队列管理 + 单线程播放,新请求等待前一任务结束(或设置队列容量)

 面试时的话术框架

如果面试官问:“你们的语音交互系统怎么管理状态的?”

你可以这样回答:

“我们会为ASR、LLM、TTS分别定义状态机,并在前端通过事件流实时同步状态变化。ASR负责从LISTENING到PROCESSING的转换LLM负责THINKING到STREAMING的转换TTS负责SYNTHESIZING到PLAYING的转换。整个链路的关键指标是TTFT和首包延迟。同时,我们设计了静音超时、打断检测和异常重试机制,确保任何单一模块故障都不会让整个对话卡死。”

Logo

Agent 垂直技术社区,欢迎活跃、内容共建。

更多推荐