長上下文語言模型評估體系探析 原創(chuàng) 精華
編者按： 如今，AI模型的上下文窗口正以驚人的速度擴大——從2018年的區(qū)區(qū)512個token到現(xiàn)在的200萬token。這種跨越式發(fā)展不僅僅是數(shù)字的變化，更代表著全新的應(yīng)用機會：律師可以讓AI快速分析數(shù)千頁的法律文書，醫(yī)生能夠基于完整的病歷做出更精準的診斷，研究人員可以同時處理數(shù)百篇學術(shù)論文...但問題是，我們?nèi)绾未_保這些超長上下文模型真的"理解"了如此龐大的信息量？
作者從三個維度詳細闡述了長上下文模型的評估方法——信息檢索能力評估、深度分析能力評估、上下文學習能力評估。作者基于實際研究案例，系統(tǒng)地展示了這些評估方法的應(yīng)用場景和局限性。
作者 | Yennie Jun
編譯 | 岳揚
近年來，語言模型的上下文窗口大小呈指數(shù)級增長，此圖由原文作者制作
01 Introduction
大語言模型的上下文窗口 —— 即它們一次性能夠處理的文章長度 —— 一直在以指數(shù)級速度增長。
2018 年，BERT[1]、T5[2] 和 GPT-1[3] 等語言模型能夠處理的輸入 token 數(shù)量上限為 512 個。而到了 2024 年夏季，這一數(shù)字已飆升至 200 萬個 token（在公開可用的 LLMs 中）。這一變化對我們有何影響，我們又該如何評估這些能力越來越強的模型呢？
1.1 大上下文窗口究竟意味著什么？
最新發(fā)布的 Gemini 1.5 Pro 模型能夠接收高達 200 萬個 token[4]。但 200 萬個 token 究竟代表什么呢？
假設(shè)大約每 4 個單詞轉(zhuǎn)換為 3 個 token，那么 200 萬個 token 幾乎可以囊括完整的《哈利·波特》和《指環(huán)王》系列小說。
這張圖表展示了 Gemini 1.5 的 200 萬 tokens 上下文窗口能夠容納多少本《哈利·波特》和《指環(huán)王》書籍。此圖表部分靈感來源于 2024 年 3 月的這張精彩的信息圖表[5]。該圖由原文作者制作
這些數(shù)字指的是公開模型中可用的上下文窗口。盡管 Gemini 1.5 Pro 模型目前公開可用的上下文窗口為 200 萬個 token，但它能夠處理多達 1000 萬個 token[6]。
正如一位 Reddit 用戶所說，這意味著可以將 1000 篇科學論文納入 Gemini 的 1000 萬 token 上下文窗口中，以開展創(chuàng)新研究[7]。
1.2 大上下文窗口為何至關(guān)重要？
擴大上下文窗口的意義，不僅僅在于讓構(gòu)建 LLMs 的公司能夠相互競技。長上下文模型在現(xiàn)實世界中的應(yīng)用場景廣泛，以下是一些例子：
- 法律研究：律師可以將完整的案例經(jīng)過、先例和法規(guī)輸入模型，在幾秒鐘內(nèi)就能獲得全面的分析，而非耗費數(shù)小時甚至數(shù)日進行人工審查。
- 財務(wù)分析：將多年的財務(wù)報告、市場動態(tài)和經(jīng)濟指標輸入AI，就能立即獲得深入洞察。
- 醫(yī)療診斷：醫(yī)生能夠輸入患者的全部醫(yī)療記錄，包括醫(yī)療檢測結(jié)果、治療記錄和高清醫(yī)學影像，以實現(xiàn)更精確的診斷和個性化治療方案。
- 教育領(lǐng)域：學生可以將整本教材和課程資料輸入模型，獲得定制化的知識點解釋和跨學科的知識串聯(lián)。
然而，這些使用案例也引起了人們的擔憂。如果不當使用，處理海量個人數(shù)據(jù)的能力可能會帶來前所未有的監(jiān)控和隱私侵犯。隨著這些能力的提升，制定強有力的倫理規(guī)范和安全保障的需求也日益迫切。
02 我們該如何評估上下文窗口大小不斷增加的 LLMs？
擁有超長上下文窗口的模型是近期的發(fā)展趨勢。因此，研究人員正在嘗試開發(fā)新的評估方法，以判斷這些模型的性能。這些評估方法旨在對長上下文模型的能力與局限性進行基準測試，并探討擴展上下文窗口所帶來的利弊。
核心觀點是，擁有更長輸入上下文的模型應(yīng)當能夠完成那些之前難以或無法完成的任務(wù)。
評估場景
本文將探討研究人員考慮用于評估長上下文模型的以下三種方法：
- 從長篇文檔中提取信息
- 對長篇文檔進行深入分析（推理和概括）
- 為即時模型訓練提供上下文學習支持
備注：以上列舉并不全面。如需全面了解長上下文模型的基準測試，請訪問 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 在日益增大的上下文內(nèi)，定位具體信息的能力。
Greg Kamradt[9] 設(shè)計的原始“大海撈針”圖表，用于檢驗 LLMs 在檢索深層次信息方面的能力。通過將這句不協(xié)調(diào)的句子（“針”）置于不同長度的文本片段（“?！保┑母鱾€層級，我們可以評估不同 LLMs 在尋找這些信息時的表現(xiàn)。
“needle in a Haystack”的多種變體
研究人員設(shè)計了幾種不同的測試，以探究信息檢索的各個方面：
- 多“針”測試：在冗長的文檔中散布多個“針”句子（由 Langchain[11] 提出，并在 NeedleBench[12] 中進行實驗）。
- 多模態(tài)搜索：根據(jù)描述，在一堆無關(guān)的圖片中尋找目標圖像。
- 音頻搜索：在長達五天的音頻信號中識別出一段簡短的音頻（該測試在 Gemini 1.5 技術(shù)報告[13]中提出）。在此測試中，一段包含“the secret keyword is needle”這句話的音頻片段，被隱藏在接近五天（107小時）的音頻信號中。
- 視頻搜索：在一部長達 10.5 小時的視頻中，找到含有特定文字的單幀畫面（同樣在 Gemini 1.5 技術(shù)報告[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”方法應(yīng)用廣泛，但它也存在一些局限性：
- 首先，這是一個模擬任務(wù)，可能與現(xiàn)實世界的應(yīng)用場景不符。
- 其次，它僅評估信息的查找能力，而不涉及邏輯推理或理解能力。
- 再者，隨著上下文范圍的擴大，對所有可能的“?！贝笮『汀搬槨蔽恢玫慕M合進行評估，其成本將越來越高。
盡管存在這些缺陷，該測試卻凸顯了長上下文模型的一項重要功能：即能從海量數(shù)據(jù)中迅速搜尋和提取信息。這一功能的重要性不容小覷，它不僅能提升研究效率，還能達到前所未有的數(shù)據(jù)分析水平——甚至可能用于監(jiān)控。
值得注意的是，這種信息檢索方式與檢索增強生成（RAG）不同，它是在一個連貫的大型上下文中進行，而不是從外部資源中提取信息。
2.2 對長篇文檔進行深入分析（推理和概括）
盡管" Needle in a Haystack "測試主要關(guān)注信息檢索能力，但還有其他評估方法用于檢測大語言模型在處理長篇內(nèi)容時的推理、解讀和綜合信息的能力。這些評估方法旨在檢驗?zāi)Ｐ褪欠衲軌蜻M行更高級的推理，而不僅僅是尋找數(shù)據(jù)的具體位置。
以下是屬于此類的幾種評估方法：
文學問答任務(wù)
書籍是長篇文檔的經(jīng)典例子。NOVELQA[14] 這樣的基準測試就是用來評估模型處理文學小說的能力，文檔長度可達 200K 個 tokens。這個測試包含了針對 88 本英語小說的問題（這些問題由人類編寫），涵蓋了公版書和受版權(quán)保護的作品。其他數(shù)據(jù)集，比如NoCha[15]，也采取了相似的評估方式。
在這里插入圖片描述
插圖說明：這張圖表展示了來自 NovelQA 數(shù)據(jù)集[14]的兩個示例問題，這些示例取自《NovelQA: Benchmarking Question Answering on Documents Exceeding 200K Tokens》[14]一文。
在含有隱蔽相關(guān)信息的長篇文章中進行邏輯推理
FlenQA[16] 通過將相關(guān)信息嵌入到較長的非相關(guān)信息中，生成了多個不同長度的上下文版本。這種方法有助于我們了解，隨著上下文長度的增加，大語言模型的處理能力如何逐步下降。
在 FlenQA 的一個任務(wù)示例中，相關(guān)信息（以深紅色表示）被穿插在大量無關(guān)信息之中。此圖表摘自《Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models》[16]一文。
針對特定領(lǐng)域的邏輯推理
- 醫(yī)療領(lǐng)域：LongHealth[17] 基準測試采用了 20 個虛構(gòu)的病例（每個病例包含 5-7 千字），以此來評估模型在醫(yī)學推理方面的能力。
- 金融領(lǐng)域：DocFinQA[18] 則通過讓模型處理長達 150 頁的金融文檔（包含超過 100K 個 tokens）來對其進行挑戰(zhàn)。
總結(jié)摘要任務(wù)
對于大語言模型而言，能夠有效地壓縮長篇文檔的內(nèi)容是一項至關(guān)重要的能力，因為它可以讓用戶在不閱讀全部內(nèi)容的情況下，快速掌握大量文本中的關(guān)鍵信息。這一點在研究領(lǐng)域、商業(yè)分析和法律實踐中尤為重要，這些領(lǐng)域的專家經(jīng)常需要將大量資料精煉為簡潔的報告。
但是，如何評價總結(jié)摘要的質(zhì)量是一項復(fù)雜的任務(wù)。總結(jié)摘要不僅要求對全文有深刻的理解，還要求能夠精準地識別并整合關(guān)鍵信息。 什么樣的總結(jié)摘要算是優(yōu)質(zhì)，往往取決于個人主觀判斷和具體上下文。
目前，總結(jié)摘要質(zhì)量的評估多依賴于將模型的輸出與人工編寫的總結(jié)摘要進行對比，這種方法并不完美，可能無法涵蓋所有合理的總結(jié)摘要方式，也可能會忽略那些用詞不同但含義準確的總結(jié)摘要。
為了應(yīng)對這些挑戰(zhàn)，LongBench[19] 和 ∞Bench[20] 等基準測試應(yīng)運而生。LongBench 涵蓋了多種文檔類型（如政府報告、會議紀要、新聞報道）的摘要任務(wù)，文檔長度可達 15K 字；而 ∞Bench 則進一步拓展了摘要任務(wù)的挑戰(zhàn)邊界，包含長度可達 100K 個 tokens 的文檔。盡管這些基準測試頗具價值，但該領(lǐng)域仍在探索更為有效的評估方法，以便更精準地評價高質(zhì)量總結(jié)摘要的細微差別。
若想深入了解這一主題，可以查閱《An Empirical Survey on Long Document Summarization: Datasets, Models, and Metrics》[21]這一文章。
2.3 為即時模型訓練提供上下文學習支持
長上下文模型最酷的應(yīng)用之一便是在上下文學習（ICL）方面的增強能力。ICL 技術(shù)使得模型能夠即時從提示詞中的示例中學會處理新任務(wù)。得益于更大的上下文窗口，我們現(xiàn)在能夠納入成百上千的訓練樣本，甚至是那些復(fù)雜且篇幅較長的任務(wù)，比如文本摘要。
這項技術(shù)改變了游戲規(guī)則。它讓開發(fā)人員可以跳過針對特定領(lǐng)域的模型微調(diào)，直接通過 ICL 讓模型迅速適應(yīng)新任務(wù)。
Many-shot ICL
DeepMind 針對多樣本 ICL[22] 的研究表明，當提示詞中包含更多示例時，模型在不同任務(wù)上的表現(xiàn)有顯著提升。通過擴充到成百上千的示例，模型能夠克服預(yù)訓練中的偏見，并處理更為復(fù)雜的問題。
通過在提示詞中增加更多的示例（即“shots”），相同的 LLM 模型在多種任務(wù)上都能展現(xiàn)出更好的性能。例如，將情感分析任務(wù)的示例從 32 個增加到 2048 個，模型的表現(xiàn)提升了 18.2 %。此圖摘自《Many-Shot In-Context Learning》[22]。
這一理念不僅僅局限于性能提升。Anthropic 公司在其“Many-shot Jailbreaking”[23]項目中的研究發(fā)現(xiàn)，雖然僅憑幾個樣本無法突破模型的安全防線，但是如果有數(shù)百個樣本，就能做到這一點——這一發(fā)現(xiàn)既展示了這種方法的威力，也揭示了其潛在的風險。
例如，我們可以看到，僅僅幾個樣本是無法誘導(dǎo) LLM 生成有害內(nèi)容的，但是當樣本數(shù)量增加到數(shù)十個甚至數(shù)百個時，就能讓模型忽視其“安全圍欄”。此圖來自于《Many-Shot Jailbreaking》[23]。
翻譯低資源語言
在低資源語言的翻譯方面，長上下文模型展現(xiàn)出了非凡的價值。在 Gemini 1.5 的技術(shù)報告[13]中，以 Kalamang 語為例，這種語言的使用者不足200人，網(wǎng)絡(luò)資源也非常有限。通過向模型輸入 500 頁的語法資料、一個包含 2000 個詞條的雙語詞匯表以及 400 個對照句子（總共 250 k個 tokens），模型不僅能翻譯 Kalamang 語，還能進行語音轉(zhuǎn)錄。
這種方法同樣適用于其他低資源語言，并且隨著示例數(shù)量的增加，翻譯性能也在不斷提升。對于瀕危語言的保護和使用來說，這無疑是一個充滿希望的新進展。
03 Discussion
對于更長上下文窗口的追求正在語言模型領(lǐng)域掀起一場激烈的競賽，上下文窗口的規(guī)模正以驚人的速度擴張。這種擴張迫使我們需要開發(fā)新的評估手段，以便更準確地把握這些模型的實力與短板。
盡管已經(jīng)涌現(xiàn)出了一批針對長上下文模型的評估基準（如 SCROLLS[24]、LongBench[19]、∞BENCH[20]等），但仍有許多疑問尚待解答：
- 規(guī)模的權(quán)衡：當上下文長度不斷增加時，模型在安全性、偏見和指令執(zhí)行方面的表現(xiàn)會如何波動？
- 多語種表現(xiàn)：大多數(shù)評估基準都著眼于英語（CLongEval[25] 等評估基準除外，其中也涵蓋了中文的評估）。那么，對于非英語系的語言，隨著上下文的增加，其表現(xiàn)又會與英語有何不同？
- 性能衰退：模型在處理更豐富上下文的同時，是否會犧牲掉某些特定能力，比如編程技能或是創(chuàng)造力？
- 現(xiàn)實影響：當模型能夠處理整本書籍、完整個人經(jīng)歷，甚至是稀缺語言的詳盡數(shù)據(jù)時，我們將面臨哪些倫理和現(xiàn)實層面的挑戰(zhàn)？
隨著大語言模型（LLMs）的上下文窗口不斷擴大，我們不僅要了解它們能做到什么，還要探究它們的基本特性可能會如何變化。
目前來看，這場追逐更大上下文窗口模型的競賽還將持續(xù)升溫。
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
本期互動內(nèi)容 ??
? #技術(shù)探討# 你認為評估長上下文模型最重要的指標是什么？為什么？
??文中鏈接??
[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/??
[6]??https://www.notion.so/Long-Context-Eval-Survey-fe3c69173f2e4eb0b5cd4c973f712626?pvs=21??
[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??
[24]??https://arxiv.org/abs/2201.03533??
[25]??https://arxiv.org/abs/2403.03514??
原文鏈接：
