QCon- 小布助手对话系统工程实践
1 智能助手和对话系统的价值
智能助理是蓬勃发展的行业，用户诉求非常强烈，目前远没有达到可以满足用户的程度。
第一层面的用户对于效率要求非常高，一句话搞定的事情不会说两句话。
第二层面的用户需要非常贴心的、智慧懂我的、类似于个人助理一样的角色。
第三层面的用户，智能助理作为倾诉的出口，满足人类情感需求。
在近几年不断涌现的智能设备，印证了 Kevin Kelly 预言的“智化”趋势。以苹果为首，打造耳机、手表等多款风靡全球、让人怦然心动的产品，也出现了机器人等创新智能设备。未来智能家居、个人穿戴、智慧出行等各行业，都可以清晰预见“智化”的设备将会爆发式的增长。
英国市场调研公司 Juniper Research 预测，到 2023 年，搭载智能助理的设备将从 2018 年底的 25 亿部增加到 80 亿部。
小布助手正是软硬服一体的科技公司——OPPO 在智能助理赛道里面的重量级产品。自 2019 年上线以来，增长非常迅速，目前已经达到了 2.5 亿设备覆盖，1.3 亿月活用户。
小布助手作为 OPPO 唯一的智能助理，除手机以外，覆盖众多 OPPO 旗下的智能设备。同时在手机中不同的 app 入口，也有着小布助手的身影，如闹钟、商店等等。
小布助手拥有 260+技能，如天气、系统操控、闲聊交互，是一个满足用户宽泛需求的产品。
小布助手里最核心的系统——对话系统，覆盖三类典型的对话系统场景。
任务型：答案精确，限定领域，以最简交互满足用户为目标。比如定闹钟。
问答型：答案宽泛，限定领域，以最简交互满足用户为目标。比如百科。
闲聊型：答案宽泛，开放领域，以对话轮次为目标。
2 小布助手对话系统业务架构
工业界通常基于典型的 Pipeline 方式实现，较少使用 E2E 的方式。
ASR：语音信号输入，未来包括多模态的扩展，转换成文本。
NLU：输入文本，经过模型分类、提取，转换为结构化的意图和槽位。
DM：维护上下文的对话状态，通过上文的对话状态以及本轮的结构化输入，更新至新的对话状态，输出 action。
NLG：输入 action，转换为人可以听懂文本。
TTS：输入文本，转换为人声音频。
上述基线的 Pipeline 满足理想、简单的场景。小布助手的业务架构实践的过程中，有两点思考。
第一，多领域如何融合。小布助手可以支持非常多的技能，分布在不同领域的技能怎么做融合？
第二，多领域的业务架构之下，怎么对性能和成本做折中？
小布助手对 pipeline 有如下改动。
新增 rank，可理解为多领域顶层的 DP（dialog policy）。
RG，与 NLG 对等，除文本生成外，还包含资源获取。
新增 Post rank，对资源做校验。
多领域融合问题，原则为尽可能领域自治，分为 2 个子问题，多领域结果排序和跨领域结果融合。
多领域结果排序：rank 负责。同时为简化复杂度，当前不对具体 action 做排序，对 DM 来源做排序。
跨领域结果融合：DM 负责。跨领域 intent 输入 DM，进行跨域融合逻辑处理。
效果、性能和成本折中问题，rank 模块位置是关键。
Rank 位置处于最后，与 post rank 合并，即多领域多路召回-排序的方式。慢资源需要全量召回，在性能和成本上存在问题。
Rank 位置处于 NLU+DST 后，即强化学习 MDP 架构。Rank 相当于顶层 DP，此时只含 NLU 和 DST 信息，从长期效果天花板考虑希望有更多特征参与排序。
Rank 选择中间位置，折中效果、性能和成本。性能和成本上，由于已选取 top action，过滤大量慢资源请求。效果上，action 已带出除资源外的特征，最大程度保证效果提升空间。
3 小布助手流畅度优化实践
小布助手用户体验中，流畅度优化是一个关键点。用户从唤醒说话，到最后看到结果的阶段当中，真实感知的延迟在中间，即从用户结束说话到看到结果。流畅度优化目标就是这段用户可感知 RT。
小布助手流畅度遇到 top 问题为：
服务端三方资源执行耗时占比最大。服务端 580ms 耗时中，三方资源执行耗时占比最大，80%+。
服务端语音识别耗时占比第二。端云语音识别耗时中，尾点识别耗时 380ms-600ms。
客户端渲染交互可更简洁。部分垂直技能客户端交互可更简洁，执行可更快。
前两部分占比已经很大，且外部原因无法有效控制缩短 RT，对流畅度优化有很大的挑战。
以几个小故事来为例，类比在三方不受控时，如何优化耗时性能。小 A 跟小 B 抢答提问，可以自己去回答，也可以依赖外援，类比对话系统，外部耗时无法控制，只能控制自己的策略，帮助小 A 战胜小 B。
故事 1：
小 A：看我 ctrl c+v 大法，并发请求擅长的外援，同时翻笔记。
小 A：说不定小 B 串行请求外援，肯定比他快。
几回合下来，小 B 多数时候比小 A 还快一点！
小 B：我早就分析过 1 号外援速度最慢，只能额外覆盖 20%的答案。
小 B：对笔记和外援做快慢分层，就算 20%情况串行，80%我不需要傻等，当然比小 A 快。
小布助手通过快慢分层，RT 降低约 100ms，层级可灵活编排。
故事 2：
小 A 照抄小 B 策略后，反应还是慢半拍。
小 A：你是不是还分析出外援的什么特点了？
小 B：没错。我发现外援 3 的回复占了 40%，所以我拿到问题想都不想，预发给外援 3，反应当然比你快一点。
小布助手通过预发，RT 降低约 20ms。
故事 3：
小 A 不甘心，暗下决心要想个妙招。
小 A：主持人没说完，我就能预测到他完整问题，要是偷跑不就能遥遥领先？
果真小 A 比小 B 答得更快!
但是好景不长，小 A 发现外援的答案经常给错，害小 A 扣了不少分。
小 A 心想原因是什么呢？
A：原来是外援认为预测请求是正式请求的上文，正式请求本应理解为“谁和 X 同时出书”，实际理解为“谁和 Y 同时出书”。
A：没想到状态引入副作用，预测是不是没法用了？
预测在搜索引擎等系统里面行业内有采用，需要在用户体验和成本上折中。
在小布助手里面主要难点对架构的冲击比较大。预测需要把一个请求拆分为请求序列，N-1 个预测的非正式请求，1 个正式请求，下游无法知道请求是否为正式请求，处理过程中要避免 N-1 个非正式请求引入状态副作用，否则会因为多轮状态错乱导致不正确的结果。
预测方案 1——每个预测请求回撤状态
实施难点是顺序性难以保证，需要上分布式事务，保证下列步骤在一个事务中。
对话状态回滚 undo
对话业务逻辑 dialog
对话状态写入 write
预测方案 2——正式请求完成后提交状态
实施难点是：
业务逻辑侵入强，每个设计业务状态维护需要改造实现 try，confirm 和 cancel.
请求放大，后端写请求增加 1/N，通常预测请求 N 比较小。
预测方案 3——改造为无状态
写状态持久化统一在上游，状态读写通过请求协议携带。对话状态大小 1kb 以下。
部分无法改造为无状态的服务，通过预测判断会走到，返回 reject.
该方案整体适用于小布助手的数据量，架构更简单优雅，对性能、可用性更友好。开启的技能整体命中率 42.3%，耗时收益 173ms。
进一步的抽象，传统对话系统是同步系统，真实世界是异步对话的过程。真实世界对话不是一来一回的，存在相互重叠、相互打断、多次穿插、间隔沉默等异步的现象，对于对话系统而言，输入和输出的节奏不固定。
行业内使用全双工方案来解决以上问题，小布助手通过建设节奏控制器模块，将单工、双工场景下的外部异步节奏转换为下游系统的同步处理。包含本文提及的预测、预发等输入节奏控制策略；本文未提及的铺垫对话、主动对话等输出节奏控制策略。为解决收音提前结束、收音停不下的问题，判停、判不停的输入节奏控制策略当前实践中。
4 小布助手微服务实践
小布助手经历三个阶段的架构演进：
起步阶段，2019 年快速上线核心功能的原形系统。
快跑阶段，功能和团队快速扩展的主要矛盾下，进行微服务架构升级。
冲锋阶段，体验、技术能力深耕。
微服务架构升级，从业务架构上构建五个领域以及六个业务快速独立迭代，速度提升了 472%，取得显著效果。本章不展开介绍领域设计和业务架构演变，将聚焦在微服务技术架构。
微服务架构大幅提升架构复杂性，采用最适合自身业务和团队的技术架构，保障系统质量和实施成本可控。
质量保障的第一步，是能捕获故障。
故障发现：得益于 OPPO 云比较完善的基础设施条件，打造立体监控较低。
故障定位：对话系统的背景下，秒级埋点聚合的全链路 debug 平台大幅度提升排查效率。
质量保障的第二步，是采用高可用架构降低故障概率，并提供自愈恢复和手工恢复能力。
故障概率：
同城双活：降低单机房故障导致全局故障的概率。
轻重分离：小布助手系统重算法，算法服务比工程服务通常更脆弱，通过隔离部署减少故障影响范围和概率。算法服务采用 sidecar 统一服务治理能力降低故障概率。
自动恢复：
限流拒绝：自研服务过载拒绝策略做上下游服务保护，避免压垮，流量异常后系统可自动恢复。
熔断降级：第三方不可控的外部系统熔断降级需要更完备，特别是长连接服务，外部系统异常后能马上切换备份系统做自动恢复。
手动恢复：
同城双活：来源于单一单元链路上的大面积未知故障，通过手动切流快速恢复，控制影响面。
灰度回滚：来源于发布上线过程引入的故障，灰度发布控制故障影响面，回滚提供手动快速恢复。微服务本身较容易实现，数据如何实现灰度发布和回滚较困难，过程中的数据。
质量保证的第三步，不管是正常情况，还是异常恢复过程的数据一致性和正确性，如何低成本实施保证？
业务透明：在线数据一致性问题集中处理，做到业务透明。写状态集中到聚合服务，业务服务无状态，同城双活 redis 双向同步等存储中间件的一致性问题只有聚合服务关注。
业务无状态：协议携带状态数据透传至下游业务服务读状态，实现业务服务无状态。大部分无状态业务服务接口幂等，存在少量依赖第三方非幂等服务导致自身接口无法做到幂等。
单元发布：离线数据通过中心单元的管理后台，单向发布至在线实例。对话系统场景下，主要发布元数据，进行 sqlite 快照全量版本控制，低成本保证发布和回滚中数据一致性和正确性。
技术架构选型中，为什么使用 sqlite？
问题抽象为管理后台数据自动发布至在线服务，实现数据库版本控制和灰度发布。
数据支持版本控制
数据按研发流程发布至各单元
数据按实例灰度生效和回滚
小布助手业务特性如下：
管理后台元数据量较小，几十 MB。
数据发布时效性分钟级内。
单表全量 replace 发布。
此业务特性下，以下三方面考虑 sqlite 的选型：
一 数据版本控制
方案一：记录 revision
1）有 schema revision 表。单独新建一张版本记录表，将关联的原表字段值存储下来。
2）无 schema revision 表。使用统一的 revision 表实现历史版本序列化存储。
3）原表 revision。在原表中增加版本字段。
三种不同 revision 方案，缺点在于业务不透明，表结构要变化。
方案二：flyway
适用于 devops 发布，不适用于管理后台数据发布。
方案三：sqlite 快照
db 全量快照做版本控制，通过创建 sqlitedb、数据导入方式创建 snapshot，相当于使用 sqlite 作为中间序列化方式。
优势：
管理后台业务透明
在线服务业务透明
适合做全表/全库版本控制，不适合做数据行版本控制。
二 数据按单元发布
方案一：binlog
数据发布进度难以控制，无法做到只发布开发测试，不发步生产。
方案二：mq 同步
存在较多额外的数据同步/发布研发成本。
方案三：快照文件同步
依赖对象存储完成快照数据单元间同步。
优势是可以直接复用文件发布方案。
适合做分钟级发布，不适合做秒级发布。
三 数据按实例灰度发布和回滚
方案一：内存缓存+触发加载
数据库的数据更新后，实例进行重启触发、mq 触发等方式加载。
正常发布没有问题，发生异常情况如回滚实例 1 时，由于数据库没有 V2 数据，将会影响实例恢复时的数据加载正确性。
方案二：mq 发布和回滚
与 mq 同步类似，将会引入额外的数据发布研发成本。
方案三：实例内嵌数据库
实例内嵌 sqlite，加载 V2 版本快照可实现恢复。
优势：
实例隔离性最强。
版本快照支持数据快速回滚恢复。
适合小数据量，不适合大数据量。
综上，sqlite 选型适用于小数据量、分钟级、全量控制的关键元数据，实现低成本、高质量的发布和回滚。
5 总结
本文介绍智能助理和对话系统的背景和价值，以及小布助手的工程实践，技术点总结如下：
作者简介
Xiao OPPO 对话系统后端专家
负责从 0 到 1 搭建小布助手对话系统后端系统，以及工程架构规划和研发。
获取更多精彩内容，请扫码关注[OPPO 数智技术]公众号
版权声明: 本文为 InfoQ 作者【OPPO数智技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/620aed5e1ccd033d35bfe21f7】。文章转载请联系作者。
还未添加个人签名 2019.12.23 加入
OPPO数智技术干货及技术活动分享平台
评论