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

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

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

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

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

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

首先，長上下文模型會降低對相關(guān)信息的關(guān)注度，這會導(dǎo)致答案質(zhì)量下降，NVIDIA的研究證實了這一點。

其次，對于問答聊天機器人等用例，重要的不是上下文信息的數(shù)量，而是質(zhì)量。高質(zhì)量的上下文是通過針對所提問題進行高度選擇性的細粒度搜索實現(xiàn)的，而這是RAG能夠?qū)崿F(xiàn)的。

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

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

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