要說最近最鬱悶的公司，Google肯定算得上一個：自家的 Gemini 1.5 # 剛發布，就被OpenAI 的Sora 搶盡了風頭，堪稱AI 界的「汪峰」。
具體來說，Google這次推出的是早期測試的 Gemini 1.5 的第一個版本 ——Gemini 1.5 Pro。它是一種中型多模態模型（涉及文字、視訊、音訊），性能水平與Google迄今為止最大的模型 1.0 Ultra 類似，並引入了長上下文理解的突破性實驗特徵。它能夠穩定處理高達100 萬token（相當於1 小時的影片、11 小時的音訊、超過3 萬行程式碼或70 萬個單字），極限為1,000 萬token（相當於《魔戒》三部曲），創下了最長上下文視窗的紀錄。
此外，它還能只憑一本500 頁的文法書、 2000 條雙語詞條和400 個額外的平行句子來學習一門小語種的翻譯（網路上沒有相關資料），在翻譯方面達到接近人類學習者的程度。
許多使用 Gemini 1.5 Pro 的人都認為這款車型被低估了。有人進行實驗，將從Github 下載的完整程式碼庫和相關問題一併輸入到Gemini 1.5 Pro 中，結果令人驚訝：它不僅理解了整個程式碼庫，還能識別出最緊急的問題並對其進行修復。
在另一個與程式碼相關的測試中，Gemini 1.5 Pro 展現出了出色的搜尋功能，能夠快速在程式碼庫中找到最相關的範例。此外，它還展示了很強的理解能力，能夠準確找到控制動畫的程式碼，並提供個人化的程式碼建議。同樣，Gemini 1.5 Pro 也展現了卓越的跨模式能力，透過截圖能夠準確地找到演示內容，並提供指導以編輯圖像代碼。
這樣一個模型，理當引起大家的重視。而且，值得注意的是，Gemini 1.5 Pro 展現出的處理超長脈絡的能力也讓不少研究者開始思考，傳統的 RAG 方法還有存在的必要嗎？
一位X 網友表示，在他進行的一個測試中，支援超長上下文的Gemini 1.5 Pro 確實做到了RAG 做不到的事。
「一個擁有1000 萬token 上下文視窗的模型讓大多數現有的RAG 框架都變得不那麼必要了，也就是說，1000 萬token 上下文殺死了RAG ，」愛丁堡大學博士生符堯在評價Gemini 1.5 Pro 的貼文中寫到。
RAG 是「Retrieval-Augmented Generation」的縮寫，中文可以翻譯為「檢索增強生成」。 RAG 通常包括兩個階段：檢索上下文相關資訊和使用檢索到的知識指導生成過程。舉個例子，作為一名員工，你可以直接問大模型「我們公司對遲到有什麼懲罰措施？」在沒有讀過《員工手冊》的情況下，大模型沒有辦法回答。但是，借助RAG 方法，我們可以先讓一個檢索模型到《員工手冊》裡去尋找最相關的幾個答案，然後把你的問題和它找到的相關答案都送到生成模型中，讓大模型生成答案。這就解決了之前很多大模型上下文視窗不夠大（例如容不下《員工手冊》）的問題，但 RAGfangfa 在捕捉上下文之間細微聯繫等方面有所欠缺。
符堯認為，如果一個模型可以直接處理 1000 萬 token 的上下文訊息，就沒有必要再透過額外的檢索步驟來尋找和整合相關資訊了。使用者可以直接將他們需要的所有資料作為上下文放入模型中，然後像往常一樣與模型進行互動。 「大型語言模型本身已經是一個非常強大的檢索器，為什麼還要費力建立一個弱小的檢索器，並在分塊、嵌入、索引等方面耗費大量工程精力呢？」他繼續寫到。
不過，符堯的觀點也遭到了許多研究者的反駁。他表示，其中許多反駁都是合理的，他也將這些意見系統梳理了一下：
1、成本問題：批評者指出，RAG 比長上下文模型便宜。符堯承認這一點，但他比較了不同技術的發展歷程，指出雖然低成本模型（如 BERT-small 或 n-gram）確實便宜，但在 AI 發展的歷史中，先進技術的成本最終都會降低。他的觀點是，先追求智慧模型的效能，然後再透過技術進步降低成本，因為讓智慧模型變得便宜比讓便宜模型變得聰明要容易得多。
2、檢索與推理的整合：符堯強調，長上下文模型能夠在整個解碼過程中混合檢索和推理，而RAG 僅在開始時進行檢索。長上下文模型可以在每一層、每一個 token 進行檢索，這意味著模型能夠根據初步推理的結果動態決定需要檢索的信息，實現更緊密的檢索與推理整合。
3、支援的token 數量：儘管RAG 支援的token 數量達到了萬億級別，而長上下文模型目前支援的是百萬級別，符堯認為，在自然分佈的輸入文件中，大多數需要檢索的情況都在百萬級以下。他以法律文件分析和學習機器學習為例，認為這些情況下的輸入量並不會超過百萬等級。
4、快取機制：關於長上下文模型需要重新輸入整個文件的問題，符堯指出存在所謂的KV（鍵值）緩存機制，可以設計複雜的快取和記憶體層次結構，使得輸入只需讀取一次，後續查詢可以重複使用KV 快取。他還提到，儘管 KV 快取可能很大，但他對未來會出現高效的 KV 快取壓縮演算法持樂觀態度。
5、呼叫搜尋引擎的需求：他承認，在短期內，呼叫搜尋引擎進行檢索仍然是必要的。然而，他提出了一個大膽的設想，即讓語言模型直接訪問整個谷歌搜尋索引，從而吸收全部信息，這體現了對 AI 技術未來潛力的極大想像。
6、效能問題：符堯承認目前的Gemini 1.5 在處理1M 情境時速度較慢，但他對提速持樂觀態度，認為未來長上下文模型的速度將大大提升，最終可能達到與RAG 相當的速度。
除了符堯，其他許多研究者也在 X 平台上發表了自己對 RAG 前景的看法，例如 AI 部落客 @elvis。
整體來看，他不認為長上下文模型能取代RAG，理由包括：
1、特定資料類型的挑戰：@elvis 提出了一種情景，即資料具有複雜結構、定期變化，並且具有重要的時間維度（例如程式碼編輯/ 更改和網路日誌）。這種類型的數據可能與歷史數據點相連，並且將來可能連接更多數據點。 @elvis 認為，今天的長上下文語言模型無法單獨處理依賴此類資料的用例，因為這些資料對於 LLM 來說可能太複雜，而目前的最大上下文視窗對於此類資料來說並不可行。在處理此類資料時，最終可能需要某種巧妙的檢索機制。
2、對動態訊息的處理：今天的長上下文LLM 在處理靜態訊息（如書籍、錄影、PDF 等）方面表現出色，但在處理高度動態的訊息和知識方面尚未經過實戰測試。 @elvis 認為，雖然我們將朝著解決一些挑戰（如“lost in the middle”）以及處理更複雜的結構化和動態數據方面取得進展，但我們仍有很長的路要走。
3、@elvis 提出，為了解決這些類型的問題，可以將RAG 和長上下文LLM 結合起來，建構一個強大的系統，有效且有效率地檢索和分析關鍵的歷史資訊。他強調，即使是這樣，在許多情況下也可能不足夠。特別是因為大量數據可能會迅速變化，基於 AI 的智能體增加了更多的複雜性。 @elvis 認為，對於複雜的用例，很可能會結合這些想法，而不是通用或長上下文 LLM 取代一切。
4、對不同型別 LLM 的需求：@elvis 指出，不是所有資料都是靜態的，很多資料都是動態的。在考慮這些應用時，需要記住大數據的三個 V：速度（velocity）、體積（volume）和多樣性（variety）。 @elvis 透過在搜尋公司的工作經驗學到了這一課。他認為，不同類型的 LLM 將有助於解決不同類型的問題，我們需要拋棄一個 LLM 將統治一切的想法。
@elvis 最後引用了Oriol Vinyals（GoogleDeepMind 的研究副總裁）的話，指出即使現在我們能夠處理100 萬或更多token的上下文，RAG 的時代還遠遠沒有結束。實際上，RAG 具有一些非常好的特性。這些特性不僅可以透過長上下文模型得到增強，而且長上下文模型也可以透過 RAG 來增強。 RAG 允許我們找到相關的信息，但是模型訪問這些信息的方式可能由於數據壓縮而變得過於受限。長上下文模型可以幫助彌補這一差距，這有點類似於現代 CPU 中 L1/L2 快取和主記憶體是如何協同工作的。在這種協作模式下，快取和主記憶體各自承擔不同的角色，但又相互補充，從而提高了處理速度和效率。同樣，RAG 和長上下文的結合使用，可以實現更靈活、更有效率的資訊檢索和生成，充分利用各自的優勢來處理複雜的資料和任務。
看來，「RAG 的時代是否即將終結」還沒有定論。但許多人都表示，作為一個超長上下文視窗模型，Gemini 1.5 Pro 確實被低估了。 @elvis 也給了他的測試結果。
長文件分析能力
為了展示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” 。本實驗的另一個相關後續任務是透過上傳一組論文和如何總結這些論文的說明來撰寫相關工作。另一個有趣的任務是要求模型將較新的 LLM 論文寫進綜述。
影片理解
#Gemini 1.5 Pro 從一開始就接受了多模態資料的訓練。 @elvis 用Andrej Karpathy 最近的LLM 講座影片測試了一些提示：
#他要求模型完成的第二個任務是提供一份簡明扼要的講座提綱（篇幅為一頁）。答案如下（為簡潔起見作了編輯）：
#Gemini 1.5 Pro 給出的摘要非常簡潔，很好地概括了講座內容和要點。
當具體細節非常重要時，請注意模型有時可能會產生「幻覺」，或由於各種原因檢索錯誤訊息。例如，當向模型詢問以下問題時：「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」。技術報告中包含了許多例子，說明當被問及有關影片的具體問題時，這些長上下文模型會出現錯誤。
下一項任務是從影片中提取表格資訊。測試結果表明，該模型能產生表格，其中一些細節正確，一些細節錯誤。例如，表格的欄位是正確的，但其中一行的標籤是錯誤的（即 Concept Resolution 應該是 Coref Resolution）。測試者以其他表格和其他不同元素（如文字方塊）測試了其中一些提取任務，也發現了類似的不一致性。
技術報告中記錄的一個有趣的例子是，模型能夠根據特定場景或時間戳從影片中檢索細節。在第一個例子中，測試者向模型詢問某個部分是從哪裡開始的。模型回答正確。
在下一個範例中，他要求模型解釋投影片中的一個圖表。該模型似乎很好地利用了所提供的資訊來解釋圖表中的結果。
下面是對應投影片的快照：
@elvis 表示，他已經開始著手進行第二輪測試，有興趣的同學可以去 X 平台上圍觀。
以上是谷歌10M上下文視窗正在殺死RAG？被Sora奪走風頭的Gemini被低估了？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
