一、螞蟻金融知識圖譜平臺介紹

首先介紹知識圖譜的發(fā)展和螞蟻知識圖譜平臺的現(xiàn)狀。

1、知識圖譜的發(fā)展

根據《艾瑞咨詢：2022年中國知識圖譜行業(yè)研究報告》，2021年，知識圖譜在國內的核心市場規(guī)模預計達到百億元級別。到2026年，相應規(guī)模將超過296億元，每年復合增長率超過20%。其中金融和公安兩大行業(yè)的占比較高而且增長的速度更快一些。

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

2、螞蟻知識圖譜平臺目標

螞蟻知識圖譜平臺建設初期遇到了幾個挑戰(zhàn)：

• 大量復雜的跨業(yè)務域多元關系。在金融領域，面臨的業(yè)務場景是多元化的，如支付、安全、保險、財富等。
• 多個不同職能的用戶群體。面向不同職能的用戶群體比較多，比如算法、運營、數據等。
• 分析/決策實時化要求。圖譜的分析或者決策的實時性要求比較高。比如面向C端的保險理賠這些場景。
• 專家規(guī)則的復雜性。比如安全風控領域的專家規(guī)則就十分復雜。

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

3、螞蟻金融知識圖譜建設現(xiàn)狀

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

二、語義知識表示模型

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

1、語義化的作用

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

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

2、知識分類和定義

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

• 實體。比如用戶、企業(yè)、商戶等這些業(yè)務相關性比較強的客觀存在的實例，它是一些個體。
• 概念。概念是對一類實體的抽象概述。比如人的個體，可以分成喜歡運動的，喜歡旅游的，等等，給一類人群貼上標簽，就成為人群的概念。
• 事件。第三類是會動態(tài)發(fā)生變化的事件，它對實體類型加入了時間、空間等約束，比如企業(yè)的事件、診療的事件，或者交易的事件。

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

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

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

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

因此，我們提出了一種語義增強的屬性圖模型，它是結合了LPG和RDF優(yōu)勢的混合模型，更適合業(yè)務數據到知識標準化的演化過程。它提供業(yè)務易理解的表達，更利于知識復用，可規(guī)?；涞?。

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

• 邏輯推演。包括symmetric（spouse），transitive（located_in）等。以可傳遞性為例，比如說某個人位于成都市，那他一定位于四川省。
• 數據完整性約束。包括mutexOf等。以互斥類型為例，如果兩個人是兄弟關系，就一定不是父子關系。
• 屬性類型約束。語義增強的屬性圖模型，它支持int、string這些基礎屬性類型，也支持City等標準類型。區(qū)別于String類型，標準類型可枚舉，支持實體間可傳播計算，基礎類型演化到標準類型，即可實現(xiàn)屬性圖到語義圖內置轉換。
• 實體衍生/鏈指。包括subClassOf、equivalent、fuse等，主要是知識復用的約束范式。

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

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

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

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

• 語義增強。主要是結合語義知識的表示，提供語義增強的能力。
• 知識演化。是實現(xiàn)業(yè)務數據到知識標準化的過程，包括圖譜Schema及其綁定算子的增、刪、改，比如把屬性類型從string等基礎類型變更為Brand等可枚舉標準語義類型。
• 跨域融合。在金融業(yè)務場景通常會面臨多領域的圖譜構建，領域和領域之間的數據要互通，實現(xiàn)業(yè)務價值增益。
• 推理預構圖。是在應用端通過分布式推理實現(xiàn)計算的加速。整個知識的管理，底層以語義圖layout方式表示，上層對接圖計算引擎提高推理的效率。
• 多場景構建。對于事件、概念、實體及關系，不同場景有不同更新頻率，需要支持多種場景下實時和批量知識更新的需求。

2、基于DFS的知識管理架構

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

這種架構的優(yōu)勢和特點為：

• 基于DFS的萬億級知識管理及演化。采用存算分離架構具有更好的擴展性和伸縮性，知識演化效率高，成本也比較低。
• 語義增強的屬性圖模型。底層支持RDF和屬性圖混合模型，實現(xiàn)了概念掛載、實體繼承等語義圖能力擴展。
• 零拷貝知識復用。底層根據不同的領域數據按照name space管理，實現(xiàn)了多租戶數據的隔離管理，以及零拷貝的知識復用。
• 多引擎對接。上層通過多引擎對接，支持知識構建、分析和推理等不同的應用；通過預構圖加速推理；支持流批知識增量更新等。

3、語義知識生產及算子演化

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

• 基于搜索（向量/文本/LBS索引等）實現(xiàn)大規(guī)模的實體鏈指和融合能力。這里面會用到向量、文本或者LBS的索引能力。舉一個例子，線下支付場景一般存在一個商戶有多個店鋪、一店多碼這種情況，識別商戶同店，就需要用到向量或者LBS索引。
• 知識生產過程支持用戶通過Python/Java SDK自助研發(fā)pipeline，并支持算子版本演化。比如事件抽取服務是通過Python SDK去調用NLP服務實現(xiàn)知識的抽取。
• 知識生產鏈路可適配到blink、spark等通用流批計算引擎，來支持多云部署。目前完成在螞蟻內部blink適配，以及中信spark等私有云環(huán)境適配。

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

4、案例：事理圖譜構建

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

5、語義增強模型實現(xiàn)

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

6、概念模型實現(xiàn)

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

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

7、事件模型實現(xiàn)

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

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

8、基于事件模型構建資金圖譜案例

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

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

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

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

9、分布式推理構圖實現(xiàn)

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

10、SPO索引：語義圈人

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

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

11、知識復用-實體繼承

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

12、知識復用-圖譜融合

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

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

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

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

四、展望

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

1、面向DataFabric的企業(yè)級知識管理平臺

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

• 知識圖譜的數據管理平臺，位于數據湖或者數據倉儲之上，它可以集成并管理結構化、非結構化等多源數據。
• 通過語義增強模型實現(xiàn)數據到知識的約束和統(tǒng)一表示。同時，通過開放的API，支持不同的企業(yè)應用場景。
• 在知識管理過程中，需要遵循企業(yè)數據管理標準，實現(xiàn)血緣追蹤、數據安全和質量保證等機制。

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

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

• 推進知識語義化、標準化，兼顧工業(yè)界落地和業(yè)務的理解成本。
• 在實現(xiàn)跨機構、跨主體的知識互聯(lián)的時候，需要更多的考慮隱私計算。另外就是沉淀行業(yè)解決方案，輔助更多的機構應用知識圖譜。
• 知識管理和大模型結合，例如利用高質量知識圖譜，提升大模型在推理上準確率和專業(yè)性，增強大模型的在金融等特定領域的知識深度。

五、Q&A

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

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

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

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

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

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

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