大語言模型：RAG 和長上下文長度的優缺點比較

如何控制大語言模型(LLM_的幻覺(Hallucination)一直是想善用LLM發展應用的企業的頭痛問題。目前科技圈最流行的解決方案有兩種:

1. 透過檢索增強生成(RAG) 引入一個檢索器，動態選擇與給定問題（輸入查詢）最相關的上下文，並將這些資訊添加到LLM中，以減少幻覺生成。
2. 選擇支援長上下文長度(Long Context Length)的LLM，將較長的文字段落暴力輸入給LLM進行理解並基於輸入之長文字段落回答問題。

然而，以上兩種方法該如何選擇效果最好呢？WITS AI+Data COE 的AI專家許傅鈞博士提出了他的見解，以下為許博士的文章。

RAG 和Long Context LLM的比較

最近在注意力機制方面的進展讓大語言模型（LLM）可處理的上下文長度（Context Window)快速提升。

從最初受限於512個tokens輸入上下文的BERT，到最新的每次計算能處理數百萬tokens的模型如Gemini-1.5-pro，長上下文LLM吸引了大家的注意。然而，關於是直接應用它還是使用帶有檢索技術的較短上下文LLM（俗稱RAG，即檢索增強生成）仍然存在爭論。

如何評估

Long Context的優點

• 改善多跳查詢

例如：

(1) 在2023年第三季度報告中，Google、Apple和Nvidia中哪家公司報告的利潤率最大？

(2) Apple過去三年的銷售趨勢如何？

這需要“從多個文件中提取證據”來形成答案。 然而，使用LLM Agent進行多次證據檢索和重新排序可以解決這個問題。

• 支援更長的響應長度

例如：財務報告、大規模編程代碼或論文。 (但可以通過適當的提示或代理處理)

Long Context的缺點

• 大海撈針 - 性能下降

• 長上下文窗口LLM的計算開銷 - 高量查詢 - 成本較高

• 黑箱 - 無法訪問或追蹤其使用的資料
• 失去“上下文學習”能力
• 中間丟失問題：證明了在長上下文提交文檔的開頭和結尾的事實比中間部分獲得更多的覆蓋。

RAG 的優點

• 資料處理效率高：較低的計算成本和延遲，RAG僅檢索最相關的資訊片段，達到減少浪費的效果。
• 可靠的資訊源：提供透明度和可追蹤性
• 代理功能 ：使用ReAct和工具解決多跳查詢問題，通過從多個來源檢索和整合資訊執行複雜任務。
• 企業性能：RAG能夠有效處理多樣化和動態的資料源。
  

RAG 的缺點

• 對“檢索器”的負擔較重，需要搜索更多的“閱讀器”單元以萃取所需的精確資訊。
• 對問題的語義理解不完整
• 語料庫規模非常大
• 如果問題涉及文件不同部分的不同資訊，風險最小化
• 答案召回性能下降

總結

• LCLMs(Long-context language models)可以直接處理整個資訊來源語料庫，消除了對外部工具專業知識的需求。然而，在需要複雜推理的任務中（例如SQL類任務）仍然面臨困難。最後，性能受限於所使用的提示策略。
• 儘管長上下文LLM在某些QA任務（例如多跳）方面相比短上下文窗口LLM（不使用RAG）具有優勢，但在擴展上下文窗口中，除非檢索答案位於文本的開頭或結尾，否則可能會遭受“中間丟失”現象。
• 通過RAG的4K模型效率高且性能接近長上下文LLM。當然，結合長上下文和RAG的大模型（LLaMA20-70B-32k-ret）表現最佳，但成本也較高。