|
在讨论知识图谱和问答系统之前，先给出几篇以前的文章。第一篇文章是《立委科普：问答系统的前生今世》，以前也发过，再发一下。详见博文：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商业化，市场需求也是我的搭档先提出来的。
图 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 这样的事实型问题难度大得多。可是，我们有基于深度分析的信息抽取，较好地解决了这个难题。 特定类型问题的问答系统可以看成是新一代的垂直搜索引擎，我们把它叫作 research tool。这么好的技术创新，填补的产品空白，世界上没有第二家系统可以弥补，至少目前如此。可是经历了六年还是归于失败。Elsevier的全球用户都使用这个产品这么些年，但是发现还是无法拿它盈利。尽管用的人还是喜欢，也还是掐了。光技术好还是不行,不熟悉市场和商业模式，也还是死路一条。
我给的标题是《知识图谱和问答系统》，这年头只要提到知识图谱就吸引眼球了。这是谷歌等“盗用”了学界的信息抽取（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给出的不是标准答案，只是在更细颗粒度上与解决方案相关的信息。我们这个系统后来是给 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 的，适应性广，基本上就是搜索引擎的自然延伸，可惜它死了。 QA 的主要难点一个是How QA，一个是Why QA，都被立委（作者自称）啃掉了，虽然只是一个子集。那个 What QA和Who QA我也在谷歌前做过，而且现在谷歌就是靠这个扬名了知识图谱的，就不值一提了。其他的事实型问题更是小菜一碟了。 大体说把，500 个 SVO patterns，基本涵盖了语言学中解决方案的各种表达。如果没有 SVO，从底层算 pattern 数量，大体是两个数量级。也就是说我涵盖了50000个线性模式的解决方案的表达法。而个体的How QA作为QA的难题留下来给后人研究吧。对于实际开放域测试，好像也很少有漏掉的，当然不敢说绝对。不过面对大数据的话，信息有冗余，基本不用太担心召回率。我们做了 500 模式已经有点“overdone”了，属于完美主义者的毛病，真正管用的模式也不过几十条，后面的 patterns 都是为了长尾。 Elsevier花了几千万用我们这个系统，用了五六年后，去年终止了合同。虽然从他们的客户得来的反馈非常好，但这个系统没法让Elsevier赚钱，他们的客户多是教授科学家之类，是小众，不是有钱人。蛮丧气的，眼看自己做的技术一个个灰飞烟灭。心里其实明白，它是有用的，目前不可替代的。 对结果的排序我们基本是按照频率来的，这个不一定是合理的，因为信息量为零的常识容易飘在上面。 |
|
|
