虚拟数字人之《手语翻译官》的技术实践

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

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

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

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

调研用户画像

【听障人士】
1、听力受损程度在中重度及以上，在参与社会生活方面存在中度障碍。借助我们提供的产品，能有效提升其社会生活日常沟通效率；
2、会相对标准的手语，其通过手语所表达出的信息，在听障人群中，能被大多数听障人士看懂并理解；
3、至少具备普通智能手机使用能力；

【听人】
1、与听障人士密切生活的非听障人群，与听障人士有较大的日常交流沟通诉求；
2、公共服务机构（政府、银行、医院、快递、商场等）的工作人员在日常工作中，可能会遇到要为听障人群提供服务的场景；

痛点场景

线下调研

手语翻译的难点

• 我们就是第一人
  我们是“首个”以双向手语翻译为目标的项目，实现从0到1的过程。
  现阶段同类的手语合成产品，按照自然语言的语序采用逐字翻译，忽视了听障朋友的语言逻辑与健听人语言逻辑的差别，导致听障朋友理解困难。
  现阶段手语识别还未有成熟的商用产品，精度仍然是最大的挑战。 
  ‍

  
  

  
  

• 巧妇难为无米之炊
  由于听障朋友对外交流有限，已有手语数据存留较少。且具备手语
  能力的人群数量较少，进一步阻碍了数据收集的速度。
  与语音识别、语种互译相比，获取充足、高质量的手语数据难度不言而喻。 

  
  

  
  

• 手语的区域特性
  由于听障朋友的活动区域局限，形成大到地区、小到社区的多元化手语打法风格。这对于数据采集的覆盖范围，以及数据本身多样性对算法的挑战都十分巨大。 

  
  

  
  

• 手语是视觉语言
  

• 纯视觉方案的手语识别

• 工程难度大
  1、业务并发量大：与以往的工程架构不同（接口调用），现阶段提供流媒体服务，若高并发的时候需要大规模的集群和资源调度。
  2、响应延时问题：流媒体本身就有几百毫秒的延时，再加上双向翻译的流程中嵌入了大量的算法模块，导致延时加长。延时翻译是非常影响产品的交互体验。 

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

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

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

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

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

1. 解决ASR识别不准确问题， 可实时在线进行人工干预。
2. 解决手语识别不准确的情况下进行人工干预。

   
   

3. 单工模式下手语翻译官支持主动打断， 这需要依赖行为交互逻辑模块的实现交互逻辑的处理。

   ‍

   
   

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

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

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

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

行为树编排

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

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

手语合成

1. 算法及协议复用单设备单工流程， 修改行为树逻辑实现， 仅实现行为树任务流程管理。
2. 实时手语翻译、离线文本手语翻译及视频手语翻译保持同一套架构。
3. 离线音视频手语合成， 因为手语的速度与音频播报速度不一致， 针对手语给出的时间消耗是不一样的， 所以需要离线音视频手语合成专门做定制。
4. 实时手语合成，由BH模块复用行为树实现，但是行为树的编排存在差异。
5. 离线文本&离线视频合成由BH模块实现定时任务实现。
6. 离线音视频手语合成音视频用左对齐的方案实现。
7. 离线合成整体的渲染流程与实时渲染保持一致。
8. 表情驱动： 

1. 文本转手语输入文本， 识别用户情感类型及情感强度。
2. 词汇转手语输入用户情感类型和强度， 从而输出数字人表情和动作。(表情和动作是事先标注和制作完成的。)
3. 情感分7个类别和3个强度来进行表情驱动。

• 数据对于手语来说是最核心组成部分。 

1. 数据的产出是特殊人群。
2. 数据的定义和拆解无法靠听人解决。

• 3D手语动作数据的采集方案， 采集成本等等都是没有可参考的成功案例。

3D资产静态生产流程

• 静态资产包含“原画”， “中之人3D超高精度模型5000万面”，“高/中/低灰模”， “蒙皮贴图”， “服装道具”， “头发”， “BS&骨骼绑定”， “蒙皮绑定”。静态资产做完之后， 才能进入动捕阶段。

• 为了降低整体的生产成本， 我们打算使用手语老师作为终止人， 防止由于3D模型服装道具的变化， 引入的动作资产的修改。

• 人物原型设计主要是人物原画的输出。
• 模型制作。

• 蒙皮贴图
• BS面部绑定。
• keypose绑定。
• 衣服&道具制作。

3D动态资产制作

• 动捕设备确定， 最终我们确定使用光学动捕。
• 手套， 使用数据手套进行动捕。
• 动捕场地和供应商由我们指定。
• 动捕完成后 由指定供应商进行精修。

• 动捕资产交付上线。

手语词典

词典组成

数据标注