辛辛苦苦給大語言模型輸入了一大堆提示，它卻只記住了開頭和結尾？

這個現象叫做LLM的中間迷失（Lost in the Middle），是大模型當前仍面臨的最大挑戰之一。

畢竟，LLM現在的上下文長度已經沖到了百萬級別，而難以處理中間的信息，會使得LLM在評估大量數據時不再可靠。

Midjourney對于Lost in the Middle的理解

其實，我們人類也有類似「中間迷失」的毛病，心理學上叫「Primacy/recency effect」，感興趣的讀者可以參見：

??https://www.sciencedirect.com/topics/psychology/recency-effect??

「我怕零點的鐘聲太響......后面忘了」

不過就在不久前，來自西交、微軟和北大的研究人員，開發了一種純粹的數據驅動解決方案，來治療LLM丟失中間信息的癥狀：

論文地址：https://arxiv.org/pdf/2404.16811

研究人員認為，Lost in the Middle的原因是訓練數據中的無意偏差。

因為LLM的預訓練側重于根據最近的一些token預測下一個token，而在微調過程中，真正的指令又往往位于上下文開始的位置。

這在不知不覺中引入了一種立場偏見，讓LLM認為重要信息總是位于上下文的開頭和結尾。

基于這樣的見解，研究人員提出了信息密集型（INformation-INtensive，IN2）訓練方法，來建立數據之間的橋梁。

既然是訓練過程造成的偏見，那么就用訓練數據來解決。

IN2訓練使用合成問答數據，向模型顯式指出重要信息可以位于上下文中的任何位置。

整個上下文長度（4K-32K個token），被分為許多128個token的片段，而答案所對應的信息位于隨機位置的片段中。

研究人員使用了兩種類型的訓練問題：一種是要求在一個片段中提供細節，另一種是需要整合和推斷來自多個片段的信息。

IN2訓練到底效果如何？使用明星模型Mistral-7B來試試。

將IN2訓練應用于Mistral-7B，得到了新模型FILM-7B（FILl-in-the-Middle），然后測試為長上下文設計的三個新的提取任務。

測試任務涵蓋不同的上下文類型（文檔、代碼、結構化數據）和搜索模式（向前、向后、雙向）。

結果表明，IN2顯著降低了原始Mistral模型的「中間丟失」問題。更厲害的是，作為只有7B的模型，FILM的性能在很多情況下甚至超越了GPT-4 Turbo。

在保持自己執行短上下文任務能力的同時，FILM-7B在各種長上下文任務中也表現出色，例如總結長文本，回答有關長文檔的問題，以及對多個文檔的推理。

上表是不同模型在現實的長上下文任務中的表現。與本體Mistral-7B 相比，INformation-INtensive （IN2） 訓練帶來的提升很明顯，FILM-7B的綜合成績僅次于GPT-4 Turbo。

不過有一說一，Lost in the Middle的問題并沒有完全解決，而且在長上下文存在問題的情況下，GPT-4 Turbo也仍然是上下文基準中最強的模型。

Lost in the Middle

LLM丟失中間信息的問題最早由斯坦福、UC伯克利和Samaya AI的研究人員在去年發現。

論文地址：https://arxiv.org/pdf/2307.03172

當面對較長的信息流時，人類傾向于記住開頭和結尾，中間的內容更容易被忽視。

沒想到LLM也學會了這個套路：對于從輸入中檢索信息的任務，當信息位于輸入的開頭或結尾時，模型的表現最好。

但是，當相關信息位于輸入的中間時，性能會顯著下降。尤其是在回答需要從多個文檔中提取信息的問題時，性能下降尤為明顯。

——真是干啥啥不行，偷懶第一名。

模型必須同時處理的輸入越多，其性能往往越差。——而在實際得應用場景中，往往就是需要LLM同時均勻地處理大量信息。

另外，研究結果還表明，大型語言模型使用額外信息的效率是有限的，具有特別詳細指令的「大型提示」可能弊大于利。

對于許多長上下文LLM，中間信息丟失的現象普遍存在。上表測試了當時市面上流行的各種款式LLM，包括GPT-4，一共是七種。

可以看出，不論是開源還是閉源模型的強者，測試結果都顯示出明顯的U形曲線，說明都是在兩頭效果好，而中間就拉跨了。

即使強如GPT-4，也難逃被「掰彎」的命運。

這也不禁讓人質疑：你們這些卷超長上下文的模型到底有沒有用啊？不但吃得多，中間信息也記不住。

信息密集型訓練大法

為了明確教導模型，在長上下文中的任何位置都可以包含關鍵信息。研究人員構建了一個長上下文問答訓練數據集 D = {L，q，a}，其中問題q的答案a，來自長上下文L中的隨機位置。

下圖展示了整個數據構建過程。具體來說，訓練數據D基于通用自然語言語料庫C。給定一個原始文本，首先使用LLM（GPT-4-Turbo）生成一個問答對 （q，a），然后合成一個長上下文 L，其中包括來自C的其他隨機抽樣文本的必要信息。

上圖包含兩種類型的問答對：（1）對長上下文中細粒度信息的掌握；（2）對長上下文中不同位置出現的信息進行整合和推理。

細粒度信息感知

將包含128個token的段視為上下文的最小信息單元。給定一個原始文本C，首先從中隨機提取一個128個token的段s，然后生成q、a和 L：

信息整合和推理

除了利用每個片段之外，研究人員還考慮為兩個或多個片段中包含的信息生成問答對。

按照上面最小信息單元的設置，同樣將全文拆分為一組128個token的段 [s]，然后相應地生成 q、a和L：

使用LLM生成多跳問答對，保證每個問題對應的答案至少需要兩個段內的信息。

訓練

整個訓練數據集包含：1.1M用于細粒度信息感知的長上下文數據（～63%）、300K用于信息整合和推理的長上下文數據（～17%）、150K短上下文問答數據（～9%）和200K通用指令調整數據（～11%）。

使用上面構建的訓練數據，研究人員對Mistral-7B-Instruct-v0.2執行 IN2訓練：將長上下文和問題作為指令，并使用答案部分的損失來更新模型。

超參數：將全局批處理大小設置為128，使用余弦學習率衰減，最大值為1e-6。

模型訓練在16個80G A100 GPU上進行，采用由pytorch FSDP實現的完整分片策略和cpu卸載策略，整個訓練過程耗時大約18天。

VAL 探測

研究人員提出了VAL探測方法，作為評估語言模型上下文性能的更合適的方法，涵蓋了不同的上下文風格和檢索模式，以進行更徹底的評估。

下圖表示VAL探測中的三個任務。檢索模式由檢索關鍵字與要檢索的信息之間的相對位置決定。

這里考慮了三種上下文樣式（文檔、代碼和結構化數據上下文）和三種檢索模式（前向、后向和雙向檢索）。

VAL探測中的每個上下文都包含約32K個token，每個任務包含約3K個示例。

文檔句子檢索（雙向）：上下文由許多自然語言句子組成，目的是檢索包含給定片段的單個句子。這些句子是從arXiv上的論文摘要中抽取的。

此任務遵循雙向檢索模式，因為預期的檢索結果包含上下文中給定片段之前和之后的單詞。評估指標是單詞級別的召回率分數。

代碼函數檢索（向后）：上下文由Python函數組成，目的是檢索函數定義中給定代碼行的函數名稱。原始代碼函數是從StarCoder數據集中采樣的，并為每個函數隨機選擇三行定義。

此任務遵循向后檢索模式，因為函數名稱始終位于定義之前。評估指標是匹配精度。

數據庫實體檢索（向前）：上下文包含結構化實體列表，每個實體都有三個字段：ID、label和description，目的是檢索給定ID的標簽和說明。這些實體是從維基百科數據中采樣的。

此任務遵循正向檢索模式，因為標簽和說明跟隨ID。以寬松的匹配準確性作為衡量標準：如果響應中的標簽或描述完全匹配，則給出 1 分，否則為0分。

本文轉自 新智元 ，作者：新智元

原文鏈接:??https://mp.weixin.qq.com/s/O0GXiaa3aypMWLJcvyboYA??