ChatGPT コンテキストが 64K オープン ソース モデルを圧倒!カリフォルニア大学バークレー校: オープンソース モデルの機能は深刻な「誤ったラベル付け」を受けている | 最新のハードコア評価が暴露される

以前に Vicuna モデルと大規模な言語モデル コンペティションをリリースした LMSYS Org (カリフォルニア大学バークレー校が主導) の研究者たちは、また新しいことを行っています。

今回、彼らは長いコンテキストをサポートし、最大 16K トークンのコンテキスト長をサポートするオープンソースの大規模モデル ファミリ LongChat-7B と LongChat-13B を開発しました。

しかし、実際には、市場にはすでに 65K (MPT-7B-storyteller) および 32K (CHatGLM2-6B) トークンをサポートするプレーヤーが存在します。

写真

研究者たちは、疑問を持ちながら謙虚に彼らから学んでいるという精神で、長いコンテキストのタスクを処理する際の大規模言語モデルのパフォーマンスを評価するためのツールを特別に設計し、長いコンテキストをサポートすると主張するいくつかのモデルのパフォーマンスをテストしました。

テストしてみるまでわかりません。テストしてみると、これまで長い浮き沈みをサポートすると主張していたオープン ソース モデルはほとんどすべて品質が悪く、自分の LongChat がすべての「オープン ソースの偽物」の中で本物であることがわかります。

商用のクローズドソースの大規模モデルのロングコンテキスト機能は非常に優れており、それぞれが非常に強力です。

写真

長距離トピック検索タスクにおける LongChat と他のモデルの比較

長い文脈「偽造防止」

研究者のテストによると、クローズドソースの商用ロングコンテキストモデルは期待通りの性能を発揮し、GPT-3.5-16k と Anthropic Claude はどちらもベンチマークでほぼ完璧なパフォーマンスを達成しました。

しかし、既存のオープンソース モデルは、長いコンテキスト長に対しては「主張」されているよりもはるかにパフォーマンスが低下します。

写真

大規模言語モデルは長いコンテキスト機能をサポートする

新しい LongChat オープンソース モデル、16k コンテキストをサポート

LongChat モデルは、最大 16,000 トークンのコンテキスト長を処理できるだけでなく、会話における人間の指示に正確に従い、人間の好みのベンチマーク MT-Bench で優れたパフォーマンスを発揮します。

プレビュー版はHuggingFaceで入手可能です:

• lmsys/ロングチャット-13b-16k
• lmsys/ロングチャット-7b-16k

興味のある学生は、コマンドライン インターフェイスまたは Web インターフェイスで FastChat の使用を試すことができます。

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

研究結果を再現するために使用されたデータとコードは、研究チームの LongChat リポジトリで見つかります。また、研究者は視覚化も親切に提供してくれました。

それでは、LLaMA の 2048 トークンのコンテキスト長から 16K まで、LongChat が段階的にトレーニングされる様子を見てみましょう。

ステップ1：圧縮ロータリー埋め込み

回転位置埋め込みは、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 などのインデックスであり、文中のトークンの位置を示すために使用されます。

たとえば、「今日は良い日だ」という文では、トークン「今日」の 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 のトークンは position_ids = 10000 / 8 = 1250 になり、隣接するトークン 10001 は 10001 / 8 = 1250.125 になります。

このテクノロジーは、オープンソース コミュニティ (https://kaiokendev.github.io/context) のオープンソース愛好家である Kaiokendev によって最初に発見され、普及され、議論されました。 LMSys Org の研究者は、この技術が非常にうまく機能し、このステップでは 1 行のコードの変更のみが必要で、トレーニングは不要であることを発見しました。

ステップ2: キュレーションされたダイアログデータベースを微調整する

埋め込みを圧縮した後、研究者は慎重に選択した会話データセットを使用して微調整プロセスを実行しました。

研究チームは、以前ビクーニャのトレーニングに使用したユーザー共有会話データを再利用しました。

データは FastChat データ処理パイプラインを使用してクリーンアップされ、会話は 16K 以下の長さに切り捨てられました。

次に、標準の次のトークン予測損失を使用してモデルを微調整します。

最後に、それぞれ 80,000 件と 18,000 件の対話を使用して、7B モデルと 13B モデルを微調整しました。

A100 をクラウドで使用する場合、1 時間あたり 3 ドルかかると仮定すると、7B モデルは約 300 ドル、13B モデルは約 700 ドルになります。

コンテキスト能力検証ツール: LongEval

研究チームは、市販のクローズドソースおよびオープンソース モデルで宣伝されている長いコンテキスト機能 (8K、32K、100K) を検証するために、検証ツールキットを開発しました。

モデルの作成者によって、いわゆる「ロングコンテキスト機能」に対する理解が異なる場合があります。

たとえば、MPT-7B-StoryWriter が主張する 65K のコンテキスト長は、16K のコンテキスト長での OpenAI の ChatGPT と同じパフォーマンスを発揮しますか?

同じ問題は、LongChat の開発中にも研究チームを悩ませました。

新しくトレーニングされたモデルが実際に予想されるコンテキストの長さを効果的に処理できるかどうかを迅速かつ効率的に確認するにはどうすればよいでしょうか?

この問題に対処するために、研究チームは、LLM が長いコンテキストを処理することを必要とするタスクに基づいて評価を実施できます。

例としては、長いテキストシーケンスにおけるテキストの生成、検索、要約、情報の関連付けなどが挙げられます。

最近の研究に触発されて、研究者たちは LongEval と呼ばれるロングコンテキスト テスト スイートを設計しました。

このスイートには難易度の異なる 2 つのタスクが含まれており、長いコンテキストでのパフォーマンスを簡単かつ迅速に測定および比較する方法を提供します。

タスク 1: 粗粒度のトピック検索

現実世界の長い会話では、ユーザーはチャットボットとの会話の中で複数のトピック間を行き来することがよくあります。

研究チームはトピック検索タスクを使用してこのシナリオをシミュレートしました。

このタスクは、複数のトピックで構成される長い会話の最初のトピックを取得するようにチャットボットに要求することで、このシナリオをシミュレートします。

タスクの例は次のとおりです。

 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 個のトークンで構成される多数のダイアログを設計し、それらをランダムに組み合わせて目的のテストの長さに達し、組み合わせた長いテキストをプロンプトとして使用しました。

したがって、これは粒度の粗い会話です。モデルが正しい位置からそれほど離れていない位置 (< 500 トークンの距離) を特定できる場合、正しい予測が得られる可能性があるからです。

タスク 2: きめ細かな検索

長い会話の中でテキストを見つけて関連付けるモデルの能力をさらにテストするために、研究者らはより洗練された行検索テストを導入しました。

このテストでは、チャットボットは長い会話からトピックを取得するのではなく、長いドキュメントから数字を正確に取得する必要があります。

次に例を示します。

 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 であると主張していますが、主張されているコンテキスト長の 4 分の 1 (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能力の無関係な要因の解明

研究者らは、話題と行の検索テストにおいて、いくつかの誤りは、指示に従う能力など、長い文脈の能力とは無関係の要因によって引き起こされたことを観察した。

たとえば、行検索テストでは、モデルは要求された実際の数字を答える代わりに、「はい、数字をお教えします」とだけ応答する場合があります。

公平な比較を行うために、研究者は長期文脈能力とは無関係な要因を回避するために 2 つの対策を講じました。

1) 適切なプロンプトワードをデザインする

2) 精度は、モデルが研究者の指示どおりに動作する場合にのみ計算されます。

人間の嗜好ベンチマーク（MTベンチ）

前のセクションでは、研究者は LongChat モデルが長距離検索タスクで優れたパフォーマンスを発揮することを確認しましたが、これは人間の好みの大幅な低下につながるのでしょうか?

それがまだ人間の好みに合っているかどうかをテストするために、研究者たちはGPT-4を使用して、一連の難しいマルチターン対話問題であるMTベンチを採点しました。

研究者らは、LongChat-13B-16K は最も近い代替モデルである Vicuna-13B と比較して MT-Bench スコアがわずかに低下したことを発見しましたが、それは許容範囲内であり、この長距離能力が短距離能力を大幅に犠牲にしていないことを示唆しています。

同時に、LongChat-13B-16K は、同じサイズの他のモデルと比較しても競争力があります。

写真

議論と分析

研究者らは、コンテキストの長さが 16K に近づくと、LongChat-13B-16K では細粒度の行検索タスクの精度が低下することを発見しました。

研究者たちは当初、これが最大の微調整長に近づいたためだと推測した。

たとえば、トレーニングに長い長さ (32K など) を使用すると、この問題を軽減できます。

研究者たちはこの問題の解決に積極的に取り組んでおり、将来のリリースで対処する予定です。

研究者らは、パフォーマンス レベルの定性的な説明を表形式で提供し、最終的な考察を示したいと考えています。コンテキスト内でテキストを生成できることと、主張されているコンテキストの長さで実際に推論と検索を実行できることの間には大きなギャップがあります。

モデルプロバイダーは通常、優れたロングコンテキストテキストの生成、検索、および推論機能を実現するために、モデルを適切にトレーニングする必要があります (たとえば、高品質の長いシーケンスデータを使用するか、研究者が検討したようにデータを圧縮する)。

クローズドソース モデルは、研究者が設計した検索テストの要件を基本的に満たすことができますが、オープン ソース モデルの提供者は、サポートすると主張する長いテキストの長さを非常に誇張しています。

研究者たちは、コミュニティに対し、ロングコンテキスト チャットボットの評価ベンチマークをさらに提供し、このギャップをさらに理解して埋めるよう呼びかけています。

チームについて

共著者: 李大成

Dacheng Liは現在、カリフォルニア大学バークレー校の博士課程の学生です。彼はカリフォルニア大学サンディエゴ校で学士号を取得し、カーネギーメロン大学で機械学習の修士号を取得しました。彼の主な研究対象は、機械学習と分散システムの交差点です。

共著者 ルリン・シャオ

Rulin Shao は現在、Amazon AWS 人工知能研究教育センターに勤務しており、ワシントン大学の博士課程に入学しています。彼女は西安交通大学で学士号を取得し、CMU で機械学習の修士号を取得しました。

アンゼ・シェ

Anze Xie は現在、カリフォルニア大学サンディエゴ校でコンピューターサイエンスを学んでおり、ウィスコンシン大学マディソン校で学士号を取得しています。

馬雪哲

Xuezhe Ma は現在、南カリフォルニア大学のコンピュータサイエンス学部の助教授です。上海交通大学で学士号と修士号を取得し、カーネギーメロン大学で博士号を取得しました。彼の研究の方向性は、表現学習の効率と有効性を向上させることです。

チームの他のメンバーは、LMSYS Org の創設者や古くからの知り合いである Sheng Ying、Zheng Lianmin、Ion Stoica、Zhang Hao などです。

参考文献:

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