iOS端 ASR优化

一、ASR(Automatic Speech Recognition)简介

ASR是一种将语音信号转换为文本的技术，它可以帮助人们更方便地与计算机进行交互。我们的AI作业小节在录制过程中会同步调用ASR服务商实时将用户录制的语音转成为文字，在录制完成后根据ASR结果计算流畅度、语速评分，在上传作业的时候将ASR结果同时上传到服务端进行AI分析。

可见AI作业的流畅度维度评分、语速维度评分和AI分析报告中的关键词分析、口头禅分析、停顿分析都是建立在获得准确的ASR结果上的。所以构建一个准确可靠的语音识别服务是AI作业小节的基本要求，也是AI作业小节的分析准确度和用户满意度的关键。

二、ASR存在的问题

2.1 热词/词库问题

ASR服务需要手工校准一些生僻专业词语的发音或同音词识别，这也就意味着需要ASR服务商提供词库/热词功能，同时对不同的用户/企业甚至每一次ASR识别过程都可能需要不同的热词。

解决方案:

针对CN、CO、COM/TW/IO 这三个环境平台，调研支持热词的服务商并测试效果。CN 采用了阿里听悟，CO采用了AmiVoice，COM/TW/IO 会采用微软。

2.2 Socket连接稳定性问题

2.2.1 并发控制

目前采用的几家服务商对实时语音识别的技术方案都是使用Socket将录制采集的音频数据推流到厂商的服务端进行实时识别。每家厂商对并发数控制都是不同的，如果新的Socket请求达到最大并发数量会无法连接到服务商。（这个问题可以通过联系服务商提高并发数量上限来解决，但是并不能无限提高）。

2.2.2 网络波动

端上发起的Socket连接的稳定性是不可靠的容易受到短时通讯质量波动影响导致超时断连。

2.2.3 断线重连问题

由于流畅度以及停顿分析强依赖ASR返回的断句结果和Word偏移时间，断连之后重连的断句结果中的起始时间重置为0从而导致停顿分析和流畅度打分不准。并且服务商有并发数控制，重连也不一定能连上。

如果不考虑并发控制直接重连，本地维护录制的绝对时间，仅依赖ASR结果中的相对时间去拼接完整时间轴也是有问题的。因为ASR结果中存在整句和单词的断句，这个断句依赖连续的音频输入。如果服务断开连接后我们本地存储音频数据，重连后再次进行识别，这样拿到的结果的断句一定是错误的（一定会有物理中断的特征断句）。

所以Google Voice v1的识别一直存在一个问题，Google v1（iOS）目前会每60s中断重连一次，即使用户在此时间点无停顿，其识别结果也会在每个60s处都有一个断句。非连续的数据一定会出现异常的停顿，对结果影响非常大会导致流畅度分析不可用。后续会针对COM/TW/IO站点切换微软语音识别来解决这个问题。

2.2.4 用户体验问题

目前ASR发生了断连或不可用问题用户是较难感知的（只有文字识别是否显示的区别），并且直接影响此次录制的流畅度和语速评分（无数据会显示一团迷雾）。如果讲师开启了提交作业最低分限制会直接导致该次录制无法提交，用户回到”上传视频作业”流程比较远，可能会间接导致该次录制作废，业务主流程卡死，十分影响用户体验。

解决方案

考虑通过增加一些兜底的交互将出现ASR连接错误的作业从实时录制流程快速导向到上传流程。使用服务端异步分析为端上实时连接做一次兜底（用户如果对当次录制的作业比较满意可以选择直接提交到服务端走上传流程，如果不满意可能会自行重录）。

三、优化方案

3.1 支持热词功能

• 中文：听悟 支持临时热词列表
• 日文：Ami 支持临时热词列表和热词词库
• 英文及其他：微软 支持临时热词

当前支持以企业为维度配置热词列表，在服务端维护。未来可以支持以作业为维度配置热词列表。

3.2 可观测性增强

在往期的基础上丰富了日志上报：

• 在常规的各个服务商Socket或者SDK的关键生命周期（初始化、开始识别、停止识别等）和返回错误信息的关键节点增加kibana日志上报
• 增加一个30s为周期的心跳日志，记录识别到的稳态结果文本长度，表示ASR服务仍然在正常运行

3.3 错误降级机制

如上方断线的解决方案，增加检测到ASR报错时增加服务端兜底机制。

3.4 支持切换站点和语言使用不同ASR服务

切换语言

目前的技术方案已经支持根据不同站点的阿波罗配置下的根据语言下发ASR服务平台类型，APP根据对应的类型启动ASR服务。

切换站点

当前iOS项目中ASR服务按照包来区分，每个站点引入的SDK是不同的：

• CN包：阿里，AMi
• CO包：AMi，Google，微软
• COM包：AMi，Google，微软

有些SDK因为合规问题不可以接入特定包，如711只有Google ASR。

UASR、腾讯、AMI、微软这四个ASR服务支持切换站点，根据对应站点下发的类型即可调起对应的服务。

在CN包还保留了阿里ASR兜底，别的包使用微软ASR兜底。如果下发的ASR服务在当前包是缺失的则会使用兜底。

iOS会在2024.10尝试将不同站点用到的ASR SDK全部引入当前包中，实现切换站点就可以切换服务的功能（安卓已经合并到一个包中）。

风险点在于新引入腾讯ASRSDK加引入多个SDK会使包体积增大，但经测试合并前后包体积基本无影响。

四、日志设计

ASR服务提升可观测性，在以下生命周期进行日志监测。所有ASR的日志都以UMUASRService为key，在kibana搜索这个key过滤ASR问题。

4.1 准备阶段

获取ASR配置失败时会上报 refreshASRGlobalConfig fail

4.2 启动服务

• buildASRService的时候打一次日志，携带服务端下发的平台类型
• 初始化服务失败会打一次日志，不同Service根据SDK初始化方式打的时机不同
• buildASRService完成后打一次日志，携带APP实际采用的ASR类型（根据类名区分）

4.3 服务进行中

• 正常场景：在收到稳态识别结果后每30s上报一次ASR服务心跳日志，携带当次识别结果的文本长度。增加心跳的目的是监控ASR服务是否正常持续运行
• 异常场景：收到ASR服务商SDK、Server回调的错误上报错误代码和信息日志

4.4 服务结束

打一次结束日志