筆者自2011年大二的時候加入北大計算所圖數(shù)據(jù)庫小組直到18年博士畢業(yè)，此后工作的兩年一直關注圖技術的發(fā)展，并同很多同行和圖庫的潛在客戶有較多接觸。同時也參與過知識圖譜、圖計算系統(tǒng)以及圖表示學習算法等的研發(fā)。本篇的內容主要從圖模型、圖查詢以及圖計算和圖學習四個方面著手闡述，重點介紹對圖的應用上的經(jīng)驗、思考，討論關于圖有哪些應用、為什么有用、怎么用以及哪些地方難用或無用、為什么沒用等內容，避免復雜概念或公式以保證非技術人員也能充分理解，相信這篇文章能讓大家開卷有益，也歡迎大家來一起討論。

1 圖模型

1.1 圖的點、邊、標簽、屬性與同異構

圖論中，圖（Graph）的符號往往用G表示，圖被定義為一個多元組，核心元素為頂點（vertex）集V以及邊（edge）集E，即G=（V，E）。從數(shù)據(jù)的角度，頂點可以理解為針對實體、對象的建模，邊則是用于描述兩個頂點間的關聯(lián)或交互。給定兩個頂點u,v, 用（u,v）表示兩點間的邊。此外，圖的多元組中往往還有標簽函數(shù)L（指向點邊的標簽）、屬性函數(shù)P（指向點邊的屬性）以及點邊類型函數(shù)T等等。比如，社交網(wǎng)絡中異常的賬號可能有色情、賭博等標簽。賬號可以有注冊時長的屬性，所屬用戶年齡屬性等。而好友關系的邊則可以有好友建立時間點的屬性。值得一提的是，點邊均只有一種類型的圖稱為同構圖，比如轉賬網(wǎng)絡中只有用戶賬號一種點類型，并且只有轉賬關系這一種邊類型，因此轉賬網(wǎng)絡為同構圖。除了同構圖之外的圖均為異構圖。如微信支付的交易網(wǎng)絡中，用戶賬號間的交易既可以轉賬，也可以是紅包或者面對面，因此支付交易網(wǎng)絡的邊不僅有一種類型，微信支付的交易網(wǎng)絡是異構圖

1.2 圖形式簡單，圖問題復雜

圖論起源于歐拉對哥尼斯堡七橋問題的研究。七橋問題是指如何能夠不走重復路的情況下走遍哥尼斯堡的七座橋，其實就是現(xiàn)今大家熟知的一筆畫的問題。形式很簡單，但解決卻不容易。歐拉通過將七橋問題形式化為點邊的一筆畫問題來解決。這種簡潔的點邊建模思路為后世的學者沿用發(fā)展，逐漸形成了圖論體系。圖論問題在高中數(shù)學聯(lián)賽試題中很常見，這個點跟圖模型的一個重要特性有或多或少的關聯(lián)：圖模型的形式足夠簡單，但圖模型下提出的問題往往很復雜。這個特點也引來不少對圖饒有興趣卻不求甚解的同行，時常把簡單問題復雜化以獲取信息不對等優(yōu)勢進而行不實宣傳，導致大量圖的潛在使用者的時間浪費與業(yè)界對圖的信心受挫。 希望此篇能夠澄清圖的相關概念與作用，幫助大家在圖應用上少走彎路。

1.3 高效的關聯(lián)表達與分析能力

圖的形式雖然簡潔，但是對信息的表達能力卻非常強。

復雜信息的建模與融合

人們每天獲取的信息，不限任何主題或領域，大都可以一條或多條陳述句來表達。例如“拜登當選了美國總統(tǒng)”，“Twitter封殺了特朗普”。陳述句的主體大都可以表示為主謂賓，如三元組:<主語：拜登， 謂語：當選，賓語：美國總統(tǒng)>以及<主語：Twitter，謂語：封殺，賓語：特朗普>。而圖模型可以很好地建模主謂賓，即以主、賓為兩個對象（頂點），以謂語表示對象間的關聯(lián)或交互（邊）。因此圖模型能很好地建模主謂賓，進而建模陳述句、信息。而且，這里不對信息做任何主題或者領域的限制，因此圖模型能以簡潔的形式對復雜知識信息進行良好的建模和融合。

高效的關聯(lián)發(fā)現(xiàn)與分析

圖做關聯(lián)分析的高效性來源于其本身對關聯(lián)的存儲與頂點的低冗余度。以“旅美物理學家吳健雄與中國近代權臣袁世凱有什么關系”這一問題為例，為了回答這一問題，在傳統(tǒng)的關系數(shù)據(jù)庫中，需要先在各種可能的關系表里定位“吳健雄”，而“吳健雄”在同一表中的出現(xiàn)可能相當冗余，因為每個“吳健雄”相關的關系實例中“吳健雄”均會出現(xiàn)一次，存在冗余的計算代價。而在圖模型中，定位單個“吳健雄”的出現(xiàn)就能夠同時定位其相關的所有關聯(lián)關系，如鄰接表。更簡潔地說，在傳統(tǒng)關系數(shù)據(jù)庫中，以上關聯(lián)分析往往會在大量表上進行代價高昂的join過程，效率低下，尤其是多個join串聯(lián)的計算。而在圖模型中，由于圖本身直接存儲了部分關聯(lián)，同時對頂點及其直接關聯(lián)的定位能夠足夠高效（相比于join），進而使得圖的關聯(lián)發(fā)現(xiàn)與分析足夠高效。 此外，在對傳統(tǒng)關系數(shù)據(jù)多級join的優(yōu)化過程，往往也將關系數(shù)據(jù)進行圖模型化的過程?；氐?ldquo;吳健雄”與“袁世凱”關系的問題，這個問題在圖模型中會以路徑的形式來建模，而圖算法中有大量針對路徑的優(yōu)化工作，這也是圖模型關聯(lián)高效性的一個來源?？偟膩碚f，圖對關聯(lián)的聚焦，帶來了能夠保證高效關聯(lián)分析的相關方法論與技術手段，這點促進了圖關聯(lián)分析的高效。

1.4 圖系統(tǒng)的三大類功能

目前圖技術的應用主要通過三個技術點的支撐來實現(xiàn)，分別是圖查詢、圖計算和圖表示學習。

圖查詢主要是對圖關聯(lián)數(shù)據(jù)的基礎查詢，旨在直接獲取關聯(lián)信息，包括多階鄰居查詢、路徑查詢與子圖查詢。此外圖可視化也是輔助圖查詢結果的展示，是提高圖關聯(lián)分析效能的重要組件。圖計算是指針對全圖結構進行重組、抽象或者傳播迭代得到點/邊全局屬性的過程，如圖的聚類、分割、生成樹、PageRank的計算等等。國際學術界常用Graph Processing System表示圖計算系統(tǒng)，中文翻譯過來是圖處理系統(tǒng)，但中文語境下圖計算這個詞更為形象，也使用的更為普遍。

圖學習主要是指圖表示學習，將圖中的頂點映射到低維向量空間，要求向量間的相對距離能夠盡可能地反映原頂點在圖結構關聯(lián)強度上的相對大小，實現(xiàn)非歐圖數(shù)據(jù)向歐式向量空間的轉變（圖數(shù)據(jù)無法滿足歐式空間約束）。歐式的向量數(shù)據(jù)能夠作為特征，更直接地支撐下游的業(yè)務需求。圖的關聯(lián)數(shù)據(jù)與用戶屬性數(shù)據(jù)有明顯的不同，是業(yè)務瓶頸提升探索上的一個非常重要的新視角。

圖學習經(jīng)常被歸入圖計算范疇內討論。其實兩者內涵迥異。其中最大的不同點在于，圖計算的結果仍然在圖語義范圍內有清晰的解釋，如PageRank作為頂點的網(wǎng)絡中心性度量，而圖學習的結果是向量集，同圖語義無交集。圖計算和圖學習在學術界也是較為不同的學者群體在各自研究。后文將以筆者在業(yè)務實踐中，對圖的三大類技術點的應用思考展開討論。

2 圖查詢

圖查詢包括單點的多階鄰居查詢、兩點間的關聯(lián)路徑查詢以及獲取多點間關聯(lián)的子圖查詢。除此之外我們也會討論驅動圖查詢的圖數(shù)據(jù)庫的現(xiàn)狀，騰訊公司圖數(shù)據(jù)庫Oteam的產品EasyGraph以及知識圖譜等相關內容。

2.1 多階鄰居查詢

同某個頂點v有關聯(lián)邊的所有頂點均為v的鄰居，如圖所示，以中心紅色頂點v為源頂點，綠色頂點為v的鄰居，也稱為一階鄰居；綠色頂點的鄰居集合里，去除v自身以及所有綠色頂點，剩下的頂點稱為v的二階鄰居，如圖中的藍色頂點；依次類推得到v的三階鄰居，即圖中的紫色頂點。

圖查詢應用點很多，這里介紹常見的四種應用點：多階擴散、近鄰分布、關聯(lián)可視化展示、特定鄰居搜索。

多階擴散 多階擴散是較為常見的圖查詢操作。近鄰往往同自身關系密切或屬性相近，多階擴散則是用來獲取同自身屬性一致或相近的人群。例如在特定標簽的人群識別中，同類人群往往形成社區(qū)并且彼此間緊密關聯(lián)，從已知的標簽人群出發(fā)，通過相應標簽場景的緊密的關聯(lián)（如業(yè)界常見的共同設備）擴散出的人群往往能覆蓋未知的標簽人群。值得注意的是，擴散后的人群也往往也可能包括正常人群，因此擴散結果需要進一步的過濾處理。實踐中，圖的多階查詢效率比傳統(tǒng)關系型系統(tǒng)的join操作在性能上高出2~3個數(shù)量級。

近鄰分布 多階鄰居查詢也用來獲取近鄰分布，進而更精準地刻畫用戶自身特定屬性。例如，程序員在社交網(wǎng)絡關聯(lián)的鄰居里，具有程序員標簽的用戶密度會明顯偏高。對于一個未知標簽的用戶，可以通過其社交網(wǎng)絡或資金網(wǎng)絡多階鄰居中已知的用戶分布來輔助確定用戶是否具有相應的屬性。

關聯(lián)畫像 對于給定的一個頂點，多階鄰居的全貌展示能夠有助于對頂點更深刻的理解，即通過多階鄰居的關聯(lián)來對頂點進行畫像。這類應用的落地主要通過圖可視化工具對多階鄰居的展示來完成，如天眼查等通過關聯(lián)可視化落地的應用。

特定鄰居搜索 多階鄰居的查詢也能獲取特定的鄰居進行強化關聯(lián)。以社交網(wǎng)絡為例，每個人的一階好友關系為其可見的人脈集合，而二階好友往往是每個人的人脈盲區(qū)，通過特定的二階好友的查詢能夠精確定位到符合需求的人脈。舉現(xiàn)實例子來說，假設一名患者想在赴診前對某醫(yī)院某科室醫(yī)生提前進行健康咨詢，而該患者一階人脈并無覆蓋該科室的任何一名醫(yī)生，如果該患者能夠找到同某個目標醫(yī)生的公共好友，則可以通過公共好友同目標醫(yī)生建立直接的關聯(lián)關系，實現(xiàn)提前的健康咨詢。

多階查詢往往最大階數(shù)為3，因為4階及以上查詢結果將非常龐大難以處理。此外，高階的鄰居同源點的關聯(lián)強度也隨著階數(shù)的增長而不斷下降。因此，從經(jīng)驗的角度看，多階鄰居查詢一般最多到3階。

2.2 路徑查詢

路徑的一般定義為：兩點間能夠連通起來的邊的集合。如下圖從史玉柱到深大，從深大到張維，從張維到高曉松的三條邊的集合即構成了史玉柱到高曉松的一條路徑。

[[378232]]

路徑聚焦兩點間的間接關聯(lián)關系。間接關聯(lián)獲取成本更大，更為隱蔽。在金融欺詐場景中，犯罪團伙往往將資金關聯(lián)拉長以進行對抗，如將直接的資金往來通過多階的轉賬來間接實現(xiàn)。傳統(tǒng)的關系型數(shù)據(jù)平臺因串聯(lián)join的低效性導致路徑查詢成本高昂難以實現(xiàn)，而路徑查詢是圖研究領域的經(jīng)典問題，通過對路徑的高效查詢能夠降低間接關聯(lián)的發(fā)現(xiàn)成本，提高欺詐團伙的對抗門檻。

例如，在刑偵場景中，案件里的受害人與施害人的關聯(lián)也是刑警首要關注的信息。如果能構建足夠大的一張圖，包括多種關聯(lián)關系信息（圖有很強的數(shù)據(jù)融合能力），則通過在該圖中獲取受害人與施害人之間的所有路徑，就能清晰展現(xiàn)兩者間的各種直接與間接的關聯(lián)關系。高效地進行路徑查詢則有利于提高案件分析的效率。

億級圖上，路徑查詢的目標路徑長度一般不會大于6（受限于計算能力），而實際需求往往不會大于4（關聯(lián)信息衰減），查詢過程往往是從兩點分別向對方搜索，將兩點各自的多階鄰居進行取交，實現(xiàn)路徑的發(fā)現(xiàn)。每個頂點最多往外搜索的深度為3。正如前面多階查詢所說，搜索深度大于等于4時，搜索空間容易過于巨大。（以上數(shù)據(jù)經(jīng)驗之談，僅供參考）

2.3 子圖查詢

子圖的概念是相對一個更大的圖來定義的。如果一個圖的點集和邊集都是另一個圖的子集，則該圖為另外一個圖的子圖。以微信支付月度轉賬網(wǎng)絡為例，該月騰訊公司員工之間的轉賬關系則是構成了一個轉賬網(wǎng)絡的子圖。

子圖查詢最直接的優(yōu)點就是對數(shù)據(jù)需求的表達能力很強。假設我們有一個查詢需求：“在國務院工作并且家鄉(xiāng)在安徽的博士有哪些？”已有的查詢理解方式往往只是從查詢中抽取關鍵字來進行，而子圖的方式則更為精準，如下圖所示。子圖能夠理解查詢的目標是個頂點，頂點有三條關聯(lián)的邊，分別是對“國務院”的就職關系，對“安徽”的家鄉(xiāng)定位關系以及對“博士學位”的學歷關系。而通過子圖同構的查詢，則能夠對查詢需求進行更為精準地響應。

子圖也可以用來構建通用的行為特征。例如針對頂點及其一階或多階的鄰居構成的頻繁子圖（復雜網(wǎng)絡領域定義為Motif，Wikipedia顯示Motif的本質定義就是頻繁子圖），將對應頻繁子圖的頻次定義成特定維的特征，這樣的特征是對頻繁子圖的數(shù)值化描述，因此具有較強的穩(wěn)定性和一定程度的可解釋性。

子圖的第三個優(yōu)點，也是非常重要的優(yōu)點就是描述多點多階關聯(lián)，如導出子圖：給定圖G及其點集V的某個子集V’，假設邊集子集E’對應G中頂點同時屬于V’的所有的邊，則子圖（V’，E’）為G在V’上的導出子圖。即導出子圖是給定點集子集的情況下，邊集最大的子圖。從數(shù)據(jù)的角度來說，給定一個頂點集，其導出子圖能描述頂點集在原圖上的所有的關聯(lián)關系。在微信支付反欺詐中，經(jīng)常會遇到做法手法高度一致的一批用戶賬號，即欺詐團伙。挖掘并打擊團伙的關鍵在于分析出團伙是組織的，而導出子圖的查詢則能夠對批量賬號查詢其間所有的相互關聯(lián)。例如，我們曾發(fā)現(xiàn)一個典型的欺詐手法，欺詐分子以少女形象，通過網(wǎng)絡同新認識的用戶約定，如果該用戶向“少女”的前男友發(fā)送48元轉賬（48為某不和諧用語諧音）并備注侮辱性用詞，則“少女”將返現(xiàn)1000給到新認識的用戶。

利用這一套路行騙的不同賬號數(shù)超過一千，是我們重點打擊的團伙。通過hive進行代價高昂的同設備、同證件、同地理位置等關聯(lián)時，并沒有發(fā)現(xiàn)特別的團伙痕跡。經(jīng)過大量的高昂代價關聯(lián)后，我們最終發(fā)現(xiàn)了欺詐分子真實的關聯(lián)方式。如果我們構建支付欺詐場景下的多種關聯(lián)形成大圖，在遇到作案手法高度一致的批量賬號時，直接在大圖上進行導出子圖查詢，則能夠高效且全面地獲取賬號團伙的蛛絲馬跡并順藤摸瓜打擊所有欺詐賬號。

2.4 圖數(shù)據(jù)庫

目前驅動以上查詢的主要是圖數(shù)據(jù)庫，針對已有圖數(shù)據(jù)庫的最新詳實的對比信息可以在DB-Engine( https:// db-engines.com/en/ranki ng/graph+dbms ) 上獲取。圖庫的潛在使用者該如何選擇圖數(shù)據(jù)庫？這一問題也等價于技術圈該如何發(fā)展圖數(shù)據(jù)庫。這里不得不提一個目前普遍存在的現(xiàn)象：技術圈對圖數(shù)據(jù)庫的發(fā)展同業(yè)務圈對圖庫的需求定位存在明顯不一致。

技術與業(yè)務對圖庫定位的分歧 已了解到的圖應用場景中，對圖數(shù)據(jù)庫的功能與性能需求暫時沒有到線上數(shù)據(jù)庫的級別，對圖數(shù)據(jù)庫的讀寫要求大體是周期性地批量導入或寫入之后，進行多次只讀。因此與其說圖數(shù)據(jù)庫，不如說圖分析平臺更為貼切。而且，在圖操作的事務管理方面，研究上都還有較大空白，進展寥寥，實際落地上更是困難重重。業(yè)務側對圖的需求重點仍然是數(shù)據(jù)分析為主，而技術圈以數(shù)據(jù)庫視角去發(fā)展圖系統(tǒng)的卻是主流，已知的很多圖數(shù)據(jù)產品團隊在以性能為重點內容做宣傳。而其實從業(yè)務的角度，性能只要達到一定程度（比如一秒內響應）就沒有迫切的提高性能的需求（比如十毫秒級）。

再者，圖數(shù)據(jù)庫對屬性數(shù)據(jù)的管理相比傳統(tǒng)關系型數(shù)據(jù)庫毫無優(yōu)勢。點邊屬性數(shù)據(jù)的獲取與關聯(lián)無關，考慮點屬性或邊屬性的查詢時，點、邊均為孤立的存在，而孤立的點、邊在圖數(shù)據(jù)模型中意義相當有限。據(jù)說某大廠內部，有部分圖數(shù)據(jù)庫產品中的屬性管理仍然交由傳統(tǒng)關系型數(shù)據(jù)庫管理。因此，技術圈與業(yè)務圈對圖庫定位存在分歧，不過隨著越來越多的圖庫應用落地，這種分歧似乎在不斷減少，圖技術與實際業(yè)務更多的碰撞令人期待。

Easygraph（ http:// easygraph.oa.com ）落地過程中遇到的數(shù)據(jù)導入圖庫的成本與思考

技術圈對數(shù)據(jù)導入圖庫過程中開發(fā)人員所消耗的時間成本其實存在明顯的忽視。EasyGraph作為騰訊公司圖數(shù)據(jù)庫Oteam協(xié)同開源的一款產品，經(jīng)歷了微信支付欺詐業(yè)務場景下多次迭代優(yōu)化，也是圖庫在技術和業(yè)務上的一次難得的結合。在微信支付欺詐場景下，同EasyGraph團隊的合作過程中，筆者對圖庫在業(yè)務應用上的理解要加深了許多。例如，欺詐場景中非常關心的一點是欺詐分子之間或欺詐分子與受騙人之間的關聯(lián)和交互，進而制定相應的策略或模型進行精準打擊。核心點在于，關聯(lián)數(shù)據(jù)的查找和可視化。傳統(tǒng)的hive在關聯(lián)數(shù)據(jù)的查找上效率低下，而已有的圖數(shù)據(jù)庫，雖然能夠加速關聯(lián)查詢，卻忽略了另一重大的成本：數(shù)據(jù)導入圖庫。當有一個圖數(shù)據(jù)可視化需求時，往往需要先進行既定格式的數(shù)據(jù)出庫（如HDFS），填寫相應圖庫的配置文件，再啟動圖庫導入。

不同的圖庫產品往往有不同的導入格式和流程。當可視化過程中需要對關聯(lián)結果進行微調時，整個流程需要再進行一遍，過程繁瑣費時。數(shù)據(jù)導入圖庫的成本高昂其實在VLDB 2018的best paper [1]里就重點提到，該論文的核心內容是關于加拿大滑鐵盧大學的Semih針對圖應用的調研分析。時隔兩年，大量圖數(shù)據(jù)庫的數(shù)據(jù)導入成本仍然很高，以筆者所了解的情況，騰訊公司的EasyGraph圖數(shù)據(jù)庫對數(shù)據(jù)導入成本問題解決得較為完善。在EasyGraph落地微信支付場景的過程中，我們迭代了三個版本的圖庫導入。

①最開始的版本則是通過預處理組件，按既定格式出庫數(shù)據(jù)到HDFS，并通過配置文件啟動導入；②之后，我們推動了通過UI交互的方式直接對數(shù)據(jù)源進行相關配置的導入方式，如瀏覽器端的庫表配置，從列名等字段到點邊及其屬性的映射等。避免了配置文件和數(shù)據(jù)預處理腳本開發(fā)的成本。但其實對構圖成本解決仍不夠徹底，因為可視化的數(shù)據(jù)源往往需要數(shù)據(jù)分析者先創(chuàng)建相應的臨時表，占用存儲和元數(shù)據(jù)開銷。即便用視圖來優(yōu)化這一問題，隨著時間的推進，圖數(shù)據(jù)庫中仍然需要定期清理相應的臨時視圖等。

基于此，EasyGraph團隊又迭代了第三個版本，通過類sql-schema的邏輯，一行簡潔的代碼就能完成導入，具體導入語法此處不詳述，而且第三版的導入方式很大地減少了圖庫使用者的數(shù)據(jù)導入成本。這里也給出一個筆者在支付場景下思考獲得的一個圖庫導入設計，這個設計啟發(fā)于 hive create table as select x,x,x from t_xxxx 的語法。數(shù)據(jù)分析者僅需要針對點邊及其屬性數(shù)據(jù)寫select的查詢來反應需求，由圖庫自身將SQL語法解析出對應的查詢計劃并從SQL數(shù)據(jù)庫表中直接獲取數(shù)據(jù)并完成相應schema構建和數(shù)據(jù)導入。數(shù)據(jù)分析者僅需要撰寫寥寥幾個其足夠熟悉且通用的SQL語句，語句中可以通過SQL語法中的限制條件語句對數(shù)據(jù)需求進行詳細定制。這點其實對技術來說，完全可以實現(xiàn)。

2.5 知識圖譜

已有的知識圖譜可以直觀理解為知識+圖譜，即用圖的模型與方法對知識數(shù)據(jù)進行建模、存儲與查詢挖掘。知識很有用，圖譜也有用，所以知識圖譜肯定有用，但是大家肯定期待知識和圖譜結合起來，有什么新的用處，諸如推理、糾錯等強大的功能，也就是做兩個減法：知識圖譜-知識-圖譜 所剩下的那部分功能到底有什么。我個人的看法是：還有待進一步觀察。下文也針對這點展開討論。

從搜索引擎到語義網(wǎng) 知識圖譜起源于搜索引擎的瓶頸：對查詢需求與信息的理解不足。搜索引擎體系以關鍵字來理解查詢需求。以“老家在安徽并且在國務院工作的博士是誰？”問題為例，當下的搜索引擎的主干技術均在于對語句分詞，得到關鍵字后通過關鍵字對目標網(wǎng)頁進行召回排序并反饋。而關鍵字序列的信息相比原句是有不少信息損失的。 此外，搜索引擎所獲取的信息也是非結構的復雜的數(shù)據(jù)，如無格式化的文本、表格等等。直接按排序提供給用戶之后，用戶需要另外瀏覽選擇過濾得到目標的結果，用戶可能在無關的網(wǎng)頁中進行費時的篩選。因此以關鍵字理解查詢需求存在不少信息損失，以網(wǎng)頁文本集反饋用戶，對用戶來說其實也存在額外的信息獲取成本?；谶@個原因，WWW聯(lián)盟的Tim Berners-Lee在1998年提出了語義網(wǎng)的概念。

語義網(wǎng)旨在將文檔上的元素添加計算機能理解的語義，使得互聯(lián)網(wǎng)成為一個通用的信息交換介質。語義網(wǎng)有兩個非常重要的標準，分別是RDF和SPARQL。

RDF全稱資源描述框架（Resource Description Framework），用來描述網(wǎng)絡資源，這里可以粗淺地理解RDF的描述方式為三元組的方式，分別是主語、謂詞以及賓語/字面量（如日期、金額等數(shù)值/數(shù)詞類賓語）?；蛘吒唵蔚卣f，RDF數(shù)據(jù)集就是一系列的三元組集合，三元組分別為主謂賓?；趫D模型部分的內容，相信讀者可以理解，三元組集合的RDF數(shù)據(jù)集對復雜數(shù)據(jù)的表達與融合能力非常出色。

SPARQL是針對RDF數(shù)據(jù)集的查詢語言，全稱是SPARQL Protocol and RDF Query Language。如上圖所示，SPARQL查詢的核心模塊是where語句中的三元組集合，此處的三元組不同于RDF的三元組，一般每一個where語句中的三元組至少有一個元組是變量，例如圖中的?p，若?p出現(xiàn)在select 的目標中，則是查詢需要的對象，若不存在，?p則只是起到對查詢結果的約束作用，表示查詢結果中，?p出現(xiàn)的幾個位置所匹配的實際元組必須完全一致。

這兩個標準將精準語義的信息獲取分成了三個階段，第一個階段是從復雜的網(wǎng)絡資源中抽取出三元組集合，即RDF數(shù)據(jù)集。比如德國的馬克思普朗克實驗室輸出的知名的Yago系列數(shù)據(jù)集。第二個階段是將表達數(shù)據(jù)需求的自然語句轉化成格式化的SPARQL查詢語句，是NLP語義理解范疇的問題。前兩個階段高度依賴于NLP技術的發(fā)展，從學術的角度來看還有較大的發(fā)展空間，但在實際業(yè)務場景中其實影響有限，因為業(yè)務場景上報采集的數(shù)據(jù)格式相對穩(wěn)定，查詢的需求也相對確定，因此，基于業(yè)務經(jīng)驗能夠較好地直接格式化出RDF三元組。第三個階段則是針對RDF數(shù)據(jù)集處理SPARQL查詢，可行的方法眾多，其中一種就是用子圖匹配的方式，也就是我們接下來要提到的知識圖譜的典型查詢處理方式。筆者的導師鄒磊教授是最早一批用子圖匹配的方式處理SPARQL查詢的學者，其相關工作形成的博士論文獲CCF 優(yōu)博提名獎。 感興趣的讀者也可以去閱讀其發(fā)表在VLDB 2011的關于子圖匹配處理SPARQL查詢的文章 [2] https:// dl.acm.org/doi/pdf/10.1 4778/2002974.2002976 。

從語義網(wǎng)到知識圖譜

知識圖譜一般可以理解為以圖譜的方式驅動知識的管理，為知識數(shù)據(jù)建模、存儲和查詢挖掘。圖模型能夠很好地建模三元組集合的RDF數(shù)據(jù)集，同時也能夠很好地將SPARQL的查詢需求表達成子圖（如下圖所示），因此SPARQL查詢可以轉化成子圖查詢，而RDF數(shù)據(jù)集則可以轉化成RDF圖，SPARQL的查詢處理自然就成了在RDF圖上進行子圖匹配的過程。因此，撇開挖掘不談，如果只從建模、存儲和查詢三個方面，知識圖譜僅僅是圖數(shù)據(jù)庫來管理知識數(shù)據(jù)并提供子圖查詢得到的功能，也就是說是知識+圖譜。知識+圖譜本身就有很大應用，針對知識的圖查詢本身就能解決很多應用問題，如天眼查的知識展示。而知識+圖譜能否碰撞出更大的火花，就必須討論知識圖譜中的挖掘方面的技術成果，這也是廣大對知識圖譜感興趣的人群最關心的地方。

而我的結論是：目前不要期望太高，有待進一步觀察。圖譜對知識本身并無在內涵上的增益，是對知識的一個管理工具。推理、糾錯、監(jiān)控種種在NLP角度發(fā)展所遇到的瓶頸，在知識圖譜中仍然是瓶頸。以推理為例，給定四個頂點“吳健雄”，“袁家騮”，“袁克文”，“袁世凱“以及他們之間的關系：“吳健雄”與“袁家騮”的夫妻關系以及袁氏三父子的關系，知識圖譜大致能基于規(guī)則推導出“吳健雄”和“袁世凱”的孫媳婦的關系。整個過程里圖譜其實起到的是數(shù)據(jù)建模和管理的作用，對數(shù)據(jù)內涵增益有限，甚至不需要圖譜來完成推理，因此這個推理實質還是知識范疇的技術在起作用，并非是知識+圖譜碰撞出的新信息。更具體地說，如果存在這么一個問題，知識范疇內無法解決而加了圖譜就可以解決的話，目前來看基本可以確定解決這個問題的技術關鍵在于圖譜自身獨立存在的功能，如知識的高效關聯(lián)可視化問題的技術關鍵在于圖譜的可視化，與知識角度的NLP技術無關。反之亦然。

此外，NLP角度解決語義推理問題的一大瓶頸是常識邏輯的缺失，如鳥是天上飛的以及魚是水里游的。因為邏輯推理的鏈條不能缺失任何一環(huán)，而常識邏輯難以全盤數(shù)字化，因此推理這一瓶頸難以突破，期冀知識圖譜來解決這個問題，在目前來看困難重重，有待存儲和計算能力的進一步發(fā)展。

3 圖計算

圖計算主要指基于全圖結構計算點邊或點邊子集屬性的過程。如PageRank描述點的中心性，點邊介數(shù)（Betweenness）則是描述點邊的連通重要性。圖計算可以作為對圖查詢的一個補充，圖查詢是直接獲取關聯(lián)的信息，而圖計算的目標則是計算出基于關聯(lián)結構蘊藏在點邊中的信息，而且，圖計算結果本身可以再存儲到圖數(shù)據(jù)庫中作為圖查詢的查詢目標。對于希望借力圖計算提升業(yè)務效果的同行來說，重點要關注兩個方面，首先是圖計算的結果怎么用，其次是如何高效算出圖計算的結果。

對于圖計算能起到多大作用問題，難以一概而論。鑒于圖計算任務大都是計算和資源均密集型的，明確圖計算對業(yè)務助力的效果應該優(yōu)于圖計算在計算效率上的提升。 圖計算算法可達數(shù)十種，每種有各自適用的場景。圖計算的結果可以是點邊具體的屬性，如PageRank，Betweenness，置信度傳播，聚集系數(shù)等等；也可以是點邊子集所對應的屬性或結構，如社區(qū)類的連通分量、圖聚類、圖分割、圖染色等等，以及子圖類的生成圖、生成樹、斯坦納樹、最大獨立集、K-Core等等。圖計算的結果確實在特定的場景下起到過非常關鍵的作用，如PageRank、斯坦納樹等，但在支付場景的欺詐人群識別實踐中，基于資金網(wǎng)絡得到的圖計算結果對分類效果的支撐提升比較有限，離開特定的場景需求暴力使用圖計算的結果難以達到預期的效果。

已有的圖計算工作的宣傳也側重計算效率的提升，并沒有很全面地解答圖計算對業(yè)務的提升效果如何。例如，對于連通分量來說，作為經(jīng)典的圖計算的問題，在各大公司內部什么場景，起到多大的業(yè)務提升作用？如果存在圖計算比較全面地、大幅地提升業(yè)務效果（不是效率）的案例，是不是應該有比較多關注圖計算的同行已經(jīng)周知？期待有相關經(jīng)驗的同行能夠分享圖計算針對業(yè)務大幅提升效果的成功案例，筆者也是在較長的一段時間里一直關注圖計算在業(yè)務中的落地效果。結合自己的實踐經(jīng)驗，確實看到過圖計算對業(yè)務的一定程度的提升，但是提升幅度相比于圖計算的投入成本而言，并未達到預期。因此，目前還在持續(xù)觀察圖計算是否能在業(yè)務上發(fā)揮更大的、更全面且更高效的作用。

圖計算算法眾多，但是大都可以通過傳播迭代的方式實現(xiàn)目標的收斂計算。對于計算和資源均密集的圖計算任務，如果直接計算精確的結果，對應的算法復雜度容易達到O(N^2) 甚至更高，在大規(guī)模圖上計算的執(zhí)行時間不可承受。已有的圖計算系統(tǒng)主要是基于點中心框架的計算，通過定義單點的算子，來實現(xiàn)點粒度的并發(fā)，同時多次迭代來收斂至計算目標。類似于Hadoop/Spark生態(tài)對行的抽象：開發(fā)者只需要對行進行低代碼量的開發(fā)就能夠調度大規(guī)模的集群對大規(guī)模數(shù)據(jù)實現(xiàn)計算；點中心圖計算則是對點的抽象：開發(fā)者僅需要開發(fā)基于點的低代碼量的函數(shù)/算子，就能夠調度大規(guī)模的集群對大規(guī)模圖數(shù)據(jù)實現(xiàn)高效計算。

已有的圖系統(tǒng)對圖計算的效率提升到了相當?shù)母叨取Ｗ?010年谷歌首次提出點中心編程框架Pregel（開源對應Giraph系統(tǒng)）之后，GraphLab通過共享內存將Pregel的性能提升了2~3倍，PowerGraph隨后基于圖的冪率分布進行優(yōu)化并提出GAS模型，又將GraphLab的性能提升了將近5倍。比較特殊的是隨后出現(xiàn)的GraphX，立足于Spark生態(tài)的普及在RDD上開發(fā)圖計算的框架，并直接承認性能弱于PowerGraph將近7倍。但是GraphX基于生態(tài)優(yōu)勢也能夠大幅解放開發(fā)者在數(shù)據(jù)預處理（ETL）上的生產力，這點上被后來的GraphX的流行所驗證。學術界目前最先進的圖計算系統(tǒng)應該是清華大學發(fā)表在OSDI2016的Gemini。騰訊公司W(wǎng)XG也有基于Gemini原理開發(fā)的Plato，在Gemini之上做了很多充分的落地優(yōu)化。騰訊公司TEG 的Angel圖計算則另辟蹊徑，通過PS驅動圖計算，性能足夠優(yōu)秀的同時與騰訊公司內部TDW生態(tài)有非常好的結合。

值得注意的是，目前圖計算對異構圖的支持有限，針對異構圖的計算優(yōu)化與實際圖數(shù)據(jù)的構圖形式有較大的關聯(lián)，因此難以有通用的圖計算系統(tǒng)或算法，但實際業(yè)務中的圖計算往往更關注異構圖。筆者曾在騰訊CSIG開發(fā)過基于GraphCHI存儲的分布式核外（即磁盤為主）異構圖的圖計算系統(tǒng)，但由于磁盤I/O效率過低，而業(yè)務中對內存的成本并無嚴苛的要求，該圖計算系統(tǒng)實際應用性不足。筆者在異構圖計算的開發(fā)過程中最大的體會是，具體的計算邏輯和構圖形式對計算引擎的效率影響很大，所以通用且高效的異構圖計算系統(tǒng)短期內可能難以實現(xiàn)。

4 圖表示學習

圖表示學習并沒有形式化的定義，但基本原理大都為將圖中頂點映射到低維向量空間，并且向量間的相對距離能夠盡可能地反映頂點間在圖上的相對關聯(lián)強度，完成從非歐圖模型到歐式向量空間的轉換。而點向量則是可以作為特征無縫地支持下游深度學習任務，因此圖學習也是在工業(yè)界落地最多，使用最普遍的圖技術。鑒于網(wǎng)絡上對圖表示學習的文章眾多，不乏全面詳實的綜述論文，本篇不在對表示學習已有工作進行過多的展開，直接討論筆者在圖表示學習落地過程中的經(jīng)驗。

圖表示學習的核心本質在于表示學習，圖只是作為數(shù)據(jù)源，因此圖表示學習的技術部分主要在于表示學習，除了數(shù)據(jù)外，并沒有圖的語義，也沒有圖的算法，理解這點對如何使用、何時使用圖表示學習至關重要。討論這點需要從筆者之前開發(fā)的基于LINE算法的擴展版本W(wǎng)xPayLine++說起，算法細節(jié)未獲授權對外，此處不再展開。

WxPayLine++是基于LINE的二階無效性開發(fā)的LINE的優(yōu)化版本，核心思路是基于筆者提出的傳遞增強算子，將多階信息融合到一階再進行表示學習。如圖所示，WxpayLine++在轉賬網(wǎng)絡學習得到的用戶的向量特征，在多種異常人群識別中提升的效果顯著。

但是有一點出乎了我們的意料，就是刷單和羊毛黨兩種標簽的提升情況截然不同。這兩類標簽在各種場合常是同時被提起，并且粗淺理解起來是高度相似的兩種標簽。然而仔細推敲才發(fā)現(xiàn)兩者其實非常不同。在微信支付場景中，刷單用戶因為回款和傭金的原因往往通過中介形成了緊密的資金流關系，而羊毛黨用戶均是只有同商戶的商業(yè)支付，羊毛黨用戶之間卻不一定形成緊密的資金流關系。因此基于轉賬網(wǎng)絡表示學習對刷單有明顯的提升，而羊毛黨則沒有，反而引入了噪聲導致效果下降。這點引發(fā)了針對圖表示學習適用性問題的思考。這里向大家分享下思考的心得：構圖關聯(lián)對問題的指向性決定了表示學習的是否有效果。還是回到剛才的問題，即圖表示學習有用時，是表示學習起了作用還是圖起了作用。換句話說，當圖表示學習對業(yè)務不起效果時，是表示學習環(huán)節(jié)出了問題，還是圖本身無用？我傾向認為是后者。畢竟表示學習算法已經(jīng)經(jīng)過廣大同行的檢驗。

關于構圖關聯(lián)指向性的討論，再從一個簡單的問題說起。假設以一個人向另一個人發(fā)起了微信轉賬，那是否能夠說明以下三種情況成立：第①種：兩者是微信好友。顯然這點是充分成立的；第②種：兩者是居住地同省。考慮到同省人之間更容易發(fā)生經(jīng)濟交流，這點上也是有一定概率成立的；第③種：兩者身高差18公分。這點就毫無邏輯可言了。因此，轉賬關系對不同的問題，其指向性程度是不同的，轉賬對同為刷單用戶的指向性要遠大于同為羊毛黨用戶，這點應該可以解釋WxPayLine++在兩種標簽下迥異的表現(xiàn)。

如何判斷關聯(lián)對問題具有指向性？如果可以提前判斷關聯(lián)與問題缺乏指向性，則可以避免代價高昂的圖表示學習的計算，節(jié)約開發(fā)者時間。這里介紹兩種方法。

首先是直觀理解，即如果有關聯(lián)的雙方能夠同時離目標較近，關聯(lián)對問題則有較強的指向性。如對于兩個用戶，若一位用戶是刷單用戶的轉賬交易關聯(lián)方，而另一位不是，則前者是刷單用戶的概率相對要高于后者。一個有趣的案例則是微信支付場景中的非本人項目。非本人項目旨在挖掘實名證件同賬號實際使用者并不一致的所有微信支付賬號（如上圖所示）。例如未成年人通過綁定父母的銀行卡實現(xiàn)實名的微信支付賬號則為非本人賬號。 該項目初期通過分類遇到較大的效果瓶頸，有同事提議使用圖表示學習的介入來提升效果。圖表示學習的計算代價高昂，經(jīng)過詳細評估之后判斷圖表示學習在該場景中難以發(fā)揮作用，核心的障礙在于無法構圖。即基于非本人的語義，無論是人為頂點，抑或人證pair為點，均難以構建針對非本人有指向性意義的關聯(lián)。這點不做詳細的展開，歡迎讀者一起討論。

其次是低代價的統(tǒng)計分布。通過抽取相同數(shù)量的正負樣本，分別組成對應的導出子圖。可以比較兩個導出子圖的連通分量數(shù)、邊數(shù)以及二階路徑數(shù)，如果差異明顯，則關聯(lián)對正負樣本的區(qū)分具有指向性，反之則無指向性。

表示學習效果與畫像特征可能的重疊 一般來說，表示學習從數(shù)據(jù)還是方法的角度上，同畫像特征都是相對獨立的。但在支付場景的實踐中我們發(fā)現(xiàn)一個有趣的現(xiàn)象：表示特征的提升效果在畫像特征不斷豐富后會出現(xiàn)下降。在微信支付反欺詐場景的惡意率建模中，交易網(wǎng)絡表示學習的特征在第一版模型上效果提升明顯，但隨著模型特征工程的展開和優(yōu)化，表示學習的提升效果明顯下降，即畫像等基礎特征足夠豐富時，交易的關聯(lián)所帶來的額外信息在減少。初步估計是交易關聯(lián)的雙方相比無交易關聯(lián)的雙方更容易畫像相似，諸如消費地點、興趣愛好或其它行為上的相似，通過畫像工程體現(xiàn)在特征中。這點上并沒有形式化的證明，但有個有趣的真實例子可以供大家參考：筆者之前常去南山文體游泳館游泳，游泳館需要客戶交現(xiàn)金做衣柜鑰匙的押金，這里很容易出現(xiàn)某位客戶忘了帶現(xiàn)金向其他泳友求助現(xiàn)金并微信轉賬還款的情況，筆者自身就遇到過一次。這種情況下轉賬交易的雙方往往出現(xiàn)在相同的地點，有相同的興趣愛好和消費習慣（泳具）等等。

以上幾點均是經(jīng)驗之談，僅供參考，更準確的方法或更形式化的證明留待未來研究。

5 總結

• 圖查詢的關鍵在于可視化與即時關聯(lián)分析的高效
• 圖計算的核心作用再全局關聯(lián)計算中的性能加速
• 圖學習同目前業(yè)務需求關系最為緊密，作用最為明顯
• 圖的運用應該在遇到業(yè)務瓶頸之后
• 圖的產品應該聚焦業(yè)務需求、使用體驗而非圖技術本身