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

笛里谁知壮士心，沙头空照征人骨。这篇文章主要讲述QCon-小布助手对话系统工程实践相关的知识，希望能为你提供帮助。
1 智能助手和对话系统的价值
智能助理是蓬勃发展的行业，用户诉求非常强烈，目前远没有达到可以满足用户的程度。

第一层面的用户对于效率要求非常高，一句话搞定的事情不会说两句话。
第二层面的用户需要非常贴心的、智慧懂我的、类似于个人助理一样的角色。
第三层面的用户，智能助理作为倾诉的出口，满足人类情感需求。

在近几年不断涌现的智能设备，印证了Kevin Kelly预言的“智化”趋势。以苹果为首，打造耳机、手表等多款风靡全球、让人怦然心动的产品，也出现了机器人等创新智能设备。未来智能家居、个人穿戴、智慧出行等各行业，都可以清晰预见“智化”的设备将会爆发式的增长。
英国市场调研公司Juniper Research预测，到2023年，搭载智能助理的设备将从2018年底的25亿部增加到80亿部。
?
图1：智能助手行业背景
小布助手正是软硬服一体的科技公司——OPPO在智能助理赛道里面的重量级产品。自2019年上线以来，增长非常迅速，目前已经达到了2.5亿设备覆盖，1.3亿月活用户。
?
?图2：小布助手规模
小布助手作为OPPO唯一的智能助理，除手机以外，覆盖众多OPPO旗下的智能设备。同时在手机中不同的app入口，也有着小布助手的身影，如闹钟、商店等等。
小布助手拥有260+技能，如天气、系统操控、闲聊交互，是一个满足用户宽泛需求的产品。
?
图3：小布助手业务场景
小布助手里最核心的系统——对话系统，覆盖三类典型的对话系统场景。

任务型：答案精确，限定领域，以最简交互满足用户为目标。比如定闹钟。
问答型：答案宽泛，限定领域，以最简交互满足用户为目标。比如百科。
闲聊型：答案宽泛，开放领域，以对话轮次为目标。

?
图4：对话系统典型业务场景
2 小布助手对话系统业务架构?
工业界通常基于典型的Pipeline方式实现，较少使用E2E的方式。

ASR：语音信号输入，未来包括多模态的扩展，转换成文本。
NLU：输入文本，经过模型分类、提取，转换为结构化的意图和槽位。
DM：维护上下文的对话状态，通过上文的对话状态以及本轮的结构化输入，更新至新的对话状态，输出action。
NLG：输入action，转换为人可以听懂文本。
TTS：输入文本，转换为人声音频。

?
图5：对话系统经典pipeline
上述基线的Pipeline满足理想、简单的场景。小布助手的业务架构实践的过程中，有两点思考。
第一，多领域如何融合。小布助手可以支持非常多的技能，分布在不同领域的技能怎么做融合？
第二，多领域的业务架构之下，怎么对性能和成本做折中？

图6：小布助手对话系统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，对流畅度优化有很大的挑战。

图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——每个预测请求回撤状态
实施难点是顺序性难以保证，需要上分布式事务，保证下列步骤在一个事务中。

对话状态回滚undo
对话业务逻辑dialog
对话状态写入write

?
图14：预测状态回滚方案示意图
预测方案2——正式请求完成后提交状态
实施难点是：

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

?
图15：预测tcc方案示意图
预测方案3——改造为无状态

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

图16：预测无状态方案示意图
该方案整体适用于小布助手的数据量，架构更简单优雅，对性能、可用性更友好。开启的技能整体命中率42.3%，耗时收益173ms。
进一步的抽象，传统对话系统是同步系统，真实世界是异步对话的过程。真实世界对话不是一来一回的，存在相互重叠、相互打断、多次穿插、间隔沉默等异步的现象，对于对话系统而言，输入和输出的节奏不固定。
行业内使用全双工方案来解决以上问题，小布助手通过建设节奏控制器模块，将单工、双工场景下的外部异步节奏转换为下游系统的同步处理。包含本文提及的预测、预发等输入节奏控制策略；本文未提及的铺垫对话、主动对话等输出节奏控制策略。为解决收音提前结束、收音停不下的问题，判停、判不停的输入节奏控制策略当前实践中。
?
图17：节奏控制器模块职责
4 小布助手微服务实践
小布助手经历三个阶段的架构演进：

起步阶段，2019年快速上线核心功能的原形系统。
快跑阶段，功能和团队快速扩展的主要矛盾下，进行微服务架构升级。
冲锋阶段，体验、技术能力深耕。

?
图18：小布助手技术架构演进三阶段
微服务架构升级，从业务架构上构建五个领域以及六个业务快速独立迭代，速度提升了472%，取得显著效果。本章不展开介绍领域设计和业务架构演变，将聚焦在微服务技术架构。
?
图19：小布助手领域设计
微服务架构大幅提升架构复杂性，采用最适合自身业务和团队的技术架构，保障系统质量和实施成本可控。
质量保障的第一步，是能捕获故障。

故障发现：得益于OPPO云比较完善的基础设施条件，打造立体监控较低。
故障定位：对话系统的背景下，秒级埋点聚合的全链路debug平台大幅度提升排查效率。

?
图20：微服务解耦技术架构原则——可维护性
质量保障的第二步，是采用高可用架构降低故障概率，并提供自愈恢复和手工恢复能力。
故障概率：

同城双活：降低单机房故障导致全局故障的概率。
轻重分离：小布助手系统重算法，算法服务比工程服务通常更脆弱，通过隔离部署减少故障影响范围和概率。算法服务采用sidecar统一服务治理能力降低故障概率。

自动恢复：

限流拒绝：自研服务过载拒绝策略做上下游服务保护，避免压垮，流量异常后系统可自动恢复。
熔断降级：第三方不可控的外部系统熔断降级需要更完备，特别是长连接服务，外部系统异常后能马上切换备份系统做自动恢复。

手动恢复：

同城双活：来源于单一单元链路上的大面积未知故障，通过手动切流快速恢复，控制影响面。
灰度回滚：来源于发布上线过程引入的故障，灰度发布控制故障影响面，回滚提供手动快速恢复。微服务本身较容易实现，数据如何实现灰度发布和回滚较困难，过程中的数据。

图21：微服务解耦技术架构原则——可靠性
质量保证的第三步，不管是正常情况，还是异常恢复过程的数据一致性和正确性，如何低成本实施保证？

业务透明：在线数据一致性问题集中处理，做到业务透明。写状态集中到聚合服务，业务服务无状态，同城双活redis双向同步等存储中间件的一致性问题只有聚合服务关注。
业务无状态：协议携带状态数据透传至下游业务服务读状态，实现业务服务无状态。大部分无状态业务服务接口幂等，存在少量依赖第三方非幂等服务导致自身接口无法做到幂等。
单元发布：离线数据通过中心单元的管理后台，单向发布至在线实例。对话系统场景下，主要发布元数据，进行sqlite快照全量版本控制，低成本保证发布和回滚中数据一致性和正确性。

?
图22：微服务解耦技术架构原则——一致性
技术架构选型中，为什么使用sqlite？
问题抽象为管理后台数据自动发布至在线服务，实现数据库版本控制和灰度发布。

数据支持版本控制
数据按研发流程发布至各单元
数据按实例灰度生效和回滚

?
图23：管理后台数据发布场景
小布助手业务特性如下：

管理后台元数据量较小，几十MB。
数据发布时效性分钟级内。
单表全量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快照版本控制方案示意图
优势：

管理后台业务透明
在线服务业务透明

适合做全表/全库版本控制，不适合做数据行版本控制。
二数据按单元发布
方案一：binlog
数据发布进度难以控制，无法做到只发布开发测试，不发步生产。
?
?图28：binlog同步方案示意图
方案二：mq同步
存在较多额外的数据同步/发布研发成本。

?图29：mq同步方案示意图
方案三：快照文件同步
依赖对象存储完成快照数据单元间同步。
?
图30：快照同步方案示意图
优势是可以直接复用文件发布方案。
适合做分钟级发布，不适合做秒级发布。
三? ?数据按实例灰度发布和回滚
方案一：内存缓存+触发加载
数据库的数据更新后，实例进行重启触发、mq触发等方式加载。
?
图31：db数据发布和回滚方案示意图
正常发布没有问题，发生异常情况如回滚实例1时，由于数据库没有V2数据，将会影响实例恢复时的数据加载正确性。
方案二：mq发布和回滚
与mq同步类似，将会引入额外的数据发布研发成本。
方案三：实例内嵌数据库
实例内嵌sqlite，加载V2版本快照可实现恢复。

图32：embed sqlite数据发布和回滚方案示意图
优势：

实例隔离性最强。
版本快照支持数据快速回滚恢复。

适合小数据量，不适合大数据量。
综上，sqlite选型适用于小数据量、分钟级、全量控制的关键元数据，实现低成本、高质量的发布和回滚。
5 总结
本文介绍智能助理和对话系统的背景和价值，以及小布助手的工程实践，技术点总结如下：
?
作者简介
Xiao OPPO对话系统后端专家
负责从0到1搭建小布助手对话系统后端系统，以及工程架构规划和研发。
获取更多精彩内容，请扫码关注[OPPO数智技术]公众号
【QCon-小布助手对话系统工程实践】