相较通用知识图谱而言，行业知识图谱具备以下几个特点：
- 第一，领域性更强，能具体到某一个行业细分问题。
- 第二，数据来源更加复杂，包括企业的数据库、日志、文本报告等数据。
- 第三，规模非常大，一般来说，明略科技构建的行业知识图谱规模都在百亿规模以上。
- 第四，对实时性和数据质量的要求非常高，因为要依赖于知识图谱做分析决策。
- 第五，需结合行业知识搭建更多的复杂行业应用。
行业知识图谱的落地，存在不少技术挑战。
比如，要对海量多源异构数据做数据融合，构建知识图谱。再如，解决大规模知识图谱的存储计算问题。此外，要把数据转化成为真正的行业知识，满足行业应用的需求。
为了帮助客户更高效地沉淀行业知识，指导实际业务，明略科技从知识图谱的构建、存储到应用，形成了一套成熟的产品体系，其核心技术包括，基于智能化文本挖掘技术的文本抽取，智能数据字段识别和映射结构化抽取，以及最核心的混合存储的知识图谱系统，用于支撑应用层的社区挖掘、群体的分析，智能问答。
二、行业知识图谱构建的关键步骤
尽管数据可能有各种各样的形式和来源，但行业知识图谱构建可以抽象成为几个关键的步骤，包括图谱建模、数据接入、图谱映射、图谱元素抽取、图谱融合。
例如，一张表格中有人的信息、户口的信息。假设需要定义人物关系、亲属关系这类图谱模型，需从表格数据里读取相关信息，把不同的数据列映射到图谱模式的属性，根据这个映射，从数据源抽取数据，形成实体关系结果。从不同数据源抽取的数据，可能会存在相同的元素，比如，有两个叫张三的人，要考虑进行数据融合，保障图谱的融合统一性。
(一) 图谱建模与数据接入
图谱建模是非常关键的环节，与业务紧密相关，往往需要结合客户的特定业务场景去定义图谱中需要包含哪些实体属性和关系类型。
明略科技采取了界面化的方式，简化图谱建模，快速定义图谱结构。
知识图谱构建涉及两大数据类型，结构化和非结构化数据。
对于结构化数据来说，明略科技认为一个端到端的图谱构建工具，需要满足一些基本要求：
- 首先，能够对接各种各样的结构化数据源。因为数据会有各种各样的数据质量问题，所以这个工具应该具备很灵活的数据清洗和标准化的能力。
- 其次，具备高效、灵活、便捷的图谱映射和融合功能。
- 第三，具备支持增量流式图谱构建的能力。
因此，明略科技基于以上原则打造了图谱构建工具，解决数据清洗问题，用户可进行二次开发和拓展，以及最细粒度的字段级融合策略的定义。
在行业知识图谱落地过程中，虽然结构化数据占了大部分的数据来源，但文本这类非结构化数据是对结构化数据的重要补充，从文本构建知识图谱，一些常见技术包括命名实体识别、关系抽取、指代消解、实体链接等。比如，张某某一天在北京盗取了一辆车。可通过命名实体识别出有没有实体词、地域、车等，通过关系抽取建立实体词之间的关联，指代消解和实体链接，则能将提取出来的实体词进行标准化，反映到实体。
对于文本数据而言，不缺数据，但缺标注数据，是行业知识图谱落地过程中的普遍现状。而文本处理所需的 NLP 技术需要模型支撑，所以能否提供模型是一个很大的问题。明略科技针对这个问题，研发了一款高效的文本标注工具 Raptor，帮助用户借助规则以及机器学习、深度学习等技术，加速标注过程。在过程中，可以积累训练的语料，以及通过主动学习的方式，不断提高训练出来的模型的准确率。
(二) 图谱映射
在构建图谱过程中，很多时候需要从成百上千张源表数据中构建图谱。一张源表与图谱模型是多对多的关系，如果缺乏一个高效自动化工具，图谱映射效率低下且故障百出。明略科技为客户提供规则技术，保障同样的一个源表在映射过程中只配置一次映射规则，提高映射效率。然后数据分别经过批式和流式的过程处理，成为实体关系数据，最后存储到数据库。
(三) 图谱元素抽取与图谱融合
当从不同的表中抽取图谱数据时，必须考虑数据融合的问题。比如，两张表里面都抽取出来同样的一个人的数据，要考虑这两个人的数据是不是存在可融合的部分。融合的方法需要考虑数据属性，是否有重合的部分，重合的部分如何融合。
比如，表 A、表 B 都有年龄属性，两者的年龄属性并不一样，绰号属性也不一样。
对于年龄属性来说，一般选取一个比较准确的值，这时就需决定表 A、表 B 哪一个更优先，配置表级和字段级的优先顺序。
对于绰号属性来说，客户需要往往保存所有的内容去辅助更广泛的分析，所以需要定义融合的策略，比如，合并。此外客户还很关注图谱数据的一个数据来源是什么，所以在图谱构建过程中我们也会保留数据的来源信息。
三、行业知识图谱的自动构建
对于终端用户的图谱构建需求，明略科技开发了自动图谱构建工具，将一些中间构建过程自动化。
比如，用户可以上传一个通话的记录数据表，通过自动映射数据列到图谱模型元素，加速映射过程。用户只需要确认最终映射的结果是否合理，实现图谱的自动构建及入库。
在这个方案里，通过结合各种相似度的计算方式，分别针对数据的表头、数据的内容以及最后这两种相似度计算的方式进行加权融合，得到识别出来的数据实体属性，实体的唯一标识。然后在技术上结合实体的 ID 属性、图谱模型，判断覆盖率情况，选择最合理、最可能的实体类型，或者关系类型进行输出。
另外，利用 Raptor 标注工具得到的训练语料和模型，可以很方便的做到自动化构建。
- 首先，我们可以把文本中的实体关系抽取出来。
- 其次，还可以把多个文本中的实体，进行相同实体绑定，从而关联多个文本的图谱。
- 最后，把文本的实体关系与知识库的实体关系关联起来，实现全图谱的融合。
这对于明略科技的客户来说非常重要，因为他们更看重全量数据融合产生的更大的图谱价值。
整个过程，从实体识别开始，到句法分析、指代消解，再将多个子句拆分进行关系抽取和实体链接，在系统默认情况下，会内置十几种实体类型的自动识别。结合现场标注的一些数据和训练模型，可以进一步扩展可支持的实体类别。
关系抽取是从提取侯选实体对开始，利用定义好的图谱模型以及关系分类算法，进行关系分析，输出初步的关系三元组。因为我们使用的是比较简洁的属性图模型，所以还需要通过将三元组转换为属性图结果得出最终的关系数据。
对于实体链接，会根据待链接实体词从数据库中查询候选实体，然后根据侯选实体及其周边的关联实体，与待链接实体所在的文本进行相似度计算，得出侯选实体的排序推荐，用户再进行最终的选择确认。
四、大规模行业知识图谱的存储与计算
我们认为，行业知识图谱的存储需要满足几点基本要求：
- 首先，自主可控。行业知识图谱，需要及时为客户提供技术响应和支持，明略科技通过结合开源和自研软件的方案来解决这一问题。
- 第二，分布式和可扩展。明略科技采用 HBase 作为底层一个基本存储组件，ElasticSearch 作为索引的基本组件。
- 第三，高性能和高可用。明略科技以图数据库为中心，考虑行业数据的具体情况，根据场景设计存储架构，并且针对特定场景做了性能优化。
- 最后，多图谱的管理。行业知识图谱，往往不只是一个图谱，而是会根据不同的部门或者业务场景构建多个图谱，因此必须考虑多个图谱的管理需求。
为了满足以上基本要求，明略科技构建的是一个基于混合存储架构的知识图谱数据库。
第一要考虑的，图数据库的选型，最初开源方案并不多，后来才进入 JanusGraph 项目。如果现在重新考虑，我们依然会选择 JanusGraph 项目，因为它的功能比较丰富成熟，能跟大数据体系有很好的兼容（比如以 HBase 作为底层存储），另外社区生态也发展得很好。
第二，我们基于 HBase 作为底层存储和 ES 作为索引组件，HBase 是开源的一个非常好的生态项目。在应对检索需求时，我们并没有直接使用 JanusGraph 自带的 ES 查询检索功能，而是单独使用 ES 封装检索服务定义特定的索引结构，提供检索功能以满足我们图谱的丰富应用需求。
第三个存储组件是 Phoenix，我们用来存储“事件”这一种图谱数据类型。
第四，整个存储层抽象了一套数据接口层，用于对接客户事先已采购的数据库，保障计算层、应用层不受影响。
在计算层，明略科技提供 OLTP 和 OLAP 计算能力。OLTP 的计算，通过 RPC 的 API 接口和标准的 Gremlin 接口，提供在线数据服务。OLAP 计算可提供 Tinkerpop 的 Graph Computer 计算，以及使用 GraphX 图计算算法进行全图的挖掘计算。
我们在落地过程中，也遇到了很多图数据库方面的问题。
第一，读图效率。
在分布式导入性能方面，JanusGraph 它自己的 bulkload 并不是特别友好，需要用户事先定义好点的 ID，所以明略科技自己开发了一个分布式工具，以 HBase 作为底层存储，通过 bulkload 的方式提高导入的效率，测试表明我们 bulkload 的版本，相比于普通的分布式导入程序，有十几倍的性能提升。
在查询功能方面，利用 HBase 底层的接口，优化 JanusGraph 里面的点边查询功能，并且明略科技研发了自己的算法，比如，全路径的关系推演接口。同时也扩展了图数据库存储的一些功能，比如，批量数据统计、数据删除的功能。
在图计算方面，我们探索过 tinkerpop 的一些功能，发现算法效率比较低，而且 tinkerpop 本身的算法非常有限，也不好扩展。后来通过直接对接 JanusGraph 这个存储，生成 GraphX 的 Graph 进行图计算，以 pagerank 为例，相较于 tinkerpop 有很明显的性能提升。而且这样的方案有一个好处，在图计算时，相比于去读取原始的数据进行图计算，使用的是最统一融合的图谱存储，作为图计算的输入，从而避免数据一致性的问题。
第二，时序关联数据的存储。
很多行业客户数据存在时序的关联数据，比如，一个人的行为轨迹，交易流水。这类数据如果直接存储到图数据库，会形成很多大量的超级点（Super node），大大影响图谱的查询效率，所以明略科技采取的方式是，把数据分两层存储。比如，两个人是否存在交易的关系，这类汇总的关联信息，依然存在图数据库，而对于明细的交易数据，则存在 Phoenix，通过 Phoenix 灵活的索引实现复杂的多维分析和挖掘功能。
在落地过程中，原始数据可能会发生修改和删除，在图谱构建完之后，同样会存在实体和关系数据被修改或删除的情况。一种方式是直接把修改删除的效果反映到图谱。但由于很多行业客户需要保留历史信息和状态，以便回溯进行历史分析，所以明略科技研发了图谱的历史版本数据管理功能。在方案考虑上，如果基于传统数据库的方案，存储空间占用冗余，且无法实现细粒度的历史版本管理。另外一种方式是把每个状态当作一个点存储，这样每个实体不同的历史时间的状态都是不同的点。这种方案会使图谱结构变得非常复杂，查询效率也会受影响。所以明略科技选择的是把最新版本和历史版本分开存储。
90% 的情况下访问的是最新版本的数据，只需单独访问最新版本的数据即可，如需获取历史版本信息，可单独访问历史版本存储。这样可以实现在线即时记录历史状态变更，有选择性地保存历史信息，也不会出现过度的空间损耗。基于分布式存储，可以实现大规模无限制的历史数据存放。此外，这个方案还能实现图谱数据的回滚和错误恢复。
第三，隐性关系计算。
在图谱计算方面，除了前文提到的 GraphX 图计算工作之外，在行业知识图谱里面还遇到了很常见的一种需求，即隐性关系的计算。一般方式构建的知识图谱中的关系，是显性关系。显性关系是很显然的关系，可以直接得到；而隐性关系需要经过复杂计算才可以得到。
我们结合了客户的业务知识，将业务知识放到明略科技研发的一套关系计算 DSL 中，通过 spark 进行分布式的全图关系计算。
在公安领域的团伙挖掘业务中，用户希望在隐性关系的挖掘过程中，通过调整参数，不断验证自己的想法，所以明略科技研发了一个在线关系计算功能，让用户应用单一轨迹，或多种轨迹，生成在线关系结果，也便于用户沉淀业务知识和经验，进行分享。
第四，图谱深度分析。
通过图谱直接展示一些简单的关系扩展，远远不足以产生更深度价值，所以明略科技开发了一个知识图谱网络深度分析工具。通过一些条件，比如属性、关系或者事件，得到初步的实体结果，称之为群体。通过群体拓扑分析，得到多个子图，应用中心度等算法挖掘核心成员，或者新的成员，还可以针对挖掘出来的子图进行实时虚拟关系计算，帮助用户做辅助分析。
此外，知识图谱本身是一种很好的标签系统，比如，数据属性，包括性别、民族等，就是一种标签，可以基于知识图谱这种属性作为标签体系，进行统计画像。也可以基于实体的轨迹信息进行轨迹画像。
五、行业知识图谱的应用落地
公安领域的关注点主要在于案件的侦查、事件的预警等，明略科技结合知识图谱技术、图计算技术、智能问答技术，帮助客户解决隐性团伙挖掘、家族式犯罪分析、时空轨迹分析、群体行为多元布控等应用场景。明略科技在公安行业已经落地了 200 多个地市级有关单位的智慧公安解决方案，利用百亿规模的知识图谱辅助办案，解决了多起大案。明略科技还与公安部第一研究所，联合发布了中国第一个公安知识图谱标准白皮书。
金融领域，比如，银行，更关注风险管控、智能化营销、内部审计、反洗钱等场景。明略科技在金融领域服务了 50 多个标杆客户，建成了国内银行业首个全行级的知识图谱，利用百亿规模的图谱支撑在线分析、智能化预警、电子化查证等内部审计业务，帮助各部门发现员工异常行为、复杂资金交易网络等。此外，明略科技还帮助客户搭建了首个全行级信贷知识图谱应用，通过图计算、通过图挖掘技术，构建隐性交易关系，发现疑似集资、诈骗等。
工业领域，明略科技给全球最大的轴承厂商搭建了一套智能问答系统，帮助其优化产品使用效率，自动解答用户提问，用知识图谱进行答案的展示和解释。
行业知识图谱，需要海量多源异构数据的构建、存储和灵活计算。在构建方面，要以人机交互的方式，结合规则和机器学习，提高构建效率。在存储方面，要结合客户的使用场景和需求，综合设计架构。在应用方面，不仅仅是提供一个工具，而要结合行业知识 know-how，研发贴近实际业务的应用，最大化发挥行业知识图谱的业务价值。
