博文
《新智元笔记：知识图谱和问答系统：how-question QA（2）》
|||
我:好，开讲。
龚: 准备了。精彩即将呈现。
我: 首先谢谢各位来捧场，希望讲完后，不至于太失望。
龚:下面欢迎李维老师给我们带来分享，时间交给李老师。
我: 给的标题是《知识图谱和问答系统》，这年头只要提到知识图谱就吸引眼球了。这是谷歌等“盗用”了学界的信息抽取（IE）的概念而火起来的时髦词。
雷: @wei 报个到。不是盗用，是谷歌把这个行业提到公众台面了。
龚: 李老师把握主线，大家随意沟通，我给整理的。
我: 尽管提问，各位老师同学。本意就是为了交流和碰撞。
过些年后，大家也不必再提啥 IE 了，都用知识图谱代替得了。真地就是一回事儿，不过谷歌嗓门大，又在搜索引擎里把 what和who的问题给用知识图谱解决了。
雷: 过去吵死了的概念，只能在业界。现在一换门面，大众知。
我: 是。信息抽取是个动词，说的是过程。知识图谱是这个动作的结果，存在库里。相当于我们以前说的 IE Store，就是类似于 keyword index 一样的存取关系的库。知识图谱这名字与应用更近，更接地气。因为IE作为基础只是 offline processing，其结果才是 online 取来去帮助回答问题的。
雷: 想知道知识图谱与RDF之间的关系。知识图谱用得好！
我: 回到正题，知识图谱与问答系统。问答系统需要IE的支持，我们15年前就极力主张，当时的几篇 QA 论文也是强调的这个。但这只对于预先定义好的问题有效，因为知识图谱是预先定义好的关系。知道有什么问题类型，然后去针对性地抽取相应的答案，这样一来应该是一打一个准。
Zhou: 立委讲的好。
我: 但是，这并不是说问答系统只能利用知识图谱来做。事实上，开始的QA系统，都只有有限量的 IE 支持（一般都做了 NE tagging，但没有做图谱）。其次，对于不能预先定义的问题，也没法用知识图谱来支持。那么 open-ended questions 怎么办？最好是用知识图谱的后备（backoff）来支持。这个后备就是 parsing。如果既没有花功夫建立知识图谱，又没有功力去做 parsing，也还是可以做 QA 的，初期的 QA 都没有这两项，那就是用关键词+NE了，TREC-QA 开始大多如此。如果问题很长，关键词+NE 对于 factoid 问题（时间 地点 等）不仅鲁棒，而且还是相当有效的。
wang: 问答系统有结构化信息作支撑，质量确实可以提高不少
我: 当然正如@wang 所说，有了结构与没有结构不是一个档次。结构就是 parse （SVO等） 或知识图谱（关系和事件）。
sujian: 请问李老师，沃森是依赖知识图谱了吗？对QA不了解
我: 沃森应该是用了知识图谱+open ended 的策略的。
荀: 李老师讲的好！
雷: @wei 适当贴一些例子最好
我: 好，到进入 how 的讲解之后，会以例子来讲解。现在先形而上，看一下 high level 的关系是怎样的。
作为一个实用系统，沃森应该是有针对性地做了一些知识图谱的事先功夫，来对付可以预测到的问题类型。
昊: 沃森不是单独用知识图谱
我: 当然不会单靠知识图谱，那样的话系统就失去了鲁棒性。它应该是利用关键词作为最终的后备，利用某种 parsing 做中间支撑。这个是自然的、可以想见的。在电脑历史上，沃森的成就被认为是与下棋程序打败人类一样的标志性人工智能大事件。但是，我的看法是它就是一个工程上的成就，而不是科技的突破，因为其实那些问题的难度没有想象的那么大。
Zhou: 基于document接jeopady不难
我: 不错，绝大多数 factoid 问题，只要有大数据+云计算，工程上上去了，打败人类是理所当然的，因为机器比人脑记忆力强太多了，更因为绝大多数的问题在大数据里面有太多冗余答案了。沃森那个小组当年与我的小组同时参加QA的，我们交流过几次，当时的起点都是用的 NE+ keywords。我们还做了一点 parsing。
Zhou: 传统trecqa解决沃森就很好
雷: @wei 对，是工程上的
我: @周明 对，传统的 trecqa 可以应对大多数沃森所面对的问题。
sujian: 知识图谱的构建和应用任务一般独立吗？很多公司要建知识图谱，好像开始并没有明确的任务。@wei 我对Ｑａ和知识图谱都不太了解。之前接触一些公司，号称建知识图谱，但并没有一个明确任务，不知道这样构建知识图谱的模式好不好？
我: 没有明确的任务，理论上是建不了图谱的，图谱的本质就是 predefined 的关系。当然，如果你的应用层还不十分确定，但是大体有个方向，也是可能的。譬如，不管3721，先把某些entity之间常见的关系先做出来，存到库里去，然后想，迟早这些关系可以在应用层面用上。
我: 好，我们还是聚焦 HOW。
白: how问题到底怎么定义的，回答成什么样算是过关了？比如，谁谁是怎么爱上谁谁的。
sujian: 李老师，您先讲吧。
我: how 问题是问题类型中相当宽泛的一种，open domain，它的基本形式就是：how+VP （how to do sth）。
how should we do sth
how did you do sth
这个 do sth 就是VP
白: 这有点差异了，对个别事件和通用做法
我: 从大数据来讲，不论个别与通用
白: 比如，前苏联是怎么垮台的
我: HOW QA 的目的不是给出一个正确的答案，而是给出所有能找到的说法，统计上有意义的答案的集合。然后是问问题的人从中发现对自己有用的。
白: 这可能有问题。比如出国，有几十种出法，张三出国，只用了其中一种，问的人也只想知道一种。这种场景，说多了反而是错的。一个国家垮台，也有好多种垮法。
wang: 我觉得简单的一句话能解答的how问题，可以通过句子骨架信息来实现。但是复杂的就很犯难，比如”如何化解当前的中美之间的微妙关系？"之类
我: 抽象地谈，可以说这些差别。具体的business 应用场景的要求是，目前的搜索引擎对于how 类的 questions 没有好的应对，我们需要一个工具可以帮助寻找各种可能的解决方案。
白: 那还是面向通用。但具体的对象，具体的事件，难道就不是需求了？我们可不是在讨论理论问题。
我: 说到这里，先说一下这里所讲的 HOW 系统（产品名叫：illumin8，2008年发布上线，这是产品介绍的youTube，国内需要翻墙：https://youtu.be/jx9ULRi1AN4）的起源和动因。
照片中麦克是我们公司的创始人，就是他苦口婆心拉我入伙上贼船的，后来成为铁哥们儿。我挺感谢他的，是他给我一个平台，我要求不高，只要有个台就可以唱戏，这些年来合作得很愉快默契。麦克有市场敏感性，伯克利电脑后在 MIT 做 MBA，当学生时就有了这么个 idea，说现在大家讲创新，可是创新怎么能保证利用现存的最好的技术呢，除了自家的以外。这个概念叫 open innovation，目的是不要 re-invent wheels。他发现对于产品经理和科学家，还有专利律师，在浩如烟海中要找到前人已经解决了的问题，是一件非常困难的事儿，目前的搜索工具不给力。就是基于这么一个市场需求，他开始自己人为地搜集问题和答案，建了一个库做可行性测试。印象是手工搜集了几万个问题和几十万的答案。他是有市场调查的，知道这个是有需求的，弥补了搜索引擎的不足。到我加入以后，我说，你这个问题对我来说就是 IE 支持 QA 的问题。我给你自动做一个图谱就行了。
wang: 李老师先是从基本的how问题处理说开去，现在搜索引擎方面确实还差点，不然“小冰”，“小娜”什么就不会成为关注点
白: 可能先要定义什么是 how 问题。看来李老师定义的比我预期的窄。
我: 就是通用的 how qa，不求唯一 ，不求准确，但求 comprehensive。只要人提到过的解决方案，尽可能一网打尽。所以我们叫它是 research tool， 尽管长得跟 search engine 差不多。
白: 对一个具体的对象，和一个具体的事件，问how问题，回答多了是错的。而且也不一定是解决方案，只是一个细粒度描述。
我: @白，说的很对，的确不是标准答案，只是细颗粒度的与解决方案相关的信息。不过，今天我们还是放下 how qa 的这一面，看看作为搜索引擎延伸的一网打尽式的 how 系统该是怎么回事儿。
白: 好的
我: 其实搜寻出来的答案的大部分没有新意，是在发问者预料之中的，他根本就不要看。但是这样的系统的价值在于，总有一些答案完全出乎预料，是他自己查资料几乎不可能查到的。这时候，他就有兴趣去研究这些个没有想到过的结果，然后看对自己是不是有启发，或者是不是可以 license 过来用，这就是 open innovation 的本义。对于专利律师，这个需求也是有的，他需要为他 claim 的专利的每一个 statement 负责，保证没有与 prior art 的冲突。所以说，照这个思路做出来的 how qa 实际上是搜索引擎的直接的延伸，就是为了弥补搜索引擎目前无法搜罗尽可能多答案的缺陷。
Zhou: 你不考虑搜Yahoo answer。只考虑在网页或者document搜答案吧。
我: Yahoo answers 我印象是包括在我们网络数据源的。我们这个系统后来是给全球最大的科技出版商 Elsevier 在它的全球用户中使用，主要是部署在图书馆。他们要求在我们的 Internet archive 的图谱之上，把他们自己的科技文献作为优先。这个是合理的，因为科技文献的解决方案比较靠谱，他们也需要突出他们的文献，网上搜罗来的答案作为补充。
怎样为 how 问题设计知识图谱呢？我们的研究发现，在我们给定的这个 business 用场，how 后面的 VP 实际上是一个 benefit statement, 就是说，我们的焦点不必涵盖所有的 VP，因为几乎语言中每一个句子都有一个 VP，这样下来我们吃不消，也没必要。
白: benefit也包括整死一个人，如何下毒又不留痕迹，诸如此类。
我: 通常来说，都是说的解决方案可以解决什么问题。都是功能性描述或“好话”，譬如 increase bone density 这样的。
当然，白老师说的也对，也可以有相反的，譬如
how to kill John
how to cheat on SAT
我们把 VP 缩小了，包括了中性的动词，但排除了贬义的动词，虽然理论上它是存在的，但对于科学家用户和产品经理设计产品这样的场景，贬义的 VP 可以扔掉。
白: 粗俗但有利的呢？比如在竞争语境下说“抢”“挖”“逼”之类。
我: 粗俗还好，我们没有那么严。如果是 murder 这类就排除出局了，一般的动词还是涵盖了。这是第一步，缩小知识图谱的范围。再一个发现是，这类 statement 中，最常出现的类型是SOLVE+PROBLEM 这样的 VP pattern，SOLVE 可以是 solve, resolve, treat, handle, get rid of, etc.
这个很重要，因为绝大多数的how 问题是要解决问题的。如果发现“问题”已经明确了，那么就可以跳过 SOLVE 的各种形式，直接提供解决方案。这一点对于知识图谱的设计，以及对于系统的接口都有意义。
wang: 在想是否有些否定+贬义词情况被丢弃？比如“xx 并没有损害 xx”。
我: 没有丢弃，损害的否定式是作为 benefit statement 抽取的。如，某新产品不会造成污染。
这些是概念设计。系统允许两个接口，一个query是问题 ，譬如，心脏病。另一个就是 （how） VP。这是query接口。
知识图谱内部的设计主要是预定抽取的 template，就是要抓取哪些信息来回答how类的问题。
D: 譬如：心脏病，这个query没看懂，是要说明什么呢？您能解释一下吗
我: 就是说 how to treat 心脏病 的意思。
D: 明白, 您继续。
我: 首先是解决方案的槽：Solution1，Solution2。通常一个句子里最多有两个这样的 roles。譬如：Aspirin can relieve the pain of headache by making people sleep. 这是我瞎造的句子，意思是说, VP 前的主语 Aspirin 可能是解决方案，PP+ing （by making people sleep）也是解决方案。
白: 解决方案里面有什么？允许分支？循环？条件判断？还是只允许顺序执行？比如，怎么做拔丝地瓜。菜谱本身要有内部的条件判断？
我: 没那么复杂，也没那么多推理。
白: 还是说，对solution，就像个普通网页一样，里面爱啥啥，不做结构化整理？
我: 就是从语句的表述中，看到像是解决方案的，就抽取出来。然后在提供给用户前，做一个 classification，药品等 entity 算一类，procedure 通常用的是动词（by doing sth）算另一种，专家是第三种， 譬如心脏科大夫的名字，等等。使得搜罗来的解决方案可以分门别类给用户看
白: 那我要按菜谱自动做菜，怕是没戏了。solution只是信息，不是知识。就是说下边没有grounding
我: 菜谱做菜还是有戏的，因为所有提供的答案只是给你一个 summary，你对哪一点感兴趣了，可以 drill down，菜谱就被顺藤摸瓜出来了。
白: 那就涉及solution的内部构造了
我: 知识图谱的本质之一就是允许顺藤摸瓜。
白: 这用户还是人，我们希望用户是机器。
我: 一个静态的页面不能反映这个功能。每个答案都是一个链接。
好，我们的图谱里面有了两个解决方案的 roles，第三个 role 叫 Problem，第四个 role 叫 Benefit。有了这四个 roles （我们实际上做的比这个细，还包括 Beneficiary 等，但这要详细讲起来，就长了，简略一点反正不影响主旨），一个用知识图谱支持how qa 的系统就可以建造了。当然它不是为了how问答的所有场景，而是为了帮助创新者在最短的时间里搜罗前人的工作。主体设计大概就是这样了，然后就是力气活。不过这力气活因为有了靠谱的parser 也不是难事儿。
白: 如果被搜的文档恰好是科幻呢？怎么自动确定这是“前人的工作”？或者说，如果我在网上放一些伪solution，这个系统当然也会照单全收的。
我: 白老师那些问题，在应用场景都是由使用者判定的。他怎么用是他的事儿，反正我给他提供了一张联络图。他可以任意地研究决定哪个情报对他有用，多数挖掘出来的情报是没用的，要忽略舍弃的。
不错，所有的伪答案也照单全收。所以如果你问 depression 的解决方案，上帝在前几条里。还有 family，还有 吸毒之类。当我问机器：how to become a millionaire？最先的答案就是 lottery。
白: make sense
wang: 我觉得能（正确）提取句子基本骨架SVO，并且能达到一定规模，可以覆盖很大的问题量，虽然处理过程有些“机械”，但是收益还是不错的。不知道对否？
我: 很多答案都是 common sense，但是价值不在这里，价值在肯定有你一辈子也想不到甚至常规方法搜不到的答案出现。这就是用户所需要的灵感，用知识图谱回答问题。
白: 为啥两个solution?
我: 两个 Solutions 是设计图谱 template 时候，为了方便而行，因为语言中，一个句子内通常最多有两个，一个是主语 entity，一个是 by doing sth 这类：如，某某止疼药是通过麻痹神经达到止疼功效。到了内部，这两个 solutions 可以概念上对等，只是分类的不同。
NP solves this problem by doing this.
you can also say：
Doing this solves the problem
We solve this problem using NP
等等。
比起多数抽取任务，how 的解决方案的表达模式太多样了。如果问题的答案不多样，那么就可以直接用 SVO 支持问答系统，而不必用知识图谱做功夫。大体说来，在 deep parsing 的已经逻辑化的pattern基础上，我们需要有几百条规则来涵盖这些 patterns。换句话说，如果我用 SVO 来得到相同的质量，我就需要把几百个 SVO 用 OR 连接起来，作为对 SVO parse tree 的库的query，来搜索答案，这显然是不现实的。
白: 可以并行做。弥漫式联想。
我: 并行也不行。在对于一个知识库做 query 的时候，不仅仅是并行搜索的问题，还要考虑给 query 的人，怎么可能写出那个 query。上百个 patterns 让任何人去写都是几乎不可能的。而这几百个 patterns 作为知识图谱的开发结果则是完全可行的。因为开发人员是程序“猿"，知道系统内部的结构支持和如何协调平衡条件，最后完成开发任务。变成 query 以后就是 online 的了，不可能代替知识图谱的整个开发过程。
白: 为啥要人写呢，这是很好的用机器学习的场景。
我: 白老师这是蛮典型的拿着ML的锤子找钉子，总想抢我们语言学家的饭碗，呵呵。凭什么相信机器学习能比我们一辈子研究语言的语言学家做得好呢，且不说机器学习所要求的大量带标数据的知识瓶颈。在这些结构patterns就可以搞定的任务上，机器学习不可能赢过我。倒是我自己编写开发的规则系统偶尔倒还有这个可能。物化的我（机器）凭借长期的受教和积累可能打败他的创造者，因为后者有打瞌睡和一时反应不过来的时候。
不过对于有些问题，SVO 足矣，不必借助图谱。譬如，你要是想问，微软2015年并购了哪些公司。这个问题就可以不需要图谱的，可以直接在 SVO上操作。因为这个问题的 patterns 非常有限，下述 query 就大体搞定：
Subject=Microsoft
Verb=acquire|purchase|buy
Time=2015
Object=?
这种 SVO search 非常有效。不过 how 不行, patterns 复杂得多。
大体就是这些了。
wang: 李老师，辛苦了！
我: 这个技术不是雕虫小技，当然也不是火箭技术，但是只要 scale up，他所提供的价值，是目前的系统不能提供的，而且是 open domain 的，适应性广，基本上就是搜索引擎的自然延伸。
可惜它死了。虽然我知道它有一天会在搜索巨头里面复活。
白: 很精彩，基本就是，不看广告看疗效，这样才能撒大网。用疗效卡位，solution爱谁谁。
我: 白老师这个总结十分地到位！
wang: 想问一下，您认为当前QA还有哪些难点？
我：QA 的主要难点都被立委啃掉了，虽然也许每个难点只是解决了其中一个子集，一个场景（use scenario）。
QA难点一个是 how，一个是 why，那个 what和who 我也在谷歌之前好几年深入做过，但是现在谷歌就是靠这个扬名了知识图谱的，就不提了（历史足迹在此：
《知识图谱的先行：从 Julian Hill 说起 》）。其他的 factoid 问题是小菜。
《知识图谱的先行：从 Julian Hill 说起 》）。其他的 factoid 问题是小菜。白: solution里面的动词，不是坑的提供者，而是坑的消费者
我: 对。VP 作为 solution，的确是是填写坑的，而 VP 作为query，是为了与作为坑的VP做matching而用的。
wang: 我觉得李老师讲得通俗易通，我们能理解怎样的思路，可是每种类型pattern 的比例，它们怎样的存在，我们外人就无从所知了，呵呵
白: 回过头来，个体的how，还是没有解决啊。
我: 个体的 how 作为 QA 的难题留下来吧。
大体说吧，几百个 SVO patterns，基本涵盖了语言学中解决方案的各种表达。如果没有 SVO，从底层算 patterns 数量，毛估估是两个数量级。也就是说我涵盖了几万个 linear patterns （拿 ngrams 做近似物）的解决方案表达法。
wang: 实际开放域测试，不知覆盖怎样的问题比例？
我: 好像很少有漏掉的。当然不敢说绝对。不过，面对大数据的话，信息有冗余。不用太 worry 了。
我们做了几百个 patterns 已经有点 overdone 了，属于完美主义者的毛病。
wang: 恩，大数据，信息海洋的确帮了不少忙
我: 真正管用的 patterns 不过几十条。后面的 patterns 都是为了长尾，不做意犹未尽，做吧越来越进入 corner cases。
白: 伟哥说它死了，how so？
我: Elsevier 花了几千万用我们这个系统，用了五六年后，去年终止了合同。他们还是没法赚钱，虽然从他们的客户得来的反馈，好话都说尽了。他们的客户多是教授科学家之类，是小众，不是有钱人。
wang: 那这些候选答案项，是否要rank ？是按怎样权重计算呢？还是自然罗列？
我: 各种好话都听到过，喜欢的人喜欢得不得了。因为目前没有其他工具可以代替。
我: ranking 基本是按照频率，这个不一定是合理的，因为信息量为零的常识类的答案容易飘在上面。
wang: 通过这个学术用户的试水，我相信肯定会有其他更广阔的市场的，李老师加油！
我: 谢谢大家。我前面有另一篇笔记 ( 泥沙龙笔记：创新，失败，再创新，再失败，直至看上去没失败)，里面提到了这个技术在医用场景的 prototype。那个是很有前途的，可惜我们没有作为方向去发展为产品。用了很短的时间就完成了 domain 化，做出的 demo 美得让人窒息 。。。 呵呵。蛮丧气的，眼看自己做的技术一个个灰飞烟灭。心里其实明白，它是有独特 value 的，目前工具不可替代的，只是那个特定的市场切入点或时间点不足以让它赚钱。
泥沙龙笔记：创新，失败，再创新，再失败，直至看上去没失败)，里面提到了这个技术在医用场景的 prototype。那个是很有前途的，可惜我们没有作为方向去发展为产品。用了很短的时间就完成了 domain 化，做出的 demo 美得让人窒息 。。。 呵呵。蛮丧气的，眼看自己做的技术一个个灰飞烟灭。心里其实明白，它是有独特 value 的，目前工具不可替代的，只是那个特定的市场切入点或时间点不足以让它赚钱。wang: 也可以学学沃森，据说它也走进了医疗领域。相信李老师的能力！还会有更好的作品的。
我: 转一个刚刚看到的马云在互联网大会上的发言：“这是一个摧毁你，却与你无关的时代；这是一个跨界打劫你，你却无力反击的时代；这是一个你醒来太慢，干脆就不用醒来的时代；这是一个不是对手比你强，而是你根本连对手是谁都不知道的时代。在这个大跨界的时代，告诫你唯有不断学习，才能立于不败之地！ 今天你還很贫穷，是因为你怀疑一切；如果你什么都不敢尝试，你将永远一事无成，机会总是留给有准备的人。”
白: 我关注三个未解决的问题，这里总结一下：一、个体的how；二、solution的结构化表示和grouning；三、面对上百个贡献因子，不用罗列的方式而用学习的方式建立具体动词和solution、和problem之间的微观连接。上万个也是可能的。
我: 白老师的问题第二个没看明白。
白: 就是下载了菜谱，跟智能厨房连在一起，直接炒菜。
我: 哦
白: solution内部有控制流，条件判断，分支循环什么的
我: 那是具体 domain 的 understanding 了
白: solution 的原子动词，在一个受限的领域里，解释为智能硬件的动作。也可以是软件，比如在一个纯数字的世界里。
wang: 白老师，是否“如何把这篇稿子改成社论？”--“改”字。用一系列，过程性知识进行处理
白: 嗯，这就是变相的指令了。又是个体how，又是纯数字世界
wang: 我觉得李老师像是外科处理，白老师通过外科想看内科
我: 我就是杀猪匠。老友说的，外科大夫的起源就是杀猪匠
wang: 呵呵，但是“有效”，落地啊。
白: 抓需求抓的给力
我: 需求还是产品经理的事儿。这个项目是麦克定义的，我就是根据他定义的需求去往 NLP 上靠，把它自动化了。内部的设计就是那个知识图谱的模板。剩下的开发循的就是所有规则系统走的coding 的路子。一个 dev corpus，然后 develop 和 test，不断循环。
wang: 大多用户都是看外科，内科出力说不清楚（稍微耽误一下效率，或不理想，用户就不待见）。
白: 内科也有内科的商业模式。至于说是IE还是understanding，其实说是IE也无妨。以Siri为例，grounding到数字对象的，和grounding到网页的，并不打架。
wang: 当然，进一步往深做好，还是需要多内功，也是飞跃的必须。李老师，这也是天然NLP处理的应用，自动化，也可以走得更远，做得更大。
我: 这种项目是 tractable 的。几百条规则，听上去很肉工，机器学习者会觉得理应去学。可是写惯了语言学程序的人觉得很好玩，没有大到受不了。不大不小，做完了很有成就感。我的看法，这些 tractable 的语言现象，机器敌不过有经验的语言学家，深度学习也不行。值得注意的是，有了 SVO 以后，绝大多数的知识图谱的任务都是非常 tractable 的。how 算是复杂的多样的。多数图谱工作不过 100 条以内的规则开发量就搞定了。有不少图谱抽取的任务，只要几十条就可以穷尽语言表达了。有了 deep parsing，知识图谱真地不是一个难题。
白: 难不难，这取决于需求，需求可能导致必须内科解决。
wang: 同意，需求激发的难度升级
我: 难的是产品定位和对知识图谱的需求的确定。我说的是开发并不难（SVO就好比当年的数理化，仗着它走遍天下都不怕）。难的是没有足够多好素质的 product designers，他们了解客户需求，可以清晰地提出要求，requirements specs。我说过，最牛的永远不是技术本身，最牛的是知道把牛技术用到市场的人。懂市场和客户，能设计产品或带来 revenue 的牛人，比技术人更难找到。这是我自己的切身感受。
雷晓军: @wei pattern与ontology的关系？
我: ontology 的问题，目前就是类似 HowNet 那一套的上层。我们在 SVO patterns 的节点中用它来为了扩展 pattern 的涵盖面和 fine-tune 规则的质量。没有用到专业的 ontology，因为这是 open domain的系统。但是后来我们做 medical domain 的 how 系统的时候，医用ontology起到了很大的作用。
雷: @wei pattern多了不就可以形成ontology了？
我: patterns 本身无所谓 ontology。几百条，你怎么组织都可以掌控。他们之间的关系就是用蛮力和intuition也可以调整好，无需叠床架屋在上面加一层逻辑关系。其实多数 patterns 是个性的长尾，根本就不怎么参与纠缠。真正要调控的不过几十条。
QA 应用有两大类，完全不同的场景，一类是搜索的自然延伸，另一类是Siri这样的人机界面。后一类有 grounding 的问题，而且后一类几乎都是局限于狭窄领域，或者app specific 的，grounding 也就不太难，因为那边需要的 action 选项是非常有限的。
白: 说不定，一个商业模式，恰恰需要both。逼着你结合，而不是简单取舍。
我：好，各位晚安。吃早饭去了。
wang: 谢谢李老师！好胃口！各位晚安！
白: 龚博，好好整理啊
Jixhu: 谢谢李老师！期待纪要。
【相关】
《新智元笔记：知识图谱和问答系统：开题（1）》 2015-12-21
泥沙龙笔记：parsing 是引擎的核武器，再论NLP与搜索
泥沙龙笔记：从 sparse data 再论parsing乃是NLP应用的核武器
Elsevier Upgrades illumin8, Enhancing Access to Critical Information...
产品介绍youTube（要翻墙）：https://www.youtube.com/watch?v=jx9ULRi1AN4
About illumin8
illumin8 is a web-based research tool that enables more confident product and partnering decisions at the front-end of innovation. Beyond just search results, illumin8 leverages semantic search technology to uncover hidden insights and relationships between technologies, organizations, products, and scientific approaches. It indexes a content base of 40 million+ scientific records from Elsevier and 5,000+ publishers, 24 million+ patents from 5 patent offices worldwide, and billions of web pages that include 1,000+ online business, technical and news sources.
学术发表：Srihari, R., Li, W., Li, X. 2006. Question Answering Supported by Multiple Levels of Information Extraction. a book chapter in T. Strzalkowski & S. Harabagiu (eds.), Advances in Open- Domain Question Answering. Springer, 2006.
https://blog.sciencenet.cn/blog-362400-945003.html
上一篇：核能发展的核心问题
下一篇：《泥沙龙笔记：知识习得对本体知识，信息抽取对知识图谱》
