早先發布Vicuna模型和大語言模型排位賽的LMSYS Org（UC伯克利主導）的研究人員又開始搞事情了。

這次，他們開發出了一個支持長上下文的開源大模型家族LongChat-7B和LongChat-13B，支持高達16K token的上下文長度。

但是吧，其實市面上早已出現支持65K（MPT-7B-storyteller）和32K（CHatGLM2-6B）token的選手了。

圖片

抱著一邊向他們虛心學習一邊質疑的研究者心態，他們設計一個專門評估大語言模型處理長上下文任務的性能的工具，測了測一眾號稱支持長上下文的模型們性能到底怎么樣。

不測不知道，一測發現之前宣稱能支持長上下的開源模型幾乎水平都不怎么樣，而自家的LongChat在一眾「開源李鬼」里才是真的李逵。

而商業閉源大模型的長上下文能力，是真的不錯，各個都很能打。

圖片

在長距離主題檢索任務上比較LongChat和其他模型

長上下文「打假」

根據研究人員測試的結果，閉源的商業長上下文模型確實能兌現它們的承諾：gpt-3.5-16k和Anthropic Claude在基準測試中幾乎都達到了完美的性能。

然而，現有的開源模型在長上下文長度方面的表現卻比自己「聲稱」的要差很多。

圖片

大語言模型支持長上下文能力的等級

全新LongChat開源模型，支持16k上下文

LongChat模型不僅可以處理高達16k token的上下文長度，而且還能準確地遵循對話中的人類指令，并在人類偏好基準MT-Bench中展示出強大的性能。

預覽版本可在HuggingFace上獲得：

• lmsys/longchat-13b-16k
• lmsys/longchat-7b-16k

感興趣的同學可以在命令行界面或Web界面中使用FastChat來跑一下試試：

Python
python3 -m fastchat.serve.cli --model-path lmsys/longchat-7b-16k

在研究團隊的LongChat存儲庫中可以找到用于重現研究結果結果的數據和代碼，研究人員還貼心地提供了可視化效果展示。

那么我們來看看LongChat是怎么一步一步從LLaMA的2048個token的上下文長度訓練到16K的。

第一步：壓縮旋轉嵌入（ Rotary embedding）

旋轉位置嵌入是一種將位置信息注入Transformer的位置嵌入方法。

在Hugging Face的Transformer庫中，它的實現方式如下：

Python
query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin, position_ids)

其中position_ids是索引，如1、2、3等，用于表示句子中token的位置。

例如，在句子「today is a good day」中，token「today」的position_ids為1。apply_rotary_pos_emb()函數根據提供的position_ids應用變換。

LLaMA模型使用旋轉嵌入在序列長度2048上進行預訓練的。

這就意味著在預訓練階段就觀察不到position_ids > 2048的情況。

研究團隊沒有強制LLaMA模型適應position_ids > 2048，而是將position_ids > 2048的部分壓縮到0到2048之間。

直觀地說，研究人員假設這種壓縮可以最大程度地重用在預訓練階段學到的模型權重。

他們通過將目標新上下文長度y除以2048來定義壓縮比率。

然后將每個position_ids除以這個比率，并將其輸入apply_rotary_pos_emb()函數。

Python
query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin, position_ids / ratio)

在此版本中，研究人員將模型微調到上下文長度為16384，壓縮率設為8。

例如，把position_ids = 10000的token變為position_ids = 10000 / 8 = 1250，而相鄰的token10001變為10001 / 8 = 1250.125。

這個技術最先由開源社區的一個叫Kaiokendev的開源愛好者發現（https://kaiokendev.github.io/context）并傳播和討論。LMSys Org的研究人員發現這個技術確實很好使，而且這一步只需要改一行代碼，不需要進行訓練。

第二步：微調精選的對話數據庫

在壓縮嵌入之后，研究人員使用他們精心挑選的對話數據集執行微調過程。

研究團隊重新使用了先前用來訓練Vicuna的用戶分享對話數據。

使用FastChat數據處理流程清理數據，截斷了這些對話，使其長度不超過16K。

然后再使用標準下一個token預測損失對模型進行微調。

最后他們分別使用80,000個和18,000個對話對7B和13B模型進行微調。

假設在云上使用A100花費每小時3美元，7B模型的成本約為300美元，而13B模型的成本約為700美元。

上下文能力驗證工具：LongEval

為了驗證商業閉源和開源模型宣傳支持的長上下文能力（從8K、32K到100K）到底有多強，研究團隊開發了一套驗證工具包。

不同的模型作者可能對所謂的「長上下文能力」對有著不同的理解。

舉個例子，MPT-7B-StoryWriter所宣稱的65K上下文長度是否與OpenAI的ChatGPT在16K上下文長度下具有相同的性能？

在LongChat開發過程中，同樣的問題也困擾著研究團隊。

如何迅速有效地確認一個新訓練的模型是否能夠真地有效處理預期的上下文長度？

為了解決這個問題，研究團隊可以基于需要LLM處理長上下文的任務進行評估。

例如文本生成、檢索、摘要和長文本序列中的信息關聯。

受最近的研究啟發，研究人員們設計了一個名為LongEval的長上下文測試套件。

這個套件包括兩個難度不同的任務，提供了一種簡單快捷的方式來衡量和比較長上下文的性能。

任務一：粗粒度主題檢索

在現實世界的長對話中，用戶通常與聊天機器人的討論會在多個主題間跳轉。

研究團隊使用主題檢索任務來模擬這種場景。

這個任務會要求聊天機器人檢索由多個主題組成的長對話中的第一個主題，來模擬這種情景。

示例任務如下：

Python
… (instruction of the task)
USER: I would like to discuss <TOPIC-1>
ASSISTANT: Sure! What about xxx of <TOPIC-1>?
… (a multi-turn conversation of <TOPIC-1>)
USER: I would like to discuss  <TOPIC-2>
…
USER: I would like to discuss <TOPIC-k>
…
USER: What is the first topic we discussed?
ASSISTANT:

這個任務測試模型是否能夠定位長下文中的一段文本并將其與正確的主題名稱相關聯。

研究人員設計了很多個由400到600個token組成的對話，并隨機組合它們達到到想要測試的長度，將組合出來的長文本作為 Prompt.

所以，這是一個粗粒度的對話，因為當模型能夠定位到距離正確位置不太遠（<500個token距離）的位置時，它可能會給出正確的預測。

任務二：細粒度檢索

為了進一步測試模型在長對話中定位和關聯文本的能力，研究人員引入了更精細的行檢索測試（Line Retrieval test）。

在這個測試中，聊天機器人需要精確地從長文檔中檢索一個數字，而不是從長對話中檢索一個主題。

以下是一個示例：

Python
line torpid-kid: REGISTER_CONTENT is <24169>
line moaning-conversation: REGISTER_CONTENT is <10310>
…
line tacit-colonial: REGISTER_CONTENT is <14564>
What is the <REGISTER_CONTENT> in line moaning-conversation?

這個任務最初是在「Little Retrieval Test」中被設計出來的。

原始的測試中，是使用數字來表示一行，但研究人員發現較小的LLM通常無法很好地理解數字。

為了解開這些因素并使其更適合測試不同大小的開源聊天機器人，他們通過使用隨機的自然語言（例如「torpid-kid」）進行改進。

研究人員發現這兩個任務都具有這幾預期的特點：

1. 任務可以有效捕捉到文本生成、檢索和長上下文信息關聯的能力，最終反映在檢索準確性上。

2. 可以輕松將測試擴展到任意長度，以測試模型在不同上下文長度下的能力。

3. 研究人員已經對這兩個任務進行了檢查，并觀察到了預期的結果。

例如，對于使用2K上下文進行預訓練的原始LLaMA模型，在測試輸入長度小于2K時可以實現完美的準確性。

但對于超過2K的測試輸入，準確性幾乎為零。

研究人員通過這個原理，就能檢測不同模型對于不同上下文長度時，執行信息檢索和關聯相關信息的能力。

測評結果

圖片

根據粗粒度的主題檢索測試結果，團隊觀察到開源的長上下文模型的性能似乎沒有自己宣稱得那么好。

例如，Mpt-7b-storywriter聲稱具有84K的上下文長度，但即使在它聲稱的上下文長度的四分之一（16K）處，準確率也僅達到50%。

Chatglm2-6B在長度為6K（46%準確率）時無法可靠地檢索第一個主題。

當在大于10K的上下文長度上進行測試時，其準確率幾乎為0%。

另一方面，研究人員觀察到LongChat-13B-16K模型可靠地檢索到第一個主題，并且準確率與gpt-3.5-turbo相當。

圖片

在更細粒度的行檢索測試中，Mpt-7b-storywriter的表現甚至比粗粒度情況下更差，準確率從約50%下降到約30%。

Chatglm2-6B也出現了下降，在研究人員測試的最短長度（5K上下文長度）上表現也不太好。

相比之下，LongChat-13B-16K表現可靠，在12K的上下文長度內接近gpt-3.5/Anthropic-claude的能力。

解開LongEval中與LLM能力無關的因素

在主題和行檢索測試中，研究人員觀察到一些錯誤是由與長上下文能力無關的因素引起的，比如指令跟隨能力。

例如，在行檢索測試中，模型可能會簡單地回答「當然，我會告訴你這個數字」，而不是按照要求回答實際的數字。

為了進行公平比較，研究人員采取了兩個措施來避免與長上下文能力無關的因素：

1）設計適當的提示詞

2）僅在模型按照研究人員的指令執行的情況下計算準確率。

人類偏好基準（MT-bench）

在前面的部分中，研究人員觀察到LongChat模型在長距離檢索任務上表現良好，但這是否會導致人類偏好顯著下降呢？

為了測試它是否仍然符合人類的偏好，研究人員使用了GPT-4評分的MT-bench，這是一組具有挑戰性的多輪對話問題。

研究人員發現，LongChat-13B-16K與其最接近的替代模型Vicuna-13B相比，確實在MT-Bench分數上略有下降，但在可接受的范圍內，這表明這種長距離能力并沒有顯著犧牲其短距離能力。

同時，LongChat-13B-16K與其他相同規模的模型相比也具有競爭力。

圖片

討論分析

研究人員發現，當上下文長度接近16K時，LongChat-13B-16K在細粒度的行檢索任務上出現了準確率下降的情況。

在他們的初步嘗試中，研究人員猜測這是因為接近最大的微調長度。

例如，使用更大的長度（例如32K）進行訓練可以緩解這個問題。

研究人員正在積極努力解決這個問題，并計劃在不久的將來發布中解決。

研究人員用表格形式定性地說明了性能水平，并且希望提出他們的最終思考：能夠在一個上下文范圍內生成文本，和真正的具備在宣稱的上下文長度上能進行reasoning和檢索，這兩種能力是有很大差距的。

模型提供者通暢需要對模型進行良好的訓練（例如使用高質量的長序列數據，或者像研究人員探索過的進行壓縮），以實現良好的長上下文文本生成、檢索和推理能力。

雖然閉源模型基本在研究人員設計出的檢索測試上都能達到要求，但開源模型提供者在自己宣傳支持的長下文長度上，水分很大。

研究人員呼吁社區為長上下文聊天機器人貢獻更多的評估基準，并進一步理解和填補這一差距。

團隊介紹

共同一作Dacheng Li

Dacheng Li目前是加州大學伯克利分校的博士生。本科畢業于加州大學圣地亞哥分校，碩士畢業于卡耐基梅隆大學機器學習專業。他的主要研究方向是機器學習和分布式系統的交叉領域。

共同一作Rulin Shao

Rulin Shao 目前就職于亞馬遜AWS人工智能研究和教育中心，被錄取為華盛頓大學博士。她本科畢業于西安交通大學，碩士畢業于CMU機器學習專業。

Anze Xie

Anze Xie目前就讀于加州大學圣地亞哥分校計算機專業，本科畢業于維斯康星大學麥迪遜分校。

Xuezhe Ma

Xuezhe Ma目前是南加州大學計算機系的助理教授，本科和研究生畢業于上海交通大學，博士畢業于卡耐基梅隆大學。他的研究方向是提高表征學習的效率，有效性等。

團隊的其他幾位成員就是LMSYS Org發起人和老熟人了：盛穎，鄭憐憫，Ion Stoica和張昊等。

參考資料：

https://lmsys.org/blog/2023-06-29-longchat/