新一代海量資料搜尋引擎 TurboSearch 來了！

本文作者：sololzluo，騰訊 AI Lab 開發工程師

一. TurboSearch 簡介

AI Lab 多年一直在搜尋領域進行深耕和積累，繼搜搜網頁搜尋之後，陸續服務於微信搜一搜（公眾號文章、朋友圈、影片）、應用寶搜尋、地圖搜尋、音樂搜尋、影片搜尋、手 Q、QQ 群等精品垂直搜尋業務，以及雲搜中小資料搜尋業務。

從網頁搜尋繼承下來的搜尋系統，經過多年的需求迭代，越來越難以支撐結構級新特性更新。因此我們投入精力對整體系統重構和最佳化，重新構建了大規模、輕量級、松耦合、可裁剪、低運營成本 具有完整解決方案 的新一代搜尋系統 TurboSearch 。主要有以下特性：

• 完整的 分散式、海量 搜尋系統及運營解決方案

• 支援便捷 私有化部署

• 高效能索引及 並行檢索

• 支援 多粒度索引 及檢索

• 支援普通檢索、分類檢索、WAND 及精細化的檢索層過濾邏輯

• 核心元件 解耦，支援橫向擴充套件，能力可裁剪

• 無縫對接 AI Lab 各項 NLP 能力，涵蓋 Query 分析及排序等多個領域

• 支援場景豐富，除傳統的網頁和各類非結構化垂類場景外，同時 可擴充套件 到多模態向量搜尋場景

與業界部分開源引擎框架 ElasticSearch，Solr 等不同的是，TurboSearch 更傾向於面向線上 *高併發、大規模、低時延* 的檢索需求，同時能夠平行擴充套件到多模態場景，並提供完整的搜尋運營能力。TurboSearch 在將會分層次和分階段逐步在公司內部開源。

在 多模態/向量檢索 領域，AI Lab 已經推出 GNES 檢索系統，聚焦於內容物件的 Encoding，以及多種演算法模型的平臺化整合。同樣在向量檢索領域，TurboSearch 會逐步從索引層面，探索針對大規模向量資料集的高效能檢索。並從向量索引、及系統化運營層面為 GNES 提供支援。

二. 引擎框架介紹

TurboSearch 引擎主要有六大核心能力：

• 搜尋核心元件：基礎核心能力抽象和元件化，便於擴充套件，如索引計算、檢索核心等。同時為了降低多程式資源開銷，構建了多執行緒 C++ 檢索通訊框架 smqRPC。

• 搜尋基礎服務：基於搜尋核心元件分層包裝的檢索服務，主要包括離線索引、線上檢索及檢索接入三大層次。支援包括記憶體、磁碟索引在內的分散式索引及檢索環境。

• 搜尋 OSS 體系：包括離線索引生成、線上索引滾動更新、檢索干預、ABTest 等多項能力。後續將進一步完善包括好例、離線效果評估等其它精細化運營系統。

• 效果擴充套件元件：搜尋效果隨業務場景而變化，我們將打分排序解耦剝離，內建部分基礎相關性排序功能，也可自定義排序。

• API 元件：提供包括 SDK、smq 協議訪問及 HTTP RESTful 介面等多種訪問方式。

• Query 分析能力：除了基礎的分詞之外，也具備同義詞、糾錯、時新性計算、意圖識別、成分分析、非比留、新詞發現等全面能力。

TurboSearch 基礎框架：

三. 引擎特性

1. Query 檢索召回

檢索多次下發

一個 Query 的搜尋過程可以分為以下幾個主要部分：

• Query 分析（適用於網頁和垂搜），包括切詞、糾錯、擴充、改寫等。

• 檢索召回，包括倒排求交、截斷合併等。

• 打分排序，在 TurboSearch 中包含多層 rank 提高召回率。

然而，單次 Query 召回往往並不能達到搜尋預期。比如，搜尋 “吃雞”，只召回吃飯相關的文章可能難以命中使用者意圖。將其擴充為 “和平精英”，或其他熱點事件 Query，並將多次擴充結果融合，更容易命中使用者意圖。因此 TurboSearch 應對這樣的 NLP 擴充能力，原生支援多次下發結果融合。

2. QRW & 分層打分排序

QRW 是 AI Lab 多年積累的 Query 分析 NLP 服務，除了覆蓋垂搜所需的 糾錯 同義詞/非比留/基礎相關性等基礎能力之外，也涵蓋了全網搜尋所需具備的全部能力，如 Query 改寫/時新性/意圖識別/成分分析/文字分檔 等等。

在排序和召回層面，TurboSearch 設計了 5 層 Rank 來最大化提高召回率，從 L0 - L4 覆蓋離線、倒排求交、精計算、全域性精排等多個層面，為每個可能漏招環節做保障。

3. 高效能檢索

並行檢索

文字檢索召回的基礎即倒排求交：

最耗時部分集中在 求交+L1 打分 和 L3 打分。在傳統的程式設計中，這兩部分均在單執行緒中序列執行。使得在高頻詞檢索求交時，單次請求耗時難以控制。

TurboSearch 針對兩個高耗時流程，採用 多執行緒並行處理。將倒排索引切分，來並行化檢索求交+L1：

我們做了一些 特殊的無鎖多執行緒結果合併設計，避免合併結果等待導致閒置 CPU 的問題。負載未達 100% 時，平均檢索耗時可大幅降低（資料集為長文字新聞資料 250w）：

Weak-AND

Weak-AND 在廣告或推薦等小資料集召回場景下，已經有較多的應用。在海量資料檢索中，TurboSearch 正探索其在 長 Query 召回場景 下的應用。透過結合 Weak-AND 與 AND，平衡召回率和檢索效能。

Weak-AND 的效能最佳化和場景探索將持續進行。

倒排效能最佳化

求交召回過程中，倒排的索引結構設計，對求交耗時影響較大。記憶體實時索引倒排在設計上具有以下特性：

• 倒排索引需要支援 高效能同時讀寫，寫入新文件和讀取倒排求交的能力。

• 需要寫入 共享記憶體 避免程式停止導致索引需要重新載入。

• 倒排鏈中，儲存塊越多，效能越差，儘量避免倒排塊數量過多。

TurboSearch 對記憶體倒排索引做以下設計：

其中：

• BuddyAllocator 單執行緒執行， 分配釋放處理能力達 1000w/s。

• 分超小塊 CombinedChunk 和普通 SingleSlice，解決超短倒排儲存率問題。

• 小塊 SingleSlice 合併為大 SingleSlice，解決超長倒排中倒排塊過多問題。

對比老架構固定塊倒排索引：

4. 多粒度索引

不同於 N-gram 這種暴力索引方式，多粒度索引專注於文件與 Query 中的隱性片語發現，對正常分詞補充。檢索時先進行粗粒度詞召回，如果粗粒度無結果或結果偏少，將再次進行細粒度詞召回。透過這個方式來解決鬆散召回導致的緊鄰結果截斷問題。

如 “海底撈永珍城店” 對應的粗粒度索引為 “P:海底撈 永珍城 店”，保證結果能緊鄰命中召回，如果在粗粒度檢索無結果時，將再次使用 “海底撈”、“永珍城”、“店” 進行檢索召回。既保證了準確性，也能兼顧召回率。

5. 海量資料索引支援

對於海量資料搜尋業務場景，脫胎於網頁搜尋的 TurboSearch 繼承三種型別的索引叢集結構:

• FOB，全記憶體索引，支援實時增刪。

• GOB/NOB，記憶體倒排+正排，磁碟摘要，不支援實時增刪。

• WOB，磁碟索引，不支援實時增刪。

根據不用搜尋業務資料場景需求，可將各類索引叢集組合達到設計目標。

6. 核心邏輯功能外掛擴充

TurboSearch 引擎考慮到自定義功能開發擴充，目前對以下核心功能做了外掛支援：

• 過濾庫 filter

• 打分庫 score

• 求交 intersect

• 語法樹 syntax

• 分詞庫 segment

7. 私有化部署

TurboSearch 整體設計上支援私有化部署。在公司內網環境運營時，可使用已有的服務元件，如 CL5（名字服務）、Sumeru（資源管理） 等。然而在私有化部署場景下，這些公共服務難以一同打包部署。因此 TurboSearch 對這些功能 均有 內建相應能力，可選擇使用，並基於以下設計支援私有化實現：

• 開發和部署上，較少的內部環境和外部專案依賴。

• 從運營系統、DB 環境、服務模組均可支援 Docker 部署。

• 完善獨立設計的路由管理和資源管理。

四. 系統運營

1. 離線、線上運營架構

以較小資料量的 FOB（實時記憶體索引系統）叢集為例，離線、線上運營系統透過以下設計保證穩定持續服務：

• 全量資料平滑無縫版本更新，確保線上服務 不受資料滾動影響。

• 實時資料與全量滾動無縫銜接，確保滾動 不會導致實時資料缺失。

2. 干預系統

在現網運營中，檢索召回排序無法保證所有 Query 達到最佳。對於一些突發高曝光 Badcase，需要有 臨時干預能力。TurboSearch 在接入層設計了干預系統，並沉澱積累了大量干預策略，可覆蓋現網運營大部分干預需求。**主要支援兩大類干預型別：

• 通用干預規則，系統預先定義和實現了具體的干預處理邏輯。

• 自定義干預規則，提供干預規則的讀寫介面，滿足不同業務的特定干預需求。

3. 全流程檢索、資料診斷

在持續最佳化的海量資料搜尋業務運營過程中，會有持續或突發的 Badcase 需要定位。而一個海量資料搜尋業務中，一般都是 *多叢集、多機服務、多層邏輯* 的複雜系統。在整體系統中定位和診斷 Badcase 是一個複雜而困難的工作。比如一篇文件未被召回有以下多種可能：

• 文件資料入庫問題，某些原因資料被刪除或未入庫。

• 求交篇數階段問題，由於線上檢索考慮耗時和效能問題，無法做到全求交召回，召回太多被截斷。

• 求交超時截斷問題，出於耗時限制，超高頻詞之間的求交過程常常會出現超時截斷。

• L1 打分低未進入 L3，L1 取 Top300 進入 L3，因此 L1 打分過低可能導致無法召回。

• L3 打分低被合併截斷，每一層檢索轉發 access 服務均會對召回結果按照打分取 TopN 截斷返回。

• L4 打分低或被過濾，多叢集召回融合打分會丟棄掉一些文件。

• 語法樹本身無法召回目標文件，下發的語法樹全求交也不可能召回目標文件。

• …

一篇文章有如此繁多的漏召回可能性。TurboSearch 從線上服務模組和離線資料流程兩個方面入手，設計全流程的診斷，來協助快速定位召回和資料問題。

五. 應用場景和展望

目前 TurboSearch 已可應用在 傳統文字搜尋、關係鏈搜尋、LBS 位置相關搜尋、中心聚類向量搜尋 等場景。在持續改進引擎現有功能之外，我們還會做更多的探索：

• 持續最佳化 WAND 檢索效能，以及分析擴充其使用的 Query 場景。

• 探索基於倒排索引，引入 知識實體的連結類搜尋，比如搜尋 “騰訊總辦”，可從索引層面召回相應結果。

• 在 多模態/向量檢索 領域，探索新結構索引，比如圖式、樹式索引來最佳化向量檢索效能和效果。

• 逐步開源開放整個引擎，並構建協同開發生態。