拯救被「掰彎」的GPT-4！西交微軟北大聯(lián)合提出IN2訓練治療LLM「中間迷失」

　　近日，西交微軟北大聯(lián)合提出信息密集型訓練大法，使用純數(shù)據(jù)驅動的方式，矯正LLM訓練過程產生的偏見，在一定程度上治療了大語言模型丟失中間信息的問題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Lost in the Middle

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

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

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

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

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

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

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

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

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

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

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

　　信息密集型訓練大法

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

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

　　上圖包含兩種類型的問答對:(1)對長上下文中細粒度信息的掌握;(2)對長上下文中不同位置出現(xiàn)的信息進行整合和推理。

　　細粒度信息感知

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

　　信息整合和推理

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

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

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

　　訓練

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

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

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

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

　　VAL 探測

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

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

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

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

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

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

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

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

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

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