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

近期的一些語言模型有能力輸入較長的上下文，但它究竟能多好地利用更長的上下文？這一點卻相對少有人知。

近日，斯坦福大學、加州大學伯克利分校和 Samaya AI 的研究者發布了一篇實證研究論文，探究了這個問題。

結論令人意外：如果上下文太長，語言模型會更關注其中的前后部分，中間部分卻幾乎被略過不看，導致模型難以找到放在輸入上下文中部的相關信息。

圖片

論文鏈接：https://arxiv.org/pdf/2307.03172.pdf

他們對多種不同的開源（MPT-30B-Instruct、LongChat-13B (16K)）和閉源（OpenAI 的 GPT-3.5-Turbo 和 Anthropic 的 Claude）的語言模型進行了對照實驗 —— 實驗中需要模型獲取并使用輸入上下文中的信息。

研究者首先實驗了多文檔問答，該任務需要模型基于多個文檔進行推理，以找到相關信息并將其用于回答給定問題。這個任務模擬了檢索增強式生成任務，其是許多商用生成式搜索和問答應用（如 Bing Chat）的基礎。在實驗中，他們的做法是改變輸入上下文長度和輸入上下文中相關信息的位置，然后對照比較輸出結果的表現。

更詳細地說，研究者通過向輸入上下文添加更多文檔來增大輸入上下文的長度（類似于在檢索增強式生成任務中檢索更多文檔）；以及通過修改輸入上下文中文檔的順序，將相關信息放置在上下文的開頭、中間或結尾，從而修改上下文中相關信息的位置。

實驗中，研究者觀察到，隨著相關信息位置的變化，模型性能呈現出明顯的 U 型趨勢，如圖 1 所示。也就是說，當相關信息出現在輸入上下文的開頭或末尾時，語言模型的性能最高；而當模型必須獲取和使用的信息位于輸入上下文中部時，模型性能會顯著下降。舉個例子，當相關信息被放置在其輸入上下文中間時，GPT3.5-Turbo 在多文檔問題任務上的性能劣于沒有任何文檔時的情況（即閉卷設置；56.1%）。此外，研究者還發現，當上下文更長時，模型性能會穩步下降；而且配備有上下文擴展的模型并不一定就更善于使用自己的上下文。

圖 1

既然已經知道語言模型在多文檔問答任務中難以檢索和使用相關信息，那么我們不禁要問：語言模型究竟能在多大程度上從輸入上下文中檢索信息？

研究者通過一個合成的鍵 - 值檢索任務研究了這一問題。該任務被設計成一個最小化的測試平臺，用于檢測從輸入上下文中檢索出相匹配的 token 的基本能力。

在此任務中，研究者會向模型提供一個 JSON 格式的「鍵 - 值」對集合，然后要求模型返回與特定鍵關聯的值。與多文檔問答任務相似，鍵 - 值檢索任務也允許對輸入上下文的長度（添加更多鍵 - 值對）和相關信息的位置進行進行對照更改。研究者在實驗中觀察到了類似的 U 型性能曲線，即當匹配的 token 出現在輸入上下文中部時，許多模型就難以檢測出它們。

為了理解語言模型難以獲取和使用輸入上下文中部位置的信息的原因，研究者分析了模型架構（僅解碼器和編碼器 - 解碼器）、查詢感知型上下文化（query-aware contextualization）和指令微調的作用。

他們發現，當評估時的序列長度在訓練時所用的序列長度范圍內時，對于輸入上下文中相關信息位置的變化，編碼器 - 解碼器模型是相對穩健的；但如果評估時的序列長度長于訓練時的，那么模型性能會呈現出 U 型特征。

此外，查詢感知型上下文化（將查詢放在文檔或鍵 - 值對之前和之后）能讓模型可以完美地執行該合成鍵 - 值任務，但基本不會改變多文檔問答任務中呈現的趨勢。還有，甚至是基礎語言模型（即沒有指令微調）也會隨輸入上下文中相關信息的位置變化而呈現出 U 型性能曲線。

最后，為了更好地理解「向輸入上下文添加更多信息」與「增多模型推理所用的內容量」之間的權衡，研究者進行了一個案例研究。該研究基于檢索器 - 閱讀器模型在開放域問答任務上的表現。相較于對照式的多文檔問答任務實驗（上下文總是會包含剛好一個用于問答問題的文檔），在開放域問答任務中，可能會有多個或零個文檔包含答案。

研究者發現，當通過檢索維基百科來回答 NaturalQuestions-Open 中的查詢時，模型性能在檢索器召回率趨于穩定之前很久就已經飽和，這表明模型無法有效地使用額外的檢索文檔 —— 使用超過 20 個檢索文檔僅能略微提高性能（對于 GPT-3.5-Turbo 是 ～1.5%，對于 claude-1.3 為 ～1%）。

整體來說，這份研究能幫助人們更好地理解語言模型是如何使用輸入上下文的，并為未來的長上下文模型引入了新的評估協議。為了促進未來的相關研究，研究者放出了代碼和評估數據，請訪問：https://github.com/nelson-liu/lost-in-the-middle   

為什么語言模型難以完整使用其輸入上下文？

在多文檔問答和鍵 - 值檢索實驗上的結果表明，當語言模型需要從長輸入上下文的中部獲取相關信息時，模型性能會顯著下降。為了理解原因，研究者分析了模型架構（僅解碼器和編碼器 - 解碼器）、查詢感知型上下文化和指令微調的作用。

模型架構的影響

為了更好地理解模型架構的潛在影響，研究者比較了僅解碼器模型和編碼器 - 解碼器語言模型。

實驗中使用的具體模型為 Flan-T5-XXL 和 Flan-UL2。Flan-T5-XXL 的訓練使用了序列長度為 512 token 的序列（編碼器和解碼器）。Flan-UL2 一開始使用 512 token 長度的序列訓練（編碼器和解碼器），但之后又在 1024 token 長度的序列上預訓練了額外 10 萬步（編碼器和解碼器），然后進行了指令微調 —— 其編碼器在 2048 token 長度的序列上微調，解碼器的序列長度則為 512 token。但是，由于這些模型使用相對位置嵌入，因此它們的推斷能力（原則上）可以超出這些最大上下文長度 ——Shaham et al. (2023) 發現當序列長度為 8000 token 時，這兩個模型都能取得不錯的表現。

圖 11 并排展示了僅解碼器模型和編碼器 - 解碼器模型的性能表現。當 Flan-UL2 評估時的序列長度在其訓練時的 2048 token 上下文窗口范圍內時，輸入上下文中相關信息的位置變化能得到穩健的應對。而當評估時的序列長度超過 2048 token 時，如果相關信息位于輸入上下文中部，那么 Flan-UL2 的性能會開始下降。Flan-T5-XXL 展現出的趨勢類似 —— 如果相關信息在輸入上下文中部，那么更長的輸入上下文會導致性能下降更多。

圖 11

研究者推測編碼器 - 解碼器模型也許能更好地利用其上下文窗口，因為它們的雙向編碼器讓它們可以在未來文檔的上下文中處理每個文檔，這或許能提升文檔之間的相對重要性估計。

查詢感知型上下文化的影響

實驗中，研究者的做法是將查詢（即要回答的問題或要檢索的鍵）放在數據（即文檔或鍵 - 值對）之后來處理。由此，當對文檔或鍵 - 值對進行上下文化時，僅解碼器模型無法顧及查詢 token，因為查詢只會出現在 prompt 末尾而僅解碼器模型在每個時間步驟只能關注之前的 token。

另一方面，編碼器 - 解碼器模型使用了雙向編碼器來上下文化輸入上下文，這似乎能更加穩健地應對相關信息的位置變化 —— 研究者猜想這一直觀結論或許也能用于提升僅解碼器模型的性能，做法是將查詢同時放在數據的前面和后面，從而實現文檔或鍵 - 值對的查詢感知型上下文化。

研究者發現，查詢感知型上下文化能極大提升模型在鍵 - 值檢索任務上的表現。舉個例子，當使用 300 個鍵 - 值對進行評估時，GPT-3.5-Turbo (16K)（使用了查詢感知型上下文化）的表現堪稱完美。對比之下，如果沒有查詢感知型上下文化，其在同樣設置下的表現最低為 45.6%。   

圖 12

相比之下，在多文檔問答任務上，查詢感知型上下文化的影響很小。特別指出，當相關信息位于輸入上下文的最開始時，它可以提高性能，但在其他設置中會稍微降低性能。

指令微調的影響

指令微調是指在初始的預訓練之后，語言模型還會使用一個指令和響應數據集進行監督式微調。在這種監督式的指令微調數據中，任務規范和 / 或指令通常放置在輸入上下文的開頭，這可能會導致經過指令微調的語言模型為輸入上下文的開頭賦予更多權重。

為了更好地理解指令微調的潛在影響，研究者比較了 MPT-30B-Instruct 與其基礎模型 MPT-30B（未經指令微調）在多文檔問答任務上的性能表現。

圖 13 展示了 MPT-30B-Instruct 和 MPT-30B 在多文檔問答任務上的性能隨輸入上下文中相關信息的位置的變化。研究者驚訝地發現，MPT-30B-Instruct 和 MPT-30B 都展現出了 U 型趨勢。盡管 MPT-30B-Instruct 的絕對表現優于 MPT-30B，但它們的整體性能趨勢十分相似。

圖 13

其實之前已有研究發現語言模型更偏向于近期的 token（即輸入上下文的末端）。這種對近期 token 的偏好通常表現在預測連續文本的下一個詞的語境中，此時語言模型只能從長程信息中獲得極少的好處。相比之下，這里的實驗結果表明，當 prompt 是指令格式的數據時，語言模型能夠使用更長程的信息（即輸入上下文的開頭）。研究者猜想語言模型是從相似格式的數據中學習了這些上下文，而這些數據來自預訓練時見過的網絡文本。

上下文更多就總是更好嗎？一個基于開放域問答的案例研究

在實踐中，在輸入上下文長度方面往往存在一個權衡 —— 如果給經過指令微調的語言模型輸入更多信息，可能有助于其在下游任務上的性能，但也會增加模型需要處理的內容量。就算一個語言模型可以處理 1.6 萬個 token，那么如果真的為其提供這么多 token，那會真的有用嗎？這個問題的答案是：由下游任務決定。因為這取決于所添加上下文的邊際價值以及模型有效使用長輸入上下文的能力。為了更好地理解這一權衡，研究者在 NaturalQuestions-Open 上進行了開放域問答的案例研究。

他們使用的模型采用了標準的檢索器 - 閱讀器設置。一個檢索系統（Contriever，基于 MS-MARCO 微調得到）從 NaturalQuestions-Open 取用一個輸入查詢，然后返回 k 個維基百科文檔。為了在這些檢索到的文檔上調節經過指令微調的語言模型，研究者將它們包含到了 prompt 中。他們評估了檢索器召回率和閱讀器準確度（任何帶注釋的答案是否出現在預測輸出中）隨檢索出的文檔數 k 的變化情況。研究者使用了 NaturalQuestions-Open 的一個子集，其中長答案是一個段落（而不是表格或列表）。

圖 14 給出了開放域問答的實驗結果。可以看到，在檢索器性能趨于穩定之前很久，閱讀器模型的性能就早已飽和，這表明閱讀器沒有有效地使用額外的上下文。使用超過 20 個檢索文檔只能略微提升閱讀器性能（對于 GPT-3.5-Turbo 是 ～1.5%，對于 Claude 為 ～1%），但卻顯著提升了輸入上下文長度（由此延遲和成本都大幅提升）。

圖 14

這些結果表明，如果能有效地對檢索文檔排序（讓相關信息與輸入上下文的起始處更近）或對已排序的列表進行截斷處理（必要時返回更少的文檔），那么也許可以提升基于語言模型的閱讀器使用檢索上下文的能力。