Contextualizing Airbnb by Building Knowledge Graph
我想你去洛杉磯旅行。 第一步是訪問A irbnb.com并搜索“洛杉磯”。在后端，查詢“洛杉磯”被翻譯成地圖上的一個區(qū)塊; 此塊中的可用房屋將在許多搜索結(jié)果頁面中返回。 這足以讓你制定旅行計劃嗎？
隨著Airbnb逐漸走向成為端到端的旅行平臺 ，我們越來越重要的是提供旅行見解，幫助人們決定何時旅行，去哪里以及旅行時 做些什么 。 例如，洛杉磯最受歡迎的地標和社區(qū)是什么？ 是否有任何即將舉行的音樂會或體育賽事可能與我的旅行相符？ 哪些Airbnb房源最適合家庭？ 去洛杉磯一年中最實惠的時間是什么？ 所有這些內(nèi)容和背景對度假計劃者都有幫助，我們可以提供的準確，有用的旅行信息越多，我們的用戶就越信任我們。
為了擴展我們回答這些旅行查詢的能力，我們需要一種系統(tǒng)的方法來存儲和提供有關(guān)實體 （例如城市，地標，事件等）的高質(zhì)量信息以及它們之間的關(guān)系 （例如，城市中最受歡迎的地標） ，玉米餅最好的鄰居等）。 為了解決這個問題，我們在過去一年中建立并應用了一個知識圖表來存儲和提供結(jié)構(gòu)化數(shù)據(jù) ，這些數(shù)據(jù)連接了我們的庫存獨特之處，用戶所尋找的內(nèi)容以及旅行世界所提供的內(nèi)容。
在我們之前的文章中 ，我們分享了對Airbnb的知識圖及其工作原理的高級概述。 在這篇文章中，我們將深入探討如何構(gòu)建知識圖基礎(chǔ)架構(gòu)并在此過程中分享我們的知識。 我們還將介紹如何使用知識圖對我們的庫存進行分類并將整個平臺置于上下文中。
基礎(chǔ)設施
下圖說明了截至今天Airbnb的知識圖服務的架構(gòu)。 它可以分為3個組件： 圖形存儲， 圖形查詢API和存儲更改器 。 在本節(jié)中，我們將詳細介紹每個細節(jié)。
知識圖形基礎(chǔ)結(jié)構(gòu)的體系結(jié)構(gòu)
圖存儲
我們?yōu)橹R圖基礎(chǔ)架構(gòu)構(gòu)建的第一件事是圖形存儲模塊 。 我們采用了一個內(nèi)部關(guān)系數(shù)據(jù)存儲作為底層數(shù)據(jù)庫，我們在其上實現(xiàn)了一個節(jié)點存儲和邊緣存儲 ，以便可以直接在節(jié)點（實體）上執(zhí)行CRUD（創(chuàng)建，讀取，更新和刪除）操作。邊（關(guān)系），而不是處理數(shù)據(jù)庫表中的行。 為每個節(jié)點或邊緣分配全局唯一標識符 （GUID）。 我們可以使用GUID獲取節(jié)點和邊緣; 此外，我們還可以獲取連接某些節(jié)點的特定類型的邊。
為了將本體和關(guān)系構(gòu)建到知識圖中，圖存儲中的節(jié)點被劃分為不同的節(jié)點類型。 此外，每個節(jié)點類型都由唯一的模式定義。 例如， 地點節(jié)點由名稱和GPS坐標定義，而事件節(jié)點類型由名稱，日期和地點定義。 這些不同的節(jié)點類型存儲在底層數(shù)據(jù)庫的單獨表中。
類似地，邊緣可以是不同的邊緣類型，以反映實體之間的不同類型的關(guān)系（例如， 城市中的地標和國內(nèi)的語言 ）。 與RDFS中的域和范圍相對應，每個邊類型對于從其開始和連接的節(jié)點類型具有可配置約束。 例如， 城市中的地標必須從地標節(jié)點連接到城市節(jié)點。
此外，圖存儲設計用于存儲來自不同數(shù)據(jù)源的邊，以便多個團隊（作為數(shù)據(jù)所有者）可以向知識圖提供數(shù)據(jù)。 因此，每個邊緣還存儲每個邊緣的源和置信度分數(shù) 。 為了保證數(shù)據(jù)所有者的操作不太可能影響其他團隊的數(shù)據(jù)，我們將每個數(shù)據(jù)源的邊緣存儲在底層數(shù)據(jù)庫的單獨表中。 存儲還可以存儲邊緣的額外有效載荷; 一個例子是Home列表與地標附近的地標之間的距離。
在Airbnb，知識圖中的數(shù)據(jù)并不總是通過在線查詢消費，因此我們還將節(jié)點和邊緣的每日快照轉(zhuǎn)儲到數(shù)據(jù)倉庫中以供離線使用 。 應用程序（例如我們的自動完成服務）依賴于知識圖的數(shù)據(jù)轉(zhuǎn)儲來滿足其產(chǎn)品需求。 此外，我們還在數(shù)據(jù)轉(zhuǎn)儲上應用機器學習技術(shù)，用于圖形嵌入 ， 知識推理等目的。
最后，我們很樂意反思我們對圖形存儲的底層數(shù)據(jù)庫的選擇。 為什么我們采用關(guān)系數(shù)據(jù)庫而不是圖數(shù)據(jù)庫 ？ 簡短的回答是操作開銷 。 當時，我們在Airbnb上沒有生產(chǎn)就緒的圖形數(shù)據(jù)庫，使用現(xiàn)有的關(guān)系數(shù)據(jù)庫具有以下優(yōu)點：
- 我們的內(nèi)部關(guān)系數(shù)據(jù)庫因其被廣泛使用而被證明是可靠的。 它還帶有許多有用的功能，例如易于使用的客戶端，架構(gòu)遷移工具，監(jiān)視和警報以及每日數(shù)據(jù)導出。
- 使用圖形數(shù)據(jù)庫意味著我們必須在Airbnb的基礎(chǔ)上進行設置，調(diào)試任何可靠性/性能問題，并開發(fā)我們需要的其他功能。 它會減慢我們的進度并分散我們對知識圖本身的關(guān)注。
到目前為止，圖存儲與關(guān)系數(shù)據(jù)庫具有令人滿意的性能。 我們還仔細地封裝和整合邏輯以一起處理數(shù)據(jù)庫并將其隱藏在知識圖代碼庫的其余部分。 通過這樣做，我們可以靈活地在將來需要時替換底層數(shù)據(jù)庫。
圖形查詢API
當我們開始在生產(chǎn)中使用知識圖時，我們注意到大多數(shù)產(chǎn)品用例需要遍歷子圖并從遍歷中檢索節(jié)點和邊。 例如，在Airbnb的產(chǎn)品詳細信息頁面（PDP或列表頁面）中，查詢知識圖以顯示主頁列表附近的興趣點，以及所提及的每個餐館，博物館或地標的照片。 利用圖論中的術(shù)語，該查詢需要遍歷（1）連接到特定Home列表節(jié)點的所有場所節(jié)點，以及（2）與在前一步驟中獲取的場所節(jié)點連接的照片節(jié)點。
為了支持這些產(chǎn)品需求，除知識圖API模塊中的節(jié)點和邊緣的CRUD端點外，我們還實現(xiàn)了圖形查詢端點。 通過圖形查詢，可以通過指定路徑來遍歷圖形，路徑是一系列邊緣類型和數(shù)據(jù)過濾器 ，從某些節(jié)點開始，并以結(jié)構(gòu)化格式接收遍歷的子圖。 圖形查詢API具有遞歸接口，使得可以通過多個步驟遍歷知識圖。
為了給你一個品味，讓我們看一個例子：如果想要找到所有與城市節(jié)點“ Beijing ”連接的地點節(jié)點，邊緣類型為“ contains_location” ，那么他們（1）周圍有超過5,000個列表和（2） ）屬于“ 風景 ”類別。 該查詢可以寫成如下。
?
如上所述，知識圖旨在存儲來自多個數(shù)據(jù)源的數(shù)據(jù)。 通過我們的知識圖API，可以查詢來自所有來源的數(shù)據(jù)。 在圖形查詢中，可以指定要從中查詢數(shù)據(jù)的數(shù)據(jù)源。 同時，我們還在開發(fā)一個數(shù)據(jù)協(xié)調(diào)層，旨在匯總來自不同來源的數(shù)據(jù) ， 協(xié)調(diào)沖突，并在用戶不知道要信任哪些數(shù)據(jù)源時提供一致的數(shù)據(jù)視圖 。
到目前為止，知識圖可以完美地支持用例，例如在Airbnb上獲取靠近Home的所有地標 ，因為它可以轉(zhuǎn)換為圖形查詢。 但是，有些用例無法通過圖形查詢直接支持 - 例如， 獲取 主頁周圍 最受歡迎的 地標。 我們現(xiàn)在正積極投入努力來處理這種模糊查詢 ，方法是通過ML合并地標的元數(shù)據(jù)和用戶的個性化信號 。
存儲Mutator
對于我們的許多產(chǎn)品用例，我們需要不斷將數(shù)據(jù)導入圖存儲并將這些突變傳播到下游。 有些情況下，通過知識圖API同步寫入數(shù)據(jù)是不理想的，原因如下：
- 在將數(shù)據(jù)寫入知識圖的每個管道中同步調(diào)用知識圖API是一個操作負擔，因為管道是在不同的技術(shù)堆棧（例如Airflow ， IDL服務等）中實現(xiàn)的，并且每個管道需要處理速率限制，重試異常等問題
- 通過API編寫數(shù)據(jù)可能會與知識圖的其他重要在線用法（例如，搜索，PDP等）進行交互，尤其是在寫入流量出現(xiàn)峰值或圖形存儲上的寫入路徑出錯時。
在圖存儲之上，我們構(gòu)建了一個存儲更改器來解決此問題。 除了調(diào)用API之外，數(shù)據(jù)管道還可以通過向我們的Kafka消息總線發(fā)送具有特定Kafka主題的消息來向知識圖發(fā)送變異請求; 突變消費者訂閱該主題并在接收消息時相應地將數(shù)據(jù)寫入知識圖。 這種模式有助于從各種管道將數(shù)據(jù)寫入知識圖的過程，現(xiàn)在是我們導入數(shù)據(jù)的主要方式。 我們還計劃將其用于存儲回滾和第三方數(shù)據(jù)提取等功能 。
在存儲mutator中，我們還構(gòu)建了一個變異發(fā)布者，將數(shù)據(jù)突變傳播到Kafka消息總線。 下游管道可以為其產(chǎn)品用例使用這些消息。 一個例子是搜索索引管道，其中知識圖通過該模式將分類數(shù)據(jù)填充到搜索索引中。 我們將在下一節(jié)中深入研究這個用例。
運用分類法對旅行世界進行分類
如今，Airbnb上有超過500萬家庭。 為了幫助旅行者找到最佳旅行之家，我們首先需要對我們平臺上的每個家庭建立深刻的理解。 例如，哪些房屋最適合家庭，哪些房屋可以24小時辦理登機手續(xù)？ 為了支持這個用例，我們在知識圖中構(gòu)建了一個豐富的分類法 ，并將其用于對Airbnb的所有庫存進行分類 。
在悉尼尋找“海濱”住宅
分類
為了豐富知識圖中的語義 ，我們構(gòu)建了一個分類法作為我們本體的一部分，這是我們用來描述我們的庫存和我們周圍世界的詞匯。 分類法采用層次結(jié)構(gòu)，表示不同粒度級別的概念，以便我們可以將更高級別的概念映射到非常具體的概念。 例如，上面屏幕截圖中的“Beachfront”是我們分類中的標簽，而其父標簽是“Nature Venue”，祖父母標簽是“Venue”。
Airbnb的分類標準的子集
我們的分類法甚至在知識圖之前就開始了，目的是在Airbnb上對經(jīng)驗進行分類。 之后，分類法作為一種特殊類型的節(jié)點遷移到知識圖中。 如今，該分類法被修訂為通用的，適用于Airbnb的所有業(yè)務垂直（ 家庭 ， 經(jīng)驗 ， 餐館等）以及存儲在其中的其他類型的實體（如地點 ， 事件等）。知識圖。
鑒于分類法在知識圖中發(fā)揮的基本作用，我們將分類法節(jié)點與其他類型的節(jié)點區(qū)別對待。 對分類標準的任何編輯都需要由一個由內(nèi)容策略師，產(chǎn)品經(jīng)理和工程師組成的跨職能團隊進行討論和批準，然后才能執(zhí)行。
分類
為了對Airbnb的庫存進行分類，每個體驗，家庭或餐館都需要使用分類中的相關(guān)節(jié)點進行標記。 這個過程一直充滿挑戰(zhàn)。 一方面，人力分類昂貴且難以擴展; 另一方面，自動分類工作需要額外的工作來確保準確性。 以下是我們探索過的幾種不同方法。
Airbnb體驗由全球運營團隊手動標記。 為了促進這一過程，我們構(gòu)建了一個管理標記工具，其中包含簡潔的UI。 （將來，我們的主機可能會承擔一些此過程。）
手動分類體驗的工具
對于自動分類，我們測試了幾種不同的方法。 首先，我們直接從庫存元數(shù)據(jù)中進行知識推斷 。 為了對具有位置設施的房屋進行分類（例如上面示例中的“海濱”）， 供應動態(tài)團隊正在采用將kd樹應用于家庭位置以及從家庭描述和客人評論中提取文本的組合。 他們還為主機建立了一個反饋循環(huán)（見下文），以確認他們的推理結(jié)果。
主人可以確認他們家的位置設施
此外， AI Labs團隊還應用Airbnb Homes嵌入了Home的描述，Home鄰居的描述和主持人的個人資料描述。 基于嵌入，他們正在積極致力于推斷Airbnb家庭可能缺少的設施。 AI實驗室將發(fā)布一篇關(guān)于他們工作細節(jié)的文章。
為用戶提供旅行環(huán)境
到目前為止，我們已經(jīng)探索了一些產(chǎn)品接觸點，以便在預訂流程中為用戶提供上下文旅行洞察。 以下是Airbnb知識圖授權(quán)的一些??功能。
鼓勵用戶選擇目的地
為了幫助用戶選擇目的地開始搜索，我們在主頁上推出了一系列鼓舞人心的目的地輪播。 我們在知識圖中存儲了數(shù)百張目的地照片，然后向用戶提供最相關(guān)的旅行創(chuàng)意。
Airbnb主頁上的一組熱門歐洲旅游目的地
幫助用戶選擇一個家庭預訂
選擇目的地后，用戶開始決定一個家庭。 為了幫助指導用戶，我們使用知識圖來表達目的地中的住宅的背景和洞察力。 在某些情況下，我們重點介紹熱門設施（見下文），頂級地標或有趣的社區(qū)。
建議用戶預訂帶游泳池的房屋，因為“去年訪問洛杉磯的客人中有33％搜索了帶游泳池的房屋”
提供有關(guān)房屋的更多背景信息
我們從研究中了解到，用戶經(jīng)常希望找到一個接近特定興趣點的房屋，無論是迪斯尼樂園還是盧浮宮。 為了幫助用戶了解特定列表與關(guān)鍵地標的關(guān)系，我們使用知識圖來展示特定家庭附近的內(nèi)容，并在PDP上顯示該信息（見下文）。
顯示洛杉磯一個家的當?shù)乇尘?/p>
最后的想法
我們在知識圖中的工作已經(jīng)幫助我們極大地增強和個性化了Airbnb的搜索，供應分組和內(nèi)容交付。 也存在挑戰(zhàn)，特別是在數(shù)據(jù)質(zhì)量和在線性能方面。
為了解決這些問題，我們正在利用最先進的機器學習，統(tǒng)計，優(yōu)化模型和算法。 具體來說，我們正在建立卷積神經(jīng)網(wǎng)絡（CNN）來審查標記的質(zhì)量。 此外，我們正在部署上下文多臂強盜模型，以推薦在線服務中的個性化內(nèi)容。 此外，通過利用產(chǎn)品，用戶和搜索查詢嵌入技術(shù)，我們希望生成以前在人工定義的分類集中不可用的新類別。 目前，這些方法還處于試驗階段，敬請期待！
我們開始使用知識圖，以便為清理，當前和完整的有關(guān)我們的庫存和整個旅行世界的結(jié)構(gòu)化數(shù)據(jù)提供一致的界面 。 通過提供連接 的高質(zhì)量數(shù)據(jù)，我們相信知識圖有很大機會改善Airbnb的訪客和主機體驗。 在2019年，我們將不斷投資使用我們的知識圖來豐富我們對旅行世界（ 分類 ）的理解，并在旅行計劃和決策過程的每一步為每位旅行者提供更多旅行內(nèi)容（ 情境化 ）。
?
https://medium.com/airbnb-engineering/contextualizing-airbnb-by-building-knowledge-graph-b7077e268d5a
總結(jié)
以上是生活随笔為你收集整理的Contextualizing Airbnb by Building Knowledge Graph的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： zabbix监控链接
- 下一篇： 项目管理平台（总结篇一）