写点什么

从问答系统到 AI 中间件:云上智能机器人构建之路

  • 2019-09-06
  • 本文字数:7609 字

    阅读完需:约 25 分钟

从问答系统到 AI 中间件:云上智能机器人构建之路

问答系统早在 1960 年代便初见雏形,大致经历了基于结构化数据、基于自由文本、基于问题答案对等阶段,近年来知识图谱、任务型等技术的出现和应用,为问答系统提供了更好的体验与更多的场景。发展多年,问答系统在商业化的过程中仍然面临很多挑战。为了更好地服务丰富多元的智能问答场景,腾讯云构建开放 Bot 市集,打造 AI 中间件,为各行各业的问答系统提供基础能力。


以下为腾讯云 AI 语义研发总监钟黎在ArchSummit 全球架构师峰会(深圳站)2019 现场的演讲全文(有删减),听他分享智能问答的技术发展和趋势、及智能问答产品构建的实践与思考。


今天我演讲的内容主要从三部分展开,首先从一个回顾的视角去看问答系统的技术演变过程;其次,探讨构建智能问答产品,特别是智能客服,在实践中遇到的问题和解决方案;最后跟大家分享一些到云上构建智能机器人的思考。

问答系统的前世今生

问答系统早在 1960 年代便初见雏形,大致经历了基于结构化数据、基于自由文本、基于问题答案对等阶段。


关于问答系统,有一些比较关键的时间点,其中有几个时间点跟 AI 技术的发展关系非常密切。从图灵测试往后看,上世纪 60-80 年代的问答系统,主要是基于逻辑规则、结构化数据来做的。这个时代正值连接主义,也是神经网络的寒冬(AI  winter),当时主流的一些技术都是基于逻辑的、符号的。因此,在问答系统的展现上它更多偏向于符号与逻辑计算的结构。而另一方面,神经网络也开始有了分布式表示的早期概念,例如 Hinton 提出的“分布式的概念表示”。现在来看,分布式的语义表示几乎已成为绝大多数 NLP 任务的基础,从思想上来看是一脉相承的。


在 1990 年,美国标准委员会 NIST 开始做大规模检索语料集的收集与评测,后来通过 TREC 这个会议开放给信息检索的研究社区。1999 年,TREC 新增了一个项目子项,叫做 TRECQA,当时,TrackQA 更多的思路还是在延续信息检索、IR 领域的一些经典方法在问答上面做一些尝试。后面会再展开讲一点。


之后随着互联网技术的发展,一些问答社区产品涌现出来,比如雅虎问答。最近几年,因为知识图谱概念的流行,让基于知识图谱的问答也开始获得了更多的关注。同样的,因为机器阅读理解技术的发展,也促进了非结构化文档问答的发展。从这些例子可以看出,技术的发展和成熟,会帮助拓展产品的场景和边界。


接下来讲一下问答和智能的联系,很多人主张从图灵测试开始看,但早在 17 世纪时,就有笛卡尔语言测试,当时笛卡尔认为,语言和智能的关系是一个很明确的三段论 — “大前提,小前提和结论” ,大前提是什么?它是指如果一个机器能够产生一些回答、词语,就存在对某些现象产生反映,但它不能对任何现象都产生所有可能的反映(无法编码穷尽),一旦存在某种现象,机器无法正确地产生反映,这个大前提即说明机器没有语言能力。小前提是,语言能力代表着思维、智能的呈现,通过“大前提、小前提”推断出来“机器没有智能”。


1950 年的图灵测试避免了对智能定义的讨论,而从行为、功能的角度看,如果一个机器能够跟我对话,且我又不能分辨它是机器还是人,我就认为它有智能,这是从功能的角度去判断的。


80 年代 John R. Searle 的“中文屋”实验对图灵测试做了反驳,中文屋实验是指,在一个房间里有一个完全不懂中文的人和一本中文工具书,外面的人用中文纸条和房间里的人对话,里面的人通过查询工具书找到对应的中文输出,对于外面的人来说,里面的人是可以通过中文对话的,但其实他并不懂中文。


我觉得“中文屋”实验更重要的点不在于反驳图灵,而是在于它提出了一些更有外延的一些想法,它思考了句法和语义的关系。我们都知道,人的思维活动其实是计算,或者说人类的思维很多是在大脑中的计算,并通过神经元、突出进行化学信号、电信号等的传递,那是不是意味着人的思维等价于计算呢?


“中文屋”就是在反驳这个(说法),它认为思维不仅是符号的操作过程,不纯粹是物理的操作过程,它认为物理介质本身也很重要,也就是说我们的思维不仅仅是因为我们的突触、神经元在传递电信号、化学信号,是因为神经元本身这个载体也构成了我们思维的一部分。因此该实验认为,必须要有一个特定的实现,这个特定的实现必须要有物理化学基础。当然后来中文屋实验也引起了很多的讨论,有兴趣的同学可以看看 John Searle 后来写的中文屋回顾总结。


刚才讲的两个都是思维实验,它其实是一个想法,并不适合用来做真正的问答测试。


如果真正做一个严肃的问答系统的测试,要如何做呢?也有一些人提出了新的测试方式,比如 WSC,这是一个相对来说更加规范的测试,它会给一句话、一个描述,然后给一个问题,让人去选答案。这样的问题非常简单,只要你能看得懂这句话就能选出正确的答案。目前 WSC 测试最好的效果能达到 61,人类可以做到 95,所以,在这个方面机器和人类的距离还差得很远。


刚在提到,在上个世纪 60 年代— 80 年代的问答系统中,主要是基于句法、逻辑规则、结构化数据来做的,当时这些问答系统都有一个名字,叫做 NLIDB。当时智能问答系统研究主要针对数据库自然语言接口任务,即如何使用自然语言检索结构化数据库,代表系统包括 BASEBALL 和 LUNAR。LUNAR 允许用户使用自然语言提问的形式查询 NASA 月球岩石及土壤数据库。


1999 年,TREC 举办了第一届开放领域智能问答测评任务 TREC-8,它从信息检索的角度打开了智能问答的一个新方向,2000 年,当时 TREC 的做法跟 IR 的体系是一脉相承的,很多想法都是继承了 IR 的思路,当时做 TREC 系统的比较经典的架构,跟 IR 系统是密不可分的。


一些文档集通过 IR 的子系统,再通过一些语义(名词动词、语法结构、主语谓语)相关性的筛选,去找到侯选的答案。这其实都没有 Model,基本上都是基于这样的一些符号的操作,并得到了很多侯选答案。这些方法,已经有了现在的问答系统的雏形了,但当时这个方法的效果并没有那么好,当时的 TREC 也好几个数据集,最好的也没有超过 60%,普遍的在 30%。


到 2010 年的时候,TRECQA 已有一定发展。在美国,有一个电视问答比赛节目—“Jeopargy", 这个问答节目的规则是,有一些侯选人站在台上,主持人提一个问题,大家先是选择要不要去抢答这个问题,抢答后就可以回答问题。这里涉及到回答的准确率和覆盖率(有多少问题抢答了)。在这个节目里,人类冠军的准确率大概在 85% —95%,覆盖率在 40% — 60%。


从 2007 年开始,IBM 一直想去挑战这个比赛,4 年之后,IBM 构建的 Watson 系统参加了这个节目,并在比赛中击败了人类冠军选手。Watson 系统结合了检索和结构化数据两个方法,结构化的一个好处是,它不会随着数据量扩大而掉的很厉害,当范围扩大的时候,它仍然能维持在一定的表现,它做了很多优化的技巧,在 0.7 版本时已经能够比一半的人类冠军的表现要好。


在拿到冠军之前,Watson 系统曾遇到过的一个最大问题是它的线上耗时问题,因为它当时维持了一个非常大数量级的结构化知识库,去做查找时需要两个小时。当时节目中有一个 5 秒钟倒计时,为了加速到线上去,5 秒钟能做到,IBM 花了 300 万美元组建了一个 90 台的集群,每台集群的配置很高,78 核、16PB 的内存,在当时世界超级计算中心的集群里排名前五百。


到现在,问答系统已经有一定技术成熟度,在面向垂类的问答比如智能客服、智能咨询、智能导购类方面做的比较好,在面向开放域的任务问答、KEG 问答、闲聊等方面已有很多厂商做的很不错,比如腾讯云,腾讯云会开放自己的对话平台,大家可以在上面构建自己的任务机器人。目前,具备常识推理的,具有情感感知能力的拟人对话系统,离我们还比较遥远。

从构建一个智能客服产品说起

刚才简单讲了一下问答系统的发展历程,接下来讲一讲构建智能问答产品的实践,我们就以智能客服为例。


现在,大家可能经常遇到这样一个场景,很多厂商都会有自己的智能客服,可能老板就会说,智能客服很常见,技术好像也都比较成熟,是不是可以很快地去构建一套自己的智能问答的一个产品?


在之前也提到,其实现在信息检索方法对 QA 的影响是深远的,所以我们可以直接去用 IR 的方式先去构造一个初始的版本。构造完初始的版本后,我们会发现一些问题,比如在做问答的时候,用户的 query 是比较口语的,多样性会比较丰富,因此如果我们基于全文检索,基于关键字匹配、关键词的倒排索引来做,可能在泛化这一块儿会有一些问题。所以我们需要去加入一些更多技能进来,比如需要去做意图的判断、理解,比如说需要去做一些排序和匹配的工作等。


再来说关于深度学习的问题,对于这个问题,针对大部分的场景也需要去考虑一下它的投入比,当实际上数据量很小的情况下是不是一定要去上深度学习?我们的架构能不能支持很好地把模型加载进来?耗时能不能在线上承接的住?这些都是我们需要在深度学习上去考虑的。


假设到此我们已经搭了一个检索的基本框架、加了一些 NLU 和匹配的算法,加了深度学习来进一步增强准确率,现在我们的 FAQ 的机器人终于上线了。


上线之后,我们发现还是会遇到一个问题:如果场景实体特别多,每个实体都要配置 FAQ 吗?这样工作量其实是非常大的,这样类似的场景,可以归纳成一个多(物品)实体,少(问法)模式的场景,在电商、文旅里尤为常见。对于这样的场景,KG 图谱的问答会更加适合,图谱的问答可以允许较多实体的数量,可以支持实体以比较低成本的大量增加,但它的模式会相对固定,使用 KG 问答,可以免去我们配制很多关于实体的问答对。


另外一个非常常见的场景是,在 FAQ 机器人中会发现很多问题其实是没有的,或者说这些问题都存在于文档里,可能会有很多的规章制度、解答都会写在文章里,那这样的情况是不是需要大家从文档里面去抽这样的一些问答对?当文档数量很多的时候,这个问题就会比较繁琐,耗人力。因此我们会有文档问答的一些场景,就是为了去解决这样的一些长尾问答、长尾问题。说到 FAQ,大家往往只关注它的 AQ,就是它的 QA 对,往往没有怎么去关注这个 F,F 的意思是 Frequent,是常见问题集,对于一些不常见、长尾的问题,我们完全可以通过文档问答的方式,在文档里面去找到答案。


我们还可能会碰到另外的场景,当机器人上线以后,用户的问法往往会认为它可能会有上下文的理解,有些话用户在上一次说了,不希望在下一次再重复,那么对于这一些多轮场景,我们也需要去构建一个多轮的引擎,我们需要有一个会话引擎去做会话管理,去管理它的上下文,去把用户的逻辑和算法逻辑去配置在一起。


以上具体介绍了我们在构建一个智能客服产品的时候,遇到的一些问题和场景。总结一下,当遇到这些场景后,我们首先是基于检索的一个框架,做了一个初版,然后我们加了意图识别 NLU 的模块,让它的问答支持更泛化的问法,进一步加了匹配和深度学习的模块,让准确率效果更好。最后,因为要面对它有很多实体但模式比较固定的场景,因此加入了 KG 的部分。为了去解决长尾问题,又加入了文档的部分,最后为了关联住上下文的问题,让这个对话有对话记忆的功能,加了多轮交互的问题。


看似做了很多的工作,但问题解决了吗?我们可能会发现这个系统上线后,它的效果还不如人工客服+以前的规则引擎,那该如何解决这个问题?


这就是我们接下来要讲的 AI 中间件的部分。

AI 中间件:Beyond 智能客服

我们再进一步深入去看一下数据的原因,当线上数据出问题的时候,应该要从三方面去看,第一部分要看数据本身,第二部分看数据的模型,第三部分是看数据运营。


我分别来讲一下这三个部分,首先要看数据本身的问题,不管是 FAQ 的数据也好,还是 KG 的数据也好,还是文档的数据也好,这些都是基于数据的,我们首先要去对数据做一个健康度的指标和评价。我们都知道,模型有一个原则,“garbage in,garbage out”,如果你给它一些"垃圾",它出来肯定是"垃圾",我们必须要对数据做一个比较清晰的认识,这里会设一些指标,比如 Coverage(线上问答和知识库的重合度到底有多少)。如果用户问的问题都不在我的库里,那再好的模型也无法回答。


第二个是这些模型本身是否有足够的分离特点,如果这些知识点都耦合在一起,对模型来说,它也很难去学习。第三是看知识点是不是均衡的,有些知识点的问题和答案会比较均衡。有些问题,它有很多相似问题,有些问题则没有,我不太希望我的知识库里面出现这样悬殊的样本,这些是一些宏观指标。


此外还有微观指标,我们理想中的“相似问”是希望它和“标准问”的距离不要太远,也不要太近,因为如果它太远,可能机器无法去学习,太近的话,我们认为它是一个冗余,它没有提供任何新的信息。我们希望每一个知识点的相似问的距离,它的分布是一个钟型的,我希望他们大量的分布都是集中在一个窄的范围里,希望所有的这个距离既不要太近也不要太远。另外我希望这个钟型足够的窄、足够的瘦、足够的苗条,让它们的分布会比较均衡,这就是刚才提到的“均衡度”。


刚才讲了一些知识度的指标,那如何运用呢?可以构建一个数据闭环,我们有了知识库以后,通过自动化的评测,评测后能拿到一个健康度的指标,可以去可视化,并给它一些梳理的建议,那梳理建议完了以后,可以通过智能运营工具 QnAMaker 去生成或产生优化知识点,然后给到人工去审核、编辑,最后回馈到知识库里面去,这就是一个很好的数据闭环。同时,这样一个健康可视化和知识处理也会给后面过程的选型、技术的选型带来参考。


我刚才主要讲的是 FAQ,这里也顺带去提一下 KG 的数据要求,KG 对数据的要求会更多,因为它是结构化的数据,那还有一部分是 Doc,为了能够回答长尾问题,它人工介入的数据量会比较低,它是一个更加非结构化的数据。


接下来看一下数据模型,在看模型的时候,因为框架是自己检索的,我觉得第一步应该先去看一下召回。召回很重要,因为召回是给我们画了一个“圈”,告诉我们答案就在这个“圈”里,如果这个“圈”都画不对,那后面的工作很难做的更好。如果召回没有问题,这个圈里面答案的覆盖率是百分之百,那就没问题。


做到这些以后,就去看模型,先看排序模型,排序模型里要分别去看它的场景,另外再去看匹配的模型,这里有两种主流模型的代表,很多人会觉得,现在普遍都用 Interaction based 的方法,为什么你还会说这个 Representation based 的方法呢,为什么还讲这种 Arc-I 的结构呢?其实 Arc-I 的结构大家不要去忽视它,因为在线上的时候,Interaction based 的方法耗时会大,每一次交互都是需要实时去做的。但如果是基于 Feature  based 的方法,可以离线算好存好,知识库里的问答对都可以预计算,在实时的过程,只需要做很少的计算。所以在实际中要考虑 Trade  off。


此外,大家可能在做模型的时候,比较少去关注的点是负例的构造,loss 的构造,这对实际效果的影响会比较大,有可能比模型本身的架构影响会更大,还有关于打分的问题,怎样让打分是有用的、可比较的。


接下来是 KG 的模型,其实 KG 的模型现在来讲都比较经典,主要有几类方法,一类类似于“Natural Language Interface to Database ”这种方式,通过很多规则,通过设法标注句法的方式把它转成图数据库的查询语句。第二三种方法会综合考虑问答的表示,就是问法的向量化及图谱里的一些向量化,最后把它变成一个机器学习的问题。还有 Doc 模型,这里没有展开去讲阅读理解这个模型,更多是在讲,在实际工程里去考虑怎么去做这个事情,我们可能会先做文档检索,然后找到段落,做段落定位,再去段落里找答案。


做了这么多模型和数据的工作后,我们发现,AI 用上去效果是不错,但随着时间的流失,它就慢慢“掉”下来了,它又比原来的人工差了。这就是需要第三部分—运营的思想。


我们在传统软件里都会提到 CICD,AI 软件跟传统软件有些不同,传统软件不需要长期的去培育。我们去交付一个传统软件更多情况下是一次性的。但对于 AI 软件来讲,我们交付的是一个“婴儿”,我们得不停地去”培育“他,用线上的数据去“哺育”他,让他尽快地成长起来,要更加的鲁棒,因此我们要非常需要去关注运营效果。在 AI 软件里,我们需要有 CICL 的思想,需要持续学习、持续进化的思想。


在运营里,我们可以重点看两部分,第一个是事前,第二个是事中。事前运营,它有以下几类,第一类是从文档里去生成 QA 对;第二部分是从对话里去生成 QA;第三部分是


生成相似问;这些是为了去启动一个系统、一个 Model 可以做的一些事前部分。


事中部分是指,如果已经上线了,该怎么样让它做得更好?可以通过流水日志去看未解决的问题、去做一些聚类和发现。刚才也提到了一个智能运营工具— QnAMaker,这个工具它是从文档里去生成一个 QA  pair,它跟文档的结构是很相关的。另外一个工具是去生成一个相似问,我们可能会做一些模板库,基于这个模板库,抽出答案后把它做不同的套用。相对来说,做了聚类分析的模块,比较适合在业务的线上去用到,尤其适合线上业务有线上客服的情况。


刚才讲了很多关于数据运营的部分,除了数据以外,模型也需要运营。模型在不停地有新数据进来以后,需要做很多迭代,需要去做模型的训练、模型的自适应的调参、模型的版本管理等等。因此,我们会有一个 Auto NLP 的平台,这个平台可以理解为 AutoML 在 NLP 领域的一个实现。现在在这上面,我们已经实现了一些闭环,第一个闭环是数据的闭环,第二个闭环是模型的闭环,第三个闭环是流水日志的闭环。一个理想的运营系统,应该要实现这三个闭环。

总结

最后总结一下,在智能客服这块,我们发现它的工作没有想象中那么简单,并不是老板说一周上线,我们就可以去解决所有问题。但我们发现其实智能客服的提效和降本的能力还是很强的,以一个实际客户的数据举例,它的智能客服系统上线 8 个月以后,在成本方面,上千人的人工客服团队缩减到了 60%,而同时接单量反而有增无减,用户排队等待时间也大幅缩短,在只保留 40%的人工客服的情况下,整体客服系统效率反而提高了 30%以上,这还是一个相对来说比较保守的估计。因为最开始我们会有投入,比如购买成本,它是负的,但随着它的客服系统上线运营的效果,会发现它的收益是越来越明显增加。


如果大家想要去做智能客服,但又发现它没有那么容易的时候,我们腾讯云可以帮大家做这个“Dirty   Work”。对于一些不同类型、不同场景的 Bot,及数据运营和模型运营的模块,我们都会开放一些能力给到大家,主要有 4 层能力,从下往上分别是:底层的平台、原子化的能力;AI 中间件能力,比如不同类型的 Bot 中间件、运营的中间件、数据运营和模型运营的中间件;PaaS 平台,腾讯云可以提供一些平台的功能;最上层,企业可以针对各自所处的行业里面去做自己的行业应用,此外,还可以针对自己的场景去做自己的业务应用。


希望大家都能搭建自己的智能问答产品和系统,为自身业务降本增效。我们云也非常愿意为大家的智能化建设出一份力。分享就到这里,谢谢!


嘉宾介绍:


钟黎,腾讯云 AI 语义研发总监,主要负责云上智能搜索、问答、对话方向的产品业务研发工作。之前为腾讯社交网络事业群语义分析负责人,主要负责社交网络中的文本挖掘与语义分析工作。


2019-09-06 21:532494
用户头像
刘燕 InfoQ高级技术编辑

发布了 1098 篇内容, 共 429.9 次阅读, 收获喜欢 1904 次。

关注

评论

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

流动性缺失是NFT市场的症结,Protradex是如何解决此问题?

石头财经

天天预约 | 预约小程序分销功能,最全的操作指南来啦!

天天预约

小程序 SaaS 系统 预约工具 分销

熬了一个月肝完这份阿里P8的Java面试手册,我从20K变成了30K

Java你猿哥

Java 面经 校招 春招 八股文

流动性缺失是NFT市场的症结,Protradex是如何解决此问题?

BlockChain先知

当你对 redis 说你中意的女孩是 Mia

京东科技开发者

c++ 数据库 redis 缓存 企业号 3 月 PK 榜

牛客网Java面试题及答案整理(2023年春招最新版,持续更新)

架构师之道

编程 java面试

Qualcomm QCN9074 4x4 MIMO 802.11ax MX6974 F5 WIFI6 Module

MAXON

QCN9074

ProTradex是链上衍生品领域发展的强力推手

鳄鱼视界

掌握C++中static关键字的多种使用场景

小万哥

c++ 程序员 后端 开发 static

测试用例设计指南

京东科技开发者

软件测试 测试用例

2023年金三银四牛客网一线大厂Java面试大全(1000道题目附解析)

采菊东篱下

Java 程序员 面试

TLS、SSL、CA 证书、公钥、私钥。。。今天捋一捋!

江南一点雨

gRPC TLS CA ssl

深入理解C++右值引用和移动语义:全面解析

小万哥

后端 开发 C++11 右值引用 移动语义

美团二面:细数 Redis 阻塞的9种情况

做梦都在改BUG

Java redis 面试

微信小程序管理软件有哪些特点?

没有用户名丶

微信小程序

源码MetaForce佛萨奇2.0系统开发(搭建)

l8l259l3365

全新升级|ECS成熟度评估与洞察,助你精准定位运维风险

云布道师

ECS

Protradex,一个专注于链上衍生品交易市场的收益优化聚合平台

股市老人

C++编程必备:对象生命周期管理的最佳实践

小万哥

c++ 后端 生命周期 对象模型 RAII

贪心算法思想与练习

timerring

贪心算法

集成Health Kit时因证书问题出现错误码50063的解决方案

HMS Core

HMS Core

春招升级打怪拿offer,10w+字总结的Java面试题(附答案)够你刷

做梦都在改BUG

Java java面试 Java八股文 Java面试题 Java面试八股文

视频动态壁纸:Dynamic Wallpaper 激活版

真大的脸盆

Mac Mac 软件 动态壁纸 高清动态壁纸

Last Week in Milvus

Zilliz

非结构化数据 Milvus 向量数据库

MySQL kill会话不起作用?

GreatSQL

MySQL greatsql社区

机器学习算法(二): 基于鸢尾花数据集的朴素贝叶斯(Naive Bayes)预测分类

汀丶

数据挖掘 机器学习

SEO优化:友情链接!真心换真心?

烤冷面

SEO SEO优化

机器学习算法(三):基于horse-colic数据的KNN近邻(k-nearest neighbors)预测分类

汀丶

数据挖掘 机器学习

太全了!马士兵内部共享—1658页《Java面试突击核心讲》

做梦都在改BUG

Java java面试 Java八股文 Java面试题 Java面试八股文

RabbitMQ 延迟消息实战

做梦都在改BUG

Java 消息队列 消息中间件 Rabbit MQ

三天吃透MongoDB面试八股文

程序员大彬

Java mongodb

从问答系统到 AI 中间件:云上智能机器人构建之路_AI_刘燕_InfoQ精选文章