首字延迟怎么测：我们的评测口径
流式识别的首字延迟，常被一句话带过：开口之后，多久能看到第一个字。这句话里有三处没说清：从哪一刻算起，到哪一刻为止，在什么条件下测。条件不同，同一个系统量出的数字可以相差很多。本文写明评测表里的首字延迟怎样测，以及它和你在语音识别与合成页上看到的读数有什么不同。
1. 我们怎样定义首字延迟
流式识别的服务端一边收音频，一边返回中间结果（partial）。中间结果是当前这句话到目前为止识别出的文字，后面还会被修正。
首字延迟只看第一条文字不为空的中间结果，也就是第一个识别字。空结果不算，因为用户此时还看不到任何字。
首字延迟
= 第一个识别字返回的时刻
− 第一帧音频送入服务的时刻2. 为什么在同机房内测
计时的起点不是点击麦克风的那一刻。点击之后用户可能还没开口，从点击算起，量到的就是人的反应时间。所以评测不经过人，由测试程序把测试集里的音频逐帧送入服务。
测试程序和识别服务在同一个机房，网络往返很短。这样测到的主要是服务端从收到音频到给出第一个字的时间：解码、识别，并产生第一条结果。用户设备上的采集缓冲、用户到机房的网络，都不在这个数字里。
3. 哪些条件要固定
换一块显卡，或者多几路并发，首字延迟就会变。评测把下面这些条件固定，并和数字一起写出来：
- 服务端 GPU：[GPU 型号]
- 同时在线的流数：[N] 路
- 模型版本与测试日期：[版本]，[日期]
- 测试集：[测试集]
缺任何一项，这个数字就不能和别处的数字直接比较。
4. P50 与 P90 分别说明什么
对每条测试音频量出一个首字延迟，把全部结果从小到大排列。
P50：一半的结果不比它慢
P90：90% 的结果不比它慢P50 是排在中间的值，说明典型情况；P90 说明慢的一端，十次里有一次比它更慢。用户记住的是慢的那几次，所以只看平均值或 P50，会让系统显得比实际更顺畅。平均值既容易被少数极慢的异常值拉高，又会把长尾延迟掩盖在大量快速样本里，所以我们不用。公开评测页的延迟表里同时列出 P50 和 P90。
5. 实时语音识别页上的读数
在实时语音识别页说话时，“首字”一栏显示的是这一次会话测到的值；开始说话之前，那里显示的是评测表里的 P50。
这个值在浏览器里用 performance.now() 计时，口径和评测表不同：
- 起点是第一帧带有语音能量的音频。一帧音频归一化后的均方根（RMS）达到 0.015，就算有人在说话，这一帧的开头就是起点。如果整个会话里没有一帧达到阈值，起点退回到发出的第一帧的开头。
- 采集缓冲算在里面。浏览器攒够 2048 个采样点才交出一帧，16 kHz 下是 128 ms，48 kHz 下约 43 ms。起点取帧的开头，帧交出时已经过去一整帧的时间。
- 你到服务端的网络算在里面，服务端处理也算在里面。
所以这个读数反映的是你此刻的设备和网络，适合用来感受整条链路，不适合拿来和评测表比较。背景噪声大到超过阈值时，起点会提前到噪声出现的位置，读数也会偏大。
6. 读别人的数字时可以问什么
- 从哪一刻开始计时：点击、第一帧音频，还是第一帧有语音的音频？
- 到哪一刻为止：第一个字，还是整句的最终结果？
- 在哪里测：同机房，还是用户的浏览器？用的什么硬件？
- 报的是 P50、P90，还是平均值？
四个问题都有答案，两个数字才有可比性。想看自己设备上的读数，可以在语音识别与合成页对着麦克风说几句话。