流式识别与整段识别：什么时候该用哪个

2026-08-24

流式识别与整段识别的区别，不是”快”和”慢”的程度差异，而是”能不能边说边出字”的结构性差异。 前者在音频还没说完时就持续吐出中间结果，后者要拿到完整音频（或完整片段）才开始给答案。

这个差别一旦想清楚，很多纠结就没了：不是流式更先进，也不是整段更准，而是两条路各自放弃了一些东西，换回另一些。

一句话结论

需要边说边有反馈的场景选流式：实时对话、语音输入法、直播字幕。用户盯着屏幕等字出来，任何”憋着不出”都是体验灾难。
只在乎最终文稿质量的场景选整段：录音归档、会议纪要生成、内容审核。没人盯着中间过程，多等一会儿换来更规整的文本是划算的。
两者可以叠加：会议实时字幕用流式给现场看，散会后用整段重跑一遍出正式纪要。同一份音频跑两遍并不浪费，因为两次的产物用途不同。
选型的第一问不是”哪个准”，而是”结果会不会被改动”。如果你的下游拿到文本就立刻做不可逆的事（下单、转账、写库），那中间结果就不能直接用。

差别的根子：模型能看到多少上下文

整段识别在解码任何一个字的时候，理论上可以参考它后面的音频。人也是这样理解语言的——“我要去银行”里的”银行”，靠后半句的”取钱”还是”排队”才能确定读音与词义；同音词、断句、专名边界都依赖后文。

流式识别为了立刻出字，主动放弃了后文信息，只能基于”到目前为止听到的”做判断。这不是工程实现不够好，而是任务定义本身的约束：你要求它在第 3 秒就给出第 3 秒的字，它就不可能用到第 5 秒的信息。

所以在同等模型能力、同等音频质量下，整段识别更容易做对，这是信息量决定的，不是谁调优得更好。

建模范式决定了能不能流式

端到端 ASR 的三种主流范式，对流式的支持是天生的差异，不是配置项：

范式	流式能力	原因
CTC	天然适合流式	逐帧输出，假设输出标签间条件独立，不需要回看整段
AED（注意力编码器-解码器）	原生不适合流式	解码时要看整段编码结果，得先有”全部”才能开始
RNN-T（Transducer）	流式的主流选择	在 CTC 基础上加预测网络与联合网络，既能流式又能建模输出间依赖

这张表最值得记住的是为什么 RNN-T 成了主流：CTC 能流式但不建模输出依赖，结果容易缺少语言层面的连贯性；AED 建模能力强但要等整段。RNN-T 补上了输出依赖，又保持逐步吐字，正好卡在两者之间。

需要说明的是，AED 的”不适合流式”指的是原生结构。限制注意力范围、分块处理等手段可以让它近似流式，但那是额外加的约束——看得越少，越接近 CTC 的处境。

一个可以点名的例子：Whisper 的原生转写路径

OpenAI 的 Whisper（MIT）README 里对 transcribe() 的描述写得很明确：该方法读入整个文件，用一个 30 秒的滑动窗口处理音频，对每个窗口做自回归的 seq2seq 预测；示例代码也会把音频 pad/trim 到 30 秒。

据此可以下的判断是：它的原生转写路径属于”整段读入 + 定长窗口切分”，不是逐帧流式。这是结构描述而非性能评价，只说明它的设计取向落在整段这一侧。

对照另一侧，FunASR（MIT）在 README 里自述支持 offline、streaming、edge 三种部署形态，其对比表中 Streaming 一行标注为 WebSocket（Paraformer）——它把流式作为一种明确提供的部署形态。

两个项目摆在一起，说明的不是谁强谁弱，而是**“是否原生流式”是选型时必须单独确认的能力项**，不能默认所有 ASR 都能流式。

流式的隐藏成本，选之前要认

结果会被修订

流式的中间结果是可能被推翻的。先出的字，在后文到达后可能被改写成别的字——这在体验上是正常的（用户看到字在跳动，最终稳定下来），但在工程上是陷阱。

如果下游把中间结果当最终结果用就会出问题：把还没稳定的转写送去做意图识别、直接触发业务动作、或写进不可回滚的日志，都会因后续修订而不一致。

正确做法是区分两种结果：中间结果只用于显示，只有标记为”已确定”的那部分才能进入业务链路。

标点必须等后文

标点恢复通常是独立的后处理任务，按逐 token 序列标注的方式，为每个字预测其后应跟的标点。问题在于，一个字后面跟句号还是逗号，取决于后面还说不说、说什么。

流式场景下这构成一个硬矛盾：标点要等后文，流式要立刻输出。常见折中是先输出无标点结果，后续再修订补上。所以流式产物在标点上天然不如整段规整，把流式结果直接当正式文稿用之前，要先接受这一点。

RTF 好看，不等于体验好

这是流式选型里最常见的误判。

RTF = 处理耗时 / 音频时长，小于 1 表示比实时快。它衡量的是吞吐效率，回答”一台机器能扛多少路”。

但流式体验取决于首字延迟——用户开口到屏幕上出现第一个字的时间。一个系统完全可能 RTF 很漂亮而首字延迟很难受：它攒够一个足够长的窗口才开始算，算得飞快，但用户已经干等了一截。

RTF 是给容量规划看的，首字延迟是给用户体验看的。 评估流式方案时，两个都要量，别用前者替代后者。

另外，流式请求是长连接，一路连接在整通对话期间都占着资源，容量按并发路数算，不是按每秒请求数算。

分场景选型表

你的场景	选哪个	原因
实时对话（语音助手、AI 客服接听）	流式	延迟直接叠加进对话链路，用户对沉默极其敏感；结果修订可接受，因为下游是大模型，本身有容错
会议实时字幕	流式为主，整段补一份	现场必须边说边显示；散会后用整段重跑生成正式纪要，标点和专名都更规整
录音转写归档	整段	没有实时观众，模型可以用完整上下文；一次做对比反复修订更省事
语音输入法	流式	用户边说边看反馈才有掌控感；输入法本来就允许上屏后修改，与流式的修订特性天然契合
客服质检	整段	通话已结束，音频是完整文件；质检要的准确文本、说话人分轨、时间戳都受益于完整上下文

选型时的自检顺序：①有没有人在等着看字？②结果被改动能不能接受？③音频是流还是文件？ 三问答完，选哪个基本就定了。

常见问题

问：流式识别一定比整段识别不准吗？

不能这么绝对。准确率还取决于模型本身、训练数据、音频质量。能确定的是：同一个模型能力档次下，看得到后文的一方在信息上更占优。把它理解为”流式为了即时性付出了信息代价”，比理解为”流式模型比较差”更准确。

问：我能不能拿流式方案跑离线文件转写？

技术上可以，把文件当成一个流喂进去就行。但你会白白损失后文信息，得到一份本可以更好的转写。既然是文件，就没有理由主动放弃上下文。

问：既然流式会修订，那”最终结果”怎么判定？

看接口的语义。流式接口通常会区分中间结果与确定结果（有的按句子边界确定，有的按静音段确定）。这个标志位是流式接入的核心细节，比延迟数字重要得多，接入前必须在文档里确认清楚。