写点什么

QCon- 小布助手对话系统工程实践

  • 2021 年 12 月 29 日
  • 本文字数:4706 字

    阅读完需:约 15 分钟

1 智能助手和对话系统的价值

智能助理是蓬勃发展的行业,用户诉求非常强烈,目前远没有达到可以满足用户的程度。

  1. 第一层面的用户对于效率要求非常高,一句话搞定的事情不会说两句话。

  2. 第二层面的用户需要非常贴心的、智慧懂我的、类似于个人助理一样的角色。

  3. 第三层面的用户,智能助理作为倾诉的出口,满足人类情感需求。


在近几年不断涌现的智能设备,印证了 Kevin Kelly 预言的“智化”趋势。以苹果为首,打造耳机、手表等多款风靡全球、让人怦然心动的产品,也出现了机器人等创新智能设备。未来智能家居、个人穿戴、智慧出行等各行业,都可以清晰预见“智化”的设备将会爆发式的增长。


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

图1:智能助手行业背景

小布助手正是软硬服一体的科技公司——OPPO 在智能助理赛道里面的重量级产品。自 2019 年上线以来,增长非常迅速,目前已经达到了 2.5 亿设备覆盖,1.3 亿月活用户。

图2:小布助手规模

小布助手作为 OPPO 唯一的智能助理,除手机以外,覆盖众多 OPPO 旗下的智能设备。同时在手机中不同的 app 入口,也有着小布助手的身影,如闹钟、商店等等。


小布助手拥有 260+技能,如天气、系统操控、闲聊交互,是一个满足用户宽泛需求的产品。

图3:小布助手业务场景

小布助手里最核心的系统——对话系统,覆盖三类典型的对话系统场景。

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

  2. 问答型:答案宽泛,限定领域,以最简交互满足用户为目标。比如百科。

  3. 闲聊型:答案宽泛,开放领域,以对话轮次为目标。

图4:对话系统典型业务场景

2 小布助手对话系统业务架构

工业界通常基于典型的 Pipeline 方式实现,较少使用 E2E 的方式。

  1. ASR:语音信号输入,未来包括多模态的扩展,转换成文本。

  2. NLU:输入文本,经过模型分类、提取,转换为结构化的意图和槽位。

  3. DM:维护上下文的对话状态,通过上文的对话状态以及本轮的结构化输入,更新至新的对话状态,输出 action。

  4. NLG:输入 action,转换为人可以听懂文本。

  5. TTS:输入文本,转换为人声音频。

图5:对话系统经典pipeline

上述基线的 Pipeline 满足理想、简单的场景。小布助手的业务架构实践的过程中,有两点思考。

第一,多领域如何融合。小布助手可以支持非常多的技能,分布在不同领域的技能怎么做融合?

第二,多领域的业务架构之下,怎么对性能和成本做折中?

图6:小布助手对话系统pipeline

小布助手对 pipeline 有如下改动。

  1. 新增 rank,可理解为多领域顶层的 DP(dialog policy)。

  2. RG,与 NLG 对等,除文本生成外,还包含资源获取。

  3. 新增 Post rank,对资源做校验。


多领域融合问题,原则为尽可能领域自治,分为 2 个子问题,多领域结果排序和跨领域结果融合。

  1. 多领域结果排序:rank 负责。同时为简化复杂度,当前不对具体 action 做排序,对 DM 来源做排序。

  2. 跨领域结果融合:DM 负责。跨领域 intent 输入 DM,进行跨域融合逻辑处理。


效果、性能和成本折中问题,rank 模块位置是关键。

  1. Rank 位置处于最后,与 post rank 合并,即多领域多路召回-排序的方式。慢资源需要全量召回,在性能和成本上存在问题。

  2. Rank 位置处于 NLU+DST 后,即强化学习 MDP 架构。Rank 相当于顶层 DP,此时只含 NLU 和 DST 信息,从长期效果天花板考虑希望有更多特征参与排序。

  3. Rank 选择中间位置,折中效果、性能和成本。性能和成本上,由于已选取 top action,过滤大量慢资源请求。效果上,action 已带出除资源外的特征,最大程度保证效果提升空间。

3 小布助手流畅度优化实践

小布助手用户体验中,流畅度优化是一个关键点。用户从唤醒说话,到最后看到结果的阶段当中,真实感知的延迟在中间,即从用户结束说话到看到结果。流畅度优化目标就是这段用户可感知 RT。


小布助手流畅度遇到 top 问题为:

  1. 服务端三方资源执行耗时占比最大。服务端 580ms 耗时中,三方资源执行耗时占比最大,80%+。

  2. 服务端语音识别耗时占比第二。端云语音识别耗时中,尾点识别耗时 380ms-600ms。

  3. 客户端渲染交互可更简洁。部分垂直技能客户端交互可更简洁,执行可更快。


前两部分占比已经很大,且外部原因无法有效控制缩短 RT,对流畅度优化有很大的挑战。

图7:小布助手对话系统pipeline

以几个小故事来为例,类比在三方不受控时,如何优化耗时性能。小 A 跟小 B 抢答提问,可以自己去回答,也可以依赖外援,类比对话系统,外部耗时无法控制,只能控制自己的策略,帮助小 A 战胜小 B。

图8:提问抢答类比示意图

故事 1:

小 A:看我 ctrl c+v 大法,并发请求擅长的外援,同时翻笔记。

小 A:说不定小 B 串行请求外援,肯定比他快。

图9:整体并发

几回合下来,小 B 多数时候比小 A 还快一点!

小 B:我早就分析过 1 号外援速度最慢,只能额外覆盖 20%的答案。

小 B:对笔记和外援做快慢分层,就算 20%情况串行,80%我不需要傻等,当然比小 A 快。

图10:快慢分层

小布助手通过快慢分层,RT 降低约 100ms,层级可灵活编排。


故事 2:

小 A 照抄小 B 策略后,反应还是慢半拍。

小 A:你是不是还分析出外援的什么特点了?

小 B:没错。我发现外援 3 的回复占了 40%,所以我拿到问题想都不想,预发给外援 3,反应当然比你快一点。

图11:预发

小布助手通过预发,RT 降低约 20ms。


故事 3:

小 A 不甘心,暗下决心要想个妙招。

小 A:主持人没说完,我就能预测到他完整问题,要是偷跑不就能遥遥领先?

图12:预测

果真小 A 比小 B 答得更快!

但是好景不长,小 A 发现外援的答案经常给错,害小 A 扣了不少分。

小 A 心想原因是什么呢? 

图13:预测错误示意图

A:原来是外援认为预测请求是正式请求的上文,正式请求本应理解为“谁和 X 同时出书”,实际理解为“谁和 Y 同时出书”。

A:没想到状态引入副作用,预测是不是没法用了?

预测在搜索引擎等系统里面行业内有采用,需要在用户体验和成本上折中。

在小布助手里面主要难点对架构的冲击比较大。预测需要把一个请求拆分为请求序列,N-1 个预测的非正式请求,1 个正式请求,下游无法知道请求是否为正式请求,处理过程中要避免 N-1 个非正式请求引入状态副作用,否则会因为多轮状态错乱导致不正确的结果。


预测方案 1——每个预测请求回撤状态

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

  1. 对话状态回滚 undo

  2. 对话业务逻辑 dialog

  3. 对话状态写入 write

图14:预测状态回滚方案示意图

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

实施难点是:

  1. 业务逻辑侵入强,每个设计业务状态维护需要改造实现 try,confirm 和 cancel.

  2. 请求放大,后端写请求增加 1/N,通常预测请求 N 比较小。

图15:预测tcc方案示意图

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

  1. 写状态持久化统一在上游,状态读写通过请求协议携带。对话状态大小 1kb 以下。

  2. 部分无法改造为无状态的服务,通过预测判断会走到,返回 reject.

图16:预测无状态方案示意图

该方案整体适用于小布助手的数据量,架构更简单优雅,对性能、可用性更友好。开启的技能整体命中率 42.3%,耗时收益 173ms。


进一步的抽象,传统对话系统是同步系统,真实世界是异步对话的过程。真实世界对话不是一来一回的,存在相互重叠、相互打断、多次穿插、间隔沉默等异步的现象,对于对话系统而言,输入和输出的节奏不固定。


行业内使用全双工方案来解决以上问题,小布助手通过建设节奏控制器模块,将单工、双工场景下的外部异步节奏转换为下游系统的同步处理。包含本文提及的预测、预发等输入节奏控制策略;本文未提及的铺垫对话、主动对话等输出节奏控制策略。为解决收音提前结束、收音停不下的问题,判停、判不停的输入节奏控制策略当前实践中。

图17:节奏控制器模块职责

4 小布助手微服务实践

小布助手经历三个阶段的架构演进:

  1. 起步阶段,2019 年快速上线核心功能的原形系统。

  2. 快跑阶段,功能和团队快速扩展的主要矛盾下,进行微服务架构升级。

  3. 冲锋阶段,体验、技术能力深耕。

图18:小布助手技术架构演进三阶段

微服务架构升级,从业务架构上构建五个领域以及六个业务快速独立迭代,速度提升了 472%,取得显著效果。本章不展开介绍领域设计和业务架构演变,将聚焦在微服务技术架构。

图19:小布助手领域设计

微服务架构大幅提升架构复杂性,采用最适合自身业务和团队的技术架构,保障系统质量和实施成本可控。

质量保障的第一步,是能捕获故障。

  1. 故障发现:得益于 OPPO 云比较完善的基础设施条件,打造立体监控较低。

  2. 故障定位:对话系统的背景下,秒级埋点聚合的全链路 debug 平台大幅度提升排查效率。

图20:微服务解耦技术架构原则——可维护性

质量保障的第二步,是采用高可用架构降低故障概率,并提供自愈恢复和手工恢复能力。


故障概率:

  1. 同城双活:降低单机房故障导致全局故障的概率。

  2. 轻重分离:小布助手系统重算法,算法服务比工程服务通常更脆弱,通过隔离部署减少故障影响范围和概率。算法服务采用 sidecar 统一服务治理能力降低故障概率。


自动恢复:

  1. 限流拒绝:自研服务过载拒绝策略做上下游服务保护,避免压垮,流量异常后系统可自动恢复。

  2. 熔断降级:第三方不可控的外部系统熔断降级需要更完备,特别是长连接服务,外部系统异常后能马上切换备份系统做自动恢复。


手动恢复:

  1. 同城双活:来源于单一单元链路上的大面积未知故障,通过手动切流快速恢复,控制影响面。

  2. 灰度回滚:来源于发布上线过程引入的故障,灰度发布控制故障影响面,回滚提供手动快速恢复。微服务本身较容易实现,数据如何实现灰度发布和回滚较困难,过程中的数据。

图21:微服务解耦技术架构原则——可靠性

质量保证的第三步,不管是正常情况,还是异常恢复过程的数据一致性和正确性,如何低成本实施保证?

  1. 业务透明:在线数据一致性问题集中处理,做到业务透明。写状态集中到聚合服务,业务服务无状态,同城双活 redis 双向同步等存储中间件的一致性问题只有聚合服务关注。

  2. 业务无状态:协议携带状态数据透传至下游业务服务读状态,实现业务服务无状态。大部分无状态业务服务接口幂等,存在少量依赖第三方非幂等服务导致自身接口无法做到幂等。

  3. 单元发布:离线数据通过中心单元的管理后台,单向发布至在线实例。对话系统场景下,主要发布元数据,进行 sqlite 快照全量版本控制,低成本保证发布和回滚中数据一致性和正确性。

图22:微服务解耦技术架构原则——一致性

技术架构选型中,为什么使用 sqlite?

问题抽象为管理后台数据自动发布至在线服务,实现数据库版本控制和灰度发布。

  1. 数据支持版本控制

  2. 数据按研发流程发布至各单元

  3. 数据按实例灰度生效和回滚

图23:管理后台数据发布场景

小布助手业务特性如下:

  1. 管理后台元数据量较小,几十 MB。

  2. 数据发布时效性分钟级内。

  3. 单表全量 replace 发布。

此业务特性下,以下三方面考虑 sqlite 的选型:


一 数据版本控制

方案一:记录 revision

1)有 schema revision 表。单独新建一张版本记录表,将关联的原表字段值存储下来。

图24:版本控制有schema revision表方案示意图

2)无 schema revision 表。使用统一的 revision 表实现历史版本序列化存储。

图25:版本控制无schema revision表方案示意图

3)原表 revision。在原表中增加版本字段。

图26:版本控制原表revision方案示意图

三种不同 revision 方案,缺点在于业务不透明,表结构要变化。


方案二:flyway

适用于 devops 发布,不适用于管理后台数据发布。

方案三:sqlite 快照

db 全量快照做版本控制,通过创建 sqlitedb、数据导入方式创建 snapshot,相当于使用 sqlite 作为中间序列化方式。

图27:sqlite快照版本控制方案示意图

优势:

  1. 管理后台业务透明

  2. 在线服务业务透明

适合做全表/全库版本控制,不适合做数据行版本控制。


二 数据按单元发布

方案一:binlog

数据发布进度难以控制,无法做到只发布开发测试,不发步生产。

图28:binlog同步方案示意图

方案二:mq 同步

存在较多额外的数据同步/发布研发成本。

图29:mq同步方案示意图

方案三:快照文件同步

依赖对象存储完成快照数据单元间同步。

图30:快照同步方案示意图

优势是可以直接复用文件发布方案。

适合做分钟级发布,不适合做秒级发布。


 数据按实例灰度发布和回滚

方案一:内存缓存+触发加载

数据库的数据更新后,实例进行重启触发、mq 触发等方式加载。

图31:db数据发布和回滚方案示意图

正常发布没有问题,发生异常情况如回滚实例 1 时,由于数据库没有 V2 数据,将会影响实例恢复时的数据加载正确性。


方案二:mq 发布和回滚

与 mq 同步类似,将会引入额外的数据发布研发成本。

方案三:实例内嵌数据库

实例内嵌 sqlite,加载 V2 版本快照可实现恢复。

图32:embed sqlite数据发布和回滚方案示意图

优势:

  1. 实例隔离性最强。

  2. 版本快照支持数据快速回滚恢复。

适合小数据量,不适合大数据量。

综上,sqlite 选型适用于小数据量、分钟级、全量控制的关键元数据,实现低成本、高质量的发布和回滚。

5 总结

本文介绍智能助理和对话系统的背景和价值,以及小布助手的工程实践,技术点总结如下:

作者简介

Xiao OPPO 对话系统后端专家

负责从 0 到 1 搭建小布助手对话系统后端系统,以及工程架构规划和研发。


获取更多精彩内容,请扫码关注[OPPO 数智技术]公众号

发布于: 刚刚
用户头像

还未添加个人签名 2019.12.23 加入

OPPO数智技术干货及技术活动分享平台

评论

发布
暂无评论
QCon-小布助手对话系统工程实践