OPPO小布助手算法系统的探索、实践与思考

对话交互是继传统PC、PC互联网及移动互联网之后，下一个时代非常有想象力的关键技术方向，无论是学术界还是工业界都有极高的关注度，同时作为OPPO万物互融战略的关键节点之一，承载着伟大而艰巨的使命。

算法是对话交互的核心能力之一，决定了语音助手能达到的智能化水平，具有极高的技术价值。本文将主要从对话交互的目标、算法要解决的关键问题，行业现状与趋势、OPPO小布助手主要实践与进展，以及挑战与未来几个方面做个介绍。

【OPPO小布助手技术实践】第一篇：对话系统简介与OPPO小布助手的工程实践

1. 对话交互的目标与关键问题

通俗来说，对话交互的目标就是通过语音或文字以自然对话的方式，完成任务执行、信息获取、情感交流等人机交互过程。比如像科幻电影里面的贾维斯、大白等智能助手，代表了人们关于对话交互能力理想状态的期待。

对话交互近年来受到越来越多的关注，其背后的原因究竟是什么呢？其实回顾下近40年来信息科技发展的历程，就不难理解。我们知道，信息科技先后经历了传统PC、PC互联网、移动互联网几个大时代，其中每一个时代都与设备密切相关，进而催生入口和交互方式的革命。

而今我们正迈向被寄予厚望的AIoT时代，对话交互因其在新一代搜索引擎、超级服务分发中心、新型交互方式等方面的巨大想象力，承载了这一新时代下一入口级交互变革的使命愿景。

然而，想要达到理想的对话交互效果是非常困难的，主要是因为它需要跨越目前成熟的感知智能技术，迈向认知智能，当下在认知智能领域还存在很多尚未根本解决甚至未能清晰定义的问题。典型的认知难题包括如何表示和理解常识，如何使机器具有推理和规划能力，如何使机器有像人一样的想象力和自主性等。

在某种程度上，可以说解决了认知智能的问题，基本上就等同于实现了强人工智能，足见对话交互的难度之高。

对话交互的主干流程如下图所示，从中不难发现几乎所有关键节点都与算法相关，算法是取得较好对话交互效果的核心能力。

语义理解和对话能力是本文的重点，主要任务是在拿到用户Query后，通过先理解用户要什么，再决定给用户什么，最终组装合适资源恰当满足用户。由语义理解和对话能力组成语义算法系统就是为了达成以上目标的，该系统的涉及主要会面临系统性问题和技术类问题两大类，如下图所示。

系统性问题包括面向需要支持全领域Query、数百项技能、多设备多渠道的复杂系统，如何解耦拆解；面向产品需求多、模块多流程长、算法不确定性大等问题，如何高效迭代；面向无法穷举的多样化口语Query，如何通过效果监控保障体验；如何规避低级缺陷、答非所问、过度兜底等“智障”体验。

技术类问题则包括算法的选型、关键问题的建模求解、多轮对话的控制、性能方面的保障等。

2. 行业现状与算法趋势

首先，对话交互在应用场景方面已日趋成熟，涵盖智能家居、车载、生活出行、专业服务等众多领域，方便快捷是自然语言对话交互方式的天然优势，被越来越多的用户接受，据预估2020年将有超过70亿部设备搭载语音助手。

另外，发展趋势来看，近十年来顶级科技公司从未放弃在此方向上的投入，国外以苹果、亚马逊、谷歌三家公司作为代表，无一不把对话交互作为他们非常重要的方向；国内情况也类似，百度、小米、阿里都积极布局，旨在抢占对话交互这一未来流量入口。

一个值得关注的趋势是，面向第三方设备的对话交互智能助手逐渐淡出，各家主要集中在自有设备上大力发展，除了相关技术与设备耦合紧密的原因外，还有一个更重要的原因是这一入口太重要了，没有任何一个头部设备厂商愿意将其完全交给第三方技术方。

对话交互也是学术界研究的热点，从ACL论文的趋势分析可以看出，近5年来对话交互方向异军突起，在2019和2020年成为当前最热门的研究方向。

参考：Trends of ACL: https://public.flourish.studi...

在核心的认知理解算法方面，其求解范式由传统的强依赖语言、问题类型和人工定制经验的多模块流水线方案，演变成了更简单、通用、高效的端到端一体化方案。这种范式的演进极大地简化了问题求解流程，不仅能够有效避免累积误差，更使得大数据、大模型、大算力能够落地应用，显著提升效果。

近两年来，在模型层面以谷歌BERT为代表的大规模预训练模型横空出世，横扫各大语言建模任务榜单，为研发更先进的语义理解算法模型释放了巨大的潜能，这无疑会给对话交互的发展提供坚实的技术支撑。

总结来看，无论是工业界还是学术界都非常关注对话交互这一方向，这反映了行业对未来趋势的预判。算法技术的突破性进展则进一步催化了对话交互产品落地的速度，使得未来将会更早到来。

3. 小布助手的算法系统实践与进展

如前所述，语义理解和对话能力一起构成了OPPO小布助手核心的语义算法系统，以下部分将详细呈现我们在这一方向上的实践与关键进展。

首先，在业务需求方面我们主要考虑业务边界、对话能力、用户体量，以及评价指标这四个维度。

• 在业务边界方面，小布助手属于全场景开放域对话交互系统，需要支持的领域包括系统控制、信息查询、影音娱乐、生活服务、智能聊天等，共约包括数百项技能，用户Query的广度非常大；
• 在对话能力方面，除了简单指令型命令控制和单轮问题，还需要支持面向多轮的任务型、弱多轮、上下文理解等能力，以及对话推荐、主动对话等高阶能力；
• 在用户体量方面，小布需要覆公司手机、手表、耳机、电视等亿级别设备，千万量级的日活；
• 在评价指标方面，主要考虑需求覆盖度、意图召准率、技能满意度、响应时间等。

概况来讲，小布助手的使命任务是建立一种对话连接，连接的一端是公司设备生态庞大的用户群，另一端是优质的对话式服务，借助于这种连接来实现用户价值、技术价值等。

为了支撑上述业务需求，我们抽象总结了四项设计原则来指导算法系统的设计。

• 领域分治：采用划分领域的方式将全领域复杂问题进行分解，转化成更简单的子问题分组求解，降低求解的难度，提升系统的可掌控性。
• 效果优先：为了尽可能避免“智障”体验，不拘泥于任何单一技术，以效果优先驱动算法方案设计，规避低级缺陷。
• 闭环监控：建立完善的闭环监控机制，在研发阶段通过产品、测试、研发等多方拉通的测试例设计提升测试覆盖度，在线上采用实时动态测试集监控和人工评测来保障体验。
• 平台提效：为了应对众多中长尾的技能支持，推进技能平台的建设，以一致、通用的平台化解决方案降低中长尾技能的研发和维护成本。

参考业务需求和设计原则，小布助手目前的算法系统整体架构如下图所示。

首先，在平台与工具方面，基础算法以行业主流的深度学习算法为主，在其上针对不同的问题类型构建算法方案，并进一步封装成NLU框架、通用图谱问答、技能平台、开放平台等模块。

然后在业务方面，最上层会采用符号化、结构化、数值化的思路对Query进行通用处理，再按系统应用、生活服务、影音娱乐、信息查询、智能聊天几个维度进行业务拆分，各业务线独立迭代。最后再结合对话生成、融合排序优选出最佳的技能去满足用户的诉求。

从处理流程上，又可以分为预处理、意图识别、多分类ranking、资源获取和后置处理几个环节，其中前三个节点主要对意图的召准率负责，后两个节点对资源的覆盖度和结果相关性负责，全流程一起为最终的技能执行满意度负责。

语义算法系统中涉及的关键算法模块如下图所示，后续将分别对语义理解、对话管理、对话生成三个核心模块进行介绍。

意图识别是语义理解的核心模块，其主要任务是通过对用户当前Query，以及交互历史的分析，推断用户到底想要干什么，包括封闭域、开放域、上下文几种典型的场景。

槽位提取是与意图识别密切关联的任务，主要任务是从用户当前Query以及交互历史中提取关键信息，辅助精准获取用户所需的答案/内容。

意图识别和槽位提取共同构成语义理解模块，其难点主要在于口语多样化（亿级别独立Query）；歧义性（如小猪佩奇是动画片，也是App）；依赖知识（如“可不可以”竟然也是一首歌名）。

对话管理是语义算法系统的另一关键模块，其任务是根据当前Query和对话上下文推导对话状态，并据此推理对话系统下一步的最佳响应。

完成语义理解和对话管理后，还需结合对话生成才能实现技能的最终恰当的执行反馈。对话生成的任务就是根据语义理解的解析结果和要执行的动作，通过恰当的方式获取恰当的响应话术。

在算法模型方面，小布以强深度学习驱动为主，这类模块一方面效果较好，另外技术方案也已经比较成熟，存在非常多成功的案例。

然而值得强调的是，在这一领域基本不存在“一招鲜”的单一模型解决所有技术问题的算法方案，一般基于深度学习的主模型负责保障效果的基本面，仍需要结合定制规则来处理边角的badcase。

面对系统应用操控类技能，为了提升语义理解的效果，我们主要采用基于规则和深度学习模型融合的方案，其中反向规则用于快速拒绝领域外的Query，正向规则用于覆盖强说法，深度学习模型负责通用case的泛化识别。此外为了提升意图和槽位的联合准确率，引入了多任务联合学习。

多任务联合学习能使得意图和槽位互相消歧，主要应用在电话、短信、日程等技能上，相对与单任务独立学习，一般准确率能提升1%～3%。结合细致的数据驱动优化和规则校验，基本可以做到95%以上的召准率。

面向知识强依赖型的技能，如音乐、电台、影视等，我们主要采用了融合知识的意图识别方案，如下图所示。这类技能主要难点是单从句式无法判定意图，从Query中准确提取资源字段非常关键，融合资源关联结果后再进行意图识别能显著降低问题求解的难度。

不同于封闭域，开放域的意图识别难以建模成分类问题，一般需要采用语义匹配方案进行求解。针对这类问题，我们主要采用深度语义匹配方式，如下图所示。

相对传统基于文本符号的匹配，效果更好，匹配准确率可达到95%以上；不过也存在主语识别、语义包含等问题，需要配合下游验证策略控制。目前主要应用在信息查询和闲聊QA匹配中。

此外，为了进一步提升语义理解的效果，我们也在探索大规模复杂模型的落地方案。在大规模预训练语言模型方向，团队在开源模型基础上进行改进、重训与微调，实现了效果上的快速提升，目前排在中文语言理解测评基准（CLUE）总排行榜第五名。

不过这类模型计算复杂度很高，一般难以满足线上推理的时效性要求，需要结合知识蒸馏等加速方案才能落地应用。

常见的知识蒸馏方案可以分为数据蒸馏和模型蒸馏两种，其中数据蒸馏的假设是简单模型是因为标注数据的缺失导致效果不如复杂模型，如果利用复杂模型提供足够多的伪标注数据，可以帮助简单模型逐渐逼近复杂模型的效果。

模型蒸馏的假设是简单模型不仅仅是缺少足够多的数据，而是缺乏好的指引，如果通过训练复杂模型过程中获得的中间结果来同时指引简单模型的训练过程，则有助于简单模型逼近复杂模型的效果。数据蒸馏和模型蒸馏都有在小布助手业务中落地应用。

对话系统也被认为是下一代搜索引擎，用户关于知识问答类的诉求也非常多，预期是能够获得精准答案，为了满足这类需求，我们通过数据获取、数据挖掘构建自有知识库，再结合在线语义匹配、KBQA等提供问答服务。

此外，为了精准回答垂域事实类的问题，我们还构建了基于知识图谱的通用问答能力，对于精品垂类，通过数据合作和自助爬取构建领域图谱，再基于模版和图谱进行精准问答。

在对话管理方面，常用的方案包括基于有限状态机的方案、基于Slot-Filling的方案，以及端到端的方案，其难点是灵活的流程控制、上下文的继承与遗忘、意图跳转、异常处理等，目前主要采用Slot-Filling的模式。

为了在多轮中达到比较好的上下文理解效果，小布助手实现了基于指代消解的上下文理解方案，用于处理多轮对话中普遍存在的指代和省略问题。

参考：ACL 2019 Improving Multi-turn Dialogue Modelling with Utterance ReWriter

借助于对话管理和上下文理解，小布助手已支持沉浸式强多轮、自由切换弱多轮、上下文推理多轮等模式，覆盖了任务型、信息查询、多轮聊天等业务场景。

在对话生成方面，目前行业里主要有基于模板、基于检索、基于模型三种类型，由于生成式模型可控性弱，目前小布主要采用基于模版和基于检索的方案，生成式模型仍在预研中。

在算法工程方面，早期为了快速上线，提供了基于Python的服务框架，通过部署多实例来弥补单服务并发能力弱的问题；目前针对计算复杂度高的服务也在探索算子化工程重构优化，以及联合机器学习平台团队探索更简单高效的服务模式。

在技能建设方面，早期为了快速上线，以技能定制研发为主；去年底开始启动技能平台建设。主要思路是标准化离线模型生成和在线推理流程，将关键算法算子化，通过数据导入和流程配置完成技能研发，降低中长尾技能支持和维护成本。

最后，为了保障对话交互的效果体验，我们联合数据团队和评测团队构建了全流程的闭环监控方案，先由研发自测保证算法模型效果符合预期，然后在发版时再进入一轮批测，确保不会引入新的风险；上线以后，会有例行的监控和即时监控来分别保障整体效果和监控关键功能正常；此外，还会引入基于人工的抽样评测和三方评测进一步监控体验。

4. 挑战与未来思考

尽管对话交互近几年来在算法技术上取得了很大的进展，但是相对于用户期待的贾维斯和大白，还存在非常多的挑战.

首先在语义理解方面，目前的模型本质上还是基于数据的统计归纳，遇到极端case时缺乏鲁棒性和完备性。

其次，作为有潜力替代搜索引擎的候选，势必要承担“百事通”的角色。然后，低频问答存在领域开放、长尾效应明显、非常依赖知识内容等难题，建设难度和成本非常高。

另外，不同于相对成熟的搜索和推荐场景，对话交互能力迭代优化主要依赖人工，难以接上大数据驱动的自反馈自学习高速引擎，难以快速提升。

未来的挑战还远远不止于此，OPPO小布助手团队将持续在更强大的语义理解能力、更渊博的知识、更流畅的对话、更领域的对话管理，以及自反馈、弱监督、自进化学习能力等方面积极探索，为打造中文领域用户体验最好的智能助手而不懈努力。