作者：王昊奮

近兩年來，隨著Linking Open Data[1] 等項目的全面展開，語義Web數據源的數量激增，大量RDF數據被發布。互聯網正從僅包含網頁和網頁之間超鏈接的文檔萬維網(Document Web)轉變成包含大量描述各種實體和實體之間豐富關系的數據萬維網(Data Web)。在這個背景下，Google、百度和搜狗等搜索引擎公司紛紛以此為基礎構建知識圖譜，分別為Knowledge Graph、知心和知立方，來改進搜索質量，從而拉開了語義搜索的序幕。下面我將從以下幾個方面來介紹知識圖譜：知識圖譜的表示和在搜索中的展現形式，知識圖譜的構建和知識圖譜在搜索中的應用等，從而讓大家有機會了解其內部的技術實現和各種挑戰。

知識圖譜的表示和在搜索中的展現形式

正如Google的辛格博士在介紹知識圖譜時提到的：“The world is not made of strings , but is made of things.”，知識圖譜旨在描述真實世界中存在的各種實體或概念。其中，每個實體或概念用一個全局唯一確定的ID來標識，稱為它們的標識符(identifier)。每個屬性-值對(attribute-value pair，又稱AVP)用來刻畫實體的內在特性，而關系(relation)用來連接兩個實體，刻畫它們之間的關聯。知識圖譜亦可被看作是一張巨大的圖，圖中的節點表示實體或概念，而圖中的邊則由屬性或關系構成。上述圖模型可用W3C提出的資源描述框架RDF[2] 或屬性圖(property graph)[3] 來表示。知識圖譜率先由Google提出，以提高其搜索的質量。

為了更好地理解知識圖譜，我們先來看一下其在搜索中的展現形式，即知識卡片(又稱Knowledge Card)。知識卡片旨在為用戶提供更多與搜索內容相關的信息。更具體地說，知識卡片為用戶查詢中所包含的實體或返回的答案提供詳細的結構化摘要。從某種意義來說，它是特定于查詢(query specific)的知識圖譜。例如，當在搜索引擎中輸入“姚明”作為關鍵詞時，我們發現搜索結果頁面的右側原先用于置放廣告的地方被知識卡片所取代。廣告被移至左上角，而廣告下面則顯示的是傳統的搜索結果，即匹配關鍵詞的文檔列表。這個布局上的微調也預示著各大搜索引擎在提高用戶體驗和直接返回答案方面的決心。

【三大搜索引擎關于姚明的知識卡片(略)】

雖說三大搜索引擎在知識卡片的排版和內容展現上略有不同，但是它們都列出了姚明的身高、體重、民族等屬性信息。此外，它們均包含“用戶還搜索了”或“其他人還搜”的功能來展現相關的人物。該功能允許用戶去瀏覽其他與姚明相關的人物的詳細信息。細心的讀者也發現Google在其知識卡片中也展示了很多與姚明相關的圖片，以圖文并茂的方式來展示姚明的方方面面。百度則結合了百度風云榜的信息，列出了姚明的類別(體壇人物)及其百度指數(今日排名和今日搜索熱度等信息)。在搜索結果頁面的左上角(在圖中未給出)，百度還展示了其特有的專題搜索，包含了與姚明相關的百科、圖片、微博、新聞、音樂、貼吧和視頻等七大類的結果，基本涵蓋了用戶最基本的需求。搜狗在列出與姚明相關的百科、圖片，電影和最新相關消息等專題的同時，其知識卡片額外顯示了諸如“主持電視節目”、“效力籃球隊”、“人物關系”等各種細粒度的語義關系。當遇到含有歧義的用戶查詢時，知識卡片還會列出其他可能的查詢目標對象。在上面的例子中，搜狗還列出了一項“您是否要找”的功能，列出一位也叫姚明的一級作曲家。該功能用于去歧義，在顯示最相關實體的同時也給出其他可能的對象，達到去歧義的作用。當搜索“李娜”或“長城”時，Google和百度也在其知識卡片下方展現了類似的功能。除了給出著名網球運動員李娜和萬里長城之外，它們還列出歌手李娜和長城汽車供用戶選擇和瀏覽。更值得一提的是，當在搜狗知立方中輸入“姚明的老婆的女兒的身高”如此復雜的查詢時，其會直接返回其女兒的姓名(姚沁蕾)以及其身高(110cm)，并給出推理說明“葉莉的女兒是姚沁蕾”。如此詳實的說明不僅為返回的答案提供了很好的解釋，從另一個側面也展示了知識圖譜的強大，其不僅能識別出運動員姚明，也能抽取出關系“老婆”和“女兒”和屬性“身高”等信息。當我們將查詢修改為“姚明的妻子的女兒的身高”時，依然返回相同的結果，這也意味著知識圖譜知道“妻子”和“老婆”代表相同的含義。

通過上述的介紹，大家應該對知識圖譜的表示以及其在搜索中的展現形式有了更深的了解。接著，我將介紹知識圖譜的構建以及如何在搜索中應用知識圖譜返回相應的知識卡片以及答案。

知識圖譜的構建

1. 知識圖譜的規模

據不完全統計，Google知識圖譜到目前為止包含了5億個實體和35億條事實(形如實體-屬性-值，和實體-關系-實體)。其知識圖譜是面向全球的，因此包含了實體和相關事實的多語言描述。不過相比占主導的英語外，僅包含其他語言(如中文)的知識圖譜的規模則小了很多。與此不同的是，百度和搜狗主要針對中文搜索推出知識圖譜，其知識庫中的知識也主要以中文來描述，其規模略小于Google的。

2.?知識圖譜的數據來源

為了提高搜索質量，特別是提供如對話搜索和復雜問答等新的搜索體驗，我們不僅要求知識圖譜包含大量高質量的常識性知識，還要能及時發現并添加新的知識。在這種背景下，知識圖譜通過收集來自百科類站點和各種垂直站點的結構化數據來覆蓋大部分常識性知識。這些數據普遍質量較高，更新比較慢。而另一方面，知識圖譜通過從各種半結構化數據(形如HTML表格)抽取相關實體的屬性-值對來豐富實體的描述。此外，通過搜索日志(query log)發現新的實體或新的實體屬性從而不斷擴展知識圖譜的覆蓋率。相比高質量的常識性知識，通過數據挖掘抽取得到的知識數據更大，更能反映當前用戶的查詢需求并能及時發現最新的實體或事實，但其質量相對較差，存在一定的錯誤。這些知識利用互聯網的冗余性在后續的挖掘中通過投票或其他聚合算法來評估其置信度，并通過人工審核加入到知識圖譜中。

a) 百科類數據

維基百科[4] ，通過協同編輯，已經成為最大的在線百科全書，其質量與大英百科媲美。可以通過以下方式來從維基百科中獲取所需的內容：通過文章頁面(Article Page)抽取各種實體;通過重定向頁面(Redirect Page)獲得這些實體的同義詞(又稱Synonym);通過去歧義頁面(Disambiguation Page)和內鏈錨文本(Internal Link Anchor Text)獲得它們的同音異義詞(又稱Homonym);通過概念頁面(Category Page)獲得各種概念以及其上下位(subclass)關系;通過文章頁面關聯的開放分類抽取實體所對應的類別;通過信息框(Infobox)抽取實體所對應的屬性-值對和關系-實體對。類似地，從百度百科和互動百科抽取各種中文知識來彌補維基百科中文數據不足的缺陷。此外，Freebase[5] 是另一個重要的百科類的數據源，其包含超過3900萬個實體(其稱為Topics)和18億條事實，規模遠大于維基百科。對比之前提及的知識圖譜的規模，我們發現僅Freebase一個數據源就構成了Google知識圖譜的半壁江山。更為重要的是，維基百科所編輯的是各種詞條，這些詞條以文章的形式來展現，包含各種半結構化信息，需要通過事先制定的規則來抽取知識;而Freebase則直接編輯知識，包括實體及其包含的屬性和關系，以及實體所屬的類型等結構化信息。因此，不需要通過任何抽取規則即可獲得高質量的知識。雖然開發Freebase的母公司MetaWeb于2010年被Google收購，Freebase還是作為開放的知識管理平臺獨立運行。所以百度和搜狗也將Freebase加入到其知識圖譜中。

b) 結構化數據

除了百科類的數據，各大搜索引擎公司在構建知識圖譜時，還考慮其他結構化數據。其中，LOD項目在發布各種語義數據的同時，通過owl:sameAs將新發布的語義數據中涉及的實體和LOD中已有數據源所包含的潛在同一實體進行關聯，從而實現了手工的實體對齊(entity alignment)。LOD不僅包括如DBpedia[6] 和YAGO[7] 等通用語義數據集，還包括如MusicBrainz[8] 和DrugBank[9] 等特定領域的知識庫。因此，Google等通過整合LOD中的(部分)語義數據提高知識的覆蓋率，尤其是垂直領域的各種知識。此外，Web上存在大量高質量的垂直領域站點(如電商網站，點評網站等)，這些站點被稱為Deep Web[10]。它們通過動態網頁技術將保存在數據庫中的各種領域相關的結構化數據以HTML表格的形式展現給用戶。各大搜索引擎公司通過收購這些站點或購買其數據來進一步擴充其知識圖譜在特定領域的知識。這樣做出于三方面原因：其一、大量爬取這些站點的數據會占據大量帶寬，導致這些站點無法被正常訪問;其二、爬取全站點數據可能會涉及知識產權糾紛;最后，相比靜態網頁的爬取，Deep Web爬蟲需要通過表單填充(Form Filling)技術來獲取相關內容，且解析這些頁面中包含的結構化信息需要額外的自動化抽取算法，具體細節在下一節描述。

c) 半結構化數據挖掘AVP

雖然從Deep Web爬取數據并解析其中所包含的結構化信息面臨很大的挑戰，各大搜索引擎公司仍在這方面投入了大量精力。一方面，Web上存在大量長尾的結構化站點，這些站點提供的數據與最主流的相關領域站點所提供的內容具有很強的互補性，因此對這些長尾站點進行大規模的信息抽取(尤其是實體相關的屬性-值對的抽取)對于知識圖譜所含內容的擴展是非常有價值的。另一方面，中文百科類的站點(如百度百科等)的結構化程度遠不如維基百科，能通過信息框獲得AVP的實體非常稀少，大量屬性-值對隱含在一些列表或表格中。一個切實可行的做法是構建面向站點的包裝器(Site-specific Wrapper)。其背后的基本思想是：一個Deep Web站點中的各種頁面由統一的程序動態生成，具有類似的布局和結構。利用這一點，我們僅需從當前待抽取站點采樣并標注幾個典型詳細頁面(Detailed Pages)，利用這些頁面通過模式學習算法(Pattern Learning)自動構建出一個或多個以類Xpath表示的模式，然后將其應用在該站點的其他詳細頁面中從而實現自動化的AVP抽取。對于百科類站點，我們可以將具有相同類別的頁面作為某個“虛擬”站點，并使用類似的方法進行實體AVP的抽取。自動學習獲得的模式并非完美，可能會遺漏部分重要的屬性，也可能產生錯誤的抽取結果。為了應對這個問題，搜索引擎公司往往通過構建工具來可視化這些模式，并人工調整或新增合適的模式用于抽取。此外，通過人工評估抽取的結果，將那些抽取結果不令人滿意的典型頁面進行再標注來更新訓練樣本，從而達到主動學習(Active Learning)的目的。

d) 通過搜索日志進行實體和實體屬性等挖掘

搜索日志是搜索引擎公司積累的寶貴財富。一條搜索日志形如<查詢，點擊的頁面鏈接，時間戳>。通過挖掘搜索日志，我們往往可以發現最新出現的各種實體及其屬性，從而保證知識圖譜的實時性。這里側重于從查詢的關鍵詞短語和點擊的頁面所對應的標題中抽取實體及其屬性。選擇查詢作為抽取目標的意義在于其反映了用戶最新最廣泛的需求，從中能挖掘出用戶感興趣的實體以及實體對應的屬性。而選擇頁面的標題作為抽取目標的意義在于標題往往是對整個頁面的摘要，包含最重要的信息。據百度研究者的統計，90%以上的實體可以在網頁標題中被找到。為了完成上述抽取任務，一個常用的做法是：針對每個類別，挑選出若干屬于該類的實體(及相關屬性)作為種子(Seeds)，找到包含這些種子的查詢和頁面標題，形成正則表達式或文法模式。這些模式將被用于抽取查詢和頁面標題中出現的其他實體及其屬性。如果當前抽取所得的實體未被包含在知識圖譜中，則該實體成為一個新的候選實體。類似地，如果當前被抽取的屬性未出現在知識圖譜中，則此屬性成為一個新的候選屬性。這里，我們僅保留置信度高的實體及其屬性，新增的實體和屬性將被作為新的種子發現新的模式。此過程不斷迭代直到沒有新的種子可以加入或所有的模式都已經找到且無法泛化。在決定模式的好壞時，常用的基本原則是盡量多地發現屬于當前類別的實體和對應屬性，盡量少地抽取出屬于其他類別的實體及屬性。上述方法被稱為基于Bootstrapping的多類別協同模式學習。

3. 從抽取圖譜到知識圖譜

上述所介紹的方法僅僅是從各種類型的數據源抽取構建知識圖譜所需的各種候選實體(概念)及其屬性關聯，形成了一個個孤立的抽取圖譜(Extraction Graphs)。為了形成一個真正的知識圖譜，我們需要將這些信息孤島集成在一起。下面我對知識圖譜挖掘所涉及的重要技術點逐一進行介紹。

a) 實體對齊

實體對齊(Object Alignment)旨在發現具有不同ID但卻代表真實世界中同一對象的那些實體，并將這些實體歸并為一個具有全局唯一標識的實體對象添加到知識圖譜中。雖然實體對齊在數據庫領域被廣泛研究，但面對如此多異構數據源上的Web規模的實體對齊，這還是第一次嘗試。各大搜索引擎公司普遍采用的方法是聚類。聚類的關鍵在于定義合適的相似度度量。這些相似度度量遵循如下觀察：具有相同描述的實體可能代表同一實體(字符相似);具有相同屬性-值的實體可能代表相同對象(屬性相似);具有相同鄰居的實體可能指向同一個對象(結構相似)。在此基礎上，為了解決大規模實體對齊存在的效率問題，各種基于數據劃分或分割的算法被提出將實體分成一個個子集，在這些子集上使用基于更復雜的相似度計算的聚類并行地發現潛在相同的對象。另外，利用來自如LOD中已有的對齊標注數據(使用owl:sameAs關聯兩個實體)作為訓練數據，然后結合相似度計算使用如標簽傳遞(Label Propagation)等基于圖的半監督學習算法發現更多相同的實體對。無論何種自動化方法都無法保證100%的準確率，所以這些方法的產出結果將作為候選供人工進一步審核和過濾。

b) 知識圖譜schema構建

在之前的技術點介紹中，大部分篇幅均在介紹知識圖譜中數據層(Data Level)的構建，而沒有過多涉及模式層(Schema Level)。事實上，模式是對知識的提煉，而且遵循預先給定的schema有助于知識的標準化，更利于查詢等后續處理。為知識圖譜構建schema相當于為其建立本體(Ontology)。最基本的本體包括概念、概念層次、屬性、屬性值類型、關系、關系定義域(Domain)概念集以及關系值域(Range)概念集。在此基礎上，我們可以額外添加規則(Rules)或公理(Axioms)來表示模式層更復雜的約束關系。面對如此龐大且領域無關的知識庫，即使是構建最基本的本體，也是非常有挑戰的。Google等公司普遍采用的方法是自頂向下(Top-Down)和自底向上(Bottom-Up)相結合的方式。這里，自頂向下的方式是指通過本體編輯器(Ontology Editor)預先構建本體。當然這里的本體構建不是從無到有的過程，而是依賴于從百科類和結構化數據得到的高質量知識中所提取的模式信息。更值得一提的是，Google知識圖譜的Schema是在其收購的Freebase的schema基礎上修改而得。Freebase的模式定義了Domain(領域)，Type(類別)和Topic(主題，即實體)。每個Domain有若干Types，每個Type包含多個Topics且和多個Properties關聯，這些Properties規定了屬于當前Type的那些Topics需要包含的屬性和關系。定義好的模式可被用于抽取屬于某個Type或滿足某個Property的新實體(或實體對)。另一方面，自底向上的方式則通過上面介紹的各種抽取技術，特別是通過搜索日志和Web Table抽取發現的類別、屬性和關系，并將這些置信度高的模式合并到知識圖譜中。合并過程將使用類似實體對齊的對齊算法。對于未能匹配原有知識圖譜中模式的類別、屬性和關系作為新的模式加入知識圖譜供人工過濾。自頂向下的方法有利于抽取新的實例，保證抽取質量，而自底向上的方法則能發現新的模式。兩者是互補的。

c) 不一致性的解決

當融合來自不同數據源的信息構成知識圖譜時，有一些實體會同時屬于兩個互斥的類別(如男女)或某個實體所對應的一個Property[11] (如性別)對應多個值。這樣就會出現不一致性。這些互斥的類別對以及Functional Properties可以看作是模式層的知識，通常規模不是很大，可以通過手工指定規則來定義。而由于不一致性的檢測要面對大規模的實體及相關事實，純手工的方法將不再可行。一個簡單有效的方法充分考慮數據源的可靠性以及不同信息在各個數據源中出現的頻度等因素來決定最終選用哪個類別或哪個屬性值。也就是說，我們優先采用那些可靠性高的數據源(如百科類或結構化數據)抽取得到的事實。另外，如果一個實體在多個數據源中都被識別為某個類別的實例，或實體某個functional property在多個數據源中都對應相同的值，那么我們傾向于最終選擇該類別和該值。注：在統計某個類別在數據源中出現的頻率前需要完成類別對齊計算。類似地，對于數值型的屬性值我們還需要額外統一它們所使用的單位。

4. 知識圖譜上的挖掘

通過各種信息抽取和數據集成技術已經可以構建Web規模的知識圖譜。為了進一步增加圖譜的知識覆蓋率，需要進一步在知識圖譜上進行挖掘。下面將介紹幾項重要的基于知識圖譜的挖掘技術。

a) 推理

推理(Reasoning或Inference)被廣泛用于發現隱含知識。推理功能一般通過可擴展的規則引擎來完成。知識圖譜上的規則一般涉及兩大類。一類是針對屬性的，即通過數值計算來獲取其屬性值。例如：知識圖譜中包含某人的出生年月，我們可以通過當前日期減去其出生年月獲取其年齡。這類規則對于那些屬性值隨時間或其他因素發生改變的情況特別有用。另一類是針對關系的，即通過(鏈式)規則發現實體間的隱含關系。例如，我們可以定義規定：岳父是妻子的父親。利用這條規則，當已知姚明的妻子(葉莉)和葉莉的父親(葉發)時，可以推出姚明的岳父是葉發。

b) 實體重要性排序

搜索引擎識別用戶查詢中提到的實體，并通過知識卡片展現該實體的結構化摘要。當查詢涉及多個實體時，搜索引擎將選擇與查詢更相關且更重要的實體來展示。實體的相關性度量需在查詢時在線計算，而實體重要性與查詢無關可離線計算。搜索引擎公司將PageRank算法[12] 應用在知識圖譜上來計算實體的重要性。和傳統的Web Graph相比，知識圖譜中的節點從單一的網頁變成了各種類型的實體，而圖中的邊也由連接網頁的超鏈接(Hyperlink)變成豐富的各種語義關系。由于不同的實體和語義關系的流行程度以及抽取的置信度均不同，而這些因素將影響實體重要性的最終計算結果，因此，各大搜索引擎公司嵌入這些因素來刻畫實體和語義關系的初始重要性，從而使用帶偏的PageRank算法(Biased PageRank)。

c) 相關實體挖掘

在相同查詢中共現的實體，或在同一個查詢會話(Session)中被提到的其他實體稱為相關實體。一個常用的做法是將這些查詢或會話看作是虛擬文檔，將其中出現的實體看作是文檔中的詞條，使用主題模型(如LDA)發現虛擬文檔集中的主題分布。其中每個主題包含1個或多個實體，這些在同一個主題中的實體互為相關實體。當用戶輸入查詢時，搜索引擎分析查詢的主題分布并選出最相關的主題。同時，搜索引擎將給出該主題中與知識卡片所展現的實體最相關的那些實體作為“其他人還搜了”的推薦結果。

5. 知識圖譜的更新和維護

a) Type和Collection的關系

知識圖譜的schema為了保證其質量，由專業團隊審核和維護。以Google知識圖譜為例，目前定義的Type數在103-104的數量級。為了提高知識圖譜的覆蓋率，搜索引擎公司還通過自動化算法從各種數據源抽取新的類型信息(也包含關聯的Property信息)，這些類型信息通過一個稱為Collection的數據結構保存。它們不是馬上被加入到知識圖譜schema中。有些今天生成后第二天就被刪除了，有些則能長期的保留在Collection中，如果Collection中的某一種類型能夠長期的保留，發展到一定程度后，由專業的人員進行決策和命名并最終成為一種新的Type。

b) 結構化站點包裝器的維護

站點的更新常常會導致原有模式失效。搜索引擎會定期檢查站點是否存在更新。當檢測到現有頁面(原先已爬取)發生了變化，搜索引擎會檢查這些頁面的變化量，同時使用最新的站點包裝器進行AVP抽取。如果變化量超過事先設定的閾值且抽取結果與原先標注的答案差別較大，則表明現有的站點包裝器失效了。在這種情況下，需要對最新的頁面進行重新標注并學習新的模式，從而構建更新的包裝器。

c) 知識圖譜的更新頻率

加入到知識圖譜中的數據不是一成不變的。Type對應的實例往往是動態變化的。例如，美國總統，隨著時間的推移，可能對應不同的人。由于數據層的規模和更新頻度都遠超schema層，搜索引擎公司利用其強大的計算保證圖譜每天的更新都能在3個小時內完成，而實時的熱點也能保證在事件發生6個小時內在搜索結果中反映出來。

d) 眾包(Crowdsourcing)反饋機制

除了搜索引擎公司內部的專業團隊對構建的知識圖譜進行審核和維護，它們還依賴用戶來幫助改善圖譜。具體來說，用戶可以對搜索結果中展現的知識卡片所列出的實體相關的事實進行糾錯。當很多用戶都指出某個錯誤時，搜索引擎將采納并修正。這種利用群體智慧的協同式知識編輯是對專業團隊集中式管理的互補。

知識圖譜在搜索中的應用

1. 查詢理解

搜索引擎借助知識圖譜來識別查詢中涉及到的實體(概念)及其屬性等，并根據實體的重要性展現相應的知識卡片。搜索引擎并非展現實體的全部屬性，而是根據當前輸入的查詢自動選擇最相關的屬性及屬性值來顯示。此外，搜索引擎僅當知識卡片所涉及的知識的正確性很高(通常超過95%，甚至達到99%)時，才會展現。當要展現的實體被選中之后，利用相關實體挖掘來推薦其他用戶可能感興趣的實體供進一步瀏覽。

2. 問題回答

除了展現與查詢相關的知識卡片，知識圖譜對于搜索所帶來的另一個革新是：直接返回答案，而不僅僅是排序的文檔列表。要實現自動問答系統，搜索引擎不僅要理解查詢中涉及到的實體及其屬性，更需要理解查詢所對應的語義信息。搜索引擎通過高效的圖搜索，在知識圖譜中查找連接這些實體及屬性的子圖并轉換為相應的圖查詢(如SPARQL[13] )。這些翻譯過的圖查詢被進一步提交給圖數據庫進行回答返回相應的答案。

總結

這篇文章比較系統地介紹了知識圖譜的表示、構建、挖掘以及在搜索中的應用。通過上述介紹，大家可以看出：1)目前知識圖譜還處于初期階段;2)人工干預很重要;3)結構化數據在知識圖譜的構建中起到決定性作用;4)各大搜索引擎公司為了保證知識圖譜的質量多半采用成熟的算法;5)知識卡片的給出相對比較謹慎;6)更復雜的自然語言查詢將嶄露頭角(如Google的蜂鳥算法)。

此外，知識圖譜的構建是多學科的結合，需要知識庫、自然語言理解，機器學習和數據挖掘等多方面知識的融合。有很多開放性問題需要學術界和業界一起解決。我們有理由相信學術界在上述方面的突破將會極大地促進知識圖譜的發展。

致謝

感謝來自谷歌的王棟博士、來自搜狗的張坤以及來自百度的吳華博士和趙士奇博士分別介紹了Google知識圖譜、搜狗知立方和百度知心系統的工作。他們精彩的報告是本篇技術文章的基礎。

撰稿人簡介：

王昊奮，上海交通大學計算機應用專業博士，對語義搜索、圖數據庫以及Web挖掘與信息抽取有濃厚的興趣。在博士就讀期間發表了30余篇國際頂級會議和期刊論文，長期在WWW、ISWC等頂級會議擔任程序委員會委員。作為Apex數據與知識管理實驗室語義組負責人，他主持并參與了多項相關項目的研發，長期與IBM、百度等知名IT企業進行合作，在知識圖譜相關的研究領域積累了豐富的經驗。

總結

以上是生活随笔為你收集整理的知识图谱技术原理介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。