目前全球范围内手语老师严重不足，调研各种情况后我们开发了一款产品希望帮助听障人士解决一些生活中的常见问题，本文将为大家分享虚拟数字人《手语翻译官》的技术实现。

作者 | 吴淑明

来源 | 阿里开发者公众号

背景

用户规模

世界银行的数据显示，全球大约有 11 亿残障人士，全球听障人士约有7000W+，中国残疾人总残疾人人数为 8500 万人左右，听障人士约2780W，占全国残疾人口的约30%，每年新增20W；浙江有90万。全国范围内容手语老师严重不足, 专业的手语老师就更加少之又少。

听障群体用户画像

• 男女比例： 男女比例58%比42%
• 年龄分布：
  2.8%为0-6岁共80W，无法学习手语，主要是比较好的治疗时间
  4.3%为6-14岁共120W，小学教育时期，但是参与小学教育的只有7.5W，占到这部分群体的6%
  33%为老年群体，听力受损的发病率也越来越高，多与老年人罹患各种慢性病有关
  剩下约59%左右群体为适龄劳动群体。
• 教育情况
  6-14岁的听障人士有120W，目前同官方统计言语残疾小学校的学生有7.5W，只占6%；
  特殊教育（学前教育、小学、初中和高中四个教育阶段），2019年听力及言语残疾在校生共13.5万，占比17%。特殊教育在校生人数逐年增长，近5年增长近80%
  千名听障残疾群体在中等职业学校或高等院校学习，是听障群体中的佼佼者

• 收入情况和主流职业
  a. 收入情况：4000元 收入偏低。
  b. 主要的就业分类
  ⅰ. 政府扶持主要是按比例就业和集中就业，占就业情况的11%
  ⅱ. 灵活用工从招聘网站上看主要的top职业为： 操作员、缝纫工、头皮理疗师
  ⅲ. 77%仍然需要听障人士自己找工作。

聋人生活中的困境

• 与健听人的简单交流，即便使用文字也不能顺畅交流，再加上部分年长受教育程度低的人群，文字交流也困难。
• 由于听障人群的受教育程度以及独特表达和理解方式，导致他们的文字表述和语法结构与健听人完全不同，即便通过文字也无法便捷无障碍的与健听人沟通。听障人群与健听人之间的沟通障碍，严重影响了听障人群的生活质量。听障人群与健听人的沟通需求主要集中在几下情况：

较复杂的交流，就医、纠纷 水电煤银网办事等具有一定专业性、复杂性的交流场景，需要有一个专业的手语翻译人员协助， 否则就是下面这句话：

晚上熬夜半夜早晨， 他老换找位置舒服他妈妈多次断睡性帮他盖好被子别着凉，他有时翻中了我体位置得痛，看我醒酒冲来抱舒服能秒入睡了，哼！等中午他父母要补睡......

听人完全是看不懂，这是在说什么？

• 深度交流：听障人士需要与听人进行深度的交流，通常是有一定专业性、复杂性的交流场景，如就医、水电煤银网办事等；
• 信息获取难度大：
  听障人士需要从听人世界的影音内容中获取更多的信息，而当前手语内容覆盖极度有限；

一夜通宵没睡，宝宝总是动来动去寻找一个舒适的睡觉位置，他妈妈时不时给宝宝盖被子，怕他着凉了。他有时候翻身的时候还会踢疼我，看到我醒了就跑到我怀里来了，我一抱着他他就入睡了。中午我和他妈妈需要补个觉 。

产品设计

产品调研

调研用户画像

【听障人士】
1、听力受损程度在中重度及以上，在参与社会生活方面存在中度障碍。借助我们提供的产品，能有效提升其社会生活日常沟通效率；
2、会相对标准的手语，其通过手语所表达出的信息，在听障人群中，能被大多数听障人士看懂并理解；
3、至少具备普通智能手机使用能力；
【听人】
1、与听障人士密切生活的非听障人群，与听障人士有较大的日常交流沟通诉求；
2、公共服务机构（政府、银行、医院、快递、商场等）的工作人员在日常工作中，可能会遇到要为听障人群提供服务的场景；

痛点场景

1、简单交流：听障人士需要与听人进行简短的交流，对话轮次通常不超过10轮即可完成，内容为日常生活所需的交流场景，如日常购物、出行、问询、工作交办；
2、深度交流：听障人士需要与听人进行深度的交流，通常是有一定专业性、复杂性的交流场景，如就医、水电煤银网办事等；
3、信息获取：听障人士需要从听人世界的影音内容中获取更多的信息，而当前手语内容覆盖极度有限；
4、参加会议：听障人士需要从有声会议中获取会议信息，当前主要通过讯飞的语音识别技术转成文字；

线下调研

场景一描述：A开车途中遇停车时，接打视频电话。

停车期间，通过微信视频，和他人进行手语沟通。相比于常人，A接打视频几乎是秒通，上午3小时的观察过程中，约有20次左右的视频接打。在车上主要通过车载手机支架固定手机

分析：听障人士对手机视频通话的依赖较大，视频通话功能使用极为频繁。今天见到的几乎所有的听障朋友，均随身携带充电宝；

场景二描述：A到达法院后，寻找联系对象。

A没有去前台寻求帮助，径直走向电梯，出电梯后观察是否自己要去的地方，经历1-4-3-2-1多楼层寻找后，才到前台寻求帮助，打字告诉对方自己要找谁。

分析：和普通人沟通存在一定的障碍，导致听障人士非必要情况下，不会主动寻求常人协助。 形成天然的鸿沟；

场景描述：A和法官沟通案件细节。

进入沟通室后，法官建议使用微信平台上的微法院进行图文沟通。但A坚持使用手之声APP，在排队等待后，进入真人手语翻译视频通话。用手机支架将手机放置在桌面后，通过视频里的远程手语翻译，和法官完成了需要进行的沟通。A先是表达了另一涉案人的近期信息，之后提出要求，在法官给出处理意见后，A表示认可，并结束通话。适应了加入手语翻译的节奏后，对话过程的障碍相对较小；

分析：虽然能打字进行IM对话，但对A来说，还是认为远程手语翻译介入后的沟通效率更高。 在环境简单不嘈杂，参与对话人数仅为3人（A、法官、远程手语翻译）的情况下，是可以进行沟通的。对A或是其他听障人士来说，使用手语翻译的效率，比起文字沟通要高很多。输入文字给对方看，适用于日常简短的沟通。如果是一个时间较长较正式的沟通，还是需要稳定的环境和手语翻译的帮助，才能顺利完成；

手语翻译的难点

双向手语翻译的难点

• 我们就是第一人
  我们是“首个”以双向手语翻译为目标的项目，实现从0到1的过程。
  现阶段同类的手语合成产品，按照自然语言的语序采用逐字翻译，忽视了听障朋友的语言逻辑与健听人语言逻辑的差别，导致听障朋友理解困难。
  现阶段手语识别还未有成熟的商用产品，精度仍然是最大的挑战。
• 巧妇难为无米之炊
  由于听障朋友对外交流有限，已有手语数据存留较少。且具备手语
  能力的人群数量较少，进一步阻碍的数据收集的速度。
  与语音识别、语种互译相比，获取充足、高质量的手语数据难度不言而喻。
• 手语的区域特性
  由于听障朋友的活动区域局限，形成大到地区、小到社区的多元化手语打法风格。这对于数据采集的覆盖范围，以及数据本身多样性对算法的挑战都十分巨大。
• 手语是视觉语言
  手语是一门视觉语言，语言表达顺序与自然语言完全不同且没有固定语法约束。手语生成需要生成符合听障人群表达习惯，便于理解的语言；相当于学习了一门新的语言，而不是单纯的逐字翻译
  比如，自然语言中 "灭火" 在手语中的表达是 火->灭 因为先看到火才能灭
• 纯视觉方案的手语识别
  相对于现有基于昂贵传感器的手语识别，我们是首个采用纯视觉方案（仅依赖手机摄像头），需要实时精准的图像处理算法研发，从捕获的手语视频中提取有效的空时信息，进行手语识别。
  这里涉及实时高效的处理高维度的视频数据，准确提取脸部、和具备高自由度的精细手指手势信息，同时要处理手语本身的多元性、多样性表达。这对视觉算法提取了更高的要求。
  手语语速快，动作精细和多变，动作间相似度高。
• 工程难度大
  ● 业务并发量大：与以往的工程架构不同（接口调用），现阶段提供流媒体服务，若高并发的时候需要大规模的集群和资源调度。
  ● 响应延时问题：流媒体本身就有几百毫秒的延时，再加上双向翻译的流程中嵌入了大量的算法模块，导致延时加长。延时翻译是非常影响产品的交互体验。

双向手语翻译

• 由于本文主要讲解的技术实现， 产品上仅仅放了实现之后的一些产品使用。
• 大家可以在支付宝上搜索《现声》体验。
  产品链路：

手语合成

• 大家可以去这个页面做手语内容的生产。
  https://avatar.aliyun.com/#home

技术落地

依托云原生技术， 池化数字人云渲染服务， 实现数字人的不同业务模型下的快速服务， 完成手语翻译单设备单工开发及手语合成实时翻译， 文本转手语合成翻译， 视频转手语合成翻译。v

技术方案设计

1. 因为涉及实时图像识别 ， 对于网络带宽的要求非常高， 所以我们当前将视觉相关算法和流媒体部署在同一个pod， 从而降低网络开销及识别时延。
2. 手语识别技术最大难度是“手语识别的图像数据来源， 以及图像数据的标注团队”， 技术上必须解决训练数据的生成效率问题。
3. 由于听障和听人信息交互方式存在差异， 听障朋友给出的是物理世界能形容的事物， 整句话是由一堆动/名词组成， 还会涉及到倒装， 所以必须加一个手语词汇转自然文本的翻译模块。
4. 相同于第3点， 手语合成也需要一个文本转手语模块， 将自然文本转换成手语词汇， 同时面临第2点一样的数据问题。

• 专有名词解释

• 媒体服务： 流媒体模块， 负责编&解码， rtc渠道的订阅和推送， 本地视频转码录制， 解码后图片推送。
• 手语识别： 算法模块， 按照协定的图片格式输入图片， 输出一系列手语词汇。
• 手语转文本： 算法模块， 输入手语词汇， 输出自然文本。
• 手语合成： 算法模块， 输入手语词汇， 情绪及等级， 输出手语keypose和bs数据.

• 文本转手语： 算法模块， 输入自然文本，输出手语词汇， 并且传输给BH模块。
• 行为交互逻辑： 工程模块， 统一决策调用数字人交互逻辑。
• agent： 工程模块， 负责各个POD容器之间的消息传输。
• 3D渲染引擎： 渲染模块， 负责数字人实时渲染， 生成数字人帧数据。

方案落地

初期产品上希望实现单设备双工模式，确实也实现了一个单设备双工模式， 但是由于环境噪音依赖终端设备的降噪， 手语摄像头安放位置等等因素，最终确定使用单设备单工模式。

单设备单工模式-《现声》

1. 解决ASR识别不准确问题， 可实时在线进行人工干预。
2. 解决手语识别不准确的情况下进行人工干预。
3. 单工模式下手语翻译官支持主动打断， 这需要依赖行为交互逻辑模块的实现交互逻辑的处理。

实时手语识别链路技术方案

1. 手语识别帧数据要求为10FPS, 360P，
2. 端上通过RTC将帧数据推送上来。
3. media在数字人没有启动的前提下， 会自动向手语转手语词汇模块发送空白帧数据，空白帧数据为全0图片数据， 算法不会产出任何结果。
4. 数字人开始工作后， 流媒体解码出第一帧时候，并且发送手语转手语词汇模块， 手语识别才开始工作，手语转手语词汇发送识别结束事件给行为树。
5. 手语识别中间会实时返回识别结果， 结果为累积数据，并且通过 手语识别结果事件发送给行为树模块。
6. 行为树模块将手语识别结果发送给手语词汇转自然文本模块。
7. 手语词汇转自然文本模块会产生手语识别结束事件， 并且进行本地redis缓存。
8. 行为树决策引擎， 等收到手语识别结束后， 行为树向前端发送手语识别结束事件，默认回到数字人界面， 等待播报内容。
9. 如果需要进行语音播报， 行为树会发送播报文案给媒体， 并且发送文案给前端展示， 流媒体合成tts后， 插入到流媒体里面。

实时手语合成链路技术方案

• 实时手语合成算法处理方案
  关于手语标注数据， 大家可以参考《手语众包》这一章节。
  算法核心会计算词汇动作与词汇动作之间的过渡帧， 及词汇动作到空闲动作的过渡帧， 这要求数据标注的时候， 尽量标注出空间最接近于空闲动作的那一帧数据。
• 实时手语合成unity处理方案， 通过实时渲染加媒体视频编码转RTC的方式实现。

行为树编排

核心目的： 解决数字人交互过程中， 工程， 算法，前端等各个模块对数字人行为变化及C端GUI交互反馈。抽象数字人行为节点， 降低代码开发， 通过编排的方式快速实现数字人业务落地。

• 如： 用户切换成手语识别时， TTS要主动打断。
• 如： 用户呼叫时， 要等待C端用户订阅流成功后， 数字人才开始打招呼。
• 如： TTS开始播报时， TTS文案才显示在前端页面。
• 如： TTS结束播报后， TTS自动消失， 或者长期维持不变。

1. 行为树提供大量的流程控制方法，使得状态之间的改变更加直观；
2. 整个游戏AI使用树型结构，方便查看与编辑；
3. 方便调试和代码编写；
4. 最重要的：行为树方便制作编辑器，可以交由策划人员使用；

点击查看原文，获取更多福利！

https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247532182&idx=1&sn=e2daf6a274d1c1bc9d01a2901be98fb3&chksm=e92a4399de5dca8fa729a9e512d441f23de41c7354dffdc9be78fb4fdb26bea7ced3f3f34bc2&token=552668333&lang=zh_CN#rd

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。