一、背景簡介

首先來介紹一下云問科技的發展歷程。

云問科技公司由 Chatbot 起家，在 2013 年到 2019 年間一直投身于 Chatbot 領域，主要關注人機對話方向，推出了很多客服類產品。后轉型去做知識相關領域的原因是，在 Bert 發布之前機器人的問答效果難以提升，如果只是通過單個 NLP 算法，很難有質的提升。因此我們開始思考如果算法上無法突破，如何能提升問答系統的質量。我們發現構建高質量企業級知識將是一個很好的方向。所以從 2020 年到 2023 年，我們開始深耕知識領域的內容，也開始注意到知識圖譜可以有很廣泛的應用空間。

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

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

基于這些原因，如果有小伙伴想要研究知識圖譜方向，我們的建議是從知識的全生命周期去考慮，思考要解決的問題和具體的落地點。比如有企業利用現有的一些文檔生成考試、培訓、面試相關的內容，雖然這個落地點看上去并不像多模態、Agent 這些技術熱詞那么火熱，但是這樣的私有化模型會比 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 結合上下位來實現。還有很多論文在英文數據集上表現很好，但是在中文數據集上效果就不太理想。所以我們需要結合自己的需求來設計，并不斷迭代，才能達到好的效果。

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

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

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

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

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