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

騰訊技術工程發表於2020-04-06

本文作者:sololzluo,騰訊 AI Lab 開發工程師

一. TurboSearch 簡介

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

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

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

  • 支援便捷 私有化部署

  • 高效能索引及 並行檢索

  • 支援 多粒度索引 及檢索

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

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

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

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

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

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


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

二. 引擎框架介紹

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

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

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

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

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

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

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

TurboSearch 基礎框架:

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

三. 引擎特性

1. Query 檢索召回

檢索多次下發

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

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

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

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

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

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


2. QRW & 分層打分排序

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

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

3. 高效能檢索

並行檢索

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

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

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

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

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

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

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

Weak-AND

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

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

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

倒排效能優化

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

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

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

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

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

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

其中:

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

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

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

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

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

4. 多粒度索引

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

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

5. 海量資料索引支援

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

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

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

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

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

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

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

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

  • 過濾庫 filter

  • 打分庫 score

  • 求交 intersect

  • 語法樹 syntax

  • 分詞庫 segment

7. 私有化部署

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

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

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

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

四. 系統運營

1. 離線、線上運營架構

以較小資料量的 FOB(實時記憶體索引系統)叢集為例,離線、線上運營系統通過以下設計保證穩定持續服務:

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

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

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


2. 干預系統

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五. 應用場景和展望

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

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

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

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

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31559354/viewspace-2666278/,如需轉載,請註明出處,否則將追究法律責任。

相關文章