2月5-7日QCon全球软件开发大会携手100+位大咖讲师落定北京,点击查看完整日程>> 了解详情
写点什么

大话“智能对话”

  • 2023-01-11
    北京
  • 本文字数:4547 字

    阅读完需:约 15 分钟

大话“智能对话”

近年来,随着人工智能的快速发展,智能对话技术趋成熟,逐渐成为大家关注的焦点。大环境催化下,全行业数字化应用也迎来了需求拐点,智能对话行业发展进入需求爆发期。如今智能硬件语音交互所搭载的算法将成为硬件智能化的基础标配,随着 5G 技术的发展,智能硬件市场的发展将驱动中国语音助手市场规模进入爆发阶段。

 

于是 InfoQ 编辑对 OPPO 对话系统工程专家莫骁进行了采访,莫骁多年来一直专注后端工程架构,从 0 到 1 搭建 OPPO 智能助手小布的对话系统后端系统,目前负责对话系统工程架构规划和研发工作,与他的对话,我们对 OPPO 及全行业智能对话技术的发展有了一个全面的了解。

 

以下是视频采访的全部内容,为方便读者查看,视频下方也附上了文字内容。


00:00 / 00:00
    1.0x
    • 2.0x
    • 1.5x
    • 1.25x
    • 1.0x
    • 0.75x
    • 0.5x
    网页全屏
    全屏
    00:00


    InfoQ:目前越来越多的人开始关注智能对话领域,现在智能对话技术的发展现状是怎样的?国内外相关技术的演进方向和发展速度是否有所差异?

     

    莫骁:行业的技术发展可以分成两层,第一层是感知智能的技术,第二层是认知智能的技术,这两方面共同构成了产业目前需要的对话技术。在感知智能方面,整体趋势是从语音的单模态向多模态发展。认知智能则是从人工规则系统向预训练大模型的方向发展,这在产业界也有所体现。

     

    2013 年至 2015 年期间,深度学习技术实现了爆发式的成长。在亚马逊 Alexa 等智能音箱的领域及智能客服的领域都实现了产业落地。从目前的发展来看,Alexa 的智能音箱目前也是从语音交互形态往触屏到多模态的方向演进,这也对百度、阿里、小米等公司产生了较大的影响。在这一方面,国内外的差异不会太大,整体的发展趋势还是一致的。

     

    InfoQ:关于对话系统的评估,这个是最难被定义的,也是最重要的,您认为到底什么是“好的”对话?

     

    莫骁:我们可以从一个人的感知层面去定义一个对话的“好坏”,简单来说,一个好的对话首先是流畅的,其次是满意的,第三是可信的。

     

    从流畅度来说,对话要能够自然进行下去,不要有割裂感。

     

    从满意度来说,对话要能满足一定的意图,比如说在这次采访中,需要从专业的角度进行作答,即使是在平时的闲聊沟通中,对话也并非是毫无意图的,漫无目的的闲聊也会有情感的诉求,在这种情况下,也可以认为是满足了用户的某种意图。

     

    从可信度来说,我们希望人机要像朋友一样能够持续地交互下去,人机之间的信任关系非常重要,这包括了安全隐私方面的互信,内容的可信以及三观的可信,比如不能出现敏感的政治评论或是对用户进行人身攻击。

     

    这是从人三个感知层面对对话进行“好坏”的判断,它是非定量的,也相对模糊。学术界会用更加量化的指标来评价“对话”的好坏,比如参考机器翻译,用 BLEU 指标评价结果和人工标注之间的相关性。除此之外,对话的轮次,或者是任务的完成度,以及其它的近似任务完成度的指标定义也是评价对话“好坏”的指标。

     

    OPPO 的实践中,我们会构建一个完整的数据质量的工程系统来辅助定义对话的“好坏”,目前主要是以人工评价为主、自动的指标评价为辅。在对话的完整链路当中,要能够听清你在说什么,理解你在说什么,并用一个合适的内容来满足你的意图。在整个过程的漏斗模型中,我们会通过数据的埋点、采集、上报、分析、评估形成闭环,打造对话系统“好坏”的人工和自动化相结合的评估体系。

     

    InfoQ:目前智能对话领域最大的“技术挑战”是什么?行业里是如何应对这个挑战的?

     

    莫骁:当前智能对话领域最大的“技术挑战”需要从两个方面来看,一个是智商的层面,一个是情商的层面,这两个因素共同决定了人机对话中机器的对象是否足够的聪明。在智商方面,行业里有一些公司背靠搜索及知识图谱技术,通过知识补充智商;在情商方面,也有公司从拟人化及情感化的角度赋予机器人格,赋予它人类的感知和情感,对情商做一个补充。

     

    InfoQ:对于用户来说,“智能对话”产品的核心需求是什么?

     

    莫骁:从用户需求层面看,主要分为三层。第一层需求是来源于效率型用户的需求,用户希望能够通过对话的方式控制一些设备,这种属于命令型的需求,比如我需要智能助手帮我打开 WI-FI。

     

    第二层需求是知识内容与日常服务,用户会对智能助手进行提问,比如在小孩的教育场景种所需要回答的内容,或者是满足用户叫外卖等需求。这种属于“进阶”的需求,用户需要的是更贴心的个性化服务,智能对话产品还会有一些主动行为,比如在识别到用户熬夜之后,通过一些推送服务提醒用户早睡。

     

    第三层需求会更加高阶一些,它是更上层的需求——情感诉求,通过分析用户与小布助手进行的多轮交互,我们会发现用户对智能助手具有大量的情感诉求。

     

    从技术层面看,也是分为三类需求。第一类是任务型的对话,在这种需求形态下,为了完成某些任务,对对话进行相应的组织,对应的是前面提到的第一层和第二层的用户需求。第二类是知识问答类型的对话,也就是 Q&A ,一般会对应第二层的用户需求。第三类是开放域的闲聊对话,对应的是第三层用户需求。

     

    InfoQ:小布助手对话系统主要是应用在什么样的场景里?分别解决了用户什么需求?有哪些技术亮点?

     

    莫骁:截至去年 2 月,小布助手覆盖了逾 3 亿设备,月活跃用户数超过 1.4 亿。在如此庞大的用户规模下,它的用户群体也非常广泛,我们需要满足不同用户群体的不同需求。在上一个问题中,我们提及的三层用户需求以及三种不同技术需求都会有所覆盖。

     

    总的来说,小布助手的用户需求是非常长尾的需求,有点类似搜索系统,在长尾的用户需求之下,如何让这些用户的需求不断地被发现、被满足,这是需要持续探索的事情。基于此,小布技术团队以自学习的算法工程架构进行支撑,发现问题并主动根据用户需求进行产品升级与维护。

     

    InfoQ:从前面的回答可以看到,在技术探索上,小布助手主要是在预训练大模型上有所投入,除此之外,在其他方向上是否也会有相应的探索呢??

        

    莫骁:小布助手是从 2018 年开始从 0 到 1 进行建设的,这一启动时间较晚于行业,如何面向数亿用户量快速完成技术的追赶,是我们当时面临的一大挑战。

     

    在此背景下,我们发现,小布助手的用户场景中可以归纳为“五多”,我们会面临多设备、多领域、多模式、多模态以及多上下文的挑战,因此需要一个非常灵活并且能够支撑业务快速迭代的工程架构往下发展,于是我们选择了分布式的组件化架构——Pipeline 架构来做支撑。

     

    InfoQ:在学术界,对话系统主要有 Pipeline 和 E2E 两种架构,但据我们观察,Pipeline 在工业届应用较多,E2E 还处在探索阶段。您觉这两种架构分别有何优缺点呢?

     

    莫骁:这是一个很好的问题,Pipeline 架构的主要优点也是它在工业界应用比较多的原因。Pipeline 的分治思想可以把一个大问题拆解成若干个小问题,每一个小问题用相应的模块来解决,这样可以得到一个比较可控的解决方案。它最大的优点在于可控、稳定。但 Pipeline 也有相应的缺点,因为每一个模块之间是一个级联的关系,所以错误会累积,优化效果的“天花板”比较受限,串联出来的问题解决起来也比较困难。

     

    E2E 架构在学术界应用得比较多。E2E 架构主要通过大模型解决端到端的问题,不再把一个大的问题拆解成若干个小问题。这种解决方案主要的优点在于可以联合地解决问题,整体的目标是统一的。它的缺点在于过程会相对不太可控,因为大模型的可解释性是相对比较弱的。

     

    在小布助手的实践中,整个对话系统是一个大的工程系统,采用 Pipeline 架构更符合当前的业务状态及业务诉求。

     

    InfoQ:小布助手对话系统在 Pipeline 和 E2E 这两种架构方面分别做了哪些探索?

     

    莫骁:小布助手对话系统在 E2E 上会进行相应的融合,比如用户情感诉求中的“闲聊”,在预训练技术红利下,基于 transformer 架构的大模型在小布助手也有得到应用,这是一个比较典型的 E2E 系统,我们也会把它集成进 Pipeline 的系统当中。在这种情况下,小布助手的对话轮次会明显增加;针对在安全方面不太受控的问题,我们会在合适的场景里进行限定。这相当于 E2E 在局部领域集成进 Pipeline 中。

     

    InfoQ:从对话引擎层和数据层,小布助手对话系统分别又有哪些技术突破?有什么架构建设经验可以分享呢?

     

    莫骁:前面已经提到,小布助手从 2018 年开始进行建设,建设过程可以分成三个阶段:第一个阶段是 2018 年启动建设,一年内在 2019 年 4 月份上线,这是起步阶段。第二个阶段是上线后,一年之内快速对齐竞品特性,这是快跑阶段。第三个阶段是深入进行体验优化以及业务创新,这是冲锋阶段。

     

    这三个不同的阶段,整体架构建设的原则是一致的,最终还是要为业务成功服务。因此,小布助手的架构建设主要遵循了康威定律——随着组织架构的变化,技术架构需要适应组织架构。

     

    在起步阶段,小布助手采用大单体的架构设计思路,比较适合小团队快速试错以及快速推进的业务目标。

     

    在快跑阶段,小布助手采用前面介绍的分布式组件化的 Pipeline 架构,支持团队的快速扩展,适应迭代速度的提升以及多人的协作,迭代效率较起步阶段提升了 4-5 倍。

     

    最后的冲锋阶段需要往更深入地优化体验并进行业务探索,对于质量及性能的诉求会更高。在这个阶段,我们会在组件化的 Pipeline 架构中,集成更完善的质量体系和观测体系。

     

    InfoQ:数据安全问题一直是一个广受用户关注的问题,请问小布助手对此有何解决方案?您如何看待智能助手的数据治理技术现状呢?

     

    莫骁:小布助手一直非常重视隐私安全的保护,隐私安全是我们的第一道红线,基于此,我们专门设计了安第斯安全大脑来看护。通过在 Pipeline 架构中加入安全考虑和设计,例如端侧数据运行架构、声纹等用户生物识别数据还有数据加密、去标识化、匿名化、分级访问控制等一系列技术,我们实现了对用户个人数据全生命周期安全保护。整套解决方案现已通过 ISO27001、ISO27701 等权威机构认证,能够有效保障用户的数据安全。在内容安全方面,小布助手的回复会相对谨慎,避免输出敏感内容;在风控安全方面,如积分等与资产相关的服务,小布助手会通过风控架构解决恶意黑灰产行为。

     

    站在行业视角来看,从国外的 Alexa 到 Siri ,再到国内众多的语音助手,都经历过一些有关“语音数据是否有安全保障”的质疑。小布助手从未忽略过这种威胁,也不断加强在这一方面的治理。随着端侧算力增强,端边云协同技术的成熟,未来部分必须云侧做的计算可能迁移到端侧和边侧,实现更强的隐私安全保障。

     

    InfoQ:未来,您觉得智能对话在智能助手方面还将有哪些演进?您理想中的“智能对话”是怎样的?

     

    莫骁:总的来说,智能对话在智能助手上会有三个演进方向,端边云协同、多模态和主动对话,这也是基于前面的技术探讨得出的结论。隐私安全驱动下的端边云协同,多样化设备和元宇宙虚实共生下的多模态,个性化有温度体验驱动下的主动对话。

     

    刚才讨论到,好的对话应该要流畅、满意、可信,技术上如何逼近?在我看来,一个好的对话首先是高智商的,目前很多智能助手的回答并不理解真实世界的知识,需要在这一层面做一些补充,要能理解用户所说的话,能够和真实世界的知识对应起来进行理解,同时需要一定程度的推理。第二是高情商的,一个好的对话需要能够用情商来让对话流畅进行,让人认为这个“人”是有人格的。第三是高度个性化的,需要像一个老朋友或者是一个真正的助理一样了解用户,不需要重复出现上下文,可以根据用户过往的行为和兴趣、画像更好地满足用户需求,在更少的对话轮次中猜中用户的意图。

    2023-01-11 13:483068
    用户头像
    鲁冬雪 InfoQ 资深编辑

    发布了 83 篇内容, 共 35.5 次阅读, 收获喜欢 99 次。

    关注

    评论

    发布
    暂无评论
    发现更多内容

    OceanBase存储层代码解读(四):宏块的垃圾回收和坏块检查

    OceanBase 数据库

    遭不住了!Alibaba开源内网“M9”级别高并发编程全彩版进阶手册

    程序知音

    Java 架构 并发编程 多线程与高并发 后端技术

    阿里内网流传的9w字图解网络(全彩版)GitHub现已下载量过百万

    程序知音

    Java 程序员 计算机网络 后端技术 计算机底层

    互联网架构师联合总结的Java面试攻略,GitHub标星30K!

    程序知音

    java面试 大厂面试 java架构师 后端技术 Java面试八股文

    详解CAN总线:CAN协议分层结构及功能

    不脱发的程序猿

    CAN总线 CAN协议 CAN协议分层结构及功能

    详解CAN总线:CAN总线报文格式—数据帧

    不脱发的程序猿

    汽车电子 CAN总线 CAN协议 CAN总线报文格式 CAN数据帧

    Github爆火!阿里最新发布的《高并发核心编程笔记》PDF文档

    Geek_0c76c3

    Java 数据库 开源 架构 开发

    架构实战营模块1作业

    陌生流云

    架构实战营

    全网首次公开:Java面试参考指南V3.0版(完美契合当下所有互联网公司面试需求)

    Java全栈架构师

    数据库 程序人生 后端 高并发 Java 面试

    信息论与编码(一)| 信源分类与数学模型

    timerring

    9月日更 信息熵

    微信业务架构图与学生管理系统架构图

    冷夫冲

    架构实战营 #架构实战营 架构师实战营 「架构实战营」

    【云原生 | 从零开始学Kubernetes】八、命名空间资源配额以及标签

    泡泡

    Docker 云计算 云原生 k8s 9月月更

    详解CAN总线:标准数据帧和扩展数据帧

    不脱发的程序猿

    汽车电子 通信协议 CAN总线 CAN协议 标准数据帧和扩展数据帧

    邓荣伟:稳定支撑每秒百万笔支付请求,支付宝数据库架构的过去、现在与未来

    OceanBase 数据库

    直冲云霄,阿里大牛耗时49天整理12W字面试手册,押题准确率直冲95%

    Geek_0c76c3

    Java 数据库 开源 程序员 架构

    【云原生 | 从零开始学Kubernetes】九、k8s的node节点选择器与node节点亲和性

    泡泡

    Docker 云计算 云原生 k8s 9月月更

    阿里最新秋招面经,腾讯/美团/字节1万道Java中高级面试题

    程序知音

    Java 大厂面试 后端技术 Java面试八股文 阿里面试

    Canvas+Javascript实现点击小球的爆炸效果

    Sam9029

    JavaScript canvas 9月月更 小球爆炸

    全网首次公开!阿里巴巴1685页Java面试突击核心讲(基础到高级足足涵盖19个Java核心技术)

    Java永远的神

    数据库 spring 程序员 程序人生 java面试

    Python语法之字典

    向阳逐梦

    字典 9月月更 Python语法

    2022年企业Java面试前复习的正确姿势(已助力512人入职大厂)

    收到请回复

    Java 程序员 微服务 语言 & 开发

    详解CAN总线:CAN节点硬件构成方案

    不脱发的程序猿

    嵌入式 汽车电子 CAN总线 CAN节点硬件构成方案 CAN节点

    吃透阿里大佬分享的这份Java面试神技,3个月斩获8家offer

    Geek_0c76c3

    Java 数据库 开源 架构 开发

    阿里五位MySQL封神大佬耗17个月总结出53章性能优化法则

    Geek_0c76c3

    Java 数据库 开源 程序员 开发

    【编程实践】提高工作效率,避免重复且枯燥的操作,利用Python自动发送邮件

    迷彩

    SMTP 邮件协议 9月月更 Python邮件发送

    大话“智能对话”_AI_鲁冬雪_InfoQ精选文章