对话式任务机器人深度解析与应用实践

彭小阳

作者：

张真，来自企业叫百信银行，可能很多人没听过这个名字，它是由中信与百度联合打造的互联网银行，我们跟传统银行有两点不同，第一点，我们是一个完全没有线下网点，通过互联网实现对客户的服务。我们也有一些开源软件，比如UAVStack，AIOps要完成一些权威监控的一些东西可能对大家有帮助。目前我负责基于自然语言动态银行，以及相关AI技术在金融、生活这种领域的研究。

我今天分享的话题是有四个部分，第一部分还是想带着大家一起过一下，跟这个对话机器人相关的背景，另一方面就是我们前面会提到一些可能会跟对话式任务相关的一些探索和思考。希望通过这样的分享让大家了解我们现在做的这方面的比较深度的原理，希望能够把一些干货带给大家。第三条，结合我们实际应用场景给大家做一些深度分享。最后也要思考一下、畅想一下未来。

一、对话式任务机器人的背景介绍

首先看一下我们在谈任务机器人还是要谈一下对话机器人。

常见的智能客服上的客服机器人，他的分类应该叫问答机器人，常见模式是一问一答，还有一种叫推理式问答，推理式问答比较难一些，我想起周星弛一个电影，讲的就是老婆邻居家儿子旁边的那条狗的名字叫什么，这就是需要用推理完成的一个过程。其实在准确率方面在80-90%。

目前其实应用场景我觉得还是蛮多的，我们在真正场景下，往往客户根本不知道要问什么问题，所以他所表达的内容通常不是那么直白，不直白说得直白一点就是不能通过字面某个关键词甚至句式的表达理解这是什么问题，难点在于隐含含义的理解。
举个例子，一个人跟客服说，我开户的时候失败的，这是什么问题？这里面发现字面表达的问题是开户，好像在说开户的事，实际上是做一个投诉，出现了问题。在商业价值上面，我给的评价是降本提效作用。
第二个是闲聊机器人，很多时候像一个附属品，在很多客服机器人里面都有闲聊这个成分，准确率本身来说不是太高，主要有两条：第一，闲聊很难，虽然闲聊机器人看起来没什么用，但是很难，因为聊得话题非常发散，要和人的情感、情绪产生非常多的理解。
我大概说了半个字，你通过我的情绪大概就了解我在说什么，这个事情对机器来说现在还是做不到。另外一点，本身商业价值不确定性，很多企业投入资源比较少。
第三个是今天重点分享的任务机器人，任务机器人有两点，一种叫被动式，就是我提一个要求你帮我完成一个任务，主动式是一个任务机器人的高级阶段，等于这个时候提的不是标准要求，需要自己规划出来，达成业务目标的步骤和计划，并且执行反馈给我。
目前我们在业内看到一些应用，准确率可能在70-95%左右，难点第一要理解任务，理解任务比理解话要难，需要理解系统。前面的对话更多是和人的，但任务机器人结合运维场景发现很多时候和系统之间要发生关系。
这个时候需要了解这个系统有什么功能，有什么API，甚至需要细到API里面有什么参数。落地的场景还是比较少的，但是商用价值比较高，为什么？因为对话机器人本质上能做的事情更多是降本增效，任务机器人拿他做业务可以达到增收的作用。

我之前从事了很多实践和研究也都是和AIOps相关的，我在这里还是想把任务机器人和AIOps之间的应用场景再和大家简单过一下。比如经常遇到的场景，比如智能报警、上线、容量调节、智能自愈、问题定位、智能影响评估。
影响评估这块可以多说两句，其实智能影响评估这个事情还蛮重要的，这个点还是在研究探索期，影响评估分两个层面：一个是系统层面，另外一个是业务层面。系统层面随着运维数据的积累，往往会更容易一点，但实际上在业务层面这个影响非常难，特别是在金融领域，因为金融领域很多领域是相对比较“虚”，比如一个节点这个挂了，对业务有没有影响，影响了多少钱，这是比较难量化的。

在谈任务机器人之前还是想了解一下对话机器人现在主流玩法是什么。一般来说，一个对话机器人可能分为三个步骤：第一，理解人要干什么，做意图分类；第二，对话设计；第三，参数解析。
在意图分类上面，现在主流的做法是用深度学习来做意图的分类，这里面也面临一个问题，很多时候你的数据是能启动的，比如在运维场景里面，大家有没有想过，虽然可能做运维做了很多年，但是可能从来没有累计过运维里面的语量，到底会说一些什么话、什么样的词来描述运维上的问题，其实很少，几乎没有公司会做这些事情。实际上你上来可能遇到数据启动问题。
另外是个模型问题，用了深度学习当你支持一定意图场景的时候，你的模型非常大，做一个模型可能40G，意味着在磁盘上存40个G，加载内存要运行40个G，GPU的机器，因为你要让它准，所以模型大小也是值得关注的，对话设计这部分现在主流的一些平台做的方式还是通过人工，现在用得比较多的就是对话树，就是一棵决策树，我问什么答什么。
难点在于意图的切换，我们都知道人在说一个事情的时候，往往是比较发散的，不一定会很聚焦，从A话题会变成B话题，这时候要让机器人意识到整体的话题切换了，这是一个难点，对于参数解析，我没有用术语。
现在很多主流方式还是人工设定这样的东西，人工设定不是问题，如果是做到任务机器人场景里面，人工设定槽上的参数和系统调的参数差距是很大的，还是干脆写一段逻辑。真正把这个东西上线以后，系统层面的API就有几万个，你需要写几万个这样的东西？谁维护这样的东西？这也是一个问题。

我们看一下对话机器人经典架构，这个架构很多同学都见过，我对这个架构本身不做过多描述，通过语音识别把声音转化成文本，文本提取语义，然后做多轮对话，然后把反馈结果通过语言生成文本，再通过语音播报给用户。在语义理解、语音生成没有完整落地。马上复联4要上映了，钢铁侠有一个助手，语音说一句话帮你搞定所有事情，你会很嗨，这是大家的梦想。

随着深度学习出现以后，我们发现还有另外一种架构出现，就是Seq2Seq，原来主要是用在机器翻译，这是来自于Google，把中文翻译成英文用Seq2Seq这个架构做这个事情。我们经常听到LSTM+Attention，通过这套模型可以帮你完成意图分类和参数提取的过程。这个架构好不好呢？我认为挺好，效果看情况。在很多问答对话的场景下效果还是可以的，但是放在任务场景下，你发现可能会比较失望。

前面谈的都是对话机器人的东西，我想说，因为对话机器人相对来说还是成熟一些，任务机器人还是更多要做一些探索，所以我想先把任务机器人对比前面的对话机器人把难点摆出来。
第一个就是数据冷启动，第二个是原则性差异。我们都知道一个对话问答机器人要点是说尽量能够理解你的意思，并且尽量给出你需要的结果，其实那个结果有可能不太准，但是无所谓。
对于任务机器人来说不一样，尤其用在运维场景下，用在运营场景下也是一样的，就是你不能错，我宁可不能识别你的意思，我也要把你的意思问清楚了以后再去完成执行，否则的话在这上面出了问题就是大事故。
第三个原则性上是有差异的。带出来的对于任务机器人，准确性要求很高，没有任何一个AI算法可以承诺我的准确率是100%，99%都不敢。
第四点大家也能看到，前面整个对话是机器人的框架，不是一个端到端的方案，因为我们前面提到，如果是任务机器人更多要和系统接触，要调用要理解，但是没有这样一些东西在里面。
第五，场景的普适性，不管运维还是运营都会有很多场景，假如说做了一个机器人，做完以后只能干这一件事，下一件事的需要把前面所有事情重干一遍。老板就有问题了，你干这个事有什么意义？第一次投入你花了100万干出来了，好像很智能，干第二件事情的时候还要花100万，就接受不了。场景普适性也是一个很大的挑战。

二、重新定义对话式任务

基于以上的难点，我们有了一些重新的思考，不完全来自于我们自己，我们关注了一些研究界、工业界的进展，我们重新思考对话式任务模式到底是什么。这是来自于学术界，最近有一个非常热的话题，前提还是由于无人车，无人车是最早把研究型内网系统考虑。无人车的场景和我们提到的场景非常像，无人车也是不能出问题的，工作原理来自于对人脑的反思。

我们人脑的方式，首先要接触外部感官的刺激，获得外部的信号，然后通过神经中枢思考作出决策，把决策结果交给行动执行器官然后对外界产生反应。这是基本人脑的工作原理。

从这上面，能不能有一种感知+认知到执行的架构，可能是一些语言、图形图像、传感信号，我们理解了以后然后交给执行部分，动手去干。

进一步讲之前讲一下关于认知和决策的概念，在认知智能领域做了一些分类，把什么东西定义为认知呢？定义6个类型，理解、解释、规化、推理、演绎、归纳，蓝色部分是我们可以用人工智能技术相关解决的类型，灰色部分目前是比较难的事情。
演绎和归纳是有创新性的。理解和决策是有什么关系？理解要理解人的意图、理解现实世界、理解系统，在运维场景也是一样的。解释就是要解释现象、定位问题、做根因分析。规划就是根据目标、规划达成目标的步骤。推理是根据已知经验推导新问题的结论。
我们把这四个步骤称之为决策。在这样一个概念下，我们又会想到一个事情，以理解为例，如果要理解这个世界首先要知道这个世界有啥，这里有另外一个概念，我在很早一些分享里面也提到，这是来自于智能家居，叫微智能概念，就是自动发现、自我维护、自我适应的状态。

和运维联系起来，从用户侧到网络、数据中心物理架构、再到应用层、微服务等等，把所有这些精确投入到事件里面，我们也叫做画像。是不是意味着我们有一个能力，这个能力就是比较实时感知和同步现实世界，这可能是你接下来做所有智能的前提。

如果参考BrainLike的架构，可能是这样的，通过类脑的思考提出决策，然后执行，对系统来说只有API一个选择，执行达到你的任务目标。
这是从任务执行的角度，从另外一个角度，任务机器人和系统之间也需要非常强的关系，就是说之所以可以完成一些智能的工作，你一定是能够从系统上拿到一些非结构化数据或者结构化数据，通过微智能和AI的方式完成感知、认知、执行一直到个性化交付的逻辑。

其实这个概念我在之前分享AIOps场景的时候也提出过，只不过我觉得和BrainLike结合以后成为新的形式。我们可以简称IBA架构，IBA架构特点就是希望通过这样一个架构提供一个完整的端到端的对话式任务，并且是完整的智能体验，最左侧是用户，右边是系统，毕竟我要完成任务。
可能有些分层，感官交互是感知，会有类脑思考到系统执行，系统执行也是认知，大家可能觉得好奇怪。我们在整体架构里面要建设很多的AI能力，这些AI能力之间什么关系？从感知层来说，也许通过一些语音或者机器识别的方式让类脑提取你的意图或者想干什么，交给类脑思考形成一些决策计划，最终交给系统执行，产生一个执行结果。
这里提一下系统执行层面为什么也是认知，其实从一个语言里面，假如说就是以自然语言为例，自然语言提出一个东西和系统调用参数之间差异很大，像智能API调用要解决的问题就是首先理解你说什么，然后你说的东西和系统这边的功能哪些是相关的，这个系统功能又应该对应哪个API。
这个API什么参数可能是你提到这个的东西，还有哪些参数需要来自于其他数据帮助我拼凑成系统调用，要把系统调用结果反馈，我要理解错误码是什么，错误码数据是什么意思，怎么形成反馈。这个过程也是一个认知。大家不要认为只是面向自然语言是认知，其实面向机器语言也是认知。

我想从一个被动式任务实现落地校对来具体剖析一下，到底IBA架构怎么工作。这是大家非常常见的，会有一个对话的端，用户直接说，不用敲字了，这需要语音识别，把消息拿过来可以得到一个文本，通过对话的服务交互会话，再交给类脑服务判断语义理解，在执行服务这一曾有一个智能API的调用。
最终完成和系统之间发生关系的调用，并且还要把回复的结果给到WebJS，这主要是帮助前端做回复用的。在前端可以看到什么呢？也许只是一句话或者一个图表、或者任务执行的结果、可视化数据。同时通过语义合成可以把分析结果播报出来。这有点钢铁侠类似的意思。

这里面有几个细节可以分享一下，关于机器对话理解这个事情，我们前面也提到，任务机器人有一个很重要的要求，不仅仅是理解你干什么，还要理解干什么以后还要准。我们分成三个部分，这里面有一些自己的方法。
首先是基于模型的分类，这没有什么特别要去强调的，因为这块我们会选择一些模型识别到底是什么任务。但是我们识别任务之后，我们会结合知识铺也要做一个辅助的补偿，叫做知图的意图理解，通过这样的补偿模型层面只能到90%，通过补偿就能到99%。
当我们要把类脑交互认知层的东西交给认知层理解就不要设置障碍，这就是为什么要定义ChatOps的标准指令，这不是人工定好了能干什么，更像一套协议和规范，目前业内没有太多人提这个，我们现在也只是在这方面做一些相关的尝试。
我们有了这个东西以后，其实我们在下一步真正做参数填充的时候，就可以结合模型，比如PrNet实现对参数准确性的提升，参数填的时候要填得准，填偏了也不对。在ChatOps指令生成的时候也是比较准确的。

另外一个细节是关于模型的使用问题，我觉得大家都有很多的困惑，不管运维场景的时候，到底模型怎么被管理起来、被运行起来的模式？在我们自己这边首先要有模型训练的平台，他要解决的问题是什么？
数据导入、设计验证和模型到处，实际上还有一个模型运行的组件，这个组件可能在类脑思考都会运行，解决的是把模型相关code加进来，哪些是给你的思考，哪些是给你的执行。
在调用的时候通过模型路由，模型路由建跟业务属性相关的信息，比如需要用什么样的技能，这种技能规划是由另外一种模型完成的，除了这个以外还需要评价、评分体系，模型的东西通常第一次效果都是很长，千万不要认为某一个模型上去很好，上去很好肯定是有问题，一上去很差说明每次迭代提升是正确的。
一定要有模型评分体系，要反馈到模型训练平台，让他帮你进一步迭代。我这里有一个观点，上智能的过程要有耐心，而且一定要想办法说服你的老板。我们在很多公司里面大家知道，肯定会有KPI的压力，见效果一定要看场景，要找到一个垂直点，把这个东西打上去见效果。
不可能一上去堆一堆模型算法就解决一堆问题，这是不现实的，一定是在这个过程中不断迭代出来的，而且一定要让老板意识到这个事情，否则总觉得一天天在搞什么。

三、应用实践剖析

接下来我结合一些实际的应用场景给大家分享一下，到底IBA工作是什么样子。

这是比较经典在Ops里面要解决的问题，就是智能报警，可能完成智能报警相关的信息，不仅仅是收链，一直到根因都完成了。
在智能报警有两类任务，一个是被动任务一类是主动任务，被动任务比如作为业务人员提出要看数据的需求，或者我要订阅一些报纸需求，这种是属于被动的，这就是比较常规的链路，大家都看到了，从智能运维、智能调用。
我想讲一下主动任务，好的智能报警是主动出来的，并不是被动的，怎么做到主动？这里也有前提，首先监控系统一定要对应监控数仓，能不能像潘老师那么家建到中台话的程度，看每家的进展。
但是一定要数仓？监控系统本身不是也提供数据查询的功能吗？这对于机器和模型来说用不了，因为查询是给人的概念。还有一点是从底层的技术栈来说也不支持。比较好的方式很多公司都有大数据库，大数据库里面一定会有大数据平台，会有数仓，就他的数仓就好了。
在这里面怎么完成工作呢？异常检测优先，用异常检测方式，通过对数仓数据进行多维分析，然后把异常检测结果可能是一个评分交给一个现实认知模块，它其实是用来做真正的安排，就是如果报了一些异常或者报了一堆异常，到底应不应该做下一步的动作，其实由他来决定。
他会生成一个执行计划，生成执行计划，比如应该做下一步动作，就发生了三四五六，根据异常检测结果做问题定位。每次提问题定位的时候，每家对问题定位这个事说法不一样，我这里的问题定位是链路，数据依赖没有一个调用关系，但是上个系统确实用了下部系统数据，这借助于大数据做数据分析，用这个做问题定位。
问题定位的同时会做一些根因分析，根因分析比较容易理解，就是做一个到底这个问题发生的原因是什么，比如NPE指数的错误，需要和整个运维知识库关联起来，由于今天我的分享不是重点讲这个，我没有太画出来。
在这部分完成以后，实际上现实认知会搜集到这个阶段，给出一个总体结论，把这个结论抛给WebJS，然后扔给用户。除了报警接收还有一个操作审批的动作，其实再好的模型，再好的架构，都不可能百分之百准，只要是写操作。
我建议大家在真正实践的时候，所有东西让机器做没问题，但是真正在运维动的时候，根据个人经验最好就是95%，没有达到100%过，一定要让人去审批，在这上面给出的不是一个简单的某个东西怎么了，给出来的是我的结论是什么，你分析这些结论所有的指标和数据，会给到这上面，就是让人再做一次筛选才能完成这个事情。

我们要提一个，做好运维也是为了做好运营，所以我这里提运营的场景就是客诉，比如在操作的时候出现一些问题，前面没有什么区别，首先会交给现实认知，现实认知解决的问题就是安排下一步做什么，在运营的场景里面，多数像客诉场景我们做的事情就是两个，就是排查系统层面有没有问题。
另外一个是排查业务层面有没有问题，所以不仅仅是用到监控数仓，还会用到业务数仓。上面和智能运维问题定位和根因分析没什么区别。把结果搜集回来会做一个判测，把这个判测反馈给用户，判测结果可能是特别准的，真正给到用户的，更多时候是先返给客服的，因为需要客服确认一下。
有时候是这样的，像系统层面曝露NPE的，这是不能给客户说的，客服可以看到，这是系统问题，可以选一个标准话术，跟用户说怎么帮你处理。

我刚才提到我们是一家银行，银行包括很多P2P公司都需要做审计和合规，这里面是风险运营其中一个场景，在银行审计里面是银行会有很多管理办法和合规条例，必须要遵守，合规条例简单来说就是你能干什么，不能干什么，可以做什么，不能做什么。
这对长期很多的传统银行来说，我雇很多审计专家，某行都有好几千人专门做这个事情看制度文件，从制度文件提取我们所需要公共条例的控制点，我们在这个场景里面是什么呢？
我们利用机器阅读的能力，只需要告诉我你希望我帮你完成哪些制度文件风险点的提取，我们会结合制度库和业务知识库做相关风控点信息的提取，提取完之后会返回给用户。
上面就是一个被机器标出来的应该关注的一些点，是比如上面写的，“内部审计部门至少每年对理财业务进行一次审计”，上面写的是“商业银行委托外部审批机构至少每年对理财业务做一次审计”，这样一些要遵守的规定。
这个例子想告诉大家，任务机器人本身除了完成具体任务还能帮你做一些更深层次语义理解的东西。当然这一点需要建设机器阅读的能力才可以完成这样的工作。

四、思考未来

最后我们来畅想一下未来，我认为我们未来探索的一个方向：首先是小数据大人物的模式探索，智能应用不管运维还是应用都面临一个很大问题，多数企业都是数据类启动，只有很少公司具有很高质量的数据。

所以我们在技术层面也是要探索一些事情，能够用尽量少的数据获得比较好的效果以及带来的普适性。我今天上午提到智能微服务，我上午提到其实我们有很多运用智能或者算法，你用的是包装算法服务或者把算法集成某个算法某个部分。
虽然提供的是有点智能，但是服务本身是不智能的。我说的也许只是一个方向，也许有其他的方式，也许是自然语言理解。
还有一个很核心的点，也是值得大家关注的，因为我不知道大家有没有注意过，AI在发生很大的变化，就是AI从60年代开始提出以后，经历了几起几落，真正的问题可能过去大概50年的时候，AI都是研究型AI，解决的问题是AI很难的问题。
但其实从2015年、2016年以后，包括AIOps的提出，最早百度很早就做AIOps，但是真正有AIOps概念可能是在2015、2016年的时候，那个时候提出是由研究型AI转向应用型AI，AI必须要找场景落地，如果不能落地其实都是虚的。
在场景落地的时候你会发现这里会有一个问题，比如做AIOps，可能有些同学会问我是不是要学算法？我觉得如果能把算法学好，并且能用好，你其实很牛，这是很好的方向。但是我们要考虑更多的情况是说，可能真正要做的事情就是把AI应用门槛降下来。
我觉得这个方向已经在发生了，随着很多AI开源包括大公司做各种开源，包括机器学习平台的开源，这个门槛已经在降低了，传统需要算法工程师做调节，但是很多模型不需要做调节，你需要做的事情就是喂数据。
但光是这样还不够，比如模型管理包括运行机制，为什么要提出IBA整个体系和架构，也是希望把AI门槛降低下来。我们有可能在今年有一个这方面的产品发布，大家可以关注一下。