要說最近最郁悶的公司，谷歌肯定算得上一個：自家的 Gemini 1.5 剛剛發(fā)布，就被 OpenAI 的 Sora 搶盡了風頭，堪稱 AI 界的「汪峰」。

具體來說，谷歌這次推出的是用于早期測試的 Gemini 1.5 的第一個版本 ——Gemini 1.5 Pro。它是一種中型多模態(tài)模型（涉及文本、視頻、音頻），性能水平與谷歌迄今為止最大的模型 1.0 Ultra 類似，并引入了長上下文理解方面的突破性實驗特征。它能夠穩(wěn)定處理高達 100 萬 token（相當于 1 小時的視頻、11 小時的音頻、超過 3 萬行代碼或 70 萬個單詞），極限為 1000 萬 token（相當于《指環(huán)王》三部曲），創(chuàng)下了最長上下文窗口的紀錄。

此外，它還能僅靠一本 500 頁的語法書、 2000 條雙語詞條和 400 個額外的平行句子學會一門小語種的翻譯（網(wǎng)絡上沒有相關資料），翻譯得分接近人類學習者。

很多測試過 Gemini 1.5 Pro 的人都表示，這個模型被低估了。比如有人嘗試將從 Github 上下載的整個代碼庫連同 issue 都扔給 Gemini 1.5 Pro，結果它不僅理解了整個代碼庫，還識別出了最緊急的 issue 并修復了問題。

在另一個代碼相關的測試中，Gemini 1.5 Pro 也表現(xiàn)出了強大的檢索能力（在代碼庫中查找出最相關的示例）、理解能力（找到控制動畫的代碼并給出自定義代碼的建議）和跨模態(tài)的能力（憑截圖找到演示并指導如何編輯圖像代碼）。

這樣一個模型，理應引起大家的重視。而且，值得注意的是，Gemini 1.5 Pro 展現(xiàn)出的處理超長上下文的能力也讓不少研究者開始思考，傳統(tǒng)的 RAG 方法還有存在的必要嗎？

一位 X 網(wǎng)友表示，在他進行的一個測試中，支持超長上下文的 Gemini 1.5 Pro 確實做到了 RAG 做不到的事情。

RAG 要被長上下文模型殺死了？

「一個擁有 1000 萬 token 上下文窗口的模型讓大多數(shù)現(xiàn)有的 RAG 框架都變得不那么必要了，也就是說，1000 萬 token 上下文殺死了 RAG，」愛丁堡大學博士生符堯在評價 Gemini 1.5 Pro 的帖子中寫到。

RAG 是「Retrieval-Augmented Generation」的縮寫，中文可以翻譯為「檢索增強生成」。RAG 通常包括兩個階段：檢索上下文相關信息和使用檢索到的知識指導生成過程。舉個例子，作為一名員工，你可以直接問大模型「我們公司對遲到有什么懲罰措施？」在沒有讀過《員工手冊》的情況下，大模型沒有辦法回答。但是，借助 RAG 方法，我們可以先讓一個檢索模型到《員工手冊》里去尋找最相關的幾個答案，然后把你的問題和它找到的相關答案都送到生成模型中，讓大模型生成答案。這就解決了之前很多大模型上下文窗口不夠大（比如容不下《員工手冊》）的問題，但 RAGfangfa 在捕捉上下文之間細微聯(lián)系等方面有所欠缺。

符堯認為，如果一個模型可以直接處理 1000 萬 token 的上下文信息，就沒有必要再通過額外的檢索步驟來尋找和整合相關信息了。用戶可以直接將他們需要的所有數(shù)據(jù)作為上下文放入模型中，然后像往常一樣與模型進行交互。「大型語言模型本身已經(jīng)是一個非常強大的檢索器，為什么還要費力建立一個弱小的檢索器，并在分塊、嵌入、索引等方面耗費大量工程精力呢？」他繼續(xù)寫到。

不過，符堯的觀點遭到了很多研究者的反駁。他表示，其中很多反駁都是合理的，他也將這些意見系統(tǒng)梳理了一下：

1、成本問題：批評者指出，RAG 比長上下文模型便宜。符堯承認這一點，但他比較了不同技術的發(fā)展歷程，指出雖然低成本模型（如 BERT-small 或 n-gram）確實便宜，但在 AI 發(fā)展的歷史中，先進技術的成本最終都會降低。他的觀點是，首先追求智能模型的性能，然后再通過技術進步降低成本，因為讓智能模型變得便宜比讓便宜模型變得智能要容易得多。

2、檢索與推理的整合：符堯強調，長上下文模型能夠在整個解碼過程中混合檢索和推理，而 RAG 僅在開始時進行檢索。長上下文模型可以在每一層、每一個 token 進行檢索，這意味著模型能夠根據(jù)初步推理的結果動態(tài)決定需要檢索的信息，實現(xiàn)更緊密的檢索與推理整合。

3、支持的 token 數(shù)量：盡管 RAG 支持的 token 數(shù)量達到了萬億級別，而長上下文模型目前支持的是百萬級別，符堯認為，在自然分布的輸入文檔中，大多數(shù)需要檢索的情況都在百萬級別以下。他以法律文檔分析和學習機器學習為例，認為這些情況下的輸入量并不會超過百萬級別。

4、緩存機制：關于長上下文模型需要重新輸入整個文檔的問題，符堯指出存在所謂的 KV（鍵值）緩存機制，可以設計復雜的緩存和內存層次結構，使得輸入只需讀取一次，后續(xù)查詢可以重用 KV 緩存。他還提到，盡管 KV 緩存可能很大，但他對未來會出現(xiàn)高效的 KV 緩存壓縮算法持樂觀態(tài)度。

5、調用搜索引擎的需求：他承認，在短期內，調用搜索引擎進行檢索仍然是必要的。然而，他提出了一個大膽的設想，即讓語言模型直接訪問整個谷歌搜索索引，從而吸收全部信息，這體現(xiàn)了對 AI 技術未來潛力的極大想象力。

6、性能問題：符堯承認目前的 Gemini 1.5 在處理 1M 上下文時速度較慢，但他對提速持樂觀態(tài)度，認為未來長上下文模型的速度將大大提升，最終可能達到與 RAG 相當?shù)乃俣取?/span>

除了符堯，其他很多研究者也在 X 平臺上發(fā)表了自己對于 RAG 前景的看法，比如 AI 博主 @elvis。

總體來看，他不認為長上下文模型能取代 RAG，理由包括：

1、特定數(shù)據(jù)類型的挑戰(zhàn)：@elvis 提出了一種情景，即數(shù)據(jù)具有復雜結構、定期變化，并且具有重要的時間維度（例如代碼編輯 / 更改和網(wǎng)絡日志）。這種類型的數(shù)據(jù)可能與歷史數(shù)據(jù)點相連，并且將來可能連接更多數(shù)據(jù)點。@elvis 認為，今天的長上下文語言模型單獨無法處理依賴于此類數(shù)據(jù)的用例，因為這些數(shù)據(jù)對于 LLM 來說可能太復雜，且當前的最大上下文窗口對于此類數(shù)據(jù)來說并不可行。在處理此類數(shù)據(jù)時，最終可能需要某種巧妙的檢索機制。

2、對動態(tài)信息的處理：今天的長上下文 LLM 在處理靜態(tài)信息（如書籍、視頻錄像、PDF 等）方面表現(xiàn)出色，但在處理高度動態(tài)的信息和知識方面尚未經(jīng)過實戰(zhàn)測試。@elvis 認為，雖然我們將朝著解決一些挑戰(zhàn)（如「lost in the middle」）以及處理更復雜的結構化和動態(tài)數(shù)據(jù)方面取得進展，但我們仍有很長的路要走。

3、@elvis 提出，為了解決這些類型的問題，可以將 RAG 和長上下文 LLM 結合起來，構建一個強大的系統(tǒng)，有效且高效地檢索和分析關鍵的歷史信息。他強調，即使這樣，在許多情況下也可能不足夠。特別是因為大量數(shù)據(jù)可能會迅速變化，基于 AI 的智能體增加了更多的復雜性。@elvis 認為，對于復雜的用例，很可能會結合這些想法，而不是通用或長上下文 LLM 取代一切。

4、對不同類型 LLM 的需求：@elvis 指出，不是所有數(shù)據(jù)都是靜態(tài)的，很多數(shù)據(jù)都是動態(tài)的。在考慮這些應用時，需要記住大數(shù)據(jù)的三個 V：速度（velocity）、體量（volume）和多樣性（variety）。@elvis 通過在搜索公司的工作經(jīng)驗學到了這一課。他認為，不同類型的 LLM 將幫助解決不同類型的問題，我們需要摒棄一個 LLM 將統(tǒng)治一切的想法。

@elvis 最后引用了 Oriol Vinyals（谷歌 DeepMind 的研究副總裁）的話，指出即使現(xiàn)在我們能夠處理 100 萬或更多 token 的上下文，RAG 的時代還遠未結束。實際上，RAG 具有一些非常好的特性。這些特性不僅可以通過長上下文模型得到增強，而且長上下文模型也可以通過 RAG 得到增強。RAG 允許我們找到相關的信息，但是模型訪問這些信息的方式可能由于數(shù)據(jù)壓縮而變得過于受限。長上下文模型可以幫助彌補這一差距，這有點類似于現(xiàn)代 CPU 中 L1/L2 緩存和主內存是如何協(xié)同工作的。在這種協(xié)作模式下，緩存和主內存各自承擔不同的角色，但又相互補充，從而提高了處理速度和效率。同樣，RAG 和長上下文的結合使用，可以實現(xiàn)更靈活、更高效的信息檢索和生成，充分利用各自的優(yōu)勢來處理復雜的數(shù)據(jù)和任務。

看來，「RAG 的時代是否即將終結」還沒有定論。但很多人都表示，作為一個超長上下文窗口模型，Gemini 1.5 Pro 確實被低估了。@elvis 也給出了他的測試結果。

Gemini 1.5 Pro 初步測評報告

長文檔分析能力

為了展示 Gemini 1.5 Pro 處理和分析文檔的能力，@elvis 從一個非常基本的問題解答任務開始。他上傳了一個 PDF 文件，并提出了一個簡單的問題：這篇論文是關于什么的？

模型的回復準確而簡潔，因為它提供了可接受的 Galactica 論文摘要。上面的示例使用的是 Google AI Studio 中的自由格式提示，但你也可以使用聊天格式與上傳的 PDF 進行交互。如果你有很多問題想從所提供的文檔中得到解答，這是一項非常有用的功能。

為了充分利用長上下文窗口，@elvis 接下來上傳了兩個 PDF 進行測試，并提出了一個跨越兩個 PDF 的問題。

Gemini 1.5 Pro 給出的答復是合理的。有趣的是，從第一篇論文（關于 LLM 的綜述論文）中提取的信息來自一個表格。「架構」信息看起來也是正確的。但是，「性能」部分并不屬于這部分，因為第一篇論文中沒有這部分內容。在這項任務中，重要的是要把提示「Please list the facts mentioned in the first paper about the large language model introduced in the second paper」放在最上面，并在論文上標注標簽，如「Paper 1」和「Paper 2」 。本實驗的另一個相關后續(xù)任務是通過上傳一組論文和如何總結這些論文的說明來撰寫相關工作。另一項有趣的任務是要求模型將較新的 LLM 論文寫進綜述。

視頻理解

Gemini 1.5 Pro 從一開始就接受了多模態(tài)數(shù)據(jù)的訓練。@elvis 用 Andrej Karpathy 最近的 LLM 講座視頻測試了一些提示：

他要求模型完成的第二項任務是提供一份簡明扼要的講座提綱（篇幅為一頁）。回答如下（為簡潔起見作了編輯）：

Gemini 1.5 Pro 給出的摘要非常簡潔，很好地概括了講座內容和要點。

當具體細節(jié)非常重要時，請注意模型有時可能會產(chǎn)生「幻覺」，或由于各種原因檢索到錯誤信息。例如，當向模型詢問以下問題時：「What are the FLOPs reported for Llama 2 in the lecture?」，它的回答是「The lecture reports that training Llama 2 70B required approximately 1 trillion FLOPs」，這是不準確的。正確的回答應該是「~1e24 FLOPs」。技術報告中包含了許多例子，說明當被問及有關視頻的具體問題時，這些長上下文模型會出現(xiàn)失誤。

下一項任務是從視頻中提取表格信息。測試結果表明，該模型能生成表格，其中一些細節(jié)正確，一些細節(jié)錯誤。例如，表格的列是正確的，但其中一行的標簽是錯誤的（即 Concept Resolution 應該是 Coref Resolution）。測試者用其他表格和其他不同元素（如文本框）測試了其中一些提取任務，也發(fā)現(xiàn)了類似的不一致性。

技術報告中記錄的一個有趣的例子是，模型能夠根據(jù)特定場景或時間戳從視頻中檢索細節(jié)。在第一個例子中，測試者向模型詢問某個部分是從哪里開始的。模型回答正確。

在下一個示例中，他要求模型解釋幻燈片中的一個圖表。該模型似乎很好地利用了所提供的信息來解釋圖表中的結果。

下面是相應幻燈片的快照：

@elvis 表示，他已經(jīng)開始著手進行第二輪測試，感興趣的同學可以去 X 平臺上圍觀。