（整理自鲍捷20161026于将门的报告）
（未经作者审阅，一些听写错误没有纠正。请勿转发）
事先请大家原谅，今天这个分享会比较干，所以我在思考前面加了哲学两个字。我以前做语义，现在做知识图谱,今天分享的这些东西是基于这十几年实践中的很多失败经验。这其中有一些经验、教训反反复复的出现，我就在思考如何避免这些问题。所以今天这个分享的目标听众实际上是架构师，也许现在这些抽象的东西还不能够很容易去理解，不过我希望大家以后再回过头来看的话，可能会对整个系统的架构设计有一些指导意义。
先简单介绍一下我自己，我2001年去的爱荷华州立大学Iowa State University，在那里拿的博士。我在博士期间做的工作主要是描述逻辑、推理和语义网，毕业之后去了伦斯勒理工学院 (RPI)做博士后，在那里面继续语义网的研究，主攻知识工程还有本体论语言，在那期间我参加了W3C OWL工作组，参加了OWL语言的标准制定工作。之后去了MIT和BBN做访问研究，在那里研究了金融本体和语义信息论，2011年到2013年在三星美国研发中心做它的问答系统SVoice，还有自然语言处理的工作。2013年之后开始创业，头两年在美国，我们成立了公司叫Memect，到2015年9月份的时候，我们搬回到北京来，继续做知识图谱的各种应用，最近一年在做金融数据的分析。
我从事知识图谱相关工作有15年的时间了，跟人工智能相关的工作有18年的时间，从1998年读硕士那时候开始。这里面列举了一部分我的项目经历，其中超过一半的项目最后应该可以称为不成功的，所以这一些分享，其实是基于这些项目实体的。在这之前我们6月份的时候，曾经组织过一次北京知识图谱的学习小组，所以今天讨论的一部分内容，也是跟这个知识图谱学习小组以前的教学大纲是有关的，大家可以去看一看。
还有一部分内容是来自于我以前的个人的一个博客叫语义噪声（http://baojie.org/blog），也感谢耿新鹏前一段时间帮我整理的，他把我所有的和语义网相关的工作，都放到了Github上面去，做了一本电子书，大家可以下载下来看，大概有300多页。还有另外一个资源，就是我三年前把我一些想法组织在一起叫做Lean Semantic Web，也是一个大纲。当时是想写一本书，但是没有写完，这里面列举了我认为对语义网(现在叫知识图谱)相关的一些核心领域的范畴，还有一些参考书，可能对大家会有一些用处。本文的主要是基于我以前的几篇博客，都列在这里面，一些我今天可能没有办法很深入的讲的东西，在这些博客文章里都有。
我相信大家经常会听到“知识图谱”这个词，特别是在2012年谷歌推出知识图谱之后。以前大家用各种马甲的说法，像什么关联数据，语义网，大家现在都改成了一个马甲，叫知识图谱。那实际上大家从媒体里听到的，从大公司宣传的，和我们每天日常工作中真正用到的知识图谱，并不是一样的东西，所以大家可以说现在知识图谱已经逐渐大数据化，就变成一个市场营销的名词。很多公司都在说自己的知识图谱，实际上干的东西肯定是完全不一样的。
我认为知识图谱技术现在并不是一个单一技术的名字。它是一堆技术，或者说是很多个技术经过几十年的发展，到今天汇总在一起变成一个应用的研究领域，我们把它统称为知识图谱。总的来说可以分为四个领域，首先就是知识提取，在国内大家可能会对这个领域比较熟悉，因为我们国内知识图谱的研究小组，在中文信息协会下面有一个语言与知识计算专委会，知识图谱的几次会议都是由这个专委会来举办的。因为中文信息协会是自然语言处理的一个研究组织，所以我们会遇到很多自然语言处理方向上的专家，那么大家会听到各种关系提取、实体提取，分布式表示等各种方法。但是在知识图谱的应用当中，并不仅仅是知识提取这一个领域，就是说我们怎么从非结构化数据里提取结构化数据，在我们提取了结构化数据，我们还有很多后续的处理步骤，比如说知识表现，就是传统的我们在逻辑和语义网这个领域里面，大家关注的那个。知识表现就是通过知识提取或者人工编辑之后，我拿到了一堆结构化的数据，这些结构化通常是用图来表示的，那么我怎么能有效的把这些图给合并在一起。
此外还有一个推理任务，推理是什么呢？还是我现在有一堆图，那图上有了一些边(edge)，边又称为关系，节点又称为实体，那么我已经有了一些边之后，我如何去推导新的边，这个过程就称为推理的过程，如何高效的进行推理，是知识表现完成的核心工作。
另外一块就是我们的数据有大量的不同来源，比如说我们做金融，那么有数据是从股转中心来的，有从证监会来的，那么也会从Wikipedia上来的。如何把代表多种不同意志的数据集成在一起，这也是知识表现关心的事情。
再下面一步就是知识储存，我们有了一堆图的数据，如何在数据库上面进行有效的储存和查询呢。通常是用一些新型的数据库来做的，比如图数据库，像 neo4j, stardog。其实还有一些非经典的，或者非传统的处理方法，比如说用关系数据库来做，还有人用键值数据库或者 redis 来做，根据不同工程的需要，这都是有可能的。
最后一步就是知识检索，知识检索最经典的。大家肯定听说过叫语义搜索，就是Semantic Search。在谷歌、百度和搜狗他们都有过很多这种研究，也有很多应用的领域。比如在出门问问，他们就有一个出行领域的检索，现在他们把它做到手表上，像我们主要在金融领域里面做这种知识的检索。再有一块跟它相关的就是人机交互，这也是算是知识检索的一部分。信息检索更多叫Search，这个人机交互更多的是探索，所以一个是搜索引擎，一个是探索引擎，这两块都是知识检索的内容。
今天可能无法深入的讲解每一个领域，在上个月的时候，在CCKS就是中国知识图谱大会上面，我做过一个一小时的分享，更加深入就这四个领域做了一些探讨，大家感兴趣的话，可以看看那个slides，大概有200页。今天更主要的是讲一些这种哲学或者架构问题，后面分三个问题来讲。
首先讲的是一个小数据问题。“年轻人喜欢大数据，成年人只看数据清理。”
这什么意思呢？大家看到了现在“大数据”变成一个营销名词，尽管大家没有办法去理解其他的事情。有一次我遇到了一个人，他问我你在干什么？我说我在做知识图谱，他说听不懂，然后我说我在做信息提取，他也听不懂，最后我说我在做大数据，他就听懂了，所以大数据这个词现在基本上变成计算机科学的代名词了，但实际上我们在工程当中的时候，我们真正关心的问题，并不在于是不是大数据，我们不管是做知识工程也好，还是做机器学习好，最核心的问题在于数据清洗，如何提高数据的质量。
我想跟大家讨论一个问题，就是我们在微博上面，在各种新闻上面，能看到这些大公司比如说谷歌，他们在说他们也在做知识图谱，这两年有很多其他的公司在跟进，他们也推出了很多的图引擎或者各种知识库。我们要特别小心的事情，就是他们是大象。对于我们大多数的知识图谱的实践者而言，比如像我这样的初创公司，或者是在学校里面的一些项目的话，实际上我们是老鼠，我们非常非常的小，那么老鼠和大象之间有一个很大的scalability的问题，就是大象的技术没办法用给老鼠，老鼠的技术没办法用给大象，这是特别容易犯的一个错误。
对于我们在学校里面做的事情，比如说我在博士期间，我们做了很多事情，我一个人做的很好。我自己曾经做了一个知识编辑系统，我想让大家来用，但这个实验室里大概有15个人，这15个人就没办法用，因为在工程里面，它有一个一般的规律，Jeff Dean 说的：任何一个工程系统，如果它的数据量增加十倍的时候，它一定会出错，如果它增大100倍的时候，一定会需要重构。所以我们做知识或者做语义的时候，在实验室里有一些成果，然后我们想把它做到工程里面去，通常就会失败。因为一个人用的东西和十个人用的东西完全不一样的，每大一个数量级，不管是数据还是软件都必须重新设计。反之亦然，当你有一个很大的系统的时候，他工作的很好，比如说像谷歌的系统，你想把它缩小其实也是很难的事情，大工程的数据、它的成本、它计算的成本，它的人的成本，实际上都是没有办法同比例缩小到小公司来的，这个小公司的架构一定是跟大公司不一样的，所以大象的这个结构，比如说它的腿的比例和身子的比例，跟老虎肯定是不一样的，所以我们这些创业者和学校里面的研究人员，我们不能够去追谷歌或者脸书，我们不能去看他的算法是什么样，我们要根据自己的实际情况去解决自己的问题，用最低的成本，尽可能小的数据的规模和机器的规模，尽可能的去利用先验知识，尽可能的去缩短投入产出的周期。其实在这个上面，我们是有优势的，因为很多大公司，他们没有办法去处理小问题，他们的优势也就是他们的劣势。对于谷歌这样的公司，一千万的市场规模对他们来说是一个很小的市场，那对于我们来说是一个很大的市场，也就意味着有大量的市场空白，大公司其实是没有办法去做，而丢给我们这样的老鼠。
怎么颠覆大象呢？其实今天前面整个 section，都是在讲怎么颠覆大象，所以我刚才也提到了，公司大有大的难处，现实市场中其实大多数的问题，并不会有谷歌面临的这么大。因为这里有一个所谓的典型的“创新者的窘境”，大家很多人可能听说过这个词，就是说当大公司已经很成功的时候，他很难去缩小他的规模，去降低他的利润率，去到一个新的市场上去。其实谷歌在做这个知识图谱的时候，他已经做了很多年，从2004年、2005年的时候他就开始语义网，但是一直都是失败，后来到了2010年的时候，他自己内部没有办法解决这个问题，他就买了一个公司Freebase，那后来又消化了两年时间，到了2012年的时候，他才推出了这个知识图谱。也就是说很多问题大有大的难处，小有小的难处。大公司的优点之一，他是数据比较多，因为他数据多，他可以去浪费，他可以一千个人去在很大的一个数据集上面进行搜集和整理。只要数据好，什么烂方法，什么烂系统，都能work，但是数据是非常非常贵的。在这里有一个概念叫数据奴隶主, 什么意思呢？就是像谷歌、脸书包括国内的一些大公司，实际上他们是一个奴隶主的地位，很多人在免费用他们的产品，因为他们的产品非常好，所以现在免费的给他们提供数据。那对于小公司而言，实际上没有办法得到这么样的数据的，那么技术选型的时候，我们必须考虑到这个成本问题，就是大公司它能够低成本获得这个资源，小公司那肯定做不了。
制约技术选型的核心问题，不在于技术酷不酷，而在于全周期的投入成本和维护成本。这个是很多人会忽略掉的问题，因为我之前在CCKS还有之前的中国语义网会议的时候，我看到了一些大的机构，大家提出了技术选型，都非常的炫酷。但是我可以说大部分这样的设计，一般会失败，因为整个技术它全周期的投入成本是没办法降下来的，像这样知识型的系统，它一定是从小到大的慢慢的成长起来的，而且它核心问题并不在于机器的成本，不像我们在研究一个搜索系统的时候，或者研究一个机器学习的时候，我们更多的是看这个机器跑的快不快，比如说深度学习，我们关心的是这个速度问题，而对于知识系统，最关键的问题是人力问题。因为最主要的知识是人的力量，机器是没有知识的，所以历史上深度学习它能够去革新神经网络，是他提出了一套相对于传统的神经网络，降低成本的方法。但是他用在像我们这样的知识系统里面的时候，其实它的这种维护成本并不低，所以在这之前我听到很多声音就在说知识图谱现在面临的问题，是不是深度学习都可以解决的，我觉得这个答案是很值得商榷的，深度学习不太可能是个万能药。在知识图谱，包括之前知识工程的这个领域，发展了十几年时间，有很多起起伏伏。里面一些核心的问题，并不是机器的速度提高了，或者说一些机器学习的算法的速度提高了就能够解决的，更多的还是“人”的问题，这个“人”的问题下面我提到了两点，还有更多的地方。
一个是系统，一个是数据。那么系统就是说我们在构造一个整体的知识表现，知识存储，知识检索在系统里面的时候，知识在这里面流动，它要提高可解释性，可读性，可维护性，可进化性。可解释性就是说这里面的一些东西，大家看的懂，普通人看的懂。可读性也是，比如说之前我们有XML的那种语法，后来大家都不喜欢那种，改成了 Turtle、 JSON等，其实整个语法的改进都是在提高这种系统的可读性。我们写代码的时候，知道可读性是非常关键的，实际上在写知识系统的时候也是一样，知识只不过是一个特殊的代码而已，所以可读性非常的重要。
后面两点大家如果从软件工程角度可以很容易理解，可维护性和可进化性。因为知识系统本质上来说也就是个软件系统，所以需要维护和进化。从数据上讲，一个是自描述性，多能性，还有一个结构化和非结构化数据的混合型。自描述性就是说一个数据点，它要有对这个数据的解释，就像一个字典一样，一个字典一个词条，然后每一个词条都有一个解释，这就叫自描述性。多能性和混合性，我后面会讲到。这里最重要的这个核心叫着眼于Value（价值），降低成本，所以着眼于价值这一件事情是所谓的知识图谱，或者小数据和大数据最大的区别所在，后面会用四个 slides来详细解释。
颠覆大象的方法，我在这里提四点，一个是迭代，一个是观察，一个是处理长尾，一个是小数据。小数据这件事情，我会多说几句。我先说迭代，知识图谱开发的核心问题是迭代问题，在这之后两个sections，其实都是在围绕着这个迭代来讲，特别是最后一个，讲产业界观察的时候，就是说我们从小到大的来解决问题。一般来说线上的系统，在开发的时候，会经过三个步骤就统计、规则和编辑。统计方法就是粗粗的过一遍，其实在群里有很多好东西传送门的群友，好东西传送门的架构就是这么设计。第一步数据进来以后先统计，我们是用一个topic model的方法，之后就要靠规则，因为统计只能保底，大部分真正有价值的数据，是靠人来形成的，就是有多少人工就有多少资本。所以人形成了规则，或者人在统计的基础上，统计形成一些初步的规则，然后人再进行深入规则的编辑。规则是可重复的人工投资，但还有一些不可重复的人工投资，就只能靠第三步, 就是编辑。我们在知识图谱开发的时候，就是要不断的去迭代，迭代的核心就是提高可重复的人工投资的比例，并反馈到统计系统里面去。那我们现在进行这种投资分析也是一样的，也会有统计, 规则，编辑的三个步骤，那么核心点就是把每一步的结果，都能够往前推，把编辑的结果放到规则里面去，然后再把规则的东西放到统计里面去。
我们用炼钢做一个比喻，统计相当于选矿，提供了一些简单的原材料，规则相当于拿了原材料来炼铁，这个铁勉勉强强可以用，但是强度不高的，然后编辑相当于炼钢，相当于锻打，让这个材料变成了可以被用到系统里面的零部件，所以我们用很多种方法来加强炼铁和锻打的效率，但这不仅仅是用选矿就能够替代的，也就是说我们不能仅仅迷信于统计，机器学习和深度学习。迭代的核心目的是控制成本。
关于URI（同一资源标识符)，这里面有一个核心的思路，就是在软件工程里面，过早优化是万恶资源，在我们这个知识工程里面也是一样的，我们尽可能的把一些优化的步骤放到最后去做，才能降低我们的成本，我们不要去过早的优化。
观察知识的特点，知识和数据不一样, 知识相对要比较复杂的。我们知道即使是在机器学习里面，调参也是一个非常重要的过程。所以我们很难一下子就知道我们这个知识的样子是什么样子的，或者我们怎么将一个非结构化的数据，给提高变成一个结构化的数据。通常的办法是从小做起，从一个小的数据集来做人工的观察和标注，找到数据之后，我们发现一些规律，这个过程英文叫做Bootstrap, 就是迭代。我们用规则或者用统计逐渐的来减少人工观察的比重，在这里面有一种特别好的工具叫做Faceted Browser，中文叫分面浏览器，这是一种快速的发现数据里面规律的工具，或大家不知道的话可以去搜索一下看看这种工具，我认为这种工具有非常广阔的市场前景。
其他的HCI（人机交互）工具也是很重要的，比如说谷歌有一个编辑器叫GoogleRefine，后来把它开源了，现在应该叫OpenRefine。它就是这样一种观察数据和标注数据的工具。我在硅谷的时候，还用过一个系统叫Ayasdi，它的原理是一个多维度的拓扑分析。当面对复杂的数据时，其实很难一眼看到它中间的规律是什么，那么你即使用各种各样的调参方法，比如说用SVM做各种科目的选择，你都很难选得对，最后你不如把它可视化出来。如果高维不行，你把它降到某一个低维再进行可视化，进行多分辨率，多角度的各种各样的可视化，然后人能够快速的发展其中的规律。所以一个好的知识编辑系统，它通常都是一个观察系统，一个迭代的系统，它让人去从各种不同的方向去进行这种数据的选择、变化，然后发现其中的规律。
下面一点讲这种长尾需求，就是我们常犯的两个错误，一个是满足1%用户的需求，这个市场太小，另外就满足99%的用户的需求。这样一个太过通用的目标，使得我们完全没有办法往前走，如果你能满足全人类的话，你就没有办法满足几乎任何人，就像Wikidata、Freebase、Dbpeida和 YAGO这样的通用数据库，我们把它用到任何一个垂直领域，都要进行大量的数据清洗和进一步的数据整合工作。知识库和文本的区别在哪里？它的长尾需求特别大。所以知识是非常难以融合的，而且每一个人他都有自己关心的点。不管是做企业的应用，还是个人的应用，在企业级的话，就各种各样的企业的长尾需求，那么做个人应用就各位人的长尾需求，实际上他们很难去进行融合。做统计的时候，其实是蛮容易融合的，因为你只要有一个结构化的数据，你就能把它融合在一起。知识上而言，我们之前做过很多实验，我们发现这种融合非常困难。在2010年的Semantic MediaWiki(SMW) 大会上我曾经做过一个演讲，叫做“维基的不可承受之轻”（The Unbearable lightness of Wiking），这里面有一些细节，为什么结构化的表示很难融合。最核心的一个问题，我们在满足长尾需求的时候，我们如何能够让各种不同的世界观能够共存，然后让他们在一起，而不是他们相互冲突，就是解决长尾需求的关键，在这个演讲里面都有说。
那么最后再用四五个slides来讲一讲小数据问题。大数据和小数据有什么区别？我一直在强调，之前很多个slides都在说知识图谱，它不是关于大数据是关于小数据，或者说是关于智能数据（Smart Data）的。大数据通常大家会说有几个V，比如说volume这些。那么小数据其实它也是有几个V，它不过是另外几个英文单词，第一个就是Value，就是价值。为什么有大数据问题，我们开玩笑，因为我们把垃圾扔掉的这个成本，低于我们把垃圾储存起来的成本，所以我们才会有大数据。那么对于小数据而言，我们恰恰要关心的问题，就是把垃圾给扔掉，我们不关心有多少数据，我们关心的是数据的价值密度，我们要提高数据的投入产出比。
另外一点是Veracity，就是数据的真实性。我们关心数据的质量，那数据质量的核心，就是它是不是可验证的，是不是可用的，是不是有自描述的。第三点就是Versatility，就是它的多能性。这是我们在设计语义下面的时候，经常说的一句话，语义数据它能够预言未来不可知的应用，为什么？因为我们的数据其实不是待在我们自己的服务器上，我们是要用来进行交换的，而在交换的过程当中，会产生大量的这些应用。我们之前没法去设想到的，我举一个具体的例子，负面的例子，就是在金融里面有那么一个语言叫XBRL（可扩展商业报告语言），实际上每一个金融报表，它都要有一个结构化的表示，但这种 XML 的问题就在于它只能针对一种应用而言，就是这种金融报表，那在1998年设计的这个东西，现在其实已经很难用了。现在我们面临的金融问题，投资研究的问题，就很难被它满足。所以我们之后又做了大量的工作，去设计这种金融的知识图谱。那么对于知识图谱的表示，因为这个数据本身它是可描述的，可移动的，所以它更多的在想，即使未来有了一个数据，有了新的一个应用，我不知道我在设计这个数据的时候，我一样可以在这个系统里面把它用起来，这就是三个V的作用。
小数据的价值，我总结为三点是催化剂、浓缩铀、打折卡。催化剂就是说在数据的催化和融合过程中，它可以产生新的数据，像通常在数据集成的过程中，会有一种东西叫做数据映射或者叫本体映射，其实这就是典型的催化剂，是在单个数据里发现不了的规律，把两个数据结合到一起的时候，我们就发现了，这叫催化剂。那么浓缩铀就是说有很多数据作为一种提炼的，特别精华的数据，可能这些数据就是一张U盘就能拷下来的东西，可能就是一个分类数特别小的。但是这种东西是多少人多少年的心血的凝结，这种数据是非常小但特别的有价值，所以我们核心就要追求这种数据。第三点就是打折卡，就是有些数据具有特别的先验知识，比如就是一个推理的规则，但是通过这个规则可以帮助我们极大的降低成本。那么在金融领域，其实催化剂、浓缩铀、打折卡就经常的出现，因为我们核心的数据都非常小，但是正是由于这些数据，我们可以四两拨千斤。打个比方，之前我去听因果树的一个发布会，他们也是一个金融数据公司。他们的比喻是说，他们的数据打印出来之后，可以从地球到冥王星那么远，在这个大数据上进行搜索。但实际上一个聪明的系统，它的核心需不需要这么多数据呢？可能很少，它打印出来也许可能就沿着我们呼家楼地铁道转一圈就够了。但是这么小的数据，它起到的价值可能比从地球上到冥王星的那么多的数据价值还要大，这就是小数据的价值。
小数据的“小”字其实从几点上来讲，一个是从用户的角度来讲，就是它更多的是从中小企业，或者从个人用户，从非常穷的用户开始来做的。没有专家，它的预算非常的少，那么怎么来解决这个问题。第二个就是小工具，可能大家在做系统的时候，会有一个想法，上来就要做一个大数据系统的，做这种分布式的东西。但实际上知识系统核心最难的点不是在这种系统上面，而是各种小小的工具，比如你怎么去编辑一个正则表达式，怎么去可视化一个数据，怎么去数据集成，怎么去让你读数据都觉得特别方便。这些小工具可能最多决定了项目成败的最关键的因素，而不是那些大的东西。
另外就是周期要小，知识工程跟传统的比如说机器学习最大的区别，它真的不是一下子就能够搞成的。你要反反复复的观察数据，所以一定要进行演化，进行精益，也叫Lean Startup, 然后才能够做的好，才能够降低成本。
最后总结一下小数据的方法论，其实跟邓小平讲的三个“论”，我觉得蛮像的。一个是摸论，就是摸着石头过河，我们不可能一下子就知道怎么去处理一个数据，或者怎么研究一个数据，怎么应用一个数据，我们通常是摸，从一个小事情开始摸，然后慢慢的摸大。
第二个就是猫论，不管是白猫黑猫抓到老鼠就是好猫，所以经常有人问我，你做知识图谱是不是一定要用RDF？或者一定要用neo4j图数据库，我觉得都不一定，因为核心就是我们要解决的问题是什么。比如我们解决数据的可重复性问题，或者数据的可分享性问题。结构化数据能帮助我们提高数据的质量，这就是知识图谱，不用太过于纠结，到底是哪一种具体的技术表现形式。
第三点就是不争论，因为知识实际上体现了世界观，没有任何两个人的世界观是一样的，所以没有人真正有可能在知识上面达到完全的一致，我们一定要有那么一种方法，让大家即使不一致还得往前走不争论，第一部分讲这个小数据问题。
第二部分讲一些知识表现里面的成本问题。首先声明，这是我的个人的看法，人工智能问题说到底是一个经济学问题，而不是一个算法问题。三月份的时候，我曾在云知声深入的讲过这个问题。具体到知识工程领域里面，就是它是一个经济问题，而且它是一个关于自由经济的问题，它不仅仅是一个算法问题。知识工程的核心问题是成本，刚才我们提到过的，那么成本的核心问题就是人和人之间的冲突，而这个冲突就是人思想的自由和我们未来一起在做成一件事情之间，我们要有一个冲突。怎么去降低成本呢？怎么去又达到了这个自由，但是又不让大家冲突的太厉害了。所以这是一件很难的事情，这也是知识工程这个领域发展慢的一个核心原因。这个又和经济学是紧密联系在一起的，因为我们在做这个工程的时候，不能只考虑这件事情它是一个技术问题，不管是我们有数据，我们分享数据，还是我们收集和处理数据，实际都是由一些具体的人和组织来承载的。他们的利益和观点都是完全不一样的，像谷歌的利益其实跟大家都是不一样的，所以谷歌之前推出了很多东西，这些最后都失败了。他 2006 年的时候推出了 Rich Snippets，2010年他推出了Schema.org，其中这些项目都不成功，因为谷歌的利益并不是跟其他公司完全一致的。而在这个事情上面，就他的这种世界观，强加到别人身上去的时候，别人就不用会。所以怎么能够让各种不同的观点，在不同的范围内共存，这才是知识图谱能够普及的根本。这也是为什么我认为这件事情最终是应该由小公司来做成，而不是大公司做成的原因，因为这件事情它必须从小要做起，没有一个大公司真正能强迫大家接受他的世界观，历史上没有过。
所以我们回顾一下外国之所以能够成功，外国的成功说到底就是一个自由，它允许大家可行其事，不需要每一件事情都事先批准。这是当年Tim Berners-Lee，在1991年创造了Web的核心思想。所以在知识的领域里面，那么之前称为语义网，我认为也是一样的，就是“为无为，事无事，味无味”，这是《道德经》里面的一句话。尽可能让每一个人都按照自己习惯的方式去做事情，从小事情开始做，从细节开始做，一个好的知识系统，它应该是可以被自然的增长的，它应该是容忍差异。不要让每一个人都去追求特别的整洁，通常这种整洁只是一个人的世界观，如果你强求大家在一起做的话，这个事情是做不成的。因为我们之前做很多项目的时候，包括我原来在RPI的时候，我反复问自己为什么那些项目会失败，很重要的原因就大家太强调一致，比如分类树，一个概念怎么跟另外一个概念结合到一起，大家吵了很多架，这些架其实都是没有必要去吵的。如何能够容忍差异，快速的进行推进，才是项目成败的关键。我们现在在做金融知识图谱也是一样的。所以知识管理的核心是成本问题，成本的核心问题就是隔离世界观的问题，最大的成本就是人和人之间的成本。
回到刚才讲的猫论，不争论，就不要去争论命名的问题，不要去争组织的问题，不要去争用RDF 还是用图数据库的问题。这些问题都不重要，就是一个能够快速向前推进的方法，能够去容忍这种差异的方法，才是最可能的方法。这个事情也可以从过去30年的另外一件事情上得到佐证，就是我们一直想有一个知识共存的共同语言，叫Lingua franca。在比如从七十年代、八十年代开始，有Prolog, Lisp，CL，Clips，KIF，KQMI，DAML，OIL，RDF等等很多种语言，最后这些语言都不是很成功的。所以如果想从头开始，从顶层设计一个语言，这个语言一般来说是不会成功的。因为你强求所有人去适应一种世界观，一种方法论，一般来说不会被别人接受，在英语里有一句话叫做一个语言开始只不过是一个方言，而恰好这个方言有一个军队，所以它就变成了一个语言（a language is a dialect with an army and navy）；就像为什么以北京话为基础的普通话变成了一个语言，因为北京有军队，那上海话就没有军队，所以就没有成为一个语言没有成为一个普通话。
在我们这个计算机语言里面，我觉得类似的规律也是存在的，所以一个语言它之所以能够成为计算机世界的大家共同承认的一个标准，并不仅仅说因为这个语言设计的好。我们之前在 OWL设计的时候，就犯了这样一个错误，我们想各种设计上面什么优劣问题，当然我们就忽视了市场怎么来接受它，用户怎么去接受它，各种政治的、经济的作用，怎么能够让这个语言被大家接受，仅仅从计算的角度是不够的。
这一页可能讲的有点技术，就不深入讲了。之前我们在设计OWL、RDF的时候，一个核心的东西，就是我们把一切的语义都由URI来承载了。在谷歌有一句名言，可能大家在其他的知识图谱交际场合内也听说过，叫构成世界的是实体，而不是字符串（entity not strings）。这句话我认为它是有适用范围的，如果超出这个范围，就有坑在里头呢。因为你想把这个世界用实体来表示，实际上实体它只不过是URI的另外一种说法而已。只是说现在谷歌定义了一大堆这种实体，就是谷歌的URI，然后他来表示这个世界，但是从字符串到URI的时候，它代表的是一种世界观，是谷歌的世界观，而这种世界观和大部分人的世界观是相违背和抵触的。之后进行数据集成和表示的时候，会遇到非常多的陷阱在里头。我们可以打一个比方说，在编程的时候，我们会有各种各样的模块，每一个模块里面都会有自己的变量，在程序语言里面有这种全局变量，还有局部变量。如果我们在知识构成的时候，我们用URI来进行表示的话，实际上我们强迫每一个变量在知识系统里的每一个变量都变成一个全局变量，那这个系统会有大量的不可预知的偶合性。所以这个就是很多问题的根源，如果我们想有一个 scalable 的系统， 一个大的系统，我们必须把它划分成模块。如果我们要有模块，我们尽可能的让这个系统的语义和数据局域化的，它的作用域应该是局域化的。但是在之前我们一直没有这样的工具，我认为这种工具需要出现。
第二个就是局部化事务，去中心化。我们回过头来讲，我们之前讲了这么多事情，一个核心是自由，一个是“为无为,事无事”。一个是隔离世界观的差异，然后政治问题，然后URI的罪，归根结底我认为核心问题就是要局部化和去中心化。就是数据的语义应该尽可能的局部化，它有一个多维的多层次的解释机制，它要把一个人说了算的一个解释器，变成一个在不同的上下文（context）下面，不同的语境下面去解释的一种东西。这种东西就是我们现在文因互联正在开发的一种系统，叫做大规模的一个分布式的实体解析器，具体细节可能今天就来不及说了。
最后一点就特别哲学了，叫认识论语义和本体论语义。我们之前在讨论所谓的语义网的时候，我们称为本体论。它在描述一个东西它到底是什么。但实际上我们更多关心的事情应该是一个认识论的语义，就是说我看的一个东西和你看一个东西，我们角度是不一样的。我们就应该容忍不一样语义的存在，在不同的域中应该允许不同的解释。在2010年的时候，我曾在RDF上这个Workingbook提出一个提议，就是允许他们让同一个词在不同的情况下，有不同的解释。因为我觉得未来的这种语言，它必须要满足这样的特性，这也是外国最核心的架子就是自由。
我们现在讲第三部分，第三部分更多的是结合市场的一些具体的例子来看，我们在创业的过程中，把这个知识图谱技术应用到现实中去，我觉得这里面最核心的一件事情，就是要做小事情。因为这是一个很难的事情，同历史上很多艰难的事情一样，它一定从小事情开始做起来的，它不会一下做一个很大的事情。我们之前看到了很多公司，这些公司他们有明星的CEO，然后明星的工程师，明星的科学家，再加上明星的投资机构，上来以后各种各样的发布会，高规格高逼格的录音和宣讲。但这样的公司绝大多数几年之内都失败了，因为明星的成本是非常高的，明星们因为他们一开始运营成本很高，他们就没有办法去做小事情，因为小事情只能挣很少的钱，所以明星没有办法做，最后他们都死了。在这个语义建模的语义网和后来的知识图谱实践当中，我们看到了太多这样的公司，可能有几百个这样的公司。不是每一个都是明星璀璨，但是基本上明星璀璨的公司都过的不太好，反而是那些低调的公司，最后活下来了，之前也有很多，这里列了几条。
明星的原罪就是我刚才讲的，明星本身就是企业最大的承担，他们就是最大的成本。如果我们关心的天顶星技术，我们关心的是技术发展的话，而不是这个企业本身和用户的需求，那么我们注重会失败。2006年、2007年，最后到2009年那一拨有很多企业最后死了，大家就总结说因为这个市场没有办法就像谷歌，Facebook一样去服务消费者，所以我们首先进行这种企业级的市场的服务，那么大家从消费者市场转进到企业市场。我觉得这不是问题的核心所在，到底是toB还是toC，这不是问题的核心，而是我怎么去解决成本问题，所以后来转进到这个toB的很多企业，最后也死掉了。因为成本是知识管理最核心的问题，我们刚才前面两个 part，不管是讲自由也好，不管讲工程也好，我们其实都是在谈成本问题。明星本身就是工程最大的成本，他们没有办法解决掉自己，所以他们就会完蛋。任何一个知识工程的项目，如果不能够Lean Startup，如果不能够快速的去迭代的话，它就一定是无解的，拿的投资的越多，就越接近于失败。
我们最后会分析一下Twine例子，具体的解剖这个麻雀，一个民营企业是怎么死掉的。也不光是Twine，之前有很多很多这样的企业，比如Sig.ma、Sindice，这些都曾经在2008年、2009年的时候非常好的企业，最后也就死掉了。像Powerset、kngine、Hakia、Evri，都是很好的公司，明星璀璨的公司，但是也都死掉了。因为我有幸跟其中几个公司（后来他们要么倒闭，或者被收购之后）接触，跟他们聊了聊，了解了他们内部的一些情况。我觉得总的来说，在他们那个时候，他们想做的事情太大了。因为他们作为一些很高端的人，明星璀璨的公司，他们必须做大系统。那么超越了这种公司本身所能够承载的能力，最后就死掉了，反倒有些小公司，比如说我这里列了两家，当然在美国至少还有100家这样的公司，像Yummly和Factual，这两家都是集中在餐饮这个领域里。像Yummly，提供在菜谱这个领域的语义数据，Factual是集中在餐馆这个领域的语义数据，反倒是这种公司活很不错。我在 MIT的时候，参加了一个 Entrepreneurship 的课程，那课上就有四个学生，他们做了一个class project，后来他们把 class project拿去创业，最后过了两年之后卖了八千万美元。他们做的东西非常非常的小，就帮助那个餐馆的菜谱做语义化和搜索，就这么小的一件事情，这样反而能够做成，做大了反而做不成。
我们具体来讲这个Twine里面的事情，Twine实际上它的创始人叫Nova Spivack，在我们这个领域里面是一个非常有名的人。2009年的SWC（国际语义网会议）的发言人，他在这个领域里面，之前已经差不多做了快20年的时间了，实际上做了无数个项目。在做Twine的时候，被号称是第一个主流的语义网应用。实际上它就是一个书签系统，可能现在很多年轻的小朋友，已经不知道什么叫delicious，delicious是属于一个很笨的系统，就书签的这种收藏夹，然后Twine一出来的时候，它就是一个可视化的语义的收藏夹。它可以帮助你进行这些新闻的分析，然后帮你打标签，再进行集成。Nova Spivack在2009年的时候，在 SWC就讲这个Twine，但是到第二年2010年的时候，这个公司就关门了。关门以后，他写了一个很好的总结，我强烈推荐大家每个人都去看一看。写的非常的好，后面讲的这几点，就是我在读他的总结的时候，做的一些摘要，主要的内容其实还是他自己写出来。同样犯了很多，从市场定位，到这个用户的界面的设计，到工程底层的选择，及运营策略他都犯了很多错误。我觉得从用户角度来说，他核心的问题就是做的东西太复杂了。他要满足非常多的需求，又要做书签，又要做网盘，又要做分享，又要做推荐，又要做社交。那么做了一个很大的东西，可能他其中关注做一个点，来做这个事情可能会更好一点。当时他基于语义技术，太过于乐观，被胜利冲昏了头脑。被初始的胜利冲昏了头脑，他就做了太多的事情。在做的过程当中，他们逐渐发现了“用户会管理个人信息”这个假设根本不成立。因为我们刚才提到了，这种成本核心论，就是人和人之间的世界观的冲突，还有人组织信息能力的差异。大多数的普通人其实是没有能力进行知识建模的，哪怕仅仅是简单的标签或者标签的这种组合，绝大多数的人都做不到。如果不能够把界面尽可能的降低下来的话，那么对于toC的运营而言，所遇到认知的鸿沟是没有办法跳过去的，这是从界面的角度来说。
从技术的来说，他们当时是被诱惑了，在2006年和2007年的时候，他们做了Twine系统的时候，他们认为如果是叫做语义，那么就一定是RDF，如果是RDF，下面就一定有一个RDF的数据库，所以他们就去做了一个分布式的语义数据库。因为当时还没有这样成熟的数据库，所以这个代价是非常的高。当他们做了这个分布式语义数据库的时候，他们发现用户在做检索，他们就转去做外部级别的语义检索。因为他们这个公司是非常小的公司，只有40个人，当时就想做现在谷歌要做的这种事情，显然来说这个战线就拉的太长，当时还基于lucene，基于 Solr做了一个语义接口的系统。今天我们有幸有了ElasticSearch 和neo4j这样更好的数据库和检索系统，我们就没有必要再去犯同样的错误，自己去开发这些东西。
Twine当时发展的太快了，对自己过于乐观。他们融了很多钱，之后Nova就说了，不应该融这么多钱，应该量力而为。那么我们又回到我们刚才讲的那个小问题上来了，因为一个系统，它能够很好的运作，是经过不断迭代的，先做一点小事情，出一些小成果，然后再做大一点再做一点。所以一下子融很多钱，一下子有很多明星，通常反而对这个系统是不好的事情。之后还有很多东西，我就把它跳过了，我想着重讲后面几个问题。我觉得Twine它犯的另外一个错误就是它坚持和W3C的标准兼容可能是它一个很重要的问题。然后这也是有很多人在问我，就是说我们要做知识图谱的话，那我在市面上我们看到很多书都在说要用RDF ，OWL这种语言。我说这个不一定，一定根据你具体的应用场景来定，到底要不要用RDF，因为你用它的时候，所遇到的建模的代价，遇到的存储，查询的代价，各种工具的代价肯定都是很高的。所以尽管我和王丛，我们这些人都挺熟悉这套架构的，但我们没有用RDF，我们还是尽可能应用保守的技术解决方案。就是因为这个成本，可能是我们现在这个阶段还不能够承受的，我们现在更多的是用JSON，然后把JSON放在关系数据库里面进行检索，这是降低成本的一个小的 trick。
Twine当时想做很多事情，其实后来就是Facebook做的。Facebook在2012年推出了Graph Search，那么 Twine在2007年、2008年的时候在做，他们就是超前了。所以说我们现在在做事情的时候，都提醒自己，不要做太过超前的事情，尽可能的利用现有的技术，现有的人才来做有限的这种预算之内的，能够达到有限的目标，而不是做太多的事情。基本上就这些，最后做一个总结吧，就是从 Twine的例子来看，这种做知识图谱的小公司，如果能活下来，最重要的事情就是不要做大事情，要做小事情，而且一步只做一件小事情，不要试图去发展天顶星科技，够用就好的科技就好；不要教条，不要说我们必须要用某一种特定的技术。因为我们要解决这个问题，知识图谱、语义网是一堆问题，而不是一些教条的技术，我们只要能够解决技术，解决一个需求问题，我们不要去迷信任何一种标准，我们不要试图一步到位去发展技术，不管是图数据库也好，不管是RDF这种知识表现语言也好。尽可能去演化，没有什么东西是好的东西，一下子就能够设计出来的，一定是从实践当中去总结出来，循序渐进，演化出来的东西才是好东西。
最后总结一下就是“以人为本”。知识图谱能够发展好，刚才讲的所有的东西归结为一句话，我们不要从机器的角度去思考问题，一定要从人的角度去思考问题。
我们文因互联正在开发一些工具，我们把它称为核武器，其中有几个叫大规模的实体解析引擎，还有一个知识图谱的高级语言，和一个混合的知识编辑器和知识的探索浏览器。其实这些工具设计的基本哲学思想，也都是今天说的这些，我也非常欢迎大家以后有机会的时候，来探讨这些东西，它到底是什么？还有其他的一些东西我们正在做，所以最后履行一下我CEO的职责，我们文因互联非常欢迎大家来加入，如果大家对我们做的事情有兴趣，请加我的微信（baojie_memect）我们大家一起来聊一聊，谢谢大家。
发表回复