RAG+GPT-4 Turbo讓模型性能飆升！更長上下文不是終局，「大海撈針」實驗成本僅4%
RAG+GPT-4，4%的成本，便可擁有卓越的性能。
這是最新的「大海撈針」實驗得出的結論。
在產品中使用LLM的下一階段，重點是讓它們生成的響應/回復更加「超前高速化」(hyper-specific)。
也就是LLM需要按照不同的使用情況，針對數據集、用戶、使用案例，甚至包括針對特定調用，生成完全不同的響應。
這通常是通過 3 種基本技術中的一種來實現(xiàn)的：
1. 上下文窗口填充（Context-window stuffing）
2. RAG（檢索增強生成）
3. 微調
正如實踐者所知，與炒作相反（「在您的數據上訓練的 GPT......！」），主要是使用上下文窗口填充和 RAG（而不是微調）來專門化 LLM 的響應。
作者Atai Barkai最近在CopilotKit中添加了一個新的面向文檔的react hook，專門用于容納（可能是長格式的）文檔。
為了幫助選擇合理的默認值（受到Greg Kamradt的啟發(fā)），BarkaiRAG 和 GPT-4-Turbo 的上下文窗口進行了一次「大海撈針」式的壓力測試，涉及3個關鍵指標：（1） 準確性；（2） 成本；（3） 延遲。
他還對2個不同的RAG管道進行了基準測試：
- Llama-Index 最流行的開源RAG框架（默認設置）。
- OpenAI的新助手API的檢索工具——在后臺使用 RAG（已證明可使用Qdrant向量數據庫）。
實驗結果
先來看下結果，再來講方法論。
長話短說，現(xiàn)代的檢索增強型生成（RAG）模型的效果非常好。
根據你的使用情況，你可能永遠都不想把上下文窗口塞得太滿（至少在處理文本時）。
準確性
如上圖所示，assistant API （GPT-4+RAG）的性能近乎完美。
注意：這一性能僅適用于搜索式查詢。大型上下文窗口還有其他用例（如少樣本學習）。
成本
上下文窗口填充僅產生每個token的成本，而RAG產生每個token的成本，以及額外的固定LLM推理成本。
以下是每個token的成本：
如果你沒有注意到，這個差值跨越了4個數量級（對數刻度）。
但同樣，RAG也會產生固定的LLM智能體循環(huán)成本。
對于128k上下文窗口，平均總成本約為0.0004 美元/1k token，或GPT-4-Turbo成本的4%。
Llama Index的成本略低，但與之相當，為0.00028 美元/1k token（由于智能體循環(huán)不那么復雜）。
延遲
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系統(tǒng)關于針的情況。
作者會把這根「針」放在大海的不同位置，從最開始到結束的地方，每個位置間隔約10%。
在上下文窗口填充實驗中，作者只是將「大海撈針」推到了LLM調用上下文窗口上。在RAG實驗中，作者創(chuàng)建了一個文檔并對其執(zhí)行了RAG。
（正如格雷格的出色分析一樣，「大海撈針」是Paul Graham的論文集，而「針」是一個不相關的事實。
進一步分析
準確性
GPT-4+RAG表現(xiàn)非常出色。
這并不完全令人驚訝。在LLM上下文窗口中放置不相關的信息不僅成本高昂，而且對性能有害。
更少的垃圾=更好的結果。
這些結果凸顯了我們仍處于LLM革命的初期。廣大社區(qū)仍在摸索將新的LLM構建模塊組合在一起的最合理方法。
過去一年的上下文窗口大戰(zhàn)完全有可能在平淡無奇中結束。
大家都明白，基于RAG的日益復雜的技術，而不是更大的上下文窗口，才是關鍵所在（至少對于文本而言）。
LlamaIndex
作者本以為隨著上下文窗口的增加，RAG的性能會大致相同。
但事實并非如此，當上下文長度超過約100k時，性能明顯下降。他的猜測是，超過一定的上下文大小后，「針」就不再被檢索過程獲取了。
不同的分塊和檢索配置可能會影響此結果。
總的來說，作者非常看好LlamaIndex和開源LLM技術。
很明顯，RAG仍然處于唾手可得的領域，簡化框架是關鍵。Llama-Index已經做好準備，可以繼續(xù)整合新技術和最佳實踐。
這張泄露的OpenAI開發(fā)者日幻燈片提供了一些靈感：
成本
RAG 成本分析有點微妙，因為它只是部分確定性的。RAG 的第一部分是檢索，根據一些啟發(fā)式（通常是矢量搜索）從更廣泛的數據集中選擇最「有前途」的文檔塊。
第二部分是生成增強，選擇的塊被輸入到「標準」LLM調用中（并且隨著通用性的增加，被輸入到智能體LLM循環(huán)中）。
原則上，檢索可以使用多種技術來實現(xiàn)，從關鍵字搜索到關系搜索，再到混合技術。
在實踐中，大多數當代RAG方法主要使用矢量搜索，這會產生一次性、按token索引的成本。隨著生態(tài)系統(tǒng)的成熟，混合技術的使用可能會越來越多。
每個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 個字節(jié)，即1×10^-6 美元/1k 個token/助手/天。
固定開銷
開銷部分很難計算（或者說不可能，在 OpenAI 的情況下），所以作者也只是憑經驗測量它。
如結果部分所述，RAG還會產生固定開銷，該開銷源自LLM推理步驟。對于128k上下文，此固定成本為GPT-4上下文窗口的4%。
延遲
原則上，嵌入計算是高度可并行化的。因此，考慮到市場需求，未來的基礎設施改進可能會將延遲降低到單個塊嵌入的往返。
在這種情況下，可以看到即使是「在線」RAG管道延遲也會大大減少，以至于「在線」RAG延遲僅由LLM思維鏈循環(huán)的延遲主導。
