本文是论文Turning Whisper into Real-Time Transcription System的翻译。
目录
Abstract
这篇文章介绍了最近一种先进的多语言语音识别和翻译模型Whisper，然而，它并非设计用于实时转录。在本文中，我们在Whisper基础上构建了Whisper-Streaming，这是一种实时语音转录和翻译的实现，类似于Whisper模型。Whisper-Streaming采用本地协议策略与自适应延迟，以实现流式转录。我们展示了Whisper-Streaming在未分割的长篇语音转录测试集上实现了高质量和3.3秒的延迟，并展示了它作为多语言会议现场转录服务中组件的稳健性和实用性。
1 Introduction
Whisper（Radford等人，2022）是最新的一种自动语音识别（ASR）系统，可以处理97种语言的语音，并将96种语言翻译成英语。Whisper模型在MIT许可下公开可用。然而，目前公开的Whisper推理实现通常只允许对完全可用的音频文档进行离线处理，没有任何处理时间限制。
实时流式模式在某些情况下非常有用，例如实时字幕。这意味着源语音音频必须在录制时进行处理。转录或翻译必须以短的附加延迟交付，例如在2秒内。有一些Whisper的流式实现，但它们的方法相当简单，例如首先录制30秒的音频片段，然后再处理它。这些方法的延迟较大，并且在片段边界上的质量较低，因为简单的内容无关的分割可能会将一个词拆分在中间。
在这项工作中，我们使用简单而有效的LocalAgreement（Liu等人，2020）算法实现、评估和展示了Whisper的实时(simultaneous)流式模式。LocalAgreement是一种特定的流式策略，可用于将任何完整序列到完整序列模型转换为实时流式模式。它被用于在IWSLT 2022同时语音翻译共享任务中获胜的CUNI-KIT系统（Polák等人，2022）。我们称我们的实现为Whisper-Streaming，尽管它适用于任何具有类似Whisper的API的模型。根据我们的评估，它在欧洲议会演讲测试集ESIC（Macháček等人，2021）上对英语ASR平均达到3.3秒的延迟，当运行在快速硬件处理单元NVIDIA A40 GPU上时。我们还对德语和捷克语的ASR进行了测试，并呈现了结果和最佳参数的建议。
这项工作的贡献是实现、评估和展示Whisper-Streaming。考虑到Whisper-Streaming可以迅速而轻松地打包成产品，我们希望确保最新的科学结果，例如用于同时模式的算法，可以被工业研究人员和工程师获取并使用。此外，我们希望可靠地评估我们实现的性能并将结果与研究社区分享，以进一步推动具有现实用例的实时转录解决方案的研究和开发。我们期望我们的结果可以作为未来比较的强有力基线。
我们将Whisper-Streaming与演示视频一同公开发布。
2 Background
在这一部分，我们描述了我们工作的后端组件的背景。
Whisper（Radford等人，2022）是一种用于语音转文本转录和翻译的Transformer模型，经过大量多语言数据的训练。我们使用“large-v2”模型，因为它在所有Whisper模型尺寸选项中达到了最高的质量。由于原始的Whisper后端相当慢，我们使用了更快的Whisper重新实现faster-whisper，使用了CTranslate2，这是一个用于Transformer模型的快速推理引擎。据作者报道，它的速度大约是标准实现的四倍。我们将其与16位浮点精度一起使用。
虽然我们主要使用Whisper，但我们实现中的底层模型可以轻松地替换为任何其他语音转文本转录或翻译模型（例如MMS，Pratap等人，2023），只要它产生单词级别的时间戳和标点符号。
流式处理假设有一个模型M，它将一个源序列$c_1, …, c_n$处理成一个目标序列$t_1, …, t_m$，给定一个可以用于句间连贯性的先前目标s。流式处理涉及连续接收源序列，一次接收一个块，并同时产生目标。一个流式策略P在时间T预测目标段$t_T$，如\(t_T := P_M (c_{i<T} \vert s, t_{j<T})\)。它在可用的源块$c_{i<T}$上操作模型M，先前的序列目标s和先前的目标段$t_{j<T}$。每当有新的源段可用时，策略就会触发。可以发出空的目标段，例如在等待上下文时。该策略旨在最小化延迟并最大化目标质量。
流式处理最初是为了同时翻译（Ma等人，2019）而提出的，但它适用于任何序列到序列的任务，包括ASR。Dong等人（2022）对流式语音翻译进行了总结。
LocalAgreement（Liu等人，2020）是一种流式策略，输出模型在n个连续源块上的最长公共前缀，或者在可用的块少于n时输出空段。根据IWSLT 2022共享任务关于同时翻译的信息，CUNI-KIT系统将LocalAgreement与其他策略（hold-n和wait-k）进行了比较，这些策略具有不同的块大小。他们发现，n = 2的LocalAgreement是最有效的策略。因此，我们使用LocalAgreement-2来识别稳定的目标段落。
3 Whisper-Streaming
我们描述了Whisper-Streaming的核心组件和内部工作原理。它包括更新循环、音频缓冲区、跳过音频缓冲区中已确认的输出、修剪缓冲区、连接句间上下文，以及可选的语音活动检测。
图1 处理三个连续更新的示例。黄色高亮文本是“提示”，表示要遵循的先前上下文。黑色边框矩形是音频缓冲区，里面的文本是Whisper从该声音段生成的转录文本。蓝色垂直线是时间戳，将缓冲区分为两部分，左边是先前确认的部分，右边是未确认的部分。LocalAgreement-2策略，或搜索最长公共前缀，应用于未确认（右侧）部分的两个连续更新。最长公共前缀用绿色突出显示，绿色下划线突出显示新确认的输出，而绿色虚线下划线表示先前和随后确认的输出。灰色下划线示范了在被忽略的确认部分的更新。
更新循环 Whisper-Streaming的主要部分是一个程序，利用循环接收源音频块并触发流式策略更新。参数MinChunkSize控制延迟和质量，并确定每次迭代处理的最小持续时间。如果更新计算超过MinChunkSize，下一个更新将立即在累积的音频输入上执行。该参数影响延迟和质量。
音频缓冲区 Whisper被训练用于处理长达30秒且包含一个完整句子的序列。它提供标点和单词级别的时间戳。这个过程在图1中有所说明。每次更新都涉及将传入音频存储在音频缓冲区的顶部，并用Whisper处理整个缓冲区。我们保持不变的是缓冲区始终以新句子开头，以保持Whisper的高质量。LocalAgreement-2被应用于当前和先前的Whisper输出。“确认输出”中最后一个单词的时间戳被保存。在后续更新中，我们总是从缓冲区的开头重新处理Whisper，包括上一个“确认输出”时间戳之前的部分（在图1中以灰色背景表示）。确认部分中转录的更改被忽略，因为它们在意义上常常是微不足道的。
跳过确认部分 当确定相对于先前更新的上一个确认单词的转录单词位置时，我们考虑到了由于新音频块导致的Whisper时间戳的潜在不准确性和更新。如果一个单词的时间戳在距离上一个确认单词的1秒间隔内，我们比较其前面的n-gram（其中n的范围从1到5）与上一个确认输出中的后缀。如果它们匹配，我们跳过这些单词。然而，这个规则在未来的工作中可以通过包括诸如设置和微调字符编辑距离阈值、修剪n-gram中的标点符号和大小写等措施来进一步增强。
修剪音频缓冲区 为了避免延迟中不可接受的长峰值，音频缓冲区限制在约30秒左右。当确认输出包含结束句标点符号后面跟着一个开始新句子的单词时，缓冲区会在标点符号的时间戳处被修剪。为此目的使用了语言特定的句子分割工具（例如Koehn等人，2007），确保缓冲区始终包含一个单句。尽管如此，如果缓冲区长度超过30秒，我们会保留由Whisper标记的最后确认的段落。
连接句间上下文 Whisper的转录函数利用“prompt”参数来保持文档内的一致性（一致的风格、术语和句间引用）。我们从先前音频缓冲区的确认输出中提取最后200个单词作为“prompt”参数，如图1所示（黄色背景文本）。
语音活动检测 有一个参数用于激活或停用Whisper的默认语音活动检测（VAD）过滤器，影响质量和延迟。
4 基准设置
我们描述了用于评估的数据集、指标、设置以及我们用来评估模型的硬件。
评估数据
为了进行延迟和质量分析，我们使用手动转录的ESIC语料库（Macháček等人，2021）的开发集进行英语、德语和捷克语的ASR，其中包含179个文档。该语料库包含来自欧洲议会的5小时原始英语演讲，包括对德语和捷克语的同声传译。它提供了具有手动转录和单词级时间戳的音频轨道。
WER
我们使用去除标点符号和大小写后的词错误率（WER）作为ASR质量的标准衡量指标。
延迟
在我们的延迟分析中，我们实现了自己的方法，其中我们使用ESIC语料库中提供的时间戳将黄金转录与ASR输出对齐，使用编辑距离。这使我们能够确定每个黄金单词的编辑操作。我们通过测量ASR发出单词和相应的黄金单词被说出之间的时间差来计算ASR延迟，排除ASR删除的单词。我们计算每个文档内的平均延迟，并在比较跨多个文档的不同设置时，报告平均延迟以及标准偏差。
硬件
为了进行基准测试，我们使用NVIDIA A40 GPU。我们在一个同时由其他进程使用的集群中的计算机上运行Whisper，这可能会分配相同的资源并影响延迟。由于无法始终为给定服务拥有专用服务器，这使得我们的评估非常真实。由于延迟指标会有变化，我们报告均值和标准偏差。
确保可重复性
我们模拟长篇转录的实时处理，并记录Whisper发出输出的时间。我们在一个集群中的计算机上运行模拟，这些计算机并非完全由我们控制。对于我们的模拟过程，我们阻止了一个GPU和足够数量的CPU和内存容量。然而，可能会发生其他进程同时运行的情况，导致CPU和内存负载不可预测地减慢我们的模拟。如果MinChunkSize小于处理更新的时间，则相同模拟的两次运行具有不同的分段到块的方式，导致不同的WER和延迟。
因此，我们对相同文档的相同设置进行了10次模拟运行，以测量延迟和质量的标准偏差。设置为英语转录的ESIC dev.20080925.013_007文档，时长为3分36秒，在NVIDIA A40或L40 GPU上运行，具有48GB GPU内存，8个被阻止的CPU核心和200GB的CPU内存，带或不带VAD过滤器，MinChunkSize为0.1秒。
结果见表1。我们观察到WER的标准偏差很小，可以忽略不计，低于或接近1%。平均延迟的标准偏差要大得多，根据设置的不同，从0.36秒到0.81秒不等。我们得出结论，必须注意由于无法控制的计算条件而产生的延迟的标准偏差。
表1：ESIC dev.20080925.013_007文档的10次重复运行的平均（±标准偏差）WER和延迟，使用MinChunkSize 0.1秒，使用或不使用VAD过滤器，在两种GPU类型上。加粗表示我们后来使用的设置。
5 结果
我们对Whisper-Streaming进行了各种设置的英语、德语和捷克语ASR评估。我们首先展示了异常值和语音活动检测（VAD）对确定最佳设置的影响，然后使用这些设置呈现我们的主要结果。
异常值在处理许多设置后，我们观察到英语ASR文档dev2.20101213.015_018_EN_Gallagher的WER异常高。我们意识到这是由于ESIC数据集中的噪音造成的。提及文档的前半部分是爱尔兰语，而不是英语，这不是我们期望的。只有英语部分是黄金的转录，但Whisper转录了两者，导致比参考更精确的转录。除了Gallagher文档外，所有报告的设置的WER在0%到52%之间，平均延迟在0到16.1秒之间。
VAD我们研究了Whisper后端内集成的VAD（语音活动检测）过滤器的影响。结果见表2和图2。我们发现，在ESIC语料库中，建议对英语原始语音停用VAD过滤器，因为它非常流畅，没有间隙，也没有非语音声音。没有VAD，质量基本保持不变（WER之间差异在0.2%以内），平均延迟大大降低，在0.23到0.41秒之间。
表2 VAD过滤器对ESIC dev上流媒体ASR的WER和延迟的影响，不同最小块大小（m.ch.，以秒为单位）的英语原始语音（en）和德语同时口译（de）。我们用粗体突出显示了显著的好处：没有停顿的原始语音以较低的延迟（减少0.23秒或更多）进行处理，并且在关闭VAD时具有可比较的质量。相反，对于频繁暂停的口译，打开VAD可以获得更高的质量，延迟差异较小。
图2 VAD过滤器对延迟和质量的影响。英语和德语在VAD打开或关闭时的显著差异是因为德语是一名口译员的语音。
对于同时口译的处理，我们建议激活VAD过滤器。同时口译的语音包含许多暂停，特别是在等待上下文时。使用VAD时，延迟只增加了0.1秒，因为VAD通常会过滤掉沉默，这降低了处理负载。使用VAD时，质量显著提高，在德语上，使用更短的MinChunkSize时，WER提高了2到3个百分点。对于大块大小，质量几乎相同（MinChunkSize为2秒时，WER相差0.3%），因为大块大小会使模型具有更多上下文，从而降低了产生不确定输出的风险。因此，我们为德语和捷克语的同时口译激活了VAD，并为英语原始语音停用了VAD。
对于实际的设置，我们建议在演讲实际开始前不久启动Whisper-Streaming，这样就不会错过前几个词，同时打开VAD过滤器，这样沉默和非语音声音不会导致Whisper犯错。如果降低延迟很重要，可以实现一种自适应协议来设置VAD的开启和关闭。
性能表3和图3总结了Whisper-Streaming在ESIC验证集上的WER和平均延迟，涉及三种语言跟踪。总体而言，使用1秒的MinChunkSize，英语的平均延迟为3.3秒，德语为4.4秒，捷克语为4.8秒，而WER比离线模式高出2%。对于英语和德语，捷克语的WER更高了6%。英语的WER和延迟最低，其次是德语和捷克语。这与训练Whisper所使用的语言特定数据量以及这些语言的形态复杂性有关。延迟会随着不确定性增加而增加，因为它需要更多的更新来达成一致。此外，块大小越大，延迟越大，但质量越高，因为系统具有足够的上下文。
图3 在计算感知和无感知仿真中的延迟和质量（实线和点与虚线和叉），以及离线WER（星号和浅色垂直线）。英语的VAD被关闭，而其他两种语言则开启。
表3 Whisper-Streaming在ESIC dev set中三种语言轨道上的WER和平均延迟，使用不同的MinChunkSize（“m.ch.”）。现实设置是计算感知（“aw.”），与离线WER（“offline”）和计算无感知仿真（“un.”）进行对比。数据与图3中的相同。
离线模式WER我们将结果与作为最大性能估计的设置进行对比。其中之一是离线模式，在此模式下，整个音频文档的处理是在录制后完成的，没有任何处理时间上的限制。这是Whisper的默认和最优化的设置。离线模式和使用VAD的WER低于流媒体模式，因为上下文大小没有限制。模型甚至可以使用在流媒体模式中不可用或受限的右侧（未来）上下文。此外，长形语音的内部分段在离线模式中进行了优化。
计算不可知延迟另一个对比设置是计算不可知的模拟。它使用一个不现实的假设，即Whisper处理任何音频段的计算是瞬时的，因此计算引起的延迟不包括在延迟测量中。测量包括由语言不确定性引起的延迟。计算不可知和知晓评估之间的延迟差异可以通过优化硬件或推理算法来减少。通过改进模型或流媒体策略，可以减少计算不可知延迟。
我们观察到，平均计算不可知延迟大约是块大小的两倍。这是预期的，因为我们使用两次连续更新的本地一致性。然而，英语的处理实际上更快，几乎是块大小的两倍。我们推测这可能是由于Whisper模型的预期能力引起的。第二个可能的原因是ESIC中黄金时间戳的不准确性。时间戳是通过自动强制对齐计算的，因此在非标准情况下（如重叠和非转录语音，如犹豫和外语插入）可能不太准确。
- 显示Disqus评论(需要科学上网)