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

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

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

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


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

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