長文本模型非常適合減少某些需要更長上下文用例的幻覺，但并非所有情況都理想。

譯自Solving the RAG vs. Long Context Model Dilemma，作者 Kiran Matty。

許多開發者一直在使用檢索增強生成 (RAG) 和大規模上下文語料庫來構建生成式AI應用程序，并解決諸如通用型大型語言模型 (LLM)面臨的AI幻覺等問題。

現在，長上下文模型正在興起，例如具有200萬個token上下文窗口的Gemini，其潛在優勢使您不禁想知道是否應該完全放棄RAG。解決這一難題的關鍵在于了解使用長上下文模型的優缺點，并根據您的用例做出明智的決定。

傳統上，LLM具有較小的上下文窗口，這限制了可以一次處理的文本或token數量。到目前為止，RAG一直是解決此限制的有效方案。通過檢索最相關的文本或上下文片段，用它來增強用戶提示，然后將其傳遞給LLM，RAG可以有效地處理比上下文窗口通常支持的大得多的數據集。

然而，像Gemini這樣的長上下文模型可以直接處理提供的上下文，而無需單獨的RAG系統，從而簡化了應用程序工作流程并可能減少延遲。要了解100萬個token的上下文窗口，它相當于八部中等長度的英文小說或超過200集中等長度播客節目的文字記錄。然而，它絕不是減少幻覺的靈丹妙藥，并且也有其自身的局限性。

首先，長上下文模型會降低對相關信息的關注度，這會導致答案質量下降，NVIDIA的研究證實了這一點。

其次，對于問答聊天機器人等用例，重要的不是上下文信息的數量，而是質量。高質量的上下文是通過針對所提問題進行高度選擇性的細粒度搜索實現的，而這是RAG能夠實現的。

最后，長上下文模型需要更多GPU資源來處理長上下文，從而導致處理時間更長，成本更高。可以肯定地說，這些模型每次查詢的成本更高。您可以使用鍵值 (KV) 緩存來緩存輸入token以跨請求重用，但這需要大量的GPU內存，因此會增加相關成本。關鍵在于用更少的輸入token實現高質量的答案。

盡管存在局限性，但長上下文模型支持一些需要更長上下文的引人注目的用例，例如翻譯或摘要，例如，將文檔從英語翻譯成梵語（印度使用人數最少的語言）用于教育目的。由于梵語復雜的語法結構以及與其他廣泛使用的語言相比，訓練數據的有限性，LLM難以進行這種翻譯。因此，提供足夠數量的示例作為上下文將有助于提高翻譯的準確性。其他方法包括一次對多個大型文檔進行摘要和比較以生成見解，例如，比較多家公司的10K報告以創建財務基準。

長上下文模型對于某些需要更長上下文的用例非常適合減少幻覺。但是，對于所有其他用例，我們建議使用RAG檢索與回答用戶問題相關的上下文，以實現高精度和成本效益。如果RAG無法達到預期的精度，我們建議將RAG與微調結合使用以提高領域特異性。