動態

詳情 返回 返回

百度視頻搜索架構演進 - 動態 詳情

導讀

隨着信息技術的迅猛發展,搜索引擎作為人們獲取信息的主要途徑,其背後的技術架構也在不斷演進。本文詳細闡述了近年來視頻搜索排序框架的重大變革,特別是在大模型技術需求驅動下,如何從傳統的多階段級聯框架逐步演變為更加高效、靈活的端到端排序框架。

01 背景

過去近十年,搜索引擎的主流框架為多階段級聯框架,分為召回,粗排,精排幾個階段。在每個階段中,系統會基於相關性、質量、時效性和點擊率等維度獨立建模,然後通過模型融合這些信號進行排序和截斷,最終產出檢索結果。隨着以BERT、ERNIE和GPT為代表的預訓練大模型技術的逐漸成熟,利用一套端到端框架解決信息檢索問題變得越來越可行。同時,用户差異化,多樣化,深層次信息需求越來越強烈, 為了滿足這些需求,系統的算力需求也在不斷增加。在這種技術及需求趨勢的引導下,傳統視頻搜索排序架構如何演變,已經成為視頻搜索最重要課題,同時也對排序架構提出了重大的挑戰。

02 目標

以大模型技術為主線,打造高性能,擴展靈活的視頻搜索排序框架,同時完成存量排序系統的熵減治理,從而來大幅度提升排序系統的系統能力,降級系統長期運營治理成本。

03 問題與挑戰

  • 架構功能如何解耦:視頻搜索排序架構經歷了多年的積累和發展,已經形成了策略、架構和產品邏輯高度耦合的局面。這種耦合導致排序模塊承擔了過多且複雜的功能,直接影響了研發效率,並頻繁引發穩定性問題。此外,模塊功能定位模糊,嚴重製約了新產品和業務的快速落地與迭代。面對這些挑戰,我們亟需打破現有的陳舊框架,從更底層進行架構優化,以實現理想的業務和架構收益。
  • 系統效能如何提升: 目前核心排序模塊缺少靈活高效的並行計算框架,制約系統資源使用率的提升。與此同時,系統流量低峯時段會存在大量空閒資源,沒有得到充分使用,如何充分,高效挖掘這部分空閒資源資源,來滿足業務對資源大量需求。
  • 端到端架構如何演進:在端到端大模型技術的引導下,排序策略的複雜性將逐步被模型內部化,現有策略實現可以得到極大的簡化。傳統多階段級聯排序架構如何演進升級,以適應這種新的排序模式,也是一個需要深入研究和探索的重要課題。

04 整體思路

對上述問題和挑戰,我們採取了一系列綜合措施來加以解決。首先,為了解決架構耦合與複雜性問題,我們對核心排序模塊進行了深度重構,將原本集成在其中的召回處理與摘要計算功能獨立出來,從而實現系統分層的合理化。其次,採用支持串行、並行和數據並行的靈活框架,提升視頻排序流程的可視化管理和並行計算能力,並基於彈性算力分配控制中心,高效利用系統空閒資源,最大化搜索視頻業務收益。最後,在大模型端到端排序模式下,推動多階段級聯框架向單階段端到端框架轉變升級。下面詳細介紹以上解決方案的設計思想:

  • 核心排序功能解耦:
  • 視頻核心排序模塊是在線檢索核心模塊之一,之前承接排序和部分召回功能。累積了大量的視頻獨有的策略和業務邏輯,支持了視頻搜索業務的不斷髮展。隨着越來越多的策略、架構功能迭代,核心排序模塊也越來越臃腫,接手、開發、維護等成本不斷攀升。同時也面臨例如不支持雲原生、整體框架設計老舊、功能耦合嚴重等問題。
  1. 將排序模塊中召回處理階段獨立分拆,整體功能遷移至新的視頻召回模塊。
  2. 利用圖引擎將多Query串行執行升級至Query全並行執行,包含請求構建,Cache讀取,結果解析。
  3. 常用架構,策略功能組件化,插件化,易於理解、開發和維護。

圖片

△新召回模塊

  • 為滿足用户差異化,多樣化查詢需求,每次請求都需要重新進行召回,排序計算,摘要處理等階段。如果全量穿透系統緩存,會帶來巨大的資源,耗時增長,系統成本無法承擔,所以需要考慮目前視頻搜系統分層設計是否合理,是否需要重新設計。為解決視頻個性化帶來的資源,速度問題,我們對視頻搜索核心排序功能進行重新分層設計:
  1. 核心排序系統結果返回和摘要獲取解耦,視頻排序系統有能力提供更多量結果集,彌補之前機制能力缺失的短板。
  2. 新增個性化排序模塊,優化傳輸協議,在核心排序模塊返回更多結果基礎上,同時穿透更多基礎排序,供個性化排序使用。
  3. 根據最終個性化排序結果集合,對Top N進行摘要處理計算,最後返回給上游模塊。

    圖片

△視頻個性化排序演進

  • 系統效能提升:
  • 當前的視頻搜索排序框架採用單線多策略管理器的串行執行模式。這種單線程串行處理方式在吞吐量和延遲方面表現不佳。此外,框架缺乏靈活的並行化配置能力,依靠人工經驗引入各種omp,bthread等並行組件,並且存在歷史遺留的冗餘計算邏輯,架構組件較為陳舊。為了設計出能實際解決業務需求的現代引擎框架,我們對主流圖引擎的特性進行了調研總結:
  1. 驅動方式:排序層當有大量算子,上千維特徵時,無論數據驅動,還是人工編排,可讀性都很差。這種複雜性不僅增加了理解整個排序層架構的難度,還進一步影響了項目的研發效率。
  2. 並行方式:目前主流job/processer算子並行方式,沒有辦法很好去支撐算子job內部並行,排序列隊list/item-wise並行。排序數據通常含有多list, list內包含成百上千個item數據,這樣數據處理模式需要job內部靈活的並行計算方案。

圖片

△驅動&並行方式

  • 事實上,我們發現沒有一套圖引擎能夠完全滿足排序業務場景的需求。因此,我們提出了一種圖框架引擎主張,靈活的支持搜索排序各個場景。
  1. 除了支持serial,paralle模式,常見的job 間的串,並行模式,框架還支持data\_parallel模式。召回返回數據通常包含多list隊列,list隊列間要做排序,list內有成百上千個item,同樣需要排序,常見並行模式不能很好解決這種排序需求,所以我們在框架層做了data\_paralllel模式設計,讓它契我們當前排序模式,支持list+item的混合排序模式,同時能滿足各種並行場景使用需求。
  2. 對業務階段進行清晰的stage,sub_stage抽象,相對傳統圖引擎算子推導,缺少很好可讀的效果,我們做了stage抽象,配置可讀性更好,配置即可讀,排序全流程可視化管理易讀易接手,這也就是我們做編排配置及推導的主要目的。

    圖片

△Rankflow框架

  • 我們不僅要提升現有系統的並行計算能力,還優化資源的分配和使用方式,因為搜索系統的輸入流量、資源消耗、響應時間等系統狀態存在着週期性的波峯-波谷變動,而系統資源已經預先分配好。在波谷期,由於用户輸入流量的減少,系統資源不會得到充分利用;而波峯期,隨着用户輸入流量的增多,系統往往面臨着資源緊缺甚至不足的情況。於此同時,搜索系統的業務鏈路複雜,時常還會遭受某一中間節點的故障甚至是外部流量徒增等穩定性問題。
  • 架構方案:
  • 構建全局視角的彈性算力分配控制中心。
  • 通過對集羣各種維度指標的獲取、策略分析及週期性執行最適合當前機器負載狀態的策略組合參數,實現其核心彈性算力分配決策。
  • 業務應用:
  • 目前支持視頻搜索短小視頻擴觸發,高峯減載,系統異常處置等功能。

圖片

△智能彈性算力系統

  • 端到端排序架構升級:
  • 視頻核心排序模塊主要分為粗排,精排級聯兩階段,排序策略是依據這兩階段排序模式進行迭代升級,如粗排階段完成初步相關性計算用於初步篩選,減少精排階段系統計算量,精排階段少量優質結果進行復雜計算。以大模型排序為核心的排序框架打破了原來多階段級聯模式,端到端排序框架需要對計算和數據方案進行重新設計。
  1. 精簡精排前調權和挖掘隊列策略,優化索引召回和模型計算選送邏輯,粗排和精排階段統一為粗精排一體化排序階段。
  2. 由於缺少粗排模型提前初篩作用,端到端模型需要計算數量更多的候選結果集,計算候選集合從原來精排階段的幾十條增加到幾百條。
  3. 升級精排模塊,利用Rankflow框架,高併發處理候選結果集數量增加帶來的耗時問題。

圖片

△端到端排序架構

05 總結與展望

視頻搜索排序框架通過系統分層優化、Rankflow框架引入及彈性資源複用等架構演進,顯著提升了排序系統的性能與靈活性,提高研發效率,降低了長期運營成本。

  • 在大模型技術趨勢下,視頻搜索系統如何更好提供RAG搜索增強功能。
  • 如何使視頻與通搜端到端融合,達到搜索端到端理想態,都是我們後續探索研究的方向。

————END————

推薦閲讀

網頁結構建模在低質採集站上的識別應用

如何定量分析 Llama 3,大模型系統工程師視角的 Transformer 架構

微服務架構革新:百度Jarvis2.0與雲原生技術的力量

技術路線速通!用飛槳讓京劇人物照片動起來

無需業務改造,一套數據庫滿足 OLTP 和 OLAP,GaiaDB 發佈並行查詢能力

user avatar zhidechaomian_detxs7 頭像 u_16077267 頭像 u_15316473 頭像 sovitjs 頭像 jianweilai 頭像 yeshan333 頭像 huidadebianpao 頭像 fabarta 頭像 pannideniupai 頭像 debuginn 頭像 xuri 頭像 easynvr 頭像
點贊 19 用戶, 點贊了這篇動態!
點贊

Add a new 評論

Some HTML is okay.