智能助理是蓬勃发展的行业,用户诉求非常强烈,目前远没有达到可以满足用户的程度。
在近几年不断涌现的智能设备,印证了Kevin Kelly预言的“智化”趋势。以苹果为首,打造耳机、手表等多款风靡全球、让人怦然心动的产品,也出现了机器人等创新智能设备。未来智能家居、个人穿戴、智慧出行等各行业,都可以清晰预见“智化”的设备将会爆发式的增长。
英国市场调研公司Juniper Research预测,到2023年,搭载智能助理的设备将从2018年底的25亿部增加到80亿部。
小布助手正是软硬服一体的科技公司——OPPO在智能助理赛道里面的重量级产品。自2019年上线以来,增长非常迅速,目前已经达到了2.5亿设备覆盖,1.3亿月活用户。
小布助手作为OPPO唯一的智能助理,除手机以外,覆盖众多OPPO旗下的智能设备。同时在手机中不同的app入口,也有着小布助手的身影,如闹钟、商店等等。
小布助手拥有260+技能,如天气、系统操控、闲聊交互,是一个满足用户宽泛需求的产品。
小布助手里最核心的系统——对话系统,覆盖三类典型的对话系统场景。
工业界通常基于典型的Pipeline方式实现,较少使用E2E的方式。
第一,多领域如何融合。小布助手可以支持非常多的技能,分布在不同领域的技能怎么做融合?
第二,多领域的业务架构之下,怎么对性能和成本做折中?
小布助手对pipeline有如下改动。
多领域融合问题,原则为尽可能领域自治,分为2个子问题,多领域结果排序和跨领域结果融合。
效果、性能和成本折中问题,rank模块位置是关键。
小布助手用户体验中,流畅度优化是一个关键点。用户从唤醒说话,到最后看到结果的阶段当中,真实感知的延迟在中间,即从用户结束说话到看到结果。流畅度优化目标就是这段用户可感知RT。
小布助手流畅度遇到top问题为:
前两部分占比已经很大,且外部原因无法有效控制缩短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,反应当然比你快一点。
故事3:
小A不甘心,暗下决心要想个妙招。
小A:主持人没说完,我就能预测到他完整问题,要是偷跑不就能遥遥领先?
果真小A比小B答得更快!
但是好景不长,小A发现外援的答案经常给错,害小A扣了不少分。
小A心想原因是什么呢?
A:原来是外援认为预测请求是正式请求的上文,正式请求本应理解为“谁和X同时出书”,实际理解为“谁和Y同时出书”。
A:没想到状态引入副作用,预测是不是没法用了?
预测在搜索引擎等系统里面行业内有采用,需要在用户体验和成本上折中。
在小布助手里面主要难点对架构的冲击比较大。预测需要把一个请求拆分为请求序列,N-1个预测的非正式请求,1个正式请求,下游无法知道请求是否为正式请求,处理过程中要避免N-1个非正式请求引入状态副作用,否则会因为多轮状态错乱导致不正确的结果。
预测方案1——每个预测请求回撤状态
实施难点是顺序性难以保证,需要上分布式事务,保证下列步骤在一个事务中。
预测方案2——正式请求完成后提交状态
实施难点是:
预测方案3——改造为无状态
该方案整体适用于小布助手的数据量,架构更简单优雅,对性能、可用性更友好。开启的技能整体命中率42.3%,耗时收益173ms。
进一步的抽象,传统对话系统是同步系统,真实世界是异步对话的过程。真实世界对话不是一来一回的,存在相互重叠、相互打断、多次穿插、间隔沉默等异步的现象,对于对话系统而言,输入和输出的节奏不固定。
行业内使用全双工方案来解决以上问题,小布助手通过建设节奏控制器模块,将单工、双工场景下的外部异步节奏转换为下游系统的同步处理。包含本文提及的预测、预发等输入节奏控制策略;本文未提及的铺垫对话、主动对话等输出节奏控制策略。为解决收音提前结束、收音停不下的问题,判停、判不停的输入节奏控制策略当前实践中。
小布助手经历三个阶段的架构演进:
微服务架构大幅提升架构复杂性,采用最适合自身业务和团队的技术架构,保障系统质量和实施成本可控。
质量保障的第一步,是能捕获故障。
故障概率:
自动恢复:
手动恢复:
同城双活:来源于单一单元链路上的大面积未知故障,通过手动切流快速恢复,控制影响面。
灰度回滚:来源于发布上线过程引入的故障,灰度发布控制故障影响面,回滚提供手动快速恢复。微服务本身较容易实现,数据如何实现灰度发布和回滚较困难,过程中的数据。
质量保证的第三步,不管是正常情况,还是异常恢复过程的数据一致性和正确性,如何低成本实施保证?
1. 业务透明: 在线数据一致性问题集中处理,做到业务透明。写状态集中到聚合服务,业务服务无状态,同城双活redis双向同步等存储中间件的一致性问题只有聚合服务关注。
2. 业务无状态: 协议携带状态数据透传至下游业务服务读状态,实现业务服务无状态。大部分无状态业务服务接口幂等,存在少量依赖第三方非幂等服务导致自身接口无法做到幂等。
3. 单元发布: 离线数据通过中心单元的管理后台,单向发布至在线实例。对话系统场景下,主要发布元数据,进行sqlite快照全量版本控制,低成本保证发布和回滚中数据一致性和正确性。
技术架构选型中,为什么使用sqlite?
问题抽象为管理后台数据自动发布至在线服务,实现数据库版本控制和灰度发布。
小布助手业务特性如下:
此业务特性下,以下三方面考虑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选型适用于小数据量、分钟级、全量控制的关键元数据,实现低成本、高质量的发布和回滚。
本文介绍智能助理和对话系统的背景和价值,以及小布助手的工程实践,技术点总结如下:
Xiao OPPO对话系统后端专家
负责从0到1搭建小布助手对话系统后端系统,以及工程架构规划和研发。
获取更多精彩内容,请扫码关注[OPPO数智技术]公众号