关于人工智能:对话系统简介与OPPO小布助手的工程实践

1次阅读

共计 5729 个字符,预计需要花费 15 分钟才能阅读完成。

前不久,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.08…

2.3 小蜜机器人:问答型对话零碎

小蜜机器人是经典的 pipeline 架构,因为客服类机器人的利用场景都是网页上的文本交互,所以不波及 ASR 和 TTS 模块。

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

相干材料可参考:https://zhuanlan.zhihu.com/p/…

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 实现相应的能力,服务的性能存在肯定问题
  3. 为了实现技能 nlu 畛域的能力复用,监控欠缺,性能效率的进步,反对技能 nlu 畛域的疾速上线,分层积淀算子,用 DAG 框架进行编排。

算子档次设计:

根底类库层负责最底层的能力建设,下层各算子依赖底层根底类库层实现,业务层采纳 DAG 框架将算子组合构建须要执行的流程拓扑图 (如下图),疾速搭建畛域 nlu。

试点业务收益:

  1. 平响升高 71.8%
  2. 单实例并发晋升 50 倍
  3. 单技能算子代码复用率 95.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:对内提供业务扩大点,集中公司力量建设小布助手科技品牌;对外联合技能平台,扩大技能生态
正文完
 0