語(yǔ)言模型悄悄偷懶？新研究：?上下文太長(cháng)，模型會(huì )略過(guò)中間不看

語(yǔ)言模型：太長(cháng)我不看。

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

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


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

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