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

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

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

也就是LLM需要按照不同的使用情況，針對數據集、用戶、使用案例，甚至包括針對特定調用，生成完全不同的響應。

這通常是通過 3 種基本技術中的一種來實現的：

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

2. RAG（檢索增強生成）

3. 微調

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

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

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

他還對2個不同的RAG管道進行了基準測試：

- Llama-Index  最流行的開源RAG框架（默認設置）。

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

實驗結果

先來看下結果，再來講方法論。

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

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

準確性

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

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

成本

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

以下是每個token的成本：

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

但同樣，RAG也會產生固定的LLM智能體循環成本。

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

Llama Index的成本略低，但與之相當，為0.00028 美元/1k token（由于智能體循環不那么復雜）。

延遲

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

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

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

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

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

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

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

「大海撈針」實驗

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

從本質上講，我們給一個「大海」，并在其中的某個地方隱藏了一根「針」，然后詢問AI系統關于針的情況。

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

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

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

進一步分析

準確性

GPT-4+RAG表現非常出色。

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

更少的垃圾=更好的結果。

這些結果凸顯了我們仍處于LLM革命的初期。廣大社區仍在摸索將新的LLM構建模塊組合在一起的最合理方法。

過去一年的上下文窗口大戰完全有可能在平淡無奇中結束。

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

LlamaIndex

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

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

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

總的來說，作者非常看好LlamaIndex和開源LLM技術。

很明顯，RAG仍然處于唾手可得的領域，簡化框架是關鍵。Llama-Index已經做好準備，可以繼續整合新技術和最佳實踐。

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

成本

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

第二部分是生成增強，選擇的塊被輸入到「標準」LLM調用中（并且隨著通用性的增加，被輸入到智能體LLM循環中）。

原則上，檢索可以使用多種技術來實現，從關鍵字搜索到關系搜索，再到混合技術。

在實踐中，大多數當代RAG方法主要使用矢量搜索，這會產生一次性、按token索引的成本。隨著生態系統的成熟，混合技術的使用可能會越來越多。

每個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 的檢索功能價格更加昂貴。它以「無服務器」方式收費，0.20 美元/GB/助手/天。假設 1 個token ~ 5 個字節，即1×10^-6 美元/1k 個token/助手/天。

固定開銷

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

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

延遲

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

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