知识图谱对于产品经理的工作有着很大的帮助，能够建立更系统的设计流程，其应用核心在于深刻理解业务。
一、什么是知识图谱
1.1 知识图谱的定义
知识图谱概念开始由谷歌公司（Google）提出，为了提升搜索引擎返回的答案质量，通过知识图谱的构建，去发现用户查询文本背后的语义信息，从而返回更准确的信息。
我们以李小龙为例，如果不用知识图谱，用户搜索“李小龙的儿子是谁”时，只能通过关键词搜索的方式分析网页中关键词包含“李小龙”“儿子”等关键词的网页。
但是，通过知识图谱搜索，可以精确搜索出准确答案，我们以搜狗搜索为例（见图1.1-1）：
图1.1-1 搜狗搜索结果
我们在搜索“李小龙的儿子是谁”的时候，首先会对这个文本进行语义识别，识别出来一个实体“李小龙”一个关系“儿子”，然后通过关系图谱就会精确查到实体与关系的指向（见图1.1-2），最终完成精确的检索。
通过知识图谱的辅助，搜索引擎通过背后的语义分析，返回更加精确，并且是结构化的数据。
图1.1-2李小龙的关系图谱
追本溯源知识图谱起源于上世纪60年代的语义网络。
语义网络（Semantic Network），是一种以网络格式表达人类知识构造的形式。它是由结点和结点之间的弧组成，结点表示概念(事件、事物)，弧表示它们之间的关系。
语义网络是一种比较早的知识表达形式，它是一个带标示的有向图，各个节点表示知识中的物体、概念、实物等，点与点之间的链接。
“谁是谁的什么”的指向性关联关系，与语义网络类似，在知识图谱领域，是一些相互连接的实体以及属性构成。
所以，知识图谱本质上是语义网络，是一种基于图的数据结构。
因此从数据角度来看，知识图谱通过对结构化数据、非结构化数据、半结构化数据进行处理、抽取、整合，转化成“实体-关系-实体”（见图1.1-3）的三元组，然后聚合大量知识，实现快速的响应。
从应用层面来看，知识图谱是用来描述真实世界中存在的实体，以及他们之间的关系。
图1.1-3 三元组案例
从不同视角，基于图1.1-3的案例，我们来看一下知识图谱在不同技术的理解。
从互联网视角来看，跟文本之间的超链接一样，通过图谱建立数据之间的语义链接。比如，张三的妻子是李四，通过图数据方式支持实体、实体之间的关系的检索。
从自然语言处理的角度来看，如何从非结构化数据、半结构化数据中提取数据，抽取其中的语义。比如，我们拿到张三的简历，简历上写出生地是河北，通过提取规则来获取到“张三”、“河北”这两个实体，以及“籍贯”这个关系，并机构化存储起来。
从人工智能视角来看，如何利用知识图谱来辅助理解人类的语言，并进行相应关系的查询和机器的推理。
1.2 知识图谱的表示与存储
我们了解了知识图谱的概念，那么知识图谱是如何存储知识数据以及如何呈现出来的？作为产品经理理解知识图谱的表示与存储对我们有什么意义呢？这些问题将在本章中进行解释与回答。
1.2.1 知识图谱的表示
所谓知识图谱的表示，是指计算机通过何种方式来表达真实世界中包含的知识数据。
知识图谱本质上就是语义网络的知识库，因此我们可以简单把知识图谱的表示理解为多关系图，基于向量空间学习的分布式知识表示。
我们知道图是由点和边来构成的。那在知识图谱中，用“实体”来表达图中的点，用“关系”来表单不同点之间的联系，例如图1.1-3，其中的圆形的代表实体，点与点之间的连线是叫关系。
实体是现实世界中的事物，比如人名、地名、公司名、药品名称、专业知识概念、在某些场景下年龄、性别等都可以作为实体；关系是不同实体之间的真实联系，比如李四是张三的妻子，张三的籍贯是河北等，里面的妻子、籍贯都是真实世界中的关系。
在现实世界社交网络中，我们可以找到好多实体，比图某某人、某某公司、某某人手机号、某某公司注册地址等都可以作为实体数据。实体与实体之间的关系也不是一成不变的，比如人与工作岗位的关系，并不是一成不变的，是根据人的工作年限，努力程度，其工作岗位会有变动。因此人与工作岗位的关系中可以有曾任职、现任职等关系，案例看图1.2-1。
图1.2-1 某企业信用查询APP关于企业关系的图谱
某某企业与某某企业间的参股关系；
某某企业与某某人间的职位（总经理、董事长、董事等）关系；
某某企业与某某人间的参股关系。
因此我们可以从图中得知某某人、某某企业是实体；参股、总经理、董事长、监事等是关系。
知识图谱处理表达的实体与实体间的关三元组是知识图谱的核心。除此之外，可以表达实体的某些属性，可以通过属性图来表达，比如某某人的出生日期、比如某某人的曾用名、比如某某人的介绍等。
因此，知识图谱整体来说，是通过图数据的形式，来表达实体与实体间的关系，实体的相关属性的值。
1.2.2 知识图谱的存储
通过知识图谱的表示，可以很直观看到知识图谱包含的知识数据，对于理解知识图谱的存储有很好的促进作用。
知识图谱主要有两种存储方式：
基于RDF的存储；
基于图数据库的存储。
由于RDF以三元组的方式来存储数据而且不包含属性信息，图数据库一般以属性图为基本的表示方式，常用Neo4j。因此所以实体和关系可以包含属性，能更容易表达现实的业务场景。
知识图谱的原始数据类型一般来说有三类：
结构化数据：如关系数据库；
非结构化数据：图片、PDF、视频、音频、文本等；
半结构化数据：百科知识、JSON、XML等。
从以上数据中提取实体、关系、属性以及属性值。
做后台产品经理的，对关系型数据库并不陌生，有人会问了，按照图1.1-3不一定通过知识图谱通过关系图谱也可以达到效果了，比如建一个人员基本信息表，建一个用户间家庭关系，也可以查询到，如图1.2-2。
图1.2-2 二维表关系表示
那么，知识图谱图数据存储方式到底跟关系型数据库道理有什么区别呢？
其实，关系型数据存储方式与图数据存储方式之间的作用不是非此即彼的，是相互配合使用的，根据不同的业务场景来使用。
图数据多关系的建模，关系型数据库是不同表之间的关系，如果关系太多对关系型数据库并不是很友好。在图数据库中可以把籍贯、职业拆分出来一个关系。
不仅如此，如果我们把身份证号作为一个实体，那么姓名、曾用名等都可以查分出来一个关系，这个是关系型数据库难以做到的。
因此。图数据库更加适用于通过实体的分析找到对业务有力的更多的关系。比如，我们把籍贯的地址可以拆出来多个关系，现居住地、曾居住地、出生地等，同样一个实体（河北）其实可以拆出来三种关系来满足不同业务场景。
因此，知识图谱更加关注关系，更加关注一些隐含的关系、序时变动的动态关系。当然，多关系的查询图数据的性能更好。
关系型数据库更是对数据的记录，更多适用于一些业务流程数据，比如电商里面的订单销售数据、合同数据、结算数据等，能够记录、反应、分析基本业务要求与场景。
而图数据更多是配合业务要求，去辅助业务，比如订单销售数据中记录了用户买的什么产品这一事实，我们可以通过统计功能做一些业务分析。
但是如果做一些个性化推荐工作，我们可以通过图数据的方式，通过用户信息和产品某些特性之间建立关系，可以为客户提供个性化的推荐方案——也就是说图数据存储方式可以帮助系统实现推理的功能。
比如，姚明是一个篮球运动员，我们知道篮球运动员有一个属性就是身材都比较高。当你问系统姚明身高的时候，系统可以通过姚明与篮球远动员的关系，通过篮球运动员的属性来推理出姚明身高——这也是图数据库存储数据应用的一个最重要的作用。
1.2.3 理解知识图谱的表示和存储对产品经理的意义
对于理解知识图谱的表示和存储对产品经理最重要的意义就是根据业务需求，定义实体、关系、属性以及属性值。
做后台产品经理我们都知道，我们在设计产品功能的时候，有四个基本对象需要设计：
存储数据的字段；
梳理业务的流程；
规则设计（业务规则、输入规则、逻辑规则等）；
页面交互的设计。
其中字段设计是其中最基础的部分，是我们后台设计最核心的部分。
首先，我们设计后台系统展现的表单信息来源于字段设计、业务流程中体现的业务信息载体是字段设计、规则设计中相关规则控制对象也是字段，因此设计好字段是后台产品设计最基础也是最核心的工作。
字段维度涉及如下维度：
字段所属对象，就像后台按照模块分类一样 ，字段也有所属对象的分类，比如商品、用户、订单、结算单、提现单、红包、奖励券、客户等，这些对象是字段承载的载体。
字段值类型，字段值类型常用的包括字符串（比较常用）、枚举（审核状态、是否项目等）、日期时间、浮点数（金额类型，定义小数点后位数，小数点前位数）、数字（正整数、是否可以为负等）。
字段是否必填，这个是指字段在写入值的时候是必须有值的还是可以为空，比如新增一个商品，商品编码、商品名称是必填，商品关键字可以为空等。
字段值来源，字段值来源是指字段在写入的时候来源于哪里，常见的包括以下几种：来源于输入（就是通过前段某一个页面通过用户输入或是选择获取的值），系统自动生成（比如创建时间、业务编号等字段）；来源于其他数据（比如订单里面的商品编码字段，就来源商品里面的商品编码字段）。
字段值长度，字段值长度是存储在数据库中值的最长长度是多少，比如字符串类型，可以规定长度32位，这个一般根据业务需求制定的一个最长长度，便于开发设计表结构。当你的数据项很清晰的时候，对于开发人员的理解业务、设计都有很好的促进作用。
我们做任何功能的设计，对数据的设计永远是第一步。
对知识图谱也一样，我们要明确出来储存哪些实体，建立哪些关系，哪些是属性，属性值是什么。
比如，防欺诈系统中，如果发现两个不同的用户拥有了同一个手机号或是居住地址，并且两者没有任何家庭关系的时候，我们就认为这是一个具有欺诈行为的用户（因为一般用户和手机号是一对多的，手机号对用户是一对一的，一个手机号不太可能给两个用户使用）。
这时我们会把手机号、姓名、身份证号、地域作为实体，然后建立联系方式、身份信息隶属、居住地、家庭关系等相关关系，通过手机号、姓名的联系方式关系查询一目了然。
因此，图谱的使用也离不开产品经理对业务的深入理解，在深入理解的前提下，正确识别实体、关系、属性等图数据基本存储方式。对于开发对业务的理解、开发的设计也是有相同的促进作用。
所以，理解知识图谱的存储与表示，能更好帮助产品经理定义知识图谱，定义实体、关系、属性以及属性值。
1.3 知识图谱构建过程
那下面我们简单描述一下如何构建知识图谱，以及了解如何构建知识图谱对我们产品经理有什么帮助。
1.3.1 知识图谱的逻辑架构
在了解知识图谱构建流程之前，我们先了解一下其逻辑架构。
知识图谱在逻辑上分为模式层和数据层：
模式层：是知识图谱的核心，是构建在数据层之上，也就是定义通用概念为实体、实体键的关系，也成构建本体库，也就是指的实体-关系-实体，实体-属性-性值。
数据层：是知识图谱的事实数据，以相关事实为单位进行存储，比如张三——妻子——李四；张三——出生年份——1985等。
1.3.2 知识图谱构建流程
知识图谱的构建是后续应用的基础，知识图谱确定了本体库，就需要对知识图谱的数据进行构建。具体构建过程包含3个阶段：信息抽取、知识融合、知识加工。
1）信息抽取
从各种数据源中进行实体识别、关系识别，从而抽取实体、关系、属性以及实体间的关系，属性的值，完成本体的知识表达，具体可以参照前文关于知识库的表达部分。
对于知识图谱来说，数据源我们知道有结构化数据，非结构化数据和半结构化数据。
数据渠道一般是三种：
业务的关系数据，这些数据通常包含在公司内数据库中；一般是结构化数据，或者是系统交互中Jison数据，虽然没有结构化，但是仍然可以通过功能进行存储，这种数据一般定义好本体库可以直接使用；
网上公开发布的可以抓取的数据，通常以网页形式存在，这种一般要通过爬虫技术，通过本体库相关关键词进行数据的爬取并结构化；
相关合同、文件等，比如一些保险合同、电子发票信息等；这种一般需要自然语言处理技术，进行数据信息的结构化提取。
信息的抽取是知识图谱构建的第一步，关键的点是：如何从数据源中自动抽取到实体、关系、以及属性等机构化技术。
实体抽取又称为实体识别，就是从文本中自动识别出来命名的实体，它是信息抽取中最基础的部分。
关系抽取就是进行语义的识别，抽取到实体间的关系，这个是信息抽取中最关键的部分，也是形成网状知识结构的基础。
关系的识别运用到各种算法模型以及机器学习的方法，属性抽取实现的是实体属性的完整勾勒。
2）知识融合
主要是新知识的融合、整合、判别同义、近义、消除歧义、矛盾。
比如，某些实体数据在显示世界中有多种表达方式，公司的注册名称、公司的简称等，要对这些知识进行同义融合，再比如某些特定的称谓也许对应着多个不同的实体。
知识融合包括两部分：实体链接和知识合并。
实体链接：是指对于从文本中抽取得到的实体对象，将其链接到知识库中对应的正确实体对象的操作。一般是从知识库中选中一些候选的对象，然后通过相似度将指定对象链接到正确的实体。流程如下：通过实体抽取获取实体指称项——通过实体消歧（解决同名实体歧义）和共指消解（多个指称指向同一实体进行相应的合并）——将实体指称链接到知识库对应实体。
知识合并：从第三方知识库产品或是已有的结构化数据中进行知识的获取，一般是合并外部知识库和和合并关系数据库，合并中要避免实体与关系的冲突问题，防止不必要的冗余。
3）知识加工
某些知识需要进行质量评估，并且有些还需要人工介入与甄别，并进行数据修正，然后再将正确的数据加入到知识库中，保证其中的质量。
知识加工主要包含：本体构建、知识推理和质量评估。
我们从数据源中通过信息的抽取、实体、关系的识别，相关异常数据融合后，我们可以构建本体库了。
但是构建完本体库后，算是雏形搭建好了，有关系可能存在残缺，这时候我们就可以运用推理技术，完成进一步知识的发现。比如A是B的配偶，B是生活在C城市。如果我们从数据中没有提取到A和C的关系，那我们可以通过配偶关系，推理出来A也生活在C。
质量评估就是知识的可信度进行量化，对一些置信度比较低的知识进行舍弃。在处理过程中，人的参与也非常重要。
1.3.3 了解知识图谱的构建对产品经理的意义
在知识图谱构建过程中，会综合运用知识图谱存储技术、相似度算法模型、深度学习等技术方法，是不是只需要技术人员参与就可以了？
其实并不是。
相反，他需要产品经理与技术人员更加深度的合作与交流，并且在整个图谱的建设过程中都少不了产品经理的参与；在某些图谱建设过程中产品经理还处于主导作用。
当你打算构建一个知识图谱，仅仅只靠技术人员去构建是不够的，需要产品经理做出业务定义，理解业务所需要的图谱数据，指明图谱中哪些是实体，哪些是属性，实体间有什么样的关系，这些都是要由产品经理定义好的。
并且在建设图谱来看，需要产品经理与技术人员之间更加深入的交流与配合，更加要求产品懂得技术的应用流程。比如业务数据的提供、数据范围的划分，图谱提取之后的验证等。
每一步的构建过程都需要产品经理与技术人员的沟通，所以对于AI产品经理很重要的一点：理解技术，理解技术的应用，参与到技术应用过程中。
二、知识图谱应用
通过了解支持图谱是什么，知识图谱如何表示，知识图谱的构建过程之后，那么一个完整的知识图谱是如何设计的呢？
主要包含以下步骤：
定义业务需求；
数据收集与处理；
图谱数据的设计；
知识图谱的存储；
算法开发；
应用开发。
很多人都认为，构建知识图谱主要靠算法和开发，但事实最重要的是对业务需求的理解以及图谱数据的设计。
就像我们在做后台产品设计的时候，数据库表设计尤其关键，数据库表设计的数据项与业务的深入理解是紧密联系在一起的。
因此，设计知识图谱跟我们产品经理设计其他产品一样：理解业务，设计数据字段。
图2-1借鉴李文哲对知识图谱构建理解
通过上图我们知道，一个知识图谱的构建最重要的是业务理解、图谱数据的设计，这恰恰是产品经理需要主导的设计工作。
因此下文将重点介绍一下定义业务需求、数据收集与处理以及图数据的设计。
2.1 定义业务需求
在知识图谱中定义业务需求主要是两方面：
1）要解决什么问题
这个跟咱们做前端、后台产品经理一样，我们可以通过理解业务流程、数据字段的梳理、通过原型交互的实现来实现我们的业务需求。知识图谱也一样，图谱也有上层应用，比如问答机器人、个性化推荐等，通过一定应用介质实现需求的输入和输出。
2）解决这个问题，是否需要使用知识图谱？
回答这个问题就是需要我们在设计需求的时候，我们通过什么样的数据存储就可以解决我们的业务需求。实际上有时候我们完成业务需求的时候，用关系型的数据库就可以完成，那么我们也就不需要知识图谱了。
什么样的需求可以用知识图谱呢？
要想解决这个问题，就需要我们深入理解数据的存储方式，目前数据存储的设计主要是关系型数据库和知识图谱型的数据存储。因此了解需求所需要的数据，以及数据的使用方式，是判定是否使用知识图谱最好的方法。
知识图谱对比关系型数据库，最大的功能是数据间的多关系应用，一般知识图谱数据存储方式解决的是多关系以及关系间的深度搜搜、对关系的查询实时性要求、多样化的数据以及数据孤岛的问题。
当然，处理关系深度需求需要知识图谱之外，我们知道知识图谱还有一个推理的作用，因此涉及到推理的需求也可以考虑知识图谱。
2.1.1 关系需求
关系需求，就是说需求设计到数据间多关系的查询，多关系的应用，可以考虑知识图谱。
那么，具体什么样的关系可以通过知识图谱呢？以下提供两个思路给予借鉴：
1）某一数据存在与多实体产生关系
某一数据存在与多实体产生关系，是指某一项数据跟多个实体间有关系，这样通过这一条数据的查找可以找到相关实体的数据。
比如，我们把一个年龄数据做成一个实体，实体是30周岁，张三年龄是30周岁，某一款产品试用范围是10-50周岁；如果我们通过这个人的年龄查找这个产品，我们可以建立两个实体间的关系，一个是人的年龄关系，一个是产品适用年龄关系，这样就能很快查找到。
多实体间多关系查找实体，是指一个实体与另一个实体的时候，存在多个关系，通过多个关系去查找另一个实体。
比如，人、出生地、年龄之间有三个实体、两个关系，某一款产品、售卖地区、适用年龄也是三个实体两个关系；通过人的出生地、年龄实体数据以及关系，可以相应查到这个售卖地区、适用年龄的某款产品。
因此我们可以发现知识图谱能解决数据间多关系、深层次关系的实体查询。
2.1.2 推理需求
知识图谱不仅仅是根据关系的检索，更大的核心用途是推理，发现图谱中的隐藏关系，而不是发现新知识。
1）通过实体间的关系推理相关关系
通过多实体间的关系，可以推断其他的关系，比如张三和李四之间是夫妻关系，王五是张三的领导，王五居住在A城市，我们可以推论李四也居住在A城市。
2）通过实体间的关系推理相关属性
通过多实体间的关系，实体的属性值，可以推断其实体的属性值。这个与通过实体间的关系推论关系道理类似，也可以通过一个实体间的关系、根据实体的属性推断另一个实体的属性。
在AI中涉及到推理的方法有很多，有基于逻辑的推理，有基于深度学习的推——这个就是基于图谱的推理，也就是通过关系、属性的因素做的推理。
2.2 数据的收集与处理
定义好业务需求，就得根据业务需求找相关的数据。
我们在知识图谱的构建过程中关于信息的提取，介绍过都可以用那些数据，这里重点介绍我们在收集数据的时候如何跟技术同事配合。
2.2.1 结构化数据
结构化数据是知识图谱最信赖的数据，通常来自于我们业务系统产生的数据，比如一些用户画像数据、销售数据、合同数据、资源数据、财务数据等。
凡是已经结构化的关系型数据，我们都可以结合业务的需求，来判定是否需要加入知识图谱中，对于这些数据我们如何提供给技术同事呢？
很简单，我们通过EXCEL表就可以了，只要告诉结构化数据中哪些需要写入到图谱中就可以了。
2.2.2 半结构化数据
半结构化数据要考虑两点：
在开发资源中没有存储在结构化数据数据库中，但是存在Jison中的数据，这些可以通过开发能力解析Jison中的数据，结构化到知识图谱中；
通过数据爬虫的方式，爬虫工程师在网页上爬去相关的数据，这需要产品经理指明爬取的网页、网页的哪些数据项、这些数据项拆分哪些字段，先形成结构化数据，然后在计入到知识图谱中。
2.2.3 非结构化数据
非结构化数据主要是一些文档、文件等，比如一些合同文件、文章、PDF文档等，需要产品经理明确好要提取这些文档哪些知识、提取规则，在通过算法识别、提取、训练等提取成结构化数据，然后计入到知识图谱中。
2.3 图谱数据的设计
我们拿到了数据，就要开始知识图谱的设计了。设计知识图谱不仅需要对业务有很深的理解，也需要考虑图谱的实用性、高效性。
设计知识图谱主要是设计知识图谱的三元组，也就是哪些数据是实体、哪些数据是属性、实体之间有什么关系。这个在设计过程中需要很深入的理解，要根据业务需求去设计。
在这里提一点：实体是数据不是一个类，比如产品不是实体，一个具体的产品名称是一个实体；属性也是一样，是一个具体的值，比如性别不是属性，男、女才是属性值；只有关系是一个类，比如人的年龄，年龄就是一个关系。
除此之外，知识图谱设计的艺术性还体现在，实体和属性在不同业务要求下，可以有不同的定义。
有些实体可以作为属性，有些属性可以作为实体，也要具体看业务需求。比如，年龄数据，如果不需要跟其他实体产生关系可以作为属性；如果需要产生关系，就要作为实体。
在设计图谱的时候，还要把握哪些数据是冗余的、不需要的。因此，作为产品经理在做知识图谱的设计的时候，最重要的就是这个三元组的设计。
