从问答系统到 AI 中间件：云上智能机器人构建之路
更多优质内容请关注微信公众号“AI 前线”（ID：ai-front）
今天我演讲的内容主要从三部分展开，首先从一个回顾的视角去看问答系统的技术演变过程；其次，探讨构建智能问答产品，特别是智能客服，在实践中遇到的问题和解决方案；最后跟大家分享一些到云上构建智能机器人的思考。
问答系统早在 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 中间件的部分。
我们再进一步深入去看一下数据的原因，当线上数据出问题的时候，应该要从三方面去看，第一部分要看数据本身，第二部分看数据的模型，第三部分是看数据运营。
我分别来讲一下这三个部分，首先要看数据本身的问题，不管是 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 语义研发总监，主要负责云上智能搜索、问答、对话方向的产品业务研发工作。之前为腾讯社交网络事业群语义分析负责人，主要负责社交网络中的文本挖掘与语义分析工作。
你也「在看」吗？👇
相关内容
微信扫码咨询专知VIP会员