作者：李维
感谢龚才春博士整理
话说天下群雄争相研究知识图谱，而真正对知识图谱和问答系统研究深入透彻的，唯谷歌和李维老师是也。听说李维老师将在凌晨3点给大家分享知识图谱和问答系统的知识，大家都非常愉快，有诗为证：
今晚硅谷悄悄静，微群设摊待维老。
知识图谱说根苗，估量讲到雄鸡叫。
By 洪涛老师
雄鸡叫，不睡觉，定把智普都学到。
手拿板凳准备好，静等师傅来布道。
By 马少平老师
颇有难度起阶HOW，盖因听众水平高。
讲师竹筒蚕豆倒， 听者瓜子嗑不少。
By 洪涛老师
一、引子
在谈论知识图谱和问答系统之前，先给出几篇以前的文章。第一篇文章是《立委科普：问答系统的前生现代》，以前也发过，再发一下。详见博文：http://blog.sciencenet.cn/blog-362400-436555.html
下一个姐妹篇《立委科普：自动回答 How 与 Why 的问题》。这篇文章详细谈谈问答系统中的How类型问题和Why类型问题。这篇已经太长，收住吧。希望读者您不以为太呆板，如果有所收成，则幸甚。感激您的阅览。
How 类型的问题征采的是办理方案，实在也不好回答，同一个问题每每有多种办理档案，譬如治疗一个疾病，可以用各种药品，也可以用其他疗法。因此，比较完美地回答这个 How 类型的问题也就成为问答系统研究中公认的难题之一。
Why 类型的问题是要探求一个征象的缘由或动机。这些缘故原由有些是显性表达，更多的则是隐性表达，而且险些所有的缘故原由都不是用几个大略的词或短语就可以表达清楚的，找到这些答案，并以得当的办法整合给用户，自然是一个很大的难题。
第三篇文章《立委科普：从家当角度说说NLP这个行当》，这是几年前吹的牛皮。详见李维的博文：http://blog.sciencenet.cn/blog-362400-434811.html。由于也很干系，以是也放在这里。NLP技能的工业可行性我认为已经完备被证明了，虽然很多人大概还没故意识到。证明的实例表现在我们办理了三个信息搜索的难题：
搜索 How类型问题的难题；
搜索 Why类型问题的难题；
对客户反馈情报及其动机的抽取（譬如客户对一个产品的好恶）。
前两个问题是问答搜索业界公认的最难类型的题目，第三个题目涉及的是措辞征象中较难把握的主不雅观性措辞（subjective language），并非NLP中常日面对的客不雅观性措辞（objective language）。这类从文本中提取主不雅观性措辞的技能，即情绪提取（sentiment extraction）成为措辞处理最难的课题之一。
从问答系统角度来看，回答Who、When、Where等实体事实型（entity factoid）问题比较大略，技能相对成熟，最突出的表现便是IBM的问答系统赢得美国家喻户晓的电视智力竞赛Jeopardy的冠军。Jeopardy的大多数问题是属于实体事实类的问题，而这类问题的处理技能相对成熟。电脑打败了人脑，详见 COMPUTER CRUSHES HUMAN 'JEOPARDY!' CHAMPS。详细细节就不谈了，往后有机会再论。总之，这三大公认的难题在过去五年中被我们一个一个办理，标志了作为实用技能的 NLP 已经由了须要证明自己的阶段。
二、问答系统在搜索引擎中的利用现状
由于各种缘由，全体行业的现状是慢了半拍。而我们自己做的产品虽然也大数据了，云端了，也有环球用户了，但实际上平台还是不足大。
我们的 HOW QA系统实际已经支配五六年了，可行性和有效性该当说没有什么值得疑惑的了。从理论上讲，我们的系统是 open domain 的，而且很随意马虎对接上搜索引擎，因此任何一个搜索巨子都可以用上这个技能。对接办法也特殊大略，便是在Query Plan模块中止定一下查询中是否含有 How QA，有就去调用这个别系。
调用往后的结果一定比搜索引擎现有的结果俊秀很多。但是各大巨子做了知识图谱，用到了What QA，还没有任何一家用到了How QA，莫非How型问题不常见么，或用途不大么？当然不是。How QA没有被巨子商用的缘故原由基本上便是巨子并不总是看得见小公司的创新。
在另一方面，由于平台不足大，商业代价不足有力，末了这个靠向用户收费的产品还是歇菜了。商业模式没有让它赢利，歇菜是自然的。
可对付目前主流的搜索引擎的商业模式，靠的不是向终极用户收费，而是提高用户的体验和粘性，然后向广告主收费。这种环境下，这个用图谱来支持问答的技能就该当可以着花结果的。当然这统统便是一个韶光问题。终极一定是成为搜索的一个部分的，这一点没有疑问。知识图谱回答了 What和Who的实体类事实型问题往后，回答更难的How和Why的问题是搜索变得越来越智能的必由之路。
话说回来，乃至连业界公认已经成熟的 factoid questions （when、where 之类的问题），搜索巨子也还没有大规模集成和支配，以是更难的问题迟迟不见动静也就可以理解了。巨子有巨子的考虑，我们技能人是搞不懂的。本钱该当是一个考虑成分，知识图谱的实现和掩护本钱肯定比关键词索引高很多。乃至有群友也说了，为什么搜索要改进啊，如果不进一步跳跃性改进就已经有的赚，提高用户体验就没有急迫性。谁知道，大概还真是这么回事儿。
三、我们在How QA上做的事情
先发一张我和我差错的合影照片，他是一个公司的创始人，当年我俩一起把 How QA商业化，市场需求也是我的差错先提出来的。
图 1：李维与差错麦克合影
还有两个干系的帖子，是在隔壁的泥沙龙谈论搜索与NLP关系时整理的，一并放在这里做为背景和参考。一篇是《parsing是引擎的核武器，再论NLP与搜索》，详见博文：http://blog.sciencenet.cn/home.php?mod=space&uid=362400&do=blog&id=902849。
这篇文章的干系的内容有： 问答系统有两类。一类是针对可以预见的问题，事先做信息抽取，然后索引到库里去支持问答。这类问题的召回率很高，精度也高，但是没有实时检索的灵巧性和以不变应万变的效果。
另一类问答系统便是对通用搜索的直接延伸。利用关键词索引先过滤，把包罗来的干系网页，在线剖析，深度剖析后找到答案。这个路子技能上是可行的。应对所谓事实型问题（Who、Where、When类问题）是有效的。但是繁芜问题如how、why，还是要走第一类的路线。
为什么可行？由于我们的深度剖析是线性韶光繁芜度，在当代的硬件条件下根本不是问题。不管剖析有多深入、多风雅，比起干系接口之间的耽误，剖析实在是小头，因此在线剖析已经不是性能的瓶颈了。 总之，技能上可以做到立等可取。
另一方面，对付常见的问题，互联网在线问答系统的召回率根本就不是问题，这是由于网上的冗余信息太多。无论多不堪的召回率，也不是问题。比如，问2014年诺贝尔物理奖得主是谁。这类问题，网上有上百万个答案在。如果关键词过滤了一个子集，里面有几十万答案，少了一个量级，也没问题。假设在线剖析只召回个中的十分之一，又少了一个量级，那还有几万个实例，这足以知足统计的哀求，来坐实NLP得来的答案，可以填补精度上可能的偏差。
另一篇文章是《创新，失落败，再创新，再失落败，直至看上去没失落败》，详见李维的博文：http://blog.sciencenet.cn/home.php?mod=space&uid=362400&do=blog&id=902931。
这一篇条记与本日要讲的题目最干系，供应了详细的背景信息。
有些做出来很俊秀的系统，后来市场上没站住。现身说法，举近年来作者亲自经历的NLP产品化的例子。我们曾和Elsevier签了一个千万美元以上的条约，做一个天下上绝无仅有的，实质上能回答 How QA的问答系统。这个别系的市场起源是这样一种须要，科研职员和产品设计师们在创新的时候，须要查询文献，看古人都做过若何的事情，可以借鉴。设计哀求是，给定任一问题，例如，how to handle tooth decay，或规定任一功能，例如，how to increase bone density，哀求系统从文献中抽取挖掘所有的办理办法（solutions），分门别类呈现给用户。众所周知，How问题是问答系统中最难回答的问题之一，由于涉及的答案各式各样，比起when、where、who 这样的事实型问题难度大得多。可是，我们有基于深度剖析的信息抽取，较好地办理了这个难题。
系统交货往后，用的人喜好得不得了，反馈极佳。反正天下上没有一个机器可以回答这么广泛的 how 难题。无论是如何治疗疾病，还是如何泡妞，或者如何成为百万财主，只要你能想到的问题，我们的系统---- illumin8，都可以回答。给你这个天下上谈论过这个问题的所有答案，整合到一起，一览无余。而且是动态呈现，你可以对任何办理方案找到终极原始出处和高下文，你也可以进一步找这个方案的因果关系，看得失落利害。一下子成了科学家和产品设计师搜集古人事情的利器。Elsevier里面卖力这块的小团队来拜访我，也都夸这个别系做得好，互助是非常愉快的。结果 Elsevier在其环球用户的系统中用了五六年，去年闭幕了，条约没有续约。我作为设计者很感伤。
特定类型问题的问答系统可以算作是新一代的垂直搜索引擎，我们把它叫作 research tool。这么好的技能创新，补充的产品空缺，天下上没有第二家系统可以填补，至少目前如此。可是经历了六年还是归于失落败。Elsevier的环球用户都利用这个产品这么些年，但是创造还是无法拿它盈利。只管用的人还是喜好，也还是掐了。光技能好还是弗成,不熟习市场和商业模式，也还是去世路一条。
eHow的SEO有一阵在Google上做得铺天盖地的，但凡搜个How QA的查询，头一条便是eHow供应的结果，而他们便是雇了很多人，快速编纂各种How的小tip，不用自动的方法。那些 How QA在 Youtube上也红火得不得了，紧张集中在家用方面的 FAQ of How上。例如如何换机油、如何换轮胎之类。这种针对FAQ 做How QA是有道理的，可以赚得高点击，从而可以用广告费来制作很精良到位的内容以知足需求。但对付开放性的How QA，人工办法的FAQ，自然是弗成的。
四、到底什么是知识图谱
我给的标题是《知识图谱和问答系统》，这年头只要提到知识图谱就吸引眼球了。这是谷歌等“盗用”了学界的信息抽取（Information Extraction，IE）的观点而火起来的时髦词。谷歌把这个行业提到"大众年夜众台面了。过些年后，大家也不必再提啥 IE 了，都用知识图谱代替得了。真的便是一回事儿，不过谷歌嗓门大，又在搜索引擎里把 What和Who的问题给用知识图谱办理了。
过去吵去世了的观点，只能在业界。现在一换门面，大众知。信息抽取是个动词，说的是过程。知识图谱是这个动作的结果，存在库里。相称于我们以前的 IE Store，便是类似于关键词索引一样存取关系的库。知识图谱的名字与运用更近，更接地气。由于IE作为根本只是脱机处理，其结果才是联机去帮助回答问题的。
五、知识图谱和问答系统的关系
回到正题，知识图谱与问答系统。问答系统须要IE的支持，我们很多年前就极力主见，几篇 QA 的论文也是强调的这个。但这只对付预先定义好的问题有效，由于知识图谱是预先定义的关系。知道有什么问题，然后去针对性地抽取，这样一来是一打一个准。
但是，这并不是说问答系统只能利用知识图谱来做。事实上，开始的QA系统，都只有有限量的 IE 支持，一样平常都做了实体识别，但没有做图谱。其余，对付不能预先定义的问题，也没法用知识图谱来支持。那对付open-ended questions 怎么办？最好是用知识图谱的后备来支持。这个后备便是 parsing。
如果既没有花功夫建立知识图谱，又没有功力去做 parse trees，也还是可以做 QA 的。问答系统有构造化信息作支撑，质量确实可以提高不少。初期的 QA 都没有这两项，那便是用关键词+命名实体识别了。如果问题很长，关键词+命名实体对付事实型问题（When、Where、Who等）还是相称有效的。有构造与没有构培养不是一个档次，构培养是解析（SVO等）和知识图谱（关系和事宜）。
IBM的沃森该当是用了知识图谱+open ended的，作为一个实用系统，沃森该当是有针对性地做了一些知识图谱的事先功夫，来对付可以预测到的问题类型。利用关键词作为后备，利用某种 parsing 做中间支撑。在电脑历史上，沃森的造诣被认为是与下棋程序打败人类一样的标志性人工智能的大事宜。
但是，我的意见是它便是一个工程上的造诣，而不是科技的打破，由于实在那些问题的难度没有想象的那么大，绝大多数是事实型问题。机器比人脑影象力强太多了，而绝大多数的问题在大数据里面有太多的冗余答案了，只要有大数据+云打算，工程上上去了，打败人类是天经地义的。
沃森那个小组当年与我的小组同时参加QA的，我们互换过几次，当时的出发点都是用的 关键词+命名实体。
六、知识图谱必须是明确的任务
没有明确的任务，理论上是建不了知识图谱的，图谱的实质便是 预定义的关系。当然，如果你的运用层还不十分确定，但是大体有个方向，也是可能的。譬如，不管3721，先把某些实体之间常见的关系先做出来，存到库里去。然后想，迟早这些关系可以在运用层面用上。
How问题到底怎么定义的，回答成什么样算是过关了？How问题是问题类型中相称宽泛的一种，是开放性的，其基本形式便是：how+VP，例如：
how to do sth
how should we do sth
how did you do sth
这个 do sth 便是VP。HOW QA 的目的不是给出一个精确的答案，而是给出所有能找到的可能答案。大略的一句话能解答的how问题，可以通过句子骨架信息来实现。但是繁芜的就很犯难，比如“如何化解当前的中美之间的奇妙关系”之类的问题。
统计上故意义的答案的凑集，然后用户从中创造对自己有用的。目前的搜索引擎对付How QA没有好的应对办法，我们须要一个工具可以帮助探求各种可能的办理方案。
七、起源和动因
说到这里，先说一下我们研究知识图谱和问答系统的起源和动因。前面照片中的麦克是我们公司的创始人，便是他苦口婆心拉我入伙的。麦克伯在克利毕业后在 MIT 做 MBA，当时就有了这么个 idea：说现在大家讲创新，可是创新怎么能担保利用现存的最好的技能呢，除了自家的以外。这个观点叫 open innovation，目的便是不要重复发明车轮。他创造对付产品经理和科学家，还有专利状师，在浩如烟海中要找到古人已经办理了的问题，是一个非常困难的事儿，目前的搜索工具是不足给力的。
便是基于这么一个市场需求，他开始自己人为地搜集问题和答案，见了一个库。这个库包括了他手工搜集了几万的问题和几十万的答案。这是有市场调查的，知道这个是有需求的。到我加入往后，我说，你这个问题对我来说便是 IE 的问题，我给你自动做一个图谱就行了。通用的How QA不求唯一，不求准确，但求全，只要人提到过的办理方案尽可能一扫而空，以是我们叫它是 research tool。
只管长得跟搜索引擎差不多，实在征采出来的答案的大部分没有新意，是在发问者预见之中的，他根本就不要看。但是这样的系统的代价在于总有一些答案完备出乎预见，是他自己查资料险些不可能查到的。这时候，他就有兴趣去研究这些个没有想到过的结果，然后看对自己是不是有启示，或者是不是可以license过来用，这便是Open Innovation 的本义。
对付专利状师，这个需求也是有的。他须要担保他的专利没有任何条款有古人专利中提过的。按照这个思路做出来的How QA实际上是搜索引擎的直接的延伸，便是为了填补搜索引擎目前无法包罗尽可能多答案的毛病。
八、How QA的知识图谱设计
How QA给出的不是标准答案，只是在更细颗粒度上与办理方案干系的信息。我们这个别系后来是给 Elseviers 在它的环球用户中利用，紧张是支配在图书馆。这个是合理的，由于科技文献的办理方案比较靠谱，他们也须要突出他们的文献，网上包罗来的答案作为补充。
若何为 how 问题设计知识图谱呢？第一步，缩小知识图谱的范围。我们的研究创造，在我们给定的这个运用处景下，How后面的 VP 实际上是一个利益条款，我们的焦点也不必涵盖所有的 VP。由于险些措辞中每一个句子都有一个 VP，这样下来我们吃不消，也没必要。
常日来说，都是说的办理方案可以办理什么问题，一样平常是“正面”的办理方案，对那些负面的办理方案，例如：how to kill John、how to cheat SAT等。不过这些都是在我们常日的运用处景可以忽略的。我们把 VP 缩小了，但是包括了一些中性的动词，但打消了负面的动词。虽然理论上它是存在的，但对付科学家用户和产品经理设计产品这样的场景，贬义的 VP 可以扔掉。
再一个创造是，这类条款中，最常涌现的类型是SOLVE+PROBLEM这样的 VP，而个中的SOLVE 可以是 solve, resolve, get rid of等。这个很主要，由于绝大多数的how 问题是要办理问题的。如果创造这个问题已经明确了，那么就可以跳过 SOLVE 的各种形式，直接供应办理方案。这一点对付知识图谱的设计，以及对付系统的接口都故意义。
第三，观点设计。系统许可两个接口，一个查询是问题，譬如心脏病，另一个便是How VP，这是查询接口。知识图谱内部的设计紧张是预定抽取的模板，抓取相应信息。首先是办理方案的槽：Solution1、Solution2。常日一个句子里最多有两个这样的规则，譬如：
这是我瞎造的句子，意思是说VP前的主语可能是办理方案，PP+ing 也是办理方案。便是从语句的表述中，看到像是办理方案的，就抽取出来，然后在供应给用户前，做一个 分类。Procesure 常日用的是动词by doing sth，则算另一种办理方案。专家是第三种， 譬如心脏科大夫的名字。所有供应的答案只是给用户一个可能的办理方案的择要，并且包罗来的办理方案可以分门别类给用户看。
由于所有供应的答案只是给你一个办理方案的择要，用户对哪一点感兴趣了，可以 drill down，知识图谱的实质之一便是许可顺藤摸瓜。我们的图谱里面包括4个roles：
Solution1 、Solution2、Problem、Benefit。当然，实际上我们做的比这个更细，包括 Beneficiary 等role。有了这四个roles，一个基于知识图谱的支持How QA的系统就可以建造了。当然它不是为了How QA的所有场景，而是为了帮助创新者在最短的韶光里包罗古人的事情。
主体设计大概便是这样了，然后便是力气活。不过这力气活由于有了靠谱的解析器也不是难事儿。在详细的运用处景中都是由利用者剖断答案的代价，用户怎么用是他的事儿，反正我们给用户供应了一张联结图，由用户自己决定哪个情报对他有用。能精确提取句子基本骨架SVO，并且能达到一定规模，可以覆盖很大的问题量，虽然处理过程有些“机器”，但是收益还是不错的。不知道对否？
how to become a millionaire，最先的答案便是 lottery；如果你问 depression 的办理方案，上帝是前几条，还有 family，还有吸毒之类，很多答案都是common sense。但是代价不在这里，代价在肯定有你一辈子也想不到乃至常规方法搜不到的答案涌现，这便是用户所须要的灵感。
为什么须要用知识图谱回答问题？由于How QA的办理方案的表达办法太多样了，没法直接用 SVO 支持问答系统。例如，即便在深度剖析已经逻辑化的模式根本上，我们须要至少500条规则来涵盖这些模式。换句话说，如果我用 SVO 来得到相同的质量，我就须要把 500 个 SVO 用 OR 连接起来。作为对 SVO parse tree 的库的查询，来搜索答案显然是不现实的。并行也弗成，在对付一个知识库做 query 的时候，不仅仅是并行的问题，还要考虑给 query 的人，怎么可能写出那个 query。
设计两个 Solutions的缘故原由是由于我们设计图谱模式时创造一个句子内常日最多有两个部分：主语entity和by doing sth。到了内部，这两个 solutions 可以观点上对等，只是分类的不同。例如：NP solves this problem by doing this，也可以说Doing this solves the problem。500 个 patterns 让任何人去写都是不可能的，而这 500 个 patterns 作为知识图谱的开拓结果则是可行的。由于开拓职员是程序猿，知道系统内部，不断的测试和debug，末了完成开拓任务。变成 query 往后便是 online 的了，不可能代替知识图谱的全体开拓过程。
不过对付有些问题，SVO 足矣，不必用借助图谱，你假如想问“微软2015年并购了哪些公司”，这个问题便是不须要图谱的，可以直接在 SVO上操作。由于这个问题的 patterns 非常有限，Subject= Miacrosoft, Verb= acquire | purchase| buy，Time=2015，Object=?上面这个 query pattern 就足够了。这种 SVO search 非常有效。
总体上讲，这个技能不是火箭一样的高精尖技能，但是 只要 scale up，他所供应的代价，这是目前的系统不能供应的，而且是 open domain 的，适应性广，基本上便是搜索引擎的自然延伸，可惜它去世了。
