#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？原創精華

發布于 2024-10-16 10:45

瀏覽

0收藏

??【本文正在參與 AI.x社區AIGC創新先鋒者征文大賽】??

??http://m.ekrvqnd.cn/aigc/2223.html??

編者按：隨著大語言模型（LLMs）的上下文窗口不斷擴大，您是否開始思考：我們還需要花費大量時間和資源來構建復雜的檢索增強生成（RAG）系統嗎？
本文深入探討了長上下文 LLMs 與 RAG 系統的優劣勢，揭示了它們在實際應用中的表現差異。通過對最新四篇學術研究的全面分析，作者闡明了長上下文 LLMs 在某些任務中的優勢，同時也指出了 RAG 系統在某些專業領域任務和成本效益方面仍具有優勢。
作者建議將 RAG 與長上下文 LLMs 結合使用，以發揮協同效應，并呼吁建立更全面、更嚴格的評估體系，包括統一的評估數據集和評估指標。未來，如何有效結合這兩種技術，應當是人工智能領域的一個重要研究方向。

作者 | Florian June

編譯 | 岳揚

2023 年，大語言模型（LLMs）的上下文窗口通常在 4K 到 8K 左右。但到了 2024 年 7 月，上下文窗口超過 128K 的 LLMs 已經變得很普遍了。

以 Claude 2[1] 為例，其上下文窗口可達 100K。Gemini 1.5[2] 則宣稱能夠處理 2M 的上下文信息，而 LongRoPE[3] 更是將 LLMs 的上下文窗口擴展到了 200 萬個 tokens 以上。Llama-3–8B-Instruct-Gradient-4194k[4] 的上下文窗口更是達到了 4194K 。在應用大語言模型時，上下文窗口的大小似乎已經不再是限制因素。

于是，有人提出了這樣的觀點：既然 LLMs 能夠一次性處理所有數據，那么還有必要建立檢索增強生成（RAG）[5]系統嗎？

因此，有一些研究人員宣稱“ RAG 已死”。但也有人認為，即便有了長上下文窗口的 LLMs， RAG 系統也不會因此消亡，RAG 仍然可以煥發新的活力。

本文將重點討論這個有趣的話題：長上下文 LLMs 是否會導致檢索增強生成（RAG）系統[5]的淘汰？

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 1：RAG vs Long-Context LLMs. Image by author.

文章開頭，我們將從直觀的角度比較 RAG 與具備長上下文窗口的大語言模型（LLMs）。接著，我們將分析幾篇針對這一議題的最新學術論文。文章的最后，我將分享自己的一些思考和見解。

01 RAG 與長上下文 LLMs 的對比分析

圖 2 展示了 RAG 與具備長上下文窗口的 LLMs 在不同方面的直觀對比。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 2：RAG 與長上下文 LLMs 不同維度的對比分析。

02 學術界最新研究成果

以上內容幫助我們建立一些直觀的認識，并非對這些技術嚴謹的比較。

長上下文 LLMs 的出現同樣引起了學術界的關注。以下是最新的四篇研究論文，我們將一探究竟。

Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?[6]
RAG vs. Long Context: Examining Frontier Large Language Models for Environmental Review Document Comprehension[7]
Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach[8]
ChatQA 2: Bridging the Gap to Proprietary LLMs in Long Context and RAG Capabilities[9]

2.1 Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?

該論文[6]提出了 LOFT 基準測試，這是一個模擬真實任務場景的測試環境，需要處理上百萬個 tokens 的上下文，用以評估長上下文語言模型（LCLMs）在信息檢索和邏輯推理方面的能力。

LOFT 涵蓋了六個主要任務場景，如圖 3 上半部分所示，RAG 便是其中之一。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 3：An overview of the LOFT benchmark. Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?.[6]

圖 3 的左下角展示的是傳統的處理流程，其中包括多模態檢索工具或 RAG pipeline，需要多個專業系統的協同工作。

與此相對的是，圖 3 的右下角展示的是長上下文語言模型（LCLM）。 LCLM 能夠直接將包含文本、圖像和音頻等多種模態信息的整個語料庫作為模型輸入。通過采用 “Context in Corpus”（CiC）提示詞技術，模型能夠在統一的框架內完成包括檢索、推理和答案生成在內的多種任務。

評估結果表明，在 multi-hop datasets（譯者注：在閱讀理解等自然語言處理任務中，一個問題的答案可能需要從多個不同的段落或文檔中獲取信息。這種情況下，我們就說這個問題需要"多跳"（multi-hop）來回答。包含了這類問題的數據集就被稱作是 multi-hop datasets。）（如 HotpotQA 和 MusiQue）上，Gemini 1.5 Pro 在處理整個語料庫上下文時的表現優于 RAG pipeline。這是因為 LCLM 能夠使用思維鏈 [10] 在上下文窗口內跨多個段落進行推理，而 RAG pipeline 通常不具備這種能力，除非它額外配備有規劃（planning）和推理（reasoning）模塊。

總體來看，在 LOFT 基準測試中與 RAG 相關的任務中，Gemini 1.5 Pro（0.53）的表現略勝于 RAG pipeline（0.52）。而 GPT-4o（0.48）和 Claude 3 Opus（0.47）的表現則不如 RAG pipeline（0.52），這一結果在圖 4 中有詳細展示。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 4 ：在 LOFT 128k 上下文的基準測試集上的主要實驗結果。Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?[6]

此外，圖 5 顯示，雖然 LCLM 在 128K 上下文窗口的性能與 RAG 表現相當，但當上下文擴展到 1M 時，其性能相較于 RAG pipeline 有所下降。 這一趨勢與 LCLM 在文本檢索性能上的衰退是一致的。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 5：LCLM 與各垂直場景模型在語料庫大小從 32K 擴充至 100 萬 tokens 時的性能對比。這些結果是在每個任務所包含的所有數據集上平均計算得出的。Source: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?.[6]

2.2 RAG vs. Long Context: Examining Frontier Large Language Models for Environmental Review Document Comprehension

“RAG vs. Long Context”[7]研究評估了 RAG 和長上下文 LLMs 在那些需要專業領域知識的特定任務場景中的表現。

通過構建 NEPAQuAD 1.0 基準測試，本研究對三種先進的 LLMs —— Claude Sonnet、Gemini 和 GPT-4 —— 在回答美國聯邦機構（U.S. federal agencies）根據《National Environmental Policy Act》（NEPA）編寫的環境影響報告書（EIS）中相關問題的能力進行了評估，具體請見圖 6。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 6：在比較中使用的不同環境影響報告書（EIS）上下文的示例，其中精選的 Gold passages 由領域專家挑選。Source: RAG vs. Long Context[7].

評估結果表明，不論選擇哪種前沿的 LLM，基于 RAG 的模型在答案準確性方面都明顯優于長上下文模型。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 7：在不同上下文配置下，LLMs 在 EIS 文檔上的答案正確性評估結果。其中，silver passages 是通過 RAG pipeline 篩選的，而 gold passages 則是由專家挑選的。Source: RAG vs. Long Context[7].

如圖 7 所示，當向 LLMs 提供 RAG pipeline 篩選出的 silver passages 時，其表現顯著優于不提供任何參考文獻或提供含有問題上下文的完整 PDF 文檔。其表現甚至接近于提供專家挑選的 gold passages。

圖 8 則展示了 LLMs 在不同類型問題上的性能表現。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 8：比較不同語言模型在四種不同上下文應用場景下回答各類型問題的正確性得分。Source: RAG vs. Long Context[7].

總體而言，RAG 增強的 LLMs（silver passages）在答案準確性上明顯優于僅提供長上下文的模型。特別是在處理特定垂直領域的問題時，RAG 增強的 LLMs（silver passages）具有明顯優勢，其表現優于那些僅依靠零樣本知識（zero-shot knowledge）或完整 PDF 文檔作為上下文的模型。

另外，在回答封閉式問題時，帶有上下文（silver passages 和 gold passages）的 LLMs 表現最為出色；然而，在應對發散性問題和解題型問題時，它們的表現則相對較差。

2.3 Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

本文[8]對 RAG 與長上下文 LLMs 進行了全面比較，目的是發現并利用兩者的長處。

研究方法包括使用三種最新的 LLMs，在多個公開數據集上對 RAG 和長上下文 LLMs 進行基準測試。

研究發現，在資源充足的情況下，長上下文 LLMs 的平均性能始終優于 RAG。不過，RAG 的成本明顯更低，這仍然是一個明顯的優勢。

圖 9 展示了使用 GPT-4o，GPT-3.5-Turbo 和 Gemini-1.5-Pro 這三種最新 LLMs 的長上下文LLMs、RAG 以及本論文提出的 SELF-ROUTE 方法的比較結果。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 9：盡管長上下文 LLMs（LC）在處理、理解長上下文方面勝過 RAG，但 RAG 在成本效益上具有明顯優勢。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

SELF-ROUTE 是一種結合了 RAG 和長上下文 LLMs 的一種簡便而有效的方法，目的是在降低成本的同時，還能保持與長上下文 LLMs 相媲美的性能。該方法利用 LLMs 的自我反思能力來路由 queries ，并假定 LLMs 能夠準確預測現有上下文是否足以回答 queries。

該方法分為兩個階段：首先是 RAG 及路由階段，然后是長上下文預測階段（long-context prediction step）。

在第一階段，我們向 LLMs 提供查詢和檢索到的文本塊，并引導它預測是否能夠回答 query 。如果可以，LLMs 就會生成答案。這一過程與標準 RAG pipeline 類似，但有一個關鍵區別：LLMs 有權選擇不回答，并在提示詞中注明“如果基于現有文本無法回答 query，請寫‘無法回答’”。

對于那些判斷為可以回答的 query ，我們直接采用 RAG 的預測結果作為最終答案。對于那些判斷為不可以回答的 query ，我們則進入第二階段，將完整的上下文提供給長上下文 LLMs 以獲得最終的預測結果。相關的提示詞內容展示在圖 10 中。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 10：為每個數據集提供有相應的提示詞。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

此外，該論文還進行了幾項有趣的分析。

首先，本論文探討了在使用 top-k 方法檢索到的文本塊中 k 值如何影響檢索結果。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 11：隨著 k 的增加，模型性能和實際使用的 token 百分比的變化曲線（a）和（b）。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

圖 11 展示了隨著 k 的增加，模型性能和實際使用的 token 百分比的變化曲線（a）和（b）。

在性能方面，對于 RAG 和 SELF-ROUTE，k 值越大，性能越好。隨著 k 的增加，更多文本塊被輸入到 LLMs 中，性能逐漸提升，逐漸接近長上下文。

從變化曲線中可以看出，在 k 值較小時，SELF-ROUTE 的性能優勢最為明顯，而當 k 超過 50 時，三種方法的性能表現趨于相同。

最優的 k 值可能因數據集而異。例如，平均而言，k=5 在曲線上顯示的成本最低，但在某些數據集上，尤其是那些不需要 multi-hop 推理的提取式問題數據集（如 NarrativeQA 和 QMSum ），k=1 的成本最低。這表明，最優的 k 值取決于任務的性質和性能要求。

該論文還通過手動檢查 RAG-and-Route 步驟預測為“無法回答（unanswerable）”的示例，分析了 RAG 系統失敗的原因。它總結了四種典型的失敗原因，如圖 12 從 A 到 E 所示。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 12：Prompt for the failure case analysis. Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

接下來，使用 Gemini-1.5-Pro 對提示詞進行處理，以識別所有無法回答的示例。

圖 13 展示了 LongBench 中七個數據集中失敗原因的分布情況。每個數據集可能包含不同數量的 RAG 失敗案例，因此條形圖的高度也會有所不同。

#AIGC創新先鋒者征文大賽# RAG vs 長上下文 LLMs：誰主沉浮？-AI.x社區

圖 13：典型的 RAG 失敗原因分布。Source: Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach.[8]

我們觀察到各技術在不同數據集下的性能表現：

基于維基百科的三個 multi-hop 推理數據集（HotpotQA、2WikiMQA、MuSiQue）因為它們需要進行多步檢索，對 RAG 而言具有挑戰性，如圖中藍色部分所示。
對于 NarrativeQA，其擁有包含大量對話的長故事，大多數失敗原因是由于需要理解整個上下文中的 implicit queries（譯者注：指的是那些沒有直接在文本中表達的 query，可能隱藏在上下文中，需要通過上下文理解、推理和推斷來確定。），如圖中綠色部分所示。
QMSum 是一個包含開放式問題的摘要數據集，主要失敗原因是通用的 queries，如圖中紅色部分所示。
被分類為“其他（other）”的示例大多是多步問題（multi-step questions），這些問題由于具有模糊性而難以回答。