【IT168 技术】本文根据【创客168】第12期《人工智能技术与智慧办公》现场演讲嘉宾孙林老师分享内容整理而成。

　　孙林，毕业于哈工大自然语言处理专业，先后在腾讯、360两家公司任职，目前是在360智能研究院负责对话AI方向，研究兴趣集中在信息抽取，问答系统，对话系统以及深度学习，我曾在学术会议上发表过文章，也有一些自己的专利。

　　正文

　　大家都知道现在有很多媒体报道我们已经在人工智能上取得了怎样的效果或者是在学术上达到了怎样的指标。而今天我们不搞这些花把势，实实在在的和大家分享一下360在人工智能方面的落地实践和产品。

　　如何描述Conversation AI?我认为更多的是下一代交互方式的革命。当然，这个话题有点大，所以我们先来谈一谈人机交互的发展历程。最开始是打孔机，科学人员通过打孔输入到计算机里，后来逐渐演变到用鼠标键盘作为输入方式，再后来有了触屏手机，并且围绕它有了APP生态。那么再接下来的交互方式会是什么?很多公司都在研究的语音交互会不会是下一个交互方式?

　　下一代交互方式到底是什么样的?音箱、硬件还是其它方式。对此业界有很多探索，例如亚马逊、谷歌、阿里、360和一些创业公司都发布了自己的音箱产品。

　　除此之外，各大公司还在考虑一些其它入口，例如机器人。360一直在做儿童机器人、故事机以及儿童手表等可穿戴设备。硬件会是下一代交互方式吗?软件有没有可能成为下一代交互方式?从2014年开始，我们就看到了很多手机助手、语音助手出现，如微软的小娜。其实360也有自己的语音助手系统。

　　360在整个语音交互智能硬件方面投入了很多，同时也落地了很多产品。今天就和大家分享一下360有哪些地方值得借鉴。

　　我们认为做成一个产品最重要的是天时地利人和，天时指的是当前这个方向是不是够火，技术准备是不是到了一定阶段。地利指的是我们做的事情是不是公司或者平台的主要方向。人和指的是团队的技术储备。只有集齐了这三点才是产品成功的基础。

　　360在产品方面做了很多尝试，如可穿戴的手表，智能监控的设备，行车记录仪，机器人、故事机、手机，花椒等等。这些主要是面向消费级的产品，所以有更多细节需要打磨。

　　Conversation AI整体架构分为三个部分，一个是面向具体任务的Bot，例如订餐或者查天气，类似于这样在某个领域做具体的事情;第二个是问答系统，提问一些事实性的问题并获得确定答案，例如最高的山是什么?天空为什么是蓝色?第三个是chatbot，实现人机的智能聊天，例如业界的典型代表是微软小冰。

　　这三个方向根据具体业务场景的不同而有不同的定位。例如，小娜更多是在室内使用，提升便捷性;智能客服更多的是问答系统，提升客服效率;陪伴机器人更多的是情感维护方面。不同的产品定位导致它们会对三个方向有不同的侧重点。

　　典型的Conversation AI系统架构会有上图所示的几个模块，最左边的是ASR，也就是语音识别，将语音转换成文本，之后的SLU模块对文本进行理解，解读用户意图;有了用户意图，就要尝试和用户对话，通过连续的对话过程更加清晰理解用户意图，这时我们会有DST和Dialog Policy模块，通过这个系统和用户进行多轮对话;之后要给用户做出反馈，如果这个反馈是文本，那么还需要TTS将文本转换成语音。

　　这就是基于语音交互的整个逻辑，而且这个逻辑是比较经典的，大家可能在很多论文中都看到过这种架构设计。

　　360在支持这么多产品的过程中，遇到过哪些困难呢?我会分别从四个方面来和大家分享。第一个就是具体的学术论文如何落地，这会涉及到工程上系统架构的问题;第二个是语音识别，这个方面突破很大，很多厂商都宣布自己可以达到百分之九十几的识别准确率，但这个数据其实是在相对安静，没有噪声的场景下测得的，如果是在有噪声的情况下，准确率能够达到60%~70%就不错了。而且如果是做toC端的消费级产品，语音识别的场景会更复杂，比如背景噪声、鸡尾酒问题等等。第三个是冷启动问题，例如我们要做一款音箱，用户说放音乐，没有音乐类的语料怎么办?目前比较流行的做法是训练机器学习模型来做意图识别，这就引发了一系列的问题，例如语料来源如何解决，质量如何控制，训练数据集需要到达多大的量级?第四个问题是产品上线之后，如何持续优化?

　　NLP系统在架构上最主要的矛盾点是软件工程的模块设计需要分层，但是NLP系统所有的子任务目前无法达到100%的准确率。在实际业务场景下，遇到这种算法不是100%正确的情况，算法的结果怎么往下传递呢?如果传递的话，又会遇到系统级联导致的准确率下降的问题，比如每个模块都是95%的准确率，经过三次级联或者四次级联之后，误差会被放大到一个不可承受的地步。所以系统架构上要考虑好如何保留和传递不确定的信息。

　　在我看来，这两个矛盾在整个架构上是不可调和的，一个是要求模块化输出，另一个是现有技术无法输出确定性的东西，只能传递不确定的东西。

　　怎么解决呢?业内公认的做法是前面模块不用给出条件不成熟的确定性结论，可以传递一些不确定的结论，但是也不能什么信息都往下游传递。例如做一个二分类模型，如果分类算法输出一个0到1的概率值，比如0.5，那么在下游模块中怎么使用呢?如果你把问题直接抛给下游模块，那么下游模块就会很痛苦。但是如果上游模块输出0,1,2三档，0表示一定不属于该类，2表示一定属于该类，1表示不确定，那么下游模块就比较好做一些策略性的东西。因此，上游模块不仅是不要做出绝对的0和1的判断，但是也得要传输一些相对确定的信息。

　　如果你非常追求完美，那么这个问题无解。如果不是，我们可以尝试下面的做法：第一就是要在模块分层和不确定之间做平衡，确定传递多少不确定信息到下游模块，就像我们刚才说的对置信度做分层;第二，对话AI有很多任务，我们可以选择集中式或者分布式来理解所有意图。用一个模块来理解所有意图，然后调用相应服务，这是集中式;分布式是指有上百个服务，每个服务既要理解意图又要调用服务。

　　在实际使用中，我们发现集中式更好用。例如，“我要去拉萨”，这既可能是要去拉萨旅游想要订机票，同时这也是一首歌，可能是想听音乐。如果采用分布式无法判断采用哪个服务，而且每个人的需求都不同，无法做到默认。而采用集中式，我们可以在一个模块中识别出所有意图，统一的流程和框架有可比性，可以减少很多下游的工作量。

　　第三是通用性和定制化，开发人员总是希望可以做一个通用系统，但是在实际任务中，总会遇到业务方的频繁修改。如何在通用化和定制化之间做一些平衡?我们的思考是更多的考虑通用性，但同时也要考虑可扩展性，去做一些定制化的事情。

　　基于上面的几点，我们的架构大概分为三部分，语义服务，是对话系统的线上服务;数据平台，为系统提供一些基础的模型和数据;第三个是语义理解的DEEP-X开放平台，目前这种平台的定位有两种，第一种是像科大讯飞，其上有数十上百个Skill都已经做好，你只需做组装工作就可以。第二个是像谷歌或者Facebook这类定位给开发者使用的平台，可以提供一些API组建，让开发者可以定义自己的skill。而DEEP-X平台不但提供了很多内置的Skill和通用的解决方案，也提供给开发者定制自己的Skill的能力，同时还提供了强大的业务数据分析平台和服务监控平台。

　　Deep-X平台是我们的一个重点，它大概由这几部分组成：第一部分是SDK接入端，用于对接各种硬件和软件产品。第二部分是开放平台，包括BOT搭建，以及Skill定制化等模块。DEEP-X平台会把定制化的Skill通过数据和模型的方式输出到语义服务的意图理解和对话管理的模块中。

　　这就是刚才提到的集中式意图理解架构，来了Query以后首先是做分词，词性标注、组块分析、句法分析。基础分析之后，会有三大模块，第一个是Task，第二个是问答系统，第三个是chatbot，通过三个模块分别达到对应的意图以后，进行中控意图merge模块。

　　ASR识别不准有很多原因，第一个是硬件设备不好，单麦克风，不是一个麦克风阵列，天然就会导致在去噪声、去背景声方面会遇到很多问题;第二个是特定领域的语料很少，导致语音识别系统拿不到足够的数据训练语言模型，比如很多的实体词属于未登录词，不在原来的语料里面，导致领域实体和语料的缺失，会直接影响到ASR的识别效果;第三个是我们的很多的产品是服务于儿童的，例如机器人和故事机是服务三到五岁的儿童，儿童的语言表达不是那么准确清晰。举个例子，“我想听小红帽”，小孩可能会说出小红猫，而ASR没有识别到这个歌曲，所以就需要将ASR识别错误的结果纠错成正确的结果;再比如酒干倘卖无也经常被表达的乱七八糟，我们的技术也可以做到准确识别;

　　对于任何系统来说，纠错都不是一个零和一的问题而是概率问题，例如，我有90%的把握认为我纠的是对的，也有可能70%的概率是对的。这就是我们刚才提到的系统要做分级，意图置信度也要做分级等等的原因。本身技术也许不是完美的，但是可以通过一些策略让交互更流畅，如果置信度是95%，那么就强制纠错;如果对纠错结果感觉置信度高，那么就可以通过多轮对话技术，询问一下用户，“是不是想听小红帽的故事?”来做意图确认。

　　另外，还有一些是用户口音或者是因为设备拾音导致的问题，用户本来要说“唱一下七里香”，结果发音是“上一下七里香”，纠正用户的表达方式也是纠错模型需要解决的问题。

　　在实际做系统的时候，如果你有很多标注语料，那么就会变成一个有监督的模型学习的问题，但刚开始没有标注语料怎么办?

　　意图识别本身是一个多分类的问题，加上一个NER的问题。如果有语料，我们可以利用很多模型，例如LR、SVM、CRF或者deep learning来做这个事情，但要是没有语料，就会困难很多。

　　对话本身是一个概率转移的问题。上句话说什么，下句话机器要怎么做回答，本身就是状态之间概率转移和对话策略选择的问题，如果有语料可以通过强化学习等方法来解，但是大多数情况下，语料的获取和标注非常困难，特别是多轮对话语料库。

　　对于问答系统来讲，需要解决用户的query和知识库里的<question, answer> 的语义相似度问题。分解开来看主要包括：一是 <question, answer> pair的正确性问题;二是query和<question, answer>的语义匹配问题。那么怎么计算query和< question, answer > 的语义匹配度呢?假如我有很多的query和< question, answer > 的语义匹配标注数据，那么可以使用deep semantic matching的技术来解这个问题，如果没有怎么办?

　　还有一个是chatbot，目前比较成熟的是通过检索的方式来做，构建一个大规模的口语对话语料库，然后用搜索的方式去解，但是也会遇到点击反馈的问题，怎么知道回答的结果好不好呢?

　　如果task-oriented没有语料库怎么办?Deep-X平台提供了一种解决方案，我们会先去尝试定义一套意图，包括query类别以及query本身里面的实体，用户的定义过程本身就是做一个query标注的事情，有了这个标注结果，我们可以自动的将其转变为ABNF文法，就可以解决冷启动的事情。

　　对话本身也是没有数据的，用户前一句说什么，后面要用什么做回复，在冷启动阶段可以考虑使用DFA + slot filling的方法来解。

　　有语料了就可以做数据标注，然后可以做一些分类和NER的模型来解决意图理解的问题。在设计模型的时候也会遇到很多问题，例如典型的做二分类，假如两个类别的语料是平衡的，这是比较好解的。最怕的是遇到语料极度不平衡的问题，比如我要从几千上万类Skill中识别出订餐类的query，就会遇到与语料不平衡的问题。这个问题如何解决?我们可以考虑挖掘出处在分类算法的分类面附近的query，让用户去做hard examples的数据标注工作，通过较少的数据标注来提升算法性能。

　　上图是实际系统中关于task的真实例子。

　　第二个是QA问答系统，在冷启动阶段，如何解决query和< question, answer > 的semantic matching所需要的大量标注数据?如果实在没有数据，可以考虑先使用一些启发式的算法，通过语音交互的行为，来迭代算法或收集语料。或者你可以使用transfer learning的方法，考虑使用搜索的用户点击行为，来构建语料库。比如我们使用360搜索的点击日志，构建了大规模的<query, question>的语义匹配数据。

　　目前，问答系统实际用的架构分为事实性和开放性，事实性问题例如姚明身高多少?开放性的问题，例如红烧肉怎么做好吃?每个人都有不同的见解，开放性的问题会有很多不同答案。针对问题做不同的分类，应用不同的技术去解决，比如事实性问题通过知识图谱解决，开放性问题通过CQA-QApairs的方式进行。如果对于一些不确定且又不在这两类范围内的问题，通过搜索引擎对前几百条的结果做摘要来解这个问题也是可行的。

　　ChatBot比较靠谱的是基于检索做大规模的扩充语料，我们的优势在于有自己的Spider，每天对几千亿网页数据抓取、清洗、解析，还可以抓到很多微博论坛的数据，构建了亿级口语对话库，基于这个对话库可以做检索的对话系统，它的主要技术就是进行索引，做query和response相关性计算的问题。

　　口语对话最简单的就是单轮，你说一句，我说一句，多轮就是你说一句我说一句，你再说一句我再说一句。现在衡量一个ChatBot能力就是看你能够聊多少轮，据悉小冰现在是5轮。检索是目前效果不错的，但也存在一些问题，比如怎么评价语料库库构建的质量?

　　学术界研究的更多的是生成式对话系统，现在比较不错的是利用基于深度学习的架构来做。右边的图是我们生成的模型生成一些对话，例如用户说“下大雨了”，回复说“还没有下雨呢”，用户说“不可以喝牛奶你陪我玩会儿吧”，回复说“说不能喝牛奶的”，等等。虽然目前生成对话系统有些是可用的，但是大家可以看到它更多的是安全回答，没有包含一些情感在里面。

　　第二个问题是在遇到一些用户的属性信息时要保持前后一致，比如用户问“你是男的吗”，系统回答“是”，用户再接着问“你有老婆吗”，系统如果回答“我是女的，没有老婆”，这就出现了人设前后不一致的问题。目前业界也在对此做研究，我们也在做这方面的研究。

　　下面我们讲讲持续优化的事情，刚才也提到分类以及NER识别。分类问题在刚开始冷启动、语料很少的情况下，我们模型的准确率不够，要做一些半监督的事情，例如Deep-X系统，根据线上的系统日志可以自动的挖掘出一些可能不太靠谱的或者是有错误的数据推给运营人员做标注，这是一个半自动标注方法，这个事情做完以后，开发人员不需要天天看数据优化模型了，只要有运营人员帮忙标注数据，这个模型就可以运转的非常好了，同时这也是大部分技术人员希望达到的状态。

　　此外，还需要一些指标来评估服务的效果，比如说你的意图识别的准确率，召回率，目前在Deep-X平台中，这些事情都已经做到自动化了，每天可以把数据给用户做展示，方便用户去运营。为此我们做了非常多的运营工具，当然这所有的一切都是为了节约工程师的时间，把技术模型的迭代转变为通过数据标注的方式来做持续优化。