技术前沿 | 百度曦灵数字人平台架构分享

全文约3800字，预计阅读15分钟

导读：百度曦灵数字人平台从 2019 年开始研发，平台致力于打造智能的服务型&演艺型数字人，面向金融、媒体，运营商、MCN，互娱等行业，提供全新客户体验及服务。该平台可进一步降低数字人应用门槛，实现人机可视化语音交互服务和内容生产服务，有效提升用户体验、降低人力成本，提升服务质量和效率。

全文目录：

1. 百度智能云数字人发展和现状

2. 架构分析

3. 平台介绍

4. 解决方案介绍

分享嘉宾｜何建斌 百度 ACG AI产品研发部

编辑整理｜张续然 百度

出品社区｜DataFun

01

百度智能云数字人发展和现状

1. 整体说明

百度数字人最早在 2019 年 7 月由百度和浦发银行联合发布。当时百度数字人是业内第一个金融数字人。从 2019 年到今天，我们在数字人方向持续做各种探索和实践，目前百度数字人的客户已经覆盖金融、媒体、运营商等行业。金融行业落地场景如线上理财推荐和线下智能大屏。其中线下智能大屏采用了全双工交互技术，用户不需要说欢迎词就可以直接问数字人问题。此外，金融行业我们还落地了 2D 数字人客服等场景。媒体行业的落地场景如央视康辉数字人和手语数字人直播。通过各类第三方机构的评价可以证明百度数字人目前处于行业第一梯队。

2. 价值主张

在价值主张方面，百度认为通过可视化交互，数字人能够为客户带来全新的客户服务体验。当前传统的交互模式主要有文字客服和语音客服等，在这之上我们判断下一代客服的交互形态会以数字人提供的可视化语音交互为主。这个判断主要源自于数字人带来的三大价值点。

1. 高辨识的品牌形象

基于数字人可以建设可视化的企业 IP 形象，彰显企业科技创新能力，放大 IP 效应带来的客群吸引及宣传作用，最后助力构建线上线下一体化的服务能力。

1. 多触点的客户服务

在渠道触点方面，数字人可以应用于客服、导购、短视频营销和趣味互动等多种场景，一个形象全渠道应用，通过多触点的覆盖能够为客户带来全新的服务体验。

1. 有温度的用户体验

传统的交互方式会让用户感觉和机器在交流，数字人通过模拟面对面的交流形式，能够在单次交互中传递更丰富的信息内容，支持用户随时发问和打断，提供跨终端贴身服务。

3. 功能全景图

百度数字人平台全景图如上所示，从下往上看，AI 引擎是基于百度各种AI能力引擎包括人像驱动引擎、智能对话引擎、语音交互引擎和智能推荐引擎构建百度数字人的基础AI能力。资产生产线包括 3D 写实人像、2D 人像和 3D 卡通人像的统一资产生产和管理。三大平台主要是数字人的业务编排、人设管理和内容创作。业务编排主要用于构建数字人的业务应用场景；人设管理主要用于数字人的形象配置。内容创作主要是基于数字人完成内容生产工作。基于以上所述的平台和能力，百度数字人主要面向两个业务方向输出能力。服务型数字人主要侧重于实现数字人实现对人服务的业务。演艺型数字人主要侧重于通过更好看的形象实现演艺场景。在业务方向之上百度数字人已经构建覆盖金融、运营商、零售、互娱、政务和文旅等多个行业的垂直解决方案。

02

架构分析

1. 数字人简化交互流程

以上是一个简化的数字人交互流程。数字人提供的丰富技术应用能力和场景能力简化下来主要是以下几步：

1. 第一步是用户与数字人对话，需要做 ASR、视频的结构化分析。

2. 第二步是将音视频结构化结果送到对话引擎。

3. 第三步是通过对话引擎对接第三方业务平台，比如在银行场景中用户要查余额，对话系统就需要对接银行的第三方业务系统获取查询结果，然后将查询结果反馈给对话引擎，以便进行下一步处理。

4. 第四步是对话引擎返回需要呈现给用户的内容（文本、动作、Widget）。

5. 第五步是渲染引擎进行渲染并呈现结果给用户。

简单来看，用户和数字人的交互过程就是以上五步。这个过程和做智能对话的服务过程非常相似，主要区别在于第一步的用户输入处理上，数字人系统需要做音频和视频的结构化解析。以及最后一步向客户反馈的内容不仅仅是语音或文本，还有动态的音视频画面。

2. 数字人云端渲染架构

基于以上简化流程经过适当拓展我们可以得出以上架构，这张架构图和之前一张架构图有一定相似性，前述图中的用户可以对应到这张图的客户端；音视频结构化的部分可以拆成多模态分析网关和 ASR。多模态分析网关用于视觉相关的处理；ASR 用于音频转文字的处理。以上处理完的结果会反馈到智能对话引擎，在智能对话引擎提供对话结果后就可以进入渲染数字人的环节。这里需要拆成两部分：文字到音频通过 TTS 实现。画面的渲染通过渲染引擎网关到渲染引擎中实现画面渲染。合成后的音视频流通过百度 BRTC 音视频服务将音视频流推送至前端实现一个可交互的数字人。

此外大家可以看到架构图中有不同类型的连线，这里做下解释。一般交互流程中我们会期待数字人可以很快的向用户做出反馈和应答，如果和一个数字人交互需要 4-5 秒甚至更多的时间做答复，那么其交互体验会非常差。上图中的部分流程我们可以看到是双向流式的，还有部分流程是单向流式的。双向流式在这里实现的是缩短反馈时间的效果，相比传统流程，双向流式不需要等到全部的音频返回再去做音视频流拟合，而是每有 1 帧音频返回就会同步送到下一步流程。通过这种技术我们可以实现数字人在 1 秒左右实现对用户交互问题的应答。

在功能全景中的其他功能也可以快速叠加到这个技术架构之上，比如渲染管线与该架构的集成。只需要业务人员基于业务需要发起建模请求，通过模型工厂服务完成模型的生产，然后生产完的模型会存储在当前架构中。当用户请求数字人服务时，只需要在渲染引擎动态加载模型，这样即可将全景图中数字人工厂的功能添加到本架构中。

同理主播和客服的真人接管能力也可以接入到本架构中。比如在客服真人接管方面，一般来说当智能对话引擎多次兜底后仍无法回答客户问题时，系统会把真人接管的请求推送到客服的业务平台，由客服人员进行人工接管。这时数字人平台会采集客服人员的上行音视频流，采集的音视频流经过动作捕捉和面部捕捉分析后，将相关的指令推送到渲染引擎实现数字人音视频流的渲染。在直播场景中一般没有客服业务平台和对话引擎，这时一般直接通过流程引擎拉取主播的音视频流，后续流程处理与客服真人接管相类似。

除了传统的中心机房渲染外，在实际业务应用上还有边缘渲染和就近推拉流的需求，这时就需要多机房的部署。实现这部分功能需要把相对无状态的服务拆到单个边缘机房内，提供信息共享的服务放在中心机房，然后在比如业务配置中心或者智能对话引擎等服务上同时需要额外增加全局资源池。这样在实际业务中，前端请求服务时首先会到全局资源池做请求，这时返回的是就近机房的服务地址，作为下一步请求的入口。

03

平台介绍

1. 人设管理平台

人设管理平台部分支持对 3D 数字人进行五官的捏制、美容以及服装/发型等元素的自助配置，主要用于增加数字人形象的多样性选择，打造企业专属的数字人形象。

2. 业务编排

数字人作为创新型业务，需要尽量降低用户的试错成本，快速落地验证业务价值。这里百度设计了基于文本的 DRML 语言，支持 0 改动接入客户已有的智能对话系统。DRML 语言是基于纯文本的，对于客户现有的智能对话服务没有特别的要求，数字人会根据文本来渲染其说话内容、动作形象和 Widget 等。这部分功能和 Chatbot 是解耦的，支持对接市面上所有的主流客服平台。由于该能力是文本进文本出，其本身也是对于 SSML 标签的扩展，兼容 SSML 规范。如果客户现有的对话是基于 SSML 配置的，那么不需要太多改动即可实现一个交互型数字人的打造。

百度数字人平台支持拖拽式的流程编排引擎，该引擎主要用于降低用户配置业务的门槛，能够支持 0 代码完成业务的开发。业务流程的开发完全基于拖拽式实现。这里的低代码其实主要分两块，一块指前端的低代码，另一块指后端流程的低代码。前端低代码指的是在页面上组件出现的位置可以自由配置。后端流程的低代码主要指当用户配置流程时，某个按钮在点击后下一步要跳到哪一个节点以及需要呈现什么样的内容。

3. 真人驱动

真人驱动在数字人业务中属于比较常见的能力。在面部捕捉方面，百度支持真人语音驱动数字人，这里百度也做了一个比较有趣的功能——变声器。客服人员可能是多样的，但是通过数字人可以实现千人一面的设计，不仅仅实现形象统一，也可以实现声音统一。在动作捕捉方面，百度支持两种方式，可以在不同场景上各有侧重。第一种是识别用户的动作并触发数字人的预置动作，适合在新闻主播场景中使用。第二种是基于单目 RGB 的视频动作捕捉，适合在平台直播场景中使用。

04

解决方案介绍

1. 虚拟主播

虚拟主播是比较常见的应用场景之一，是通过将数字人形象管理、视频生产和直播能力整合打造的一体化应用方案。这里只需要将数字人形象进行设置和调整，然后通过动作捕捉采集用户的实时形象，再以视频流的形式推送到各大直播平台即可。

此外百度还有手语数字人平台，由于听障群体可能存在受教育水平不足的问题，非常依赖于手语去获取外界的信息，传统的文字和字幕对他们来说可能无法快速阅读。手语数字人主要作为翻译工具解决听障人士的阅读问题。目前百度手语数字人平台已经应用在 CCTV 冬奥会和 NBA 直播等场景。

2. 数字人财富助手

数字人财富助手主要用于通过对话式导购做精准推荐，该方案还支持与短信联动，引导客户进入风评留资环节。

3. 数字人+视频IVR

最后是 VOLTE 视频电话场景，目前支持 VOLTE视频通话的终端设备在全部终端设备中占比超过 70%。该场景通过将数字人和 IVR 结合实现可视化 IVR，以数字人作为虚拟助手协助客户完成业务办理。

05

问答环节

Q1：实施阶段怎么做到数字人口型、语音和表情实时生成的同步？

A1：口型渲染指令和音频数据同步送到渲染引擎即可实现合成阶段的同步生成，合成后的视频流会送到 RTC 服务去，对外输出的音画同步性，依赖传输层的 RTC 服务。

Q2：数字人渲染是基于 Unity 还是 UE 打造的？开发方式如何？

A2：业内主流在使用 UE 开发，开发方式以代码开发为主，低代码方式比较少。

Q3：实时推流的延时大概多久？

A3：这部分延时主要取决于 RTC 的服务，基于百度 BRTC 的数字人视频流单向渲染传播延时大概在 400ms 左右。

Q4：百度是否有考虑终端渲染？

A4：百度对外售卖的产品中具备端渲染技术。在百度产品矩阵中这几种技术都是支持的。具体的落地选择会根据场景决定。比如上文提到的客服场景就非常适合云端渲染，线下摆放的 7*24 小时大屏更适合端渲染（云端渲染需要持续稳定的带宽），具体的技术栈的选择和场景需求有关。

Q5：2D 真人视频驱动动作之间如何拼接？

A5：所有的动作最终都需要回到标准位置，只要动作能回到最终的标准位置就可以实现动作之间的拼接。这里需要选择好模特的视频，在人像动作训练阶段通过 CV 技术弥补动作和原位之间的插帧。

Q6：单个 UE 服务支持的终端有限，如何解决并发问题？

A6：1 对 1 场景单个服务实例仅服务 1 人，通过部署多实例即可提高并发。

今天的分享就到这里，谢谢大家。

｜分享嘉宾｜

何建斌

百度 ACG AI产品研发部

2013年加入百度工作至今，2019年起至今负责百度数字人研发工作。

特别说明：本文仅用于学术交流，如有侵权请后台联系小编删除。

转载来源：DataFunTalk