商品知识图谱的构建思路
在现实生活中，要理解一段语言，除了语言本身的意思，一般还要结合上下文语境，以及相关的背景知识。
用计算机处理自然语言，也是类似的思路。其中一个难点是，如何把知识结构化，从而让算法模型能根据背景知识进行推断。
例如，在电商背景下，一个用户搜索“豆豆鞋”。我们希望模型不仅能识别用户要买鞋，还要推断出这种鞋适合的人群、场景等相关信息。
把知识进行表征常用两种方式：一是知识图谱，通过图的方式表达知识的结构；二是向量，把知识用有限维的向量来表达。
这两种方式并不是割裂的，我们可以用向量构建知识图谱，也可以把知识图谱向量化。本文主要介绍电商领域知识图谱的构建方法。
知识图谱
知识图谱由三要素构成：实体、属性和关系。
实体：它可以是具体的人、事、物，也可以是抽象的概念，如风格、性别。 属性：用来描述实体，包含属性名和属性值。 关系：实体之间的联系。关系本身也可以有“属性”。
实体、属性和关系的划分没有严格的标准，一般基于场景进行考虑。例如，程序员是一种职业，它可以作为实体，也可以当作一个实体的属性，还可以是实体与实体之间的关系（如下图所示）。
在电商业务中，用户和商品是核心，可以把他们作为实体。传统的用户画像和商品画像就是通过标签化的方式描述这两类实体。
知识图谱可以基于画像系统，考虑标签之间的关系，抽象出概念实体，从而打通用户与商品之间的联系。
例如，在用户画像中，存在属性<父母>；在商品画像中，存在属性<母婴>。我们创建<奶爸奶妈>这样的实体，然后把母婴类的商品和父母联系起来。
电商图谱的设计
接下来我们围绕商品构建知识图谱，主要用于客服机器人中的商品知识问答。
为了方便管理实体，我们通过“域”的概念对实体分类。每个实体域中，通过“类型”对实体进一步细分。例如，可以根据类目、商品、评价、促销这几个维度来构建。
类目域
实体：商品的类目，比如服装、美食、居家。 类型：商品的类目有多个层级，比如一级、二级、三级、四级、五级类目。 关系：类目之间如果存在包含关系，用“上位”和“下位”表示。例如，二级类目的上位是一级类目，二级类目的下位是三级类目。
商品域
实体：商品 类型：商品分为普通商品和组合商品（套装）。 关系：普通商品与组合商品之间存在成分关系。
评价域
实体：评价 类型：评价 关系：无
促销域
实体：促销玩法 类型：促销活动类型，比如满减、满折、N元任选等。 关系：无
介绍完域中的实体和关系，接下来还要把域之间的实体联系起来。即，定义跨域实体之间的关系：
类目域-商品域：包含关系 品牌域-商品域：包含关系 商品域-评价域：评价关系 商品域-促销域：参与关系
示意图如下所示：
商品知识构建
设计好了商品知识图谱的框架，下一步是基于现有的业务数据去构建图谱。一般会用到以下技术：归一化、实体识别（NER）、实体链接、关系挖掘。
如前文描述，实体主要是商品和类目，通过 ID 进行链接，而且关系已定义好。这样一来，构建图谱的主要工作是实体的识别和归一化。
数据主要分为结构化数据和非结构化数据。以商品数据为例，结构化数据主要是一些属性和标签。非结构化数据有商品标题、商品详情页、卖点文案、用户评论、搜索词、咨询问答等。
值得注意的是，数据加工需要成本，因此要考虑投入产出比。在实际业务中，建议根据业务场景和实际需求挖掘数据和构造知识图谱。
归一化
以商品标签为例，其属性名称可能存在同义词。例如，"适用群体"与“适用人群”、“材质”与“材料”等。虽然表述不同，但是描述的是同一个意思，我们需要识别这些同义词，然后对属性名称标准化。
我们基于属性名和属性值，用 word2vec 训练词向量，再用层次聚类对属性名聚类。经过人工审核，构建属性名同义词词典，最后对属性名进行规范化。
实体识别
下面我们以商品知识、商品文案和搜索词为例，介绍如何挖掘商品信息，并识别其中的实体。
商品知识
客服的知识库系统记录了商品知识，主要是通过 QA 对的方式记录，例如：
Q: 产品的主要材质是什么?
A: 德国拜耳TPU。
可以用深度神经网络模型（BERT + 微调），识别出商品实体、属性名和属性值。
对于上面的例子，模型识别出的属性名是“材质”，回答的内容作为属性值。
商品文案
对于商品标题和卖点文案中，我们也训练了类似的识别模型。
例如，商品标题为 女式轻弹慢跑运动鞋，模型的解析结果为：
{
"适用性别": ["女式"],
"适用场景": ["慢跑"],
"物种": ["运动鞋"]
}
搜索词
虽然用户的搜索词不一定反映商品的真实信息，但是结合用户的浏览行为，可以挖掘到一些主观知识，比如适用场景、风格、人群等。
挖掘的思路如下：
基于用户点击行为，构建搜索词到商品的映射； 训练实体识别的模型，识别搜索词中出现的主观知识； 设计规则与原有知识进行融合。
需要注意的是，算法模型挖掘出的知识可能与原有知识存在矛盾的地方。这种情况下，需要人工进行干预。
例如，原有知识的适用性别为“女性”，算法挖掘结果却是“男性”。原因可能是某些用户帮别人下单，或许商品本身是偏中性的。
图谱的存储
知识图谱的存储方式主要有两种：RDF (Resource Description Framework) 和 LPG (Labeled Property Graph)。
知识图谱是一种知识表示结构，不依赖具体的存储方式。在一些场景下，甚至可以把数据存储在传统的关系数据库中。一般来说，使用图数据库有更好的查询性能。
我们用 neo4j 单机版存储，做了个简单的性能测试（如下）。
图谱规模：实体数量 10万，关系数量 22万 虚拟机：CPU 8核，内存 32G
测试语句：单实体查询
match (n:`商品`) where n.origin_id='${origin_id}' and n.type='${type}' return n
测试性能：2.2w qps 机器状况：CPU使用率：45.6%；load：5.3
测试语句：多跳查询
match (n)-[:下位|:包含*1..6]->(m:`商品` {origin_id:'${origin_id}'}) return n
测试性能：1,7w qps 机器状况：CPU使用率：61%；load：6
总结
本文介绍了知识图谱的基本概念和构建思路。在实际应用中，为了保证知识图谱的可靠性，还需要人工进行审核，因此构建知识图谱有一定的成本。
商品的知识图谱除了可以用在智能客服，还可以用于个性化推荐等其他业务场景中。在具体使用中，可以把知识图谱向量化，作为其他模型的输入，从而支持更多的业务场景。