一、背景簡介

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

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

2023 年，正是大模型盛行的時期，很多企業(yè)認為有了大模型之后圖譜的重要性大大降低了，之前研究的預置的信息化系統(tǒng)也都不重要了。不過隨著 RAG 的推廣、數(shù)據(jù)治理的盛行，我們發(fā)現(xiàn)更高效的數(shù)據(jù)治理和高質(zhì)量的數(shù)據(jù)是提升私有化大模型效果的重要前提，因此越來越多的企業(yè)開始重視知識構(gòu)建的相關(guān)內(nèi)容。這也推動了知識的構(gòu)建和加工開始向更高水平發(fā)展，其中有很多技巧和方向可以挖掘?？梢娨粋€新技術(shù)的出現(xiàn)，并不是將所有的舊技術(shù)打敗，也有可能將新技術(shù)和舊技術(shù)相互融合后，會實現(xiàn)更好的結(jié)果。我們要站在巨人的肩膀上不斷向前擴展。

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

基于這些原因，如果有小伙伴想要研究知識圖譜方向，我們的建議是從知識的全生命周期去考慮，思考要解決的問題和具體的落地點。比如有企業(yè)利用現(xiàn)有的一些文檔生成考試、培訓、面試相關(guān)的內(nèi)容，雖然這個落地點看上去并不像多模態(tài)、Agent 這些技術(shù)熱詞那么火熱，但是這樣的私有化模型會比 GPT3.5 或者 GPT4 的效果更好，因為在這個場景里面已經(jīng)做過了一些場景預制。因此我們認為更專、更精的模型將是未來發(fā)展的一大趨勢。

二、圖譜產(chǎn)品形態(tài)

在上述背景下，圖譜產(chǎn)品形態(tài)會是什么樣子呢？接下來以云問科技的“AI+知識”產(chǎn)品體系為例來進行介紹。

首先要有統(tǒng)一的 AI 底座，這并不是靠一個團隊、甚至一家公司就能做好的?？梢岳么竽Ｐ鸵娴牡谌?API 或者 SDK，很多時候不一定要從零到一去造輪子，因為很可能花了數(shù)月造出的輪子的效果還不如剛剛發(fā)布的一個開源模型的效果。所以 AI 底座部分建議更多地思考如何結(jié)合第三方技術(shù)，如果自己研發(fā)就要想清楚優(yōu)勢在哪，當然發(fā)揮平臺價值二者兼顧是最好的。

關(guān)于 AI 能力組件，從我們的一些交付經(jīng)驗里發(fā)現(xiàn)，這些AI 能力組件往往會比產(chǎn)品更好賣。因為很多企業(yè)都希望可以利用專業(yè)技術(shù)公司搭建的組件去構(gòu)建自己的上層應(yīng)用。在大模型時代下賣 AI 能力組件就像是賣鏟子，而金礦還由大企業(yè)自己去挖掘。

在上層應(yīng)用方面，我們會從 AIGC 本身的應(yīng)用、知識智能和智能營服這三個方向落地。探索在哪個方向上會有更大的價值。而知識圖譜被我們劃歸為整個知識智能里面的一個核心環(huán)節(jié)。需要注意的是，知識圖譜是核心但不是唯一。我們之前遇到很多場景，客戶有大量的關(guān)系型數(shù)據(jù)庫和大量的非結(jié)構(gòu)化文檔，希望我們可以將這些知識體系和知識資產(chǎn)全部納入到知識圖譜中去，這樣做的代價是非常大的。我們認為未來的知識架構(gòu)應(yīng)該是異構(gòu)的，既有一部分知識在文檔中，也有一部分知識在關(guān)系數(shù)據(jù)庫中，還有一部分知識可能來自于圖譜網(wǎng)絡(luò)，而最終大模型要做的是基于多源異構(gòu)數(shù)據(jù)做綜合分析。比如一個情報，可以從關(guān)系型數(shù)據(jù)庫中提取一些數(shù)值指標，在文檔中找到一些建議，從工單中搜索出一些歷史信息，再將所有內(nèi)容整理在一起進行分析。這就是我們認為大模型和知識圖譜的一種結(jié)合方式。在一個整體架構(gòu)中，大模型做最終的分析，而知識圖譜通過其知識表示體系幫助大模型更快速、更準確地找到背后隱藏的知識。

前面探討了大模型和圖譜之間的關(guān)系，接下來回顧一下圖譜本身需要有些什么。

首先，圖譜的背后是一個圖數(shù)據(jù)庫，比如開源的 Neo4j、Genius Graph，還有一些國產(chǎn)的數(shù)據(jù)庫品牌。知識圖譜和圖數(shù)據(jù)庫是兩個不同的概念，打造一個知識圖譜產(chǎn)品，相當于在圖數(shù)據(jù)庫的上層做了一個封裝，以實現(xiàn)快速的圖譜建模和可視化。

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

下面介紹一下圖譜的總體特征。目前知識圖譜還是以三元組為主，在此基礎(chǔ)上構(gòu)建實體、屬性、關(guān)系等多顆粒度多層次的語義關(guān)系。在工業(yè)界，我們經(jīng)常會遇到一些三元組無法解決的問題，當我們用設(shè)定好的實體屬性值去刻畫真實物理世界時會出現(xiàn)很多問題。這時候我們就會將帶約束的條件，以 CVT 的方式來實現(xiàn)。所以大家在構(gòu)建知識圖譜的時候要先論證三元組能解決當前的問題。

需要指出的一點是，在構(gòu)建圖譜時一定要按需構(gòu)建，因為世界是無窮的，里面的知識內(nèi)容也是無窮的。在剛開始，我們常常會有一個愿景，就是將所有的物理世界中存在的實體都刻劃到我們的計算機世界。這么做會帶來的問題就是最后構(gòu)建的整套schema 過于復雜，對于真實業(yè)務(wù)沒有幫助。比如，地球繞著太陽轉(zhuǎn)這個事實，我可以把它構(gòu)建在三元組中。但這個三元組能并不能解決我當下面對的實際問題，所以一定要按需構(gòu)建三元組。

那么常識類的問題怎么處理呢？很多問題確實需要常識類的三元組。我們認為這可以交由大模型來做。我們更希望知識圖譜能夠發(fā)掘?qū)I(yè)性，把真正相關(guān)聯(lián)的知識構(gòu)建在圖譜中。然后大模型可以基于常識，再結(jié)合以知識圖譜提供的在開放領(lǐng)域中無法獲取的先驗知識，來實現(xiàn)更好的效果。

知識圖譜的構(gòu)建需要業(yè)務(wù)人員和運營人員共同去設(shè)計，包括本體、關(guān)系、屬性和實體的定義，以及如何可視化。最終會涉及到一個問題，就是從產(chǎn)品形態(tài)上呈現(xiàn)哪些內(nèi)容給用戶。如果用戶是最終的消費者，那么只需要呈現(xiàn)可視化搜索和問答就可以了。因為這類客戶并不關(guān)心圖譜是如何構(gòu)建的，是自動化還是手工。

這里又涉及另一個很重要的問題，就是即使在大模型場景下，也不是所有的圖譜都能夠自動化構(gòu)建。圖譜的構(gòu)建成本非常高，我們與其花費大量的精力在圖譜的建模上，還不如把精力花在消費上。如果想達到業(yè)務(wù)接受的效果，就可能要依賴手工構(gòu)建。比如一個格式確定的表格，如果跨表很復雜，我們可以嘗試是否可以用大模型來尋求一個 baseline。這樣就可以把精力從構(gòu)建轉(zhuǎn)移到消費上。比如一個項目周期有 100 天，我們花了 70 天來構(gòu)建圖譜，最后的 30 天來思考這個圖譜的應(yīng)用場景，或者因為前期構(gòu)建時間延長，造成沒有時間來思考有價值的消費場景，就可能帶來很大的問題。根據(jù)我們的經(jīng)驗，應(yīng)該在構(gòu)建上花費少量的時間，或者是默認為手工構(gòu)建。然后花大量的時間來思考如何讓構(gòu)建好的圖譜發(fā)揮最大的價值。

上圖展示了知識圖譜構(gòu)建的流程。在構(gòu)建本體的時候我們一定要接受本體是變化的，就像數(shù)據(jù)庫本身的表結(jié)構(gòu)也可能會更新。所以在設(shè)計時，一定要考慮其魯棒性和擴展性。比如，我們在做某一類設(shè)備的圖譜時，應(yīng)該考慮到整套設(shè)備的體系。未來可能要通過這個體系來搜索設(shè)備，并且也應(yīng)該了解到這個體系下其它設(shè)備還沒有構(gòu)建圖譜，未來可以去建。通過整個大的體系為用戶帶來更大的價值。

我們經(jīng)常聽到的一個問題是，我可以通過 FAQ 也可以通過大模型來找到答案，為什么還要用圖譜呢？我們的回答是，如果我們把當前的知識和圖譜做關(guān)聯(lián)后，看到的世界就不再是一維的，而是一個網(wǎng)狀的世界，這是圖譜在消費端可以實現(xiàn)的一個價值，而其他技術(shù)很難實現(xiàn)。目前大家的關(guān)注點往往會放在量級以及使用了什么高級的算法等，但其實更應(yīng)該從消費和解決問題的方向出發(fā)來思考圖譜的構(gòu)建。

在大模型盛行的當下，我們需要考慮大模型和圖譜的結(jié)合?？梢哉J為圖譜是上層應(yīng)用，而大模型是底層能力。我們可以從不同場景去理解大模型對圖譜帶來了什么幫助。

在圖譜構(gòu)建時，可以通過一些文檔和提示詞進行信息抽取，來替代原來的 UIE、NER 等相關(guān)技術(shù)，從而使抽取能力進一步提高。也要考慮在 zero-shot，few-shot 和充足數(shù)據(jù)訓練的情況下究竟是大模型好還是小模型好。這種問題并沒有單一的答案，不同場景、不同數(shù)據(jù)集會有不同的方案。這是一個全新的知識構(gòu)建的路徑。目前來看，在 zero-shot 的場景下，大模型的抽取能力更優(yōu)。不過一旦樣本量增加后，小模型從性價比和推理速度上都更具優(yōu)勢。

在消費端，對于運用圖譜解決推理類問題，比如政策類的判斷，例如判斷一個企業(yè)是否能滿足某個政策，能不能享受到政策中談及的福利。先前的做法是通過圖譜、規(guī)則和語句表達式來進行判斷?，F(xiàn)在的做法就像 Graph RAG 一樣，通過用戶的問句找到與當前企業(yè)相類似的三元組或者多元組，運用大模型來獲取答案，得出結(jié)論。因此很多圖譜推理類的問題、圖譜構(gòu)建的問題，都可以通過大模型技術(shù)解決。

圖譜存儲類的問題，圖數(shù)據(jù)庫和圖譜本身的數(shù)據(jù)結(jié)構(gòu)是很重要的，大模型短期內(nèi)還無法處理長文本或整個圖譜，所以圖譜的存儲是一個很重要的方向。它和向量數(shù)據(jù)庫一樣，會成為未來大模型生態(tài)圈里一個非常重要的組件。上層的應(yīng)用會決定是否要使用這個組件來解決實際問題。

圖譜可視化是偏前端的問題，需要根據(jù)場景和要解決的問題來進行設(shè)計。我們更希望可以把技術(shù)做成中臺，提供某個能力，來滿足未來不同的交互形態(tài)，比如移動端、PC、手持設(shè)備等等。我們只需要提供一個結(jié)構(gòu)，前端如何渲染和呈現(xiàn)可以根據(jù)實際需求來確定。大模型也會是調(diào)用此類結(jié)構(gòu)的一個方式。當大模型或 agent 可以基于需求來判定如何調(diào)用圖譜，就可以打通閉環(huán)。圖譜需要能封裝更好的 API 來適配未來各種應(yīng)用的調(diào)用。中臺的概念正逐步被重視，一個獨立的解耦的服務(wù)，能更加廣泛地被各方使用。

比如有時需要找到某些遺留在文檔中某個表格里的某個數(shù)值，通過搜索或者大模型技術(shù)很難去定位其位置，如果利用圖譜的結(jié)構(gòu)化能力將內(nèi)容呈現(xiàn)出來，就可以通過在應(yīng)用系統(tǒng)里調(diào)用某個接口來獲得這個圖譜的值，并把其所在的文檔，或者大模型的分析結(jié)果呈現(xiàn)出來。這種可視化方式對于用戶來說才是最高效的。這也是目前流行的 Copilot 的方式，即通過調(diào)用圖譜、搜索或其它的應(yīng)用能力，最后用大模型做“最后一公里”的生成來共同解決問題，達到提高效率的目的。

當下我們經(jīng)常會做知識庫和圖譜的各種融合，今年有很多知識類項目出現(xiàn)。之前，知識主要供人搜索和消費。隨著大模型的出現(xiàn)，大家發(fā)現(xiàn)也可以將知識供給大模型來消費。所以大家對知識的貢獻和構(gòu)建更加關(guān)注。我們本身有大量的知識，還需要第三方知識圖譜系統(tǒng)，是因為我們的知識都是非結(jié)構(gòu)化的，其中會有很多非常重要的知識，比如工單、設(shè)備維修的案例等，需要把這些知識以結(jié)構(gòu)化的內(nèi)容來存儲，這些內(nèi)容之前都是供搜索使用的，現(xiàn)在可以供大模型做 SFT。

知識庫和圖譜是天生可以結(jié)合的，當結(jié)合后，就可以對外統(tǒng)一提供一套知識服務(wù)類產(chǎn)品。這種知識服務(wù)類產(chǎn)品的生命力是十分旺盛的，無論在 OA、ERP、MIS，還是 PRM 系統(tǒng)中都會對知識有需求。

在融合的時候，要十分注意如何區(qū)分知識和數(shù)據(jù)?？蛻魰峁┐罅繑?shù)據(jù)，但這些數(shù)據(jù)可能并不是知識。我們需要從需求側(cè)出發(fā)來定義知識。比如對于一個設(shè)備，我們通常需要了解什么內(nèi)容，比如設(shè)備運行時的數(shù)據(jù)波動，這些都是數(shù)據(jù)，而這個設(shè)備的出廠時間、上次維修時間等等，這些則是知識。如何定義知識是十分重要的，需要在業(yè)務(wù)的參與和指導下共同構(gòu)建。

三、工業(yè)圖譜進階

在數(shù)字化轉(zhuǎn)型過程中，調(diào)度、設(shè)備、營銷和分析等場景中都會用到 AI 與圖譜的技術(shù)。尤其是在調(diào)度場景，無論是交通調(diào)度、能源調(diào)度還是人力調(diào)度，都是以任務(wù)下發(fā)的方式開展。比如出現(xiàn)火災，要派多少人、多少車等等，在進行調(diào)度時需要查詢一些相關(guān)數(shù)據(jù)，目前的問題往往不是找不到結(jié)果，而是返回的內(nèi)容太多了，但不能給出真正有用的解決方案。因為對知識的消費形態(tài)還停留在關(guān)鍵詞檢索，所有包含“火災”這個詞的文檔都會呈現(xiàn)出來。要獲得更好的呈現(xiàn)，就可以通過圖譜。比如在設(shè)計“火災”這個本體時，它的上位本體是災難，針對“火災”這個實體可以設(shè)計它的注意事項、保護措施和經(jīng)驗案例。通過這些內(nèi)容把知識進行分拆。這樣當用戶輸入“火災”時，就會呈現(xiàn)一個相關(guān)的圖譜脈絡(luò)和下一步應(yīng)該做的事。

在調(diào)度相關(guān)場景中，應(yīng)關(guān)注 Agent 這個方向。Agent 對于調(diào)度十分重要，因為調(diào)度本身是一個多任務(wù)場景。圖譜返回的結(jié)果會更精確、更豐富。

智能設(shè)備方面也有很多應(yīng)用場景。設(shè)備的信息會存儲在不同的系統(tǒng)中，比如出廠信息存儲在產(chǎn)品手冊中，維修信息存儲在維修工單中，運行狀態(tài)存儲于設(shè)備管理系統(tǒng)中，而巡檢狀態(tài)則存儲在工業(yè)巡檢系統(tǒng)中。工業(yè)上面對的一大問題就是系統(tǒng)太多。如果想要查詢一個設(shè)備的信息，需要從多個系統(tǒng)中查詢，并且這些系統(tǒng)中的數(shù)據(jù)是互不相通的。這時就需要一個系統(tǒng)可以打通連接，將所有內(nèi)容關(guān)聯(lián)映射起來。以知識圖譜為核心的知識庫就可以解決這個問題。

知識圖譜可以通過本體將其相關(guān)的屬性、字段、字段來源等等囊括進來，可以從底層刻畫和關(guān)聯(lián)各個系統(tǒng)之間的串并聯(lián)關(guān)系。不過在構(gòu)建圖譜時，要牢記按需設(shè)計和構(gòu)建圖譜。很多企業(yè)在構(gòu)建圖譜時會將數(shù)據(jù)中臺的數(shù)據(jù)通過 D2R 技術(shù)全部轉(zhuǎn)移過來，這個圖譜其實沒有任何意義。在構(gòu)建圖譜時一定要考慮好動態(tài)圖譜和靜態(tài)圖譜的關(guān)聯(lián)。

在智能營銷和多場景能源 AI 領(lǐng)域也有很多應(yīng)用場景和設(shè)計技巧，在此不做展開，可以后續(xù)再進行探討。

在構(gòu)建圖譜時，架構(gòu)設(shè)計是非常重要的。如何將底層的庫和工藝流程與圖譜構(gòu)建和消費結(jié)合起來。最終如何交付有很多細節(jié)需要思考?？梢詤⒖忌蠄D中列出的環(huán)節(jié)來進行設(shè)計和實踐。

在圖譜 KBQA 中我們也做了一些研究，比如上下位、圖譜 CVT 查詢等。比如醫(yī)療場景中，發(fā)燒和頭疼對應(yīng)的上位都是身體表征異常，知識庫中不會對于發(fā)燒或者頭疼進行單獨存儲，在原始文檔中都是以身體輕微異常來存儲。當用戶表述和專業(yè)表述有差異時，我們就可以通過上下位的推理 CVT 來解決。

當前搭建的圖譜可能只是 SPO 或多跳或 TransE 等實體對齊。但是在實際復雜場景下就需要 CVT 結(jié)合上下位來實現(xiàn)。還有很多論文在英文數(shù)據(jù)集上表現(xiàn)很好，但是在中文數(shù)據(jù)集上效果就不太理想。所以我們需要結(jié)合自己的需求來設(shè)計，并不斷迭代，才能達到好的效果。

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

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

在工業(yè)智改數(shù)轉(zhuǎn)過程中，研發(fā)設(shè)計、生產(chǎn)管理、供應(yīng)管理、售前營銷和綜合服務(wù)中都有很多應(yīng)用點。

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

因此在構(gòu)建工業(yè)知識圖譜時，要從具體場景著手，通過分析場景需求來構(gòu)建圖譜，才能實現(xiàn)更好地落地和應(yīng)用。