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

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

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

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

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

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

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

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

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

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

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