RAG+GPT-4，4%的成本，便可擁有卓越的性能。

這是最新的「大海撈針」實驗得出的結(jié)論。

在產(chǎn)品中使用LLM的下一階段，重點是讓它們生成的響應(yīng)/回復(fù)更加「超前高速化」(hyper-specific)。

也就是LLM需要按照不同的使用情況，針對數(shù)據(jù)集、用戶、使用案例，甚至包括針對特定調(diào)用，生成完全不同的響應(yīng)。

這通常是通過 3 種基本技術(shù)中的一種來實現(xiàn)的：

1. 上下文窗口填充（Context-window stuffing）

2. RAG（檢索增強生成）

3. 微調(diào)

正如實踐者所知，與炒作相反（「在您的數(shù)據(jù)上訓(xùn)練的 GPT......！」），主要是使用上下文窗口填充和 RAG（而不是微調(diào)）來專門化 LLM 的響應(yīng)。

作者Atai Barkai最近在CopilotKit中添加了一個新的面向文檔的react hook，專門用于容納（可能是長格式的）文檔。

為了幫助選擇合理的默認(rèn)值（受到Greg Kamradt的啟發(fā)），BarkaiRAG 和 GPT-4-Turbo 的上下文窗口進行了一次「大海撈針」式的壓力測試，涉及3個關(guān)鍵指標(biāo)：（1） 準(zhǔn)確性；（2） 成本；（3） 延遲。

他還對2個不同的RAG管道進行了基準(zhǔn)測試：

- Llama-Index  最流行的開源RAG框架（默認(rèn)設(shè)置）。

- OpenAI的新助手API的檢索工具——在后臺使用 RAG（已證明可使用Qdrant向量數(shù)據(jù)庫）。

實驗結(jié)果

先來看下結(jié)果，再來講方法論。

長話短說，現(xiàn)代的檢索增強型生成（RAG）模型的效果非常好。

根據(jù)你的使用情況，你可能永遠都不想把上下文窗口塞得太滿（至少在處理文本時）。

準(zhǔn)確性

如上圖所示，assistant API （GPT-4+RAG）的性能近乎完美。

注意：這一性能僅適用于搜索式查詢。大型上下文窗口還有其他用例（如少樣本學(xué)習(xí)）。

成本

上下文窗口填充僅產(chǎn)生每個token的成本，而RAG產(chǎn)生每個token的成本，以及額外的固定LLM推理成本。

以下是每個token的成本：

如果你沒有注意到，這個差值跨越了4個數(shù)量級（對數(shù)刻度）。

但同樣，RAG也會產(chǎn)生固定的LLM智能體循環(huán)成本。

對于128k上下文窗口，平均總成本約為0.0004 美元/1k token，或GPT-4-Turbo成本的4%。

Llama Index的成本略低，但與之相當(dāng)，為0.00028 美元/1k token（由于智能體循環(huán)不那么復(fù)雜）。

延遲

RAG通常是針對離線數(shù)據(jù)進行的，檢索延遲以毫秒為單位，端到端延遲主要由LLM調(diào)用決定。

但作者認(rèn)為，比較一下從文件上傳到返回結(jié)果的端到端延遲時間，看看RAG是否能與「在線」（而非離線）數(shù)據(jù)競爭，會很有意思。

以下是對128k token文檔進行查詢的端到端延遲：

- LlamaIndex RAG最低，平均為12.9秒。

- 其次是GPT4-Turbo，平均用時21.6秒，但差距很大，為7-36秒。

- assistant API RAG檢索時間為24.8秒。

此外，大多數(shù)應(yīng)用程序都能從樂觀的文檔上傳中獲益，從而最大限度地減少感知延遲。由于RAG索引的成本很低，通常不會有太大損失。

「大海撈針」實驗

作者Atai Barkai以Greg Kamradt的出色工作為基礎(chǔ)，他最近進行了GPT-4-Turbo和Claude 2.1的「大海撈針」（needle in a haystack）壓力測試。

從本質(zhì)上講，我們給一個「大?！?，并在其中的某個地方隱藏了一根「針」，然后詢問AI系統(tǒng)關(guān)于針的情況。

作者會把這根「針」放在大海的不同位置，從最開始到結(jié)束的地方，每個位置間隔約10%。

在上下文窗口填充實驗中，作者只是將「大海撈針」推到了LLM調(diào)用上下文窗口上。在RAG實驗中，作者創(chuàng)建了一個文檔并對其執(zhí)行了RAG。

（正如格雷格的出色分析一樣，「大海撈針」是Paul Graham的論文集，而「針」是一個不相關(guān)的事實。

進一步分析

準(zhǔn)確性

GPT-4+RAG表現(xiàn)非常出色。

這并不完全令人驚訝。在LLM上下文窗口中放置不相關(guān)的信息不僅成本高昂，而且對性能有害。

更少的垃圾=更好的結(jié)果。

這些結(jié)果凸顯了我們?nèi)蕴幱贚LM革命的初期。廣大社區(qū)仍在摸索將新的LLM構(gòu)建模塊組合在一起的最合理方法。

過去一年的上下文窗口大戰(zhàn)完全有可能在平淡無奇中結(jié)束。

大家都明白，基于RAG的日益復(fù)雜的技術(shù)，而不是更大的上下文窗口，才是關(guān)鍵所在（至少對于文本而言）。

LlamaIndex

作者本以為隨著上下文窗口的增加，RAG的性能會大致相同。

但事實并非如此，當(dāng)上下文長度超過約100k時，性能明顯下降。他的猜測是，超過一定的上下文大小后，「針」就不再被檢索過程獲取了。

不同的分塊和檢索配置可能會影響此結(jié)果。

總的來說，作者非?？春肔lamaIndex和開源LLM技術(shù)。

很明顯，RAG仍然處于唾手可得的領(lǐng)域，簡化框架是關(guān)鍵。Llama-Index已經(jīng)做好準(zhǔn)備，可以繼續(xù)整合新技術(shù)和最佳實踐。

這張泄露的OpenAI開發(fā)者日幻燈片提供了一些靈感：

成本

RAG 成本分析有點微妙，因為它只是部分確定性的。RAG 的第一部分是檢索，根據(jù)一些啟發(fā)式（通常是矢量搜索）從更廣泛的數(shù)據(jù)集中選擇最「有前途」的文檔塊。

第二部分是生成增強，選擇的塊被輸入到「標(biāo)準(zhǔn)」LLM調(diào)用中（并且隨著通用性的增加，被輸入到智能體LLM循環(huán)中）。

原則上，檢索可以使用多種技術(shù)來實現(xiàn)，從關(guān)鍵字搜索到關(guān)系搜索，再到混合技術(shù)。

在實踐中，大多數(shù)當(dāng)代RAG方法主要使用矢量搜索，這會產(chǎn)生一次性、按token索引的成本。隨著生態(tài)系統(tǒng)的成熟，混合技術(shù)的使用可能會越來越多。

每個token的成本

讓我們首先看一下每個token的成本：

- GPT-4-Turbo 以 $0.01/1k token的價格。（與GPT-4和GPT-4-32k相比，價格分別降低了3倍和6倍） - OpenAI 的 ada v2 嵌入模型收費 0.0001 美元/1k token。這比GPT-4-Turbo便宜100倍。

- OpenAI 的助手 API 的檢索功能價格更加昂貴。它以「無服務(wù)器」方式收費，0.20 美元/GB/助手/天。假設(shè) 1 個token ~ 5 個字節(jié)，即1×10^-6 美元/1k 個token/助手/天。

固定開銷

開銷部分很難計算（或者說不可能，在 OpenAI 的情況下），所以作者也只是憑經(jīng)驗測量它。

如結(jié)果部分所述，RAG還會產(chǎn)生固定開銷，該開銷源自LLM推理步驟。對于128k上下文，此固定成本為GPT-4上下文窗口的4%。

延遲

原則上，嵌入計算是高度可并行化的。因此，考慮到市場需求，未來的基礎(chǔ)設(shè)施改進可能會將延遲降低到單個塊嵌入的往返。

在這種情況下，可以看到即使是「在線」RAG管道延遲也會大大減少，以至于「在線」RAG延遲僅由LLM思維鏈循環(huán)的延遲主導(dǎo)。