阿里雲 AI 搜索 RAG 大模型優化實踐
演講嘉賓｜歐明棟，阿里雲高級算法專家
編輯 ｜蔡芳芳、Kitty
策劃 ｜AICon 全球人工智能開發與應用大會
RAG（檢索增強生成）是大模型應用的重要方向，它大幅緩解了大模型幻覺、信息更新不及時、專業域或私有域知識匱乏等問題，顯著提升了大模型在知識庫問答、網頁搜索、客服等領域的可信賴度。但我們發現，在實際落地中，RAG 仍存在不少問題，如：文檔解析結構丟失、大模型生成幻覺、複雜問題無法解答等等。
本文中，阿里雲高級算法專家歐明棟分享了阿里云爲什麼選擇 RAG 作爲解決方案，以及在實際應用中如何通過文檔結構化、大模型微調和 Agent 技術等手段，提升 RAG 的效果和性能。同時，他還介紹了 RAG 在電商、內容、企業知識庫和教育搜題等場景中的實際應用，爲同行提供了寶貴的實踐參考。
12 月 13-14 日，作爲全年系列大會的收官之站，2024 AICon 全球人工智能開發與應用大會將在北京舉辦！本次大會將繼續聚焦人工智能的前沿技術、實踐應用和未來趨勢，比如大模型訓練與推理、AI agent、RAG、多模態大模型等等...... 精彩議題正陸續上線，歡迎訪問鏈接查看詳情：https://aicon.infoq.cn/202412/beijing/
以下內容源自歐明棟在 2024 AICon 全球人工智能開發與應用大會·上海站 的演講（經 InfoQ 進行不改變原意的編輯整理）：
今天想跟大家分享阿里雲在過去一年多的時間裡，如何利用大模型優化 RAG 的實踐。
爲什麼選擇 RAG？
RAG 主要用在知識問答領域，前期我們考慮了三種主流的解決方案。
第一種方案是直接使用大模型回答問題。這種方法簡單直接，輸入一個問題，模型就會給出答案。然而，這種方法可能會遇到幻覺問題，因爲模型的預訓練數據中可能不包含足夠的領域知識和實時信息，就會導致答案不準確。例如，我們在阿里雲文檔上測試 GPT-4 時，發現準確率不到 30%。
第二種方案是對大模型進行微調。這種方法可以減少幻覺問題，因爲模型會集成一些領域知識。但這種方法也有其挑戰，比如領域數據可能不足，或者預訓練效果不佳，需要進一步的領域知識調整，這會增加成本。此外，微調後的模型需要單獨部署，雖然有技術如 LoRA 可以減少成本，但總體上成本仍然較高。
第三種方案，也就是我們採用的 RAG 方法，它不改變大模型本身，而是通過檢索領域知識，然後結合問題和檢索到的知識，用大模型生成答案。這種方法的優點在於，它使用的是原始知識，因此幻覺問題較少。同時，由於它基於檢索，可以實時更新信息，提供更多的實時數據。此外，由於它不是直接生成答案，而是基於搜索結果，所以可以提供生成答案的依據，解決了可溯源的問題。在成本方面，我們發現大模型直答和 RAG 的成本相對較低，主要成本集中在模型推理上。
RAG 架構
在 RAG 架構中，我們的流程始於用戶上傳文檔集合。上傳後，我們首先對文檔進行解析，然後進行切片處理。切片的目的是爲了與後續的向量模型或索引兼容。目前，向量模型在處理較短文本時效果較好，儘管它們也能處理長文本，但在語義搜索的相似度和區分度上可能不夠精確，因此需要通過檢索和切片來優化。由於大模型支持的上下文長度有限，我們需要將文檔切割成更小的切片，以便大模型能夠進行有效總結。這一過程是離線的，最終我們會建立一個基於語義切片的索引庫，通常採用向量和文本的混合索引方式。
當用戶在線提出問題時，我們會對查詢進行改寫。查詢改寫主要分爲兩個方面：首先，在多輪對話中，我們需要考慮歷史信息來進行查詢改寫，以形成一個語義完整的查詢，然後進行搜索；其次，對於複雜的查詢，我們會進行改寫和拆解，以便更準確地搜索到相關信息。在改寫後的查詢基礎上，我們會找到一些相近的文檔切片，然後利用大語言模型來生成答案。這個過程確保了我們能夠爲用戶提供準確和相關的回答。
RAG 的效果問題及歸因
雖然 RAG 架構能夠解決大部分簡單問題，但在處理複雜場景或文檔時，會遇到一些挑戰。
首先，幻覺問題依然存在。這可能是因爲文檔在切片過程中出現不完整或解析錯誤，導致模型在生成答案時出現幻覺。此外，即使在 RAG 場景下，大模型本身也可能產生幻覺，這種幻覺與直接生成的幻覺不同，它是基於檢索結果之外的信息進行回答。
其次，拒答現象也較爲常見。這主要是因爲檢索結果不完整或未能檢索到相關內容，導致模型無法給出答案。
第三，回答不完整的問題。這可能是因爲文檔切片本身不完整，或者召回過程中不完整。在處理複雜問題時，如果答案較長，比如步驟類問題，模型可能會遺漏關鍵信息。
第四，回答內容與問題不相關。這可能是大模型的一個普遍問題，模型傾向於給出較長的答案，而這些答案雖然不是錯誤的，但可能與問題不相關。
最後，響應速度問題。在服務客戶時，我們發現如果需要達到較好的效果，可能需要使用 72B 參數以上的模型，這會導致回答的反應速度變慢。
總結來說，爲了使 RAG 架構達到較好的效果，我們需要關注四個關鍵點：
文檔解析的準確性：文檔解析必須準確無誤。因爲如果輸入數據有誤，那麼輸出的結果肯定也會出錯。
切片的語義完整性：文檔切片需要保持語義的完整性。這意味着切片後的內容應該能夠代表原文檔的意義，以便模型能夠理解並正確處理。
信息召回的完整性：信息召回過程需要確保召回的信息是完整的。
大模型的總結推理準確率：大模型在總結和推理時的準確率必須高。
RAG 架構 -⼤模型優化
在大模型應用的優化方面，我想分享我們所做的一些工作。首先，在文檔解析方面，我們進行了文檔層級結構的抽取，目的是將文檔結構化，這樣不僅可以提高切片的效率，還能幫助大模型更好地理解文檔內容。
其次，爲了提高大模型回答的質量，我們對模型進行了微調。我們選擇的是一個相對較小的模型，這樣不僅能夠保證較快的處理速度，而且在效果上也能與更大參數量的模型相媲美。
最後，當檢索到的信息不完整，或者需要回答的問題比較複雜時，我們會採用 Agent 技術對問題進行拆解。通過這種方式，我們可以更有效地回答問題，確保即使在信息不完整或問題複雜的情況下，也能給出滿意的答案。
在討論系統優化時，我們提到的優化點都是系統模塊的一部分。目前，這個系統由多個獨立模塊組成，可以自由組合以滿足不同的需求。整個 RAG 系統包括以下幾個關鍵部分：
數據層：數據層支持多種數據格式和數據源，這是系統的基礎。
離線服務：在離線處理方面，我們包括了向量化文本切片和數據提取。這部分有多種可選的鏈路，有的效率較高，有的可能效果較好但速度較慢。
在線引擎：搜索模塊是另一個重要部分，我們支持自研的大模型以及第三方開源和閉源的大型模型。
搜索組件：Query 理解非常關鍵，如果能夠準確理解用戶的查詢，那麼檢索到正確的文檔，回答的質量基本上就有 80% 的保證。我們在 Query 理解方面也採取了多種策略來處理不同的問題。
組件編排：系統可以支持阿里雲的 SDK，以及一些目前非常流行的開源 SDK，如 LlamaIndex 等。
⽂檔結構化
在處理文檔結構化的問題時，我們的初衷是爲了解決文檔切片的問題。我們面臨的挑戰是，許多數據，如 PDF 文件，甚至是純文本輸入，很難直接通過規則分析出其語義層級。這會導致在進行語義切片時，切片內的語義不完整。
我們看下圖的兩個例子。第一個例子是，當用戶詢問如何修改雲盤的 UUID 時，搜索回來的結果可能是“修改雲盤的 UUID 步驟如下”，但接下來的步驟可能被切到了下一個切片。這樣，模型只看到了“如下”，而模型本身傾向於補充文本，因爲它的預訓練就是做文本補充。因此，它可能會根據它自己的知識生成答案，這樣的回答通常都是錯誤的。第二個例子是，切片可能只包含了某個步驟的一部分，模型在回答時也只回答了這部分內容，而遺漏了剩餘的步驟。
語義層級抽取模型
在語義層級抽取模型的開發中，我們的目標是利用大模型強大的語義理解能力來抽取文檔的語義層級。大模型已經在大量文檔上進行了訓練，因此具備了理解文檔標題、列項等不同層級的語義的能力。通過這種方式，我們希望能夠提取出文檔的層級結構。
這樣做的好處有兩個：首先，它可以使切片更加完整，避免了之前提到的切片導致的語義不完整的問題；其次，它還可以用於基於語義層級的內容摘要。許多用戶的問題具有全局性，他們可能不是詢問某個具體的知識點，而是詢問一個更廣泛的話題，如政策文件包含哪些內容。這類問題可能涉及幾千字的內容，通過傳統的切片方式很難完整地總結。
爲了實現這一目標，我們首先收集了一些公開的數據集，這些數據集中包含了 PDF 文件的層級信息。我們收集的數據質量相對較高，並根據業務需求進行了一些數據增強。有了這些增強數據後，我們採用了兩階段的 SFT 加上 DPO 的方法來訓練模型。
模型訓練後準確率仍然不是非常高，無法完全準確地抽取整個語義層級，但我們在後續處理中採取了一些策略。例如，我們會通過遞歸的方式來處理特別長的文檔，因爲模型訓練時不會處理特別長的上下文，長上下文的處理速度會比較慢。因此，我們需要對較長的文檔進行切分，然後再進行處理。
在進行數據增強時，我們主要採取了三種方式：
層級合併：首先，我們將客戶的 PDF 或 Word 數據轉換成 Markdown 格式。在轉換過程中，我們會根據一些規則，比如字體和字號，來識別並創建粗體標題。然而，我們發現許多客戶的數據中，不同層級的標題可能使用了相同的字號，這就需要我們在數據中進行層級的合併和構造，以模擬客戶的實際數據。
噪聲混入：有時客戶的數據中，某些並非標題的文字被錯誤地標記爲標題。爲了處理這種情況，我們也會在數據中引入一些假的標題，以增加模型的魯棒性。
純文本構造：對於完全由純文本組成的客戶數據，我們還需要構造一些純文本輸入，以便模型能夠學習如何處理沒有明確層級結構的文本。
在準備好數據後，我們採用標準的 SFT 和 DPO 方法進行模型訓練。輸入數據是我們初步解析出的 Markdown 格式，而輸出則是標題的層級結構。在 DPO 方面，我們使用的是 Step DPO，即只關注第一步解析的結果。這是因爲如果第一步解析出現錯誤，那麼後續的解析往往也會不準確，所以我們專注於第一步解析錯誤的部分。
語義層級切⽚
在語義層級切片的應用方面，我們採取了一種結構化的方法來處理文檔。例如，如果一個文檔包含段落 1、2、3、4，我們會將其切成四個獨立的切片，每個切片都會附帶其標題的路徑。這樣，每個段落不僅可以獨立處理，還可以生成摘要，從而有效回答一些較長的問題。此外，整個文檔的結構允許我們回溯並生成摘要，以提供更全面的答案。
隨着模型能處理的上下文長度越來越長，我們面臨一個問題：是否還需要進行切片？理論上可以直接將整個文檔輸入到大模型中，讓它直接生成答案，而無需進行切片。但經過我們的測試，長文本處理仍存在一些問題。首先，處理長文本會增加計算複雜度，導致耗時和成本增加。這是因爲輸入上下文的長度增加，計算複雜度呈平方增長，從而顯著增加了處理時間。其次，更重要的是信息丟失的問題。我們測試了 GPT-4 128K 版本，發現當輸入長度達到 30 多千字時，模型開始遺漏信息，導致回答不完整。文檔中的噪聲數據也使得模型難以精確提取信息。我們目前的策略是適當增加切片的長度，而不是完全放棄切片。我們仍在探索更好的結合長文本處理和切片的方法，以提高效率和準確性。
⼤模型微調 &Agent 探索
我們目前的工作重點是大模型的微調以及 Agent 的探索。我們的主要出發點是提高回答的質量。首先，我們關注幻覺問題。在 RAG 環境下，即使是 GPT-4 這樣的大模型，也存在大約 7% 的幻覺率。對於更小的模型，如 14B 或 7B，幻覺率通常在 20% 以上。幻覺的一個例子是，當用戶詢問如何清除過期的二級分區時，模型可能會混淆相關但不正確的回答。另一個例子是回答不完整，比如在解釋 RDS 創建數據庫的方法時，模型可能只回答了部分版本，遺漏了其他版本。這些問題可以通過意圖澄清來改善，但即便如此，模型在細節上仍可能遺漏信息。
爲了解決這些問題，我們主要通過微調模型來提高回答質量。我們認爲幻覺的來源主要是模型的邏輯推理模式與人的推理模式沒有完全對齊，而不是知識缺乏。
微調過程中最大的挑戰是如何評估和生成數據。爲此，我們建立了一個 RAG 回答的評估鏈路，類似於後來發佈的 RAGAS。這個評估鏈路主要基於檢索結果、問題和回答這三元組來評估效果。我們的評估標準包括三個方面：
幻覺：分爲編造（回答內容不在檢索結果中）和混淆（回答包含了相關但不能回答問題的內容）。
完整性：回答是否包含了所有關鍵點。
相關性：回答內容是否與問題相關。
目前，我們主要通過大模型自身進行評估。工作流程大致是：首先讓大模型進行一次評估，然後進行反思（reflection），接着自我完善（self-refine），並迭代這個過程。最終的效果顯示，僅使用大模型的準確率可以達到 95% 左右，這比單純人工的效果還要好。如果基於大模型的評估結果再由人工進行修正，效果會更好。如果以人工修正的結果爲 100%，那麼大模型的效果也能接近這個水平。
大模型微調
在大模型微調的過程中，我們遵循了一個比較標準的鏈路。以下是我們微調過程的詳細步驟：
數據來源：我們首先收集了一些公開的數據集，同時，我們也根據文檔合成了一些新的問題，以生成自己的數據集。
數據構造：我們特別關注拒答的數據。我們發現大模型傾向於強行回答一些問題，這往往會導致幻覺的產生。我們還擴展了數據集的領域多樣性，包括多人對話的場景。
指令構造：在指令方面，我們主要關注控制幻覺的發生。同時，我們也關注引用溯源的問題。目前，大模型在引用溯源方面的表現並不完整，有時不會生成引用溯源。
樣本篩選：我們關注副文本的審覈風格生成，制定了一些規則，並使用模型評測來篩選樣本。
模型訓練：我們使用 SFT 和 DPO 的經典方法來訓練模型。
我們最近在千問 1.5 上進行了一些實驗，得到了一些令人鼓舞的結果。我們使用了基於 Qwen1.5-14B 的模型，並對其進行了 SFT 和 DPO 的處理。從實驗結果來看，在 RAG 的應用場景中，經過微調的 14B 模型在回答問題方面的表現幾乎可以與 72B 的模型相媲美。此外，我們還觀察到，經過 SFT 和 DPO 處理的模型在幻覺率方面有顯著的降低。
RAG 場景中的複雜問題
模型總結的效果很大程度上取決於輸入數據的完整性。在我們的客戶場景中，很多問題都是相當複雜的，需要通過多步推理和多篇文檔的信息聚合才能得出答案。例如這個問題：“西班牙獲得歐洲盃次數最多的球員是誰？”直接搜索可能只能找到“西班牙獲得了哪幾屆歐洲盃”的信息，但要找到獲得次數最多的球員則需要更深入的分析和聚合多篇文檔中的數據。這種情況下，模型可能無法直接給出答案。另一個例子：“黎曼的生肖是什麼？”搜索結果可能只包含關於黎曼的一些基本信息，如生日，但要確定他的生肖則需要額外的計算和推理。
Agentic RAG
目前，我們在模型探索方面還處於相對初級的階段。我們嘗試在搜索服務後接入了一個規劃 Agent，這個 Agent 的作用是先評估當前的搜索結果是否足夠回答問題。如果搜索結果足夠，Agent 會直接進行總結。如果結果不足，Agent 會再次執行搜索，然後再次嘗試總結。例如，要回答“西班牙獲得歐洲盃次數最多的球員是誰”的問題，Agent 會分兩步進行搜索：
第一步，Agent 會搜索出西班牙獲得歐洲盃的年份。
第二步，它會找到每個年份下歐洲盃獲獎的球員名單。
通過這兩步搜索，Agent 可以總結出獲得歐洲盃次數最多的球員，例如伊涅斯塔、哈維、卡西利亞斯等，他們都是獲得了兩次歐洲盃的球員。
對於“黎曼的生肖是什麼”的問題，Agent 也會採取類似的兩步搜索策略：
第一步，Agent 會搜索出黎曼的出生日期。
第二步，它會搜索出黎曼出生年份對應的生肖。
最初我們嘗試直接基於 REAct 或者 Function Call 將問題輸入模型，但不提供任何搜索結果作爲參考。這種方法導致模型傾向於將問題拆解得過於細緻，從而增加了搜索輪數，有時候甚至會導致回答方向出現偏差。從效率角度來看，我們觀察到在測試集中，這種策略平均需要 1.7 次搜索。
爲了改進這一點，我們嘗試了一個更簡單的方法：首先用原始問題執行一次搜索，然後再決定是否需要進一步搜索。通過添加這第一步的直接搜索，我們發現搜索次數從 1.7 次降低到了 1.2 次，這顯著提高了回答的效率。效果也有所提升，主要是因爲減少了搜索輪次，從而降低了出現錯誤的概率。我們發現，當搜索輪次較多時，模型在推理過程中更容易出錯。
目前我們也面臨一些挑戰。首先，處理時延高，因爲模型需要進行推理，如果需要多步搜索，還要進行多步總結，這會增加總體耗時。其次，成本高，因爲涉及到多次調用大模型。最大的問題是推理本身的準確率不高。我們注意到，有時在進行幾步推理之後，模型可能甚至忘記了最初的問題。
RAG 應⽤實踐
我們應用的場景主要分爲四類：電商場景、內容場景、企業知識庫和教育搜題。
電商場景：在電商領域，我們主要處理售前和售後服務等相關問題。
內容場景：在內容領域，我們主要進行搜索結果的總結。
企業知識庫：在企業內部，我們處理的是問題的諮詢。
教育搜題：在教育領域，我們進行題目搜索並總結答案。
RAG 客戶場景都是基於我們的 AI 搜索開發平臺構建的，該平臺包括內容解析、內容切分、向量表示等模塊，可以單獨或組合使用。以營養諮詢爲例，我們的處理流程如下：如果客戶上傳了一個 PDF 文件，我們會調用 PDF 解析 API，並使用結構化模型抽取 PDF 的語義層級結構，將其轉換成 Markdown 文檔。然後，我們會對文檔進行切片。切片後，我們會爲文檔生成 embedding，包括文本的和混合索引。完成以上步驟後，我們就已經構建好了離線檢索的結構。
在線服務方面，當用戶提出一個問題，比如“如何搭配食物才能滿足高溫作業的需求”，我們的系統會這樣處理：系統會先檢索到一些相關的切片。然後，系統會做一個初步的總結。模型會進一步推理，檢查結果中是否缺少信息。如果分析結果顯示缺少某些具體信息，比如具體的蔬菜水果名單，模型會產生一個新的問題進行搜索。收到相關數據後，模型會再次進行總結。如果 planner 認爲問題已經可以完整回答，最後會生成一個完整的回答。
演講嘉賓介紹
歐明棟，阿里雲高級算法專家。多年搜索推薦算法實踐經驗，曾負責閒魚推薦、阿里雲智能搜索推薦算法；目前負責 AI 搜索 RAG 相關算法研發，產品上線已一年多，具體算法方向包括 RAG 場景下大模型優化、Agent 搭建及文檔理解等；發表過多篇人工智能相關論文，入選 AI2000 最具影響力學者提名。
內容推薦
2024年8月18-19日，AICon 全球人工智能開發與應用大會·上海站成功舉辦，匯聚超過60位大模型行業先鋒，全方位剖析大模型訓練與推理機制、多模態融合、智能體Agent前沿進展、檢索增強（RAG）生成策略、端側模型優化與應用等熱點內容。經過嘉賓授權，「AI前線」爲你獨家整理了一份演講PPT合集，不容錯過。關注「AI前線」，回覆關鍵詞「PPT」免費獲取。
會議推薦
2024 年收官之作：12 月 13 日 -14 日，AICon 人工智能與大模型大會將在北京舉辦。從 RAG、Agent、多模態模型、AI Native 開發、具身智能，到 AI 智駕、性能優化與資源統籌等大熱的 AI 大模型話題，60+ 資深專家共聚一堂，深度剖析相關落地實踐案例，共話前沿技術趨勢。大會火熱報名中，詳情可聯繫票務經理 13269078023 諮詢。
今日薦文
你也「在看」嗎？