|
大家好，今天我演讲的题目是When KG meets Chatbots，即当知识图谱遇上聊天机器人。具体来说，我们主要探讨一下，在聊天机器人（Chatbots）中，知识图谱（KnowledgeGraph，KG）将如何融入，起到重要的支撑作用。 我的报告包括四块内容，首先是简介，全面介绍Chatbots的生态。其次，我会着重介绍一下为什么需要KG，尤其是在Chatbots应用中引入知识图谱的价值。接着，我将根据自身在带领开发公子小白和Holoera等旨在创造虚拟生命的聊天机器人产品的经验以及结合Chatbots应用落地的思考，与大家一起分享一下Chatbots需要怎样的KG，并列出将KG应用于Chatbots所面临的核心挑战；最后，我将总结KG用于Chatbots的几大典型应用。 简介首先，我们来回顾一下聊天机器人的历史发展。对话问答是极具挑战的，伴随着人工智能的发展，Chatbos往往被作为杀手级应用来证明人工智能技术已经达到了相当的高度。纵观其时间轴，我们不难发现从2010年起，Chatbots产品或平台推出的频率较之前明显提升。与此同时，推出方也逐步从学术界主导渐渐转变为互联网巨头公司。这也意味着，随着大数据的积累、计算能力的提升、以及各项人工智能技术慢慢成熟，以及用户市场的培育，Chatbots慢慢从验证技术向应用落地转变。很多专家也戏称2016年为Chatbots元年。 我将从SIRI开始对目前知名的chatbots产品和平台做一个详细的介绍。在此之前，我不得不提到两个重要的早期产品。作为第一个吃螃蟹的，ELIZA诞生于1966年，开发者为MIT的JosephWeizenbaum。它是一个模拟罗杰斯心理治疗的BASIC程序，是自然语言处理方面的先驱者。另一个不得不提及的便是A.L.I.C.E，起源于美国国防部DARPA的一个项目，它诞生于符号AI鼎盛时期，基于规则和模板来处理问句理解和回复逻辑。他对Chatbots的后续发展起到了非常深远的影响。它的一个贡献是定义了AIML，一种类XML的声明式语言，可以用来编写各种问答对，甚至多轮对话的对话逻辑。这种做法对于数据规模小，且领域知识相对充足的情况下，非常利于解决冷启动并提供表现不错的对话体验，同时也是对当前基于机器学习尤其是深度学习方法的一种补充。不仅可用来积累数据，也可以提供可解释性更强，且能针对个别用例做针对性地在线干预和修正。所以，到目前为止，大部分商用聊天机器人尤其是特定领域的对话应用沿用了这一思路。 在作详细介绍之前，我们先对聊天机器人从分类角度进行一定的梳理。我们从最简单的二分类着手，即Chatbots根据其用途或使用场景，可以分为偏娱乐化或偏工具化。图中给出了一个鲜明的对比，白富美的Eva更擅长的是情感陪伴，而蓝领工人Wall-E则更擅长完成特定的工作。这两者由于目标不同，所以往往在Chatbots设计和技术选型上会存在一定的差异。微软公司很早就洞察了这一点，针对偏娱乐化场景和偏工具化的应用分别推出小冰和小娜。 围绕Bots生态圈，有些在做实际的Chatbots，既有硬件形态的Amazon Echo及狗尾草公司推出的公子小白和Holoera等，也有纯软件的如苹果的Siri和微软的小冰等。除此之外，为了加速实际Bots的研发，不少巨头或创业企业开始对外提供Bot框架（Bot Framework），以SDK或Saas服务的形态供第三方公司使用来构建特定应用和领域的聊天机器人，这里的典型代表包括支持Echo的Amazon Alexa和微软推出的包含在Cognitive Services大框架下的LUIS with Bot等。更进一步，除了提供开发Bot的API，Bot平台（Bot Platform）进一步考虑开发得到的Bot如何部署到一些常用平台中如微信或Facebook等。 聊天机器人的成功离不开智能。而图灵测试常常被用来测试机器是否具有真的智能。图灵测试是指测试者在与被测试者（一个人和一台机器）隔开的情况下，通过一些装置（如键盘）向被测试者随意提问。进行一系列时长为5分钟的测试后，如果有超过30%的测试者不能确定出被测试者是人还是机器，那么这台机器就通过了测试，并被认为具有人类智能。图灵测试一词来源于计算机科学和密码学的先驱阿兰·麦席森·图灵写于1950年的一篇论文《计算机器与智能》，其中30%是图灵对2000年时的机器思考能力的一个预测，目前我们已远远落后于这个预测。2014年6月7号，正值图灵逝世60周年纪念日，一款名为尤金·古斯特曼（Eugene Goostmanz）的聊天机器人，它伪装成了一个用第二语言沟通的13岁乌克兰男孩儿，成功“骗过”了测试者，通过了图灵测试。不过事后有很多质疑。首先，这个聊天机器人号称只有13岁，并使用第二语言来回答问题，以此作为重大缺陷的借口。另外，测试者只有5分钟与之展开互动，大大增加了他们在短期内被“欺骗”的概率。尤金无法一直保持对话的顺畅性，他会不断重复自己的话，还经常使用聊天机器人典型的无推断型回应方式。 我们对聊天机器人按照功能和交互方式等二个维度可以进一步细分为四类。交互方式可以分为主动交互或被动交互。目前大家接触到的大部分聊天机器人都属于被动交互的范畴，即由用户发起对话，机器理解对话并作出相应的响应。而主动交互能更好体现机器人和用户之间的对等关系，即通过共享或推荐用户感兴趣或热点事件等由机器人首先发起。目前主动交互更多作为传统交互方式的一种补充，作为辅助手段，并未大规模得到广泛使用。从功能角度来看，聊天机器人可以细分为以闲聊为主的聊天，问答和面向任务或目标的对话。其中，若根据场景切分，闲聊可以进一步分为情感交流和针对客观话题的讨论。问答系统需要不仅考虑如What、Who、Which、Where和When等事实型问答（Factoid QA），也需要考虑如How和Why等非事实型问答。 Siri作为iPhone4S推出时的一个亮点特征，定位是语音个人助理。在推出之时，引起了极大的轰动。虽然这么多年Siri的技术也不断提升，但我觉得他更大的价值是作为聊天机器人之门开启的开门砖，教育了用户和市场。回到刚刚的分类，Siri其实是一个面向特定任务的对话系统。他对接了很多本地服务如通讯录、音乐播放等以及Web服务如订餐、订票和导航等功能服务。针对这些服务意图，他通过实体驱动的自然语言理解（Natural Language Understanding，NLU）来识别问句中涉及到的对象和相关服务，从而实现特定任务下的多轮功能交互。对于解决不了的问题，即服务意图范畴外的需求，则直接调用搜索引擎返回相关答案来返回。随后，Siri的核心人员DagKittlaus和AdamCheyer于2016年推出了Viv。Viv被认为是Siri的升级版，虽然其在多服务组合，服务编排等方面做了不少亮点工作，但背后的基本原理和定位和Siri无差异。 正如之前介绍的那样，微软针对娱乐化和工具化这两个截然不同的定位，分别推出了小冰和小娜（Cortana）。小娜，作为嵌入在Windows或Windows Mobile等微软操作系统内核的语音个人助理，承载着类似Siri或Viv的角色，它的目的是提升用户的工作效率，据说Cortana有1.5亿多用户，这也使得微软吸引到Bengio这样的大师作为顾问加入。另一方面，小冰是微软中国团队推出的娱乐聊天机器人。她的人设是一位16岁的少女。小冰是一个基于搜索的回复检索系统。通过各种基于深度学习的语义匹配算法，从海量的问答对语料中返回最佳的回复（Message response而非Answer）。小冰也会不定期推出新的技能供大家使用，这些技能往往包含了微软团队在图像理解、语音和自然语言理解方面的各种小应用尝试。更值得一提的是：微软针对日本、北美和欧洲等市场陆续推出了具有不同人设的少女如Rinna、Tay和Zo，她们往往可以方便的通过微信、微博或Twitter等平台进行交流。 Watson系统是典型的问答系统，其由IBM研究院在2011年推出，参加美国知识竞赛Jeopardy!（危险边缘）并挑落人类冠军而名声大躁。相比AlphaGo或早年IBM研制的战胜卡斯帕罗夫的国际象棋人工智能程序深蓝，Watson具有更清晰的商业路径。IBM斥巨资成立医疗事业部，并与MD Anderson等知名医疗机构合作推出面对特定病种（尤其是癌症）的辅助诊断AI医生。与此同时，Ross Intelligence依托Watson认知计算平台推出了法律咨询系统。回到技术层面，Watson所用到的知识库是一个广义的知识库，不仅包含各种结构化知识、也包含各种文本语料和语言学知识。整个流程称为Deep QA，包含问题分解、假设生成、基于证据的融合排序等关键步骤。这里的Deep QA并非指通过深度学习（Deep Learning）技术来提供问答。事实上，Watson诞生于深度学习大热之前，这里的Deep是指通过深度解析（Deep Parsing）来实现对问句的真正理解。 众所周知，自然语言处理往往包含诸多步骤，传统的做法会将这些步骤通过串接的形式形成pipeline来完成从词法到句法最后到语义的过程。这样做法的最大问题在于，由于每一环节的组件都不是完美的，通过串接方式形成的系统易产生错误传递和放大，导致整个系统无法在生产环境中使用。针对传统NLP的局限，Watson通过如下手段来进行改善：1）对于每个组件，采用多种实现算法并集成来避免单点失败从而增加每一环节的准确性和鲁棒性；2）在候选答案生成阶段以覆盖率为主要目的，避免过早的将正确答案过滤掉；3）引入证据源和基于多证据的打分（类似循证医学）来确保正确答案的排名位于首位或头部地位。总而言之，Watson做了精细的模型分拆和设计，并基于集成学习和知识库的结合来实现传统做法（如TREC的QA任务中采用的方法）无法达到的精度和覆盖度。 之前已经提到Facebook Messenger是一个庞大的Bot平台，有非常活跃的开发者群体，平台包含上万种Bots。针对Messenger，我想讲以下几点：第一，它在 2014 年收购了wit.ai。Wit.ai类似于谷歌所收购的api.ai，包含大量的行业相关或场景相关的对话。基于以上高质量海量的对话数据，Facebook基于深度学习技术推出了一个用于自然语言处理的框架叫DeepText，用于自然语言表示学习和各种分类等任务。有名的 Fast Text 也包含在内。今年Facebook更是基于Deep Text推出了CLUE，进一步提高了其易用性，有兴趣的可以去进一步了解一下。通过以上的数据和技术积累，Facebook就可快速构建一个端到端的Chatbot或者问答系统。此外，还有一点需要强调的是，我们可以发现Facebook Bot的很多应用场景涉及到购物、递送礼物、预约参观和安排旅程等非实时任务，即相对比较复杂，但不要求马上得到反馈。传统的做法是，通过指派一名客服来对接，提供进一步的服务。对于这些非实时任务，Facebook结合机器返回的自动化推荐结果和人工的进一步编辑和审核来保证用户体验的同时也降低了纯人工对接存在效率低、工作量大等弊端。而这也是近期大家很推崇的人机融合，即赋予人工智能新的内涵：Artificial Intelligence+Human Intelligence（人类智能）=Augmented Intelligence（增强智能）。
Alexa作为亚马逊Echo智能音箱背后的Bot框架，通过Skill Set的形式不断扩展其功能，其内核是亚马逊在2016年底发布的Lex，并对接专注图像识别的Rekognition和基于机器学习特别是深度学习技术的快速TTS（文本到语音转换）。细心的观众会发现Echo音箱并没有提供任何屏幕，仅通过语音进行交互，依托Amazon的内容资源和电商购物优势提供各种智能交互。这种以语音为主的交互方式在家庭、车载等领域得到广泛关注和应用，由此也提出了Voice UI的概念。除了语义理解，这里需要强调的是：对于Echo音箱的交互，是采用远场（通常3—5米）沟通的。对于远场语音交互，目前远比近场通讯的难度大，涉及到声源定位、噪声（如回声、背景噪声、各种声波反射折射产生的混响）消除、人声分离、声音增强甚至是声纹识别等各种技术挑战。目前通用的做法是采用麦克风阵列+波束成形等方案，不过有很大的提升空间。不过智能音箱是否能在中国成为一个爆款，这个还是一个未知数，当然这里涉及到更多使用习惯、价格、内容质量等很多非技术因素的考量，在此就不做具体展开。
从Google Now到Google Assistant，谷歌一直没有停止过在语音个人助理方面的尝试。这里想介绍一下基于Google Assistant的新一代人工智能类微信IM应用。Allo具有几个亮点：首先，其具备一定的自我学习能力。这里包括两方面的学习，一方面是学习用户的习惯，包括说话风格和交互模式。值得一提的是，Allo的开发者也参与了Gmail Smart Reply功能的开发，帮用户草拟回复的邮件。具体来说，根据邮件接收的对象、主题和关联的场景等，根据用户口吻来尽量完成要回复内容。另一方面也包括用户偏好的学习，这一点在推荐系统中是非常重要的，属于用户画像的学习。Allo学习用户画像的低维稠密向量化表示（User Embedding）。将User Embedding加入Chatbot的回复生成解码模型中，将有助于回复的相对一致性和个性化。 为什么需要KG
在介绍完聊天机器人的发展和一些典型Bot背后的技术原理之后，我们将重点说一下为什么Chatbot需要知识图谱（Knowledge Graph，KG)。
知识图谱于2012年由谷歌提出，旨在提供更好的搜索体验。随着整个Web从原先由网页和超链接构成的WebofDocs转换为由实体或概念及他们之间的关系构成的WebofData，谷歌提出了更准确的语义搜索，旨在解决原有的关键字搜索仅基于字符串无法理解内容语义的局限。在KG发展的浪潮中，也诞生了基于社区协同构建的众包典范Freebase。而谷歌的GoogleKG也是基于Freebase逐步发展起来的。同样还有Wikimedia社区所推出的WikiData项目，目前Freebase也已经关闭，并将数据等均贡献给了WikiData做进一步发展。此外，作为谷歌、Bing、Yahoo！和Yandex（俄罗斯搜索引擎）共同推出的Schema.org，通过鼓励站点所有者（SiteOwner）在其页面中添加符合Schema.org分类体系（及关联属性等）规范的语义知识片段（以嵌入在HTML页面中的RDFa或Microformats等形式出现）来扩充和完善知识图谱。据悉，25%的站点和30%的页面包括Schema.org的标注。对应的回报是提升特定关键字或实体查询时相关站点（提供与关键字或实体相关的高质量语义标注知识）的搜索排名，从而起到免费搜索引擎优化（SEO）的作用。当然，KG不仅仅只有以各种类型的实体为节点的实体图，Facebook则呈现了另一种关联人、事、物的兴趣图谱。相比谷歌的实体图谱，兴趣图谱节点和边的类型没有那么丰富，但是包含的节点数更多，稠密程度也更高。对于兴趣图谱上的搜索或问答也提出了不同的要求。为此，Facebook专门提出了一种针对性的图搜索，内部的项目名叫Unicorn（独角兽），有兴趣的可以去了解一下。
除了搜索，知识图谱也被广泛用于各种问答交互场景中。Watson背后依托DBpedia和Yago等百科知识库和WordNet等语言学知识。类似地，Alexa也依托其早年收购的TrueKnowledge公司所积累的知识库；Siri则利用DBpedia和可计算的知识服务引擎WolframAlpha；狗尾草公司推出的虚拟美少女机器人琥珀虚颜则用到了首个中文链接知识库Zhishi.me。伴随着机器人和IoT设备的智能化浪潮，智能厨房、智能驾驶和智能家居等应用层出不穷。无独有偶，百度推出的DuerOS和Siri的进化版Viv背后也都有海量知识库的支撑。
KG也越来越多地被用于辅助决策。这里无外乎是通过对文本、多媒体和各种传感器产生的原始数据流建立更加规范的数据表达，通过语义抽取、数据链接形成更多机器可理解的语义知识，从而将原本异构分散的各种数据转变为机器可计算的大数据。通过可计算机的大数据，人们更容易发现领域或行业内原先不为人知的规律或一些有趣的模式，从而更好地做出决策。Plantir 就是这方面的成功应用典范，而ImageNet及Visual Genome等数据项目则极大地推进了图像语义理解和推理的进程。在构建用于辅助决策的知识图谱形成可计算大数据的过程中，如何将符号推理与统计学习有机结合起来，即碎片化的知识图谱上的推理和深度学习决策模型结合起来，形成所谓的Local Knowledge Powered Global Learning是非常有趣而富有挑战的研究课题。
KG也可辅助通用人工智能（Artificial General Intelligence，AGI），即在常识推理方面起到作用。过去人们常用图灵测试对机器的智能进行评估，近年来，Winograd Schema Challenge 逐渐进入大家的视线。这里举一个指代消解的例子。指代消解是一个经典NLP任务，旨在将代词指向具名实体。例如，Thetrophy would not fit in the brown suitcase because itwas too big (small). What was too big (small)? 当我们描述 it 是 big 时，人们很容易理解这时候是在说奖杯（trophy）；而当it与small搭配时，我们也很容易识别出在抱怨suitcase太小。这个看似非常容易的问题，却难倒了机器，这是因为人具有非常庞大的世界知识（world knowledge）和常识知识（common-sense knowledge）。当我们仅采用NLP技术来努力理解并给出答案时，正确率仅 50%；当结合知识时，正确率提升到了60%，而及格线是90%。因此，我们离真正的通用智能还有很漫长的路要走，需要更多的技术突破和数据积累才能完成这项挑战。 需要什么样的KG
刚刚对KG的各种应用做了简单的介绍。结合Chatbot，我们又需要怎么样的KG呢？
首先，Chatbot需要更加个性化的知识图谱。除了前面提到的实体KG和兴趣KG等开放领域的稀疏大图，我们也需要构建机器人KG和用户KG等个性化稠密小图。机器人或 Agent 需要图谱来建模和展示它的自我认知能力，而用户图谱则可被看作是更精细化的用户画像的知识表现。例如，机器人如“琥珀.虚颜”，有情感状态，喜好，技能等知识维度。同理，用户则需要表达其职业状态和生活轨迹等信息。需要强调的是，无论是个性化小图还是开放域大图，都不是独立存在的，需要将它们融合在一起，才能发挥更大 的价值。机器人喜欢吃的食物则需要和实体 KG 中的食谱图谱关联，而与用户形成经纪人、好友等社会关系，同时爱好方面则和兴趣图谱又关联在一起，可以实现机器人社交、机器人—用户社交和用户社交网络的统一连接。
其次，我们的世界不仅仅是静态的，而是动态地反映各种事物在时空上的变化。因此，我们不仅仅需要刚刚谈到的静态图谱，而是需要思考如何表示和应用动态图谱。对于一个机器人，它从早到晚会做不同的事情，也就是有自己的生活规则。我们该如何刻画生活轨迹呢？这就需要我们在图谱中体现时态知识。另一个例子，用户行程，即对于用户图谱，需要记住用户各种已经发生、正在星星或即将发生的事件。图谱中的行程不仅仅是一个关系或属性，而是一个由多元（N-ary）组成的事件。我们需要定义多种事件类型，并刻画时间和空间两个维度。
第三，机器人不能只是冷冰冰的回答用户的问题或帮助用户完成特定功能。它需要感知用户的情感并在输出答案回复的同时伴随着相应的情感，这样才更加拟人化。我们发现，之前构建的知识图谱大多是客观的，即描述一些客观的事实。如何在结合个性化图谱时，能包括一些主观知识，进而刻画机器人或用户的情感元素。例如，用户说：“我心情不好”。这属于闲聊中的情感表达范畴。这时需要将用户当前的心情状态更新到用户图谱的对应维度数值中。相应地，机器人也会有自己的心情、体力，甚至和用户之间的好感度关联。当此时，机器人心情不错，同时和用户很亲密时，它就会主动关心用户。这样结合机器人和用户情感因素的动态回复会更加温馨和贴合场景。当在多轮对话时，用户进一步说：“来一首快乐的歌吧”。需要进一步结合音乐知识KG（快乐作为歌曲的曲风或风格标签）和用户KG中的音乐偏好，推荐用户喜好的欢快的歌。
第四，我们发现聊天机器人为了完成很多功能需要对接外部服务或开放API。此时，图谱就需要从传统的关系型知识图谱（刻画二元关系）扩展到支持动态服务的动态图谱（刻画多元关系，事件属于服务图谱的一个特例）。另一方面，如何刻画服务之间的各种关系（如因果、时序依赖等）也是图谱扩展过程中需要考虑的。例如，当完成了订餐，会有很多Follow-up的服务（订花或预约车等）可作为后续服务被消费。建立这些服务之间的关联对于进行精准的多轮对话过程中的场景切换是非常有必要的。
我们接触世界的手段不仅仅是文字，而是结合图像、语音和文字等多模态来了解外部世界的。因此，我们所构建的知识图谱也应该从单纯文本自然扩展到多媒体知识图谱。而ImageNet和Visual Genome正是这方面的努力。但是这里我想强调的是对于用户图谱这样更新频度非常高且很稠密的KG，多媒体知识的引入能帮助机器人从更多的维度来了解用户，并提供诸如Visual QA等潜在的问答服务。例如，小明正在和琥珀进行交互，通过摄像头识别出当前交互的用户是小明根据小明的图像与用户ID的关联，进一步得到其长短时记忆，了解到他在4.20到23号期间会去北京出差，而4月24号要和小兰共进晚餐。此时，通过用户图谱中的社交关系了解到小兰是小明的女友，当我们需要进一步了解小兰长什么样时，或者当小兰出现在琥珀面前时，需要可以认出小兰，这时也需要用到我们提到的多媒体知识图谱。
总而言之，我们需要基于不同来源异构的数据来构建包含多类别且体现动态和个性化的知识图谱。这其中包括来自互联网的数据来刻画世界知识，用户数据来刻画画像知识，以及针对机器人的各种基本属性、社会关系、情感状态、兴趣爱好、以及日常生活等静态和动态知识。而我们得到的融合图谱是时空坐标中针对特定交互场景和时间节点的一个镜像。
从更技术的角度来说，我们需要考虑知识图谱将如何构建。这里不仅包含如何结合文本、多媒体、半结构化、结构化知识、服务或API，以及时态知识等的统一知识表示。在此基础上，需要进一步考虑如何结合结构化（如关系型数据库）、半结构化（HTML 或 XML）和非结构化（文本、图像等）多源异质数据源来分别构建通用事实类（各种领域相关实体知识）、常识类、用户个人记忆类、机器人自我认知类和服务任务类知识库等。针对不同类型的数据和不同种类的知识构建，有相应的构建技术，如针对结构化数据的知识映射、针对半结构化知识的包装器（Wrapper），以及针对非结构化知识的文本挖掘和自然语言处理。文本挖掘充分利用Web或大规模语料库的冗余信息来发现隐含的模式；而自然语言处理更多是做各种知识抽取（开放或确定schema的）。为了得到融合的图谱，我们除了离线的多源异构的知识融合，还需要额外考虑服务任务类动态知识的对象绑定，这块工作往往是在线完成的，相当于根据不同的交互，在线动态扩充知识图谱并实例化的过程。
所构建的知识图谱既包括事实类和常识类的静态全局大图、服务任务类动态图谱，也有对于每个用户不同的用户图谱和机器人KG。随着用户数量的增加，用户图谱的数量也随之增加。这些图互相隔离，但每个均与全局图谱关联来提供个性化的聊天机器人的对话问答服务。每个用户图谱+机器人KG又随着交互不断填充和更新其中的节点和边，导致此类图谱的读写频度均非常高。面对这样的图谱，我们该如何选择存储方案呢？从工程应用的角度，我们更愿意站在巨人的肩膀上，选择一个现有数据库或几个数据库的组合来形成高效的图谱存储。 注意：这里所谓的存储，不仅仅是将知识存放的问题，而是考虑存储之后是否可以根据图谱的规模、读写特点和查询推理等基础在线操作的效率等多个因素来考量。Mongo DB，作为面向文档（Document Oriented）的NoSQL代表，他支持无模式（Schemaless）的数据建模方式，即不要求一开始就将Schema都确定，而可以按需进行添加或修改。这对于需求经常变更或一开始对领域不是完全了解的情况下，支持自底向上方式的知识管理。不过Mongo DB仅支持数据库级别的锁，写入速度受限。对于读并发的提高，可以使用基于数据分片（Data Sharding）的分布式版本。关系型数据库MySQL应用广泛，也被用于Apache Jena（HP开源的RDF数据库）中TDB的存储引擎。而Elastic search支持图谱上的简单模式（如单关系或链式）查询，适合如Facebook Graph Search或聊天机器人中大部分口语对话，因此也是面向聊天对话的知识图谱存储方案之一；Neo4j是知名的图数据库，不同于RDF数据库，它的数据模型是属性图（property graph），基于图遍历（graph traversal）来实现各种查询功能，对于大部分熟悉面向对象编程的工程师来说非常容易上手。基于上述任何一个数据库或多个数据库的组合来满足知识图谱的管理都是工程做法。从研究的角度来说，希望做一个统一的存储和查询引擎，需要支持多租户（multi-tenant）环境下的海量个人和机器人知识图谱管理，以及融合个人图谱和全局知识上的查询分解、分布式环境下的查询路由和子查询执行，以及结果融合等操作。 4KG应用
刚刚介绍了聊天机器人需要怎么样的知识图谱，以及相应的一些挑战。下面列举在Chatbots中KG的一些典型应用场景。
第一个应用叫实体识别和链接。实体识别称为Named Entity Recognition，简称为NER。在传统NLP任务中，仅能识别PERSON（人物）、LOCATION（地点）、ORGANIZATION（组织机构）、DATE（时间日期）等有限类别。在实际应用中，NER的主要挑战在于识别大量细粒度实体类型，比如以Schema.org作为实体类别的分类体系，这里有很多标注数据充足的大类，也有很多缺乏标注数据的小类，如何保证在小类上的识别准确率。此外，分类体系是有层次结构的，如何保证底层的细粒度类别上有令人满足的识别率。例句“我想听一首海阔天空”中的“海阔天空”通过NER任务可以识别为是一个音乐作品。仅仅这样是无法执行对话意图“音乐点播”的，我们需要进一步将候选链接到知识图谱中的给定实体，这一过程称为Entity Linking。这里的核心在于歧义消解，一般借助于候选周围的其他实体或用语作为上下位来帮助去歧义。如果如例子所示，仍然无法明确是哪个实体，可通过反问来引导用户来给出更明确的实体指引。在实体链接过程中，我们所面临的挑战在于如何应对新兴实体（Emerging Entity）和实体的新兴说法（各种新说法和别名）。
聊天机器人依赖于NLP，而大量NLP任务可转换为有监督的分类或序列标注问题。我们往往会为特定任务下标注数据的缺乏或不充足而发愁，这一点在利用深度学习时尤为严重。这时，也将推出知识图谱的第二个典型应用，叫做数据增强，也就是说Data Augmentation。具体来说，通过将知识图谱与文本语料库关联，形成大量弱标注数据。这在关系抽取或事件抽取等任务上应用广泛。例如，对于三元组<琥珀，喜欢吃，葡萄>，通过一定的泛化，我们将琥珀转换为PERSON，即在Web上收集PERSON和葡萄共现的描述片段，这些描述片段可能代表人物喜欢吃葡萄的特定模式（蓝色例句），也可能代表噪声（红色）。如何通过聚类分析中的异常点检测或噪声建模等方式将弱标注语料中的噪声识别并剔除。当然，包含一定比例的随机噪声，对于模型训练是一定帮助的，可以保证模型具有一定的泛化能力和鲁棒性。使用Web作为关联的语料库，主要看中Web上描述比较多样化，且信息具有冗余性，可以在保证覆盖率的同时确保数据的分布贴近真实情况。然而对于以语音作为主要交互方式的口语化聊天对话场景，我们仍然需要考虑从Web语料上学习到的模式或训练得到的模型如何进一步迁移适配。
第三个应用就是知识问答（KB-QA）。其中句理解的难点在于NLU，而候选答案生成则与检索过程关联，至于答案融合和排序，则重点考虑各种基于证据的收集和学习排序算法。这里我们看一个真实的例子，比如说“你觉得胡海泉这个人怎么样？”，这是一个意见询问类查询（opinion query），此时可以有很多回答，为了使得答案的多样化，除了利用摘要技术（summarization）从百科站点中得到“胡海泉是个歌坛巨星呀”之外，通过机器人KG中的经纪人关系，可以显式表明琥珀和他的关系。更进一步，可以通过琥珀记忆和技能关联，主动推荐“海泉给琥珀写的歌”。当用户给予明确的回复时，将表演自己的才艺，即唱自己的歌。在我们所描述的知识图谱下支持问答，需要额外考虑： 1）如何统一对实体、问句、图像、上下文进行统一的表示，映射到同构的语义空间中？ 2）知识库永远不可能是完备的，如何从KB-QA扩展到支持知识库和Web的混合QA场景下，并提供精准的数据源选择和语义解析？ 3）如何评估问句的复杂程度，并从单一知识库查询扩展到多知识库查询？
知识问答中非常有挑战的是Multi-KB环境下的问答。这对问句分解和知识源选择等都提出了更高的要求。更有挑战的是：不仅仅一句很复杂的话会涉及多个KB，即使对于很简单的话，往往在聊天的多轮交互中，会逐步涉及不同方面的KB，甚至需要在某个看似不经意的回复中用到某个KB。在研制小白的多轮对话中，需要考虑属性询问、反问、记忆、反馈、基于跨库属性比对后的评论，基于上下文的问答、事实类知识图谱查询、对复杂问题的导流、推理联想，调教以及用户类知识图谱的查询等。例子“我靠，居然比姚明还高”就是一个多知识库问答之后的回复生成。其中，姚明身高属于事实类知识库、“我靠”等惊讶的回复，是通过常识知识库了解到很少有人身高超过2.26米，而通过用户个人知识，其身高数值比姚明还高，而返回“比姚明还高”的回复片段，最后通过融合，得到最终的返回。
第四个KG的应用就是联想和推理。这里我列举了三种推理，但实际情况下不局限于这三种。第一种是空间推理，比如说“桌子上面有电脑，电脑旁边有水杯”，然后问，“桌子上面有什么”，正确的回答是电脑和水杯。 桌子上有水杯是通过空间位置的判断得到的。空间推理在地理类问答和智能家居控制等应用中有非常广泛的应用。第二种是答案类型推理。答案类型（Answer Type）作为一种很重要的证据，对问答的准确性有很大的作用。这里的推理包括实例推理（如例子中乒乓球是一种运动）、上下位推理（白色家电是一种家电）和互斥推理（空调和电视没有交集）等。第三种是场景推理，即结合场景业务规则和相关常识知识进行一些联想。例如空调需要一定时间之后才能制冷，而用户在这段时间感到热时可以吃一些冷饮。除了这三类，冲突检测对于聊天机器人尤其是用户记忆很有价值。这里不仅包括前面提及的类别之间的互斥定义，还可以包括关系单值或数量约束，甚至形成很多由推理得到的事实和显式定义的事实组成的冲突关系链。这些对推理机的表达能力提出了更高的要求。 至此，我给大家介绍了聊天机器人的发展历程和知识图谱的应用，探讨了针对聊天机器人我们需要怎么样的知识图谱，并列举了知识图谱在表示、构建、存储、以及实体识别与链接、数据增强、知识问答，甚至推理与联想方面的机遇和挑战。我希望今天的演讲可以激发大家对知识图谱与聊天机器人结合的兴趣，一起参与到其中的各项研究中。大家有兴趣也可以扫描二维码，了解狗尾草公司在构建公子小白和Holoera琥珀虚颜虚拟生命方面的更具体信息，谢谢大家！ |
|
|
