跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践

作者:吴淑明 达摩院机器智能技术团队

当前手语内容覆盖有限,听障人士难以从影音内容中获取更多的信息,在交流场景下也面临着沟通障碍。如何才能提升听障人士在社会生活日常沟通中的效率?本文将为大家分享虚拟数字人「手语翻译官」的技术实现。

一、背景

1.1 用户规模

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

1.2 聋人生活中的困境

  • 与健听人的简单交流,即便使用文字也不能顺畅交流,再加上部分年长受教育程度低的人群,文字交流也困难。

  • 由于听障人群的受教育程度以及独特表达和理解方式,导致他们的文字表述和语法结构与健听人完全不同,即便通过文字也无法便捷无障碍的与健听人沟通。听障人群与健听人之间的沟通障碍,严重影响了听障人群的生活质量。听障人群与健听人的沟通需求主要集中在几下情况:

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

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

听人完全看不懂,这是在说什么?

深度交流:听障人士需要与听人进行深度的交流,通常是有一定专业性、复杂性的交流场景,如就医、水电煤银网办事等;

信息获取难度大:听障人士需要从听人世界的影音内容中获取更多的信息,而当前手语内容覆盖有限。

二、产品设计

2.1 产品调研

2.1.1 调研用户画像

听障人士:

1)听力受损程度在中重度及以上,在参与社会生活方面存在中度障碍,借助我们提供的产品,能有效提升其社会生活日常沟通效率;

2)会相对标准的手语,其通过手语所表达出的信息,在听障人群中,能被大多数听障人士看懂并理解;

3)至少具备普通智能手机使用能力。

听人:

1)与听障人士密切生活的非听障人群,与听障人士有较大的日常交流沟通诉求;

2)公共服务机构(政府、银行、医院、快递、商场等)的工作人员在日常工作中,可能会遇到要为听障人群提供服务的场景。

2.1.2 痛点场景

简单交流:听障人士需要与听人进行简短的交流,对话轮次通常不超过10轮即可完成,内容为日常生活所需的交流场景,如日常购物、出行、问询、工作交办;

深度交流:听障人士需要与听人进行深度的交流,通常是有一定专业性、复杂性的交流场景,如就医、水电煤银网办事等;

信息获取:听障人士需要从听人世界的影音内容中获取更多的信息,而当前手语内容覆盖有限;

参加会议:听障人士需要从有声会议中获取会议信息,当前主要通过讯飞的语音识别技术转成文字;

2.1.3 线下调研

场景一:A开车途中遇停车时,接打视频电话。

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

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

场景二:A到达法院后,寻找联系对象。

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

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

场景三:A和法官沟通案件细节。

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

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

2.1.4 双向手语翻译的难点

1)我们就是第一人

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

2)巧妇难为无米之炊

由于听障朋友对外交流有限,已有手语数据存留较少,且具备手语能力的人群数量较少,进一步减缓了数据沉淀的速度。与语音识别、语种互译相比,获取充足、高质量的手语数据难度不言而喻。

3)手语的区域特性

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

4)手语是视觉语言

手语是一门视觉语言,语言表达顺序与自然语言完全不同且没有固定语法约束。手语生成需要生成符合听障人群表达习惯,便于理解的语言;相当于学习了一门新的语言,而不是单纯的逐字翻译,例如:自然语言中“灭火”在手语中的表达是“火→灭”,因为先看到火才能灭。

5)纯视觉方案的手语识别

相对于现有基于昂贵传感器的手语识别,我们是首个采用纯视觉方案(仅依赖手机摄像头),需要实时精准的图像处理算法研发,从捕获的手语视频中提取有效的空时信息,进行手语识别。

这里涉及实时高效的处理高维度的视频数据,同时要处理手语本身的多元性、多样性表达。这对视觉算法提出了更高的要求。

手语语速快,动作精细和多变,动作间相似度高。

6)工程难度大

业务并发量大:与以往的工程架构不同(接口调用),现阶段提供流媒体服务,若高并发的时候需要大规模的集群和资源调度。

响应延时问题:流媒体本身就有几百毫秒的延时,再加上双向翻译的流程中嵌入了大量的算法模块,导致延时加长。延时翻译非常影响产品的交互体验。

2.2 双向手语翻译

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

产品链路:

跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践_第1张图片

2.3 手语合成

可以在数字人手语播报平台进行手语内容的生产:

https://avatar.aliyun.com/#home

三、技术落地

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

3.1 技术方案设计

1)因为涉及实时图像识别,对于网络带宽的要求非常高,所以我们当前将视觉相关算法和流媒体部署在同一个pod,从而降低网络开销及识别时延。

2)手语识别技术最大难度是“手语识别的图像数据来源,以及图像数据的标注团队”,技术上必须解决训练数据的生成效率问题。

3)由于听障和听人信息交互方式存在差异,听障朋友给出的是物理世界能形容的事物,整句话是由一堆动/名词组成,还会涉及到倒装,所以必须加一个手语词汇转自然文本的翻译模块。

4)相同与第3点,手语合成也需要一个文本转手语模块,将自然文本转换成手语词汇,同时面临第2点一样的数据问题。

  • 专有名词解释

    媒体服务:流媒体模块,负责编&解码,rtc渠道的订阅和推送,本地视频转码录制,解码后图片推送。

    手语识别:算法模块,按照协定的图片格式输入图片,输出一系列手语词汇。

    手语转文本:算法模块,输入手语词汇,输出自然文本。

    手语合成:算法模块,输入手语词汇,情绪及等级,输出手语keypose和bs数据。

  • 文本转手语:算法模块,输入自然文本,输出手语词汇,并且传输给BH模块。

  • 行为交互逻辑:工程模块,统一决策调用数字人交互逻辑。

  • agent:工程模块,负责各个POD容器之间的消息传输。

  • 3D渲染引擎:渲染模块,负责数字人实时渲染,生成数字人帧数据。

3.2 方案落地

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

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

  • 解决ASR识别不准确问题, 可实时在线进行人工干预。

  • 解决手语识别不准确的情况下进行人工干预。

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

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

1)手语识别帧数据要求为10FPS、360P。

2)端上通过RTC将帧数据推送上来。

3)media在数字人没有启动的前提下,会自动向手语转手语词汇模块发送空白帧数据,空白帧数据为全0图片数据,算法不会产出任何结果。

4)数字人开始工作后,流媒体解码出第一帧时候,并且发送手语转手语词汇模块,  手语识别才开始工作,手语转手语词汇发送识别结束事件给行为树。

5)手语识别中间会实时返回识别结果,结果为累积数据,并且通过手语识别结果事件发送给行为树模块。

6)行为树模块将手语识别结果发送给手语词汇转自然文本模块。

7)手语词汇转自然文本模块会产生手语识别结束事件,并且进行本地redis缓存。

8)行为树决策引擎,等收到手语识别结束后,行为树向前端发送手语识别结束事件,默认回到数字人界面,等待播报内容。

9)如果需要进行语音播报,行为树会发送播报文案给媒体,并且发送文案给前端展示,流媒体合成tts后,插入到流媒体里面。

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

跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践_第2张图片

  • 实时手语合成算法处理方案

    关于手语标注数据,可以参考《手语众包》这一章节。

    算法核心会计算词汇动作与词汇动作之间的过渡帧,及词汇动作到空闲动作的过渡帧,这要求数据标注的时候,尽量标注出空间最接近于空闲动作的那一帧数据。

  • 实时手语合成unity处理方案,通过实时渲染加媒体视频编码转RTC的方式实现。

行为树编排

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

例如:

用户切换成手语识别时, TTS要主动打断。

用户呼叫时, 要等待C端用户订阅流成功后, 数字人才开始打招呼。

TTS开始播报是, TTS文案才显示在前端页面。

TTS结束播报后, TTS自动消失, 或者长期维持不变。

1)行为树提供大量的流程控制方法,使得状态之间的改变更加直观;

2)整个游戏AI使用树型结构,方便查看与编辑;

3)方便调试和代码编写;

4)最重要的:行为树方便制作编辑器,可以交由策划人员使用。

3.2.2 手语合成

1)算法及协议复用单设备单工流程,修改行为树逻辑实现,仅实现行为树任务流程管理。

2)实时手语翻译、离线文本手语翻译及视频手语翻译保持同一套架构。

3)离线音视频手语合成,因为手语的速度与音频播报速度不一致,针对手语给出的时间消耗是不一样的,所以需要离线音视频手语合成专门做定制。

4)实时手语合成,由BH模块复用行为树实现,但是行为树的编排存在差异。

5)离线文本&离线视频合成由BH模块实现定时任务实现。

6)离线音视频手语合成音视频用左对齐的方案实现。

7)离线合成整体的渲染流程与实时渲染保持一致。

8)表情驱动:

  • 文本转手语输入文本,识别用户情感类型及情感强度。

  • 词汇转手语输入用户情感类型和强度,从而输出数字人表情和动作。(表情和动作是事先标注和制作完成的。)

  • 情感分7个类别和3个强度来进行表情驱动。

四、数据生产

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

  • 数据的产出是特殊人群。

  • 数据的定义和拆解无法靠听人解决。

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

4.1 3D数据资产

4.1.1 3D资产静态生产流程

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

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

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

  • 模型制作

  • 蒙皮贴图

  • BS面部绑定

  • keypose绑定

  • 衣服&道具制作

4.1.2 3D动态资产制作

  • 动捕设备确定,最终我们确定使用光学动捕。

  • 手套,使用数据手套进行动捕。

  • 动捕场地和供应商由我们指定。

  • 动捕完成后由指定供应商进行精修。

  • 动捕资产交付上线。

4.2 手语众包

4.2.1 手语词典

难点:如何组织一批无法沟通,特殊领域的群体,生产我们需要的数据。因此我们选择支付宝作为手语众包的载体。

4.2.2 词汇定义

  • 词根:指单一一个手语动作,最小手语颗粒度

  • 融合词汇:由多个词根组成的手语词汇

  • 专有名词:应用于特殊领域的专业词汇

  • 敏感词:指不可以进行播报的词汇,比如涉黄、涉毒等等

  • 一词多义:一个自然词汇有多种打法

  • 相似打法:一种打法可以映射到多个自然词汇上

4.2.3 词典组成

跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践_第3张图片

4.2.4 数据标注

跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践_第4张图片

跨越声音障碍,虚拟数字人「手语翻译官」开发落地实践_第5张图片

你可能感兴趣的:(数字人,虚拟人,人工智能,技术温度)