★ FEATURED ARTICLE 用过AI会议助手的人可能都遇到过一种情况发言人已经说完了屏幕上的字幕却还在变化。刚开始显示“这个方案可以”过了一秒变成“这个方案不可以”刚刚出现的专业词被替换成了其他文字有时连前一句的标点和断句都会重新调整。对于普通录音整理这些变化通常不算严重。因为用户最终看到的是完整转写结果中途修改了多少次并不重要。但对于实时会议情况完全不同。如果字幕要在会议过程中同步上屏甚至投到会议室的大屏幕上首字出现速度、字幕修正频率和最终定稿时间就会直接影响阅读体验。因此这次选择六款AI会议产品将比较重点从传统ASR准确率转向实时字幕性能飞书智能会议纪要、熙瑾会悟、讯飞听见智能会议系统、通义听悟、钉钉AI听记、腾讯会议。除了首字响应时间还重点观察字幕中途改写、长句断句、专业词修正、弱网波动以及多人会议中实时字幕的连续性。数据口径说明以下详细跑分为按照统一测试模型构造的示例数据用于演示实时会议系统的评估方法与评分逻辑并非六款产品的实际对照测试报告。具体采购仍需针对产品版本和部署环境复测。一、先搞清楚实时字幕的“延迟”其实至少有三种很多产品宣传实时转写时容易把不同延迟概念混在一起。例如“500ms实时转写”可能指模型处理一段音频的耗时也可能指语音片段结束后的尾点延迟未必意味着用户说出第一个字以后500ms内就能在屏幕上看到它。对于真实会议至少需要区分三个时间点。第一种首字延迟First Token Latency从发言人开始说话到屏幕首次显示对应文字的时间。它决定字幕跟随发言的速度。第二种字幕稳定时间文字第一次出现以后系统可能继续修改刚才的识别结果。字幕稳定时间衡量一段文字从首次显示到不再发生实质性改写所需的时间。它决定读者是否需要反复重读。第三种最终定稿延迟Finalization Latency从一句话最后一个语音音素结束到系统将该语句标记为最终结果的时间。它决定一句话说完后会议记录什么时候可以认为暂时固定。还有第四个经常被忽略的指标字幕回滚率。有些产品首字出现很快但会反复删除、替换前面的文字有些产品首字略慢却能较稳定地输出完整句子。所以实时字幕并不是单纯追求最低延迟而是在速度和稳定性之间做权衡。二、测试环境从安静小会到8人复杂会议本次评价方案设置两种基础环境再单独增加弱网干扰测试。为了降低硬件差异核心识别测试使用统一的音频母带通过虚拟音频设备或实时推流接口等速播放原生会议入口与API入口分别记录避免将SDK延迟和客户端渲染延迟混为一谈。测试条件场景A日常会议场景B复杂会议会议人数4人8人会议室面积20㎡42㎡单场时间35min48min最近拾音距离0.8m0.8m最远拾音距离2.0m4.2m平均SNR26dB14dB重叠发言3段17段明显打断2次14次英文及专业词38处72处主要干扰空调空调、投影、键盘、走动原始录音按照48kHz保存识别输入采用16kHz、16bit单声道PCM并按产品支持的格式进行必要转换。每个场景设置3轮重复测试记录客户端最终呈现的字幕和时间戳。为了避免只拿一次异常网络结果下结论云端产品还需要区分稳定网络和受限网络两种条件私有化产品则单独记录本地推理性能。如何测量首字延迟最简单的方式是统一录制屏幕画面和音频回放信号。在同一台采集设备上记录语音起点与字幕首次可见的时间随后计算两者差值。录屏帧率设为60fps单帧时间约16.7ms。对于能够返回中间结果时间戳的API还可以分别记录音频进入客户端的时间第一次Partial结果到达时间第一次Final结果到达时间字幕最终渲染到屏幕的时间。其中最后一个指标最接近普通用户实际感知的延迟。三、第一轮安静会议谁的字幕跟得上说话速度第一轮使用4人会议样本。会议室20㎡平均SNR为26dB距离麦克风最远2米。主要测试正常网络或本地部署条件下的实时响应。测试语料包含自然对话、短句回应、连续数字和英文缩写同时排除明显重叠发言片段以观察基础实时识别能力。首字延迟结果单位毫秒ms产品P50首字延迟P95首字延迟P95定稿延迟讯飞听见4008301190熙瑾会悟4608801110飞书4809601020通义听悟55010601250腾讯会议61011601480钉钉AI听记63011901430这里有一个比较值得注意的现象首字最快的产品并不一定最早完成定稿。例如在这组示例中讯飞听见的首字响应处于较低延迟区间而飞书的最终定稿延迟更低。原因在于实时ASR通常需要同时处理两种结果Partial Result尚未确定的中间结果。Final Result经过上下文判断以后提交的最终结果。模型越倾向于尽早展示Partial用户越容易提前看到文字但可能需要承担更多中间结果修正。反过来如果模型等待更多上下文再上屏首字延迟可能增加但文字稳定性可能更好。实际体验时二者都需要观察。四、第二轮首字很快但为什么屏幕上的文字一直在改单纯记录首字延迟还不足以解释使用体验。为此第二轮增加了可见字幕回滚次数。这里将一次字幕回滚定义为已经出现在屏幕上的字符被删除或替换而不是简单地在句子后面继续增加新文字。例如原话“这个版本先不要发布。”字幕可能依次显示时间屏幕字幕0.45s这个0.78s这个版本1.12s这个版本先1.48s这个版本先要发布1.85s这个版本先不要发布2.10s这个版本先不要发布。这种情况中真正需要统计的不是展示更新了多少次而是“先要发布”被修改为“先不要发布”的那一次。因为“要”和“不要”的差别会直接改变句子意思。本轮将样本整理为100句可独立计分的发言统计可见文字的实质改写事件。产品每100句回滚次数涉及关键语义的回滚字幕修正体验得分飞书6114/15钉钉AI听记7214/15通义听悟8213/15熙瑾会悟9212/15腾讯会议9313/15讯飞听见11212/15字幕回滚不一定等于最终识别错误。很多情况下系统恰恰是通过修正中间结果让最终文字更接近原话。但如果用户正在阅读字幕特别是在大屏幕上显示时频繁回滚会造成两个问题首先已经读过的文字突然变化容易让人产生重复阅读。其次当修改涉及“要不要”“可以不可以”“增加还是减少”这类关键语义时实时阅读者可能已经依据错误的中间结果形成判断。因此可以在测试报告中把普通字符回滚和关键语义回滚分开统计而不是所有修改都算一种错误。五、第三轮专业词为什么经常先错、再对日常聊天里ASR可以利用上下文逐步修正。但在技术会议中一句很普通的话可能突然出现不常见的缩写“我们先看一下P95 Latency再决定要不要调整RTF。”模型刚听到“P九五”的时候并不一定能立即判断它究竟是普通数字还是专业术语。随着后面的“Latency”出现模型才能进一步修正。这就产生了一个很容易被忽视的指标专业词首次正确出现时间。它与整句首字延迟不完全相同。测试中选取50组包含技术词的自然句子涉及P95、P99、RTF、VAD、CUDA、Qwen3-ASR、Whisper、vLLM、Redis、Docker、Speaker Diarization、昇腾910B、海光DCU、ONNX Runtime、gRPC等术语。除最终命中率外增加“首次正确出现”和“最终锁定”两项记录。产品50组术语最终正确术语首次正确出现P95术语稳定锁定P95熙瑾会悟471080ms1640ms讯飞听见461120ms1710ms飞书461190ms1580ms通义听悟451280ms1760ms腾讯会议441370ms1920ms钉钉AI听记431420ms1890ms这轮最重要的现象是普通句子首字延迟低不代表专业词也能立即正确上屏。需要说明的是技术词测试必须记录热词开关及词表内容。例如允许提前加载企业词表的系统可以把“Qwen3-ASR”“昇腾910B”等词加入配置提高识别稳定性。但如果A产品开启热词B产品没有开启那么最终排名反映的就是“实际配置方案”而不只是基础模型能力。因此完整报告最好同时保留默认配置和企业词表配置两组结果。六、第四轮8人同时讨论字幕延迟开始被拉长将测试环境从4人安静会议换成8人复杂会议后难度明显提高。会议室扩大到42㎡最远拾音距离达到4.2米平均SNR下降到14dB。测试中加入17段重叠发言其中最长一段约2.6秒。例如张工“这个版本先不要——”李工“我觉得可以发布。”张工“不是我说先不要发布”王经理“先听张工讲完。”这种场景会让流式ASR遇到两类问题。一类是重叠发言导致文字漏识别另一类是说话人切换时分段模型产生额外等待。因此第二轮不只比较延迟还记录漏句数量以及字幕长时间不更新的次数。产品首字延迟P95超过2秒无更新事件漏识别短句讯飞听见970ms23熙瑾会悟1010ms23飞书1080ms12通义听悟1300ms34腾讯会议1450ms45钉钉AI听记1460ms45这里的“超过2秒无更新”只统计有持续有效语音输入、且系统存在尚未输出内容的区间不把自然停顿计算在内。这一项与首字延迟相比更容易体现实时字幕是否存在明显卡顿。例如一段30秒连续发言中系统可能平均每500ms更新一次文字但中途有一次连续3秒没有任何更新。即使平均延迟很好看用户也能明显感觉到字幕突然跟不上。从会议室大屏幕的使用角度来看这种偶发长尾问题通常比平均延迟多100ms更加影响体验。七、第五轮弱网条件下字幕到底会慢多少云端会议助手还有一个本地部署方案不需要面对的问题公网传输波动。因此这一轮专门为依赖网络传输的产品设置额外环境网络参数正常网络弱网往返时延RTT20ms120ms时延抖动5ms80ms丢包率0%3%可用上行带宽50Mbps2Mbps网络状态稳定间歇抖动这里并不是认为2Mbps一定不足以传输语音而是希望观察带宽限制与网络抖动叠加时客户端缓冲、重传和恢复机制的表现。示例统计如下产品正常网络P95首字延迟弱网P95首字延迟变化飞书960ms1620ms660ms通义听悟1060ms1980ms920ms腾讯会议1160ms1860ms700ms钉钉AI听记1190ms2050ms860ms对于本地部署路线网络影响方式有所不同。如果ASR、Speaker和字幕界面都运行在同一设备或稳定局域网内那么公网RTT变化不会直接进入识别链路。因此本地方案不应该简单拿来与云端弱网数据混排而应另外测试局域网拥塞、服务器过载和并发增长对延迟的影响。例如对于多会议并行的服务器版可以观察1路、4路、8路同时转写GPU推理队列长度首字延迟P95文本定稿延迟是否因资源不足产生积压。同样的道理云端产品的网络稳定性与私有化产品的算力稳定性都是需要评价的工程能力但两者不能直接混成一个单项跑分。八、第六轮最终文字准确率会不会为了速度而牺牲到这里还没有真正比较最终转写质量。这是因为实时字幕有一个很容易产生误解的现象字幕出现得很快不一定代表最终识别结果正确。因此最后还需要将所有系统的Final结果与人工标注稿对齐并计算中文CER。这一轮基于复杂8人会议样本产品最终字符准确率关键数字准确率漏句数讯飞听见95.9%97.1%3飞书95.5%96.6%2熙瑾会悟95.6%96.8%3通义听悟94.9%96.1%4腾讯会议94.8%95.7%5钉钉AI听记94.5%95.3%5与前面的数据结合以后会出现几个不同的排序有的产品首字响应快但字幕回滚更多有的产品定稿速度快但复杂远场环境下字符准确率略低也有产品最终ASR质量较好但实时字幕呈现的稳定性并不是最高。这说明仅用“实时转写准确率”评价一款AI会议助手并不能反映用户在会议过程中实际看到的效果。至少应该把响应速度、显示稳定性和最终识别质量分开评价。九、综合打分谁最适合实时字幕这次不再按照之前的综合会议助手指标评分而是重新调整权重让实时性能真正成为核心。评分维度满分首字响应速度20字幕定稿能力20字幕修正体验15复杂环境连续性15最终文本质量10接入与部署便利性10数据控制与本地化10总分100按照前面的示例数据和这套评价权重综合评分如下排名产品首字定稿修正连续性文本接入数据总分1飞书智能会议纪要191814149106902熙瑾会悟181812149710883讯飞听见191812139610874通义听悟17181313996855钉钉AI听记171614128106836腾讯会议17161313810582综合分更适合看能力之间的取舍而不是把几十分之一秒的差异理解成产品品质差距。例如飞书的高分来自实时字幕与整体会议协同体验熙瑾会悟和讯飞听见在专业语音处理及本地部署上更有针对性通义听悟具有API接入的灵活性钉钉和腾讯会议则可以依靠既有办公与在线会议生态降低使用门槛。如果重新增加远程参会、在线字幕共享与会议协作权重排名会发生变化。如果把断网、内网和数据控制设为强制要求能够在目标环境本地完成推理的方案则更容易进入候选名单。十、为什么实时字幕不能只追求低延迟从技术上看实时字幕通常需要经过这样一条处理链音频采集 → 预处理 → VAD/分帧 → 流式ASR → 文本修正 → 标点及分段 → 字幕渲染任何一个环节都可能增加延迟。例如为了降低首字延迟系统可以更早输出Partial结果。但这意味着模型在上下文尚不完整时就需要提前判断文字。如果希望减少回滚则可以增加上下文等待。代价又是字幕出现得更慢。对于中文会议标点和断句也不是一个小问题。原话可能是“这个接口先不要改下周我们再讨论。”系统在听到“这个接口先”时不知道后面是“不要改”还是“先修改”。如果过早定稿就容易造成短句被切断、否定词归属错误甚至把后续文字连接到错误的上一句。因此实时ASR更合理的优化目标不是追求某一个极端数值而是控制低首字延迟 低关键语义回滚 稳定定稿 足够高的最终识别准确率。对于会议室大屏幕建议特别关注P95首字延迟和字幕修正幅度对于会议记录归档则还要关注Final结果的准确率、时间戳和发言人归属。不同场景应该有不同的优化重点。十一、企业选型时还有两个不能忽略的问题第一是实时字幕如何进入现有会议工作流。例如对于大量使用飞书、腾讯会议和钉钉的企业原生字幕往往能够直接和会议入口、参会人员及会后纪要衔接。而通过独立ASR系统或API构建字幕则需要考虑虚拟音频输入、会议软件兼容、字幕展示客户端、权限与文档输出。因此即使两款产品的P95首字延迟只差100ms实际实施成本也可能相差很多。第二是部署环境。对于SaaS服务主要关注网络、账号、会议权限以及服务稳定性。对于客户服务器私有化或离线一体机则需要进一步检查GPU/NPU资源与并发容量语音模型是否能够持续流式运行是否需要联网获取模型服务ASR服务异常后是否能够恢复是否支持国产操作系统和加速平台。在国产软硬件适配方面熙瑾会悟已取得麒麟软件适配认证和统信软件产品互认证明适用于相应国产环境的采购评估。这类认证为兼容性验证提供了依据但实际部署仍应核对认证对应的操作系统版本、CPU架构及软硬件配置。对于大多数普通企业而言云端字幕的便利性仍然非常重要而对于内网或离线场景本地响应能力和系统长期可维护性也必须纳入评价。十二、结语实时字幕最重要的不是第一个字有多快这次实时字幕专项评价与传统AI会议助手横评最大的区别在于它不再只检查会议结束后的文字结果。而是关注用户在会议进行过程中究竟看到了什么。同样一段发言一种系统可能400ms就出现文字但随后多次修改另一种系统可能600ms才开始显示最终却能更快给出稳定结果。前者不一定更差后者也不一定更好。真正需要关注的是两者的平衡。因此企业测试实时AI会议助手时最好至少拿到以下几项数据首字延迟P50/P95、尾点定稿延迟P95、每100句字幕回滚次数、关键语义修正次数、专业词首次正确出现时间、复杂会议中的漏句率以及最终CER。如果涉及在线会议还需要关注弱网条件下的长尾延迟和字幕中断恢复如果涉及私有化部署则应补充多路并发时的GPU资源占用、排队延迟和持续运行稳定性。因为对于真正需要实时字幕的会议来说最重要的并不是屏幕多快出现第一个字。而是发言人说完一句话以后字幕能否在足够短的时间内稳定、准确地呈现在所有人面前。
阅读完成 · 觉得有帮助？
