演講嘉賓｜歐明棟，阿里云高級算法專家

編輯 ｜蔡芳芳、Kitty

策劃 ｜AICon 全球人工智能開發與應用大會

本文中，阿里云高級算法專家歐明棟分享了阿里云為什么選擇 RAG 作為解決方案，以及在實際應用中如何通過文檔結構化、大模型微調和 Agent 技術等手段，提升 RAG 的效果和性能。同時，他還介紹了 RAG 在電商、內容、企業知識庫和教育搜題等場景中的實際應用，為同行提供了寶貴的實踐參考。

以下內容源自歐明棟在 2024 AICon 全球人工智能開發與應用大會·上海站的演講（經 InfoQ 進行不改變原意的編輯整理）：

今天想跟大家分享阿里云在過去一年多的時間里，如何利用大模型優化 RAG 的實踐。

為什么選擇 RAG？

RAG 主要用在知識問答領域，前期我們考慮了三種主流的解決方案。

第一種方案是直接使用大模型回答問題。這種方法簡單直接，輸入一個問題，模型就會給出答案。然而，這種方法可能會遇到幻覺問題，因為模型的預訓練數據中可能不包含足夠的領域知識和實時信息，就會導致答案不準確。例如，我們在阿里云文檔上測試 GPT-4 時，發現準確率不到 30%。

第二種方案是對大模型進行微調。這種方法可以減少幻覺問題，因為模型會集成一些領域知識。但這種方法也有其挑戰，比如領域數據可能不足，或者預訓練效果不佳，需要進一步的領域知識調整，這會增加成本。此外，微調后的模型需要單獨部署，雖然有技術如 LoRA 可以減少成本，但總體上成本仍然較高。

第三種方案，也就是我們采用的 RAG 方法，它不改變大模型本身，而是通過檢索領域知識，然后結合問題和檢索到的知識，用大模型生成答案。這種方法的優點在于，它使用的是原始知識，因此幻覺問題較少。同時，由于它基于檢索，可以實時更新信息，提供更多的實時數據。此外，由于它不是直接生成答案，而是基于搜索結果，所以可以提供生成答案的依據，解決了可溯源的問題。在成本方面，我們發現大模型直答和 RAG 的成本相對較低，主要成本集中在模型推理上。

RAG 架構

在 RAG 架構中，我們的流程始于用戶上傳文檔集合。上傳后，我們首先對文檔進行解析，然后進行切片處理。切片的目的是為了與后續的向量模型或索引兼容。目前，向量模型在處理較短文本時效果較好，盡管它們也能處理長文本，但在語義搜索的相似度和區分度上可能不夠精確，因此需要通過檢索和切片來優化。由于大模型支持的上下文長度有限，我們需要將文檔切割成更小的切片，以便大模型能夠進行有效總結。這一過程是離線的，最終我們會建立一個基于語義切片的索引庫，通常采用向量和文本的混合索引方式。

當用戶在線提出問題時，我們會對查詢進行改寫。查詢改寫主要分為兩個方面：首先，在多輪對話中，我們需要考慮歷史信息來進行查詢改寫，以形成一個語義完整的查詢，然后進行搜索；其次，對于復雜的查詢，我們會進行改寫和拆解，以便更準確地搜索到相關信息。在改寫后的查詢基礎上，我們會找到一些相近的文檔切片，然后利用大語言模型來生成答案。這個過程確保了我們能夠為用戶提供準確和相關的回答。

RAG 的效果問題及歸因

雖然 RAG 架構能夠解決大部分簡單問題，但在處理復雜場景或文檔時，會遇到一些挑戰。

首先，幻覺問題依然存在。這可能是因為文檔在切片過程中出現不完整或解析錯誤，導致模型在生成答案時出現幻覺。此外，即使在 RAG 場景下，大模型本身也可能產生幻覺，這種幻覺與直接生成的幻覺不同，它是基于檢索結果之外的信息進行回答。

其次，拒答現象也較為常見。這主要是因為檢索結果不完整或未能檢索到相關內容，導致模型無法給出答案。

第三，回答不完整的問題。這可能是因為文檔切片本身不完整，或者召回過程中不完整。在處理復雜問題時，如果答案較長，比如步驟類問題，模型可能會遺漏關鍵信息。

第四，回答內容與問題不相關。這可能是大模型的一個普遍問題，模型傾向于給出較長的答案，而這些答案雖然不是錯誤的，但可能與問題不相關。

最后，響應速度問題。在服務客戶時，我們發現如果需要達到較好的效果，可能需要使用 72B 參數以上的模型，這會導致回答的反應速度變慢。

總結來說，為了使 RAG 架構達到較好的效果，我們需要關注四個關鍵點：

1. 文檔解析的準確性：文檔解析必須準確無誤。因為如果輸入數據有誤，那么輸出的結果肯定也會出錯。

2. 切片的語義完整性：文檔切片需要保持語義的完整性。這意味著切片后的內容應該能夠代表原文檔的意義，以便模型能夠理解并正確處理。

3. 信息召回的完整性：信息召回過程需要確保召回的信息是完整的。

4. 大模型的總結推理準確率：大模型在總結和推理時的準確率必須高。

RAG 架構 -?模型優化

在大模型應用的優化方面，我想分享我們所做的一些工作。首先，在文檔解析方面，我們進行了文檔層級結構的抽取，目的是將文檔結構化，這樣不僅可以提高切片的效率，還能幫助大模型更好地理解文檔內容。

其次，為了提高大模型回答的質量，我們對模型進行了微調。我們選擇的是一個相對較小的模型，這樣不僅能夠保證較快的處理速度，而且在效果上也能與更大參數量的模型相媲美。

最后，當檢索到的信息不完整，或者需要回答的問題比較復雜時，我們會采用 Agent 技術對問題進行拆解。通過這種方式，我們可以更有效地回答問題，確保即使在信息不完整或問題復雜的情況下，也能給出滿意的答案。

在討論系統優化時，我們提到的優化點都是系統模塊的一部分。目前，這個系統由多個獨立模塊組成，可以自由組合以滿足不同的需求。整個 RAG 系統包括以下幾個關鍵部分：

1. 數據層：數據層支持多種數據格式和數據源，這是系統的基礎。

2. 離線服務：在離線處理方面，我們包括了向量化文本切片和數據提取。這部分有多種可選的鏈路，有的效率較高，有的可能效果較好但速度較慢。

3. 在線引擎：搜索模塊是另一個重要部分，我們支持自研的大模型以及第三方開源和閉源的大型模型。

4. 搜索組件：Query 理解非常關鍵，如果能夠準確理解用戶的查詢，那么檢索到正確的文檔，回答的質量基本上就有 80% 的保證。我們在 Query 理解方面也采取了多種策略來處理不同的問題。

5. 組件編排：系統可以支持阿里云的 SDK，以及一些目前非常流行的開源 SDK，如 LlamaIndex 等。

?檔結構化

在處理文檔結構化的問題時，我們的初衷是為了解決文檔切片的問題。我們面臨的挑戰是，許多數據，如 PDF 文件，甚至是純文本輸入，很難直接通過規則分析出其語義層級。這會導致在進行語義切片時，切片內的語義不完整。

我們看下圖的兩個例子。第一個例子是，當用戶詢問如何修改云盤的 UUID 時，搜索回來的結果可能是修改云盤的 UUID 步驟如下，但接下來的步驟可能被切到了下一個切片。這樣，模型只看到了如下，而模型本身傾向于補充文本，因為它的預訓練就是做文本補充。因此，它可能會根據它自己的知識生成答案，這樣的回答通常都是錯誤的。第二個例子是，切片可能只包含了某個步驟的一部分，模型在回答時也只回答了這部分內容，而遺漏了剩余的步驟。

語義層級抽取模型

在語義層級抽取模型的開發中，我們的目標是利用大模型強大的語義理解能力來抽取文檔的語義層級。大模型已經在大量文檔上進行了訓練，因此具備了理解文檔標題、列項等不同層級的語義的能力。通過這種方式，我們希望能夠提取出文檔的層級結構。

這樣做的好處有兩個：首先，它可以使切片更加完整，避免了之前提到的切片導致的語義不完整的問題；其次，它還可以用于基于語義層級的內容摘要。許多用戶的問題具有全局性，他們可能不是詢問某個具體的知識點，而是詢問一個更廣泛的話題，如政策文件包含哪些內容。這類問題可能涉及幾千字的內容，通過傳統的切片方式很難完整地總結。

為了實現這一目標，我們首先收集了一些公開的數據集，這些數據集中包含了 PDF 文件的層級信息。我們收集的數據質量相對較高，并根據業務需求進行了一些數據增強。有了這些增強數據后，我們采用了兩階段的 SFT 加上 DPO 的方法來訓練模型。

模型訓練后準確率仍然不是非常高，無法完全準確地抽取整個語義層級，但我們在后續處理中采取了一些策略。例如，我們會通過遞歸的方式來處理特別長的文檔，因為模型訓練時不會處理特別長的上下文，長上下文的處理速度會比較慢。因此，我們需要對較長的文檔進行切分，然后再進行處理。

在進行數據增強時，我們主要采取了三種方式：

2. 噪聲混入：有時客戶的數據中，某些并非標題的文字被錯誤地標記為標題。為了處理這種情況，我們也會在數據中引入一些假的標題，以增加模型的魯棒性。

3. 純文本構造：對于完全由純文本組成的客戶數據，我們還需要構造一些純文本輸入，以便模型能夠學習如何處理沒有明確層級結構的文本。

在準備好數據后，我們采用標準的 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。這個評估鏈路主要基于檢索結果、問題和回答這三元組來評估效果。我們的評估標準包括三個方面：

1. 幻覺：分為編造（回答內容不在檢索結果中）和混淆（回答包含了相關但不能回答問題的內容）。

2. 完整性：回答是否包含了所有關鍵點。

3. 相關性：回答內容是否與問題相關。

目前，我們主要通過大模型自身進行評估。工作流程大致是：首先讓大模型進行一次評估，然后進行反思（reflection），接著自我完善（self-refine），并迭代這個過程。最終的效果顯示，僅使用大模型的準確率可以達到 95% 左右，這比單純人工的效果還要好。如果基于大模型的評估結果再由人工進行修正，效果會更好。如果以人工修正的結果為 100%，那么大模型的效果也能接近這個水平。

大模型微調

在大模型微調的過程中，我們遵循了一個比較標準的鏈路。以下是我們微調過程的詳細步驟：

1. 數據來源：我們首先收集了一些公開的數據集，同時，我們也根據文檔合成了一些新的問題，以生成自己的數據集。

2. 數據構造：我們特別關注拒答的數據。我們發現大模型傾向于強行回答一些問題，這往往會導致幻覺的產生。我們還擴展了數據集的領域多樣性，包括多人對話的場景。

3. 指令構造：在指令方面，我們主要關注控制幻覺的發生。同時，我們也關注引用溯源的問題。目前，大模型在引用溯源方面的表現并不完整，有時不會生成引用溯源。

4. 樣本篩選：我們關注副文本的審核風格生成，制定了一些規則，并使用模型評測來篩選樣本。

5. 模型訓練：我們使用 SFT 和 DPO 的經典方法來訓練模型。

我們最近在千問 1.5 上進行了一些實驗，得到了一些令人鼓舞的結果。我們使用了基于 Qwen1.5-14B 的模型，并對其進行了 SFT 和 DPO 的處理。從實驗結果來看，在 RAG 的應用場景中，經過微調的 14B 模型在回答問題方面的表現幾乎可以與 72B 的模型相媲美。此外，我們還觀察到，經過 SFT 和 DPO 處理的模型在幻覺率方面有顯著的降低。

RAG 場景中的復雜問題

模型總結的效果很大程度上取決于輸入數據的完整性。在我們的客戶場景中，很多問題都是相當復雜的，需要通過多步推理和多篇文檔的信息聚合才能得出答案。例如這個問題：西班牙獲得歐洲杯次數最多的球員是誰？直接搜索可能只能找到西班牙獲得了哪幾屆歐洲杯的信息，但要找到獲得次數最多的球員則需要更深入的分析和聚合多篇文檔中的數據。這種情況下，模型可能無法直接給出答案。另一個例子：黎曼的生肖是什么？搜索結果可能只包含關于黎曼的一些基本信息，如生日，但要確定他的生肖則需要額外的計算和推理。

Agentic RAG

目前，我們在模型探索方面還處于相對初級的階段。我們嘗試在搜索服務后接入了一個規劃 Agent，這個 Agent 的作用是先評估當前的搜索結果是否足夠回答問題。如果搜索結果足夠，Agent 會直接進行總結。如果結果不足，Agent 會再次執行搜索，然后再次嘗試總結。例如，要回答西班牙獲得歐洲杯次數最多的球員是誰的問題，Agent 會分兩步進行搜索：

1. 第一步，Agent 會搜索出西班牙獲得歐洲杯的年份。

2. 第二步，它會找到每個年份下歐洲杯獲獎的球員名單。

通過這兩步搜索，Agent 可以總結出獲得歐洲杯次數最多的球員，例如伊涅斯塔、哈維、卡西利亞斯等，他們都是獲得了兩次歐洲杯的球員。

對于黎曼的生肖是什么的問題，Agent 也會采取類似的兩步搜索策略：

1. 第一步，Agent 會搜索出黎曼的出生日期。

2. 第二步，它會搜索出黎曼出生年份對應的生肖。

最初我們嘗試直接基于 REAct 或者 Function Call 將問題輸入模型，但不提供任何搜索結果作為參考。這種方法導致模型傾向于將問題拆解得過于細致，從而增加了搜索輪數，有時候甚至會導致回答方向出現偏差。從效率角度來看，我們觀察到在測試集中，這種策略平均需要 1.7 次搜索。

為了改進這一點，我們嘗試了一個更簡單的方法：首先用原始問題執行一次搜索，然后再決定是否需要進一步搜索。通過添加這第一步的直接搜索，我們發現搜索次數從 1.7 次降低到了 1.2 次，這顯著提高了回答的效率。效果也有所提升，主要是因為減少了搜索輪次，從而降低了出現錯誤的概率。我們發現，當搜索輪次較多時，模型在推理過程中更容易出錯。

目前我們也面臨一些挑戰。首先，處理時延高，因為模型需要進行推理，如果需要多步搜索，還要進行多步總結，這會增加總體耗時。其次，成本高，因為涉及到多次調用大模型。最大的問題是推理本身的準確率不高。我們注意到，有時在進行幾步推理之后，模型可能甚至忘記了最初的問題。

RAG 應?實踐

我們應用的場景主要分為四類：電商場景、內容場景、企業知識庫和教育搜題。

1. 電商場景：在電商領域，我們主要處理售前和售后服務等相關問題。

2. 內容場景：在內容領域，我們主要進行搜索結果的總結。

3. 企業知識庫：在企業內部，我們處理的是問題的咨詢。

4. 教育搜題：在教育領域，我們進行題目搜索并總結答案。

RAG 客戶場景都是基于我們的 AI 搜索開發平臺構建的，該平臺包括內容解析、內容切分、向量表示等模塊，可以單獨或組合使用。以營養咨詢為例，我們的處理流程如下：如果客戶上傳了一個 PDF 文件，我們會調用 PDF 解析 API，并使用結構化模型抽取 PDF 的語義層級結構，將其轉換成 Markdown 文檔。然后，我們會對文檔進行切片。切片后，我們會為文檔生成 embedding，包括文本的和混合索引。完成以上步驟后，我們就已經構建好了離線檢索的結構。

在線服務方面，當用戶提出一個問題，比如如何搭配食物才能滿足高溫作業的需求，我們的系統會這樣處理：系統會先檢索到一些相關的切片。然后，系統會做一個初步的總結。模型會進一步推理，檢查結果中是否缺少信息。如果分析結果顯示缺少某些具體信息，比如具體的蔬菜水果名單，模型會產生一個新的問題進行搜索。收到相關數據后，模型會再次進行總結。如果 planner 認為問題已經可以完整回答，最后會生成一個完整的回答。

演講嘉賓介紹

歐明棟，阿里云高級算法專家。多年搜索推薦算法實踐經驗，曾負責閑魚推薦、阿里云智能搜索推薦算法；目前負責 AI 搜索 RAG 相關算法研發，產品上線已一年多，具體算法方向包括 RAG 場景下大模型優化、Agent 搭建及文檔理解等；發表過多篇人工智能相關論文，入選 AI2000 最具影響力學者提名。

Flutter 被分叉！團隊縮水至 50 人，bug 堆積如山，前谷歌員工出手找出路

大模型應用開發，AI 廠商開啟新一輪群雄逐鹿？

開源的定義要變了！開源AI標準成照妖鏡：Meta、谷歌家大模型只是在假裝開源？

放棄 React，微軟 Edge 團隊改用 Web 組件減少對 Java 的依賴

活動推薦返回搜狐，查看更多

責任編輯：