多模态模型实时交互技术

CH-10-04-016·约 18 分钟·大模型·更新 2026-08-11

小李第一次走进新开的“AI 智能 KTV”时，被震撼到了。他拿起话筒唱了一句，AI 和声几乎在他第二个字落音时就接了上来，像是有一位看不见的搭档坐在身边。他唱到一半清嗓子，AI 和声立刻停下等他；他切歌，AI 瞬间跟上新歌的旋律。最神奇的是，从开口到听见 AI 回应，中间几乎没有等待。走出 KTV，小李才明白：这不是什么魔法，而是多模态大模型学会了“边听、边想、边答”。这套技术背后的核心，就是实时交互。传统 AI 助手像发微信语音——你说完一整句，松开手，对方才收到；而实时交互像打电话——你一开口，声音就源源不断地流向对方。要做到这一点，系统需要把语音切成小块一路处理，需要听懂你的半句话，需要把合成的声音像流水一样喷涌而出，还需要在你打断它时优雅地让位。这篇文章，就用这家 KTV 对唱机的故事，把实时交互的每个环节拆给你看。

岗位关联

对 AI 从业者而言，实时交互是语音助手、同声传译、实时字幕等产品体验的灵魂。掌握流式处理与低延迟优化，你才能把“能对话”的模型变成“像真人”的产品。

可视化演示
流式处理原理：火锅不等锅开，麦霸不等缓存
流式语音识别：听懂你的半句话
流式语音合成：边说边唱的音箱
中断处理机制：半路切歌，AI 立刻应变
低延迟优化：把半秒压进眨眼之间
工程实践要点：把对唱机搬上云端
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示实时交互流式管线（ASR→LLM→TTS重叠执行）、端到端延迟优化策略（KV Cache/投机解码/模型蒸馏）、以及中断处理流程。切换模式探索实时语音交互技术。

本节配有交互动效（进入视口后自动加载，约 3KB）。

流式处理管线与重叠执行 ASR流式识别→LLM增量生成→TTS流式合成，三阶段重叠执行而非串行等待每生成一个token即开始TTS合成，将端到端延迟从1.5s压缩至300ms以内 latency = ASR_first + LLM_first_token + TTS_first_audio 流式重叠是实时交互的核心机制

流式处理原理：火锅不等锅开，麦霸不等缓存

KTV 的旧式点歌机有个让人抓狂的毛病：点完一首歌，画面上“缓冲中……”要转好几秒，伴奏才缓缓响起。新一代 AI 对唱机则完全不同——小李刚唱出“月亮代表我~”，AI 和声就在同一个乐句里接了上来。它不需要等整首歌的伴奏全部准备好，而是像火锅店的服务员一样，锅底刚沸腾就先把毛肚端上来，边吃边上菜，全程不停。

在技术世界里，这种“边到边”的处理方式叫流式处理。传统 AI 对话像发微信语音：你说完一整句、松开手，对方才收到；而流式对话像打电话：你的声音一进入麦克风，就化成一个个小数据包，源源不断地流向服务器。多模态大模型不需要等到整段语音收齐才开始干活，而是收到一小块就处理一小块，再把结果一点点传回来。

实现流式的第一步是数据分块。一段音频会被按照时间切成小块，比如每 20 毫秒一帧，每 100 毫秒打包一次。其次是通信方式，客户端和服务器之间要建立一条全双工的长连接（常见的是 WebSocket），双方可以同时说话、同时听，而不是一问一答式的 HTTP 请求。这样“边说边传、边传边处理”，等待感就消失了。

分块之后，整条流水线就活了起来。每一块语音像 KTV 传送带上的一道菜，从点歌台出发，经过识别、理解、合成三个窗口，最后从音箱里飘出来。你几乎感觉不到“等待”，因为系统一直在生产内容——这就是流式处理给人“像真人”这种感觉的根本原因。

N = \displaystyle\left\lceil \frac{L}{C} \right\rceil

这段语音总量 L 分成每块 C 大小，向上取整得到 N 块。你的 6 秒语音如果每块 100 毫秒，就被切成 60 块，而不是一大坨一次性发送。

L（数据总量）一整段语音的总大小或总时长，比如小李唱的 6 秒音频。
$L = 6\,\text{秒}$
C（分块大小）每一小块音频的时长，工程上常用 20ms~100ms。
$C = 100\,\text{ms}$
ceil（向上取整）除不尽时多算一整块，保证最后一点数据也被装走。
$N = \left\lceil \frac{6000\,\text{ms}}{100\,\text{ms}} \right\rceil = 60$

流式语音识别：听懂你的半句话

AI 和声要跟住小李，必须先知道他在唱什么、唱到了哪一句。如果 AI 每次都要等小李唱完一整段才“复盘”，那和声永远慢半拍。就像一位合格的合唱搭档，AI 必须在他张嘴的瞬间就开始判断：这声音是歌声还是清嗓子？这句唱到哪个字了？下一句有没有跑调的趋势？

技术世界里，这个能力叫流式语音识别（ASR）。它面对的第一个问题是“人声从哪里开始、到哪里结束”，这一步由一个叫 VAD（语音活动检测）的模块负责。VAD 像 KTV 包厢门口的服务员，看见客人拿起话筒就叫后厨准备，客人放下话筒就示意收工。一旦检测到人声，ASR 就开始增量识别——每新到一小块音频，就立刻更新当前识别出的文字。

增量识别的输出叫中间结果。它不像最终结果那样精确，但胜在“及时”。比如小李说“帮我订北京”，系统可能先识别出“帮我”，再修正为“帮我订”，最后收敛到“帮我订北京”。这些中间结果不断被新数据修正，就像和声歌手跟着你的颤音一点点校准音准。当 VAD 检测到用户停顿或说完（端点检测，EPD），ASR 才输出最终结果，交给大模型处理。

有了这套“边说边识别”的能力，AI 才能在用户话音刚落时就开始响应。它听到的不再是“一整句话”，而是一个不断生长的文本流——就像合唱搭档听着你的旋律逐渐成形，还没等你唱完，已经知道该怎么接。

\hat{s}(t) = \begin{cases} 1, & E(t) > \theta \\ 0, & E(t) \le \theta \end{cases}

\hat{s}(t) 表示 t 时刻是否有人声，E(t) 是此刻语音的能量，θ 是判断阈值。能量超过阈值就当是人声，否则当静音。

E(t)（短时能量）把一小段音频的振幅平方求和，反映这段声音有多“响”。
$E(t) = \sum_{n=0}^{C-1} x_n^2$
θ（能量阈值）一个预设的门槛，环境噪声大时抬高，环境安静时压低。
$\theta = \alpha \cdot \bar{E}_{\text{noise}}$
决策判断能量高过阈值就判定为“有人说话”，立刻启动增量识别。
$\hat{s}(t) = 1 \Rightarrow \text{开始识别}$

流式语音合成：边说边唱的音箱

KTV 的音箱为什么不会卡顿？因为伴奏不是等整首歌下载完才开始放，而是一边接收数据一边出声。AI 对唱机也一样，当大模型还在思考下一句话时，已经生成的文字碎片就已经被送去“配音”了。这个从文本到声音的过程，就是流式语音合成（TTS）。

流式 TTS 的第一步是流式解码。大模型每生成一个文本 token，就立刻把它传给合成器，而不是等整段回复写完后才动手。合成器里有个关键角色叫声码器，它像一位技艺高超的配音演员，把文本逐字变成音频帧——每一帧只有几十毫秒，但已经可以播放了。

对实时交互来说，最重要的体验指标之一是首包延迟：从用户说完话到听见 AI 的第一个字，这中间的时间决定了对话“像不像真人”。如果首包延迟超过 500 毫秒，人就会觉得对方反应慢；如果能压到 200 毫秒以内，就像朋友在跟你聊天。另一个重要指标是 RTF（实时率），它衡量合成速度能否追上播放速度。

把声码器输出的音频帧一个个送进喇叭，就形成了连续的声音。这就像 KTV 音箱吐出伴奏的每一个节拍，你听到的不是“一整首歌”，而是一股持续流动的声音流。AI 的回复还没想完，声音已经先到了——这就是流式合成带来的神奇体验。

RTF = \displaystyle\frac{T_{\text{proc}}}{T_{\text{audio}}}

RTF 是处理一段音频所花的时间除以这段音频本身的时长。RTF 小于 1，说明“边合成边播放”来得及；大于 1，说明合成速度跟不上播放。

T_proc（处理耗时）CPU 或 GPU 合成这段音频消耗的墙钟时间。
$T_{\text{proc}} = 0.3\,\text{秒}$
T_audio（音频时长）合成出的音频在播放时的自然时长。
$T_{\text{audio}} = 1.0\,\text{秒}$
RTF 判断0.3 / 1.0 = 0.3，意味着算 1 秒音频只需 0.3 秒，完全够实时。
$RTF = 0.3 < 1 \Rightarrow \text{实时}$

中断处理机制：半路切歌，AI 立刻应变

小李唱到“你问我爱你有多深”，突然觉得调起高了，拿起遥控器切了歌。如果 AI 和声还自顾自地继续唱原调，场面会非常尴尬。真人合唱搭档听到你切歌，会立刻停下，等你选定新歌再重新跟上。AI 实时交互系统也必须具备这种能力——中断处理。

中断处理的第一步是打断检测（barge-in）。系统在 AI 播报的同时，始终开着麦克风监听。如果检测到有人声进入，而且不是 AI 自己的回声，就判定用户想插话。这一步像 KTV 里两个人同时开口，一方敏锐地感觉到对方有话说，主动把话筒让出去。

一旦判定打断，系统要立即抢占控制权：暂停 TTS 播放，把正在说的话“咽回去”，同时让 ASR 开始收集用户的新指令。这里最关键的是上下文恢复——系统不能忘记刚才进行到哪一步。比如小李说过“帮我订北京机票”，又打断说“等等，先查查价格”，AI 要记得“订机票”这个大背景，只把动作切换成“查价格”。

好的打断处理不是粗暴地“闭嘴”，而是像一位体谅人的合唱伙伴：你切歌，它就把到嘴边的音符轻轻咽下去，等你新歌起头，它又自然地跟上来。这种“让位”和“接续”的默契，是实时交互有温度的关键。

T_{\text{bargein}} = T_{\text{det}} + T_{\text{sw}} + T_{\text{rec}}

打断响应时间等于检测到用户插话的时间、暂停当前任务的时间、恢复上下文并开始新响应的时间之和。每一环都要快，整体才跟手。

T_det（检测耗时）从用户开始发声到系统判定“这是插话”的时间。
$T_{\text{det}} = 150\,\text{ms}$
T_sw（切换耗时）暂停当前 TTS 播放、释放麦克风通道的时间。
$T_{\text{sw}} = 50\,\text{ms}$
T_rec（恢复耗时）把用户新指令嵌入原对话上下文，开始新一轮生成。
$T_{\text{rec}} = 200\,\text{ms}$

低延迟优化：把半秒压进眨眼之间

对唱体验要“像真人”，从你发声到 AI 回应的时间必须短到几乎感觉不到。KTV 里如果音箱延迟半秒，所有人的节奏都会乱掉。真人对话中，200~300 毫秒的反应时间让人觉得自然；超过 500 毫秒，就会感到明显的“卡顿”。

要把延迟压下来，先得知道时间都花在哪了。端到端延迟由四个环节叠加而成：语音识别（ASR）、大模型生成（LLM）、语音合成（TTS）和网络传输（Net）。这就像 KTV 里从你开口到听见 AI 和声，中间要经过话筒、调音台、处理器、功放、音箱五个设备，每个设备都花几十毫秒，加起来就很可观。

工程上最优先优化的是大模型生成耗时，因为它通常占比最大。手段包括模型压缩——量化把权重从 32 位压到 8 位，蒸馏用一个小模型模仿大模型的行为；推理加速——用 vLLM 这类高效推理引擎优化显存和注意力计算，让 token 出得更快；网络优化——把服务部署到离用户更近的边缘节点，减少每次往返的物理距离。

把四个环节分别压到最优，整体就能进入“眨眼级”的响应范围。这就像 KTV 的音响工程师给每个设备都做了优化，话筒灵敏、处理器快速、功放利落，最终你感受到的不是某个设备的快，而是整条对唱流水线的“同步感”。

T_{\text{e2e}} = T_{\text{ASR}} + T_{\text{LLM}} + T_{\text{TTS}} + T_{\text{net}}

端到端延迟是四个环节的串联加和。哪个环节最大，就优先优化哪个——就像 KTV 里最卡的那个设备决定整体节奏。

T_ASR（识别耗时）从音频输入到文本输出的时间，通常几十到一两百毫秒。
$T_{\text{ASR}} = 120\,\text{ms}$
T_LLM（生成耗时）大模型从收到文本到产生第一个回复 token 的时间，通常是最大头。
$T_{\text{LLM}} = 300\,\text{ms}$
T_TTS（合成耗时）把第一个文本 token 变成可播放音频的时间。
$T_{\text{TTS}} = 100\,\text{ms}$
T_net（网络耗时）数据在用户与服务端之间往返的时间。
$T_{\text{net}} = 80\,\text{ms}$

工程实践要点：把对唱机搬上云端

实验室里的对唱机原型很好用，但要搬到商业 KTV 的几百个包厢里，问题就来了：网络偶尔抖动怎么办？几十个人同时点歌会不会排队？麦克风没声音了怎么处理？这些工程问题，决定了产品能不能真正落地。

第一个问题是缓冲区管理。网络不是绝对稳定的，音频块偶尔会迟到。系统需要一个小缓冲区来吸收抖动，但又不能缓冲太多——否则延迟又回来了。这就像 KTV 点歌系统会预读几秒伴奏，太少会卡顿，太多会拖慢响应。第二个问题是并发控制。多个用户的交互请求同时到达，服务端要合理调度算力，给每个会话分配资源，紧急任务（如打断处理）优先执行。

第三个问题是错误处理。识别失败、网络断线、超时无响应，都要有优雅的回退策略。比如识别置信度过低时，AI 可以主动说“没听清，请再说一遍”，而不是固执地给出错误答案。最后是评测指标，工程团队要同时考察首包延迟、RTF、打断响应时间、鲁棒性等多个维度，而不能只看单一指标。整个流水线稳定后，帧间节奏由最慢环节决定：

把每个细节都调顺，AI 对唱机才能在任何包厢、任何网络条件下都保持流畅。这正是实时交互工程的魅力：用户感受到的“像真人”，背后是工程师对缓冲、并发、错误、指标的一次次精雕细琢。一个好的实时交互产品，不是某一个模型很厉害，而是整条流水线每个环节都恰到好处。

T_{\text{pipe}} = T_{\text{first}} + (N - 1) \times \max(T_{\text{ASR}}, T_{\text{LLM}}, T_{\text{TTS}})

第一个数据块从头走到尾花 T_first，之后的每一块都取决于最慢环节。就像 KTV 流水线出菜，最慢的那个厨师决定了整桌的上菜节奏。

T_first（首块耗时）第一块音频从输入到输出走完全流程的耗时，包含所有初始化开销。
$T_{\text{first}} = 250\,\text{ms}$
N（总块数）整段交互被切成的数据块数量。
$N = 20$
max(……)（最慢环节）ASR、LLM、TTS 三者中耗时最长的一个，决定稳定后的块间隔。
$\max(T_{\text{ASR}}, T_{\text{LLM}}, T_{\text{TTS}}) = T_{\text{LLM}} = 50\,\text{ms}$

AI 应用场景

实时语音助手（智能音箱）

阶段：语音交互全链路（流式 ASR → 大模型生成 → 流式 TTS）

解决的问题：传统音箱一句话要等两三秒才回应，用户不愿等待；流式处理让 AI 在用户话没说完时就开始预判，在话说完后 300 毫秒内开始说话，体验从“对讲机”变成“真人聊天”。

具体案例：用户对音箱说“帮我把空调调低，等等，再调高一点”。流式 ASR 在“等等”出现时就触发打断检测，AI 停止执行第一个指令，记住“空调”这个主题，转而执行新指令，整个过程一气呵成。

实时同声传译耳机

阶段：多语言实时翻译（流式 ASR → 大模型翻译 → 流式 TTS）

解决的问题：传统翻译设备等对方说完一整句才开始翻译，导致对话断断续续；流式翻译在发言人讲到一半时就给出译文，并随内容补充不断修正，让跨语言交流像母语对话一样流畅。

具体案例：国际会议中，发言人用英语说“We plan to launch next quarter, actually this month“。流式系统在”next quarter“处已显示译文”下个季度“，随后修正为”本月”，听众全程无感跟上。

视频直播实时字幕与互动

阶段：多模态内容理解与生成

解决的问题：直播字幕延迟大、观众互动响应慢，影响观看体验；流式 ASR 配合低延迟大模型，让字幕实时滚动、AI 助理即时回复观众评论。

具体案例：某教育直播间里，老师讲到一半被学生语音提问打断，AI 助理立刻识别问题并生成补充讲解，老师的授课节奏没有被破坏。

Python 演示

python50 行

import time  def stream_audio(sentence, chunk_size=3):    """把句子切成小块，模拟音频流式到达"""    for i in range(0, len(sentence), chunk_size):        yield sentence[i:i + chunk_size]        time.sleep(0.08)  class StreamingAssistant:    def __init__(self):        self.partial_text = ""        self.interrupted = False     def asr_feed(self, chunk):        self.partial_text += chunk        print("[ASR 中间结果] " + self.partial_text)     def detect_interrupt(self):        return "等等" in self.partial_text or "算了" in self.partial_text     def respond(self, text):        print("[TTS 流式播放] ", end="", flush=True)        for ch in text:            print(ch, end="", flush=True)            time.sleep(0.04)        print()  def main():    assistant = StreamingAssistant()    user_speech = "帮我订等等先查查价格"    print("=== 多模态实时交互流式管道演示 ===")    for chunk in stream_audio(user_speech):        assistant.asr_feed(chunk)        if assistant.detect_interrupt():            print("[打断检测] 用户说了'等等'，AI 立即让出话语权")            assistant.interrupted = True            break    if assistant.interrupted:        print("[上下文恢复] 保留'订票'意图，切换为'查价格'")        assistant.respond("好的，先为您查询价格")    else:        print("[识别完成] " + assistant.partial_text)        assistant.respond("好的，正在为您查询价格")  if __name__ == "__main__":    main()

目的：用生成器模拟音频分块到达，演示流式 ASR 的增量识别、中间结果更新，以及用户说话途中被打断时系统的抢占与上下文恢复。

def stream_audio(sentence, chunk_size=3)定义一个生成器，把一句话按块拆开，模拟真实音频流分块到达。
yield sentence[i:i + chunk_size]每次只交出一小块文本，调用方处理完再要下一块。
self.partial_text += chunk增量累积识别结果，最新文本一行行打印出来，模拟流式 ASR 的中间结果。
"等等" in self.partial_text在流式进行中实时检查打断词，不需要等整句话说完。
assistant.interrupted = True; break检测到打断立刻抢占控制权，停止当前处理。
time.sleep(0.08)模拟音频块真实到达的时间间隔，让执行节奏可见。

常见误区

误区我学了流式处理，把数据切成小块传，AI 的响应速度就会变快，延迟问题就解决了。

正解流式处理解决的是“不用等全部数据到齐”的问题，它消除了“等待收齐”的这段时间，让系统可以边收边干。但模型本身的推理速度、网络往返、合成速度这些环节的延迟并不因此减少。就像火锅边涮边吃解决的是“不用等锅全开”，但如果涮的肉本身要煮三分钟，你依然要等三分钟。

为何常见：因为流式给人的直观感受是“好像更快了”，容易把“不需要等待”误解为“处理速度本身变快了”。

误区用户一插话，我把 TTS 播放停掉就完事了，反正用户已经说了新指令。

正解真正的打断处理需要三步：检测、抢占、恢复。停止播放只是中间的“抢占”，更关键的是恢复——系统要记住打断前在做什么，把用户的新指令放回原有上下文里理解。比如用户说“改成经济舱”，AI 得记得刚才聊的是订机票。如果直接停掉什么都不管，对话就断了。

为何常见：因为从用户视角看，打断就是“对方闭嘴了”，看不到系统内部还要做上下文衔接。

误区我只要把大模型的生成速度优化到足够快，用户的实时对话体验就一定好。

正解端到端延迟是 ASR + LLM + TTS + 网络四段串联之和。模型推理只是其中一段，ASR 识别、TTS 合成、网络往返都可能成为瓶颈。就像 KTV 对唱系统里，光把调音台换快没用，话筒、功放、音箱任何一个环节慢，整条链路的延迟都很高。这也是为什么工程师要先拆解各环节耗时，再决定优化哪里。

为何常见：因为大模型是系统里最“显眼”的部分，人们自然把注意力放在它身上，忽略了其他环节的贡献。

面试题

Q1. 流式处理的核心思想是什么？

单选题 · easy

A.提高单次计算速度
B.数据边到边处理← 正确答案
C.扩大传输带宽
D.压缩单个数据块

答案：B。流式处理把数据切成小块，每收到一块就处理一块，不用等全部数据到齐。就像火锅边涮边吃，不用等整桌菜上齐。B 准确描述了这一思想，其余选项只是性能优化手段。

Q2. 流式语音识别中 VAD 的作用是什么？

单选题 · easy

A.压缩音频数据格式
B.识别说话人身份
C.检测人声开始结束← 正确答案
D.翻译语音为文本

答案：C。VAD（语音活动检测）是判断人声从什么时候开始、什么时候结束的模块，像 KTV 门口的服务员看到客人拿起话筒才通知后厨准备。它不负责识别内容，也不负责翻译，只管“有没有人在说话”。

Q3. 下列哪一项不是实时语音对话的完整环节？

单选题 · mid

A.语音识别捕获内容
B.大模型生成回复
C.音频格式转码保存← 正确答案
D.语音合成播放回复

答案：C。一次实时语音对话由 ASR 识别、LLM 生成、TTS 合成三个核心环节串成。音频格式转码保存不是对话本身的必要环节，属于离线处理，不影响用户体验。

Q4. 下列哪些属于低延迟优化的常见手段？

多选题 · hard

A.模型量化压缩体积← 正确答案
B.增大推理批量大小
C.模型剪枝减少计算← 正确答案
D.边缘节点就近接入← 正确答案

答案：ACD。量化和剪枝都直接减少计算量，边缘节点缩短网络距离，都能降低延迟。增大推理批量虽然提高吞吐，但会让单个请求排队等待，反而增加首包延迟，就像火锅店一次只涮很多肉反而让每桌等更久。

Q5. RTF（实时率）的正确含义是什么？

单选题 · mid

A.模型每秒生成的词数
B.处理耗时除以音频时长← 正确答案
C.网络报文往返时延
D.首个语音包到达耗时

答案：B。RTF 是处理一段音频花费的墙钟时间与音频本身时长之比。RTF = 0.3 意味着算 1 秒音频只需 0.3 秒，能跟上播放速度。它衡量的是处理速度，不是生成速度或网络时延。

Q6. barge-in（打断）机制的核心是什么？

单选题 · mid

A.提高系统扬声器音量
B.识别插话并交接控制← 正确答案
C.静默所有正在输出
D.降低麦克风输入增益

答案：B。打断机制的核心是实时监听用户是否插话，一旦检测到就暂停 AI 播报、把话语权交给用户。C 只说了一半，真正优雅的打断还要记住上下文，等待用户说完后自然接续。

Q7. 关于流式语音合成，下列说法正确的是？

多选题 · hard

A.首包延迟指首块音频生成耗时← 正确答案
B.RTF 是唯一体验指标
C.声码器逐帧合成支持流式← 正确答案
D.流式需等全句文本齐备

答案：AC。首包延迟决定用户多久听到第一个字，是流式 TTS 的关键指标；声码器把文本逐帧转成音频，才能实现边生成边播放。但 RTF 只是其中一个指标，还需要看首包、尾包、音质等。流式 TTS 恰恰不需要等全句文本齐备。

Q8. 端到端延迟各环节中，通常最值得优先优化的是哪一项？

单选题 · mid

A.语音识别模块耗时
B.大模型生成耗时← 正确答案
C.语音合成模块耗时
D.网络传输链路耗时

答案：B。大模型生成时间通常占端到端延迟的最大比例，从收到文本到吐出第一个 token 往往要几百毫秒。就像 KTV 流水线里最慢的厨师决定上菜节奏，先优化占比最大的环节收益最高。

Q9. 用户说“帮我订等等先查查价格”，实时系统应该怎么做？

单选题 · easy

A.忽略打断继续执行
B.停止任务记住修正← 正确答案
C.重新开始整个识别
D.静音等待用户重说

答案：B。系统检测到“等等”后应立即暂停“订票”动作，保留“订票”这个上下文，把当前意图切换为“查价格”。这就像合唱伙伴听到你切歌，停下原调但记住你们在唱同一首歌，等你新指令下来自然接上。

Q10. 关于流式 ASR 的中间结果，正确的说法是？

多选题 · extreme

A.中间结果可能被后续修正← 正确答案
B.中间结果越多显示越好
C.下游需平滑消费中间结果← 正确答案
D.中间结果等同最终结果

答案：AC。流式 ASR 每收一块音频就更新中间结果，后续数据会让结果更完整或修正错误，所以 A 对、D 错。但中间结果并非越多越好，太频繁的更新会让下游应用抖动，需要做平滑处理，所以 B 错、C 对。