[NLP]Graph Learning: 一种数据组织观点

对于知识图谱的构建，从非结构化数据中构建，知识的价值更高，但是对信息抽取能力的要求也更高；从结构化数据中构建，可以弱化对信息抽取能力的要求，转而将重心放在应用层，这对于一个有大量结构化数据积累的团队而言，是非常有吸引力的。

为了讲清楚图数据库和传统关系型数据库有啥区别？从一个具体例子出发。

简单而言，ER图的设计和Schema设计对应，SQL和Cypher对应，关系表和图对应。

传统关系表更像是一个个挺立的烟囱，每个烟囱中装载同一种类型的数据。而图则爆破了这些烟囱，将所有数据拉平到一个巨大的平面上。

那么，为啥要研究KG/GL呢？从一些具体的应用场景出发来看，如下：

这里给出一个Cypher相对于SQL在查询上更具优势表现的例子：

左上角是完美世界的产品：全历史的工作，右上角是个人非常喜欢的工作Magi（2019年的工作），左下角是组里小姐姐研究生期间参与的一个比较大的项目（华谱网）的具体例子。

那么，一个知识查询服务，要具有什么样的特点呢？

知识查询服务意味着图构建本身就可以产生价值。除此之外，也有其他的一些应用场景，如下：

总结一下，如下：

说了这么多的场景，那么怎么用呢？这里先给出一个该方向知识体系的脉络图。左图来自THU的唐杰老师组梳理的一个脉络图，右图是比较常见的一张NLP的milestone图。

从上述体系上观察，主要重点关注的工作有三个方面，这里用三张PPT分别简要介绍各个方向上的代表性工作。

在读了大量相关方向上的资料之后，得出的一些比较宏观的观点，如下：

最后，聊一聊我们自己的工作吧。目前已经做过的包括基于结构化和非结构化的数据做图谱构建，具体为电商领域美妆行业的知识图谱。

关于上述描述的问题，在博客电商域图谱构建-问题复盘中有更加具体的阐述，这里不再瞎BB了。基于结构化数据的图谱构建，目前的图谱规模如下：

基于上述工作，即将展开的研究内容如下：

最后，总结一些基于结构化数据图谱构建的一些问题和注意点，如下：

（1）做一个好的SQL Boy吧（逃）。基于结构化数据构建的核心环节在于写SQL。

（2）DataFrame要用的6。基于SQL获取的数据能解决大部分问题，但是需要用DataFrame对这些得到的数据做二次加工，需要Join/Merge/Concat，需要去重，去空，分组等基本功能。

（3）人工参与不能避免。

（4）慢工出细活。整体上是一个非常细致的工作，要求对表，数据，属性，字符串等处理，数据处理的工作，不难但是步骤多，由此很容易导致某个步骤遗漏。数据的问题在小规模下不暴露，在大规模下就会暴露，是因为错误情况很难在没有看到数据的情况下想到，耐心一些吧。

（5）大规模数据处理需要工程优化。

（6）数据的问题，尤其要注意错误数据和遗漏数据，因为在图谱构建的最终结果中，这部分是需要被验证的，系统不会报错的。

接下来我们的工作会重点转向应用层，希望对该方向上的工作有进一步的理解和认识吧。

PPT链接: https://pan.baidu.com/s/1xob-iFB9kR5Ku1p69VkWGg

提取码: 3h2b