轉載本文需註明出處：微信公衆號EAWorld，違者必究。
1
知識圖譜的幾種典型應用方式
基於知識圖譜的應用可以分爲幾種典型的類型，這幾種應用使用的場景各有不同，在使用技術上也各有側重，我們希望能夠根據不同類型，總結出一些通用的場景，指導應用建設：
1）知識推理類型就是通過已知的知識，推理出未知的知識，這在知識圖譜應用的建設中，具備非常大的誘惑力，例如大型裝備的故障診斷，當裝備發生故障的時候，會接到很多的故障報警信息，利用知識推理可以快速定位故障的原因，提高故障定位的速度，減少對人的依賴；
2）知識呈現類是將各種實體關係進行處理，用一定的方式呈現出來，幫助使用者理解複雜的事物，找出規律或者答案。例如在公共安全領域用“數據對碰”的方式找出嫌疑人與案件之間的關聯， Palantir、i2 等公司都有這種知識可視化呈現的工具；
3）知識問答類應用根據提問者語音或者文字的輸入，找到相關的知識，完成與提問者之間的互動，通常語音客服、員工助手等應用都屬於這一類型。一般來說問答類應用分爲聽清、聽懂、能做三個部分，聽清可以基於目前百度、騰訊、科大訊飛等組件完成。由於這些應用往往面向特定的專業領域， 聽懂和會做就可以採用領域知識圖譜技術，通過交互得到 5W1H （Why、What、When、Where、Who、How）幾個方面信息，讓計算機按提問者要求完成工作。
4）知識共享類應用主要解決在不同機構之間知識共享。很多機構之間，由於法律法規等原因，無法直接獲取對方數據，只能在相互之間通過知識圖譜進行溝通，例如某市大數據中心有稅務數據，公安偵查需要稅務數據，但是根據法律不能直接調用具體的稅務數據進行偵查，除非對具體主體立案。這種情況下，公安部門可以提供主體的一些典型特徵，大數據中心根據特徵提供相關主體的列表，公安部門根據列表縮小範圍，繼續偵查，得到新特徵，再調取列表。經過幾次知識的碰撞，確定相關嫌疑人，再進行立案調查。
2
基於相關矩陣的知識推理類應用：
大型裝備故障自動診斷
知識推理的方法比較多，如果看理論文獻，有自上而下的演繹法，在給定一個或者多個前提的基礎上，推斷出一個必定成立的過程。也有自下而上的歸納法，基於已觀察的結果，得出一個結論，歸納法又分成溯因推理和類比推理。不過這些太理論化了。
領域知識圖譜應用中，最常見的推理就是基於規則的推理。在建設知識圖譜的過程中，會產生很多規則，這些規則有可能依附於概念之間的關係，也可能是事件、處置的描述方式，用規則的方式來表述知識，是一種最常見的方式。規則包括條件規則、規則樹、規則矩陣、規則流等多種方式，這裏我們介紹一種以相關矩陣做爲規則的實際應用情況。
前面提到，在大型裝備出現故障時，往往接收到大量的故障信號，如何判定故障發生的具體原因，是一個比較複雜的問題，這裏就是介紹解決這個問題的（寫這個段落時，我比較猶豫，因爲這裏會涉及到具體的裝備製造業務，最後還是咬咬牙寫下來，畢竟知識圖譜建設中，關鍵是業務的理解，實際上我們的方法也有助於快速的理解業務。當然，我會盡可能寫的簡單一些）。我們以某飛機舵控系統爲例，簡單化的方式我們把它分爲電源、核心電路板、接口電路板、控制器、電機 5 個部分，每個部分的故障分別爲斷路、CPU損壞、接口線路斷路、控制器燒燬、電機卡死 5 個故障，已有故障現象的知識爲當電機轉角異常時電機卡死，當電機轉角異常、控制器輸出信號異常時控制器燒燬，當電機轉角異常、控制器輸出異常、控制計算機輸出異常時控制芯片損壞，當電機轉角異常、控制器輸出異常、控制計算機輸出異常時接口線路斷路，當電機轉角異常、控制器輸出異常、控制計算機輸出異常、電源電壓異常時電源斷路，如下圖所示：
（點擊圖片可放大）
上面的設備部件故障模式與故障徵兆的對應關係，可以如下表所示，矩陣中的 1 代表故障模式同故障徵兆具有關聯關係，即某種故障發生的時候，對應的故障徵兆（測試現象）會發生。例如矩陣中的第一行，表示“電源斷路故障"發生的時候，“電源電源異常”“控制計算機輸出信號異常”“控制器輸出信號異常”“電機轉角異常”這些現象均會發生：
如果將上圖用規則表述，可以用下面的方式做推理計算：
IF 控制計算機信號輸出異常
IF 控制器輸出信號異常
THEN 電機卡死
ELSE
THEN 控制器燒燬
ELSE
IF 電源電壓異常
THEN 芯片損壞 或者 接口線路斷路
（都是控制計算機故障，具體故障需要進一步分析，現有數據並不能確認）
ELSE
THEN 電源電路
這裏出現了一個新問題，如果裝備有上千個部件/元件，每個部件/元件有大量故障現象，按照上述的 IF/ELSE 模式進行規則推理的編寫會非常複雜，因此在推理時不會使用 IF/ELSE 方式進行推理。而是將這些部件和故障按上圖方式，形成一個非常大的相關矩陣，上圖矩陣中每一行都對應一個具體的故障模式，這樣就可以根據每一行的特徵，利用二值相關性模型進行快速定位故障，目前有專業的故障推理機從事這方面工作。如果沒有專業的故障推理機，對於簡單一些的情況，也可以使用代碼生成的方式生成上述的 IF/ELSE 推理程序。
（點擊圖片可放大）
上面介紹的推理過程可以看出，故障診斷場景下推理的關鍵是形成故障與部件之間的相關矩陣，而形成相關矩陣的過程，也就是故障知識圖譜建設的過程。下面我們介紹一下故障知識圖譜形成的過程，如何建模，如何抽取，如何驗證，以便對知識圖譜建設方法有個更加清晰的認識。
本文針對領域知識圖譜，建設方法以“自頂向下”爲主，“自下而上”爲輔，對於故障診斷這樣的場景，“自頂向下”的知識來自於裝備設計，也就是說在裝備的設計過程中，就可以確定裝備內部各部件的拓撲結構、故障類型、測試方式，讓故障診斷的知識圖譜成爲裝備設計環節的一部分，也就是說知識的抽取是在設計階段進行的。當裝備投入使用後，新的故障出現在對設計階段形成的圖譜進行補充，可以認爲是一個“自下而上”的方式。
既然在裝備設計過程中形成知識圖譜，就需要有一個描述裝備、故障、測試幾者之間關係的模型，這也是知識建模的重要內容：業界一般用“多信號流圖”的方式描述，如下圖的示例。
（點擊圖片可放大）
這個圖形中，把裝備的部件、每個部件的故障模式、部件之間的關係、每個部件的測試點以及輸入輸出情況，用圖形化的方式描述了出來。在裝備設計中完成相關“多信號流圖”的設計，就可以通過“多信號流圖”產生前面的故障診斷相關矩陣。除此之外“多信號流圖”還可以完成知識驗證的工作，例如裝備設計中測試的完備性，推理故障之間的關聯性，出現新故障知識是推理知識是否合理等等，是裝備設計的一個重要手段。“多信號流圖”提高了知識圖譜的建設工程化水平，讓設計者用更容易理解和操作的方式進行設計，同時它也是一個多方面知識融合的過程。
我相信絕大多數讀者並不從事裝備設計領域，因此沒必要深入瞭解“多信號流圖”，但這種圖形化模式的提出對知識圖譜建設非常有借鑑價值。對應到傳統信息化軟件的設計你會發現，UML就是一種圖形化的建模方式，類圖屬於軟件靜態關係的圖形化描述，時序圖、狀態圖、序列圖等等是軟件動態關係的圖形化描述，部署圖是軟件物理結構的圖形化描述，因此在知識建模過程中，可以考慮建立自有的圖形化描述，提高知識抽取的工程化能力。
下圖總結了採用知識圖譜建設方法論，進行裝備故障診斷時各個階段的主要工作，包括：
（點擊圖片可放大）
1、知識建模階段，對裝備、功能（控制、分離、引導、連接...）、輸入輸出（能量、物質、信號）等基本概念的抽象，以及利用“多信號流圖”進行圖形化描述（類似面向對象的 UML 方式）；
2、知識抽取階段，可以在研發過程中設計裝備的“多信號流圖”，對於研發階段沒有進行這方面設計的可以從維修手冊中抽取。用多信號流圖可以產生故障樹與故障相關矩陣。
3、知識驗證階段，可以利用相關矩陣推斷新增加的知識是否有效，也可以驗證測試是否完備，例如兩個故障模式在故障矩陣中故障特徵是一致的，就可能需要增加測試點；
4、利用故障知識圖譜，可以在開發實時診斷的應用，利用推理機實時確定故障發生的部件，產生故障應急的預案等等。
感謝胡政博士爲本文提供的案例，他曾是國防科技大學裝備綜合保障技術重點實驗室的核心成員，我國裝備保障領域的知名專家。他創辦的湖南擎新公司，專注於大型裝備的實時故障診斷、檢測技術的研究與實踐，完成了多項重大武器裝備的故障診斷知識圖譜的建設。
3
總 結
企業軟件從流程化開始起步，逐步實現數據化，今天我們希望它能夠更加智能化。而目前智能化還主要體現在圖像識別、語音識別的應用，究其原因是目前以機器學習爲核心的技術並不能滿足很多場景，諸如缺少大量數據、結果不夠明確、需要明晰推理過程。而建立專業領域知識圖譜，正是將人工智能應用從簡單應用轉向知識密集但數據缺少的複雜應用。
《老焦專欄 | 解開知識圖譜神祕的面紗》、《老焦專欄 | 知識圖譜建設方法論》，在這一系列的三篇文章醞釀了很長時間，借鑑了企業軟件流行的面向對象方法，提出了一個工程化實施知識圖譜建設的方法論，包括知識建模中的領域劃分、概念與關係建模，知識抽取的自動化、非自動化方法，最後列舉了知識圖譜的四種應用形式，並通過一個裝備故障監測的示例，講解了如何基於知識圖譜進行推理、如何在知識圖譜建模時類似 UML 的方式建立知識模型。
後面我們還會針對知識圖譜這一話題，進行持續的探討，敬請期待。
- The End -
關於作者：焦烈焱，普元信息CTO，致力於技術創新和金融創新解決方案研究。專注於企業技術架構領域，對分佈式環境的企業計算、 企業信息架構的規劃與實踐有着豐厚經驗，帶領普元技術團隊相繼在雲計算、大數據及移動開發領域取得多項突破，並主持中國工商銀行、中國建設銀行等多家大型企業技術平臺的規劃與研發。
關於EAWorld
微服務，DevOps，數據治理，
移動架構原創技術分享。
長按二維碼關注！