工業知識圖譜進階實戰

一、背景簡介

首先來介紹雲端問科技的發展歷程。

雲端問科技公...

2023年，正是大模型盛行的時期，很多企業認為已經大模型之後圖譜的重要性大大降低了，之前研究的預置的資訊化系統也都不重要了。不過隨著 RAG 的推廣、資料治理的盛行，我們發現更有效率的資料治理和高品質的資料是提升私有化大模型效果的重要前提，因此越來越多的企業開始重視知識建構的相關內容。這也推動了知識的建構和加工開始向更高層次發展，其中有許多技巧和方法可以挖掘。可見一個新技術的出現，並不是將所有的舊技術打敗，也有可能將新技術和舊技術相互融合後，會達到更好的結果。我們要站在巨人的肩膀上不斷向前擴展。

雲端問科技為什麼會聚焦在企業知識中心這方面內容呢？因為我們在過去的一些案例中發現，當面對很多複雜場景時，例如風控、藥物檢測等，直接讓大模型去做這些複雜任務，在短期內很難取得理想效果，很難打造出一個標準化產品進行交付。而在企業知識管理或辦公室相關的業務管理場景中則可以較為快速地進入試運行，並可能獲得理想效果。所以我們今年在同企業共創私有化大模型時，都會把企業的知識管理，包括基於企業知識管理的問答或搜尋納入其中，作為一個重點課題。對企業來說，自身的私有化知識和知識中心的建設是十分重要的。

基於這些原因，如果有小夥伴想要研究知識圖譜方向，我們的建議是從知識的全生命週期去考慮，思考要解決的問題和具體的落地點。例如有企業利用現有的一些文件產生考試、訓練、面試相關的內容，雖然這些技術熱詞那麼火熱，但是這樣的私有化模型會比GPT3.5 或者GPT4 的效果更好，因為在這個場景裡面已經經過了一些場景預製。因此我們認為更專、更精的模式將是未來發展的一大趨勢。

在上述背景下，圖譜產品形態會是什麼樣子呢？接下來以雲問科技的「AI+知識」產品體系為例來介紹。

#########首先要有統一的 AI 底座，這並不是靠一個團隊、甚至一家公司就能做好的。可以利用大模型引擎的第三方 API 或 SDK，很多時候不一定要從零到一去造輪子，因為很可能花了數月造出的輪子的效果還不如剛發布的一個開源模型的效果。所以 AI 底座部分建議多思考如何結合第三方技術，如果自己研發就要想清楚優勢在哪，當然發揮平台價值二者兼顧是最好的。 ############關於 AI 能力組件，從我們的一些交付經驗中發現，這些AI 能力組件往往會比產品更好賣。因為很多企業都希望可以利用專業技術公司搭建的元件來建構自己的上層應用。在大模型時代下賣 AI 能力組件就像是賣鏟子，而金礦也由大企業自己去挖掘。 ######

在上層應用方面，我們會從 AIGC 本身的應用、知識智能和智慧營服這三個方向落地。探索在哪個方向上會有更大的價值。而知識圖譜則被我們劃歸為整個知識智能裡面的一個核心環節。需要注意的是，知識圖譜是核心但不是唯一。我們之前遇到很多場景，客戶有大量的關係型資料庫和大量的非結構化文檔，希望我們可以將這些知識體系和知識資產全部納入到知識圖譜中去，這樣做的代價是非常大的。我們認為未來的知識架構應該是異質的，既有一部分知識在文件中，也有一部分知識在關係資料庫中，還有一部分知識可能來自於圖譜網絡，而最終大模型要做的是基於多源異構數據做綜合分析。例如一個情報，可以從關係型資料庫中提取一些數值指標，在文件中找到一些建議，從工單中搜尋出一些歷史信息，再將所有內容整理在一起進行分析。這就是我們認為大模型和知識圖譜的一種結合。在一個整體架構中，大模型做最終的分析，而知識圖譜則透過其知識表示體系幫助大模型更快速、更精確地找到背後隱藏的知識。

前面探討了大模型和圖譜之間的關係，接下來回顧一下圖譜本身需要有些東西。

首先，圖譜的背後是一個圖資料庫，像是開源的 Neo4j、Genius Graph，還有一些國產的資料庫品牌。知識圖譜和圖資料庫是兩個不同的概念，打造一個知識圖譜產品，相當於在圖資料庫的上層做了一個封裝，以實現快速的圖譜建模和視覺化。

要打造知識圖譜產品時，可以先參考Neo4j 或國內一些大廠的知識圖譜產品的產品形態，這樣就能大概了解到知識圖譜產品需要實現哪些功能和環節。更重要的是要知道如何建立一個知識圖譜，這看起來是個業務問題，因為不同企業、不同場景，圖譜都是不一樣的。身為技術人員，如果不了解電力、設備、工業等等，就不可能建構出一個令業務滿意的圖譜。需要與業務不斷溝通，經過不斷迭代才能最終得到一個結果。討論的過程其實可以回歸到 schema 的本質，把圖譜的一套本體理論和邏輯概念全部呈現出來，這些內容是非常重要的。當 schema 定好後，後續可以讓更多的相關人員參與進來將內容豐富，進一步完善產品。這是我們目前的一些經驗。

以下介紹圖譜的整體特徵。目前知識圖譜還是以三元組為主，在此基礎上建構實體、屬性、關係等多顆粒度多層次的語意關係。在工業界，我們常常會遇到一些三元組無法解決的問題，當我們用設定好的實體屬性值去刻畫真實物理世界時會出現很多問題。這時候我們就會將帶有約束的條件，以 CVT 的方式來實現。所以大家在建構知識圖譜的時候要先論證三元組能解決當前的問題。

需要指出的一點是，在建構圖譜時一定要按需構建，因為世界是無窮的，裡面的知識內容也是無窮的。在剛開始，我們常常會有一個願景，就是將所有的物理世界中存在的實體都刻劃到我們的電腦世界。這麼做會帶來的問題就是最後建置的整套schema 過於複雜，對於真實業務沒有幫助。例如，地球繞著太陽轉這個事實，我可以把它建構在三元組中。但這個三元組能並不能解決我當下面對的實際問題，所以一定要按需建立三元組。

那麼常識類別的問題要怎麼處理呢？很多問題確實需要常識類的三元組。我們認為這可以交由大模型來做。我們更希望知識圖譜能夠發掘專業性，把真正相關聯的知識建構在圖譜中。然後大模型可以基於常識，再結合以知識圖譜提供的在開放領域中無法獲得的先驗知識，來實現更好的效果。

#

知識圖譜的建構需要業務人員和營運人員共同去設計，包括本體、關係、屬性和實體的定義，以及如何視覺化。最終會牽涉到一個問題，就是從產品形態呈現哪些內容給使用者。如果用戶是最終的消費者，那麼只需要呈現視覺化搜尋和問答就可以了。因為這類客戶並不關心圖譜是如何建構的，是自動化還是手工。

這裡又涉及另一個很重要的問題，就是即使在大模型場景下，也不是所有的圖譜都能夠自動化建構。圖譜的建造成本非常高，我們與其花費大量的精力在圖譜的建模上，不如把精力花在消費上。如果想達到業務接受的效果，就可能要依賴手作。例如一個格式決定的表格，如果跨表很複雜，我們可以嘗試是否可以用大模型來尋求一個 baseline。這樣就可以把精力從建構轉移到消費。例如一個專案週期有100 天，我們花了70 天建構圖譜，最後的30 天思考這個圖譜的應用場景，或是因為前期建置時間延長，造成沒有時間思考有價值的消費場景，就可能帶來很大的問題。根據我們的經驗，應該在建造上花費少量的時間，或預設為手工建造。然後花大量的時間思考如何讓建構好的圖譜發揮最大的價值。

上圖展示了知識圖譜所建構的流程。在建構本體的時候我們一定要接受本體是變化的，就像資料庫本身的表結構也可能會更新。所以在設計時，一定要考慮其穩健性和擴充性。例如，我們在做某一類設備的圖譜時，我們應該考慮整套設備的體系。未來可能要透過這個體系來搜尋設備，也應該了解到這個體系下其它設備還沒有建構圖譜，未來可以去建。透過整個大的體系為使用者帶來更大的價值。

我們常聽到的一個問題是，我可以透過 FAQ 也可以透過大模型來找到答案，為什麼還要用圖譜呢？我們的回答是，如果我們把目前的知識和圖譜做關聯後，看到的世界就不再是一維的，而是一個網狀的世界，這是圖譜在消費端可以實現的一個價值，而其他技術很難實現。目前大家的關注點往往會放在量級以及使用了什麼高階的演算法等，但其實更應該從消費和解決問題的方向出發來思考圖譜的建構。

在大模型盛行的當下，我們需要考慮大模型和圖譜的結合。可以認為圖譜是上層應用，而大模型是底層能力。我們可以從不同場景去理解大模型對圖譜帶來了什麼幫助。

在圖譜建構時，可以透過一些文件和提示詞進行資訊抽取，來取代原始的 UIE、NER 等相關技術，從而使抽取能力進一步提高。也要考慮在 zero-shot，few-shot 和充足資料訓練的情況下究竟是大模型好還是小模型好。這種問題並沒有單一的答案，不同場景、不同資料集會有不同的方案。這是一個全新的知識建構的路徑。目前來看，在 zero-shot 的場景下，大模型的抽取能力較優。不過一旦樣本量增加後，小模型從性價比和推理速度都更有優勢。

在消費端，對於運用圖譜解決推理類問題，例如政策類的判斷，例如判斷一個企業是否能滿足某個政策，能不能享受到政策中談及的福利。先前的做法是透過圖譜、規則和語句表達式來進行判斷。現在的做法就像 Graph RAG 一樣，透過使用者的問句找到與目前企業相類似的三元組或多元組，運用大模型來獲得答案，得出結論。因此許多圖譜推理類別的問題、圖譜建構的問題，都可以透過大模型技術解決。

圖譜儲存類別的問題，圖資料庫和圖譜本身的資料結構是很重要的，大模型短期內還無法處理長文字或整個圖譜，所以圖譜的儲存是一個很重要的方向。它和向量資料庫一樣，會成為未來大模型生態圈裡一個非常重要的元件。上層的應用會決定是否要使用這個元件來解決實際問題。

#

圖譜視覺化是偏前端的問題，需要根據場景和要解決的問題來進行設計。我們更希望可以把科技做成中台，提供某個能力，來滿足未來不同的互動型態，像是行動端、PC、手持裝置等等。我們只需要提供一個結構，前端如何渲染和呈現可以根據實際需求來決定。大模型也會是呼叫此類結構的一個方式。當大模型或 agent 可以基於需求來判定如何呼叫圖譜，就可以打通閉環。圖譜需要能封裝更好的 API 來適配未來各種應用的呼叫。中台的概念正逐步被重視，一個獨立的解耦的服務，能更廣泛地被各方使用。

例如有時需要找到某些遺留在文件中某個表格裡的某個數值，透過搜尋或大模型技術很難去定位其位置，如果利用圖譜的結構化能力將內容呈現出來，就可以透過在應用系統裡呼叫某個介面來獲得這個圖譜的值，並把其所在的文檔，或是大模型的分析結果呈現出來。這種視覺化方式對於使用者來說才是最有效率的。這也是目前流行的 Copilot 的方式，也就是透過呼叫圖譜、搜尋或其它的應用能力，最後用大模型做「最後一公里」的生成來共同解決問題，達到提高效率的目的。

當下我們常會做知識庫和圖譜的各種融合，今年有許多知識類別專案出現。之前，知識主要供人搜尋和消費。隨著大模型的出現，大家發現也可以將知識供給大模型來消費。所以大家對知識的貢獻和建構更加重視。我們本身有大量的知識，還需要第三方知識圖譜系統，是因為我們的知識都是非結構化的，其中會有很多非常重要的知識，例如工單、設備維修的案例等，需要把這些知識以結構化的內容來存儲，這些內容之前都是供搜尋使用的，現在可以供大模型做SFT。

知識庫和圖譜是天生可以結合的，當結合後，就可以對外統一提供一套知識服務類產品。這種知識服務類產品的生命力是十分旺盛的，無論在 OA、ERP、MIS，或是 PRM 系統中都會對知識有需求。

在融合的時候，要十分注意如何區分知識和數據。客戶會提供大量數據，但這些數據可能不是知識。我們需要從需求面出發來定義知識。例如對於一個設備，我們通常需要了解什麼內容，例如設備運作時的數據波動，這些都是數據，而這個設備的出廠時間、上次維修時間等等，這些都是知識。如何定義知識是十分重要的，需要在業務的參與和指導下共同建構。

三、工業圖譜進階

在數位轉型過程中，調度、設備、行銷和分析等場景中都會用到AI 與圖譜的技術。尤其是在調度場景，無論是交通調度、能源調度或人力調度，都是以任務下發的方式進行。例如出現火災，要派多少人、多少車等等，在進行調度時需要查詢一些相關數據，目前的問題往往不是找不到結果，而是返回的內容太多了，但不能給出真正有用的解決方案。因為知識的消費形態仍停留在關鍵字檢索，所有包含「火災」這個字的文檔都會呈現出來。要獲得更好的呈現，就可以透過圖譜。例如在設計「火災」這個本體時，它的上位本體是災難，針對「火災」這個實體可以設計它的注意事項、保護措施和經驗案例。透過這些內容把知識分拆。這樣當使用者輸入「火災」時，就會呈現一個相關的圖譜脈絡和下一步該做的事。

在調度相關場景中，應關注 Agent 這個方向。 Agent 對於調度十分重要，因為調度本身就是一個多任務場景。圖譜回傳的結果會更精確、更豐富。

智慧型裝置方面也有很多應用場景。設備的資訊會儲存在不同的系統中，例如出廠資訊儲存在產品手冊中，維修資訊儲存在維修工單中，運作狀態儲存於設備管理系統中，而巡檢狀態則儲存在工業巡檢系統中。工業上面對的一大問題就是系統太多。如果想要查詢一個設備的信息，則需要從多個系統中查詢，而這些系統中的資料是互不相通的。這時就需要一個系統可以打通連接，將所有內容關聯映射起來。以知識圖譜為核心的知識庫就可以解決這個問題。

知識圖譜可以透過本體將其相關的屬性、欄位、欄位來源等等囊括進來，可以從底層刻畫和關聯各個系統之間的串並聯關係。不過在建構圖譜時，要牢記按需設計和建構圖譜。許多企業在建構圖譜時會將資料中台的資料透過 D2R 技術全部轉移過來，這個圖譜其實沒有任何意義。在建構圖譜時一定要考慮好動態圖譜和靜態圖譜的關聯。

在智慧行銷和多情境能源 AI 領域也有很多應用場景和設計技巧，在此不做展開，可以後續再進行探討。

在建立圖譜時，架構設計是非常重要的。如何將底層的函式庫和製程與圖譜建構和消費結合。最終如何交付有很多細節需要思考。可以參考上圖中列出的環節來進行設計和實作。

在圖譜 KBQA 中我們也做了一些研究，像是上下位、圖譜 CVT 查詢等。例如醫療場景中，發燒和頭痛對應的上位都是身體表徵異常，知識庫中不會對於發燒或頭痛進行單獨存儲，在原始文檔中都是以身體輕微異常來存儲。當使用者表達和專業表達有差異時，我們就可以透過上下位的推理 CVT 來解決。

目前搭建的圖譜可能只是 SPO 或多跳或 TransE 等實體對齊。但是在實際複雜場景下就需要 CVT 結合上下位來實現。還有很多論文在英文資料集上表現很好，但是在中文資料集上效果就不太理想。所以我們需要結合自己的需求來設計，並且不斷迭代，才能達到好的效果。

半自動化文件加工，包含文件解析、段落擷取、三元組抽取和手動審核。人工審核這一步常常會被忽略，尤其是在大模型到來後，大家更不重視人工審核。其實如果進行資料加工和資料治理，對於模型效果會有很大的提升。因此我們要考慮最終想要解決的場景要具備高價值，同時也要關注投入的資源在哪裡，是在圖譜的構建，還是在大模型的最佳化。如果沒有這些考慮，那麼產品將很容易被取代或挑戰。

上圖展示的是雲端問科技的一款裝置生命週期管理產品。這類場景透過輕量化中間模組，透過不同場景進行上層應用建構實現。這些模組的生命力遠比知識圖譜系統本身的生命力更旺盛。單賣或只賣中間件在圖譜領域並不適用，尤其在工業場景。很多工業問題在客戶視角上是很複雜的問題，圖譜和大模型都無法解決。我們需要做的是從效果說服客戶。

在工業智改數轉換過程中，研發設計、生產管理、供應管理、售前行銷和綜合服務中都有很多應用點。

#

上圖是故障裝置圖譜的應用情境範例。在這個場景中我們並沒有把所有圖譜元素加入其中，例如裝置運作狀態和關係型資料庫中的簡單資料。我們認為對於設備維修來說，主要關註三類數據，第一類是設備基本訊息，例如出廠時間，生產廠家，投入運作多久；第二類是故障，例如故障的名稱、上下級，此類故障會導致什麼缺陷，什麼缺陷會導致哪一類故障等；第三類是工單，描述在什麼設備發生了什麼故障。透過這三種數據的連接，我們可以建立一個小型閉環的圖譜。未來也可以根據動態資料進行延伸。所以在建構圖譜時，我們更傾向於去做一個小而美的、場景可閉環的圖譜。而並非一味追求量級的高大上，卻無法滿足消費端需求的圖譜。

因此在建立工業知識圖譜時，要從具體場景著手，透過分析場景需求來建立圖譜，才能實現更好地落地和應用。

以上是工業知識圖譜進階實戰的詳細內容。更多資訊請關注PHP中文網其他相關文章！