分享知识图谱的理论， 相关工具和实际应用

最近做了一段时间关于知识图谱的项目。

知识图谱是一个非常有意思的领域，在这个信息泛滥并且越来越依赖于大数据的时代，知识图谱将会是一个被广泛应用的工具。

但是，在目前的中国，知识图谱的应用还不会很顺利，至于原因，我们可以通过对知识图谱的逐步了解来发现。

知识图谱的理论

---

网上有很多关于知识图谱的文章，但是很遗憾，现在的人都不太喜欢好好说话，明明很简单的事情，却一定要用一种复杂或者特别的表达方式，也就是所谓的行业黑话。

作为一个实际的应用者，知识图谱对我来说，就是四个字——呈现关系。

找一个角度去观察世界，理解世界，抽象出本体和实体（类似于面向对象中的对象和实例），然后立足于你的角度，找出实体之间的关系。

讲到实体之间的关系，不得不提三元组这个数据结构。

三元组其实也很简单，就是三个字——主谓宾。

比如说地球属于太阳系，那么主语是地球，宾语是太阳系，谓词是属于，那么地球和太阳系之间的关系就是属于，如果主语和宾语反过来，太阳系和地球关系就是包含。

当然，如果你换一个角度去观察太阳系和地球，你也可以得到其他的关系。

在实际应用中，深刻的理解这两个理论概念（知识图谱和三元组）非常重要。

如果都不知道自己在做什么，那你怎么可能做得好呢？方向不对，前进就是倒退。

在当代中国，知识图谱不能得到很好的应用，也是因为这个，大部分的决策者不能理解（他们往往已经有了思维定势）这个理论和工具，而大部分实际的使用者也不愿意花时间去理解这个理论和工具，这就导致理论和实际使用的完全脱节，这点我会在后面的实际应用中举几个例子。

构建知识图谱的工具

---

知识图谱的数据最好能保存在专门的图数据库里，这个现在有很多选择，由于我不是后端，就不专门展开讲了，以免贻笑大方。

作为一个前端，就多讲讲如何渲染和展示知识图谱吧。

d3和echarts都是历史比较悠久的前端库了，也都可以渲染图谱数据，但是他们并不是针对图谱进行专门开发的，所以如果你只是想做简单的展示，那么d3和echarts都是不错的选择。

不过，如果你希望在展示的同时，引入更多的交互，能对图谱的节点和关系做更多的定制开发，那么antv的G6的确是个不错的选择。

甚至你也可以直接使用antv出品的Graph Insight，这个产品相当于是一个知识图谱的低代码平台。

知识图谱的实际应用

---

可以这么说，任何行业都可以应用图谱。

因为现在这个时代，任何行业都会有数据，只要是数据，就会存在关系，只要存在关系，就可以使用图谱来进行展示。

但是这里有几个问题需要先考虑清楚：

1. 数据量大吗？

2. 数据关系复杂吗？

3. 对于关系数据分析的需求紧急吗？

我称其为知识图谱实际应用的不可能三角。

只要有一个条件不满足，实际工作就很难去选择知识图谱工具。

当然，这里的数据量大或者复杂，实际上又是相对于时间的紧急性。

antv在Graph Insight的早期应用案例中，重点突出的就是一个反洗钱的应用场景。

分析这个应用场景，你会发现这个场景非常符合前面所说的不可能三角。

由此展开，我们会发现，图谱的应用往往在需要应付紧急突发事件的时候特别合适。

因为紧急，所以平时看起来少的数据，就会变多，平时看起来简单的关系，就会变的复杂。

而图谱这个工具，在这个紧急的时候，就提供了一个直观的可视化手段，以最快的速度去梳理关系，找到关键节点。

这只是图谱应用的极端情况，在大部分实际应用中，不可能紧急到这种程度。

就以我最近所做的项目为例，客户属于教育科研行业的。

他们对图谱有一定的了解，但是由于他们缺乏对关系数据分析的紧迫性，所以图谱的应用对他们来说可有可无。

毕竟时间可以冲淡一切，数据再多再复杂，只要有足够的时间，也会变得简单而少。

所以，在这些客户的眼里，图谱就变成了一种科技属性的加成，只要在项目里加上图谱，项目立马就变成了高科技项目。

所以在项目里就会出现这样一些奇葩的应用形式：

例如明明可以用列表形式展示的数据，就一定要用图谱。把一个作者相关的作品都展现的图谱里，虽然关系有很多种，但是大部分节点都只跟一个中心节点有关系，最后的结果就是一个菊花形的图案。

例如在图谱里加上时间轴，还要求节点的位置和时间轴上时间相对应。

例如在展示数据的时候 ，希望以树型结构展示，却又希望子节点能同时和其他父节点建立关系，更可怕的是，子节点还要翻页。

以上的种种，都建立在需求的提出者的两个错误上，第一，他们不知道如何用图谱来展示关系，第二，他们天真的以为图谱可以用来研究关系。

图谱最大的作用是用来展示关系。

那问题是，简单的关系还需要用图谱来展示吗？

在第一个例子中，我们需要了解一个作者创作或者参与创作的作品时，只要一个简单的表格就可以了，如果一定要放在图谱里，合适吗？

或者我们需要了解一个作品有多少人一起参与创作时，也只要一个简单的表格就可以了。

但是如果我们需要了解一个作品的创作者们是否同时参与了其他作品的创作，或者我们需要了解一个作品的参与者是不是同乡、同事或者同学时，图谱的作用就很大了。

越是复杂的关系，就越需要图谱来进行展示。

与此相对的一个结论就是，图谱的数据量是有范围的，往往数据量越大就越不要用图谱来进行展示。

想象一下，一个图谱里有三千个节点，每个节点都至少和十个节点存在关系，这样的图谱有任何意义吗？

除了一堆乱麻，你能看出什么？

这样的图谱数据就不应该被计算出来。

在这样一个混乱的数据库里，我们真正应该做的是，给出起点和终点，限定途径节点的数量，然后找出所有可能的路径，最后在图谱里展示起点和终点之间的关系。

这就是我想说的，图谱最大的作用是展示关系，不是研究关系。

诚然，我们不能否认，在展示关系的过程里，我们是可以得到帮助，发现实体之间的潜在关系，但是只要这种潜在关系是完全客观的，那就一定可以用代码来实现，而不是靠人自己判断。

反之，如果这种潜在关系是主观的，不可以用代码来发现，那图谱的意义又何在呢？

如果关系的厘清需要使用者自己的主观判断，那么图谱的数据应该是使用者自己来创建生成，建立在代码基础上的图谱是不可能帮使用者建立关系的。

如果关系的厘清是完全客观的，是有规律的，那么拿到数据，相关的应用就可以得到使用者想要展示的关系，图谱并不需要去处理数据，图谱也不太可能展示出你意想不到的关系。

但是，在实际的开发过程里，我们经常会碰到需求的提出者（当然，不一定是客户），会提出种种匪夷所思的需求，既要***又要***，还不想付出任何代价。

包括但不限于：

既想展示大量数据，又想数据关系清晰。

既想数据关系简单，又想图谱能看起来有用。

既想图谱严谨可靠的展示数据，又想图谱能够自由定制。

既想图谱按照这种形式展示数据，又想图谱同时可以按照另一种形式展示数据。

还有既想分页又不想分页的矛盾心理，就不一一举出了。

正如我之前所说，这些需求都是因为根本不知道图谱如何在实际中应用导致的，之所以如此，又是因为他们根本不愿意去了解或者理解图谱，他们从一开始就对图谱又了不切实际的想法，认为图谱有很高的技术含量，觉得这是大数据时代必须掌握的技术。

图谱究其本质，就是对数据进行抽象、整理和分析，最终得到关系数据，再通过某种形式表现出来。

在这个过程里，最重要的是数据的抽象、整理和分析，并不是表现的手段。

而现在中国之所以还不能对图谱进行广泛的应用，就是因为大部分使用者把图谱当成一种纯粹的数据可视化手段，却忽略了数据分析这个基础。

再好的形式和手段，没有基础，都是无源之水，无本之木。

中国的知识图谱应用，不缺开发人员，缺少的是真正理解知识图谱的决策者。