導讀

大型語言模型（LLMs）展示了非常強大能力，但在實際應用中仍舊有一些問題需要解決，比如幻覺現象、在垂類細分場景下的知識更新較慢，以及在回答中缺乏透明度（模型黑盒問題）等。檢索增強生成（RAG）是在使用LLM回答問題之前，從外部信息系統中檢索最新，最相關的信息，再借助LLM的生成能力，生成準確的結果。在多方論文和文獻中，RAG已被證明其有效性。

百度作為全球最大的中文搜索引擎，收錄了超過千億的中文網頁數據庫，為用户提供準確、高效、便捷的搜索服務。百度搜索系統經歷了20年的搜索產品演進，系統的目標是高效的為人們解決信息檢索問題，經過數據抓取、收錄、檢索，排序和展現，為用户提供準確、易用的搜索服務。但是對於大模型來説，人類易讀的搜索結果內容卻不便於模型對內容抽取和理解。

在RAG場景下，提出了一個既要又要的問題：一方面希望能夠利用百度檢索排序的優質策略，保證數據的高相關、高時效和多樣性，為大模型提供完整的全文結構化內容；另一方面又希望用更低的檢索成本、更高的時延要求給大模型的內容精細化組織預留足夠的空間。在此背景下，我們啓動了AIAPI項目，為大模型提供更加AI原生的檢索能力。

01 RAG簡介

1.1 什麼是RAG

RAG（Retrieval-Augmented Generation）檢索增強生成。檢索是方法，生成是目的，通過高質量的檢索系統，解決LLM生成過程中的一些問題。從當前RAG模式上，LLMs時代RAG的發展基本三種範式：簡單型RAG(Naive RAG)、高級型RAG(Advanced RAG)和組件化RAG(Modular RAG)[1]。

簡單型RAG：遵循傳統的過程，包括索引、檢索和生成，通常也稱之為『檢索-讀取』框架 。 Advanced RAG：專注於提高檢索質量，高質量的檢索結果為LLM生成的提供了非常穩定，正確的數據源。

Modular RAG：採用了多種策略來改進其組件，例如添加用於相似性搜索模塊(需要有一定的泛化能力)以及通過微調來改進檢索器。Modular RAG 方法正在變得普遍，儘管具有獨特性，Modular RAG 仍建立在 Advanced RAG 和 Naive RAG 的基本原則之上，體現了 RAG 進步和完善。

1.2 百度搜索：RAG中R?

在檢索增強生成的背景下，檢索質量的優劣在很大程度上影響了生成模型的最終生成結果的優劣。百度在提升檢索質量等方面做了很多卓有成效的工作。

但是RAG不是R and G的簡單結合。百度搜索經過多年的產品迭代和技術演進，搜索產品策略邏輯、中間態的數據結構和特徵表示非常複雜。從功能上看，百度搜索的在線拓撲架構、排序召回策略設計，特徵建設、檢索結果的摘要/標題計算、飄紅策略等都是圍繞最大限度的提升用户體驗和檢索效率這個目標而構建，如圖1所示；從數據資源維度看，百度除了擁有千億級別的互聯網數據外，還有有很多非常優質的自建資源，比如阿拉丁資源，但其中大部分是基於業務需求定製化的數據。這些數據內容雖然優質，但是對於大模型來説，明確其數據結構和意義是一件成本非常高的事情。

△圖1

直接複用搜索產出結果，在模型生成前需要對數據進行清洗，篩選和結構化整理。這無疑對在線生成系統增加了複雜性。那麼再為LLM的需求搭建一套類似系統呢？答案當然是否定的，其原因不僅僅是巨大資源成本開銷無法滿足，更多的挑戰源於兩套系統下的開發，效果打平和運維成本的翻倍。

我們要尋找一種架構解決方案，能夠同時高效支持搜索業務場景和大模型生成場景。既能複用百度搜索技術，保證高質量的檢索效果；又能做到對用户/大模型請求的系統QoS分級表達，在大模型場景下提供更低成本、時延的套餐方案來滿足差異化QueryPlan生成。

02 AIAPI設計概述

2.1 AIAPI的設計要求

AIAIP的設計要求是為了提供更好的檢索效果用於模型生成，同時又兼顧資源，速度，效率等需求。要求從系統層面到數據效果層面均有比較大的提升。為了更好的拓展接口和能力，Aiapi設計了一整套標準協議，保證了接口的高可解釋性、可擴展性，增強大模型對檢索內容吸收理解能力；同時提供基於QueryPlan的多級Qos系統控制，在保障效果的同時追求成本控制的極限；

數據上：

• 優質：優質性包括了數據來源是權威的、可信的、優質的、實時的。在大模型場景下權威優質庫帶來的體驗提升可能遠大於全網庫。從號和站的角度，去做先驗的判斷，也一定程度上可以提升權威性和內容的可信性；同時搜索產品積累的大量豐富的用户後驗的特徵信號，可以更好的反饋生成系統，提升大模型生成質量。
• 完整：隻言片語或者跟檢索詞高相關的飄紅信息對於人來説是有幫助的。能夠幫用户快速判斷這條結果的價值。而對於LLM來説，在token數量有限的場景下，儘可能的給模型完整的文本內容或者檢索命中的上下文關聯信息比給經過展現策略優化的摘要好得多。不完整的摘要反而會誘導模產生幻覺。
• 結構化表達：高效簡潔可解釋的結構化接口對於大模型來説是非常重要的。有助於大模型的內容理解。百度搜索在產品化演進過程中，阿拉丁資源是非常重要的一個組成部分，但是阿拉丁資源數據結構定製化高，除了阿拉丁之外，視頻，圖片等資源也不是統一的結構化數據來表徵。因此需要設計一套統一的結構化且有明確語義的接口，將檢索結果的內容 改為對 LLM 更友好的結構，數據層級更加扁平，其中key 的語義更加明確。

系統上：

• 低時延：大模型檢索增強的首token時延，會對用户的體驗帶來較大的影響。應該儘量壓縮檢索系統的整體時延。傳統檢索系統中的一些步驟（例如混排，摘要飄紅計算，出圖策略等）對於大語言模型不是必須的。同時在面向用户的檢索產品中，由於展示位置有限，在排序中的精排階段消耗了比較大的時間，但是對大模型而言，第一位和第二位的資源排序對其來説可能不是那麼重要。因此基於搜索產品效果的策略集合在檢索增強場景下存在策略裁剪的空間。
• 成本控制：對於收錄全網內容的檢索引擎來説，在大模型生成場景下，可控的成本一定是生成模型對系統的要求。否則資源會成為模型生成效果的一大制約條件。特別是在當前RAG設計場景下，僅僅一次生成往往不能滿足需求，在生成時會有多輪次生成過程:迭代檢索，在文本生成過程中涉及多次檢索迭代，以實現動態信息集成，如圖2所示。這種情況下檢索成本是成倍數放大的。因此檢索成本成為了系統設計中非常重要的一個指標。

△圖2

2.2 AIAPI的系統分層

百度當前的搜索產品細分為基礎檢索、生成式檢索以及多輪對話檢索三大類別，此外還囊括了文心一言這一大型語言模型應用。具體產品陣列展示如圖3所示：

△圖3

面對既要提升效果又要優化系統資源利用率的雙重挑戰，如何在百度既有的技術框架基礎上，以最小的工程代價開創一條全新的檢索路徑，對當前搜索架構分層提出了要求。

第一步，召回和排序層複用。在召回排序層，儘可能複用了當前排序和召回的架構，主要原因是對成本和效果的雙重考慮。對於在AIAPI場景下的差異化需求，基於流量、接口控制參數，提供了若干套套餐組合。使得業務可以根據自己的業務場景定製最合適的套餐組合，提升AIAPI的靈活性。

第二步，在數據層進行能力拓展。數據層的主要功能是對不同的流量來源做不同路由控制和數據加工（統一檢索增強場景下的數據表達方式）。在數據層使用圖引擎能夠高效實現對不同流量的隔離和定製化數據處理。同時增加網頁內容獲取能力，添加對結果類型（主搜、視頻、不同阿拉丁）的篩選和數據組織能力，便於業務側做 Query Planning；出於成本和速度方面考慮，數據層還設計了不同的緩存方案。

第三步，將上層的展現層進行了拆分，即檢索流量和AIAPI的生成流量在展現層是不同的。主要原因是搜索產品的前端數據渲染和數據的處理在LLM生成場景下是無法複用的，同時在AIAPI場景下基於用户的鑑權，流控，特徵管理等功能是需要同步建設的。針對速度、效果、成本不同傾向的需求，提供分級的 API 能力，便於用户選擇；

△圖4

03 AIAPI場景下的架構升級

3.1 雙通道

△圖5

在一套檢索框架同時支持傳統搜索業務（P請求）和檢索增強（R請求），從架構視角看，兩類請求是兩個不同的數據通道，但是兩個通道間還在一些階段存在交集。拓撲關係示意圖如圖5所示。基於上述要求，我們將數據模式抽象為三種情況況：

• 僅有P請求：常規的檢索請求，同時可以低成本預充R請求中P流量庫結果cache；
• 僅有R請求：Rag的相關請求，優先複用P請求下的召回結果，如果沒有可以複用的P請求召回結果，會觸發一次新的檢索，同時在排序層根據業務需求選用排序策略套餐進行排序；
• P+R混合請求：常規檢索中在query分析階段用户主要意圖，比如問答類、建議類需求下，會生成先驗特徵信號，在混合請求場景下，100%複用召回和排序的計算過程。

假設：產品請求的召回結果集是針對該次請求最完整的結果集合，同時召回效果也會隨着業務發展持續提升。那麼產品請求的召回結果是完全可以滿足檢索增強請求的召回需求。而在資源層面，我們希望達到1(產品請求) + 1(增強檢索請求) < 2次檢索召回成本開銷。這樣就達成了效果最優的同時資源開銷最小的目標。

該目標達成緩存系統也發揮了非常重要作用。一套靈活的cache方案可以極大提升整體系統的吞吐，減少重複計算。同時cache系統對檢索系統的穩定性也起到了非常重要的作用。

3.2 完整內容獲取方案

關鍵設計點：

• 展現策略解耦：產品搜索結果的摘要等內容信息獲取在排序層，實現基於 Query 做的複雜段落選取、飄紅等展現策略。而檢索增強結果不依賴展現策略，可以與展現策略拆分；
• 內容加工效率：為了滿足不同業務的內容定製化能力和提升內容獲取效率，該服務在存儲訪問，數據加工等階段使用動態併發處理模式，如圖6所示，保證在返回結果數過多場景下的時延和效率。

△圖6

• cache存儲優化：檢索增強場景下數據Cache在數據層和排序層之間，為了減少了cache的存儲開銷，需要將內容獲取上移到Cache層之上，最終R-Cache的存儲成本降低70%左右。

04 評估

基於百度文心4.0大模型的gsb評估結論：評估結果表明**AIAPI 優質檢索結果佔比提升顯著。**速度方面AIAPI相對產品檢索接口速度相對提升34%。

效果上測評：

△圖7

圖7中左側使用百度搜索產品原生數據，回答內容過於寬泛，右側使用AIAPI接口，回覆準確且豐富。提升了回答的效果。

05 展望

儘管AIAPI的架構設計能夠快速將業務效果提升同步到生成式檢索效果上，在計算複用、資源優化方向上持續不斷優化和提升資源利用效率。但作為RAG中重要的檢索環節仍存在許多挑戰，需要進行深入研究。比如如何降低正排，摘要的存儲成本、能夠在每次搜索中方便表徵檢索query與命中文檔中相關章節的關係，解決正排存儲信息中的冗餘存儲問題等等。因此可以預見的是隨着LLMs的不斷髮展，AIAPI的檢索架構也需要不斷進行優化和升級。

———— END ———— 推薦閲讀

學校新來了一位AI作文老師：能看、會評、還教改寫

搞定十萬卡集羣！貧窮限制了我的想象力…

AI Agent重塑微服務治理

百度智能雲千帆大模型平台引領企業創新增長

輕鬆搞定平穩運行，數據庫平台 DBStack 幫助 DBA 運維不同基礎設施上的各類數據庫