在語言模型中，上下文窗口對于理解和生成與特定上下文相關(guān)的文本至關(guān)重要。

一般而言較大的上下文窗口可以提供更豐富的語義信息、消除歧義。

由于硬件和算法的最新進(jìn)步，大模型的上下文窗口的長度也越來越“卷”。

其中的卷王當(dāng)屬Anthropic 公司，其五月份就將 Claude 的上下文窗口從 9k token擴(kuò)展到了 100k。

最近更新的Claude 2 更是讓其100K的上下文能力“常駐”模型。

圖片

有大模型“風(fēng)向標(biāo)”之稱ChatGPT也在三月份將GPT-4模型最大上下文窗口達(dá)擴(kuò)至32K；六月份將GPT-3.5-Turbo增加了16k的上下文長度（此前是4k）。

圖片

而斯坦福大學(xué)聯(lián)合加州伯克利大學(xué)以及Samaya的研究員，在一篇題為“中途迷失：語言模型的長·上下文利用之道”中提出：在多文檔問題回答和鍵值檢索，這兩種都需要從輸入的上下文中識(shí)別相關(guān)信息的任務(wù)中，大語言模型會(huì)隨著輸入上下文的長度增加，性能會(huì)顯著下降。

具體而言，作者指出當(dāng)相關(guān)信息出現(xiàn)在輸入上下文的開頭或結(jié)尾時(shí)，性能通常最好，但當(dāng)模型需要在長篇上下文的中間獲取相關(guān)信息時(shí)，性能明顯降低。

換句話說：當(dāng)帶有答案的文字，被放在文章的中間時(shí)候，大語言模型可能無法準(zhǔn)確識(shí)別、理解該答案。

因此，大模型目前越來越卷的上下文窗口長度，可能并不能增加模型的理解能力。

圖片

值得一提的是，知名科技媒體網(wǎng)站VentureBeat也報(bào)道了這篇論文，并咨詢了一些專家，表示，向量數(shù)據(jù)庫可能是破局的關(guān)鍵。

Vector databases like Pinecone help developers increase LLM memory by searching for relevant information to pull into the context window.

這一說法也得到了上述論文的關(guān)鍵作者“Nelson Liu”的認(rèn)可，他表示：如果將整個(gè) PDF 放到語言模型上下文窗口中，然后詢問有關(guān)該文檔的問題，那么使用向量數(shù)據(jù)庫搜索通常會(huì)更有效。

同時(shí)Nelson Liu也提到這篇論文并不是在說將整篇文檔塞進(jìn)大模型的上下文窗口，就一定表現(xiàn)不好。其實(shí)，結(jié)果取決于文檔所包含的具體內(nèi)容，大模型在區(qū)分“關(guān)系密切的內(nèi)容”時(shí)，表現(xiàn)不佳。當(dāng)各部分內(nèi)容不相關(guān)（相互獨(dú)立）的時(shí)候，大模型非常擅長“準(zhǔn)確定位”。

編者注：向量數(shù)據(jù)庫的核心思想是將文本轉(zhuǎn)換成向量，然后將向量存儲(chǔ)在數(shù)據(jù)庫中，當(dāng)用戶輸入問題時(shí)，將問題轉(zhuǎn)換成向量，然后在數(shù)據(jù)庫中搜索最相似的向量和上下文，最后將文本返回給用戶。

論文細(xì)節(jié)

論文對開源和非開源的模型都進(jìn)行了測驗(yàn)，前者包括MPT-30B-Instruct，LongChat-13B（16K）；后者包括OpenAI的GPT-3.5-Turbo和Anthropic的Claude。

首先進(jìn)行了多文檔問題回答的實(shí)驗(yàn)。該任務(wù)的目標(biāo)是讓模型對文檔進(jìn)行推理，找到并使用相關(guān)信息來回答給定的問題。

在實(shí)驗(yàn)中，對輸入上下文的大小以及輸入上下文中的相關(guān)信息位置進(jìn)行了有控制的調(diào)整。

圖片

如上圖所示，當(dāng)改變相關(guān)信息在文檔中的位置時(shí)，模型性能呈現(xiàn)獨(dú)特的U形趨勢，即當(dāng)相關(guān)信息出現(xiàn)在輸入上下文的開頭或結(jié)尾時(shí)，性能通常最好；當(dāng)模型需要在長篇上下文的中間獲取相關(guān)信息時(shí)，性能明顯最低。

甚至，在相關(guān)信息被放在輸入上下文的中間位置時(shí)，GPT-3.5-Turbo在多文檔問題回答任務(wù)上的表現(xiàn)不如別提供文檔。

此外，一些號(hào)稱專門處理長文本的大模型，在這方面表現(xiàn)也不好。

那么，語言模型有多大程度上能從輸入上下文中檢索信息呢？論文作者指定了一個(gè)合成的鍵值檢索任務(wù)來探索該問題。

在這個(gè)任務(wù)中，模型需要處理一組JSON格式的鍵值對，并必須返回與特定鍵相關(guān)聯(lián)的值。類似于多文檔問題回答任務(wù)，鍵值檢索任務(wù)在操作過程中，也對輸入上下文的大小以及輸入上下文中的相關(guān)信息位置進(jìn)行了有控制的調(diào)整。

結(jié)果顯示：仍然是U形性能曲線。

多文檔問答

多文檔問答任務(wù)在很大程度上類似于商業(yè)搜索和問答應(yīng)用（例如，Bing Chat）所采用的檢索增強(qiáng)生成模式。

在這些實(shí)驗(yàn)中，模型的輸入是一個(gè)需要回答的問題，以及k篇文檔（例如，來自維基百科的段落），其中一篇文檔包含了問題的答案，而剩下的k-1篇“干擾”文檔則沒有。

圖片

如上圖所示，要執(zhí)行多文檔問答任務(wù)，模型需要在輸入的上下文中獲取包含答案的文檔，并用它來回答問題。

具體測驗(yàn)中，作者利用NaturalQuestions基準(zhǔn)測試的數(shù)據(jù)，創(chuàng)建了這一任務(wù)的實(shí)例。其中，使用的查詢來自于NaturalQuestions-Open，并從維基百科抽取段落（即不超過100個(gè)Token的文本塊）作為輸入上下文中的文檔。

對于所有這些查詢，需要找到一份包含答案的文檔，并找到k - 1份沒有答案的文檔作為干擾項(xiàng)。前者作者采用NaturalQuestions注釋中含有答案的維基百科段落；后者采用了Contriever檢索系統(tǒng)找出那些最與問題相關(guān)，但并未包含任何NaturalQuestions標(biāo)注答案的k - 1個(gè)維基百科片段。

最后，將準(zhǔn)確度作為主要的評價(jià)標(biāo)準(zhǔn)，以此來判斷預(yù)測輸出中是否出現(xiàn)了正確的答案。

圖片

前期準(zhǔn)備工作完畢，作者對當(dāng)前幾個(gè)“最能打”的大模型進(jìn)行了測驗(yàn)。從上圖可以看出，這些模型都展示出了U形性能。

圖片

如上圖所示，隨著輸入上下文的增長，模型的表現(xiàn)有明顯的下滑。無論哪一個(gè)任務(wù)，隨著上下文擴(kuò)展，模型的功能都會(huì)表現(xiàn)出退化。

鍵值檢索任務(wù)

鍵值檢索任務(wù)能夠測驗(yàn)大模型從輸入上下文直接獲取信息的能力。鍵值檢索任務(wù)中，輸入是含k對鍵值的JSON對象及一特定鍵，目標(biāo)是返回該鍵關(guān)聯(lián)的值。

圖片

因此，每個(gè)JSON對象都包含一個(gè)關(guān)聯(lián)的鍵值對（需要檢索的值），和k-1個(gè)不相關(guān)的“干擾”鍵值對。上圖展示了鍵值檢索任務(wù)輸入內(nèi)容和其對應(yīng)的預(yù)期輸出。

該任務(wù)中，可通過增加或減少隨機(jī)鍵來改變JSON鍵值對的數(shù)量，這樣就改變了輸入的長度；同時(shí)也會(huì)調(diào)整輸入中相關(guān)的正確信息的位置。

圖片

含有75、140和300個(gè)鍵值對的測試

上圖展示了鍵值檢索的表現(xiàn)。結(jié)果顯示雖然鍵值找回任務(wù)僅需找到輸入上下文中的精確匹配，但并非所有模型都表現(xiàn)優(yōu)秀。claude模型在各種長度上都接近完美，但其他模型在檢索大量鍵值對時(shí)遇到了困難。

在鍵值檢索和多文檔問答任務(wù)中，表現(xiàn)出類似的U型曲線。唯一的例外是在鍵值檢索任務(wù)中表現(xiàn)出色的模型（claude）。值得一提的是，LongChat-13B在140鍵值環(huán)境下的表現(xiàn)非常獨(dú)特，它會(huì)生成代碼來提取鍵值，而非直接輸出值。

為什么會(huì)出現(xiàn)這種問題？

為深入洞察其原因，作者初步研究了模型構(gòu)架，答案在上下文中位置，和指令調(diào)優(yōu)起到的作用。

圖片

在模型架構(gòu)層面，論文比較了only解碼器和編碼-解碼兩類模型，結(jié)論是：相比于only解碼器的語言模型,編碼器-解碼器結(jié)構(gòu)的語言模型在上下文窗口方面較為穩(wěn)健。但當(dāng)模型處理超過其在訓(xùn)練時(shí)使用的最大序列長度時(shí),編碼器-解碼器模型也會(huì)出現(xiàn)U形曲線。

另外，更改答案在上下文中的位置，可以完美地提高關(guān)鍵-值檢索任務(wù)的性能,但對多文檔問答任務(wù)的性能趨勢影響不大。

最后，作者發(fā)現(xiàn)基礎(chǔ)語言模型在沒有指令調(diào)優(yōu)的情況下也表現(xiàn)出U形曲線,這表明指令調(diào)優(yōu)過程本身可能不是造成這一性能模式的原因。

換句話說，語言模型在利用中間信息上的困難,其根本原因可能不在于指令調(diào)優(yōu),這需要我們更深入地研究模型本身的結(jié)構(gòu)及訓(xùn)練過程。

論文結(jié)論

提供更多上下文信息并非總是有益的。盡管在某些情況下，向語言模型提供更多的上下文信息可以提高其性能，但是在一定點(diǎn)之后，增加更多的上下文信息可能無法帶來顯著的性能改進(jìn)。

模型優(yōu)先使用開頭和末尾信息。語言模型更容易處理輸入信息的開頭和末尾部分，所以把關(guān)鍵信息放在這些位置或縮短文檔長度可能有助于提升性能。

模型難以利用更長的上下文。僅僅通過增加上下文長度可能無法有效提升語言模型的性能。要真正改善模型處理長上下文的能力，可能需要從模型本身進(jìn)行改進(jìn)，例如改進(jìn)模型的架構(gòu)或者訓(xùn)練策略。

參考文獻(xiàn)：

https://venturebeat.com/ai/stanford-study-challenges-assumptions-about-language-models-larger-context-doesnt-mean-better-understanding/

https://arxiv.org/abs/2307.03172

https://guangzhengli.com/blog/zh/vector-database/