应用实践 | 网络智能运维下的知识图谱

会员服务 ·

应用实践 | 网络智能运维下的知识图谱

2020 年 3 月 13 日 开放知识图谱

本文转载自公众号：网络人工智能园地。

让AI更智能，谷歌要用知识图谱让AI像人一样理解世界。

让AI更智能，我们要用知识图谱让AI像网络专家一样了解网络。

知识图谱引领人工智能从感知阶段演进到认知阶段，成为当前的热点技术之一，受到ICT产学研界的重点关注。

为什么人们如此重视知识图谱技术？

因为知识图谱不仅能够通过为万事万物建立起全方位的链接，支撑基于常识知识和概念知识的搜索类需求，催生了Google、百度、Amazon Go、微软 Bing等搜索技术的智能化升级，而且让各行业应用在知识图谱加持下获得新进展，诞生出各种领域知识图谱应用，如智能问答、金融征信、医药研发、公安技侦、互联网+生活服务等等。

不同行业不同场景对不同的知识领域提出了各种诉求，催生出知识图谱工程和NLP各种技术的爆炸式增长，同时对知识抽取和数据处理技术提出了各种各样的技术需求。

华为网络人工智能在知识图谱领域的探索

华为网络人工智能希望能够利用知识图谱技术解决网络领域典型场景下的智能化运维问题，也对如何构建图谱、应用图谱提出了各种诉求：从知识内容看，不同于百科类知识图谱，网络领域知识图谱更关注网络领域的知识深度和完备性，从人机交互技术角度讲，不同于开放式聊天的交互方式，网络领域更关注面向解决问题的目标导向性问答体验。比如说，一个电信核心网络运维专家可以回答和解决的一些专业领域问题，机器是否也能做到，甚至进行更为深刻的理解和推理演绎，进而让机器能辅助人达到提高运维效率，降低运维成本和节省时间的目的；未来演进到网络自动驾驶的高级阶段，可以减少甚至消除网络运维工程师和网络专家的运维值守压力和起夜率，提供更精准更人性化的智能服务，善莫大焉。

构建知识图谱的流程主要可以分为知识获取、知识融合、知识验证、知识计算、知识应用等几个步骤，华为网络人工智能基于NAIE平台需要知识图谱工程系统在此基础上设立领域知识标准规范、细化知识加工技术链条、完善运营运维与可信能力等等。总体构想如下图所示：

打开来看看这一块、那一块、方方面面都有啥：

知识来源

从来源形式上看，知识蕴藏在结构化（例如：告警、指标等）、半结构化（例如：配置、日志、规范化产品文档）、非结构化（例如：实践手册、故障案例、分享帖子）数据中，甚至在专家的脑子里。这些网络知识来源于support网站的产品文档，运维专家的维护文档，发生告警故障时的现网抓包数据，现网环境的配置文档数据，运维专家的经验沉淀文档或者故障传播知识采集等，相应的我们需要配套对接获取这些数据的工具，可以复用现有NAIE平台的数据采集工具，也需要补齐诸如抓包数据获取工具、接口，文档数据获取链接通道与管理工具等，以便从不同来源、不同结构的数据源中获取知识语料。

知识建模

有了语料，我们面临的第一个重要问题是，我们需要什么样的知识？或者说我们需要在数据中提取出哪些有价值的知识才能解决我们面临的故障运维问题？这就需要有效的知识组织结构，我们在数据获取之前就需要先设计知识模式，建立知识图谱的数据模式（schema）。通常模式设计方法有两种：一种是自顶向下的方法，网络专家与建模专家利用知识图谱建模工具手工编辑schema；另一种是自底向上的方法，基于来源数据的结构、语料的规范标准，以图技术组织知识结构设计，包括：实体（点）建模、属性建模、关系（边）建模，将数据中蕴含的知识组织形式以图的方式表达建立起来，从现有的高质量数据源中进行映射。数据建模的重要性在于这项工作是知识图谱工程所有工作的基础，因此标准规范的 schema设计能有效降低领域知识抽取使用对接的总体成本。

举个例子，我们做故障传播知识图谱，就需要定义故障在哪里发生（产品对象），发生了什么故障（告警、指标异常、故障现象、日志异常），所发生的故障之间有什么传递或依赖关系（告警间的关系、告警与指标异常的关系、指标异常间的关系、故障现象间的关系等等）。要注意的一点是，分类标准定义数据中蕴含的很重要的知识，需要在设计中体现出来。此外只有这个业务知识还是不够，对于支撑良好的人机交互还需要补齐网络领域的语义知识。比如：当NE这个缩略语出现时，要知道这里说的是“网元”，不是“东北”；当“Pod起不来”出现时，说的是一个进程失败故障现象，不是叫Pod的家伙睡懒觉。

知识存储

有了知识模型，知识的组织和摆放就有了货架，知识如何按货架摆放就需要知识存储，要存好还要好用是知识存储技术的关键，重要考虑的是选什么样的数据库按设计好的schema来存。要不要选关系数据库或者NoSQL数据库？要用什么样的图数据库？这些都需要根据数据场景仔细选择。

WikiData选择了Virtuso，CN-DBpedia 实际上是基于mongo 数据库，一般基于特定领域的知识图谱都可能会按需用到某个图数据库，选择RDF Store还是Property Graph，需要综合考虑知识来源、使用方式和应用特点。网络故障知识不仅需要图查询、图计算，也需要理解语义、承载故障问题的答案，因而最理想的图数据库是即能并行化部署、支撑关系存储、支持图计算，又能有效存储RDF形式的知识，支撑语义理解所需的词典表、三元组、符号化知识表示，目前受限于实体名单的限制，我们只能在合规的开源图数据库和自研图数据库中做选择，这也催生了我们对自研图数据库的一些关键诉求——多能力融合，当满足该需求的版本正式发布后，相信对开发者来说是一个值得期待的选择。

知识抽取

我们知道，分布在网上的知识常常以分散、异构的形式存在，传统的数据清洗抽取方式不一定适用于知识抽取，很多问题不能解决，因此需要针对知识来源格式和知识抽取目标有针对性的设计抽取工具能力。目前我们利用自研的基于正则表达的无码化抽取工具TIE作为机器数据知识抽取工具；对于文档知识抽取，情况稍微复杂些，首先我们需要保留产品文档组织结构中的章节段落分类分层知识，利用文档元数据解析XML标签，获得段落句子级别的抽取中粒度知识，然后需要利用神经网络模型和NLP工具针抽取词级别的细粒度知识，包括实体词和特征词间的分类、关系等。通常抽取结果需要迭代和验证来提高新词发现准确率，这样来将不同源不同结构的数据融合成统一表示的不同颗粒度的知识，存入知识库中。

知识表示和知识融合

单靠抽取获得的知识，在关系表达层面往往是稀疏的，说白了就是关系是不足的，往往需要通过各种算法自动挖掘、发现新的关系，做知识补全。我们需要的知识补全能力不仅包括实体间的关系补全，也包括各种故障特征传导关系的补全。例如故障A的可能原因可能与故障B的可能影响表达的是一个意思，那就需要在“原因”与“影响”间补全一个相似关系。这样的知识补全是对细粒度级别知识抽取的有效补充。

纯文本数据中获取知识会涉及到的实体识别、实体链接、关系识别、概念抽象等，需要用到许多自然语言处理的技术，包括但不仅限于分词、样本标注、词性标注、同义词提取等等。

做好知识加工准备，只是完成了AI应用开发的一部分准备工作，如何利用获取到的知识，最重要的是解决关键应用场景问题，实现业务价值，才能体现技术的价值。

2020年华为开发者大会HDC.Cloud上，华为网络人工智能将线上直播对知识图谱构建和应用场景做一个系统性介绍，希望我们在开发过程中的一些创新尝试和实践经验能够给广大开发者提供一些有益的参考，敬请期待！

OpenKG

开放知识图谱（简称 OpenKG）旨在促进中文知识图谱数据的开放与互联，促进知识图谱和语义技术的普及和广泛应用。