科学网

 找回密码
  注册
科学网 标签 SVO

tag 标签: SVO

相关帖子

版块 作者 回复/查看 最后发表

没有相关内容

相关日志

【科普小品:伟哥的关键词故事】
liwei999 2016-1-27 02:25
讲个伟哥的故事。 当年在水牛城的时候,我们开始开发信息抽取挖掘(如今叫知识图谱)的产品,名叫 Brand Dashboard,就是从在线新闻和论坛等专门收集品牌的全方位信息。这个产品生不逢时,超出时代了,因为那时社交媒体还没诞生,网络舆情和品牌情报还处于 BBS 和论坛新闻的时代。即便如此,大企业客户的market 还是有的,我们的顾客之一就是这个伟哥的厂商,大名鼎鼎的 Pfizer。 当时为了这个产品,我领导开发了一个品牌和术语的消歧模块,其中用到的排歧条件包括利用句法关系如SVO的限制,backoff 到 keywords。关键词条件就是所谓共现关系,可以根据距离进一步区分为在同一个句子,同一个段落,或者同一篇文章。所以这个排歧的 backoff model 实际上就是: SVO -- keywords within S -- keywords within P -- keywords within D SVO 不用说,条件最严苛,一旦 match 了,歧义自然七窍生烟被打趴下了,非常精准,但覆盖面常常不够。这关键词怎么用呢?需要给新人讲解为什么关键词共现也可以排歧。于是,顺手牵羊,就用了这么个案例:说 ED 是两个字母的缩写,歧义得很,查查缩略语词典,可以找出一长列可能的词义来,包括不举。但是,哪怕是 backoff 到 Document level,这个排歧也是有效的,因为有的时候,词与词之间有很强的 semantic coherance(其实关键词技术横行NLP领域多年,其诀窍就在于此)。具体说来,ED 的同一篇文章中如果出现了关键词 Viagra 或 Pfizer,它就死定了,绝不会有其他的解释。这时候,句法结构就不必要了(而且句法也不能跨句,更不用说跨越段落去影响了)。俗话说,戏不够,词来凑,这戏就是结构:如果 SVO 太窄或太不全,recall 不够,那就用词的共现来凑呗。懂得这个原理,NLP就入门了。 话说这个讲解还真有效,甚至实习生也一听就明白,原来语法结构与关键词共现还有这样的后备关系啊。 伟哥故事完。 【相关】 【 立委科普:NLP 中的一袋子词是什么 】 《 立委科普:关键词革命 》 《 立委科普:关键词外传 》 《朝华午拾:创业之路》 《朝华午拾 - 水牛风云》 【置顶:立委科学网博客NLP博文一览(定期更新版)】
个人分类: 立委科普|4420 次阅读|0 个评论
《新智元笔记:知识图谱和问答系统:how-question QA(2)》
liwei999 2015-12-22 04:32
我:好,开讲。 龚: 准备了。 精彩即将呈现。 我: 首先谢谢各位来捧场,希望讲完后,不至于太失望。 龚: 下面欢迎李维老师给我们带来分享, 时间交给李老师。 我: 给的标题是《知识图谱和问答系统》,这年头只要提到知识图谱就吸引眼球了。这是谷歌等“盗用”了学界的信息抽取(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 我对Qa和知识图谱都不太了解。之前接触一些公司,号称建知识图谱,但并没有一个明确任务,不知道这样构建知识图谱的模式好不好? 我: 没有明确的任务,理论上是建不了图谱的,图谱的本质就是 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 问题是小菜。 白: 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 的,目前工具不可替代的,只是那个特定的市场切入点或时间点不足以让它赚钱。 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 【 立委科普:问答系统的前生今世 】 【立委科普:从产业角度说说NLP这个行当】 《 泥沙龙笔记:搜索和知识图谱的话题 》 泥沙龙笔记:创新,失败,再创新,再失败,直至看上去没失败 【创业故事:技术的力量和技术公司的命运】 泥沙龙笔记:parsing 是引擎的核武器,再论NLP与搜索 泥沙龙笔记:从 sparse data 再论parsing乃是NLP应用的核武器 【立委科普:信息抽取】 【置顶:立委科学网博客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. Click to edit publication title 学术发表: 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.
个人分类: 立委科普|8973 次阅读|0 个评论
《泥沙龙笔记:再聊关键词和SVO》
热度 1 liwei999 2015-10-22 02:16
白: (关于SVO取代关键词)要我是广告商,这种变化不值得去搞。要搞就搞大的。 增加的定价复杂性和收益不一定匹配。 如果这种变化导致广告商不给钱了,搜索公司不会干。 不是说技术进步点在句法,广告标的的表现也一定在句法。 配套一系列东西,计量等等,都要动。包括博弈,在博弈中定价, 本来是清晰的,regex一来,糊涂了,SVO也一样问题。 我: 不过,从广告商的终极目标来看,这些问题都是技术层面的问题, 总是可以想到办法来规约双方的,前提是,加入了 regex 或更进一步 加入了 SVO,广告的精准投放可以获得大幅度提升。现在我想要鼓吹的就是,后者的条件已经成熟,越来越成熟, 精准投放不是梦。关键词对于传统广告,实现了针对客户的初级阶段的精准投放, 引起了互联网产业的革命。现在谈的是高级阶段的精准投放,也有一场革命。 白: 不见得,标的的属性和商业模式的匹配与否, 直接决定标的能否被采纳。胆子忒小了,步子也忒小了。太老实了呗。技术进步到句法, 标的就在句法里找。这就叫老实。 我: 这里有一个 backward compatibility 类似的考量。基本上说,新的模式应该是这样的 , 这是一个 backoff 模型: SVO backoff 到 regex; regex backoff 到 keywords 。 对于拥抱创新的广告商,让他尝到 SVO 高级阶段精准投放的甜头。等到这个甜头被广泛谈论以后, 整个产业就会整体上从关键词模式上升到SVO模式。 即便整体模式转变了,也不妨碍人们继续使用关键词, 但那个时候的关键词使用是在具体的场景下进行的。这就好比我们说话通常都是合法的相对完整的句子, 因为这是我们的语言能力决定的,但是这不妨碍我们在特定情形下, 躶体出境,说不太合法的话,譬如在社交媒体,譬如在打电报, 譬如尼克和冰在一起的时候。这些时候,SVO 不是必须的。 其实 SVO 根本不像人们想象的那样高深,它是相当 intuitive 的,不过是 who did what 这样的事件描述。如果说教育全民学 SVO 可能是一个艰巨的任务,对于广告商、对于搜索供应商、对于 Power users,这个 SVO 一点也不难。它比学会用 regex 容易,比 SQL 更是简单多了。 白: 兼容有另一种处理办法。首先要确定,广告商和广告所宣传的产品供应商不是重合的, 而且跨度可以很大,对不对?加上SVO, 标的数量即使没有关键词的立方级,至少也有平方级,对不对? 我的不同意见恰恰就在这里,广告代理越综合, 标的选择越不宜细粒度,细粒度的事儿,交给技术上去做。 精准投放和标的的粒度是两回事,可以解耦。 当标的规模出现量级的变化时,这种脱钩尤为显得重要。 我说的是,商业标的的粒度变粗、同时技术标的的粒度变细, 才对广告商有吸引力,否则他们会宁要关键词模式。 比如理发店,最终是想向客户推销某种储值卡, 但是客户可能更关注哪个发型师给你服务。因此, 推销卡的任务摊派给发型师好了,这就是粗粒度。 发型师再来细粒度因人而异。见什么人说什么话,理发师全管了, 但是包销多少卡,不需要用户级别的个性化。 关键词模式有一点是错的, 就是用户的粘性和他们使用的关键词有关。 regex和SOV要想继续这个错误,肯定走不远。 要想纠正这个错误,可参考理发店模式。有粘性才有广告, 精准投放是技术手段但不是产生粘性的必要条件。更精准, 不一定更有粘性。不管是谁,粒度一定很粗。性价比不会很高。 我: 先搞清白老师的问题。明确一下, 我和白老师现在谈的是关键词作为广告标的和广告入口这个模式的利弊, 以及可能不可能革命这个模式。 白老师提出了很有意思的疑问:细颗粒度的 SVO 不适合做广告的标的: 还是关键词合适。原因之一前面说过,就是关键词直观,少扯皮。 这一点我的回应是,确实有这个问题,但这是技术层面的, 终究可以解决扯皮和定量的问题,如果让“标的”与“入口”分离,并且找到它们合适接口的话。 对于广告商,终极目的不会变,他就是要精准投放,看到广告的 1000 个潜在客户,是100个真地感兴趣开始点击了,还是 200 个, 转换率就会不同, 这都是精准投放的硬指标,都是可以定量测量的。 咱们后退一步,我的问题是:广告商想表达的意思,关键词能不能表达?如果有难以表达的情形, 那就是现有关键词模式的局限。 而突破这种局限的唯一办法是给关键词增加新的维度,譬如 regex 或者 SVO 等关系。 还是举个容易说明的例子吧,如果一家 VC 想给自己做广告,其中一个场景就是,如果客户搜寻公司购并, 或者客户点击的网页谈的是公司购并, 那么我觉得那才是我应该显示广告的好地方。 这样一个广告的精准投放需求,关键词怎么表达? 现在的办法就是出卖两个关键词,或者一个合成词:公司购并。 这个效果差太远了,因为谈论公司购并或者搜寻公司购并的, 里面恰好提到这两个词的,是少数。 多数的情形都是,张三购并了李四、苹果要吃掉特斯拉之类,这个没有 SVO 怎么玩得转? 白: 咱们设想啊,假如一个发型师是冰冰,另一个是圆圆, 还有一个是娜娜,大家都有类似的精准程度……这时候粘性靠啥? 1000个变成1000000个, 广告商的工作量就大1000倍。 我: 性价比不高,确实可能是一个问题。这个层面的问题也是现存的关键词模式的问题。 白: 对,但是你的标的规模平方级放大的时候,问题也随之放大。 所以性价比不得不考虑。 具体地说, 是专业广告代理向智能搜索平台定制自己认可的人机交互虚拟代言人 。 数据是同一批数据,SVO是同一批SVO, 但是虚拟代言人决定粘性竞争力。 丁: 这里限定了广告投放的两个具体场景: 搜索公司的针对用户的搜索行为,出发点是“search string, 用户寻求内容,寻求解决方案 ,内容平台网站针对用户网页浏览行为,出发点是”page/ site content, 用户浏览特定领域内容“ , 理发师更类似于后一种(广告商直接投放垂直领域网站) 洪: @wei deep parsing用于广告投放好倒是好, 但可能对用户隐私是一种深度侵犯。 我: 不会吧,任何svo 都是抓取某类事件,而不是针对特定用户。如果特定用户的行为描述match了投放的 svo,那也是公共信息,抓到的不是某一位,而是一大批符合条件的人。换个角度 同样的信息关键词也可能抓到,只是抓得不够准而已。 举个例子,譬如, 如果某个广告想投放给并购了其他公司的那些大公司,那么这个 SVO 广告投放大概就是: V:购并|购买|买|吃 O: 注意谓语V的坑里面是枚举的关键词(SVO框架里称为驱动词),OR 的关系。 而宾语的坑则不同,它里面不是关键词,而是词的 feature or tag,这就克服了关键词没有概括性的缺点。 这里彰显了关键词的两大局限:(1)不能抽象概括, 只能用直接量;(2)不能规定语法关系。 这样的VO就抓住了一批做S的公司,如:微软,IBM,Facebook,。 。。, 这里面不涉及啥隐私,因为这些并购消息都是公开发布的。 洪: 在mail或用户文档中按keyword投广告, 只是scan文本,keyword spotting,除了一些敏感领域,隐私不是问题。 但parsing involved,理解分析让人担心隐私泄露。 regex matching,谷歌/百度的sponsed search应该已经在用。 我: boolean query 之所以在某些服务商和一些power users 可以无限复杂化,就是为了弥补简单关键词的这两个不足而生的, 可这不是 “人活儿”,而且毕竟是关键词框架内利用与或非而来, 因此捉襟见肘,比起SVO表达力还是远远不够,无法应对远距离的挑战。是没办法的办法。 因此,backoff 实际上是这样: simple query -- boolean query -- regex query -- SVO SVO,特别是VO,具有普适性,几乎可以涵盖一切事件,因为事件最自然的语言表达就是主谓宾,VO往往是定义一个事件的必 要条件,而主语在语言学上属于 external arg,是可以省略或隐藏的(譬如在被动语态或不定式短语中)。 动宾定义事件的例子很多,再给一些例示如下: 1. 撤销 ... 职务 (裁员事件 ) 2. 丢 ... 工作 (失业事件) 3 修理 ... (电器修理事件) 4. 发布 ... (产品发布事件 ) 5. 伤 ... (譬如车祸、事故等) 等等。 【相关】 泥沙龙小品:关键词必须革命,没商量的 2015-10-20 《立委科普:关键词革新》 2015-10-17 《立委科普:关键词外传》 2015-10-12 《泥沙龙笔记:铿锵众人行,parsing 可以颠覆关键词吗?》 2015-10-10 【置顶:立委科学网博客NLP博文一览(定期更新版)】
个人分类: 立委科普|3782 次阅读|0 个评论
泥沙龙小品:关键词必须革命,没商量的
liwei999 2015-10-20 09:13
独: (腾讯收购京东)真的假的? 我: 靠,这几天老出惊天新闻,刚报说苹果天价购买特斯拉,如今又是腾讯收购京东,准备与阿里一决雌雄。稍早前还有 EMC 明珠暗投,被个七零八落的 Dell 收购了。后天会不会出个新闻,惠普收购了推特,或者推特收购了惠普?企业世界真疯狂啊。 毛: 我自岿然不动(因为动不了)。 我: 还是要动,不能坐以待毙。 我大概属于一根筋的人,这两天一直觉得一件事儿没完。 终于按照原来的思路,把姐妹篇完成: 《 立委科普:关键词革命 》, 请方家鼓掌,指正就不必了。 毛: 我慢慢看。 白: 哈,那天讨论,伟哥的思路被我们七嘴八舌冲得很凌乱。 我: 是啊,一下子就给你绕到模式里面去了,乱了心性。 其实我的思路是一贯的,根子就是关键词表达力不够,它没有资格作为信息载体的唯一代表。这一点是如此清晰无误:信息载体的一维不符合语言和逻辑的本性。必须革命,没商量的。其他一切都是枝节。 毛: 他们那帮人都是捣乱分子,有娜姐在场就不能让他们这些人出来。我是不捣乱的,我只是看捣乱。 我: 白老师说的经过深思熟虑,不是捣乱,不过他只从一个角度和一个支点谈。即便作为卖钱的计量单位的关键词暂时不会或无需革新,也不影响广告商的接口那头还是需要革新才能满足精准投放(可以测量的!)的总目标。二者之间一定有某种办法协调。除这一点尚需进一步商榷外,我文中的论点完全经得起历史的检验。关键词捉襟见肘,怎么可能永远占据信息处理的霸主地位。革命潮流浩浩荡荡:关键词要凤凰涅槃,SVO 必大放光芒。 【相关】 《立委科普:关键词外传》 2015-10-12 《立委科普:关键词革命》 2015-10-17 【置顶:立委科学网博客NLP博文一览(定期更新版)】
个人分类: 立委科普|2786 次阅读|0 个评论

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-6-17 05:21

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部