螞蟻集團大規模語義知識管理關鍵技術及實踐

在學術和產業界，自從2012年谷歌在搜索領域提出了知識圖譜的概念並應用之後，隨後的10年時間，國內外科技公司在知識圖譜包括圖資料庫和圖計算上都爭先布局。從谷歌學術發表的知識圖譜文章來看，最近5到10年時間，越來越多的技術人員投入到知識圖譜領域研發中。

2. 螞蟻知識圖譜平台目標

螞蟻知識圖譜平台建設初期遇到了幾個挑戰：

• 大量複雜的跨業務域多元關係。在金融領域，面臨的業務場景是多元化的，如支付、安全、保險、財富等。

• 多個不同職能的用戶群體。面向不同職能的用戶群體比較多，比如算法、運營、數據等。

• 分析/決策實時化要求。圖譜的分析或者決策的實時性要求比較高。比如面向C端的保險理賠這些場景。

• 專家規則的複雜性。比如安全風控領域的專家規則就十分複雜。

大量複雜的跨業務域多元關係。在金融領域，面臨的業務場景是多元化的，如支付、安全、保險、財富等。

多個不同職能的用戶群體。面向不同職能的用戶群體比較多，比如算法、運營、數據等。

分析/決策實時化要求。圖譜的分析或者決策的實時性要求比較高。比如面向C端的保險理賠這些場景。

專家規則的複雜性。比如安全風控領域的專家規則就十分複雜。

螞蟻知識圖譜平台的目標就是建設面向金融領域的一站式知識研發和管理平台，提供面向業務的知識建模、知識構建、可視化分析、專家經驗決策和圖譜算法推理等全場景知識生命周期解決方案。

3. 螞蟻金融知識圖譜建設現狀

經過4-5年時間的建設，螞蟻金融知識圖譜已經覆蓋了整個金融領域的安全、消費金融、支付、保險、財富、網商、智能資金等很多場景，實體、概念、關係類型超過了5000，知識規模從最初的億級別快速增長到萬億級別，知識應用調用量也已經超過了每天千億級別。這也說明金融領域業務對知識圖譜的應用需求越來越多。

02

語義知識表示模型

知識圖譜作為一種語義網絡，是大數據時代知識表示的重要方式之一。接下來我們首先介紹語義化的作用、知識的定義和分類以及語義知識表示等基本概念，並引出螞蟻語義知識表示模型。

1.語義化的作用

語義化的概念，源於語義網絡（Semantic Network），這個概念由奎林(J. R. Quillian)於1968年提出，是一種以網絡格式表達人類知識構造的形式，使用語義和語義的關係表示知識的網絡結構。語義網絡圖中，包含兩種類型的知識。一種是人們總結的常識類知識。比如從貓到哺乳動物再到動物，它是一種概念的分類體系。另外一種是面向事實類的知識，比如不同貓的個體和人的個體之間的被飼養（has）的關係。

語義化的作用主要是兩點，一是讓數據表示標準化，實現數據的復用。二是不同領域的數據可交互，促進數據編織（Data Fabric）。例如一所醫院和一個自然人，他們都有地理位置的信息，有可能是簡稱，也有可能是全稱。要通過地理位置建立醫院和自然人之間的聯繫，就要實現地址位置信息的表示標準化，之後才能實現其之間的關聯。

2. 知識分類和定義

結合業務場景，我們把知識分成三種類型。

• 實體。比如用戶、企業、商戶等這些業務相關性比較強的客觀存在的實例，它是一些個體。

• 概念。概念是對一類實體的抽象概述。比如人的個體，可以分成喜歡運動的，喜歡旅遊的，等等，給一類人群貼上標籤，就成為人群的概念。

• 事件。第三類是會動態發生變化的事件，它對實體類型加入了時間、空間等約束，比如企業的事件、診療的事件，或者交易的事件。

實體。比如用戶、企業、商戶等這些業務相關性比較強的客觀存在的實例，它是一些個體。

概念。概念是對一類實體的抽象概述。比如人的個體，可以分成喜歡運動的，喜歡旅遊的，等等，給一類人群貼上標籤，就成為人群的概念。

事件。第三類是會動態發生變化的事件，它對實體類型加入了時間、空間等約束，比如企業的事件、診療的事件，或者交易的事件。

事件、實體及關係、概念構成的語義網絡，相互之間會發生連接，整體構成了知識圖譜的分類能力。

3. 語義知識表示- SPG(Semantic enhanced Property Graph)

語義知識表示，即知識建模，業界主要分為標記屬性圖（Labeled Property Graph）和資源描述框架（Resource Deion Framework，RDF）兩種主流的模型。兩種模型各有優勢。LPG基於點邊屬性實現知識表示，這種建模方式更貼近於圖的數據結構表示，相對來說更清晰、更簡單，建模成本更低。RDF採用三元組的表示方式，實體之間通過屬性建立了豐富的連接，但RDF在工業界的落地相對差一些。

在知識圖譜構建過程中，面臨從業務數據到知識標準化的演化過程。因為在業務建設初期，很多屬性的類型都是文本類型。隨著概念網絡的完善，這些文本類型需要不斷地演化到標準類型，從而實現知識的復用，以及與更多其他領域的數據進行連接。

因此，我們提出了一種語義增強的屬性圖模型，它是結合了LPG和RDF優勢的混合模型，更適合業務數據到知識標準化的演化過程。它提供業務易理解的表達，更利於知識復用，可規模化落地。

這種語義增強的屬性圖模型，有一些語義約束的範式。我們參考了OWL的表達方式，大概分成如下幾類：

• 邏輯推演。包括symmetric（spouse），transitive（located_in）等。以可傳遞性為例，比如說某個人位於成都市，那他一定位於四川省。

• 數據完整性約束。包括mutexOf等。以互斥類型為例，如果兩個人是兄弟關係，就一定不是父子關係。

• 屬性類型約束。語義增強的屬性圖模型，它支持int、string這些基礎屬性類型，也支持City等標準類型。區別於String類型，標準類型可枚舉，支持實體間可傳播計算，基礎類型演化到標準類型，即可實現屬性圖到語義圖內置轉換。

• 實體衍生/鏈指。包括subClassOf、equivalent、fuse等，主要是知識復用的約束範式。

邏輯推演。包括symmetric（spouse），transitive（located_in）等。以可傳遞性為例，比如說某個人位於成都市，那他一定位於四川省。

數據完整性約束。包括mutexOf等。以互斥類型為例，如果兩個人是兄弟關係，就一定不是父子關係。

屬性類型約束。語義增強的屬性圖模型，它支持int、string這些基礎屬性類型，也支持City等標準類型。區別於String類型，標準類型可枚舉，支持實體間可傳播計算，基礎類型演化到標準類型，即可實現屬性圖到語義圖內置轉換。

實體衍生/鏈指。包括subClassOf、equivalent、fuse等，主要是知識復用的約束範式。

03

語義知識管理關鍵技術及應用

接下來重點介紹語義知識管理的底層關鍵技術和在業務上的應用。

1.語義知識管理核心能力

語義知識管理的核心能力分成以下幾個部分：

• 語義增強。主要是結合語義知識的表示，提供語義增強的能力。

• 知識演化。是實現業務數據到知識標準化的過程，包括圖譜Schema及其綁定運算元的增、刪、改，比如把屬性類型從string等基礎類型變更為Brand等可枚舉標準語義類型。

• 跨域融合。在金融業務場景通常會面臨多領域的圖譜構建，領域和領域之間的數據要互通，實現業務價值增益。

• 推理預構圖。是在應用端通過分布式推理實現計算的加速。整個知識的管理，底層以語義圖layout方式表示，上層對接圖計算引擎提高推理的效率。

• 多場景構建。對於事件、概念、實體及關係，不同場景有不同更新頻率，需要支持多種場景下實時和批量知識更新的需求。

語義增強。主要是結合語義知識的表示，提供語義增強的能力。

知識演化。是實現業務數據到知識標準化的過程，包括圖譜Schema及其綁定運算元的增、刪、改，比如把屬性類型從string等基礎類型變更為Brand等可枚舉標準語義類型。

跨域融合。在金融業務場景通常會面臨多領域的圖譜構建，領域和領域之間的數據要互通，實現業務價值增益。

推理預構圖。是在應用端通過分布式推理實現計算的加速。整個知識的管理，底層以語義圖layout方式表示，上層對接圖計算引擎提高推理的效率。

多場景構建。對於事件、概念、實體及關係，不同場景有不同更新頻率，需要支持多種場景下實時和批量知識更新的需求。

2. 基於DFS的知識管理架構

我們整個知識圖譜的知識管理架構分成兩層，下層為存儲層，基於DFS（分布式文件系統）實現全量知識的管理。上層為應用層，通過SDK對接到圖資料庫、圖計算等引擎，支持知識服務、知識推理分析以及知識構建等應用。

這種架構的優勢和特點為：

• 基於DFS的萬億級知識管理及演化。採用存算分離架構具有更好的擴展性和伸縮性，知識演化效率高，成本也比較低。

• 語義增強的屬性圖模型。底層支持RDF和屬性圖混合模型，實現了概念掛載、實體繼承等語義圖能力擴展。

• 零拷貝知識復用。底層根據不同的領域數據按照name space管理，實現了多租戶數據的隔離管理，以及零拷貝的知識復用。

• 多引擎對接。上層通過多引擎對接，支持知識構建、分析和推理等不同的應用；通過預構圖加速推理；支持流批知識增量更新等。

基於DFS的萬億級知識管理及演化。採用存算分離架構具有更好的擴展性和伸縮性，知識演化效率高，成本也比較低。

語義增強的屬性圖模型。底層支持RDF和屬性圖混合模型，實現了概念掛載、實體繼承等語義圖能力擴展。

零拷貝知識復用。底層根據不同的領域數據按照name space管理，實現了多租戶數據的隔離管理，以及零拷貝的知識復用。

多引擎對接。上層通過多引擎對接，支持知識構建、分析和推理等不同的應用；通過預構圖加速推理；支持流批知識增量更新等。

3. 語義知識生產及運算元演化

下面介紹知識生產的過程。一般的，知識圖譜的知識生產過程包括知識抽取、屬性標準化、實體鏈指及融合等幾個關鍵部分。語義知識生產鏈路提供的核心能力包括：

• 基於搜索（向量/文本/LBS索引等）實現大規模的實體鏈指和融合能力。這裡面會用到向量、文本或者LBS的索引能力。舉一個例子，線下支付場景一般存在一個商戶有多個店鋪、一店多碼這種情況，識別商戶同店，就需要用到向量或者LBS索引。

• 知識生產過程支持用戶通過Python/Java SDK自助研發pipeline，並支持運算元版本演化。比如事件抽取服務是通過Python SDK去調用NLP服務實現知識的抽取。

• 知識生產鏈路可適配到blink、spark等通用流批計算引擎，來支持多雲部署。目前完成在螞蟻內部blink適配，以及中信spark等私有雲環境適配。

基於搜索（向量/文本/LBS索引等）實現大規模的實體鏈指和融合能力。這裡面會用到向量、文本或者LBS的索引能力。舉一個例子，線下支付場景一般存在一個商戶有多個店鋪、一店多碼這種情況，識別商戶同店，就需要用到向量或者LBS索引。

知識生產過程支持用戶通過Python/Java SDK自助研發pipeline，並支持運算元版本演化。比如事件抽取服務是通過Python SDK去調用NLP服務實現知識的抽取。

知識生產鏈路可適配到blink、spark等通用流批計算引擎，來支持多雲部署。目前完成在螞蟻內部blink適配，以及中信spark等私有雲環境適配。

接下來以事理圖譜構建為例，介紹語義知識生產過程。

4. 案例：事理圖譜構建

首先我們從中國地震台網發布的一則地震新聞信息，通過NLP模型進行事件抽取，抽取得到地震事件發生的地理位置和時間等關鍵要素。通過屬性的標準化，可以把地震事件的地理位置標準化，歸屬到相應的省市區，然後和中國行政區的標準概念網絡進行關聯。同時，這個事件也會歸屬到事件分類的概念網絡裡面，比如它屬於這個地域的事件，或者是氣象的事件。這樣的好處就是通過這個地震事件，關聯到周邊的一些房地產企業，地震事件對它們的經營產生影響，從而有利於支撐我們對這些企業進行風險評估。

5. 語義增強模型實現

下面介紹如何基於hybrid layout實現語義增強模型。首先，底層有兩種類型的layout，一種就是LPG，通過屬性和圖結構的表示方式實現。另一種是RDF，主要通過SPO三元組索引實現，這也是典型RDF存儲的實現方案。其次，上層通過語義解釋器和schema語義模型聯動，把對圖譜的讀寫流程轉化為底層針對兩種不同layout的讀寫IO。

6. 概念模型實現

概念模型是一個樹狀的分類分層體系，我們對概念樹進行分層編碼，形成概念詞典。這樣的好處是在概念改名時，只需要更新概念詞典信息，而不需要更新索引或者關係的數據。因為和一般的概念關聯的實體非常多，概念一變就涉及整個樹的變更，變更量非常大，用概念詞典就能很好的解決這個問題。

另外，屬性的ID化能夠讓實體的屬性連接到唯一的概念實例，通過構建RDF的SPO索引實現屬性到實體到概念的正反向傳播。這樣的好處是減少了大量的概念到實體之間的物理邊的維護成本。

7. 事件模型實現

事件模型的實現有兩個比較關鍵的要求：一是事件具有時序特性，一般需要支持時間窗口查詢表達，以及TTL版本控制能力。比如通過時間的分片，把所有數據按時間切割成不同的分片，從而提升構建或者推理的效率。

二是事件表達的是多元的關係，需要通過多要素索引支持事件與實體要素的傳播計算。比如線下購買事件，通常會關聯到一個用戶、一個商品，也會關聯到一個商店和它的地理位置信息。這和傳統的pairwise二元關係還是有區別的。為了實現事件到實體要素之間的傳播，我們需要構建它的多維索引，包括事件關聯的實體要素索引，以及實體要素到事件的索引。

8. 基於事件模型構建資金圖譜案例

接下來我們通過螞蟻資金圖譜的一個例子介紹如何通過事件模型構建圖譜。螞蟻資金圖譜構建的背景是公安反詐。公安部門接到一筆資金報案之後，需要查看資金的流向，判斷資金流向涉及的個人信息。資金溯源的過程牽扯到很多人工線下操作，查控操作繁瑣，通常要耗費好幾個小時，分析成本很高。我們提供了兩個能力來解決這個問題。

一是通過事件模型把千億級的資金交易事件，與交易發生的WIFI和地理位置等信息融合，來構建螞蟻資金圖譜，把交易事件、設備和時空的信息關聯起來，更便於分析洗錢的帳戶及黑產信息，輔助公安部門偵查。

二是基於大規模資金交易事件進行資金的深度追蹤，結合沉澱的大量資金事件專家規則，能夠實時洞察每一筆資金的流向，提升案件偵查的效率。

資金圖譜支持資金追蹤的可視化分析、一鍵處理，大幅提升了偵查效率，目前在多個省市的幾十家公安部門中試用，凍結折還的資金已經達到了數百萬。

9. 分布式推理構圖實現

分布式知識推理過程基於圖計算引擎實現，整個推理的流程包括構圖和圖疊代兩個部分。我們採用圖表示的存儲模型，能更高效對接GeaFlow等圖計算引擎，實現無shuffle構圖，提升推理效率。測試表明，我們現在的這種知識管理方案，比以前直接基於table的關係模型，實現了構圖效率的大幅提升。後續我們也會和TuGraph團隊合作，更好地實現引擎銜接，做到無序列化推理構圖。另外我們也在探索局部性友好的知識編碼，提升圖疊代效率。

10. SPO索引：語義圈人

語義圖推理一個比較重要的場景是語義圈人，特別是營銷推薦。語義圖推理本質上是一個子圖匹配的過程，如圖所示。比如我們圈選一些商家，通過品牌偏好、城市、職業和收入等級去圈選需要投放的營銷用戶群體。這可以轉化為RDF SPO索引的join問題。面臨的技術難點是，這個語意圖熱點問題非常突出。比如一個運動的品牌或者一個城市，它關聯的用戶和商家非常多。我們提出了兩個解決方案。

一是在分布式的計算場景上實現subject分區優化，提升計算的局部性，減少消息的傳遞。二是在多條件情況下選擇合適的join算法（如BinaryJoin、WCOJ等），優化dense/sparse下的搜索空間。

11. 知識復用-實體繼承

實體繼承是語義知識復用的一個非常典型的場景。在螞蟻的內部場景中，我們的POI/AOI，支付寶用戶等億級別的實體復用，已經用到了實體繼承。實體繼承類似面向對象的繼承概念，比如一個公司實體，它有一些通用屬性。而在這個公司上面還有上市公司，上市公司會有市值等特有屬性信息。實體繼承就是要解決子父類屬性的冗餘和一致性問題，即通過一種方案，使得查詢或者推理在獲取子類屬性的時候，能夠動態拼接父類的屬性。我們的解決方案首先是子類和父類實體的ID相同，各自屬性保持獨立更新和互為索引。然後在讀取端通過語義解釋器，生成readPlan，實現子父類實體的屬性動態IO合併。

12. 知識復用-圖譜融合

圖譜融合是知識管理的一個難點，也是非常重要的業務場景。圖譜融合簡單來說就是把兩個領域的圖譜通過某種方式融合到一起，實現兩個領域的圖譜互通，解決數據孤島問題。由於圖本身的連通性，實現兩個圖譜融合，涉及的數據範圍非常廣，所以首先要解決數據冗餘的問題。我們把圖譜融合分成兩個階段，第一個階段叫做鏈指，第二個階段叫做歸一。鏈指是指在兩個不同的領域圖譜裡面選擇一個錨點實體，通過鏈指算法建立這個錨點實體的關聯。歸一是指對這個錨點實體對應的子圖信息進行合併的過程。

如果把歸一的過程放在構建端，每一次錨點實體的更新，都會觸發圖數據的歸併，這個成本非常高。因為一個點關聯的周邊關係或者一度子圖，可能是非常龐大的。所以我們在構建融合實體的時候，都是把它作為一個虛擬的實體存在，僅存儲鏈指的idmap和它的局部子圖信息。更重要是融合算法或者規則發生更新的時候，鏈指關係的變化只會觸發增量更新，更好地適應算法的疊代。

13. 螞蟻圖譜融合案例：金融消費

我們舉一個金融消費的例子解釋螞蟻知識圖譜的融合場景。在這個例子裡，我們有兩個不同領域的圖譜，一個是用戶消費側的知識圖譜，另一個是商家供給側的知識圖譜，兩個都是數百億的知識圖譜。消費側知識圖譜關注消費的場景信息，供給側知識圖譜關注的是商家的品牌、類目、門店以及地理位置等信息。通過把用戶或者商戶作為錨點實體就可以建立兩個圖譜之間的零拷貝關聯。商戶作為消費金融產業鏈重要的一環，串聯起了用戶和消費場景。通過關聯，這樣圍繞商戶的關係就更加豐富，表征能力更強，提升了商戶的畫像刻畫能力。

04

展望

我們對大規模語義知識管理的未來展望，一個是面向DataFabric的企業級知識管理平台，另一個是跨領域知識共享與應用。

1.面向DataFabric的企業級知識管理平台

我們的目標是建設面向DataFabric的企業級知識管理平台，主要方向包括：

• 知識圖譜的數據管理平台，位於數據湖或者數據倉儲之上，它可以集成並管理結構化、非結構化等多源數據。

• 通過語義增強模型實現數據到知識的約束和統一表示。同時，通過開放的API，支持不同的企業應用場景。

• 在知識管理過程中，需要遵循企業數據管理標準，實現血緣追蹤、數據安全和質量保證等機制。

知識圖譜的數據管理平台，位於數據湖或者數據倉儲之上，它可以集成並管理結構化、非結構化等多源數據。

通過語義增強模型實現數據到知識的約束和統一表示。同時，通過開放的API，支持不同的企業應用場景。

在知識管理過程中，需要遵循企業數據管理標準，實現血緣追蹤、數據安全和質量保證等機制。

2. 跨領域知識共享與應用

我們的最終目標是實現跨領域的知識共享和應用，主要方向包括：

• 推進知識語義化、標準化，兼顧工業界落地和業務的理解成本。

• 在實現跨機構、跨主體的知識互聯的時候，需要更多的考慮隱私計算。另外就是沉澱行業解決方案，輔助更多的機構應用知識圖譜。

• 知識管理和大模型結合，例如利用高質量知識圖譜，提升大模型在推理上準確率和專業性，增強大模型的在金融等特定領域的知識深度。

推進知識語義化、標準化，兼顧工業界落地和業務的理解成本。

在實現跨機構、跨主體的知識互聯的時候，需要更多的考慮隱私計算。另外就是沉澱行業解決方案，輔助更多的機構應用知識圖譜。

知識管理和大模型結合，例如利用高質量知識圖譜，提升大模型在推理上準確率和專業性，增強大模型的在金融等特定領域的知識深度。

05

Q&A

Q1 ：知識管理平台底層有屬性圖和RDF圖，兩者是相對獨立的存儲，那他們是怎麼融合的？在查詢引擎上是用哪種方式融合的？

A：我們知識管理平台提供語義增強的圖譜schema和底層倉儲SDK，包括build、query、scan等構建和讀取圖譜的API或tool。這些API裡面植入了一些語義和我們的語義模型去聯動，通過語義解釋器實現底層的RDF或者是LPG文件的讀取IO。

上層和GeaFlow圖計算引擎銜接，它調用query或scan等SDK實現對圖譜語義數據的加載，這些SDK的輸出會轉換成圖計算引擎能識別的屬性圖。

Q2 ：歸一的結果是將不同領域的同一實體在融合圖中形成了同一個主鍵嗎？

A：歸一是將兩個實體的圖結構合併為一個實體圖結構的過程，包括屬性和關係的合併和衝突解決。兩個圖結構分別維護不同領域的數據，最後在應用的時候，用戶看到的是一個新的實體類型，我們把它叫做融合實體，融合實體在讀取時按需做圖結構合併，解決了存儲冗餘的問題。

Q3 ：知識管理平台融合了很多的引擎，比如GeaFlow、GeaBase、Flink等，現在有沒有一種語言能把它們都包裝起來，實際使用的時候的入口是同一個？

A：現在整個應用端分成兩部分，一個叫做構建側或者叫生產側，另一個叫做推理側或者服務側。在服務側，現在正在推進的就是通過接口統一去表達。在生產側，因為知識的構建是一個並行計算場景，不一定是圖計算場景，它通過一個流水線SDK去表示。這個流水線SDK會植入一些運算元或者組件，比如我們剛才提到的實體鏈指組件，然後通過執行計劃的翻譯，適配運行在Flink或spark等不同計算引擎上。