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

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

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

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

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

圖片

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

圖片

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

具體而言，作者指出當相關信息出現在輸入上下文的開頭或結尾時，性能通常最好，但當模型需要在長篇上下文的中間獲取相關信息時，性能明顯降低。

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

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

圖片

值得一提的是，知名科技媒體網站VentureBeat也報道了這篇論文，并咨詢了一些專家，表示，向量數據庫可能是破局的關鍵。

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

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

同時Nelson Liu也提到這篇論文并不是在說將整篇文檔塞進大模型的上下文窗口，就一定表現不好。其實，結果取決于文檔所包含的具體內容，大模型在區分“關系密切的內容”時，表現不佳。當各部分內容不相關（相互獨立）的時候，大模型非常擅長“準確定位”。

編者注：向量數據庫的核心思想是將文本轉換成向量，然后將向量存儲在數據庫中，當用戶輸入問題時，將問題轉換成向量，然后在數據庫中搜索最相似的向量和上下文，最后將文本返回給用戶。

論文細節

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

首先進行了多文檔問題回答的實驗。該任務的目標是讓模型對文檔進行推理，找到并使用相關信息來回答給定的問題。

在實驗中，對輸入上下文的大小以及輸入上下文中的相關信息位置進行了有控制的調整。

圖片

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

甚至，在相關信息被放在輸入上下文的中間位置時，GPT-3.5-Turbo在多文檔問題回答任務上的表現不如別提供文檔。

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

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

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

結果顯示：仍然是U形性能曲線。

多文檔問答

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

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

圖片

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

具體測驗中，作者利用NaturalQuestions基準測試的數據，創建了這一任務的實例。其中，使用的查詢來自于NaturalQuestions-Open，并從維基百科抽取段落（即不超過100個Token的文本塊）作為輸入上下文中的文檔。

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

最后，將準確度作為主要的評價標準，以此來判斷預測輸出中是否出現了正確的答案。

圖片

前期準備工作完畢，作者對當前幾個“最能打”的大模型進行了測驗。從上圖可以看出，這些模型都展示出了U形性能。

圖片

如上圖所示，隨著輸入上下文的增長，模型的表現有明顯的下滑。無論哪一個任務，隨著上下文擴展，模型的功能都會表現出退化。

鍵值檢索任務

鍵值檢索任務能夠測驗大模型從輸入上下文直接獲取信息的能力。鍵值檢索任務中，輸入是含k對鍵值的JSON對象及一特定鍵，目標是返回該鍵關聯的值。

圖片

因此，每個JSON對象都包含一個關聯的鍵值對（需要檢索的值），和k-1個不相關的“干擾”鍵值對。上圖展示了鍵值檢索任務輸入內容和其對應的預期輸出。

該任務中，可通過增加或減少隨機鍵來改變JSON鍵值對的數量，這樣就改變了輸入的長度；同時也會調整輸入中相關的正確信息的位置。

圖片

含有75、140和300個鍵值對的測試

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

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

為什么會出現這種問題？

為深入洞察其原因，作者初步研究了模型構架，答案在上下文中位置，和指令調優起到的作用。

圖片

在模型架構層面，論文比較了only解碼器和編碼-解碼兩類模型，結論是：相比于only解碼器的語言模型,編碼器-解碼器結構的語言模型在上下文窗口方面較為穩健。但當模型處理超過其在訓練時使用的最大序列長度時,編碼器-解碼器模型也會出現U形曲線。

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

最后，作者發現基礎語言模型在沒有指令調優的情況下也表現出U形曲線,這表明指令調優過程本身可能不是造成這一性能模式的原因。

換句話說，語言模型在利用中間信息上的困難,其根本原因可能不在于指令調優,這需要我們更深入地研究模型本身的結構及訓練過程。

論文結論

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

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

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

參考文獻：

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/