加入 Zilliz AI 初創計劃
Zilliz AI 初創計劃是面向 AI 初創企業推出的一項扶持計劃，預計提供總計 1000 萬元的 Zilliz Cloud 抵扣金，致力於幫助 AI 開發者構建高效的非結構化數據管理系統，助力打造高質量 AI 服務與運用，加速產業落地。文末點擊[閱讀原文]瞭解更多。
攜程集團(Trip.com Group) 是全球領先的一站式旅行平臺，旗下的平臺可面向全球用戶提供一套完整的旅行產品、 服務及差異化的旅行內容，能夠提供超過 120 萬種全球住宿服務。
而隨着攜程用戶需求和搜索行爲日趨複雜多樣化，基於文本匹配的檢索方法已經不能夠很好地滿足用戶在個性化精準搜索方面的需要。其中比較常見的問題有多義詞問題。基於文本的檢索方法主要依賴於關鍵詞匹配進行搜索和排序，所以會忽視搜索意圖背後更深層次的語義信息，導致對搜索結果的準確性和召回率的性能上有較大的影響。例如，查詢“蘋果”可以指代水果，也可以指代科技公司。同時，傳統的搜索引擎在處理長尾查詢上也往往出現召回效果不佳的情況。
此外，酒店搜索還會涉及到豐富的信息維度，如酒店的位置、房間類型、標籤、評價等。傳統的文本匹配方法難以有效整合和利用這些多維信息，對於多條件的精確搜索和篩選也有一些乏力。搭建向量引擎可以有效地解決上述問題，本文將詳細介紹向量引擎在攜程酒店搜索中的應用場景和相關經驗。
01.
當前侷限性剖析
侷限性之一：用戶和商戶表述差異
搜索引擎的索引數據是基於攜程酒店搜索引擎團隊採集的酒店信息、設施信息、地理信息等基礎數據建立的。然而，不同用戶的搜索習慣因人而異，商戶和用戶的描述也存在差異，不同商戶在維護信息時也會千差萬別。因此，搜索引擎需要具備一定的語義理解能力，使其能夠順利的在用戶搜索輸入和商戶維護詞彙之間進行匹配，以便準確地召回用戶最想要的結果。
舉個例子，如果商戶維護了一個名爲"帶寵物"的設施服務標籤，如果有一部分用戶的輸入是"能夠帶寵物"，相關的設施服務和酒店就無法被搜索到。以往的常規解決方案是給"帶寵物"標籤添加別名"能夠帶寵物"，這樣可以通過關聯別名來解決用戶和商戶之間的表述差異，使得不同的搜索輸入能夠召回同一類型的結果。然而，這種方法存在一定的侷限性。別名的選擇依賴於現有搜索詞的點擊情況，如果搜索引擎中沒有某個詞，那麼該詞就不會被展示出來，從而無法產生點擊行爲，那麼該別名就無法被髮掘到。
侷限性之二：不同語種的表述差異
舉個例子，在攜程海外搜索場景中，如果在多語言標籤庫中沒有維護"無料Wi-Fi"，搜索"無料Wi-Fi"時，搜索結果中就沒有相關的酒店設施標籤。在這種情況下，"無料"一詞在日語中意味着免費，"無料Wi-Fi"實際上想要表達的是可以免費使用的無線網絡連接。然而，如果沒有維護多語言的標籤名稱，搜索引擎將無法正確識別用戶的意圖，導致搜索結果不準確。
爲了解決這個問題，團隊的解決方案是補充維護更多不同語言的標籤信息，例如將設施標籤的日文表達"無料Wi-Fi"添加到搜索引擎中。但這種方法依賴於翻譯庫的準確度和豐富度。由於詞庫龐大，很多詞無法進行人工翻譯，可能只能依靠機翻，這就存在準確度的問題，翻譯的準確性對於能否搜索到所需內容有很大影響。
侷限性之三：不同背景下的音譯表述差異
由於音譯表述的差異，用戶可能使用不同的拼寫或注音來搜索同一個詞或短語。如果搜索引擎無法正確理解用戶的音譯表述，用戶換一種音譯翻譯詞搜索就無法找到相應的結果，可能會導致搜索結果的相關性和準確性下降。舉個例子，當用戶搜索"荷里活"時，搜索結果可能全是中國的地標，而當搜索"好萊塢"時，則會正常召回美國好萊塢的相關結果。
常規的解決方案是添加同義詞"好萊塢"和"荷里活"之間的關聯，例如將"荷里活"作爲"好萊塢"的別名，並在商區實體維護中進行相應的標註。這樣可以確保搜索引擎既能召回相關結果，又能保證結果的排序準確性。但是由於音譯詞組合的多樣性，有可能導致指數級別的爆炸問題，搜索引擎會承受的巨大索引壓力，且收益不佳。
02.
向量引擎的前期調研
通過上面的問題分析，可以看到，攜程酒店搜索面臨着泛化召回和模糊召回的場景需求。爲了能夠滿足需求，團隊考慮了使用向量查詢來幫助實現更準確的搜索。向量查詢是一種基於向量空間模型的信息檢索方法，其基本思想是將查詢和文檔表示爲向量，通過計算它們之間的相似度來確定匹配程度，以此來召回與查詢最相關的文檔。
爲了初步驗證向量化能否解決問題，團隊做了一個簡單的初步驗證：通過調用 OpenAI 的 text-embedding-ada-002 模型來獲取查詢詞(query)和酒店名(item)的向量表示，並利用這些計算向量之間的餘弦相似度。一般在語義上越是相似的詞，其向量之間的相似度越高。可以根據計算向量的相似度，評估文本之間所包含的語義相似度。
從驗證結果來看，通過對比不同詞語的向量相似度，可以區分出具有相同含義的詞語和語義有差異的詞語。那麼向量相似度可以作爲攜程酒店搜索提供更準確的語義相似度衡量方式，引入向量引擎來改進攜程酒店搜索結果的質量是一種可行方案。
03.
向量引擎的架構設計
04.
技術選型
向量化模型選型
向量化模型是我們實現向量引擎的第一塊基石。團隊對比了一些常見的語言向量化模型，就準確率而言， multilingual-e5 和 Luotuo 都表現出相對較高的準確率。
dmultilingual-e5 在多語言處理方面具有更好的表現，相比之下，Luotuo 在小語種處理方面表現不佳。就性能而言，大模型（超過 1B 參數）的在線推理速度較慢，不適合實時調用。所以綜合考慮準確率和性能兩方面原因，團隊最終選擇了 multilingual-e5 模型作爲語言模型。
向量數據庫選型
向量數據庫則是支撐向量引擎進行向量檢索的的另一大基石。根據市場上的選擇，向量引擎可分爲三類：向量索引組件+自建服務、專用向量數據庫和傳統引擎+向量索引組件。
在進行技術選型時，攜程酒店團隊對向量引擎的幾種實現方式進行了分類和對比，以便於根據具體需求和考慮因素來選擇最適合的向量引擎，以此滿足開發和業務的需求。
對於向量索引組件+自建服務的方式上來說：爲適應具體的應用場景和數據特點，可能需要更多時間的學習組件及額外編寫代碼處理索引的構建更新等，這可能增加了使用和維護的難度。傳統引擎+向量索引組件這個方向上，公司的基礎服務部門如果有這方面的支持，對於使用方來說，也是一種比較省力的辦法。還有一個方向是使用專用向量數據庫，所謂專業的工具做專業的事，可以實現事半功倍的效果。
經過上面的對比，團隊選擇將 Milvus 作爲向量引擎，原因如下圖所示：
在服務能力上，爲了確保能夠滿足接口服務的響應時間要求，團隊對 Milvus 進行了相關性能測試。從測試環境下的測試結果可以看到，兩種索引均能保證在 30ms 左右召回。IVF-SQ8 索引佔用內存相對較少，優點是可實現單機部署，但該索引方式在召回性能上會略差於 HNSW，可根據實際需求平衡選擇哪種索引結構做向量數據存儲。
05.
向量引擎搭建實現
向量化服務
向量化服務主要包含三個方面的工作，即在線向量服務、實體數據離線向量化和向量化召回服務。
在線向量服務：通過文本在線向量化服務，用戶可以將文本數據轉換爲數值向量表示，從而方便進行文本相似度計算等任務。使用的是 multilingual-e5 預訓練的文本向量模型，可以直接使用這些模型進行文本向量化，無需自行訓練。
實體數據離線向量化：該服務將實體數據轉化爲向量形式並做持久化，以便後續的向量檢索和召回使用。
向量化召回服務：向量化召回服務會對召回的向量會進行相關的依賴檢查，確保召回的實體滿足業務需求。最終，該服務會返回 TOPK 個最相似的滿足依賴檢查的實體。
06.
向量數據庫部署搭建
Milvus 部署的前置依賴
Milvus 向量數據庫的部署的前置依賴是對象存儲、消息隊列和分佈式鍵值存儲。
分佈式鍵值存儲：團隊使用的是 ETCD 負責存儲和管理各個節點的配置信息，用於配置和服務發現。
消息隊列：團隊使用的是公司提供的 Kafka 基礎服務，用於實時數據處理和消息傳遞。
對象存儲：團隊使用的是公司提供的對象雲存儲平臺，用於存儲向量數據和相關的元數據。
Milvus 部署情況
部署方式
團隊使用的是 GitHub 上的源碼構建自定義鏡像的方式進行 Milvus 向量數據庫的部署。版本爲：v2.3.1。基於攜程 k8s 基礎服務平臺，採用了集羣部署方式。
部署節點
針對於 Milvus 數據庫的部署模塊，集羣部署方式需要部署以下 8 個組件，分別是訪問代理層（proxy）、協調節點(Root coordinator，Query coordinator ，Data coordinator，Index coordinator)和執行節點(Query node，Data node，Index node)。
索引選擇
索引選擇的 HNSW 索引。HNSW 是基於圖的索引，該索引具有高效的近似最近鄰搜索，在處理高維度向量數據時表現出色，適用於追求高查詢效率的場景。
資源大小
在 Milvus 的部署中，參考 Milvus 官方提供的工具和根據實際的數據量和維度來配置資源。實際生產環境中，數據量達到了 3100 萬+，每個向量數據的維度爲 1024 維。下圖展示了各個節點的資源配置情況：
07.
向量引擎的使用場景
場景一：攜程酒店搜索場景
未引入向量引擎前，在直搜和聯想場景下，例如搜索"美麗夜景"，可能只能召回兩家酒店。但如果搜索"不錯夜景"，則可以召回更多酒店。"美麗夜景"和"不錯夜景"實際上都是酒店的一種標籤類型，可以視爲同義詞。從查詢語義的一致性上來說，使用"美麗夜景"應該具有召回"不錯夜景"酒店的能力。因此，該場景下，可以引入向量引擎來實現同義詞的召回，得到更準確的結果召回，以滿足用戶的需求。
攜程酒店搜索引入向量引擎召回的過程總覽如下：
查詢理解：根據用戶的輸入詞進行查詢理解，生成查詢理解語句。
召回階段：召回階段包含文本召回和語義召回。
a. 文本召回：對查詢理解語句進行切詞，使用文本匹配的方式進行召回。
b. 語義召回：語義召回包含意圖召回和向量召回。意圖召回是根據用戶的查詢輸入，進行意圖識別，並根據成功識別的用戶意圖進行酒店召回；向量召回是在無法準確識別用戶意圖的情況下，通過向量引擎進行向量召回。
合併和精排：根據召回的結果進行合併和精排的操作，最終輸出展示給用戶。
場景二：SEO 落地頁生成
SEO 落地頁生成整個過程如下：
關鍵詞挖掘：通過國際化團隊的挖掘結果獲取相關的關鍵詞。
實體召回：根據挖掘的關鍵詞召回相關的實體。
意圖識別：對用戶搜索詞做意圖分析識別。
向量引擎泛化召回：當意圖識別失敗時，使用向量引擎進行泛化召回，以擴大召回範圍。
相關依賴檢查：對召回的實體進行相關依賴檢查，確保召回的實體與用戶需求相關。
酒店相關召回：根據識別和泛化召回的實體，進行與酒店相關的召回。
篩選排序：對召回的酒店進行篩選和排序，按照產品規則進行處理。
精排：根據精細排名規則對召回的酒店進行精細排名，以優化搜索結果的質量。
生成 SEO 落地頁：根據最終召回和排名結果生成相應的 SEO 落地頁。
08.
總結
本文主要介紹了向量引擎在攜程酒店搜索中的應用場景和相關經驗，分別從以下幾個方面進行了介紹：
攜程酒店爲什麼需要向量引擎。攜程酒店搜索亟需提升泛化搜索能力，以此更好的解決傳統文本檢索的同義詞問題和長尾問題等。
探討了實現向量引擎如何做技術選型。在選擇向量數據庫時，根據攜程酒店的需求和實際情況，選擇了 Milvus 向量數據庫作爲解決方案。
介紹瞭如何設計搭建向量引擎，包括向量化服務搭建和向量數據庫部署等方面。
介紹了向量引擎在攜程酒店搜索中的使用場景，利用向量引擎的泛化召回能力，在酒店搜索場景和 SEO 優化上提高搜索結果的質量和準確性。
通過以上介紹，可以看出向量引擎在攜程酒店搜索中的重要性和應用價值，對向量引擎進行合適的選型和設計，能夠實現更精準高效的酒店搜索服務，提升用戶的搜索體驗。
本文作者
趙明辰 攜程酒店搜索引擎高級研發經理；劉陽 攜程酒店搜索引擎資深研發
本文分享自微信公衆號 - ZILLIZ（Zilliztech）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。