編者按： 如今，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？
擁有超長上下文視窗的模型是近期的發展趨勢。因此，研究人員正在嘗試開發新的評估方法，以判斷這些模型的效能。這些評估方法旨在對長上下文模型的能力與侷限性進行基準測試，並探討擴充套件上下文視窗所帶來的利弊。
核心觀點是，擁有更長輸入上下文的模型應當能夠完成那些之前難以或無法完成的任務。
評估場景
本文將探討研究人員考慮用於評估長上下文模型的以下三種方法：
- 從長篇文件中提取資訊
- 對長篇文件進行深入分析（推理和概括）
- 為即時模型訓練提供上下文學習支援
備註：以上列舉並不全面。如需全面瞭解長上下文模型的基準測試，請訪問 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/...
[4]https://developers.googleblog.com/en/new-features-for-the-gem...
[5]https://www.reddit.com/r/OpenAI/comments/1buz5ju/geminis_cont...
[6]https://www.notion.so/Long-Context-Eval-Survey-fe3c69173f2e4e...
[7]https://www.reddit.com/r/singularity/comments/1ausp2k/geminis...
[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/af5633c94ed2beb282f6a53c595eb43...
[24]https://arxiv.org/abs/2201.03533
[25]https://arxiv.org/abs/2403.03514
原文連結：
https://www.artfish.ai/p/long-context-llms