一、電信網絡運營場景

首先向大家介紹下電信網絡運營的背景：

• 電信網絡運營場景介紹
• 網絡運營知識來源
• 基于知識圖譜的智能網絡運營技術方案

1、電信網絡運營場景介紹

電信網絡運營主要是處理網絡的故障和問題，這些故障和問題是記錄在工單中的，其中包含著很多的專業術語，同時具有數據量大、結構多樣、缺乏規范等特點。此類數據是非常有價值的，需要通過較好的分析和應用來體現。以往都是依靠專家經驗來處理工單中對應的實時發生的網絡問題，這種處理方式面臨以下多種問題：

• 運行工作量逐年增長：比如集團云網運營部維護網元數同比增加10%，甚至更多；故障單同比增加5%以上。
• 運維模式陳舊：當前運維模式主要依賴于專家經驗和規則來維護網絡的穩定，自動化流程占比還比較少。
• 業務數據利用率低：業務中所產生的工單數據、案例數據以及專家手冊等還沒有得到很好的利用，缺乏結構化的知識沉淀。
• 智能化程度低：當前結構化數據資源匱乏，深度學習技術還未較好利用，無法提供足夠的智能化應用。

針對上述問題，AI 研發中心希望基于知識圖譜來探索輔助電信網絡運營、提高運維效率的途徑。知識圖譜的關系表達能力強，基于圖的方式可以處理多樣的關聯分析，在一定程度上能夠像人類一樣進行知識推理，而且相較于傳統的存儲方式，在查詢時具有更高的結果反饋速度。

此外圖數據庫呈現數據的方式更加直觀、靈活，具備高性能的深度關系查詢、分析、推理能力。在網絡領域可以支持完成網絡安全、網絡優化、故障診斷、智能問答等智能化應用。

2、網絡運營知識來源

這部分介紹網絡運營知識的一些數據特點，表中列出的是能夠從業務中獲取到的數據。比如對于工單來講，在判斷所發生的網絡故障問題之后，會進行相應的告警，同時會派出網絡運維工單，之后運維工人再根據運維工單跟進處理，這一故障解決的過程都會記錄在原始的故障問題工單中。其中包含的大部分數據其實是屬于半結構化的數據，反饋不分則主要是大量的非機構化文本。工單數據的優點是數據量大、來源穩定；缺點是工人在問題分析和處理過程中可能會因為著急處理問題而簡化記錄和反饋的內容，導致信息的缺失。

此外還有一部分是案例數據。這部分數據是專家、運維人員在處理大量的網絡故障問題過程中所積累的經驗，寫成案例文檔幫助解決后續再遇到的類似問題。案例數據雖然記錄全面，包含了故障問題發現、分析、處理的全過程，但是案例數據量比較少，而且不同的專家有自己的文檔撰寫風格，導致案例數據有很多種樣式，來源也不穩定。

第三種是業務規則數據，主要是運維人員在實際處理網絡故障問題時所編寫和使用的業務規則邏輯。這些業務邏輯規則在實際使用中非常有效，是很重要的知識信息，但是同樣具有格式多樣、來源不一等問題，實際使用時可能是從多個不同的系統中導出的，需要有專家解讀才能準確理解所表達的含義。

最后一種是專家經驗，是沉淀在專家腦海中的專業性強、價值較高的實際處置經驗。需要通過與專家溝通、言傳身教才能夠體系地了解這部分內容。由于主要依賴于專家的撰寫輸出，所以時效性也是比較低的。

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%的工作，比如設計類型的工作或者是針對系統本身的一些思考性工作。

以上是基于已有歷史工作所做的一些思考，給大家提供一些相關的思路，希望大家能夠發揮更多的想象力在這些方向進行嘗試和努力。我們對通信領域的模型合作比較感興趣，希望將模型應用到網絡運營過程中，在業務過程中帶來效率的提升以及識別的準確率，減少運維人員的工作量。

五、Q&A

Q1：在有了大模型之后，智行云網大腦智能助手通過知識圖譜的方式構建還合適嗎？因為KBQA或者FAQ的問答方式在大模型背景下可能會受到降維打擊。

A1：這一部分需要通過實踐來進行探索，不太好說大模型能不能完全替代KBQA。但是對于我們網絡運維場景，維護網絡時知識的準確性以及好的交互效果相對來說更重要一些，所以前期還是會依賴于解釋起來更直觀的知識圖譜的形式，這種形式在我們的實際應用落地中占有更多的優勢。

在大模型這方面我們也會積極地進行相關的實踐，主要是利用大模型來快速地幫助我們構建可視化的知識圖譜，提供知識支撐來輔助解決運維故障問題。我們也就大模型問題與一線業務人員進行過溝通，業務人員覺得大模型不能夠像知識圖譜那樣對于推薦的解決方案給出合理的解釋，不足以對于推薦的結論給出有力的依據，這會導致信任問題，所以大模型的實際應用落地仍需要進一步的探索。

Q2：電信網絡運營事件知識圖譜的本體是如何構建的呢？

A2：本體部分的構建主要是基于對業務的理解。我們的數據源是工單這種格式，相當于是表單，表單中會記錄相關的業務設備、發生的故障、故障時間等一系列的信息，我們從中總結出一套結構來形成本體部分的內容。

在這個結構中會有比較詳細的業務內容。比如首先會有工單號作為唯一標識來關聯相關的知識，根據工單號可以關聯到故障、告警信息、故障原因、問題解決方案，此外工單號也可以與處理該問題的人員關聯起來，記錄其處置方式和記錄反饋。針對業務本身，也會有分級體系，其中包含著不同的大類和小類，以及其他業務方面的分析。