語言模型：太長我不看。

大型語言模型大有用處，在設(shè)計 prompt 方面，人們通常建議為語言模型提供詳盡的任務(wù)描述和背景信息。

近期的一些語言模型有能力輸入較長的上下文，但它究竟能多好地利用更長的上下文？這一點卻相對少有人知。
近日，斯坦福大學(xué)、加州大學(xué)伯克利分校和 Samaya AI 的研究者發(fā)布了一篇實證研究論文，探究了這個問題。
結(jié)論令人意外：如果上下文太長，語言模型會更關(guān)注其中的前后部分，中間部分卻幾乎被略過不看，導(dǎo)致模型難以找到放在輸入上下文中部的相關(guān)信息。


論文鏈接：https://arxiv.org/pdf/2307.03172.pdf
他們對多種不同的開源（MPT-30B-Instruct、LongChat-13B (16K)）和閉源（OpenAI 的 GPT-3.5-Turbo 和 Anthropic 的 Claude）的語言模型進(jìn)行了對照實驗 —— 實驗中需要模型獲取并使用輸入上下文中的信息。
研究者首先實驗了多文檔問答，該任務(wù)需要模型基于多個文檔進(jìn)行推理，以找到相關(guān)信息并將其用于回答給定問題。這個任務(wù)模擬了檢索增強(qiáng)式生成任務(wù)，其是許多商用生成式搜索和問答應(yīng)用（如 Bing Chat）的基礎(chǔ)。在實驗中，他們的做法是改變輸入上下文長度和輸入上下文中相關(guān)信息的位置，然后對照比較輸出結(jié)果的表現(xiàn)。
更詳細(xì)地說，研究者通過向輸入上下文添加更多文檔來增大輸入上下文的長度（類似于在檢索增強(qiáng)式生成任務(wù)中檢索更多文檔）；以及通過修改輸入上下文中文檔的順序，將相關(guān)信息放置在上下文的開頭、中間或結(jié)尾，從而修改上下文中相關(guān)信息的位置。
實驗中，研究者觀察到，隨著相關(guān)信息位置的變化，模型性能呈現(xiàn)出明顯的 U 型趨勢，如圖 1 所示。也就是說，當(dāng)相關(guān)信息出現(xiàn)在輸入上下文的開頭或末尾時，語言模型的性能最高；而當(dāng)模型必須獲取和使用的信息位于輸入上下文中部時，模型性能會顯著下降。舉個例子，當(dāng)相關(guān)信息被放置在其輸入上下文中間時，GPT3.5-Turbo 在多文檔問題任務(wù)上的性能劣于沒有任何文檔時的情況（即閉卷設(shè)置；56.1%）。此外，研究者還發(fā)現(xiàn)，當(dāng)上下文更長時，模型性能會穩(wěn)步下降；而且配備有上下文擴(kuò)展的模型并不一定就更善于使用自己的上下文。 
圖 1
既然已經(jīng)知道語言模型在多文檔問答任務(wù)中難以檢索和使用相關(guān)信息，那么我們不禁要問：語言模型究竟能在多大程度上從輸入上下文中檢索信息？
研究者通過一個合成的鍵 - 值檢索任務(wù)研究了這一問題。該任務(wù)被設(shè)計成一個最小化的測試平臺，用于檢測從輸入上下文中檢索出相匹配的 token 的基本能力。
在此任務(wù)中，研究者會向模型提供一個 JSON 格式的「鍵 - 值」對集合，然后要求模型返回與特定鍵關(guān)聯(lián)的值。與多文檔問答任務(wù)相似，鍵 - 值檢索任務(wù)也允許對輸入上下文的長度（添加更多鍵 - 值對）和相關(guān)信息的位置進(jìn)行進(jìn)行對照更改。研究者在實驗中觀察到了類似的 U 型性能曲線，即當(dāng)匹配的 token 出現(xiàn)在輸入上下文中部時，許多模型就難以檢測出它們。
為了理解語言模型難以獲取和使用輸入上下文中部位置的信息的原因，研究者分析了模型架構(gòu)（僅****和編碼器 - ****）、查詢感知型上下文化（query-aware contextualization）和指令微調(diào)的作用。
他們發(fā)現(xiàn)，當(dāng)評估時的序列長度在訓(xùn)練時所用的序列長度范圍內(nèi)時，對于輸入上下文中相關(guān)信息位置的變化，編碼器 - ****模型是相對穩(wěn)健的；但如果評估時的序列長度長于訓(xùn)練時的，那么模型性能會呈現(xiàn)出 U 型特征。
此外，查詢感知型上下文化（將查詢放在文檔或鍵 - 值對之前和之后）能讓模型可以完美地執(zhí)行該合成鍵 - 值任務(wù)，但基本不會改變多文檔問答任務(wù)中呈現(xiàn)的趨勢。還有，甚至是基礎(chǔ)語言模型（即沒有指令微調(diào)）也會隨輸入上下文中相關(guān)信息的位置變化而呈現(xiàn)出 U 型性能曲線。
最后，為了更好地理解「向輸入上下文添加更多信息」與「增多模型推理所用的內(nèi)容量」之間的權(quán)衡，研究者進(jìn)行了一個案例研究。該研究基于檢索器 - 閱讀器模型在開放域問答任務(wù)上的表現(xiàn)。相較于對照式的多文檔問答任務(wù)實驗（上下文總是會包含剛好一個用于問答問題的文檔），在開放域問答任務(wù)中，可能會有多個或零個文檔包含答案。
研究者發(fā)現(xiàn)，當(dāng)通過檢索維基百科來回答 NaturalQuestions-Open 中的查詢時，模型性能在檢索器召回率趨于穩(wěn)定之前很久就已經(jīng)飽和，這表明模型無法有效地使用額外的檢索文檔 —— 使用超過 20 個檢索文檔僅能略微提高性能（對于 GPT-3.5-Turbo 是 ～1.5%，對于 claude-1.3 為 ～1%）。
整體來說，這份研究能幫助人們更好地理解語言模型是如何使用輸入上下文的，并為未來的長上下文模型引入了新的評估協(xié)議。為了促進(jìn)未來的相關(guān)研究，研究者放出了代碼和評估數(shù)據(jù)，請訪問：https://github.com/nelson-liu/lost-in-the-middle   
為什么語言模型難以完整使用其輸入上下文？
在多文檔問答和鍵 - 值檢索實驗上的結(jié)果表明，當(dāng)語言模型需要從長輸入上下文的中部獲取相關(guān)信息時，模型性能會顯著下降。為了理解原因，研究者分析了模型架構(gòu)（僅****和編碼器 - ****）、查詢感知型上下文化和指令微調(diào)的作用。
模型架構(gòu)的影響
為了更好地理解模型架構(gòu)的潛在影響，研究者比較了僅****模型和編碼器 - ****語言模型。
實驗中使用的具體模型為 Flan-T5-XXL 和 Flan-UL2。Flan-T5-XXL 的訓(xùn)練使用了序列長度為 512 token 的序列（編碼器和****）。Flan-UL2 一開始使用 512 token 長度的序列訓(xùn)練（編碼器和****），但之后又在 1024 token 長度的序列上預(yù)訓(xùn)練了額外 10 萬步（編碼器和****），然后進(jìn)行了指令微調(diào) —— 其編碼器在 2048 token 長度的序列上微調(diào)，****的序列長度則為 512 token。但是，由于這些模型使用相對位置嵌入，因此它們的推斷能力（原則上）可以超出這些最大上下文長度 ——Shaham et al. (2023) 發(fā)現(xiàn)當(dāng)序列長度為 8000 token 時，這兩個模型都能取得不錯的表現(xiàn)。
圖 11 并排展示了僅****模型和編碼器 - ****模型的性能表現(xiàn)。當(dāng) Flan-UL2 評估時的序列長度在其訓(xùn)練時的 2048 token 上下文窗口范圍內(nèi)時，輸入上下文中相關(guān)信息的位置變化能得到穩(wěn)健的應(yīng)對。而當(dāng)評估時的序列長度超過 2048 token 時，如果相關(guān)信息位于輸入上下文中部，那么 Flan-UL2 的性能會開始下降。Flan-T5-XXL 展現(xiàn)出的趨勢類似 —— 如果相關(guān)信息在輸入上下文中部，那么更長的輸入上下文會導(dǎo)致性能下降更多。  
圖 11
研究者推測編碼器 - ****模型也許能更好地利用其上下文窗口，因為它們的雙向編碼器讓它們可以在未來文檔的上下文中處理每個文檔，這或許能提升文檔之間的相對重要性估計。
查詢感知型上下文化的影響
實驗中，研究者的做法是將查詢（即要回答的問題或要檢索的鍵）放在數(shù)據(jù)（即文檔或鍵 - 值對）之后來處理。由此，當(dāng)對文檔或鍵 - 值對進(jìn)行上下文化時，僅****模型無法顧及查詢 token，因為查詢只會出現(xiàn)在 prompt 末尾而僅****模型在每個時間步驟只能關(guān)注之前的 token。
另一方面，編碼器 - ****模型使用了雙向編碼器來上下文化輸入上下文，這似乎能更加穩(wěn)健地應(yīng)對相關(guān)信息的位置變化 —— 研究者猜想這一直觀結(jié)論或許也能用于提升僅****模型的性能，做法是將查詢同時放在數(shù)據(jù)的前面和后面，從而實現(xiàn)文檔或鍵 - 值對的查詢感知型上下文化。
研究者發(fā)現(xiàn)，查詢感知型上下文化能極大提升模型在鍵 - 值檢索任務(wù)上的表現(xiàn)。舉個例子，當(dāng)使用 300 個鍵 - 值對進(jìn)行評估時，GPT-3.5-Turbo (16K)（使用了查詢感知型上下文化）的表現(xiàn)堪稱完美。對比之下，如果沒有查詢感知型上下文化，其在同樣設(shè)置下的表現(xiàn)最低為 45.6%。     
圖 12
相比之下，在多文檔問答任務(wù)上，查詢感知型上下文化的影響很小。特別指出，當(dāng)相關(guān)信息位于輸入上下文的最開始時，它可以提高性能，但在其他設(shè)置中會稍微降低性能。
指令微調(diào)的影響
指令微調(diào)是指在初始的預(yù)訓(xùn)練之后，語言模型還會使用一個指令和響應(yīng)數(shù)據(jù)集進(jìn)行監(jiān)督式微調(diào)。在這種監(jiān)督式的指令微調(diào)數(shù)據(jù)中，任務(wù)規(guī)范和 / 或指令通常放置在輸入上下文的開頭，這可能會導(dǎo)致經(jīng)過指令微調(diào)的語言模型為輸入上下文的開頭賦予更多權(quán)重。
為了更好地理解指令微調(diào)的潛在影響，研究者比較了 MPT-30B-Instruct 與其基礎(chǔ)模型 MPT-30B（未經(jīng)指令微調(diào)）在多文檔問答任務(wù)上的性能表現(xiàn)。
圖 13 展示了 MPT-30B-Instruct 和 MPT-30B 在多文檔問答任務(wù)上的性能隨輸入上下文中相關(guān)信息的位置的變化。研究者驚訝地發(fā)現(xiàn)，MPT-30B-Instruct 和 MPT-30B 都展現(xiàn)出了 U 型趨勢。盡管 MPT-30B-Instruct 的絕對表現(xiàn)優(yōu)于 MPT-30B，但它們的整體性能趨勢十分相似。
圖 13

其實之前已有研究發(fā)現(xiàn)語言模型更偏向于近期的 token（即輸入上下文的末端）。這種對近期 token 的偏好通常表現(xiàn)在預(yù)測連續(xù)文本的下一個詞的語境中，此時語言模型只能從長程信息中獲得極少的好處。相比之下，這里的實驗結(jié)果表明，當(dāng) prompt 是指令格式的數(shù)據(jù)時，語言模型能夠使用更長程的信息（即輸入上下文的開頭）。研究者猜想語言模型是從相似格式的數(shù)據(jù)中學(xué)習(xí)了這些上下文，而這些數(shù)據(jù)來自預(yù)訓(xùn)練時見過的網(wǎng)絡(luò)文本。
上下文更多就總是更好嗎？一個基于開放域問答的案例研究
在實踐中，在輸入上下文長度方面往往存在一個權(quán)衡 —— 如果給經(jīng)過指令微調(diào)的語言模型輸入更多信息，可能有助于其在下游任務(wù)上的性能，但也會增加模型需要處理的內(nèi)容量。就算一個語言模型可以處理 1.6 萬個 token，那么如果真的為其提供這么多 token，那會真的有用嗎？這個問題的答案是：由下游任務(wù)決定。因為這取決于所添加上下文的邊際價值以及模型有效使用長輸入上下文的能力。為了更好地理解這一權(quán)衡，研究者在 NaturalQuestions-Open 上進(jìn)行了開放域問答的案例研究。
他們使用的模型采用了標(biāo)準(zhǔn)的檢索器 - 閱讀器設(shè)置。一個檢索系統(tǒng)（Contriever，基于 MS-MARCO 微調(diào)得到）從 NaturalQuestions-Open 取用一個輸入查詢，然后返回 k 個維基百科文檔。為了在這些檢索到的文檔上調(diào)節(jié)經(jīng)過指令微調(diào)的語言模型，研究者將它們包含到了 prompt 中。他們評估了檢索器召回率和閱讀器準(zhǔn)確度（任何帶注釋的答案是否出現(xiàn)在預(yù)測輸出中）隨檢索出的文檔數(shù) k 的變化情況。研究者使用了 NaturalQuestions-Open 的一個子集，其中長答案是一個段落（而不是表格或列表）。
圖 14 給出了開放域問答的實驗結(jié)果。可以看到，在檢索器性能趨于穩(wěn)定之前很久，閱讀器模型的性能就早已飽和，這表明閱讀器沒有有效地使用額外的上下文。使用超過 20 個檢索文檔只能略微提升閱讀器性能（對于 GPT-3.5-Turbo 是 ～1.5%，對于 Claude 為 ～1%），但卻顯著提升了輸入上下文長度（由此延遲和成本都大幅提升）。
圖 14
這些結(jié)果表明，如果能有效地對檢索文檔排序（讓相關(guān)信息與輸入上下文的起始處更近）或?qū)σ雅判虻牧斜磉M(jìn)行截斷處理（必要時返回更少的文檔），那么也許可以提升基于語言模型的閱讀器使用檢索上下文的能力。