草庐IT

对话系统简介与OPPO小布助手的工程实践

OPPO小布助手 2023-03-28 原文
前不久，OPPO旗下的人工智能助手“小布助手”月度活跃用户数突破一亿，成为国内首个月活用户数破亿的手机语音助手。

经过2年多的成长，小布助手在能力上实现大幅升级，也融入了我们身边便捷的服务功能。小布团队亦克服了诸多技术难点，为用户带来了更智能的服务。为此，小布团队撰写了一系列文章，详细介绍小布助手背后的技术支撑。本文是揭秘小布背后技术的第一篇，主要介绍系统架构设计和演进。

1. 行业价值

1.1 前言

对话系统是一项接近30年研究历史的技术，代表人机交互的未来。近十年来随着语音、NLP领域的阶段性突破和工业界应用日趋成熟，用户价值、行业规模迅速上升。

从场景来看，对话系统大致分为三类

  • 任务型：答案精确，限定领域，以最简交互满足用户为目标，比如定闹钟。

  • 问答型：答案宽泛，限定领域，以最简交互满足用户为目标，比如百科。

  • 闲聊型：答案宽泛，开放领域，以对话轮次为目标。

智能助手是以任务型为主，融合问答型、闲聊型，集大成的对话系统产品形态，行业价值潜力巨大。

1.2 智能助手

AIoT时代来临，万物互融背景下，智能设备群越来越依赖智能助手进行自然的人机交互。智能助手将覆盖千千万万设备，拥有巨大想象空间。

英国市场调研公司Juniper Research预测，到2023年，搭载智能助手的设备将从2018年底的25亿部增加到80亿部。

用户层面来说，智能助手虽然属于小众功能，但是随着智能设备的普及，以及早期用户的逐步培养，熟悉度和认知度在逐步上升，有着较大的上升空间。

智能助手带来的用户价值有三层

  1. 效率
  2. 个性
  3. 情感

随着行业进一步普及，在小屏、无屏、大屏的基础上，逐渐延伸出更多针对垂直场景和人群的智能设备，如教育智能屏、故事机、AI学习机等。

小布助手是OPPO公司的智能助手，覆盖公司的各类终端设备，并不断增加新入口，覆盖众多任务型、问答型和闲聊型的垂域。

对话系统作为智能助手中的“大脑”，是最核心的技术点之一。有对话系统，智能助手才能理解用户的诉求，用对话式的服务满足用户效率、个性、情感上的需求。

2. 业界架构

2.1 综述

首先介绍对话系统的典型架构。在学术界，对话系统主要有Pipeline和E2E两种架构，其中Pipeline在工业届应用较多，E2E还处在探索阶段。

Pipeline模块化架构

ASR（语音识别Automatic Speech Recognition）

接收音频输入，输出一个转录的句子文本。一般包括四大块：信号处理、声学模型、解码器、后处理，首先采集声音，进行信号处理，将语音信号转化到频域，从N毫秒的语音提出特征向量，提供给声学模型，声学模型负责把音频分类成不同的音素，接着解码器得出概率最高一串词串，最后的后处理就是把单词组合成容易读取的文本。

NLU（自然语言理解Natural Language Understanding）

负责将自然语言表示成计算机能够处理的结构化数据。接收文本输入，输出结构化的三元组Domain（领域）+Intent（意图）+Slot（槽位）。主要通过分词、词性标注、命名实体识别、句法分析、指代消解等进行语义解析。

DM（对话管理Dialog Management）

负责控制整个对话过程。接收NLU的输出，维护一些上下文状态和对话策略，输出具体要执行什么动作，比如进一步询问用户以获得必要的信息。DM是对话系统的主体，有如下2个重要的模块：对话状态跟踪（Dialog State Tracking，后文用DST表述）和对话策略（Dialog Policy，后文用DP表述）。DST记录T-1甚至T-N状态与当前时间T的状态，结合上下文，确定当前的会话状态；DP根据会话状态和具体任务决定要执行什么动作。

ASR和NLU决定了语音交互的下限，DM决定了语音交互的上限。

NLG（自然语言生成Natural Language Generation）

根据DM输出的系统动作，生成回复内容。一般有基于规则模板的方法和基于深度学习的方法。

TTS（文本转换语音Text To Speech）

需要控制多音字的发音和韵律节奏，比如什么地方停顿，字词的轻读或重读。

小结：模块化pipeline架构的优点是可解释性强，易于落地，大部分工业届的任务型对话系统基于此架构。缺点是各模块之间相对独立，难以联合调优，模块之间的误差层层累积。

E2E端到端架构

近年来，随着端到端神经生成模型的发展，为对话系统构建了端到端的可训练框架。这类架构希望训练一个从用户端自然语言输入到机器端自然语言输出的整体映射关系（即合并NLU、DM、NLG作为一个模块），具有泛化和迁移能力强的特点，打破了传统pipeline架构的模块之间的隔离。然而，端到端模型对数据的数量和质量要求很高，效果不可控，并且对于填槽、API调用等过程建模不够明确，工业届应用效果有效，仍在探索中。

接下来，分别介绍不同类型对话系统的典型业界实现。

2.2 微软小冰：聊天型对话系统

微软小冰是开放域聊天的社交聊天机器人，主打“EQ”。一般通过CPS（每次会话的对话轮数）指标来评估聊天机器人的效果，CPS越大，聊天机器人的对话参与能力就越好。小冰的平均CPS有23轮（2017年4月数据）。

下图给出了小冰的整体架构。它包含三层：用户体验层、对话引擎层和数据层。

用户体验层

该层将小冰连接到流行的聊天平台(如微信、QQ)，并以两种模式与用户交流，全双工模式和轮流对话模式。该层还包括一组用于处理用户输入和小冰响应的组件，如语音识别和合成、图像理解和文本规范化。

对话引擎层

由对话管理器、移情计算模块、核心聊天和对话技能组成。对话管理器由DST和DP组成。移情计算通过用户数据、小冰人设等数据输入，计算特征作为DM和技能的输入。闲聊和技能融合生成式和检索式两种不同方案。

数据层

存储收集到的会话数据(文本对或文本图像对)、用于核心会话和技能的非会话数据和知识图谱，以及小冰和所有注册用户的画像。

相关资料可参考：https://arxiv.org/pdf/1812.08989v1.pdf

2.3 小蜜机器人：问答型对话系统

小蜜机器人是经典的pipeline架构，由于客服类机器人的应用场景都是网页上的文本交互，所以不涉及ASR和TTS模块。

它做到了领域化和平台化，面向阿里生态圈、商家生态圈和企业生态圈支持以PaaS和SaaS输出。模块化整个对话管理和流程模块化，构建算法和业务模块可插拔的并行架构体系。

相关资料可参考：https://zhuanlan.zhihu.com/p/33596423

2.4 度秘、小爱、Alexa等智能助手

它们以任务型为主，也包括聊天和问答，度秘、小爱是基于经典的pipeline架构，下面以小爱为例简要介绍。

小爱：

  1. 多路对话管理召回，每个垂域有完整的NLU和Action
  2. 流量全垂域分发，用意图预判模型减少流量
  3. 中控模块DM的Policy做返回结果的意图选择

2.5 开源方案：rasa

rasa基于pipeline架构

  1. Interpreter承担NLU的职责，Tracker+Policy+Action承担DM的职责
  2. 模块化设计，特别是interpreter流程可定制
  3. 变化最大的action隔离，可嵌入外部server
  4. 大量采用配置驱动的设计，基于规则配置完成对话流开发
  5. Rasax提供对话驱动开发方案，评估、标注、测试平台

3. 小布助手工程实践

3.1 对话系统架构设计和演进

OPPO小布助手整体系统分层如下：

其中对话系统为左侧的用户域、对话域、语义域，参考经典pipeline架构搭建。

除语音输出输出相关的基础体验外，对话系统的演进目标大致分两个阶段。

  1. 提升技能覆盖率和技能意图识别召准
  2. 挖掘提升技能满意度，亮点技能打造
阶段1以垂域快速迭代为核心，阶段2兼顾公共能力建设和垂域对话语义优化为核心。

阶段1：垂域快速迭代

技能覆盖率和单轮意图识别召准为主要目标，对话系统仅需提供强弱多轮的基础能力即可满足本阶段诉求，追求垂域各自制定目标和节奏快速迭代，垂域间低耦合。

设计原则为：

  1. 康威定律：[垂域(算法+工程)]，根据feature team划分业务，每个垂域服务端分算法和工程，以此为依据划分服务，负责完整的对话管理和语义理解
  2. 低耦合：垂域间工程不耦合，算法除全局排序决策外，各垂域NLU同样不耦合
  3. 高内聚：框架抽象常见对话管理功能，中控负责全局调度，垂域服务专注逻辑

阶段2：公共能力建设和垂域优化

技能覆盖和单轮意图识别召准优化到一定程度后，技能满意度偏向对话产品体验，以及亮点技能打造。

本阶段对话语义公共能力存在较多需求，公共建设有助于降低垂域间重复开发和维护成本，保持对话体验一致，以及保障质量和性能。

当前对话管理组件逐步解耦建设中。

设计原则为：

  1. 控制反转：垂域的DM服务不直接控制对话，通过抽象协议提供必要信息，由框架和公共对话管理控制和决策对话。其他对话管理组件同理。
  2. 单一职责：对话管理各原子能力拆解为对话组件，组件由中控服务编排，降低复杂度，提高复用性。
  3. 向下兼容：DM服务过去承担完整对话管理功能，协议扩展保证向下兼容，使DM既能托管对话管理，也能承担对话管理。
阶段1已支持的强弱多轮和意图识别外，跟随产品特性落地逐步建设覆盖以下对话能力，打造对话产品体验和亮点技能。

3.2  对话框架

过去对话系统里，迭代最频繁的业务服务是DM和NLU，分别实现对话逻辑和语义理解。

为解决业务DM服务研发和NLU服务研发的公共问题，抽象出2套框架，DM framework和DAG framework。

DM框架

DM服务输入domain、intent、slot和对话状态，输出技能的action和新的对话状态。

小布助手的DM服务有两个阶段：

  1. 多路对话管理阶段，DM服务负责完整的对话管理能力
  2. 中心对话管理阶段，DM服务负责action的产出，对话管理托管给上层中控服务统一负责
为了解决业务DM服务两个阶段的公共问题，分析如下：

  1. 业务流程相似度较大，有统一业务流程的基础
  2. 对话管理能力重复建设
  3. 代码结构相差很大，不利于新人阅读
  4. 各dm服务各自提供sdk供上层调用，接口与协议无法统一集中管理
DM服务开发框架解决以上问题，设计原则如下：

  1. 采用分层设计思想，解耦业务逻辑，降低业务的耦合以及相互的影响
  2. 采用spring El表达式+注解的形式规范代码的风格以及可读性
  3. 依赖倒置+里氏替换原则+面向接口编程解决各业务上层差异化业务逻辑实现

DAG框架

NLU分垂域建设，初期采用python搭建原型，java side car proxy的方式服务化。

逐步暴露部分工程问题：

  1. 算法各小组算子能力相似，但调用顺序区别较大，相同的算子能力重复建设，算子的维护成本较大，各小组的算子能力没有实现公用
  2. 敏捷迭代小组采用Python实现相应的能力，服务的性能存在一定问题
为了实现技能nlu领域的能力复用，监控完善，性能效率的提高，支持技能nlu领域的快速上线，分层沉淀算子，用DAG框架进行编排。

算子层次设计：

基础类库层负责最底层的能力建设，上层各算子依赖底层基础类库层实现，业务层采用DAG框架将算子组合构建需要执行的流程拓扑图(如下图)，快速搭建领域nlu。

试点业务收益：

  1. 平响降低8%
  2. 单实例并发提升50倍
  3. 单技能算子代码复用率7%

3.3  性能优化实践

小布助手追求用户的极致体验，流畅度是其中最重要的维度之一。

我们通过高速摄像机拍摄，小布助手与同类产品同时发起交互，到最终返回技能结果展示时间的对比，按照线上query实际占比计算胜出率，作为流畅度核心指标。

以下将主要展开描述流畅度优化的工程实践。

问题分析

  1. 服务端三方资源执行耗时占比最大。服务端耗时中，三方资源执行耗时占比最大，80%+
  2. 服务端语音识别耗时占比第二
  3. 客户端渲染交互可更简洁。部分垂直技能客户端交互可更简洁，执行可更快

总体解决方案

  1. 并行：预测、串改并
  2. 剪枝：快慢分层、多级缓存
  3. 提速：三方自建、云端VAD、交互简化、执行优化

预测总体思路

预测是架构复杂度较高的特性，展开说明小布助手的实践。

在用户的语音交互过程中，ASR流式中间结果不断上屏，直到尾点识别VAD结束，才会获取完整的用户音频输入。

利用业务特性，预测可以做到“边听边想”，将识别过程和执行过程并行化，缩短串行等待的时间。

分为有2种策略

  1. VAD阶段并行执行，高准确低收益。
  2. 识别阶段并行执行，低准确高收益。
当前主体采用第1种策略，在后端请求放大的成本和耗时的优化间平衡。

预测对架构存在较大冲击，实施存在难点。1个请求拆为n-1个非正式预测请求和1个正式请求，且下游无法知道这次请求是否为正式请求，有状态服务会引入副作用导致不正确的结果。

解决问题思路分为3种：

  1. 每个预测请求回撤状态
  2. 正式请求完成后提交状态
  3. 改造为无状态
预测方案——每个预测请求回撤状态

实施难点是顺序性难以保证，需要上分布式事务，保证下列步骤在一个事务中。

  1. 对话状态回滚undo
  2. 对话业务逻辑dialog
  3. 对话状态写入write

预测方案——正式请求完成后提交状态

实施难点是：

  1. 业务逻辑侵入强，每个设计业务状态维护需要改造实现try，confirm和cancel
  2. 请求放大，后端写请求增加1/N，通常预测请求N比较小

预测方案——改造为无状态

  1. 写状态持久化统一在上游，状态读写通过请求协议携带。对话状态大小1kb以下
  2. 部分无法改造为无状态的服务，通过预测判断会走到，返回reject

该方案整体适用于小布助手的数据量，架构更简单优雅，对性能、可用性更友好。

预测收益

部分命中率较高的技能达到70+%，耗时降低60+%

开启的技能整体命中率42.3%，耗时降低43%

4. 挑战与展望

对话系统的算法方案、产品场景不断扩展，链路越发复杂，工程架构扩展性、性能可用性方面将面临较大挑战。

  • 算法方案：NLU优化从单轮走向多轮、对话决策规则走向模型、标准化走向个性化
  • 产品场景：多设备、多入口、多模态
未来小布将考虑以下方向：

  • 对话系统组件化解耦：云侧扩展性，中控微内核，组件响应算法产品变化，组件公共库治理性能可用性
  • 端云交互机制优化：端侧扩展性，对话系统异步响应端侧变化事件，适应多设备、多入口、多模态复杂交互的变化
  • 开放协议和SDK：对内提供业务扩展点，集中公司力量建设小布助手科技品牌；对外结合技能平台，扩展技能生态
小布助手strong人工智能对话系统智能助手自然语言处理机器学习深度学习

有关对话系统简介与OPPO小布助手的工程实践的更多相关文章

  1. ruby-on-rails - 使用 Ruby on Rails 进行自动化测试 - 最佳实践 - 2

    很好奇，就使用ruby​​onrails自动化单元测试而言，你们正在做什么？您是否创建了一个脚本来在cron中运行rake作业并将结果邮寄给您？git中的预提交Hook？只是手动调用？我完全理解测试，但想知道在错误发生之前捕获错误的最佳实践是什么。让我们理所当然地认为测试本身是完美无缺的，并且可以正常工作。下一步是什么以确保他们在正确的时间将可能有害的结果传达给您？ 最佳答案 不确定您到底想听什么，但是有几个级别的自动代码库控制:在处理某项功能时，您可以使用类似autotest的内容获得关于哪些有效，哪些无效的即时反馈。要确保您的提

  2. 叮咚买菜基于 Apache Doris 统一 OLAP 引擎的应用实践 - 2

    导读：随着叮咚买菜业务的发展，不同的业务场景对数据分析提出了不同的需求，他们希望引入一款实时OLAP数据库，构建一个灵活的多维实时查询和分析的平台，统一数据的接入和查询方案，解决各业务线对数据高效实时查询和精细化运营的需求。经过调研选型，最终引入ApacheDoris作为最终的OLAP分析引擎，Doris作为核心的OLAP引擎支持复杂地分析操作、提供多维的数据视图，在叮咚买菜数十个业务场景中广泛应用。作者｜叮咚买菜资深数据工程师韩青叮咚买菜创立于2017年5月，是一家专注美好食物的创业公司。叮咚买菜专注吃的事业，为满足更多人“想吃什么”而努力，通过美好食材的供应、美好滋味的开发以及美食品牌的孵

  3. 电脑0x0000001A蓝屏错误怎么U盘重装系统教学 - 2

    　　电脑0x0000001A蓝屏错误怎么U盘重装系统教学分享。有用户电脑开机之后遇到了系统蓝屏的情况。系统蓝屏问题很多时候都是系统bug，只有通过重装系统来进行解决。那么蓝屏问题如何通过U盘重装新系统来解决呢？来看看以下的详细操作方法教学吧。　　准备工作：　　1、U盘一个（尽量使用8G以上的U盘）。　　2、一台正常联网可使用的电脑。　　3、ghost或ISO系统镜像文件（Win10系统下载_Win10专业版_windows10正式版下载-系统之家）。　　4、在本页面下载U盘启动盘制作工具：系统之家U盘启动工具。　　U盘启动盘制作步骤：　　注意：制作期间，U盘会被格式化，因此U盘中的重要文件请注

  4. 【鸿蒙应用开发系列】- 获取系统设备信息以及版本API兼容调用方式 - 2

    在应用开发中，有时候我们需要获取系统的设备信息，用于数据上报和行为分析。那在鸿蒙系统中，我们应该怎么去获取设备的系统信息呢，比如说获取手机的系统版本号、手机的制造商、手机型号等数据。1、获取方式这里分为两种情况，一种是设备信息的获取，一种是系统信息的获取。1.1、获取设备信息获取设备信息，鸿蒙的SDK包为我们提供了DeviceInfo类，通过该类的一些静态方法，可以获取设备信息，DeviceInfo类的包路径为：ohos.system.DeviceInfo.具体的方法如下：ModifierandTypeMethodDescriptionstatic StringgetAbiList​()Obt

  5. kvm虚拟机安装centos7基于ubuntu20.04系统 - 2

    需求：要创建虚拟机，就需要给他提供一个虚拟的磁盘，我们就在/opt目录下创建一个10G大小的raw格式的虚拟磁盘CentOS-7-x86_64.raw命令格式：qemu-imgcreate-f磁盘格式磁盘名称磁盘大小qemu-imgcreate-f磁盘格式-o?1.创建磁盘qemu-imgcreate-fraw/opt/CentOS-7-x86_64.raw10G执行效果#ls/opt/CentOS-7-x86_64.raw2.安装虚拟机使用virt-install命令，基于我们提供的系统镜像和虚拟磁盘来创建一个虚拟机，另外在创建虚拟机之前，提前打开vnc客户端，在创建虚拟机的时候，通过vnc

  6. HBase Region 简介和建议数量&大小 - 2

    Region是HBase数据管理的基本单位,region有一点像关系型数据的分区。region中存储这用户的真实数据，而为了管理这些数据，HBase使用了RegionSever来管理region。Region的结构hbaseregion的大小设置默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的RegionServer，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的RegionServer。RegionSplit时机：当1个region中的某个Store下所有StoreFile

  7. ruby - Hanami link_to 助手只呈现最后一个元素 - 2

    我是HanamiWorld的新人。我已经写了这段代码:moduleWeb::Views::HomeclassIndexincludeWeb::ViewincludeHanami::Helpers::HtmlHelperdeftitlehtml.headerdoh1'Testsearchengine',id:'title'hrdiv(id:'test')dolink_to('Home',"/",class:'mnu_orizontal')link_to('About',"/",class:'mnu_orizontal')endendendendend我在模板上调用了title方法。htm

  8. ruby-on-rails - Rails 中同一个类的多个关联的最佳实践？ - 2

    我认为我的问题最好用一个例子来描述。假设我有一个名为“Thing”的简单模型，它有一些简单数据类型的属性。像...Thing-foo:string-goo:string-bar:int这并不难。数据库表将包含具有这三个属性的三列，我可以使用@thing.foo或@thing.bar之类的东西访问它们。但我要解决的问题是当“foo”或“goo”不再包含在简单数据类型中时会发生什么？假设foo和goo代表相同类型的对象。也就是说，它们都是“Whazit”的实例，只是数据不同。所以现在事情可能看起来像这样......Thing-bar:int但是现在有一个新的模型叫做“Whazit”，看起来

  9. ruby-on-rails - 向 Rails 3 添加 Ruby 扩展方法的最佳实践？ - 2

    我有一个要在我的Rails3项目中使用的数组扩展方法。它应该住在哪里？我有一个应用程序/类，我最初把它放在(array_extensions.rb)中，在我的config/application.rb中我加载路径:config.autoload_paths+=%W(#{Rails.root}/应用程序/类)。但是，当我转到railsconsole时，未加载扩展。是否有一个预定义的位置可以放置我的Rails3扩展方法？或者，一种预先定义的方式来添加它们？我知道Rails有自己的数组扩展方法。我应该将我的添加到active_support/core_ext/array/conversion

  10. ruby - 在没有基准或时间的情况下用 Ruby 测量用户时间或系统时间 - 2

    因为我现在正在做一些时间测量，我想知道是否可以在不使用Benchmark类或命令行实用程序time的情况下测量用户时间或系统时间。使用Time类只显示挂钟时间，而不显示系统和用户时间，但是我正在寻找具有相同灵active的解决方案，例如time=TimeUtility.now#somecodeuser,system,real=TimeUtility.now-time原因是我有点不喜欢Benchmark，因为它不能只返回数字(编辑:我错了-它可以。请参阅下面的答案。)。当然，我可以解析输出，但感觉不对。*NIX系统的time实用程序也应该可以解决我的问题，但我想知道是否已经在Ruby中实

随机推荐