--- author: Best Partners TV date: '2026-11-11' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=DrIX-EuvQjA speaker: Best Partners TV tags: - context-compression - ai-agent - state-management - retrieval-augmentation title: 英偉達論文評析：長上下文並非必要與上下文壓縮策略 summary: 英偉達研究院論文提出長上下文並非必要，透過會話結束壓縮（EOC）、單作用壓縮（SAC）與選擇性閱讀策略，在代理任務與長輸入中以短上下文達成相近精度並降低推算成本，同時提出語意狀態空間模型（SSM）概念。但其成本節約基於分級定價假設，且長輸入基準多偏向可檢索任務，長上下文能力仍具價值。 insight: '' draft: true series: '' category: ai-application area: tech-engineering project: [] people: [] companies_orgs: - 英偉達 products_models: - H100 - Gemini 1.5 Pro - Claude 3 Opus - Claude 3.5 Sonnet - GPT-4o media_books: - 老人與海 - 了不起的蓋茨比 - 古蘭經 - 魔戒 - 戰爭與和平 status: evergreen --- 大家好，這裡是最佳合作夥伴，我是大飛。 幾天前，英偉達研究院發布了一篇標題頗具爭議性的論文：「長上下文並非必要」。這篇論文一經發表，便在人工智慧界引起了轟動。今天，我們就來討論這篇論文，看看它究竟是一項革命性的突破，還是只是被過度炒作的工程優化。 ### 長上下文的成本與硬體挑戰 首先，如果您使用過大型模型 API，您可能沒有注意到，無論您輸入 16K 代幣還是 256K 代幣，每百萬代幣的價格都相同。但是，在伺服器端維護長時間上下文的成本遠比僅僅儲存更多快取要複雜得多。 我們使用 H100 GPU 進行了測試，將上下文視窗從 16K 擴展到 256K，每百萬個輸出令牌的成本如下：Gemini 1.5 Pro 的價格是其 3.6 倍，Claude 3 Opus 的價格是其 5.6 倍，Qwen 2.5 Coder 的價格是其 7 倍。7 倍到底是什麼意思？這意味著，對於相同數量的計算資源，長上下文模式僅產生七分之一的代幣。 該論文還測量了其本地 DGX H100 硬體的延遲和記憶體使用情況。對於幾個處於長上下文模式的模型，令牌產生速度減半，而記憶體消耗卻大幅增加。 讓我們來看一個有趣的比較：文學作品的詞元計數與模型上下文視窗的詞元計數。《老人與海》有 37K，《了不起的蓋茨比》有 64K，英文版《古蘭經》有 207K，《魔戒》有 640K，《戰爭與和平》有 530K。從型號來看，Mistral Large 2 和 Claude 3.5 約為 128K，Gemini 1.5 Pro 為 2M，Qwen 2.5 Coder 為 128K，Gemini 1.5 Flash 為 1M，GPT-4o 為 128K。所以，你真的需要一次把半本聖經的內容塞進提示裡嗎？ ### 三個核心研究問題與情境管理策略 本文將此矛盾提煉為三個研究問題： - 首先，能否在缺乏長遠背景資訊的情況下完成長期任務？例如，像是編碼或多輪問答這樣的任務，對話歷史記錄會不斷累積。 - 第二，能否在缺乏大量情境資訊的情況下完成長時間輸入的任務？就像拿到一本數萬頁的手冊來回答問題一樣——這類任務的輸入內容本身就非常龐大。 - 第三，是否可以透過對每個片段執行一個操作來壓縮上下文？ 為了回答這三個問題，作者設計了三種情境管理策略，與當前主流的「把所有東西都放進去」的方法進行了比較： - 第一種叫做 **FHA**，即全歷史累積。這是所有主流 AI 代理框架的預設策略，其中每個歷史對話和工具輸出都會原封不動地輸入到上下文視窗中。 - 第二種是 **EOC**，即會話結束壓縮。每次任務輪次結束後，模型將從頭到尾的整個歷史濃縮成一組簡潔的工作筆記，然後開始新的對話，只保留這些筆記和原始任務。後續每一輪都會繼續使用這些筆記，並結合新的搜尋結果。 - 第三種是最極端的，稱為 **SAC**，即單作用壓縮。每個模型調用只執行一個操作——要麼是工具調用，要麼是響應——然後立即壓縮筆記，丟棄當前對話，並重新開始。每次呼叫模型時，它只能看到先前的工作記錄以及最新的操作結果。 基於這三種策略，我們究竟在壓縮什麼？我們當然不能讓模型憑空捏造事實。理論上講，好的壓縮不僅僅是簡單的摘要。標準總結旨在客觀還原事實，平等地保留所有事實。但對於一個需要工作的代理來說，它不需要知道自己搜尋了目錄三次；它只需要知道已搜尋該目錄但未找到目標檔案。 因此，有效的壓縮應包含五個要素： 1. **原始任務** 2. **當前意圖和後續步驟** 3. **分解的執行步驟和完成標準** 4. **已驗證的事實** 5. **死胡同** 這是一份為未來工作挑選事實的簡報，而不是對執行歷史的敘述。 ### 長距離任務實驗與壓縮效果 從實驗結果來看，首先是研究問題：長距離任務是否需要長遠背景？ LoCo 對六個長期任務基準進行了測試，涵蓋了軟體工程（包括 500 個 GitHub 問題修復）、Terminal 2.1 的 89 個終端命令列任務以及 FEB 的 824 個多跳 Wikipedia 問答對。代理評估涵蓋了專業領域，使用了 Claude 3.5 Sonnet 和 GPT-4o 等模型。 結果顯示，使用 EOC 策略可以將上下文保持在 16K 到 48K 個代幣之間。與完整歷史記錄相比，Claude 的準確率在 -3.7 到 +5.6 個百分點之間波動，而 GPT 的準確率在 -3.3 到 +4.4 個百分點之間波動。這是什麼意思？這意味著在大多數配置下，精度並沒有下降；整體情況甚至略有改善。在 22 種壓縮配置中，沒有超過 5 種配置會導致任何型號的效能損失超過兩個百分點。 成本方面呢？論文估計 OP 的成本節省為 2.2 到 8.8 倍，GPT 的成本節省為 2.4 到 5.0 倍，這意味著成本減半甚至更多，而準確性幾乎保持不變。 但是，我們必須指出，這些成本節約是模型預測值，而不是實際測量的計費資料。本文假設基於視窗大小的分級定價曲線，並將其應用於模型。在代幣價格固定的線性計費模式下，許多任務的實際名義成本會略有上升；因此，節省資金的前提是雲端服務提供者根據上下文長度實行分級定價。這是一個重要的注意事項，因為只有當定價機制改變時，本文所述的成本優勢才能實現。 ### 長輸入任務與選擇性閱讀 接下來是第二個研究問題：長輸入任務真的需要長上下文嗎？ 這項發現更有趣，而論文的策略被稱為「選擇性閱讀」。具體方法是將較長的輸入儲存為文件，防止模型一次處理所有內容。該模型首先查看文件的目錄結構，然後使用 grep 等工具根據問題決定要仔細閱讀哪些段落。它一次讀取並消化一個部分，將關鍵資訊寫入工作筆記，然後繼續讀取下一個部分，整個過程都使用一個簡短的上下文視窗。 結果表明，在所有七個長輸入任務基準測試中，這種選擇性閱讀加壓縮的策略比完全輸入基準提高了回憶率。例如，OP 的陽性率從約 63% 上升到 96%，BL 的陽性率從 67-71% 上升到 92-94%，ALCR on OS 的陽性率從 65% 上升到 84%，而 L-bench v2 的陽性率基本保持不變，OP 為 -0.4，GPT。 需要注意的是，這種改進主要來自選擇性讀取，而不是壓縮；對於大多數任務而言，壓縮操作的中位數為零，這表明壓縮通常是不必要的。換句話說，將長輸入視為檔案並按需讀取比一次性全部導入更有效。因為在將所有內容匯入模型後，模型仍然需要自行尋找相關內容，而選擇性讀取則有效地為模型提供了一個文件搜尋工具，完全跳過了檢索步驟。 然而，這裡也需要保持謹慎。這七個長時間輸入基準測試中的大多數本質上都是事實查找任務，或者說是「大海撈針」問題，在這些問題中，使用 grep 自然具有優勢。本文並未涵蓋真正需要全面理解的任務，例如完整的儲存庫重構、從整本書中提煉主題，或透過大量範例進行情境學習；即使在最接近的測試案例 L-bench v2 中，效能也基本持平，沒有任何改進。因此，目前只有能夠分解為檢索的任務才能得出「常見輸入任務不需要長上下文」的說法。 值得注意的是，許多測試的輸入長度，例如 R 的 256K 和 500K，或 Nahh 的 500K，都超過了 Obs 200K 的視窗。論文沒有解釋如何處理輸入資料——是截斷的還是分塊的？如果輸入因超出視窗範圍而被截斷，則壓縮策略的優勢可能會被高估。 ### 極限壓縮與語意狀態空間模型 前兩個問題的答案都是「是」。第三個問題更極端：我們能否透過在每個上下文中只採取一個行動來壓縮？ 論文第五部分的答案也是「是」；這個策略是 SAC，即單次作用壓縮。測試表明，在 OPO-SO 上，隨機半長輸入為 70%，SC 為 70.2%，兩者基本上相當。他們的半長輸入率為 47.2%，而 SC 為 51.8%，提高了 4.6 個百分點。GPT 略差一些；隨機半長從 84.4% 下降到 82.4%，下降了 2.0 個百分點；他們的半長從 87.6% 下降到 84.3%，下降了 3.3 個百分點。 有趣的是，在 SC 策略下，峰值上下文長度中位數僅為 7K 至 9K，最大值直接從 130K-200K 下降到 15K-37K。換句話說，透過讓模型一次最多看到 9K 個標記（即不到 10 頁的文字），它實際上可以完成以前需要 200K 個上下文的任務。 基於這個發現，作者提出了語意狀態空間模型（簡稱 SSM）的概念。核心思想是，未來的模型應該經過訓練，循環完成五個任務： 1. 讀取當前的自然狀態 2. 推理下一步 3. 執行該動作 4. 觀察結果 5. 將推理結論和結果更新回狀態，以便進行下一次迭代 這與目前 Transformer 的累積模式以及 Mamba 等狀態空間模型不同；Mamba 維護黑盒神經隱藏向量，而 SSM 維護可讀且可審計的自然語言描述。作者推測，這樣一來，訓練資料的效率會更高，因為模型不再需要學習在早期情境中專注於特定部分的技能。 然而，值得注意的是，SSM 目前只是一個概念；它還沒有經過真正的訓練，也沒有與現有模型進行比較實驗，而且作者自己也承認壓縮是有損的。論文第 3.1 節提供了一個例子：想像一個代理人有一個拋硬幣的工具，可以回到正面或反面。如果壓縮預算是固定的，那麼最終一些拋硬幣的結果將被捨棄。為了解決這個問題，本文提出將完整的歷史記錄作為可檢索資源卸載，區分必須保持上下文的資訊和可以按需檢索的資訊。 ### 論文六大審慎考量 好的，這篇論文對所有三個研究問題的答案都是「是」。完成所謂的長上下文任務，不一定需要很長的話脈絡。根據論文的結論，活躍情境可能遠小於任務的總資訊量。在代理場景中，證據確鑿，為 CloudCode 等工作流程提供了直接價值，並且壓縮模板設計非常實用。 但是，我必須提醒大家，論文中還有六點要仔細考慮： 1. **首先，成本節約是模型預測值，而不是實際計量的費用。** 節省成本的前提是雲端服務供應商根據上下文時長提供分級定價。然而，在目前固定單價制度下，名目成本往往不會下降。 2. **第二，長輸入基準測試偏向可檢索的任務。** 像「大海撈針」這樣的任務本質上是尋找事實，而 RAG 自然佔據主導地位，無法涵蓋真正需要整體視角的任務。 3. **第三，認為「本質上不存在長上下文任務」的說法是基於測試範圍的歸納，而不是證明。** 該論文本身也承認，它並不排除它們的存在。 4. **第四，該論文有選擇地依賴外部閱讀工具。** 實驗使用了 Bash，但並未完全考慮端到端搜尋、檔案掃描、工具呼叫和系統編排的成本。 5. **第五，研究僅關注兩個強大的閉源模型，且壓縮提示是手動調整的。** 在開源模型中，Qwen-3-CODN 在 16K 配置下的召回率從 53% 下降到 3.6%，因為其輸出軌跡過於冗長，導致壓縮之間出現進度延遲。這表明上下文能力與模型、輸出長度和訓練方法密切相關。 6. **第六，推理時間不是訓練時間。** 實驗中的模型已經針對長時間上下文進行了訓練。這篇論文實際上證明的是，運行時不需要填充上下文窗口，而不是模型不需要長上下文能力。 ### 對產業的深遠影響與總結 最後，讓我們來討論一下這對產業的影響；我認為有三點最值得注意： 第一，智能體的記憶機制可能會從上下文累積轉變為狀態管理和外部檢索的混合，其中上下文處理當前決策，狀態確保任務連續性，外部存儲保存完整歷史記錄，工具按需獲取證據，因此長期記憶不必僅依賴模型的窗口。 其次，視窗容量不應再被視為代理能力的直接指標。評估一個代理程式需要同時考慮任務完成率、狀態交接的可靠性、檢索準確性、上下文規模和端到端成本。模型能力和系統資訊管理能力也應分別進行評估。 第三，本文是英偉達「本地前沿智慧」研究計畫的一部分。目標是在成本低於 1000 美元、功耗約為 40 瓦的設備上運行前沿的本地智慧。如果短上下文就能完成任務，那麼這條路徑對於局部推理至關重要，因為顯存和計算總是限制因素，所以本文的論點可以說有點自說自話。 總而言之，本文最大的價值在於將長期上下文從預設工作記憶體降級為按需外部存儲，證明了這種工程路徑是可行的，並且對於代理來說可能更具成本效益。然而，斷言長時程模型已經過時顯然超出了目前的證據範圍。長遠視角仍然是一項寶貴的能力；它不一定需要成為推理每一步的預設值。