網絡智能運維下的知識圖譜

讓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上，華為網絡人工智能將線上直播對知識圖譜構建和應用場景做一個系統性介紹，希望我們在開發過程中的一些創新嘗試和實踐經驗能夠給廣大開發者提供一些有益的參考，敬請期待！

AI NAIE 網絡智能體 知識圖譜 運維

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。