前不久，OPPO旗下的人工智能助手“小布助手”月度活跃用户数突破一亿，成为国内首个月活用户数破亿的手机语音助手。
经过2年多的成长，小布助手在能力上实现大幅升级，也融入了我们身边便捷的服务功能。小布团队亦克服了诸多技术难点，为用户带来了更智能的服务。为此，小布团队撰写了一系列文章，详细介绍小布助手背后的技术支撑。本文是揭秘小布背后技术的第一篇，主要介绍系统架构设计和演进。
1. 行业价值 1.1 前言 对话系统是一项接近30年研究历史的技术，代表人机交互的未来。近十年来随着语音、NLP领域的阶段性突破和工业界应用日趋成熟，用户价值、行业规模迅速上升。
从场景来看，对话系统大致分为三类
智能助理是以任务型为主，融合问答型、闲聊型，集大成的对话系统产品形态，行业价值潜力巨大。
1.2智能助理 AIoT时代来临，万物互融背景下，智能设备群越来越依赖智能助理做自然的人机交互。智能助理将覆盖千千万万设备，拥有巨大想象空间。
英国市场调研公司Juniper Research预测，到2023年，搭载智能助理的设备将从2018年底的25亿部增加到80亿部。
用户层面来说，智能助理虽然属于小众功能，但是随着智能设备的普及，以及早期用户的逐步培养，熟悉度和认知度在逐步上升，有着较大的上升空间。
智能助理带来的用户价值有三层
效率
个性
情感
随着行业进一步普及，在小屏、无屏、大屏的基础上，逐渐延伸出更多针对垂直场景和人群的智能设备，如教育智能屏、故事机、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架构，下面以小爱为例简要介绍。
小爱：
多路对话管理召回，每个垂域有完整的NLU和Action
流量全垂域分发，用意图预判模型减少流量
中控模块DM的Policy做返回结果的意图选择
2.5 开源方案：rasa rasa基于pipeline架构
Interpreter承担NLU的职责，Tracker+Policy+Action承担DM的职责
模块化设计，特别是interpreter流程可定制
变化最大的action隔离，可嵌入外部server
大量采用配置驱动的设计，基于规则配置完成对话流开发
Rasax提供对话驱动开发方案，评估、标注、测试平台
3. 小布助手工程实践 3.1 对话系统架构设计和演进 OPPO小布助手整体系统分层如下：
其中对话系统为左侧的用户域、对话域、语义域，参考经典pipeline架构搭建。
除语音输出输出相关的基础体验外，对话系统的演进目标大致分两个阶段。
提升技能覆盖率和技能意图识别召准
挖掘提升技能满意度，亮点技能打造
阶段1以垂域快速迭代为核心，阶段2兼顾公共能力建设和垂域对话语义优化为核心。
阶段1：垂域快速迭代 技能覆盖率和单轮意图识别召准为主要目标，对话系统仅需提供强弱多轮的基础能力即可满足本阶段诉求，追求垂域各自制定目标和节奏快速迭代，垂域间低耦合。
设计原则为：
康威定律：[垂域(算法+工程)]，根据feature team划分业务，每个垂域服务端分算法和工程，以此为依据划分服务，负责完整的对话管理和语义理解
低耦合：垂域间工程不耦合，算法除全局排序决策外，各垂域NLU同样不耦合
高内聚：框架抽象常见对话管理功能，中控负责全局调度，垂域服务专注逻辑
阶段2：公共能力建设和垂域优化 技能覆盖和单轮意图识别召准优化到一定程度后，技能满意度偏向对话产品体验，以及亮点技能打造。
本阶段对话语义公共能力存在较多需求，公共建设有助于降低垂域间重复开发和维护成本，保持对话体验一致，以及保障质量和性能。
当前对话管理组件逐步解耦建设中。
设计原则为：
控制反转：垂域的DM服务不直接控制对话，通过抽象协议提供必要信息，由框架和公共对话管理控制和决策对话。其他对话管理组件同理。
单一职责：对话管理各原子能力拆解为对话组件，组件由中控服务编排，降低复杂度，提高复用性。
向下兼容：DM服务过去承担完整对话管理功能，协议扩展保证向下兼容，使DM既能托管对话管理，也能承担对话管理。
阶段1已支持的强弱多轮和意图识别外，跟随产品特性落地逐步建设覆盖以下对话能力，打造对话产品体验和亮点技能。
3.2 对话框架 过去对话系统里，迭代最频繁的业务服务是DM和NLU，分别实现对话逻辑和语义理解。
为解决业务DM服务研发和NLU服务研发的公共问题，抽象出2套框架，DM framework和DAG framework。
DM框架 DM服务输入domain、intent、slot和对话状态，输出技能的action和新的对话状态。
小布助手的DM服务有两个阶段
多路对话管理阶段，DM服务负责完整的对话管理能力
中心对话管理阶段，DM服务负责action的产出，对话管理托管给上层中控服务统一负责
为了解决业务DM服务两个阶段的公共问题，分析如下：
业务流程相似度较大，有统一业务流程的基础
对话管理能力重复建设
代码结构相差很大，不利于新人阅读
各dm服务各自提供sdk供上层调用，接口与协议无法统一集中管理
DM服务开发框架解决以上问题，设计原则如下：
采用分层设计思想，解耦业务逻辑，降低业务的耦合以及相互的影响
采用spring El表达式+注解的形式规范代码的风格以及可读性
依赖倒置+里氏替换原则+面向接口编程解决各业务上层差异化业务逻辑实现
框架使用前 框架使用后 效果
能力重复建设 框架提供默认处理，共同使用框架能力 节约了40%的代码量（Statistic统计技能平台技能由原来9000代码量减少到5000左右)
可维护性，可读性弱 返回协议字段，值来源清晰，抽象统一的处理流程，同时每层提供足够的扩展性 短交接（单个技能交接由平均3天/个缩短为1天/个）
统一协议，统一接口 各dm服务依赖框架的sdk，实现框架对外定义的统一接口 实现了协议的统一，调用的路由注册逻辑
DAG框架 NLU分垂域建设，初期采用python搭建原型，java side car proxy的方式服务化。
逐步暴露部分工程问题：
算法各小组算子能力相似，但调用顺序区别较大，相同的算子能力重复建设，算子的维护成本较大，各小组的算子能力没有实现公用
敏捷迭代小组采用Python实现相应的能力，服务的性能存在一定问题
为了实现技能nlu领域的能力复用，监控完善，性能效率的提高，支持技能nlu领域的快速上线，分层沉淀算子，用DAG框架进行编排。
算子层次设计：
基础类库层负责最底层的能力建设，上层各算子依赖底层基础类库层实现，业务层采用DAG框架将算子组合构建需要执行的流程拓扑图(如下图)，快速搭建领域nlu。
试点业务收益：
平响降低71.8%
单实例并发提升50倍
单技能算子代码复用率95.7%
3.3 性能优化实践 小布助手追求用户的极致体验，流畅度是其中最重要的维度之一。
我们通过高速摄像机拍摄，小布助手与同类产品同时发起交互，到最终返回技能结果展示时间的对比，按照线上query实际占比计算胜出率，作为流畅度核心指标。
以下将主要展开描述流畅度优化的工程实践。
问题分析
服务端三方资源执行耗时占比最大。服务端耗时中，三方资源执行耗时占比最大，80%+
服务端语音识别耗时占比第二。
客户端渲染交互可更简洁。部分垂直技能客户端交互可更简洁，执行可更快
总体解决方案
并行：预测、串改并
剪枝：快慢分层、多级缓存
提速：三方自建、云端VAD、交互简化、执行优化
预测总体思路
预测是架构复杂度较高的特性，展开说明小布助手的实践。
在用户的语音交互过程中，ASR流式中间结果不断上屏，直到尾点识别VAD结束，才会获取完整的用户音频输入。
利用业务特性，预测可以做到“边听边想”，将识别过程和执行过程并行化，缩短串行等待的时间。
分为有2种策略
VAD阶段并行执行，高准确低收益。
识别阶段并行执行，低准确高收益。
当前主体采用第1种策略，在后端请求放大的成本和耗时的优化间平衡。
预测对架构存在较大冲击，实施存在难点。1个请求拆为n-1个非正式预测请求和1个正式请求，且下游无法知道这次请求是否为正式请求，有状态服务会引入副作用导致不正确的结果。
解决问题思路分为3种
每个预测请求回撤状态
正式请求完成后提交状态
改造为无状态
预测方案——每个预测请求回撤状态
实施难点是顺序性难以保证，需要上分布式事务，保证下列步骤在一个事务中。
对话状态回滚undo
对话业务逻辑dialog
对话状态写入write
预测方案——正式请求完成后提交状态
实施难点是
业务逻辑侵入强，每个设计业务状态维护需要改造实现try，confirm和cancel
请求放大，后端写请求增加1/N，通常预测请求N比较小
预测方案——改造为无状态
写状态持久化统一在上游，状态读写通过请求协议携带。对话状态大小1kb以下
部分无法改造为无状态的服务，通过预测判断会走到，返回reject
该方案整体适用于小布助手的数据量，架构更简单优雅，对性能、可用性更友好。
预测收益
部分命中率较高的技能达到70+%，耗时降低60+%
开启的技能整体命中率42.3%，耗时降低43%
4. 挑战与展望 对话系统的算法方案、产品场景不断扩展，链路越发复杂，工程架构扩展性、性能可用性方面将面临较大挑战。
未来小布将考虑以下方向：
☆ END ☆
OPPO互联网技术团队招聘一大波岗位，涵盖C++、Go、OpenJDK、Java、DevOps、Android、ElasticSearch 等多个方向，请点击这里查看详细信息及JD
