英文题目：X2Streaming-ASR: wait when uncertain, emit when ready for streaming ASR

标签：#语音识别 | #强化学习 | #流式处理 | #语音

评分：7.5/10 | 创新 1.6/2 | 技术严谨 1.2/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 1.2/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1.2/1.5

👥 作者与机构

  • Zhiwei Lin：机构信息未在 arXiv HTML 中可靠披露
  • Kaiqi Fu：机构信息未在 arXiv HTML 中可靠披露
  • Rime Wen：机构信息未在 arXiv HTML 中可靠披露
  • Zehan Liu：机构信息未在 arXiv HTML 中可靠披露
  • Shawn Qin：机构信息未在 arXiv HTML 中可靠披露
  • Roy Gan：机构信息未在 arXiv HTML 中可靠披露
  • Hao Wang：机构信息未在 arXiv HTML 中可靠披露
  • Qian Wang：机构信息未在 arXiv HTML 中可靠披露

📌 核心摘要

流式自动语音识别输入为持续到达的音频，输出为逐字符一次性不可修改的部分转写，难点在于每个字符消歧所需的未来上下文不同，统一延迟难以兼顾准确率与提交速度。X2Streaming-ASR将任务拆为提交时机与提交内容，第一阶段训练增量识别能力，仅识别声学已结束的内容，并将其作为后续探测器与初始化权重。第二阶段用第一阶段模型自探测每个字符的最早正确提交轨迹，再以联合监督暖启动识别能力与初始提交策略，但不把探测时间视为真值。第三阶段冻结编码器并用组相对策略优化精炼提交策略，按字符对齐分配误差与等待代价，使等待后做对与提前做对的行为直接获得奖励。与固定分块或全局前视相比，该机制实现位置相关的提交决策，在不确定位置继续等待而在证据充分处立即提交，而非整体平移所有提交点。在5个中文测试集评测设置下，X2Streaming-ASR的延迟指标相对Zipformer与Paraformer在线版从409–585ms降至27–84ms，并在AISHELL-1上以1.96%错误率取得所评流式系统最优。该结论适用边界受限于强制对齐端点定义的延迟口径与中文朗读及会议语料验证，尚未验证其他语种与强噪声远场交互中的泛化。原文未披露训练、推理或部署成本。

🔗 开源与复现资源

本次未形成可展示的已核验资源记录，开放状态尚未核实。

可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，输出是什么，为什么延迟要从声学边界算起？

输入是 16 千赫采样的连续波形，按 80 毫秒 1 帧变成对数梅尔谱并映射为音频标记，帧率 12.5 赫。输出是逐字提交的中文文本，每个字只提交 1 次，不允许先给不稳定假设再修改。

目标是同时做到两件事：转写正确，以及在声学结束后尽快提交。论文把延迟定义为剩余等待，即实际提交时间减去强制对齐给出的字符结束时间。这个定义对初学者很关键：它不是从句子开始计时，也不是端到端响应时间，而是每个字在声音已经结束之后又被多留了多久。

下游的级联语音助手和轮次决策需要用流式前缀尽早启动后续服务，给错了会误触发，给晚了会拖慢启动，所以准确与提交延迟必须联合看。固定块、预读和全局延迟规定每次看多少未来信息，另一类做法在训练时鼓励早吐或把提交时刻拉向对齐边界。

论文认为这两类都没有回答每个位置该多用多少未来上下文。同音字在当前帧可能完全相同，必须多听一两个字才能确定，而功能词可能听清即定。如果用一个全局旋钮，调晚则所有字都被拖慢，调早则所有字共担风险。

固定延迟 × 位置相关等待： 固定延迟对所有输出位置使用同一个全局等待量，分工是简化解码配置；位置相关等待允许每个字符根据歧义程度使用不同等待量，分工是把额外上下文只花在难字上。搭配理由是难易不均时全局旋钮要么全拖慢、要么全冒险，组合意义在于用逐位置决策替代全局折中。

三条已有路线各解决了什么，又缺了哪一块？

第一条路线是全局配置流式识别，例如固定块解码、前视或延迟。它的输入条件相同，都是增量音频加有限未来窗，监督方式是常规识别损失，运行阶段是单遍硬提交。它的优点是实现简单可控，但等待量不随历史上下文和当前声学变化。

第二条路线是移动训练时的提交时间，例如鼓励更早输出，或把提交拉向对齐边界。它改变了损失对时间的偏好，但仍然是位置无关的偏好。前者在难字上可能过早，后者在难字上不允许额外等待。

第三条路线是先给部分假设再修正，用修改换取表面延迟降低。论文明确把它排除在比较目标之外，因为它不是单遍硬提交，修正前的错误仍会污染下游。按同输入、同目标、同监督、同运行阶段对照，3 类与本文的差异不在编码器强弱，而在是否允许每个字符有自己的等待决策。

论文的判断是内容生成已有监督学习较好解决，难的是提交时机。提交时机的金标准不存在，对齐结束时间只是代理变量，教师探测的最早正确时刻也继承教师语言先验和探测协议偏差。用交叉熵拟合这些时刻会惩罚两种有益偏离：为写对而稍多等，以及比标签更早写对。

单遍硬提交下，模型每一步要回答哪两个问题？

在每个音频帧，模型先回答等还是交。如果选等待，则不写回任何符号，继续读下 1 帧音频。如果选提交，则把一个提交标记写回输入作为识别起点，自回归生成文本直到结束符，再回到监听状态，结束符本身不写回输入。

这里的例子是教学例子：假设已听到上字的前半段，模型若此时提交可能把上与尚混淆，多等 80 毫秒听到海的声母后，不确定性下降，再提交就更稳。这个例子不附带论文数值，只说明等待的价值是位置相关的。

形式上，历史交织序列包含已到音频、已认文本和特殊符号，当前音频标记作为新增输入，二元决策决定状态转移。关键约束是硬提交：同一字符没有第二次修改机会。因此策略必须在不确定时保留等待选项，在证据充分时尽快触发，避免把整句拖慢。

整体架构如何让听和解码并行起来？

模型基于因果音频编码器、适配器和解码器语言模型。音频波形先变谱图再映射到文本嵌入空间的连续音频标记，与文本标记交织。语言模型在监听与解码两种状态间交替。

监听时读历史序列加当前音频标记并做二元决策，解码时停止读新音频，专注生成当前段文本。论文强调一个实现细节：语言模型在解码上一段音频时，因果音频编码器可同时编码当前音频，两者异步进行。这意味着等待不只是空转，而是在为后续决策积累编码好的未来上下文。

与所基于的实时模型的区别在于不再使用全局延迟作为条件输入，也不再把文本与音频标记绑在同一序列位置做固定偏移，而是由模型自适应决定等待或提交。这是从全局延迟到位置相关提交的结构变化。

何时提交 × 提交什么： 何时提交负责在每一音频帧决定等待还是提交，解决证据是否充分的问题；提交什么负责在触发提交后自回归生成文本，解决内容正确的问题。二者搭配的原因是监督学习已能较好解决内容生成，但提交时机依赖声学和历史上下文且没有唯一金标准，因此论文把前者交给强化策略、后者保留生成建模，组合后实现不确定则等、证据足则发。

下面先看架构图中时间步与标记流的对应关系，再回到文字解释状态转移。本图展示顶部自回归标记流、中部语言模型输入与适配器编码器、底部按 80 毫秒分块的音频 3 层如何对齐，重点是连续等待后由提交触发文本生成的时刻，时间范围覆盖单个 utterance 的多个提交片段。

看图路径： 1. 沿底部音频条从左向右看每 80 毫秒一块的因果编码，确认已编码块与待编码块的灰度区别；2. 对照顶部自回归流中连续等待后出现提交的时刻，观察提交如何触发下方的文本生成；3. 检查中间适配器与因果音频编码器两层，确认语言模型解码上一段时编码器可并行编码当前音频

原论文 Figure 1：The X2Streaming-ASR model architecture alternates between listen and decode states.

论文图 1。原论文 Figure 1:：“The X2Streaming-ASR model architecture alternates between listen and decode states.”。

从像素可见，顶部在 t1 到 t4 连续给出 4 个等待标记，t5 给出提交标记，随后生成汉字与结束符。中部对应位置把提交标记与已生成字写回输入，而音频标记保持连续。底部汉字音频块为已编码橙色，后续块为待编码灰色。图例明确区分等待、提交触发解码、文本标记、结束符与未来音频，说明提交片段的划分方式：1 次提交连同其前面连续等待自成一段，这正是后续强化做信用分配的单元。

监听决策与触发解码具体算什么？

先沿一个样本走完输入到输出。假设 t 时刻已累积音频标记与已认文本，模型读入当前音频标记，输出等待或提交的分布并采样。若为等待，输入序列不变地推进到下 1 帧。

若为提交，则把提交符号写回，作为生成第一个文本标记的条件，逐个生成直到结束符。生成结束后回到监听，继续处理下一段音频。这种设计把识别切成多个提交片段，每个片段对应 1 次触发及其前面的等待。

二元决策的计算目标是给定历史与当前音频时等待或提交的概率，触发后的计算目标是给定历史、当前音频与提交标记时下一个文本标记的概率。原文实现用语言模型直接建模这两个分布，音频标记帧率为 80 毫秒，交织输入保留时序。

决策分布的形式如下，符号含义在段中已交代：

\[c_{t}\sim p_{\theta}(c|z^{(t)},a_{t}),\quad c\in\{w,e\}.\]

该式表示在历史交织序列与当前音频条件下采样等待或提交，其中等待不写回、提交写回并转入自回归生成。理解此式后，后续训练阶段一与阶段二的掩码与标注、阶段三的采样轨迹划分才有落点。

三阶段如何分工：先学会认，再学会何时交？

第一阶段只训练流式识别能力，不学提交策略。做法是用强制对齐得到每字起止时间，把对齐字符序列随机切成长度 1 到 6 的连续块，每块提交时间为块内末字结束时间加 0 毫秒、80 毫秒或 160 毫秒，若有下一字则切点不超过其时长前半，用公式截断防止越界。损失在等待与提交位置被掩掉，只训练识别能力。

得到的第一阶段模型既是第二阶段的初始权重，也是探测器。训练时还以 0.20 比例混入离线全文识别，使同一模型保留离线能力。第二阶段用第一阶段模型逐句探测每个字符的提交时间。探测从首字结束时间开始，在当前时间贪心解码增量音频，取与解码结果匹配的最长参考前缀，这些字共享当前时间为提交时间。

对下一个失配字，若当前时间早于其结束时间则下一探从其结束时间开始，否则以 80 毫秒步进且永不回退。若探完仍得不到完整参考的提交时间，或任一字等待超过 640 毫秒，则丢弃该句，因为过长等待会教模型一直等待而不触发提交。第二阶段从第一阶段权重初始化，用探测时间做下一标记监督，联合训练识别与初始提交策略，但明确不把探测时间当真值。

探测提交时间 × 组相对策略优化： 探测提交时间用第一阶段模型贪心解码增量音频得到每个字符的可行提交时刻，分工是给提交策略一个热启动初值；组相对策略优化对同一音频采样多条等待或提交轨迹并在同字符上比较优劣，分工是直接优化错误数与延迟的真实目标。二者搭配是因为探测时间继承教师先验且不完美，只能做初值而不能当真值，最终靠强化修正。

第三阶段用组相对策略优化精修提交策略。每句采样 8 条等待或提交轨迹，采样温度为 1.4，动作是每帧的等待或提交，提交后贪心解码到结束符。关键是信用单元：轨迹自然切成提交片段，但优势不按句广播，而是按字符组内比较后回传到产生或漏掉该字符的片段。

插入错误无参考字符，记在其产生片段并在组内做零和修正。阶段三冻结编码器与适配器，只用低秩适配微调语言模型。超参数为延迟权重 0.3，截断 2000 毫秒，裁剪系数 0.2。

提交片段 × 句子级奖励： 提交片段指 1 次提交动作连同其前面连续等待构成的记分单元，分工是定位哪个决策影响了哪个字符；句子级奖励把整句得分广播到所有帧，分工是简化优化。论文指出后者会把有用等待和多余等待同等加强，导致全句拖延，因此用前者做信用分配，把同字符组内比较得到的优势回传到对应片段。

字符得分对正确对齐按归一化延迟给负奖励，对替换或删除给固定负值，延迟经截断上限归一化到 0 到 1 之间，错误优先于延迟：

\[s_{k,j}=\begin{cases}-\lambda\,d_{k,j},&\text{correct alignment},\\ -1,&\text{substitution or deletion}.\end{cases}\]

组内优势是同字符得分减去组均值，使同一难字上的等待与早交可比：

\[A_{k,j}=s_{k,j}-\bar{s}_{j},\qquad\bar{s}_{j}=\frac{1}{K}\sum_{k=1}^{K}s_{k,j}.\]

片段优势是其对齐字符优势之和加插入惩罚，段内每步共享：

\[\hat{A}_{k,m}=\sum_{j\in\mathcal{J}_{k,m}}A_{k,j}+A^{\mathrm{ins}}_{k,m}.\]

最终用裁剪目标约束新旧策略比值附近更新，加强或抑制对应等待或提交动作：

\[\mathcal{L}=\mathbb{E}\Biggl[\min\Bigl(\rho_{t}\hat{A}_{k,m(t)},\;\mathrm{clip}(\rho_{t},1-\varepsilon,1+\varepsilon)\,\hat{A}_{k,m(t)}\Bigr)\Biggr],\]

数据、基线、指标与超参数如何保证可比？

训练数据为第一阶段用 AISHELL-1、AISHELL-2、AISHELL-3、会议数据与 WenetSpeech。第二阶段因全量 WenetSpeech 标注成本过高，只探测 AISHELL 三集与 WenetSpeech 的部分子集。第三阶段用相同数据池，使监督与强化提交策略在同一标注池上比较。

第三阶段奖励只需要参考字符与其结束时间，不需要额外提交时间标签。评测在 AISHELL 三集测试集与 WenetSpeech 会议和网络测试集上进行，每句用强制对齐器给出字符结束时间，剩余等待为提交时间减结束时间，报告均值与 95 分位及字符错误率。

基线包括开源流式配置下的 Zipformer 与 Paraformer 在线版，非开源的 MoCha 与 Uni-ASR 只引用论文字符错误率，无法测剩余等待延迟，其中 Uni-ASR 流式取 1000 毫秒块、束宽 3 的结果。论文说明 X2Streaming 与 Zipformer 用同一检查点做流式与离线识别，Paraformer 离线与流式用各自版本对应参数。

声学边界 × 剩余等待： 声学边界指强制对齐给出的每个字符结束时间，分工是提供延迟零点；剩余等待指实际提交时间减去该结束时间，分工是度量模型在声学结束后又多等了多久。二者组合得到论文主延迟指标，强调即使声学已结束，语言歧义仍可能需要额外上下文。

资源状态方面，本次未发现来源绑定且完成超文本传输安全协议状态验证的资源，不得声称代码、模型或数据已公开。复现时应以论文文字与表格为准，先重建对齐与延迟计算，再谈策略。

主结果：在更低延迟下错误率发生了什么？

比较问题是：在单遍硬提交与字符级剩余等待口径下，新方法相对可运行流式基线是否同时降低延迟并保持错误率。公平条件是同一测试集、同一强制对齐零点、同一字符错误率与均值及 95 分位延迟。指标方向是字符错误率越低越好，平均延迟越低越好。

下表覆盖 3 个普通话测试集，保留流式与离线字符错误率及流式延迟，时间范围为单句字符级平均，延迟零点为强制对齐字符结束时间。

Test setCERMean lat.P95CERCERMean lat.
AISHELL-11.96272400.88⋆1.97472
AISHELL-24.93542403.524.16450
AISHELL-32.68442401.61⋆2.94464

上表显示新方法在三集上的平均字符提交延迟为数十毫秒量级，而基线平均字符提交延迟为数百毫秒量级。95 分位字符提交延迟也从接近 1000 毫秒降到 240 毫秒。在 AISHELL-1 测试集和 AISHELL-3 测试集上，新方法流式字符错误率优于参评流式基线，且离线字符错误率也最优，说明其识别上限在这些集上并未拖后腿。

在 AISHELL-2 测试集上，新方法流式字符错误率为 4.93%，高于 Zipformer 流式字符错误率 4.16% 与 Paraformer 流式字符错误率 3.91%，论文将其归因于自身离线字符错误率 3.52% 弱于对应基线离线能力，而非提交策略失效。未胜出项必须保留：AISHELL-2 与 WenetSpeech 网络集上 Uni-ASR 最优，其次为 Paraformer 与 Zipformer。

下面看包含 WenetSpeech 两集的对照，重点是困难场景下延迟与错误率的代价。比较问题仍是相同延迟口径下错误率是否可比，公平条件为同一会议与网络测试集、同一对齐零点与同一聚合方式。

Test setCERMean lat.P95CERMean lat.P95
WenetSpeech Meeting10.736132010.05582880
WenetSpeech Net9.92843208.54563880

该表显示在会议测试集与网络测试集这种更难的集上，新方法平均字符提交延迟仍为 61 毫秒与 84 毫秒，95 分位字符提交延迟为 320 毫秒，远低于基线 700 毫秒到 880 毫秒的 95 分位字符提交延迟。但流式字符错误率分别为 10.73% 与 9.92%，未能超过离线更强的基线。

论文解释为离线结果代表充分上下文下的能力上限，流式因缺完整音频而退化。当上限本身弱于基线时，流式结果也难以反超。支持的判断是延迟降低约一个数量级成立，有限解释是错误率最优只在部分集成立，待验证的是在更强基座上是否能同时保持两项优势。

为直观比较延迟与错误率的权衡，下面看同一检查点下强制延迟曲线与学习到的提交策略的位置。本图横轴为平均延迟毫秒，纵轴为字符错误率百分比，包含学习到的流式点、阶段 2 流式点、句子级奖励点、强制延迟折线与离线虚线下界。

看图路径： 1. 先看横轴平均延迟毫秒与纵轴字符错误率百分比，确认右为慢、上为差；2. 找到左下角星形自然流式点与左上方折线强制延迟点，比较相同延迟下谁的错误率更低；3. 观察右下方句子级奖励点，确认其错误率低但延迟大幅右移

原论文 Figure 2：AISHELL-1 CER vs. mean character-level latency.

论文图 2。原论文 Figure 2:：“AISHELL-1 CER vs. mean character-level latency.”。

从像素可见，学习到的流式星形点位于左下方低延迟低错误区。强制延迟折线从对齐结束时刻附近字符错误率 6.90% 的高错误点，经加 80 毫秒后字符错误率 3.40% 的点与加 160 毫秒后字符错误率 3.84% 的点形成短折线，其字符错误率仍高于自然流式星形点字符错误率 1.96%。句子级奖励三角形点位于右下方，字符错误率接近离线虚线但横轴大幅右移至约 400 毫秒。阶段 2 流式点靠近折线起点，说明监督热启动偏向全局偏早。核对纵轴为原始错误率而非改善量，向下为好，横轴向右为慢。

是学到了位置相关等待，还是全局早交或全局拖延？

要回答的反证问题是：若把提交时刻强制为对齐结束加固定偏移，同样延迟下能否达到同样错误率。论文用同一阶段三检查点做强制解码：对尚未识别的参考字符，在结束时间加固定偏移时开始贪心解码，注意 1 次提交可能覆盖后续字，后续字不再单独加偏移。指标仍为字符错误率与平均延迟及 95 分位延迟。

下表整理同一检查点在 AISHELL-1 测试集上的强制延迟与自然流式对照，表头保留原文单位写法，数据格保留原文裸值写法，延迟零点同为强制对齐结束时间。

推理条件CER(%)平均延迟(ms)P95 ms
强制对齐结束时刻6.900.680
强制加 80 ms3.4088160
强制加 160 ms3.84147240
自然流式1.9627240

上表数字来自原文连续句的逐字证据，条件为同一检查点与同一 AISHELL-1 测试集。表后解释是：立即在边界提交最快但字符错误率高达 6.90%，增加全局等待至 80 ms 后字符错误率降至 3.40%，而延迟与错误率仍差于自然流式的字符错误率 1.96% 与平均延迟 27 ms。

加到 160 ms 后字符错误率反而回升到 3.84% 且平均延迟升到 147 ms，论文归因于更长等待把下一字带入解码，却缺后续声学信息。这支持新方法不在固定延迟曲线上取折中，而是难则等多听、易则早交。阶段 2 模型落在折线附近、接近强制边界，说明监督拟合探测时间倾向全局偏早。

加内容散度约束的阶段三变体可防止识别能力漂移，但提交策略优化才是错误率与延迟改善的主要来源。句子级奖励版本字符错误率可到 1.38% 但平均延迟达 383 ms、95 分位延迟为 1120 ms，属于全局等待换正确，不可当作可部署收益。

哪些边界尚未评测，哪些推论不能做？

论文直接报告的是中文普通话五集上的字符级结果，未报告英文或其它语言、真实噪声与重叠语音下的表现，也未测量误触发下游服务的代价、实际端到端响应时间与计算开销。训练资源、推理帧率与每步延迟是分别讨论的对象，不能从平均剩余等待数十毫秒直接推出系统级实时性。

95 分位在普通话集为 240 毫秒、在 WenetSpeech 集为 320 毫秒，说明极端情况下仍有数百毫秒等待，总体趋势不等于每字都快。相关性不等于因果：离线与流式错误率正相关支持上限决定流式天花板，但不能证明提高离线能力必然等量改善流式延迟。

缺失证据不是技术错误，例如未给出统计显著性、未报告不同温度与采样数下的方差，复现时应补测。原文表头与正文在个别延迟数字的小数表述上有排版粘连，解读时以表格矩阵与连续原句共同覆盖的数值与单位为准，不自行四舍五入或拆分单位。

若要复述与复现，先重建哪三条管线？

第一条是数据与对齐管线：按论文划分准备 AISHELL 三集与 WenetSpeech 会议和网络测试，用同一强制对齐器给出每字结束时间，延迟按提交减结束计算，聚合报告均值与 95 分位。注意切块公式的截断项防止提交时刻越过下一字前半，阶段一掩掉等待与提交位置损失并以 0.20 比例混入离线数据。

第二条是探测与热启动管线：从首字结束时间开始贪心解码，匹配最长参考前缀共享提交时间，失配时按结束时间或 80 毫秒步进，丢弃不完整或等待超 640 毫秒的句子，再做下一标记监督。第三条是强化管线：每句采样 8 条轨迹，温度为 1.4，延迟权重为 0.3，截断为 2000 毫秒，裁剪系数为 0.2，冻结编码器与适配器、只微调语言模型，按字符组内优势回传到提交片段。

核对要点是每个数字同时核对数据集、基线、阶段、指标、单位与聚合对象。百分点与相对百分比不同，不同指标差值不混放。比较必须保留可运行策略，引用论文的非开源结果另行标明，不代替可部署收益。

何时值得尝试这种按字等待的流式方案？

当任务是单遍硬提交、下游对错误前缀敏感、且同音或上下文相关歧义集中在少数位置时，值得尝试把提交时机做成逐位置决策，而不是调大全局延迟。复现先做对齐与延迟口径，再做阶段一识别基线，确认离线上限后再引入探测热启动与片段级强化，避免一开始就用句子级奖励导致全局拖延。

若基座识别上限弱于基线，应先补强基座或离线能力，否则流式错误率难以反超。还需补的验证包括更难声学条件下的 95 分位、实际解码开销与端到端收益，以及多语言字符或词粒度的适用性。论文的特有误解在于把对齐边界当作唯一正确时刻，实际上边界只是零点，难字需要额外上下文，强化目标中的错误优先与延迟惩罚正是为此保留等待空间。

📎 论文与评分元数据

排名：前25% | 文档类型：方法研究 | arXiv 原文

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

  • 评分规则：type-aware-v1

  • 评分模型：muse-spark-1.3-contributor

  • 评分请求协议：openai_responses

← 返回 2026-09-10 语音/音乐/音频论文速递