編者按： 如今，AI模型的上下文窗口正以驚人的速度擴大——從2018年的區區512個token到現在的200萬token。這種跨越式發展不僅僅是數字的變化，更代表著全新的應用機會：律師可以讓AI快速分析數千頁的法律文書，醫生能夠基于完整的病歷做出更精準的診斷，研究人員可以同時處理數百篇學術論文...但問題是，我們如何確保這些超長上下文模型真的"理解"了如此龐大的信息量？

作者從三個維度詳細闡述了長上下文模型的評估方法——信息檢索能力評估、深度分析能力評估、上下文學習能力評估。作者基于實際研究案例，系統地展示了這些評估方法的應用場景和局限性。

作者 | Yennie Jun

編譯 | 岳揚

近年來，語言模型的上下文窗口大小呈指數級增長，此圖由原文作者制作

01 Introduction

大語言模型的上下文窗口 —— 即它們一次性能夠處理的文章長度 —— 一直在以指數級速度增長。

2018 年，BERT[1]、T5[2] 和 GPT-1[3] 等語言模型能夠處理的輸入 token 數量上限為 512 個。而到了 2024 年夏季，這一數字已飆升至 200 萬個 token（在公開可用的 LLMs 中）。這一變化對我們有何影響，我們又該如何評估這些能力越來越強的模型呢？

1.1 大上下文窗口究竟意味著什么？

最新發布的 Gemini 1.5 Pro 模型能夠接收高達 200 萬個 token[4]。但 200 萬個 token 究竟代表什么呢？

假設大約每 4 個單詞轉換為 3 個 token，那么 200 萬個 token 幾乎可以囊括完整的《哈利·波特》和《指環王》系列小說。

這張圖表展示了 Gemini 1.5 的 200 萬 tokens 上下文窗口能夠容納多少本《哈利·波特》和《指環王》書籍。此圖表部分靈感來源于 2024 年 3 月的這張精彩的信息圖表[5]。該圖由原文作者制作

這些數字指的是公開模型中可用的上下文窗口。盡管 Gemini 1.5 Pro 模型目前公開可用的上下文窗口為 200 萬個 token，但它能夠處理多達 1000 萬個 token[6]。

正如一位 Reddit 用戶所說，這意味著可以將 1000 篇科學論文納入 Gemini 的 1000 萬 token 上下文窗口中，以開展創新研究[7]。

1.2 大上下文窗口為何至關重要？

擴大上下文窗口的意義，不僅僅在于讓構建 LLMs 的公司能夠相互競技。長上下文模型在現實世界中的應用場景廣泛，以下是一些例子：

• 法律研究：律師可以將完整的案例經過、先例和法規輸入模型，在幾秒鐘內就能獲得全面的分析，而非耗費數小時甚至數日進行人工審查。
• 財務分析：將多年的財務報告、市場動態和經濟指標輸入AI，就能立即獲得深入洞察。
• 醫療診斷：醫生能夠輸入患者的全部醫療記錄，包括醫療檢測結果、治療記錄和高清醫學影像，以實現更精確的診斷和個性化治療方案。
• 教育領域：學生可以將整本教材和課程資料輸入模型，獲得定制化的知識點解釋和跨學科的知識串聯。

然而，這些使用案例也引起了人們的擔憂。如果不當使用，處理海量個人數據的能力可能會帶來前所未有的監控和隱私侵犯。隨著這些能力的提升，制定強有力的倫理規范和安全保障的需求也日益迫切。

02 我們該如何評估上下文窗口大小不斷增加的 LLMs？

擁有超長上下文窗口的模型是近期的發展趨勢。因此，研究人員正在嘗試開發新的評估方法，以判斷這些模型的性能。這些評估方法旨在對長上下文模型的能力與局限性進行基準測試，并探討擴展上下文窗口所帶來的利弊。

核心觀點是，擁有更長輸入上下文的模型應當能夠完成那些之前難以或無法完成的任務。

評估場景

本文將探討研究人員考慮用于評估長上下文模型的以下三種方法：

1. 從長篇文檔中提取信息
2. 對長篇文檔進行深入分析（推理和概括）
3. 為即時模型訓練提供上下文學習支持

備注：以上列舉并不全面。如需全面了解長上下文模型的基準測試，請訪問 Awesome LLM Long Context Modeling 的 Github 頁面[8]。

2.1 從長篇文檔中提取信息

Greg Kamradt[9] 提出的“大海撈針（Needle in a Haystack）”測試[10]，是評價長文本信息檢索效率的一種流行手段。該方法通過將一句與上下文不符的語句（即“針（needle）”），隨機插入不同長度的文本段落（即“海（haystack）”）中，以此考察模型在不同深度下檢索信息的能力。

例如，將“The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day”這句話，嵌入到 Paul Graham 的文章之中。

該測試旨在衡量 LLMs 在日益增大的上下文內，定位具體信息的能力。

Greg Kamradt[9] 設計的原始“大海撈針”圖表，用于檢驗 LLMs 在檢索深層次信息方面的能力。通過將這句不協調的句子（“針”）置于不同長度的文本片段（“海”）的各個層級，我們可以評估不同 LLMs 在尋找這些信息時的表現。

“needle in a Haystack”的多種變體

研究人員設計了幾種不同的測試，以探究信息檢索的各個方面：

• 多“針”測試：在冗長的文檔中散布多個“針”句子（由 Langchain[11] 提出，并在 NeedleBench[12] 中進行實驗）。
• 多模態搜索：根據描述，在一堆無關的圖片中尋找目標圖像。
• 音頻搜索：在長達五天的音頻信號中識別出一段簡短的音頻（該測試在 Gemini 1.5 技術報告[13]中提出）。在此測試中，一段包含“the secret keyword is needle”這句話的音頻片段，被隱藏在接近五天（107小時）的音頻信號中。
• 視頻搜索：在一部長達 10.5 小時的視頻中，找到含有特定文字的單幀畫面（同樣在 Gemini 1.5 技術報告[13]中描述）。在這個測試中，一張顯示“The secret word is needle”文字的畫面，被嵌入到了由七部完整的 AlphaGo 紀錄片拼接而成的視頻中。

Gemini 1.5 論文中介紹了基于視頻的“Needle in a Haystack”，圖片來自《Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context》（第 110 頁）

“Needle in a Haystack”方法的局限與影響

盡管“Needle in a Haystack”方法應用廣泛，但它也存在一些局限性：

• 首先，這是一個模擬任務，可能與現實世界的應用場景不符。
• 其次，它僅評估信息的查找能力，而不涉及邏輯推理或理解能力。
• 再者，隨著上下文范圍的擴大，對所有可能的“海”大小和“針”位置的組合進行評估，其成本將越來越高。

盡管存在這些缺陷，該測試卻凸顯了長上下文模型的一項重要功能：即能從海量數據中迅速搜尋和提取信息。這一功能的重要性不容小覷，它不僅能提升研究效率，還能達到前所未有的數據分析水平——甚至可能用于監控。

值得注意的是，這種信息檢索方式與檢索增強生成（RAG）不同，它是在一個連貫的大型上下文中進行，而不是從外部資源中提取信息。

2.2 對長篇文檔進行深入分析（推理和概括）

盡管" Needle in a Haystack "測試主要關注信息檢索能力，但還有其他評估方法用于檢測大語言模型在處理長篇內容時的推理、解讀和綜合信息的能力。這些評估方法旨在檢驗模型是否能夠進行更高級的推理，而不僅僅是尋找數據的具體位置。

以下是屬于此類的幾種評估方法：

文學問答任務

書籍是長篇文檔的經典例子。NOVELQA[14] 這樣的基準測試就是用來評估模型處理文學小說的能力，文檔長度可達 200K 個 tokens。這個測試包含了針對 88 本英語小說的問題（這些問題由人類編寫），涵蓋了公版書和受版權保護的作品。其他數據集，比如NoCha[15]，也采取了相似的評估方式。

在這里插入圖片描述

插圖說明：這張圖表展示了來自 NovelQA 數據集[14]的兩個示例問題，這些示例取自《NovelQA: Benchmarking Question Answering on Documents Exceeding 200K Tokens》[14]一文。

在含有隱蔽相關信息的長篇文章中進行邏輯推理

FlenQA[16] 通過將相關信息嵌入到較長的非相關信息中，生成了多個不同長度的上下文版本。這種方法有助于我們了解，隨著上下文長度的增加，大語言模型的處理能力如何逐步下降。

在 FlenQA 的一個任務示例中，相關信息（以深紅色表示）被穿插在大量無關信息之中。此圖表摘自《Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models》[16]一文。

針對特定領域的邏輯推理

• 醫療領域：LongHealth[17] 基準測試采用了 20 個虛構的病例（每個病例包含 5-7 千字），以此來評估模型在醫學推理方面的能力。
• 金融領域：DocFinQA[18] 則通過讓模型處理長達 150 頁的金融文檔（包含超過 100K 個 tokens）來對其進行挑戰。

總結摘要任務

對于大語言模型而言，能夠有效地壓縮長篇文檔的內容是一項至關重要的能力，因為它可以讓用戶在不閱讀全部內容的情況下，快速掌握大量文本中的關鍵信息。這一點在研究領域、商業分析和法律實踐中尤為重要，這些領域的專家經常需要將大量資料精煉為簡潔的報告。

但是，如何評價總結摘要的質量是一項復雜的任務。總結摘要不僅要求對全文有深刻的理解，還要求能夠精準地識別并整合關鍵信息。 什么樣的總結摘要算是優質，往往取決于個人主觀判斷和具體上下文。

目前，總結摘要質量的評估多依賴于將模型的輸出與人工編寫的總結摘要進行對比，這種方法并不完美，可能無法涵蓋所有合理的總結摘要方式，也可能會忽略那些用詞不同但含義準確的總結摘要。

為了應對這些挑戰，LongBench[19] 和 ∞Bench[20] 等基準測試應運而生。LongBench 涵蓋了多種文檔類型（如政府報告、會議紀要、新聞報道）的摘要任務，文檔長度可達 15K 字；而 ∞Bench 則進一步拓展了摘要任務的挑戰邊界，包含長度可達 100K 個 tokens 的文檔。盡管這些基準測試頗具價值，但該領域仍在探索更為有效的評估方法，以便更精準地評價高質量總結摘要的細微差別。

若想深入了解這一主題，可以查閱《An Empirical Survey on Long Document Summarization: Datasets, Models, and Metrics》[21]這一文章。

2.3 為即時模型訓練提供上下文學習支持

長上下文模型最酷的應用之一便是在上下文學習（ICL）方面的增強能力。ICL 技術使得模型能夠即時從提示詞中的示例中學會處理新任務。得益于更大的上下文窗口，我們現在能夠納入成百上千的訓練樣本，甚至是那些復雜且篇幅較長的任務，比如文本摘要。

這項技術改變了游戲規則。它讓開發人員可以跳過針對特定領域的模型微調，直接通過 ICL 讓模型迅速適應新任務。

Many-shot ICL

DeepMind 針對多樣本 ICL[22] 的研究表明，當提示詞中包含更多示例時，模型在不同任務上的表現有顯著提升。通過擴充到成百上千的示例，模型能夠克服預訓練中的偏見，并處理更為復雜的問題。

通過在提示詞中增加更多的示例（即“shots”），相同的 LLM 模型在多種任務上都能展現出更好的性能。例如，將情感分析任務的示例從 32 個增加到 2048 個，模型的表現提升了 18.2 %。此圖摘自《Many-Shot In-Context Learning》[22]。

這一理念不僅僅局限于性能提升。Anthropic 公司在其“Many-shot Jailbreaking”[23]項目中的研究發現，雖然僅憑幾個樣本無法突破模型的安全防線，但是如果有數百個樣本，就能做到這一點——這一發現既展示了這種方法的威力，也揭示了其潛在的風險。

例如，我們可以看到，僅僅幾個樣本是無法誘導 LLM 生成有害內容的，但是當樣本數量增加到數十個甚至數百個時，就能讓模型忽視其“安全圍欄”。此圖來自于《Many-Shot Jailbreaking》[23]。

翻譯低資源語言

在低資源語言的翻譯方面，長上下文模型展現出了非凡的價值。在 Gemini 1.5 的技術報告[13]中，以 Kalamang 語為例，這種語言的使用者不足200人，網絡資源也非常有限。通過向模型輸入 500 頁的語法資料、一個包含 2000 個詞條的雙語詞匯表以及 400 個對照句子（總共 250 k個 tokens），模型不僅能翻譯 Kalamang 語，還能進行語音轉錄。

這種方法同樣適用于其他低資源語言，并且隨著示例數量的增加，翻譯性能也在不斷提升。對于瀕危語言的保護和使用來說，這無疑是一個充滿希望的新進展。

03 Discussion

對于更長上下文窗口的追求正在語言模型領域掀起一場激烈的競賽，上下文窗口的規模正以驚人的速度擴張。這種擴張迫使我們需要開發新的評估手段，以便更準確地把握這些模型的實力與短板。

盡管已經涌現出了一批針對長上下文模型的評估基準（如 SCROLLS[24]、LongBench[19]、∞BENCH[20]等），但仍有許多疑問尚待解答：

• 規模的權衡：當上下文長度不斷增加時，模型在安全性、偏見和指令執行方面的表現會如何波動？
• 多語種表現：大多數評估基準都著眼于英語（CLongEval[25] 等評估基準除外，其中也涵蓋了中文的評估）。那么，對于非英語系的語言，隨著上下文的增加，其表現又會與英語有何不同？
• 性能衰退：模型在處理更豐富上下文的同時，是否會犧牲掉某些特定能力，比如編程技能或是創造力？
• 現實影響：當模型能夠處理整本書籍、完整個人經歷，甚至是稀缺語言的詳盡數據時，我們將面臨哪些倫理和現實層面的挑戰？

隨著大語言模型（LLMs）的上下文窗口不斷擴大，我們不僅要了解它們能做到什么，還要探究它們的基本特性可能會如何變化。

目前來看，這場追逐更大上下文窗口模型的競賽還將持續升溫。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the authors

Yennie Jun

Machine learning engineer and AI researcher exploring my curiosity of the world through creative projects

END

本期互動內容 ??

? #技術探討# 你認為評估長上下文模型最重要的指標是什么？為什么？

??文中鏈接??

[1]??https://arxiv.org/abs/1810.04805??

[2]??https://arxiv.org/abs/1910.10683??

[3]??https://cdn.openai.com/research-covers/language-unsupervised/language_understanding_paper.pdf??

[4]??https://developers.googleblog.com/en/new-features-for-the-gemini-api-and-google-ai-studio/??

[5]??https://www.reddit.com/r/OpenAI/comments/1buz5ju/geminis_context_window_is_much_larger_than_anyone/??

[6]??https://www.notion.so/Long-Context-Eval-Survey-fe3c69173f2e4eb0b5cd4c973f712626?pvs=21??

[7]??https://www.reddit.com/r/singularity/comments/1ausp2k/geminis_nearly_perfect_10_million_context_length/??

[8]??https://github.com/Xnhyacinth/Awesome-LLM-Long-Context-Modeling?tab=readme-ov-file#11-Benchmark-and-Evaluation??

[9]??https://twitter.com/GregKamradt??

[10]??https://github.com/gkamradt/LLMTest_NeedleInAHaystack??

[11]??https://blog.langchain.dev/multi-needle-in-a-haystack/??

[12]??https://arxiv.org/abs/2407.11963??

[13]??https://arxiv.org/abs/2403.05530??

[14]??https://arxiv.org/pdf/2403.12766??

[15]??https://arxiv.org/abs/2406.16264??

[16]??https://arxiv.org/pdf/2402.14848v1??

[17]??https://arxiv.org/pdf/2401.14490??

[18]??https://arxiv.org/pdf/2401.06915??

[19]??https://arxiv.org/pdf/2308.14508??

[20]??https://arxiv.org/pdf/2402.13718??

[21]??https://dl.acm.org/doi/10.1145/3545176??

[22]??https://arxiv.org/pdf/2404.11018??

[23]??https://www-cdn.anthropic.com/af5633c94ed2beb282f6a53c595eb437e8e7b630/Many_Shot_Jailbreaking__2024_04_02_0936.pdf??

[24]??https://arxiv.org/abs/2201.03533??

[25]??https://arxiv.org/abs/2403.03514??

原文鏈接：

??https://www.artfish.ai/p/long-context-llms??