| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
jopen
10年前发布

关于知识管理和语义搜索的一些思考

知识管理的坑

做知识管理最容易陷进去的坑就是满足1%用户的要求

做知识管理最容易陷进去的另一个坑就是满足99%用户的要求

知识库的构造中,当目标是满足全人类的需要,就没办法满足(几乎)任何人的需要。Wikidata, freebase, dbpedia和yago都有这个问题。

wikidata至少做对了一件事:不用RDF

众包是一个建设文本百科的好办法,但是对于建设结构化数据就没有成功的先例,因为世界观的冲突很难用结构化表示融合。详见我的《The Unbearable Lightness of Wiking》http://www.slideshare.net/baojie_iowa/2010-0522-smwcon

知识库和文本不同,它的长尾需求特别大,人们通常会关心各种小领域的entity。大部分这些entity是没有机会进入主流的知识库的。这里有认识的原因,有经济学的原因。比如ConceptNet和Freebase,他们允许众包编辑,但是真正来编辑的人是极少的。大部分领域的概念都非常稀疏。

年轻人喜欢大数据,成年人只看数据清理

做知识,做语义,很容易犯的错误,是把实验室成果外推,认为能应用到大几个数量级的数据上。而在实践中,一个人用的东西和十个人用的截然不同,1G数据的分析和1T数据的分析截然不同,不是上Hadoop就能解决的。这里面有太多人的因素,人是没法Hadoop化的。

反之亦然,在大市场、大数据上有效的算法,在小市场、小数据上效果反而不好。创业公司就不能眼睛盯着大公司,觉得他们怎么做我们就follow,只要把规模缩小了就可以了。可是大象的骨骼结构小老鼠是不能按比例缩小的。

自由…不是无代价的

人工智能问题说到底是一个经济学问题,不(仅)是算法问题

在知识工程里,“领域”往往被看作一个本体(ie 概念的正确分类的形而上的)问题。但其实领域应该是一个渠道问题,一个经济学问题。领域的大小是随着知识销售者的实力而变化的,和领域的真实大小不必然有关系。

在我看来,Knowledge Graph的核心既不是Knowledge,也不是Graph,而是自由。自由是降低成本的方式。但是众包并不是自由——对于知识库而言,众包恰恰是反自由,自古以来就没有成功的例子。允许多种观点在不同的范围内共存,这才是知识图谱能普及的根本——但是这违背大公司的利益。

例如 Google的Knowledge Graph和Schema.org,代表的是Google自己的世界观(比如命名,组织,范畴),它的目的是服务Google自己的商业利益。这也就决定了它们在用于其他人的利益范畴时,会非常的别扭。这个问题是和它的渠道紧密结合的,自由会损害它的商业利益

Web的成功,一个基础就是允许人们各行其是,尽可能降低事先约定的必要,尽可能允许多种不同的组织方式、数据形式、基础系统能共存。对于Web而言,URI是实现这种自由的基础。于是语义网界(含关联数据)外推把URI也做为结构化数据表现的基础,经历十多年的失败,现在看应该是错了。

URI当年是自由的支柱,但是现在它反而阻碍了自由。作为一种寻址方式,它代表了自由。但是作为一种*命名*方式(也就是知识组织的底层基础),它则代表了一种特殊的世界观——这种世界观和大多数人的世界观抵触。这就极大提高了成本。

知识表现中的成本,并不是说建一个模型的成本,或者机器跑一个模型的成本。最大的成本是人与人之间的成本。争吵(大到各种会议和工作组,小到邮件列表)、困惑、官僚主义(项目扩大以应项目扩大之需),而这一切的根源都在于以不恰当的方式过早优化普适性,从而导致世界观的冲突。

真理从来不是越辩越明的。在世界观的冲突中,再多的辩论也无法改变人们本身的思维方式,更不用说利益本身。所以知识结构不应该被集体设计出来——事实上,参与设计的人越多,这个知识结构越正确,于是就越没有用。反而是偏见最后能落到实处。

Unified Ontology of Everything = Unified Ontology of Nonsense 好比是把佛教、基督教、伊斯兰教混合在一起搞一个宗教

数据的语义,应该尽可能的局部化。过于照顾数据多样的应用中的语义解释,会极大提高数据发布者的发布成本,因为这就需要精确的指定语义(比如说用URI命名)。而事实上,真正产生价值的应用的数量是很少的。在1-1而非n-n的语境下语义的解释成本就会大大的下降。降低这个成本就是知识管理的一个核心任务

从社会学上说,参与事务的个体越多,分歧就会越大。把消灭分歧的任务交给发布者是不合适的,等于发布者成为整个理解系统的中心,从经济学上不可持续。应该通过局部化事务,去中心化。这就需要各种代理的出现。

把语义数据称为ontology,这已经在哲学上假设这些结构化数据是在描述本体。人们已经对本体争论了两千年,可能要再争论两千年。而工程中的数据的语义,则是主观的而非客观的描述。所以语义是一个唯心的认识论问题,而非本体论问题

因此,如果从认识论的角度设计语义系统,就可以把复杂的本体论语义转化为可解耦的认识论语义,从而在不同的域中允许不同的解释存在。这就保证了语义解释的自由,这一web发布最核心的价值。

市场的的经验教训

今日去检查John Breslin和Nova Spivack的公司StreamGlider到底怎么样了,才发现连网站都没了,准确地说被黑了。公司似乎还在,全球排名已经可以忽略不计 http://t.cn/Rw5zGbM 推ter 只有113个粉丝。作为当年号称要挑战Flipboard的公司,汇集诸多明星,为什么会只走出这点距离?

这是Streamglider当年刚推出时的新闻 http://t.cn/zOZzYeS Breslin是我们语义网界的风云人物,DERI的大牛。但是很显然,Streamglider和Bottlenose, Twine一样没有抓住用户的需求。

DERI出来的另一个创业项目,seevl.fm http://t.cn/Rw5Zhb6 ,试图在音乐领域做推荐,当年还发了很多文章,也已经基本上死掉了。单纯从知识的角度,不管是语义网也好,知识图谱也好,都不能解决用户真正关心的问题。去进攻一个准备不足的市场,这个市场本身的规模再大也和你无关,因为没人会用。

Bottlenose先后融资了6.6M。前两天他们刚刚从KMG Capital Partners B轮。但是如果他们不改变经营战略,再砸钱也没用

几乎所有的“语义”引擎在遇到消费者市场问题后就撤退了,去搞企业市场。可是这样的公司几乎过两年也都死掉了。在我看来,他们的问题不是消费者vs企业市场,而是他们(至少我接触的那几家)太过从技术的角度,而不是真正从“消费者”的角度去思考问题。把客户从个人换成企业也无助于解决问题。

几乎所的这些公司,都是明星CEO+明星技术团队+明星顾问+明星投资公司。在用户以前,他们就已经有各种C这个O,C那个O,一个漂亮的董事会。他们有各种天顶星技术。但是就是不愿意做小事。小事不需要明星。所以他们都死了。

在我看来,他们从消费者市场转进企业市场,只是一种逃避。他们不试图去解决成本、成本、成本这个知识管理最核心的问题——因为他们本身就是成本,他们没法解决掉自己。语义和知识,如果不能lean startup,那就注定无解。创始人越是明星,开始拿的投资越多,就越更接近于失败。

Sig.ma已经下线了了。sindice.com全球排名一直在40万上下,再也上不去。如今商业化的通用语义搜索十分的不景气。

在不景气名单上的还有kngine 已经加入阵亡或被收编名单的:Hakia, Kosmix, Evri, Powerset, Truevert。唯一和语义有点关系还干的不错的是DuckDuckGo

和 Hakia和Powerset的人都聊过。对这两个语义搜索先驱的失败,我的感觉还是他们想做的事情太大,超越了时代。比如Powerset为了搞语义,先发明了HBase,但是语义分析速度实在是太慢。被微软收购后,很长一段时间里Powerset其实是被抛弃了,没法满足微软要求的规模。还是要 Lean Startup

Hakia和Powerset都是以自然语言理解为核心,想从关键字搜索进步到自然语言搜索。这个路径至少在2006年是超前的。今天是不是还是超前,我不敢定言。但是任何会激发用户图灵测试欲望的界面设计,都是不妥的。

专有领域的一些语义搜索(一般它们都不这么叫自己),比如Yummly和Factual,活得都不错。所以现在的技术和市场条件,还是不太合适通用语义搜索的存在。现在的机器学习技术,做通用知识的自动挖掘还远远没能离开实验室阶段,拿它来做创业太冒险了。

我的信箱里还有好多“Twine Digest”,其实和我们现在做的机器学习日报、大数据日报也差不多。Twine的经验教训,时时刻刻都都在提醒我们。

如果Twine当时更专注一些,比如专门做书签,或者只做推送,或者专门在一个话题上深挖,会不会更好些呢?至少,它的数据量会少很多,对后端的压力就不会那么大,也就不至于需要分一半的工程力量去搞大数据基础设施,就能更关注于业务本身。当然历史是不容假设的。

来自:http://baojie.org/blog/2015/03/04/on-knowledge-management/

 本文由用户 jopen 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1425520178103.html
知识管理