关于后端:QCon小布助手对话系统工程实践

1 智能助手和对话零碎的价值

智能助理是蓬勃发展的行业，用户诉求十分强烈，目前远没有达到能够满足用户的水平。

1. 第一层面的用户对于效率要求十分高，一句话搞定的事件不会说两句话。
2. 第二层面的用户须要十分贴心的、智慧懂我的、相似于集体助理一样的角色。
3. 第三层面的用户，智能助理作为倾诉的进口，满足人类情感需要。

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

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

小布助手正是软硬服一体的科技公司——OPPO 在智能助理赛道外面的重量级产品。自 2019 年上线以来，增长十分迅速，目前曾经达到了 2.5 亿设施笼罩，1.3 亿月活用户。

小布助手作为 OPPO 惟一的智能助理，除手机以外，笼罩泛滥 OPPO 旗下的智能设施。同时在手机中不同的 app 入口，也有着小布助手的身影，如闹钟、商店等等。

小布助手领有 260+ 技能，如天气、零碎操控、闲聊交互，是一个满足用户宽泛需要的产品。

小布助手里最外围的零碎——对话零碎，笼罩三类典型的对话零碎场景。

1. 工作型：答案准确，限定畛域，以最简交互满足用户为指标。比方定闹钟。
2. 问答型：答案宽泛，限定畛域，以最简交互满足用户为指标。比方百科。
3. 闲聊型：答案宽泛，凋谢畛域，以对话轮次为指标。

2 小布助手对话零碎业务架构

工业界通常基于典型的 Pipeline 形式实现，较少应用 E2E 的形式。

1. ASR：语音信号输出，将来包含多模态的扩大，转换成文本。
2. NLU：输出文本，通过模型分类、提取，转换为结构化的用意和槽位。
3. DM：保护上下文的对话状态，通过上文的对话状态以及本轮的结构化输出，更新至新的对话状态，输入 action。
4. NLG：输出 action，转换为人能够听懂文本。
5. TTS：输出文本，转换为人声音频。

上述基线的 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，对晦涩度优化有很大的挑战。

以几个小故事来为例，类比在三方不受控时，如何优化耗时性能。小 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 ——每个预测申请回撤状态

施行难点是程序性难以保障，须要上分布式事务，保障下列步骤在一个事务中。

1. 对话状态回滚 undo
2. 对话业务逻辑 dialog
3. 对话状态写入 write

预测计划 2 ——正式申请实现后提交状态

施行难点是：

1. 业务逻辑侵入强，每个设计业务状态保护须要革新实现 try，confirm 和 cancel.
2. 申请放大，后端写申请减少 1 /N，通常预测申请 N 比拟小。

预测计划 3 ——革新为无状态

1. 写状态长久化对立在上游，状态读写通过申请协定携带。对话状态大小 1kb 以下。
2. 局部无奈革新为无状态的服务，通过预测判断会走到，返回 reject.

该计划整体实用于小布助手的数据量，架构更简略优雅，对性能、可用性更敌对。开启的技能整体命中率 42.3%，耗时收益 173ms。

进一步的形象，传统对话零碎是同步零碎，真实世界是异步对话的过程。真实世界对话不是一来一回的，存在互相重叠、互相打断、屡次交叉、距离缄默等异步的景象，对于对话零碎而言，输出和输入的节奏不固定。

行业内应用全双工计划来解决以上问题，小布助手通过建设节奏控制器模块，将单工、双工场景下的内部异步节奏转换为上游零碎的同步解决。蕴含本文提及的预测、预发等输出节奏控制策略；本文未提及的铺垫对话、被动对话等输入节奏控制策略。为解决收音提前结束、收音停不下的问题，判停、判不停的输出节奏控制策略以后实际中。

4 小布助手微服务实际

小布助手经验三个阶段的架构演进：

1. 起步阶段，2019 年疾速上线外围性能的原形零碎。
2. 快跑阶段，性能和团队疾速扩大的主要矛盾下，进行微服务架构降级。
3. 冲锋阶段，体验、技术能力深耕。

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

微服务架构大幅晋升架构复杂性，采纳最适宜本身业务和团队的技术架构，保障系统品质和施行老本可控。

品质保障的第一步，是能捕捉故障。

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

品质保障的第二步，是采纳高可用架构升高故障概率，并提供自愈复原和手工恢复能力。

故障概率：

1. 同城双活：升高单机房故障导致全局故障的概率。
2. 轻重拆散：小布助手零碎重算法，算法服务比工程服务通常更软弱，通过隔离部署缩小故障影响范畴和概率。算法服务采纳 sidecar 对立服务治理能力升高故障概率。

主动复原：

1. 限流回绝：自研服务过载回绝策略做上下游服务爱护，防止压垮，流量异样后零碎可主动复原。
2. 熔断降级：第三方不可控的内部零碎熔断降级须要更齐备，特地是长连贯服务，内部零碎异样后能马上切换备份零碎做主动复原。

手动复原：

1. 同城双活：来源于繁多单元链路上的大面积未知故障，通过手动切流疾速复原，管制影响面。
2. 灰度回滚：来源于公布上线过程引入的故障，灰度公布管制故障影响面，回滚提供手动疾速复原。微服务自身较容易实现，数据如何实现灰度公布和回滚较艰难，过程中的数据。

质量保证的第三步，不论是失常状况，还是异样复原过程的数据一致性和正确性，如何低成本施行保障？

1. 业务通明：在线数据一致性问题集中处理，做到业务通明。写状态集中到聚合服务，业务服务无状态，同城双活 redis 双向同步等存储中间件的一致性问题只有聚合服务关注。
2. 业务无状态：协定携带状态数据透传至上游业务服务读状态，实现业务服务无状态。大部分无状态业务服务接口幂等，存在大量依赖第三方非幂等服务导致本身接口无奈做到幂等。
3. 单元公布：离线数据通过核心单元的治理后盾，单向公布至在线实例。对话零碎场景下，次要公布元数据，进行 sqlite 快照全量版本控制，低成本保障公布和回滚中数据一致性和正确性。

技术架构选型中，为什么应用 sqlite？

问题形象为治理后盾数据主动公布至在线服务，实现数据库版本控制和灰度公布。

1. 数据反对版本控制
2. 数据按研发流程公布至各单元
3. 数据按实例灰度失效和回滚

小布助手业务个性如下：

1. 治理后盾元数据量较小，几十 MB。
2. 数据公布时效性分钟级内。
3. 单表全量 replace 公布。

此业务个性下，以下三方面思考 sqlite 的选型：

一 数据版本控制

计划一：记录 revision

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

2）无 schema revision 表。应用对立的 revision 表实现历史版本序列化存储。

3）原表 revision。在原表中减少版本字段。

三种不同 revision 计划，毛病在于业务不通明，表构造要变动。

计划二：flyway

实用于 devops 公布，不适用于治理后盾数据公布。

计划三：sqlite 快照

db 全量快照做版本控制，通过创立 sqlitedb、数据导入形式创立 snapshot，相当于应用 sqlite 作为两头序列化形式。

劣势：

1. 治理后盾业务通明
2. 在线服务业务通明

适宜做全表 / 全库版本控制，不适宜做数据行版本控制。

二 数据按单元公布

计划一：binlog

数据公布进度难以管制，无奈做到只公布开发测试，不发步生产。

计划二：mq 同步

存在较多额定的数据同步 / 公布研发老本。

计划三：快照文件同步

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

劣势是能够间接复用文件公布计划。

适宜做分钟级公布，不适宜做 秒级公布。

三 数据按实例灰度公布和回滚

计划一：内存缓存 + 触发加载

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

失常公布没有问题，产生异常情况如回滚实例 1 时，因为数据库没有 V2 数据，将会影响实例复原时的数据加载正确性。

计划二：mq 公布和回滚

与 mq 同步相似，将会引入额定的数据公布研发老本。

计划三：实例内嵌数据库

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

劣势：

1. 实例隔离性最强。
2. 版本快照反对数据疾速回滚复原。

适宜小数据量，不适宜大数据量。

综上，sqlite 选型实用于小数据量、分钟级、全量管制的要害元数据，实现低成本、高质量的公布和回滚。

5 总结

本文介绍智能助理和对话零碎的背景和价值，以及小布助手的工程实际，技术点总结如下：

作者简介

Xiao OPPO 对话零碎后端专家

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

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