在AI快速發展的浪潮中，傳統的關鍵詞搜索早已難以滿足用戶日益復雜的需求。尤其在酒店預訂領域，如何精準理解“2大1小”“江浙周邊遛娃”這類模糊卻真實的意圖，成了提升用戶體驗的關鍵。本文將帶您深入探索語義搜索如何顛覆傳統檢索方式，從實體識別、向量召回到大模型加持的語義理解，全面解析攜程在智能搜索上的技術路徑與實踐經驗。讀完此文，您將看到一個未來——用戶只需自然表達需求，系統便可一步到位，智能推薦最匹配的酒店。這不僅是搜索技術的革新，更是用戶體驗的革命。

一、背景

二、我們的目標：降低搜篩費力度

三、核心AI能力

3.1. 命名實體識別

3.2. 實體鏈接

四、總結與展望

一、背景

過去一年，人工智能（AI）搜索技術實現了迅猛的發展，攜程也已推出了自研的智能產品，如“問道”、“TripGen”等。這些產品底層均應用了先進的語義搜索能力，以提升垂直領域的信息召回與用戶體驗。

傳統在線酒店預訂流程通常以關鍵詞搜索為核心，是用戶選擇酒店的重要通道之一。如果在酒店搜索流程中進一步融入更智能、更貼合用戶意圖的語義搜索能力，將極大地改善用戶的預訂體驗，使所有用戶都能直觀地感受到AI帶來的便捷與精準。

傳統搜索引擎大多依賴于倒排索引技術，即通過關鍵詞精確匹配的方式來滿足用戶的基本搜索需求。但隨著用戶期望與搜索習慣的持續演變，這種單一的關鍵詞匹配方式逐漸暴露出明顯不足。

例如，以下用戶查詢無結果 ：

• 上海的五星級酒店推薦
• 上海帶室內溫泉的酒店
• 江浙周邊適合遛娃的酒店
• 靜安寺1公里以內的酒店
• 京都當地特色酒店
• 太湖周邊四星以上酒店
• 上海2大1小適合帶娃中高端酒店
• 上海2大1小11月份3天2晚適合帶娃的熱門酒店
• 浙江網紅出片的酒店

這些問題的深層原因在于：

首先，倒排索引技術對關鍵詞表達的精確度要求極高，因此用戶若未使用標準關鍵詞，搜索結果的相關性便會顯著下降。例如系統可以識別“寵物友好”，但難以關聯用戶搜索的“可以帶寵物”意圖。

其次，現有搜索引擎在處理詞義歧義時能力有限，無法在上下文中靈活判斷用戶的真實需求。

最后，缺乏深層語義理解能力，使得搜索引擎在處理復雜查詢時難以捕捉語言的多樣性和細膩性，從而限制了用戶體驗的提升。

二、我們的目標：降低搜篩費力度

 以下以“上海熱門泳池酒店”為例，展示用戶因缺乏語義搜索功能所面臨的繁瑣操作：

1）初次查詢無結果 ：用戶在搜索框中輸入“上海熱門泳池酒店”，結果為空，找不到符合需求的推薦。

2）嘗試調整查詢詞 ：用戶簡化查詢詞，輸入“上海泳池”，找到上海包含泳池的全部酒店。

3）嘗試到篩選項手動篩選“熱門泳池” ：

• 此時，系統未將“熱門泳池”列為熱門篩選項，用戶需在篩選列表中滑動五個屏幕，才能找到“特色泳池”相關篩選項（而且用戶內心未必覺得完全match心中所需）。
• 最終，用戶篩選出上海特色泳池酒店列表，再次進入瀏覽頁面查找心儀的酒店。

這個例子展示了一個看似簡單的搜索意圖背后的真實用戶搜索過程。由于搜索系統缺乏語義理解能力，用戶不得不降低搜索的復雜度，從“上海熱門泳池酒店”簡化到“上海泳池”，再通過篩選項進行自行手動篩選。在沒有語義搜索的情況下，用戶通過簡化搜索詞邏輯、擴大搜索召回結果，然后手動進行細粒度篩選來實現搜索目的。這一過程不僅耗時，而且用戶體驗不佳。此外，用戶在搜索過程中可能會因為鏈路過長而失去耐心和信心，最終導致用戶離開應用程序。

1）“上海熱門泳池”無法被正確識別

2）只能單獨搜索“上海泳池”

3）到篩選項手動篩選“特色泳池”

4）酒店列表頁瀏覽

我們的目標：降低搜索費力度

當用戶輸入“ 東京2大1小2間房明年2月5入住7天親子酒店推薦 ”查詢時，系統會自動將其中的各要素（如地點、入住人數、日期、房間數量等）與相應篩選條件匹配，直接引導用戶至符合條件的酒店列表頁面。這樣的智能搜索流程極大簡化了操作步驟，消除了手動設置篩選條件的繁瑣過程。用戶不再需要反復調整篩選項，而是能夠直接獲得高度相關的結果。這不僅顯著減少了搜索和篩選的時間與精力消耗，還大幅提升了用戶體驗，使用戶能夠更快速、輕松地找到符合特定需求的酒店選項。

用戶輸入：東京2大1小2間房明年2月5入住7天親子酒店推薦

列表頁自動匹配：

三、核心AI能力

為了實現語義搜索，我們使用了以下先進的AI技術：

實體識別技術： 語義搜索的實現依賴于AI深度學習技術，它能夠對用戶輸入進行實體識別。當用戶輸入復雜的搜索詞時，系統通過深度學習模型自動識別出關鍵實體（如地點、日期、房間類型等），并準確區分同一詞匯在不同上下文中的含義。這使得搜索引擎能夠精準理解用戶的真實意圖，避免因歧義導致的錯誤結果。

實體鏈接技術：語義搜索還依賴于強大的實體鏈接技術，這塊主要是依靠向量搜索能力來實現與OTA垂直領域系統的無縫對接。通過將用戶的搜索內容與垂直領域信息向量化，系統能夠在高維空間中精準匹配用戶需求。這種向量搜索不僅突破了傳統的關鍵字匹配限制，還深度理解用戶的語義輸入，將其需求與OTA系統中的海量信息高效關聯，從而提供個性化和高度相關的搜索結果。

3.1. 命名實體識別

在用戶搜索時，搜索引擎需要理解搜索詞的深層含義，而這種理解依賴于命名實體識別（NER, Named Entity Recognition）技術。NER是自然語言處理（NLP）中的關鍵技術之一，它能夠從文本中識別出特定的實體（如人名、地名、時間、組織等），并對這些實體進行分類。通過NER，搜索引擎能夠識別和提取用戶搜索詞中的關鍵信息，使搜索結果更加精準和相關。

NER的核心功能

在酒店搜索場景中，NER的核心功能是識別用戶查詢中的關鍵信息，以便理解用戶的真實需求。例如，當用戶輸入“江浙周邊適合遛娃的酒店”時，NER模塊可以識別出“江浙”、“遛娃”和“酒店”三個關鍵實體：

•  “江浙” ：被識別為地理位置。
•  “酒店” ：作為搜索目標。
•  “遛娃” ：描述所需的酒店屬性，即適合帶孩子。

同時，NER模塊會過濾掉無關的詞匯（如“的”、“周邊”、“適合”等），從而提升搜索引擎對用戶意圖的識別精度。這種精準的實體識別能力，使NER成為實現精確搜索和推薦的第一步。

3.1.1. 基于LLM的實現

在設計方案時，我們充分參考了NLU技術的演進歷程，從早期的基于規則的方法到統計模型，再到深度學習的應用。這一歷程幫助我們清晰認識到各種技術方案的優劣：

• 基于規則的方法 ：在特定領域和簡單場景中表現良好，但高度依賴專家規則，靈活性和擴展性較差，難以適應復雜多樣的用戶查詢。
• 統計方法 ：在數據驅動任務上有所突破，但在細粒度的語義理解方面，精準度仍然不足。
• 深度學習方法 ：提高了特定任務的NLU效果，但需要大量標注數據，且跨領域泛化能力有限。

基于以上技術的局限性，我們決定在方案中直接采用千問7B這樣的大型語言模型（LLM）。相比傳統方法，千問7B具有明顯優勢，其深層語義理解能力、廣泛的知識儲備和跨領域的泛化能力特別適合酒店搜索等復雜場景。在設計上，千問7B的高維嵌入和注意力機制能夠精準識別復雜查詢中的細微語義。例如，當用戶輸入多條件查詢時，千問7B可以快速識別出不同的語義成分（如地點、設施、偏好等），并將這些條件精確映射到相應的酒店特征上。

模型優化

此外，我們利用TensorRT對模型進行加速，通過實施層間融合、張量融合以及在推理過程中采用較低精度的計算，有效地提升了在線推理的性能并減少了內存占用。這些優化措施將在線推理的響應時間從3000毫秒大幅縮短至300毫秒左右，顯著提高了實體識別的效率。

3.2. 實體鏈接

在用戶搜索過程中，實體識別模塊成功識別出搜索中的關鍵實體后，接下來需要將這些實體與OTA（在線旅行社）領域的知識圖譜進行匹配。這一任務由實體鏈接模塊（Entity Linking）完成。Entity Linking的作用是將用戶輸入中的實體（如地名、酒店類型、特色服務等）與知識圖譜中的對應節點精確關聯，使得系統能夠召回所有符合條件的酒店。

Entity Linking的核心技術包括實體嵌入（embedding）和向量引擎召回機制。實體嵌入通過將識別出的實體轉化為特定的數值向量，使其可以與知識圖譜中的節點相匹配。向量引擎則基于這些嵌入向量快速搜索相關內容，從而精準地找到符合用戶需求的酒店，確保搜索結果既準確又相關。

3.2.1. 實體嵌入技術

在實體鏈接任務中，選擇合適的嵌入模型 (embedding model) 至關重要，因為模型的性能直接影響實體匹配的準確性和召回效果。經過對比分析，我們評估了多種嵌入模型在多語言和中文環境下的表現，以找到最優方案。

模型選擇與部署

在多語言環境下，E5系列模型表現優異，而在中文環境中，BGE系列模型更為出色。由于遠程調用大型語言模型（LLM）的響應時間通常超過1秒，難以滿足生產環境的實時性需求，因此我們選擇了本地部署。通過對比發現，BGE-M3模型在顯存占用和響應速度上與E5系列相當，但在召回精度上更符合我們的需求，因此BGE-M3成為首選方案。

性能對比與閾值設置

在模型性能對比中，E5小型模型的相似度分數分布較集中，即使完全不相關的句子，相似度也常高于0.8。因此在E5模型中，設定相似度閾值在0.93可能導致負樣本過度召回，而提高到0.94則容易漏掉正樣本。

相比之下，BGE-M3模型的分數分布更為離散：對相似句子給出高分，對不相似句子則給出低分，從而便于合理設置閾值。實測數據表明，BGE-M3在低分句子上的相似度確實較低，驗證了其良好的區分能力。

結論

最終，我們選擇BGE-M3模型作為實體嵌入的最佳方案。BGE-M3不僅在中文環境下表現優異，還有效平衡了召回率和準確性，使其在實際場景中能夠精準、高效地支持實體鏈接任務。

3.2.2. 向量召回機制

在向量召回機制的設計過程中，我們對當前主流的向量數據庫方案進行了調研分析，評估維度包括性能表現、系統擴展性以及資源投入等多個方面。結合攜程酒店搜索業務的特點與實際需求，我們選擇了基于Elasticsearch（ES）的方案，構建向量召回能力，以實現穩定可靠的向量檢索與管理。

目前常見的向量數據庫解決方案大致可以分為三類：向量索引組件+自建服務、專用向量數據庫以及傳統數據庫+向量索引組件。不同類型的方案在部署方式、系統特性和應用場景上具有各自的優勢。如下圖所示：

向量索引組件 + 自建服務

此類方案通常基于開源的向量檢索庫，如 Faiss、SPTag 和 Lucene HNSW。它們具備靈活性強、可控性高等特點，適用于對系統定制化有較高要求的場景。該方式需要搭配自建的數據服務和檢索框架，適合具備一定技術能力和運維能力的團隊。

專用向量數據庫

如 Milvus、Qdrant 和 Proxima 等，專為向量檢索場景設計，具備良好的系統性能和一定的可擴展能力。此類產品適合對向量搜索精度和響應效率要求較高的場景，在部分業務中已具備較成熟的使用實踐。

傳統數據庫 + 向量索引組件

典型如 Elasticsearch、PostgreSQL（pgvector）和 RedisSearch。此類方案在保留傳統數據庫能力的同時，通過集成向量索引功能支持近似向量檢索。它們在系統穩定性、生態支持和集成成本方面具備一定優勢，適合業務需求相對明確、對系統易用性要求較高的場景。

綜合考慮業務穩定性、系統維護成本與平臺技術棧的契合度，我們最終選用了 Elasticsearch 作為向量召回機制的核心組件，并結合 HNSW 向量索引構建方案。該方案在攜程酒店搜索場景下運行良好，滿足了高效召回的性能要求，同時也保障了系統的易維護性與整體成本的可控性。

索引技術與算法選擇

為確保高效的向量檢索，我們在ES中采用了HNSW算法 (Hierarchical Navigable Small World)。HNSW算法能夠在高維空間中實現快速的最近鄰搜索，非常適合精確匹配的實體鏈接任務。對于酒店搜索，向量召回的核心任務是將用戶意圖與知識圖譜中的酒店數據準確對接。

四、總結與展望

通過語義理解技術，搜索引擎正在從傳統的被動式信息呈現方式，轉型為更加智能、互動的用戶體驗平臺。不再簡單地平鋪所有內容，而是基于用戶需求精準推送相關信息，真正做到“用戶需要什么，我們就提供什么”。

主動預測和理解用戶的潛在需求，使用戶無需費力在屏幕上滾動或篩選大量信息，快速找到所需內容。例如，用戶可以通過自然語言輸入復雜問題或多維需求，而搜索引擎則會根據語境、個性化偏好以及語義關系進行精準匹配和推薦。這種以用戶需求為中心的互動方式，將使得搜索體驗更加順暢、自然。

通過將AI技術深入融入搜索過程，未來的搜索平臺將實現從信息提供到全方位服務的跨越，幫助用戶在更短時間內完成決策，同時提供更高質量的體驗。