すべての GPT-3 レプリケーションが失敗するのはなぜですか? ChatGPT の使用について知っておくべきこと

このツイートは2023年2月12日に書かれたものです。個人的な意見であり、参考程度にしてください。

#GPT-3 の公開複製はすべて失敗するのはなぜですか?どのタスクに GPT-3.5 または ChatGPT を使用する必要がありますか?

このツイートには、一連の記事の詳細を注意深く再検討した上での私の要約と、上記の 2 つの問題に対する私個人の回答が含まれます。 。これらの記事には、GPT-3、PaLM、BLOOM、OPT、FLAN-T5/PaLM、HELM などが含まれますが、これらに限定されません。より信頼できる参考資料や実際の経験をお持ちの場合は、修正してください。

GPT-3 または ChatGPT を独自に再現したい人にとって、最初の質問は重要です。 2 番目の質問は、GPT-3 を使用したい人にとって重要です (以下で GPT-3 について言及する場合は、元の GPT-3 テキストを参照する場合を除き、主に GPT-3.5 または InstructGPT の最新バージョンを指します)。

GPT-3 のすべてのパブリック レプリケーションが失敗するのはなぜですか?

ここでは、これを「失敗」と呼びます。これは、トレーニングされたモデルのパラメータ番号が GPT-3 に近いか、それ以上であるにもかかわらず、元の GPT-3 の文献で報告されているパフォーマンスにまだ匹敵しないことを意味します。 .一致しました。この基準によれば、GPT-3 と PaLM は「成功」していますが、どちらのモデルも公開されていません。そして、すべての公開モデル (OPT-175B や BLOOM-176B など) はある程度「失敗」しています。しかし、私たちはこれらの「失敗」からまだいくつかの教訓を学ぶことができます。

さまざまなトレーニング設定を複数回試すことができれば、最終的にはオープンソース コミュニティが GPT-3 を再現できる可能性があることに注意する必要があります。しかし、現時点では、OPT-175B の別のバージョンをトレーニングするコストは依然として高すぎます。このような大規模モデルの場合、トレーニングには約 1000 個の 80G A100 GPU で少なくとも 2 か月かかります (データは元の文献からのものです)。オプト）。

一部の記事 (OPT-175B や GLM-130B など) では、一部のタスクでは元の GPT-3 のパフォーマンスに匹敵する、またはそれを超えると主張していますが、より多くの GPT-3テスト済みのタスクでは、この主張には疑問が残ります。同時に、より多様なタスクに対するほとんどのユーザーの経験と HELM の評価によれば、最近の OpenAI GPT-3 API のパフォーマンスはこれらのオープン ソース モデルよりも優れています。

その背後のモデルは命令チューニング (InstructGPT と同様) を使用する場合がありますが、同様の命令チューニングの OPT バージョン (OPT-IML) と BLOOM バージョン (BLOOMZ) が使用されます。それでも、InstructGPT や FLAN-PaLM (PaLM の微調整バージョン) よりもはるかに悪いです。

記事の詳細によると、GPT-3 と PaLM の成功と比較した OPT-175B と BLOOM-176B の失敗には複数の理由が考えられます。トレーニング前のデータとトレーニング戦略の 2 つの部分に分けました。

事前トレーニング データ

まず、GPT-3 がどのように事前トレーニング データを準備して使用するかを観察してみましょう。 GPT-3 は合計 300B トークンでトレーニングされます。そのうちの 60% はフィルター処理された Common Crawl からのもので、残りは webtext2 (GPT-2 のトレーニングに使用されるコーパス)、Book1、Book2、Wikipedia からのものです。

GPT-3 の更新バージョンでは、トレーニング用のコード データ セット (Github コードなど) も使用されます。各部分の割合は元のデータセットのサイズに比例せず、代わりに、より高品質のデータセットがより頻繁にサンプリングされます。 OPT-175B と BLOOM-176B の失敗の原因は、オープンソース コミュニティが同様のデータを収集することを困難にしている次の 3 つの問題である可能性があります。 point は、低品質のデータをフィルタリングするための優れた高性能分類器を備えた会社です。 GPT-3 と PaLM の事前トレーニング データセットを構築するために使用されましたが、OPT と BLOOM のトレーニングには使用されませんでした。一部の記事では、少数ながら高品質のデータセットでトレーニングされた事前トレーニング済みモデルが、より多くの混合品質のデータセットでトレーニングされた別のモデルよりも優れたパフォーマンスを発揮できることを示しています。もちろん、ポイント 3 で説明するように、データの多様性は依然として非常に重要です。したがって、データの多様性と品質の間のトレードオフを非常に注意深く扱う必要があります。

2. 2 番目のポイントは、 事前トレーニング データ セット の重複排除です。重複排除は、事前トレーニングされたモデルが同じデータに何度も直面した後に記憶したり過剰適合したりするのを防ぎ、モデルの汎化能力の向上に役立ちます。 GPT-3 と PaLM はドキュメントレベルの重複排除を採用しており、これは OPT でも採用されています。ただし、OPT の事前トレーニング済み重複排除 Pile コーパスには依然として多くの繰り返しがあり、パフォーマンスの低下につながる可能性があります (注: 最近の文献には、事前トレーニング言語モデルにおける重複排除の重要性が想像されているほど大きくない可能性があることが示されています) .)。

3. 3 番目のポイントは、ドメインの多様性と形式の多様性 (例: テキスト) を含む、事前トレーニング データ セットの多様性です。 、コードと表）と言語の多様性。 OPT-175B が使用する Pile コーパスはより優れた多様性を備えていると主張していますが、BLOOM が使用する ROOTS コーパスには既存の学術データセットが多すぎて、Common Crawl データに含まれる多様性が欠けています。これにより、BLOOM のパフォーマンスが低下する可能性があります。それに比べて、Common Crawl corpus に含まれる GPT3 の割合がはるかに高く、その内容が多岐にわたり、分野も多岐にわたることも、GPT-3 がコーパスの基本モデルとして利用できる理由の 1 つであると考えられます。初の総合チャットボットChatGPT。

注意: 一般的に、一般的な LLM (Large Language Model、大規模言語モデル) のトレーニングには多様なデータが重要ですが、特定の事前トレーニング データの分布には膨大な量のデータが含まれます。特定の下流タスクにおける LLM のパフォーマンスへの影響。たとえば、BLOOM と PaLM は多言語データの割合が高いため、一部の多言語タスクや機械翻訳タスクでのパフォーマンスが向上します。

OPT は大量の会話データ (reddit など) を使用します。これが、会話で優れたパフォーマンスを発揮する理由の 1 つである可能性があります。 PaLM はソーシャル メディアでの会話の大部分を占めており、これがさまざまな質問と回答のタスクやデータ セットで優れたパフォーマンスを発揮する理由と考えられます。同様に、PaLM および GPT-3 の新しいバージョンには大部分のコード データセットが含まれており、これによりコーディング タスクの機能が強化され、場合によっては CoT (思考連鎖) 機能も強化されます。

興味深い現象は、事前トレーニング プロセスでコード データを使用しているにもかかわらず、コードと CoT に関する BLOOM のパフォーマンスが依然として低いことです。これは、コード データだけではモデルのコードと CoT 機能が保証されないことを意味している可能性があります。

つまり、いくつかの記事では、上記の 3 つのポイント、つまりデータ重複排除によるメモリとオーバーフィッティングの回避、データ スクリーニングによる高品質データの取得、データの多様性の確保の重要性を示しています。 LLM の一般化を確実にするため。残念ながら、PaLM と GPT-3 がこれらのデータをどのように前処理するか、または事前トレーニング データ自体の詳細はまだ公開されていないため、一般のコミュニティがそれらを再現するのは困難です。

トレーニング戦略

ここでのトレーニング戦略には、トレーニング フレームワーク、トレーニング期間、モデル アーキテクチャ/トレーニング設定、変更が含まれます。トレーニング中に。これらは、非常に大規模なモデルをトレーニングするときに、より優れた安定性と収束を得るために使用されます。一般に、損失のスパイクと収束の失敗は、未知の理由により、事前トレーニング中に広く観察されます。したがって、これらの問題を回避するために、トレーニング設定とモデル アーキテクチャに対する多数の変更が提案されています。ただし、これらの変更の一部は OPT および BLOOM の最適な解決策ではなく、パフォーマンスの低下につながる可能性があります。 GPT-3 では、この問題をどのように解決するかについては明示的に言及していません。

#1. トレーニングの枠組み。 175B を超えるパラメーターを持つモデルでは、多くの場合、ZeRO スタイルのデータ並列処理 (分散オプティマイザー) とモデル並列処理 (テンソル並列、パイプライン並列、場合によってはシーケンス並列を含む) が必要になります。 OPT は、ZeRO の FSDP 実装とモデル並列 Megatron-LM 実装を使用します。 BLOOM は、ZeRO の Deepspeed 実装とモデル並列 Megatron-LM 実装を使用します。

PaLM は、TPU ベースのモデル並列処理およびデータ並列処理システムである Pathways を使用します。 GPT-3 のトレーニング システムの詳細はまだ不明ですが、少なくともある程度はモデルの並列処理が使用されています (Ray を使用しているという説もあります)。トレーニング システムとハードウェアが異なると、トレーニング現象も異なる場合があります。明らかに、PaLM の記事で紹介されている TPU トレーニング用の設定の一部は、他のすべてのモデルで使用される GPU トレーニングには適用できない可能性があります。

ハードウェアとトレーニング フレームワークの重要な影響は、bfloat16 を使用してモデルの重みや中間層のアクティベーション値などを保存できるかどうかです。 bfloat16 はより広範囲の浮動小数点数を表現でき、損失が急増したときに発生する大きな値を処理できるため、これは安定したトレーニングにおいて重要な要素であることが証明されています。 TPU では bfloat16 がデフォルト設定ですが、これが PaLM の成功の秘訣かもしれません。しかし、GPU では、V100 での混合精度トレーニングの唯一のオプションである float16 が主に使用されていました。

OPT は float16 を使用していますが、これが不安定要因の 1 つである可能性があります。 BLOOM はそのような問題を発見し、A100GPU で bfloat16 を使用することになりましたが、この設定の重要性を理解していなかったので、float16 を使用した予備実験での不安定性を解決するために、最初のワード ベクトル層の後に追加の層正規化を導入しました。ただし、この層の正規化はゼロショットの一般化を悪化させることがわかっており、これが BLOOM の失敗の要因である可能性があります。

2. トレーニング中の変更。 OPT は、クリップ勾配ノルムと学習率の変更、単純な SGD オプティマイザーへの切り替えと Adam への切り替え、動的損失スカラーのリセットなど、多くの中間調整を行い、最新のチェックポイントからトレーニングを再開しました。)、メガトロンの新バージョンなど。

この途中調整が OPT の失敗の原因の 1 つである可能性があります。対照的に、PaLM は途中での調整をほとんど行いませんでした。損失スパイクが発生したときに、スパイクの約 100 ステップ前のチェックポイントからトレーニングを再開し、約 200 ～ 500 バッチのデータをスキップするだけです。この単純な再起動に頼るだけで、PaLM は魔法のような成功を収めました。これは、事前トレーニング データの構築中にサンプリングが完了しているため、モデルはビットの意味で決定的であり、安定性を高めるためにモデル アーキテクチャとトレーニング設定に多くの変更が加えられているためです。 PaLM におけるこのような変更は次の点で示されます。

3. モデル アーキテクチャ/トレーニング設定: トレーニングをより安定させるために、PaLM は、Adafactor の修正バージョンの使用を含め、モデル アーキテクチャとトレーニング設定に多くの調整を加えました。オプティマイザーとして、ソフトマックスの前に出力ロジットをスケーリングし、ソフトマックス ノーマライザーを 0 に近づけるように補助損失を使用し、ワード ベクトルと他の層の重みに異なる初期化を使用し、フィードフォワード層と層の正規化でバイアス項を使用せず、プレドロップアウトを使用します。トレーニング中は使用しません。

GLM-130B には、DeepNorm ベースのポストレイヤー正規化の使用など、非常に大規模なモデルを安定してトレーニングする方法に関する、より貴重なコンテンツがあることに注意してください。およびワード ベクター レイヤーの勾配収縮。上記のモデル変更のほとんどは OPT および BLOOM では採用されていないため、不安定性や障害が発生する可能性があります。

4. トレーニング プロセス: 以下の表に示すように、元の GPT-3 事前トレーニング プロセスで確認されたトークンの数は OPT および BLOOM のトークンの数に近いのに対し、PaLM はそれらをはるかに上回っています。同様に、PaLM と GPT-3 の事前トレーニング コーパスはどちらも BLOOM や OPT よりも大きいです。したがって、より多くのトークンとより大規模で高品質なコーパスを使用して事前トレーニングすることが、GPT-3 と PaLM の成功の重要な要素となる可能性があります。

上記の 4 つの点に加えて、その他にも影響を与える可能性のある要因がいくつかあります。安定したトレーニングはそれほど重要ではありませんが、それでも最終的なパフォーマンスに影響を与える可能性があります。

最初のポイントは、PaLM と GPT-3 の両方で、トレーニング プロセス中に小さいものから大きいものへと徐々に増加するバッチ サイズを使用します。これは、より優れた LLM をトレーニングするのに効果的であることが示されています。ただし、OPT と BLOOM は両方とも一定のバッチ サイズを使用します。

2 番目の点は、OPT は ReLU 活性化関数を使用し、PaLM は SwiGLU 活性化関数を使用し、GPT-3 と BLOOM は GeLU を使用します。これにより、通常、トレーニングされた LLM のパフォーマンスが向上します。

3 番目の点は、より長いシーケンスをより適切にモデル化するために、PaLM は RoPE 単語ベクトルを使用し、BLOOM は ALiBi 単語ベクトルを使用し、元の GPT-3 と OPT は学習された単語ベクトルを使用します。長いシーケンスのパフォーマンスに影響します。

どのタスクに GPT-3.5 または ChatGPT を使用する必要がありますか?

どのタスクとアプリケーションに GPT-3 を使用する必要があり、どのタスクとアプリケーションを使用すべきではないかについて説明しようとします。 GPT-3 が特定のタスクに適しているかどうかを示すために、主に GPT-3 と、場合によっては他の特別な機能を備えた、微調整された小規模なモデルへのプロンプトを比較しました。最近登場した小型で微調整可能な FLAN-T5 モデルの優れたパフォーマンスを考慮すると、この問題はさらに重要です。

理想的な世界では、GPT-3 の微調整の負担が手頃であれば、さらなる改善につながる可能性があります。ただし、一部のタスクで PaLM-540B を微調整することで達成される改善は非常に限られているため、一部のタスクで GPT-3 を微調整する価値があるかどうか疑問に思う人もいます。科学的な観点から見ると、より公平な比較は、微調整された GPT-3 とキューされた GPT-3 の間です。ただし、GPT-3 を使用するには、GPT-3 を比較してより小さなモデルを微調整することに興味があるかもしれません。

私が測定としてタスクを完了する正確さに主に関心があることに注意してください。しかし、有害性、公平性など、他にも多くの重要な側面がまだあります。 HELM の記事で説明されているように、GPT-3 を使用するかどうかを決定する際には考慮に入れてください。以下の図は、大まかな意思決定プロセスを示しています。既存のタスクでもまったく新しいタスクでも、実用的なガイドとして役立つことを願っています。

#注 1 : ChatGPT は、会話シナリオに適しているため、チャットボットとして優れています。ただし、通常は、ChatGPT の背後にあるモデルである GPT-3、InstructGPT (GPT-3.5)、Codex を、より多くのタスクや使用シナリオにおける一般的なモデルとして使用します。

注 2: このセクションの結論は、モデルの現在のバージョンに関するいくつかの調査結果に基づいています。 、これは将来のより強力なモデルには適用されない可能性があります。なぜなら、ターゲット データセットに近いより多くの事前トレーニング データを使用して、学術データ セットの指示を調整したり (FLAN-PaLM がより強力なパフォーマンスをもたらす可能性があることを示唆するなど、まだ未公開です)、または RLHF を通じて、モデルをより適切なものにするためです。ターゲット タスク アライメントの向上。他のシナリオ (たとえば、InstructGPT の「アライメント タックス/アライメント タックス」) での能力が犠牲になる場合もありますが、ターゲット タスクでのモデルのパフォーマンスが向上する可能性があります。

この場合、GPT がタスク間で一般化および一般化しているのか、それとも事前トレーニング中にいくつかのテストサンプルを記憶しただけなのか、あるいはそれらを見たのかどうかを判断するのは困難です。 - 事前トレーニング中に「目に見えない」タスクと呼ばれます。しかし、実際にメモリが実際に深刻な問題となるかどうかは疑問が残ります。ユーザーは研究者とは異なるため、GPT が自分のテスト データですでに良好なパフォーマンスを発揮できることがわかった場合、GPT が事前トレーニング中に同じデータまたは類似のデータを見たかどうかは気にしない可能性があります。

いずれにせよ、このセクションの現在の実際的な価値を最大化するために、公開されている小規模なモデル (T5、FALN-T5、いくつかの特殊なモデル) を比較し、微調整することに最善を尽くしました。設計された微調整された SOTA モデルなど) および最近の GPT-3 (GPT-3.5、InstructGPT)、PaLM (または FLAN-PaLM) の最高のパフォーマンス (これらのモデルの評価データが利用可能な場合)。

GPT-3 の使用に適したタスク

一般的に、次のような状況が GPT の使用に適しています。 -3.驚くべきことに、GPT-3 論文の導入部分を振り返ると、そこにある初期設計目標の多くがこれらのタスクをカバーしていました。これは、当初の野心的な目標が部分的に達成されたことを意味します。

1. クリエイティブで複雑なタスク: コードを含む (コード補完、自然言語命令生成コード、コード変換、バグ修正)、テキストの要約、翻訳、クリエイティブライティング（ストーリー、記事、電子メール、レポートの作成、文章の改善など）。オリジナルの GPT-3 文献に示されているように、GPT-3 は、それらの困難で「不可能なアノテーション」タスク向けに設計されています。これらは、以前に微調整されたモデルを現実世界のアプリケーションに適用することは不可能であった程度のタスクですが、GPT-3 ではそれが可能になります。たとえば、最近の記事では、人間による注釈が付けられた過去のテキスト要約が、LLM によって生成された要約に追い越されたことが示されています。

PaLM-540B をプロンプトすることにより、低リソースおよび中リソースの言語から英語への翻訳を必要とする特定の機械翻訳タスクにおいて、微調整されたモデルよりも優れたパフォーマンスを発揮することもできます。

#同様の傾向が BLOOM-176B でも観察されました。これは、通常、学習前コーパスの大部分を英語データが占めるため、LLM は英語文の生成に優れているためです。コーディング タスクで良好なパフォーマンスを得るには、Codex と PaLM は以前のモデルより全体的なパフォーマンスが向上していますが、テスト サンプルに合格するために LLM が複数回 (k 回) サンプリングできるようにする必要があることに注意してください (pass @k をパラメータとして使用)メトリック）。

2. ラベル付きまたはラベルなしのデータが少数しかないタスク。元の GPT-3 ドキュメントに記載されているように、GPT-3 は「高価な注釈」タスク用に設計されています。この場合、ゼロショット、ワンショット、または少数ショットの場合に GPT-3 を達成するために、非常に少量のラベル付きデータを含む小規模なモデルを微調整することは通常不可能です。

3. 配布外 (OOD) の一般化。いくつかのトレーニング データが与えられた場合、従来の微調整ではトレーニング セットが過剰適合し、分布外汎化が不十分になる可能性がありますが、少数サンプルのコンテキスト内学習では分布外汎化が良好になる可能性があります。たとえば、ヒントを備えた PaLM は、敵対的自然言語推論 (ANLI) タスクでは微調整された SOTA モデルよりも優れたパフォーマンスを発揮しますが、通常の言語推論タスクでは依然として微調整された SOTA よりも劣る可能性があります。

もう 1 つの例は、LLM が微調整モデルよりも優れた組み合わせ一般化を示すというヒントです。より適切な分布外一般化は、コンテキスト学習中にパラメータを更新する必要がないため、過学習が回避されるため、または過去の分布外の例が LLM に配布中であるためである可能性があります。このユースケースは、GPT-3 の当初の設計目標の 1 つとして説明されました。「微調整されたモデルは、特定のタスクのデータセットでいわゆる人間レベルのパフォーマンスを達成できますが、実際には、そのタスクのパフォーマンスが過大評価される可能性があります。」これは、モデルがトレーニング セットに存在する偽の相関のみを学習し、モデルがこのトレーニング セットの狭い分布に過剰適合したためです。"

4 . 特定のタスクの卓越性に焦点を当てるのではなく、複数のタスクを処理する能力が必要です。チャットボットは、ユーザーがさまざまなタスクに正しく応答することを期待するシナリオの 1 つです。おそらくこれが、ChatGPT が GPT-3 の最も成功したユースケースの 1 つである理由です。 5. 検索が不可能な 知識集約型タスク

。 LLM に保存された知識は、クローズドブック質問応答や MMLU (STEM、人文科学、社会科学などの 57 分野からの多肢選択問題を含むベンチマーク データ セット) などの知識集約型タスクのパフォーマンスを大幅に向上させることができます。 LLM の世界の知識と問題解決スキルをテストするために使用されます)。ただし、取得前ステップを追加して取得強化を生成できれば、微調整されたより小さなモデル (Atlas モデルなど) のパフォーマンスが向上することもあります (クローズドボリュームの NaturalQuestions および TrivialQA データセットでは、PaLM より Atlas の方が優れています)。最新の InstructGPT の方が優れています)。

検索または従来の検索は、GPT-3 または ChatGPT を検索エンジンに統合するために必要なステップでもあり、これにより生成の精度が向上し、より多くの参照リンクを提供して説得力を高めることができます。しかし、Google が FLAN-PaLM ベースのモデルがうまく機能することを証明した USMLE (米国医師免許試験) の受験など、検索が許可されない、または簡単ではない場合があることを認めるべきです。

同様に、MMLU ベンチマーク セットでは、PaLM-540B は他の微調整モデルよりも優れたパフォーマンスを示しており、後者に検索を組み合わせた場合でも、InstructGPT の最新バージョンは依然としてパフォーマンスが劣っています。これらのバンドを検索するために微調整された SOTA があります。 FLAN-T5 で示されているように、より小さなモデルのコマンド チューニングでも、より大きな LLM モデルの結果に近い結果が得られることにも注意してください。

#6. LLM の創発的な能力を必要とするいくつかの困難なタスク (CoT や BIG-Bench の複雑なタスクによる推論など)論理的推論、翻訳、質疑応答、数学的タスクなどが含まれます)。たとえば、PaLM は、数学的推論と常識的推論を含む 7 つのマルチステップ推論タスクにおいて、8 サンプルの CoT が、そのうち 4 つのタスクでは微調整された SOTA より優れており、他の 3 つのタスクでは基本的に同じであることを示しました。 . .

このような成功したパフォーマンスは、より大規模なモデルと CoT の両方に起因すると考えられます。 PaLM はまた、8B、62B、540B モデルの BIG-Bench タスクで個別のパフォーマンスの向上を示しており、これは LLM の創発力として知られるスケーリング則を超えています。さらに、5 つのプロンプトを備えた PaLM-540B は、Big-Bench の 58 の一般的なタスクのうち 44 において、以前の (サンプルが少ない) SOTA よりも優れたパフォーマンスを発揮します。 Big-Bench での PaLM-540B の全体的なパフォーマンスも、人間の平均的なパフォーマンスよりも優れています。

7. 人間の模倣が必要なシーン、または目標が人間に届くパフォーマンスを生み出すことである一般的な人工知能のレベル。同様に、ChatGPT は、ChatGPT 自体を人間に近づけることで驚異的な成功を収めたケースの 1 つです。これは、GPT-3 の当初の設計目標の 1 つとしても説明されました。「人間は、ほとんどの言語タスクを学習するのに大規模な教師付きデータセットを必要としません。多くてもほんの数例だけで、人間はさまざまなタスクと技術をシームレスに統合できます」 「従来の微調整モデルは、多くのベンチマーク データセットで人間レベルのパフォーマンスを主張しているにもかかわらず、人間との不公平な比較につながります。」

#8. 一部の 言語モデリングに近い従来の NLP タスク # では、サンプル数が少ない PaLM-540B は、次のような微調整された SOTA とほぼ一致するか、それを超える可能性があります。最後の単語クローゼと照応分析。この場合、ゼロサンプル LLM で十分であり、単一サンプルまたは少数サンプルの例は通常はほとんど役に立たないことに注意してください。

他のタスクでは、GPT-3 のサイズのモデルをプロンプトする必要はありません:

GPT のタスクの使用には適していません-3

#1. OpenAI GPT-3 の API を呼び出すと予算を超えます (たとえば、あまり資金のないスタートアップ企業の場合)。

2. OpenAI GPT-3 の API 呼び出しにはセキュリティ上の問題があります (OpenAI へのデータ漏洩や有害なコンテンツが生成される可能性など)。

3. 同様のサイズのモデルをデプロイして推論の遅延問題を解決するのに十分なエンジニアリング リソースやハードウェア リソースがありません。たとえば、最先端の 80G A100 や推論速度を最適化するためのエンジニアリング リソースがなければ、Alpa を使用して 16 台の 40G A100 に OPT-175B を展開するだけで、単一サンプルの推論を完了するのに 10 秒かかりますが、これは現実的ではありません。これは、現実世界のほとんどのオンライン アプリケーションでは許容できない遅延です。

4. GPT-3 を使用して、優れたパフォーマンスと高精度を備えた微調整モデルを置き換える場合、または特定の単一タスクや用途で NLU をデプロイする場合シナリオ (自然言語理解) または NLG (自然言語生成) モデルを使用する価値があるかどうか、よく考えてください。

• 分類タスクなどの一部の従来の NLU タスクでは、GPT-3 を要求するのではなく、まず FLAN-T5-11B モデルを微調整してみることをお勧めします。たとえば、難しい NLU ベンチマーク データ セットである SuperGLUE (読解、テキストの含意、語義の曖昧さ回避、共参照解決、因果関係推論などのタスクを含む) では、PaLM-540B の数ショット プロンプトのパフォーマンスはすべて、ファイン ショット プロンプトのパフォーマンスよりも劣ります。 -チューニング.T5-11B であり、これらのタスクのほとんどに大きなギャップがあります。オリジナルの GPT3 を使用した場合、そのヒント結果と微調整された SOTA の結果との間のギャップはさらに大きくなります。興味深いことに、微調整された PaLM でさえ、微調整された T5-11B と比べて限られた改善しか示しておらず、微調整された PaLM は、微調整されたエンコーダ/デコーダ モデル 32B MoE モデルよりもさらに悪いです。これは、これらの大規模なモデルを使用するために微調整またはヒントが使用されるかどうかに関係なく、より適切なアーキテクチャ (エンコーダ/デコーダ モデルなど) を使用して小規模なモデルを微調整する方が、非常に大規模なデコーダのみのモデルを使用するよりも依然として優れたソリューションであることを示唆しています。最近の論文によると、ChatGPT は、最も伝統的な NLU 分類タスクであるセンチメント分析においてさえ、微調整された小規模なモデルよりも依然としてパフォーマンスが劣ります。
• 実世界のデータに基づいていないいくつかの困難なタスク。たとえば、BigBench には、LLM にとって難しいタスクがまだたくさんあります。具体的には、BigBench タスクの 35% では、人間の平均パフォーマンスは依然として PaLM-540B よりも高く、ナビゲーションや数学的帰納法など、モデル サイズを大きくしても役に立たないタスクもあります。数学的帰納法では、プロンプトの仮定が間違っている場合 (例: 「2 は奇数」)、PaLM は多くの間違いを犯します。逆スケーリングの法則チャレンジでも、数学記号を使用する前に数学記号を再定義する (たとえば、「π を 462 として再定義する」などのプロンプトを表示する) など、同様の傾向が観察されました。この場合、LLM の実世界の事前知識はヒントでカバーするには強すぎるため、より小規模で微調整されたモデルの方がこれらの反事実をよりよく学習できる可能性があります。
• 多くの多言語タスクや機械翻訳タスクでは、少数のサンプルでヒント GPT を使用すると、小規模なモデルを微調整するよりもパフォーマンスが低下します。これはおそらく、事前トレーニング コーパスに含まれる英語以外の言語の割合が少ないことが原因であると考えられます。

• 英語から他の言語に翻訳する場合、および高リソース言語を英語に翻訳する場合、PaLM と ChatGPT は機械翻訳タスクに合わせて微調整された小規模モデルの方が劣っているよりはまだ優れています。
• 多言語の質問応答タスクの場合、サンプル数が少ない PaLM-540B と、細かく調整された小型モデルとの間には、依然として大きな差があります。
• 多言語テキスト生成 (テキストの要約やデータからテキストへの生成を含む) については、サンプル数が少ない PaLM-540B と微調整された小型モデルとの間には依然として大きなギャップがあります。微調整された PaLM-540B でさえ、ほとんどのタスクでは微調整された T5-11B と比べて限られた改善しかなく、依然として微調整された SOTA よりも劣っています。

• 常識的な推論タスクの場合、最良の数ショット キュー LLM と微調整された SOTA の間にはまだ差があります。大きなギャップ: OpenbookQA、ARC (Easy および Challenge バージョンを含む)、CommonsenseQA (CoT ヒントを使用する場合も含む) など。
• 機械読解タスクの場合、最良の数ショット ヒント LLM と微調整された SOTA の間には、依然として大きなギャップがあります。ほとんどのデータセットでは、このギャップは非常に大きくなる可能性があります。これは、質問に答えるために必要な知識がすべてテキストにすでに含まれており、LLM に関する追加の知識が必要ないためと考えられます。

#要約すると、上記のタスクは次のカテゴリのいずれかに分類できます:

1.

一部の NLU タスクでは、追加の知識も LLM の生成機能も必要ありません。これは、テスト データが手元のトレーニング データとほぼ同じ分布にあることを意味します。これらのタスクでは、過去に微調整された小規模なモデルが良好なパフォーマンスを発揮しました。

2.

LLM からの追加の知識を必要としないいくつかのタスク各例には、機械の読解など、文脈やプロンプトに関する十分な知識がすでに含まれています。

3. LLM から得られる可能性が低い追加の知識が必要になる場合や、その可能性は低いものもあります。 LLM は、LLM が限られた事前トレーニング サンプルしか持たない一部の低リソース言語のタスクなど、同様の分散タスクをこれまでに見てきました。 #4. 一部のタスクでは、LLM に含まれる知識と矛盾する知識、または現実世界の言語データに基づいていない知識が必要です

# ＃＃。 LLM は現実世界の言語データに基づいてトレーニングされるため、新しいタスクで反事実の知識を使用して元の知識をカバーすることは困難です。逆スケールの法則チャレンジの「数学的表記の再定義」問題に加えて、わずかに変更された引用を再語るという別のタスクがあり、LLM はプロンプトに表示される変更された引用を再語るように求められます。この場合、LLM は、変更されたバージョンではなく、元のバージョンの引用を繰り返す傾向があります。

5. 一部のタスクは LM からの知識を必要としますが、この知識の操作にも大きく依存します

、および LLM の「次のトークンを予測する」という目標この種の操作は簡単には実現できません。例としては、いくつかの常識的な推論タスクがあります。 CoT と最小から最大へのヒントが LLM 推論に役立つ理由は、計画と知識の分解/結合のプロセスをたまたま模倣する継続的な事前トレーニング テキストをより適切に呼び出すことができるためである可能性があります。

したがって、CoT と最小から最大へのプロンプトは、一部の数学的推論、コード、およびその他の単純な自然言語推論タスクではうまく機能しますが、多くの常識的な推論 (逆スケーリングなど) では失敗します。法律競技会で実証された演繹的推論タスクやカスタムの記号的推論タスクでは依然としてパフォーマンスが低い。これらのタスクは通常、自然言語データの現実世界の連続シーケンスではカバーされず、完了するには散在する知識を操作する必要があります。

6.

コンテキスト学習の例または実世界のデータにおける誤った相関の影響を受けやすい一部のタスク

。一例としては、「逆スケールの法則」コンテストでの否定的な言葉を含む質疑応答が挙げられます。 LLM に「猫の体温が平均より低い場合、その体温は...ではありません」と尋ねると、「安全範囲」ではなく「危険にさらされている」と答える傾向があります。これは、LLM が「平均体温以下」と「危険」の間の一般的な関係によって支配されており、負の場合には偽の相関関係であるためです。

7. 目標が言語データの処理とは大きく異なる一部のタスク

(回帰問題など、モデルの微調整が困難な場合) LLM に置き換えます。マルチモーダル タスクに関しては、LLM では解決できませんが、大規模な事前トレーニング済みマルチモーダル モデルの恩恵を受ける可能性があります。

8. 一部のタスクでは、LLM

の緊急機能を必要としません。これらのタスクの多くを正確に識別するには、LLM トレーニング中に緊急の機能がどこで発生するかをよりよく理解する必要があります。

実際の使用シナリオでは、遅延要件を満たすことができないために LLM をオンラインで使用できない場合でも、LLM を使用してオフラインでデータを生成したりラベルを付けたりできることに注意してください。このような自動的に注釈が付けられたラベルは、オンラインで見つけてユーザーに提供したり、より小さなモデルを微調整するために使用したりできます。このようなデータを使用して小規模なモデルを微調整すると、モデルのトレーニングに必要な手動で注釈を付けたデータが減り、LLM の新機能の一部 (CoT など) が小規模なモデルに注入されます。

要約すると、十分なラベル付きデータがある場合の多くのタスクにおけるオープンソース FLAN-T5 の驚くべきパフォーマンスを考慮すると、OpenAI API を呼び出すリソースが限られているユーザーは、まず問題なく試してみることをお勧めします。 -ターゲット タスクでの FLAN-T5-11B のチューニング。さらに、MMLU データセット上での FLAN-PaLM-540B の最近のパフォーマンス (HELM によると) InstructGPT の最新バージョンのパフォーマンスと比較して驚くほど優れていることに基づくと、Google は OpenAI よりも強力な基本モデルを持っている可能性があります。 OpenAI は、これまでに取得した中で最も強力な LLM を API リリースに渡しました。

Google に残された唯一のステップは、人間のフィードバックを通じてこの LLM を会話シナリオに適合させることです。 LaMDA に基づいている可能性のある Bard のバージョンを最近披露することに「失敗」したにもかかわらず、彼らが ChatGPT のようなチャットボット、またはそれより優れたチャットボットをすぐにリリースしたとしても、私は驚かないでしょう。

著者について

## 英語原文著者: Yang Jingfeng、現 Amazon 科学者、北京大学を卒業し、学士号を取得スタンフォード大学のヤン・ディイー教授の指導の下、ジョージア工科大学で学位と修士号を取得。

Yang Haotong によって翻訳され、Wang Xiao によって改訂されました。

原稿の初版に関する提案をしてくれた Jin Honye と、議論と提案をしてくれた Chen Sanxing と Fu Yao に感謝します。

英語のオリジナルバージョン: https://jingfengyang.github.io/gpt

プッシュ原文: https://twitter.com/JingfengY/status/1625003999387881472

以上がすべての GPT-3 レプリケーションが失敗するのはなぜですか? ChatGPT の使用について知っておくべきことの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。