首先向大家介绍下电信网络运营的背景：

1、电信网络运营场景介绍

电信网络运营主要是处理网络的故障和问题，这些故障和问题是记录在工单中的，其中包含着很多的专业术语，同时具有数据量大、结构多样、缺乏规范等特点。此类数据是非常有价值的，需要通过较好的分析和应用来体现。以往都是依靠专家经验来处理工单中对应的实时发生的网络问题，这种处理方式面临以下多种问题：

针对上述问题，AI研发中心希望基于知识图谱来探索辅助电信网络运营、提高运维效率的途径。知识图谱的关系表达能力强，基于图的方式可以处理多样的关联分析，在一定程度上能够像人类一样进行知识推理，而且相较于传统的存储方式，在查询时具有更高的结果反馈速度。

此外图数据库呈现数据的方式更加直观、灵活，具备高性能的深度关系查询、分析、推理能力。在网络领域可以支持完成网络安全、网络优化、故障诊断、智能问答等智能化应用。

这部分介绍网络运营知识的一些数据特点，表中列出的是能够从业务中获取到的数据。比如对于工单来讲，在判断所发生的网络故障问题之后，会进行相应的告警，同时会派出网络运维工单，之后运维工人再根据运维工单跟进处理，这一故障解决的过程都会记录在原始的故障问题工单中。其中包含的大部分数据其实是属于半结构化的数据，反馈不分则主要是大量的非机构化文本。工单数据的优点是数据量大、来源稳定；缺点是工人在问题分析和处理过程中可能会因为着急处理问题而简化记录和反馈的内容，导致信息的缺失。

此外还有一部分是案例数据。这部分数据是专家、运维人员在处理大量的网络故障问题过程中所积累的经验，写成案例文档帮助解决后续再遇到的类似问题。案例数据虽然记录全面，包含了故障问题发现、分析、处理的全过程，但是案例数据量比较少，而且不同的专家有自己的文档撰写风格，导致案例数据有很多种样式，来源也不稳定。

第三种是业务规则数据，主要是运维人员在实际处理网络故障问题时所编写和使用的业务规则逻辑。这些业务逻辑规则在实际使用中非常有效，是很重要的知识信息，但是同样具有格式多样、来源不一等问题，实际使用时可能是从多个不同的系统中导出的，需要有专家解读才能准确理解所表达的含义。

最后一种是专家经验，是沉淀在专家脑海中的专业性强、价值较高的实际处置经验。需要通过与专家沟通、言传身教才能够体系地了解这部分内容。由于主要依赖于专家的撰写输出，所以时效性也是比较低的。

3、基于知识图谱的智能网络运营技术方案

基于上面所总结的不同种类数据特点，通过对案例数据、工单数据、运维手册等进行多元异构数据的知识抽取，构建网路运营结构化知识库。基于构建的知识库来打造检索平台、推理平台，进而实现业务场景下的网络故障知识检索、处置措施智能决策等应用。面向现场运维人员构建一个数据加知识驱动的智能运维体系。图中是该系统的基础技术架构。

二、网络运营事件知识图谱构建

第二部分主要介绍网络运营事件知识图谱的构建过程，包括：

1、网络运营事件知识图谱构建流程

知识图谱构建的流程大家都比较熟悉。首先是要进行本体构建，该部分由于需要对业务的理解非常强，所以主要依赖于专家协作完成。在知识抽取部分借鉴了业界效果比较好的 UIE 模型来进行实体抽取和属性抽取，而关系抽取则是不太需要的，因为在进行本体构建的过程中已经把关系的映射方式固定下来了，主要关心原因、故障、解决方案等内容及其之间的固定关系。在知识融合部分则主要是基于专业词汇的消歧来实现实体层面的消歧。在以上过程中得到的结构化数据主要是存储在Neo4j图数据库中。以上是网络运营事件知识图谱的整体构建流程，下面的部分会再进行详细的介绍。

2、网络运营事件知识图谱本体构建

左边图是针对工单数据定义了本体的构建。工单记录了真实发生的网络运营事件，包含工单号、业务分级、大类小类、业务类别等信息，同时也重点提取了故障原因、故障处置方法、处置结果等内容，在处置过程所发生的交互也会被记录下来，在交互的过程中抽取一系列的处置动作，将处理的处置事件关联起来。

比如最开始进行了指标原因的排查分析，然后去查看设备的状态以及业务的指标，检查完一系列内容之后去进行相关的操作，如果所面对的疑难是比较耗时的或者由于自然灾害、需要更换设备等不可抗因素需要长时间等待的，运维人员就可以申请挂起来避免超出时效，这是一个比较重要的网络运营事件。另外告警信息也比较重要，因为告警信息详细记录了发生的故障，包含告警名称、设备号、网联号、网联相关地址、机房和类别。

案例的本体构建主要利用经验总结数据。数据中包含基本的关联设备、关联工单、所属网络层等信息，重点是需要抽取其中的故障发生现象、故障原因、故障处置方式、处置效果信息，这个处置过程会记录的特别详细，分析过程也会比较清楚，所以应用价值也是比工单数据要高的。

3、网络运营事件知识图谱知识抽取

这部分会跟大家介绍在做知识抽取时所进行的操作步骤。首先会用标注工具对工单数据进行实体信息的标注，因为主要使用的是 UIE 模型，所以需要的标注数据量并不大，不会像之前使用 BERT 模型等需要大量的标注数据，进行大概1000份左右的工单数据标注就能够满足要求；标注时主要针对故障原因、解决方案、网联告警设备、地址、时间等信息。

在进行数据标注之后，第二步则是基于 UIE 强大的统一抽取模型基座去训练抽取模型，再用训练好的抽取模型来进行结果抽取和抽取结果校验。最后设置不同的 prompt 策略，用 UIE 进行事件抽取，事件主要是故障分析解决、设备处置状态等。

以上则是进行知识抽取时的主要步骤，下面会再详细介绍其中的事件抽取任务。

事件抽取任务主要是检测文本中一个事件的存在，并将事件结构、事件内容以结构化的形式输出。比如将工单中的一个完整告警处置过程理解为以下事件：出现、处理过程、是否有挂起。针对出现事件主要会有指标异常、设备故障、网元链路异常等。对于不同的事件，对应的参数角色等也不相同，比如指标异常会有一些指标的告警值、期限值等信息；网元链路异常则主要会关注告警部位、告警单元、异常现象信息。

在处理过程中会有加派工位、回单确认、告警恢复确认、设备维护以及其他相关设备指标排查和问题分析：

最后针对挂起事件，挂起主要是因为一些疑难的网络故障需要较长时间去处置。在挂起事件中需要填写挂起的原因、挂起的时长，跟进故障事件以便快速解决；其次还有观察阶段，主要是在故障处理完并且告警恢复之后进行一段时间的观察，如果一段时间内没有再出现同样的问题就表明问题已经解决了。观察之后还有调测的步骤，调测是在问题解决之后调测一些相关的电路，验证确保相关的业务也已经恢复。

4、网络运营事件知识图谱构建结果

事件知识图谱构建整体上主要是将原始工单、案例等非结构化、半结构化数据整理成实体-关系结构化数据，使得信息利用更加高效、方便。其次结构化的运维知识库可以将告警、工单、案例等信息进行关联，只要说的是同样的网络故障，那么就能够将所有相关的知识都获取到，可以更全面地了解相关问题如何处置，以便给出更精准的问题处理建议。

数据库存储方面选择的是 Neo4j 图数据库，在数据量级上不及互联网大厂的知识图谱，主要是在电信网络运营领域内的知识库。构建的道德知识库主要应用于运维知识检索、运维知识管理，比如针对工单案例的专业知识问答、针对专业名词的知识检索，在知识抽取的应用上主要是进行图谱实体关系的抽取、关系列表的管理等操作。

三、网络运营知识图谱应用

接下来介绍如何将已经构建好的事件知识图谱应用于网络运营场景中去，主要包括以下应用：

1、智行云网大脑知识库平台

基于工单和案例数据构建的知识图谱，打造智行云网大脑知识库平台，通过这个平台可以对工单、案例进行高效的图谱式智能检索，也支持运维知识的高效快速查找、知识关联、案例查重以及辅助案例撰写和修改。右侧是已经在集团内上线的智行云网大脑知识库平台。在系统图中可以看到主要有工单、案例、专业词汇辅助撰写以及问答等功能，下面的结构图中也详细列出了系统中所具备的功能模块。

2、智行云网大脑智能助手

第二部分的应用是在智行云网大脑上建设智能运维助手。早在2022年时就已经在业务流程中设置了数字工位，这个数字工位不包括前端机器人形象的展现，他可以针对用户交互过程中出现的问题给出相应的回答和指导推荐。后续基于运维知识库，采用自然语言处理相关技术来进行工单案例的推荐，打造具有丰富运维知识的智能助手，助力集团和公司解决运维过程中的繁杂工作。在实际应用中智能运维助手不会影响原本的线网系统的内容，是一个比较轻量好用的工具。

此外专家们也可以利用智行云网知识库查询历史网络运维过程中发生的故障数量、故障原因种类数、每类故障对应的解决方案以及实际处理过程中的问题解决方案、最终的处理效果等。除了查询功能，还能够帮助专家进行知识沉淀，辅助专家撰写相关案例，极大地提升了工作效率。通过建设知识+AI的智能交互运维助手，提升了网络运维中故障问题处置的自动化率。

3、网络运维工单处置动态推荐

第三部分应用时在网络运维工单处置过程中的动态推荐。处置过程主要是工单的流转，针对图中的故障工单，通过自动抽取故障描述、故障类别等故障实体，以及其他相关告警描述信息，来实现故障的精准定位，并通过故障知识图谱检索来得到知识库中的相似故障或者是相似的故障原因，基于这些历史信息推荐相关的解决方案。在此过程中，随着读取到的工单信息越来越多，故障定位也会越来越准确，新的相关信息也会进行更新并加入到检索判断条件中重新生成推荐结果，通过动态更新推荐结果来赋能一线人员，精准指导运维人员进行相关的业务操作。

图中展示的是上述过程的逻辑结构。最上边是在读的工单，会有工单号、故障类别、告警描述以及故障描述等信息。通过这些信息从历史图数据库中进行检索，比如找到70.5%概率是因为单板状态故障导致的问题，针对这个原因的解决方案有复位修复和更换设备，比如先尝试复位修复，若复位修复不成功说明设备老化或者损坏了，则再通过更换相关的设备来进行维修。此外当前的故障也有15.5%的概率是有升级操作时调测造成的，这种情况下是在正常业务操作过程中出现的告警信息，是可以申请进行屏蔽的，不需要进行相关的处置。基于以上流程实现了故障处置过程中的准确指导。

最后一部分内容是因为受到 ChatGPT 的冲击所带来的展望思考。首先针对知识图谱构建过程中的知识生产环节，在 ChatGPT 的辅助下可以进一步地简化，比如将专业的非结构化数据给到 ChatGPT，实现零样本或者100以内数据标注情况下的专业抽取结果，甚至能够自动完成领域知识的融合。

第二点是将已积累建设的知识图谱加入到 ChatGPT 模型中，作为垂直领域的知识补充。在运维交互过程中可以使得智能助手的水平更上一层，针对业务人员使用过程中的反馈还可以对模型进行迭代更新，实现知识自动迭代升级的闭环。

第三点主要是 ChatGPT 在助力网络运维智能化的过程中所体现的智能化、自动化处置进一步减轻了运维的工作量，让运维人员只关注其中20%的工作，比如设计类型的工作或者是针对系统本身的一些思考性工作。

以上是基于已有历史工作所做的一些思考，给大家提供一些相关的思路，希望大家能够发挥更多的想象力在这些方向进行尝试和努力。我们对通信领域的模型合作比较感兴趣，希望将模型应用到网络运营过程中，在业务过程中带来效率的提升以及识别的准确率，减少运维人员的工作量。

Q1：在有了大模型之后，智行云网大脑智能助手通过知识图谱的方式构建还合适吗？因为KBQA或者FAQ的问答方式在大模型背景下可能会受到降维打击。

A1：这一部分需要通过实践来进行探索，不太好说大模型能不能完全替代KBQA。但是对于我们网络运维场景，维护网络时知识的准确性以及好的交互效果相对来说更重要一些，所以前期还是会依赖于解释起来更直观的知识图谱的形式，这种形式在我们的实际应用落地中占有更多的优势。

在大模型这方面我们也会积极地进行相关的实践，主要是利用大模型来快速地帮助我们构建可视化的知识图谱，提供知识支撑来辅助解决运维故障问题。我们也就大模型问题与一线业务人员进行过沟通，业务人员觉得大模型不能够像知识图谱那样对于推荐的解决方案给出合理的解释，不足以对于推荐的结论给出有力的依据，这会导致信任问题，所以大模型的实际应用落地仍需要进一步的探索。

Q2：电信网络运营事件知识图谱的本体是如何构建的呢？

A2：本体部分的构建主要是基于对业务的理解。我们的数据源是工单这种格式，相当于是表单，表单中会记录相关的业务设备、发生的故障、故障时间等一系列的信息，我们从中总结出一套结构来形成本体部分的内容。

在这个结构中会有比较详细的业务内容。比如首先会有工单号作为唯一标识来关联相关的知识，根据工单号可以关联到故障、告警信息、故障原因、问题解决方案，此外工单号也可以与处理该问题的人员关联起来，记录其处置方式和记录反馈。针对业务本身，也会有分级体系，其中包含着不同的大类和小类，以及其他业务方面的分析。