譯者 | 布加迪

審校 | 重樓

檢索增強生成（RAG）已成為為定制信息定制大語言模型（LLM）的事實上的方法。然而RAG帶來了前期技術(shù)成本，并且速度可能很慢。由于長上下文LLM方面取得的進步，企業(yè)可以通過在提示中插入所有的專有信息來繞過RAG。

臺灣政治大學(xué)的一項新研究表明，如果使用長上下文LLM和緩存技術(shù)，你就可以創(chuàng)建定制的應(yīng)用程序，性能卻比RAG管道更勝一籌。這種方法就叫作緩存增強生成（CAG），可以在知識語料庫能裝入到模型上下文窗口的企業(yè)環(huán)境中簡單而有效地替代RAG。

RAG的局限性

RAG是處理開放領(lǐng)域問題和專門任務(wù)的一種有效方法。它使用檢索算法來收集與請求相關(guān)的文檔，并添加上下文使LLM能夠生成更準(zhǔn)確的響應(yīng)。

然而，RAG給LLM應(yīng)用帶來了幾個限制。添加的檢索步驟引入了延遲，這會降低用戶體驗。結(jié)果還取決于文檔選擇和排序步驟的質(zhì)量。在許多情況下，用于檢索的模型具有的局限性要求將文檔分解為更小的塊，這可能會影響檢索過程。

此外，RAG通常增添了LLM應(yīng)用的復(fù)雜性，需要開發(fā)、集成和維護額外的組件。增加的開銷減慢了開發(fā)過程。

緩存增強檢索

圖1. RAG（上）與CAG（下）（來源：arXiv）

開發(fā)RAG管道的替代方法是將整個文檔語料庫插入到提示中，讓模型選擇哪些部分與請求相關(guān)。這種方法消除了RAG管道的復(fù)雜性以及檢索錯誤引起的問題。

然而，將所有文檔預(yù)先加載到提示中存在三個關(guān)鍵挑戰(zhàn)。首先，長提示會減慢模型的速度，并增加推理的成本。其次，LLM上下文窗口的長度限制了插入到提示中的文檔數(shù)量。最后，為提示添加不相關(guān)的信息會導(dǎo)致模型混淆，降低其響應(yīng)的質(zhì)量。因此，僅僅將所有文檔塞入到提示而不是選擇最相關(guān)的文檔，最終會降低模型的性能。

提議的CAG方法利用以下三個關(guān)鍵趨勢來克服這些挑戰(zhàn)。

首先，先進的緩存技術(shù)使處理提示模板變得更快速、更省錢。CAG的前提是知識文檔將包含在發(fā)送給模型的每個提示中。因此，你可以提前計算其詞元（token）的注意力值，而不是在接收請求時這么做。這種預(yù)先計算縮短了處理用戶請求所需的時間。

OpenAI、Anthropic和谷歌等領(lǐng)先的LLM提供商為提示的重復(fù)部分提供了提示緩存功能，這包括你在提示開頭插入的知識文檔和指令。以Anthropic為例，如果使用提示的緩存部分，你就可以減少高達90%的成本和85%的延遲。廠商們已為開源LLM托管平臺開發(fā)出了相應(yīng)的緩存功能。

其次，長上下文LLM使更多文檔和知識更容易插入到提示中。Claude 3.5 Sonnet支持多達20萬個詞元，而GPT-40支持128000個詞元，Gemini支持多達200萬個詞元。因此就有可能在提示中插入多個文檔或整本書。

最后，先進的訓(xùn)練方法使模型面對很長的序列能夠執(zhí)行更好的檢索、推理和問答。在去年，研究人員已為長序列任務(wù)開發(fā)出了幾個LLM基準(zhǔn)測試，包括BABILong、LongICLBench和RULER。這些基準(zhǔn)測試可以測試LLM在多次檢索和多跳問答等難題上的表現(xiàn)。這個領(lǐng)域仍有改進的空間，但AI實驗室仍在不斷取得進展。

隨著新一代模型繼續(xù)擴展上下文窗口，它們將能夠處理更龐大的知識庫。此外，我們可以期望模型繼續(xù)提升從長上下文中提取和使用相關(guān)信息的能力。

研究人員寫道：“這兩個趨勢將大大擴展我們這種方法的可用性，使其能夠處理更復(fù)雜、更多樣化的應(yīng)用。因此，我們的方法很有希望成為處理知識密集型任務(wù)的強大而通用的解決方案，利用下一代LLM不斷增強的功能。”

RAG vs CAG

為了比較RAG和CAG，研究人員針對兩個廣泛認(rèn)可的問答基準(zhǔn)測試SQuAD和HotPotQA進行了實驗：前者側(cè)重于單個文檔的上下文感知問答，后者需要跨多個文檔進行多跳推理。

他們使用了Llama-3.1-8B模型，具有128000個詞元上下文窗口。針對RAG，他們將LLM與兩個檢索系統(tǒng)相結(jié)合以獲得與問題相關(guān)的段落：基本的BM25算法和OpenAI嵌入。針對CAG，他們將多個文檔從基準(zhǔn)測試中插入到提示中，讓模型自行決定使用哪些段落來回答問題。他們的實驗表明，CAG在大多數(shù)情況下的表現(xiàn)都優(yōu)于RAG系統(tǒng)。

圖2. CAG的表現(xiàn)優(yōu)于稀疏RAG （BM25檢索）和密集RAG（OpenAI嵌入）

研究人員寫道：“通過從測試集預(yù)加載整個上下文，我們的系統(tǒng)消除了檢索錯誤，并確保了針對所有相關(guān)信息的整體推理。在RAG系統(tǒng)可能檢索不完整或不相關(guān)的段落、導(dǎo)致答案生成不盡如人意的情況下，這種優(yōu)勢來得尤為明顯。”

CAG還顯著縮短了生成答案的時間，特別是當(dāng)參考文本長度增加時。

圖3. CAG的答案生成時間比RAG短得多（來源：arXiv）

話雖如此，CAG并非靈丹妙藥，應(yīng)該謹(jǐn)慎使用。它非常適合這類場景：知識庫并不經(jīng)常改變，又小到足以插入到模型的上下文窗口。企業(yè)還應(yīng)該注意文檔包含基于文檔上下文的沖突性事實的情況，這可能會在推理過程中導(dǎo)致模型混淆。

要確定CAG是否適合你的使用場景，最佳方法是試驗一番。幸好，CAG的實現(xiàn)很簡單，在致力于需要更多開發(fā)工作的RAG解決方案之前，應(yīng)該始終將試用CAG視為第一步。

原文標(biāo)題：Beyond RAG: How cache-augmented generation reduces latency, complexity for smaller workloads，作者：Ben Dickson