本文来自文因互联CEO鲍捷博士于2017年7月5日在天津大学参与由中国计算机学会青年计算机科技论坛主办的【知识图谱与图数据库新进展】报告会上所做的演讲。
鲍捷：感谢天津大学邀请我来参加这个活动，也谢谢各位今天来听这个讲座。我讲的东西跟各位老师相比，可能显得很 LOW，我更多考虑的是如何落地的问题。
KG科学到KG工程
我这两天在看《长征》这本书（注：《长征》王树增 著），在火车上看的。所以今天早上临时就在我的 PPT 上加了“长征”这两个字。我之前一直是做逻辑的，博士、博士后期间基本上都是做逻辑的工作。当时非常困惑，为什么做出来那么多好东西都没人用。
我在2007年、2008年去 RPI 的时候，RPI 应该是语义网最重要的一个研究重镇。我在那里做了一些项目也是失败的。当我在看《长征》这本书的时候，书中提到中央苏区出发的时候是8万军队，到了陕北之后只有8000人，90%的力量都损失掉了，这个问题出在哪里？
我觉得就是经典的所谓的普遍真理和具体实践相结合的问题。
KG 工程中，在落地这件事情上，所遇到的痛苦、困难，也是一样的。很多原理，我们20年前就已经知道了，40年前就已经有知识管理这个学科分支了，但中间一路落地的过程当中，还是不断遇到新问题。在某些时候，研究滞后于工业的发展，滞后于市场的发展。如果还停留在过去那个时代，用过去的那套普遍真理来套现在的具体问题，就会流血、流汗、流泪，这是我们现在遇到的问题。
高投入、长周期、低效率的交付
走完长征是一件非常难的事情，类似地，世界上绝大多数的项目也都失败了，因为这些项目是高投入、长周期、低效率。就像漆老师（东南大学教授漆桂林）刚才说的，这不是个简单的用深度学习就能解决的问题，通常这是需要把很多种人工智能的方法组合在一起才能解决的问题，机器学习、神经网络、逻辑方法，甚至还有一些非人工智能的，比如说像人机交互技术，还有数据库的技术，还有信息检索的技术，把这些技术都融合在一起，才能够真正解决实际问题。
这种融合本身就是超级困难的一件事情，而且你要配置以及融合这样一个团队，这是超级困难的事情。这还没有考虑如果做商业化落地，还需要有运营团队、需要商务团队，还需要投资人团队，所以整个把这样一群人组织在一起，可能两年、三年甚至五年时间，都未必能够有一个真正的成果出来，这是一件极大考验所有人信心的工作。
更重要的问题是，如何能够在相关方的信心耗尽之前，交付一个结果。 这就是为什么专家系统，或者逻辑的这些东西，在这之前只在非常有限的几个领域里面应用起来，比如像国防、医学。因为只有像这样的领域才可以容忍一个长周期的项目，它可以获得一个非常高的现金初始投入。
所以说如果没有美国军方的支持，根本不会有这个学科。比如像 Siri 一开始就是军方投入的。现在的 RDF、 OWL 全都是军方一开始投入的，美国军方砸了几十亿美元，才有了今天这些东西。
今天的商业落地，不再有军方或者政府这样的大靠山帮我们渡过开始的难关了。我经常开个玩笑，今天面临的所有的这些知识图谱上的问题，如果现在发生了第三次世界大战，都能够解决掉，因为政府只要抓一千万免费劳动力来就可以了。核心问题就是，怎么去降低成本，怎么让流血、流汗、流泪流得少一点。
有没有一种万灵药能够帮助我们?答案可能让大家失望了。这件事情，至少到目前为止没有一个标准化的解决方案。
可能这个领域还是在发展的极早期，甚至我觉得人工智能整个领域，它的商业化也都在极早期。现在人工智能领域发展的极早期的一个表现，就是各大公司都在从学校里挖教授，来主导他们产品的开发，就充分证明了这个产业非常的不成熟。
对于大公司在投资人工智能这件事情，相对于之前已经是进步了，因为之前是军方和政府在投资这个事情。最近这几年，主要是大公司来投资这件事情，还有一些大 VC。过去这一年，中国人工智能的投资已经超过美国了，这就是超级火爆，这是一个进步。
但是真正再往前走，不能仅仅依赖于大公司，要知道真正的革新都不会是大公司做出来的，都是小公司做出来的。因为大公司通常都只能在现有的模式上修修补补，给它加一点什么东西。大公司的东西更多是 PR 的效果。当然大公司的价值在于它能够激发整个领域，激活一些投资机构包括政府对这个领域的想象，那么就连带起来，把整个领域全部拉起来。
精益迭代
那么对于更小规模的公司，如何来推进这件事情？我觉得精益迭代是不可绕过的事情，这也不仅仅是在知识图谱这一件事情上面。精益这个概念，最早是从工业制造领域出现的，就是在丰田汽车的制造里面诞生。在传统工业里面会发现，一个事情可能要花很长的时间，有很高的风险才能做，怎么去降低我的风险，降低成本？关键就是把一些大的事情拆分成很多小的步骤。
日常生活中也会有这样的事情，比如说高考，整个高中阶段是三年时间，最终才会有一个成绩。中间就要分成年级，年级又分成学期，学期又有很多的考试，一层一层的逐步地考试，为什么要有这些考试？因为是要提供反馈，通过反馈来调整行为。
所谓精益方法的核心就是构造这样的反馈，通常的反馈会有三个步骤：一个是 build，第二个是 measure，第三个是 learn。build就是构造一个系统；measure 就是把这个系统放到现实中去检查，看看跟预想的有多大的差距。measure之后，得到一些数据，再进行分析，分析结果再反馈到系统里头。
这个原则是非常非常简单的，基本上一分钟解释下来，在座的都能听得懂。但是精益迭代可能是世界上最难的一件事情，远远超过高考，远远超过算法研究。实际上精益迭代是降低成本，也是在构造一种可演化的系统，它的核心是反人性的，实际上它是一种假设检验系统。
精益迭代=反人性
科学就是反人性的，所以世界上真正拥有科学素质的人是非常少非常少的，几个百分点而已。精益这种迭代的事情，在创业或者在实际工程应用中，也是非常难的，不管在大公司还是小公司。尤其是在大公司实现精益的概率是非常非常低的。包括自己在内，我觉得这几年走下来，要让每个人都去了解精益的思想是什么，包括让不同背景的人都能够来学习，来接受这种概念非常困难。
比如说做算法的研发，做算法的这些科学家们，包括以前的我自己，我的工作周期是以年为单位的，因为会议是一年开一次，我就盯着每一年的会议，现在做的工作，可能一年之后才能被检测。但是在工业界，要想做落地应用，反馈周期必须快很多，可能是以月、以周，很多时候是以天为单位进行反馈的，这种思维的转变非常地困难。
再比如说做金融的，需要做金融分析师，金融建模怎么去进行快速地迭代？这也是完全不一样的一件事情。可能之前他们就不会想到说以周为单位来进行这个事。比如说我做一个产业链模型，或者做一个财务分析模型，怎么能够快速地以天为单位的进行迭代，这跟传统的金融分析完全是背道而驰的东西。
这只是非常小的两个方面，但真正你要想落地智能金融这件事情，还要思考怎么精益地运营、实现工程。最后会讲到15条军规，就是在讲如何在知识图谱里面做这种精益。每一条让大家能够接受，并且把成本意识深入到骨髓里面去，是非常困难的事情。
知识图谱的全周期成本
刚才提到成本，有哪些成本？我认为分为技术成本、团队成本和组织成本。我把技术成本放在第一个，并不意味着它是最重要的，只是大家更容易理解这件事情。技术有知识提取的成本、知识存储的成本、知识推理的成本、知识检索的成本、运维的成本、更新的成本，这些都具体不多说了，大家应该很容易理解。
团队和组织成本，在这件事情里面是更重要的，刚才在茶歇的时候，也跟一位朋友在聊，他问落地最困难的是什么？我就说政治。政治是整个困难程度的90%。政治困难包括了建立一个团队并融合好这个团队的全面问题。我先说团队成本，现在中国市场上能有多少人真正理解知识图谱？我觉得几百人可能是一个非常夸张的数字。
也就是说如果在这里面稍有不慎，做一个比较激进一点的技术架构，比如你很不幸地选择了 triple store 来做技术架构，架构师离职了，你可能要花一年来找一个人替代他，这个成本就非常高了。而且这里面有教育成本，一个人进来之后，他到底是一个月之后就能干活，还是半年之后能干活，取决于你的技术架构。如果你的知识提取架构是以正则表达式为基础的，那可能很容易。如果你是以一个规则的神经网络分布式表示来做，可能要半年之后才能理解是什么，所以这都是成本。
组织成本包括规划，不管是大公司，还是小公司都是需要做规划的。我原来在大公司，我们开玩笑说，一年会花6个月时间做 plan for planning，然后再花3个月时间做 planning，最后再花3个月时间来干活，这就是规划成本。小公司不停地融资，这也是规划，不停地有各种月度规划，写 OKR。要想让每个人都能够理解技术是什么、目标是什么，非常困难。
大公司有一个部门之间的配合问题，几个部门之间的撕逼是无处不在的。整个知识图谱技术，刚才提到的是极早期技术，极早期技术也就意味着大多数人不理解，包括那些手里有钱的人、手里有权的人。那些现在在干活的人，都不理解这个东西是什么。你要让所有的人都能够理解，就必须降低你的预期，然后降低你的风险。尽可能地用别人已经理解的词汇，尽可能用已经成熟的技术来一点一点的拱，日拱一卒，把这件事情拱下去，但千万不要激进，激进经常会失败。
如何选择数据库
大多数的组织都会需要知识图谱，因为所有的人都需要知识图谱，这是没有疑问的。经常会有人问我，比如汽车领域需不需要知识图谱，或者教育领域需不需要，那答案肯定是需要。但是实际上大多数组织现在不应该上知识图谱，原因如上所述，现在是知识图谱的一个极早期的阶段，如果你这个团队里头没有一个合适的人来主导这件事情，失败的概率非常大，就是白白浪费钱。
经常有人问我说知识图谱，是不是该上个图数据库。如果问这个问题，我的答案就是 No，你不应该用，因为你不了解。如果你不了解，先用传统的技术，先上关系数据库，什么时候你觉得关系数据库已经难用到无以复加的时候，你再来用先进的技术。但是一般情况下，我认为现在的关系数据库已经足够好了，它的各种扩展，就已经能够满足大多数实用的问题。
优先选择什么样的数据库？我把它称为关系文档数据库。第一个，它要自身要支持 SQL 查询，第二个它要支持 JSON。为什么要支持这两个？还可以有其他的选择吗？为什么不是 XML 的数据库？现在 JSON 就是整个互联网上数据的标配，如果你选择其他的数据库还要再做一层的转化，这就是提高了成本，不要小看这个转换，会带来无尽无穷的数据更新的困难。
SQL 也是非常好，其实 SPARQL、SQL 都很像，都是一种描述性的查询语言，现在也有像 mongodb、elasticsearch 的基于 JSON 的查询语言，但那种语言都非常的反人类。所以目前能够大规模的应用的，并且你想让一个程序员第二天就能够上手，请用这种语言，绝对可以帮助你降低成本。
这样的数据库有哪些？我现在能够想到的就是 PostgreSQL。OrientDB 在这里没有写，我不推荐大家在工业的应用中应用，因为它不成熟。我觉得唯一的选择就是 PostgreSQL。什么是 JSON，工程师都很清楚，我放在这儿只是给没有技术背景的朋友们，告诉大家什么叫做 JSON，就是一个简单的数据结构。
在不同的情况下会需要不同的数据库，关系数据库是最基本的，非常成熟，你遇到任何问题，一定能够找到人来帮你。各种表结构的处理，就是这种ER图，我们遇到的绝大多数的知识图谱问题，都可以转化成ER图来建模的，所以这应该不会有太大的问题。我们遇到的绝大多数的推理任务，你都可以转化成SQL的查询，变成一个递归查询，或者变成一个存储过程。只要你想做，都可以在 SQL 内部解决所谓的80%的问题，剩下20%的问题，你可以先忽略，如果它的商业价值不大的话。
缺点就是传统 SQL 的表结构比较死，比如说你定了表结构，已经上线了，突然发现表结构要修改，然后你得锁表，一锁锁几个小时，很多线上系统是不可承受的，但是好在现在很多新的系统已经可以允许你在线做这件事情。比如说 PostgreSQL 已经允许你做了。传统上，你需要有固定的 Schema，现在有了 JSON 的支持之后，你可以把 JSON 作为一个字段，放在关系数据库表里面，这已经把 Schema 的可演进性变得更加灵活了。这是第一种。
第二种是文档数据库，基本上就是各种各样的 JSON 数据库，最有代表性的是 mongodb，跟它竞争的还有好几家。mongodb 应该是所有的文档数据库里用得最多的一个。好用、简单、程序员超级喜欢。问题就是不能支持 join 联合查询，也存在稳定性问题，比如说 mongodb 在早期的时候会有丢失数据的问题，还会有速度慢的问题，失内存的问题。做学术研究的都不会想这些事情，但是一到工业中就变成麻烦的事情。上线一个系统，大部分时间可能都在处理这种内存问题、硬盘问题、吞吐量问题。这就是工业和学界关注点不一样的地方。
最后一个是图数据库，在座几位老师也都提到过。优点就是在这三种数据库里面，它的表达力是最强的，为此付出的代价就是性能。目前的图数据库的性能都比较差，量稍微大一点以后都不行，而且图数据库还有一个非常本质的限制，就是它的分布式查询能力比较差，所以如果数据量比较大，图数据库就不是好的选择。
这是一个 PostgreSQL 上 JSON 查询的例子，我选了一个特别特别简单的例子。还有好几种不同的原语，可以构造出非常复杂的JSON 的查询。
现在也有人在 PostgreSQL 上面来构造一个图数据库，比如说有 Agens Graph，就是在 PostgreSQL 上面构造一个图数据库。大家可以看一看，但我不推荐大家在生产系统里用，因为还是非常实验性的东西。
一些工程的经验
1.持续交付和错误归因
下面我讲一些非常非常工程的经验。第一个就是持续交付和错误归因，这个是我们团队自己内部在做数据提取的时候，曾经遇到的困难。我们在做一种类型的提取的时候，团队一开始就特别没信心。我的要求是95%的正确率，现在大概能不到 80% 的正确率，我说你什么时候能达到95%的正确率？整个提取团队都不知道该怎么回答这个问题。
我说那先坐下来，先来看代码。我又问，你们有没有联调系统？什么叫联调系统？就是你做了提取之后，这个提取有的对、有的错，错误在哪里，你们能不能实时自动地做这个联调。三个人在做这件事情，能不能每个人都知道错误归在哪里，答案是没有。我说现在先不去想算法了，先把联调问题搞定，所以核心是什么？就是反馈。
一个知识提取的任务，如果从算法角度来思考，优先考虑的是算法精度那些问题，是从机器的角度来思考这些问题的。但实际上这件事情的核心不是机器而是人的问题，人的问题就是你如何理解这个问题，如何提供一个反馈。
那么一个联调系统和错误归因系统，就是提供这种反馈的关键所在，包括很多小细节问题。比如说一开始打印的错误信息是很长很长的一串的，这么长的一串字符串，谁也看不懂。我说咱们先把它给分行分好，然后把关键的数字彩色化，一目了然，这样相当于有一个错误的控制面板，一看就知道错误在哪里。大概花了几天时间做这样的联调系统，提供反馈之后，第一周就提高了10%，第二周提高了5%，第三周又提高了5%，所以很快，不到一个月的时间，就做到了95%。
在这个过程中，我没有跟团队讲任何算法问题，事实上这个错误的下降，发源于这样一个精益系统的构造，就是持续交付和错误归因。持续交付是指，之前这个系统可能要一个星期才能 demo 一次，这样太慢了，你必须以天为单位，你每天必须交付一次。你这个代码必须每天通过测试，所以这个过程，没有涉及到任何算法的教育，仅仅是通过提高了反馈频率，切碎了任务，就让系统开发的成本大大下降了。
2.平衡粒度和成本
第二个是平衡粒度和成本。现在在做文本摘要，摘要会分成很多种，一种是要做非常细粒度的提取。比如说对外担保公告，能够担保什么公司，什么时间，担保事由是什么，金额是什么，这是我们要做的一个非常细粒度的 entity 级别的提取。
谷歌的知识图谱出来以后，他说搜索的是 entity ，不是 string，这句话非常好，但是这个普遍真理是有适用范围的。如果把这个作为一个教条来理解，凡事都要上entity，这个系统的成本会高到无以复加。更多的时候，不是需要entity。很多时候，只要句子层面的东西就够了，或者一个段落层面的东西就够了，为什么还要再深入下去？所以在这个时候，从段落到句子、到词、到实体，每往前处理一步，这个成本都会直线地上升。
要根据商业目标来选择，到底到了哪一个粒度，要先停下来，不要再往前走了。客户可能因此在某个程度上他不满意，但他只要能够忍，这就是可以接受的。在有限的预算内，要找到一个平衡点。
最后一句话，最廉价的知识结构化依赖于中学语文。今天能够做所谓的知识图谱，核心就在于这个市场上已经有了大量结构化数据了，这些结构化数据，要么是通过表格来做的，要么是出于中学语文。因为每个人都会用标点符号，每个人都会分段，如果没有这些中学语文的教育，今天做各种知识提取的可能性就不存在。我认为目前世界上技术水平下唯一能够大规模提取的结构化知识，就是句子和段落。实际上很多情况下，到这个程度就足够了，不需要再往下了。
精益知识图谱15条军规
最后再多说几句团队管理的事。整个知识图谱的建设，团队的核心是很重要的。而核心的人，他既要理解业务，他也要理解技术，最核心的人，他要打心眼里头知道这个事情的边界和成本是什么，他打心眼里头理解精益迭代是实现这件事情的一个非常重要的技术手段，要能够按天、按周来交付，要能够做好沟通。这里面每一条，说起来都很容易，但是现实生活中都是要一个项目一个项目的尸体累积起来才能实际掌握的。
像这本书（《长征》）里面总结的中国革命的战略问题。这是用几十万红军的牺牲才学习总结出来的东西。今天也是一样的，我这里面列了15条，这些也都是我过去十几年，做了这么多项目，死亡了十几个项目，在“尸体”上面总结出来的一些东西。我不敢说每一条都对，也不一定每一条都能够应用到其他的项目，它不一定具有可复制性，因为它是跟我个人有关的。其中有一些，我刚才已经讲到了，这里再把其中几个，我认为很重要的，我再多提一下。
周期、交付、沟通这个都提到了。第五条，其实也是跟工程有关的，要想保证工作不发霉就一定要晒，因为知识图谱这件事情特别容易出错，所以一定要保持透明性，不管对内还是对外。对内要让整个团队实时知道，比如：过去一个星期又提取了1000条。对外也要向各种投资人、客户不停地沟通，我们做了什么。一定要有在线的 Demo，这是低成本沟通的好方法，不需要每个人个别请求就能做好。要让工作的进度，让每个人都能够看到。下面我就不多说了，具体十五条军规请看下文：
1） 知识提取是投入很大的工作。因为周期长，反而更需要任务分解，化长期工作为若干可以短期交付的工作。
2）交付很重要。交付不一定要是最终的产品，尽可能思考是否可以可以把中间阶段变成可用的。按周为单位交付。
3）越是长期的工程，越需要在团队沟通上下功夫。及时通知团队成员已可交付模块的变化。
4）保持一个交付的心态。不仅对外交付，对内部也要交付。 联调系统就是交付的检查器。
5）保持工作不发霉最好的办法是晒。越是长期的工作，越要有意识地经常拿出来晒。
6）在线 Demo 是低成本沟通的好办法。
7）可视化工作的进度，并让所有的人都看到。
8）保存提取的中间产物：原始文件，富文本格式，text格式，段落篇章，Meme 提取，实体，标签……
9）不要用 RDF，或者三元组。那会带来演进的噩梦
10）保持提取出来的数据的可读性。保持合理的粒度的组织，不要分得太细，但也不要太大。如果原始数据可读性不好，多做一些自己用的工具来提升其可读性，如缩进、语法高亮、表格化、导出为 csv 等。数据可读性是数据debug的关键之一。
11）观察数据，不怕麻烦。知识提取是水磨功夫。牛人的能力往往就是掌握了快速观察的方法。
12）从第一分钟开始就写回归测试。写测试是节约开发时间，不是浪费时间。测试代码比提取代码还多是正常。测试提供反馈。
13）提取和测试，先写单线程，再多线程并发。写单线程的时候就考虑到数据可能会并发处理。队列方法可能简化处理架构。
14）尽可能避免问题大数据化。尽量避免分布式处理。先尽可能scale up，而后scale out。
15）适应没有标注数据、Golden standard。如果没有标准答案，可以试着用两种（或更多）不同的算法去解决同一个问题，然后比较结果是不是一致。不要等有标准答案。
这里再履行一下我的义务，如果你认同我们实事求是的做事方法，无论是新进工程师还是资深工程师，都欢迎你和我联系，我们一定会成为好朋友。
我也衷心邀请你加入我们公司——文因互联，一个稳扎稳打的慢公司。我是文因互联创始人鲍捷，我的电子邮件是 baojie@memect.co
发表回复