より少ない学習データと小さなモデルで、より大きな言語モデルを上回る技術
(blog.research.google)- 大規模LLMはfew-shotだけで新しいタスクを解けるが、サービングコストが大きいため、Google Cloud AIチームは小さなタスク特化モデルに自然言語の根拠（rationale）も併せて学習させるdistilling step-by-stepを提案した
- この手法はfew-shotのChain-of-Thought（CoT）でLLMの中間推論を抽出し、T5モデルがラベル予測と根拠生成を同時に学ぶマルチタスク学習へ変換する
- 実験では540BのPaLMを基準LLM、T5をダウンストリームモデルとして使い、e-SNLI、ANLI、CQA、SVAMPの自然言語推論・常識質問応答・算術文章題を評価した
- e-SNLIでは全データの**12.5%**だけで標準的なファインチューニングを上回る性能を出し、ANLIでは770MのT5が80%のデータで540B PaLMのfew-shot性能を超え、モデルサイズを700倍以上削減した
- 小さなモデルのデプロイと学習データ収集コストの間のトレードオフを減らすアプローチであり、Vertex AIでprivate previewとして提供されている
LLMのデプロイコストと小型モデル学習の限界
- LLMはzero-shotやfew-shotプロンプティングで、見たことのない新しいタスクを処理できるが、実サービスではモデルサイズが大きな制約になる
- 175B規模のLLMを1つサービングするには、特殊なインフラ上で少なくとも350GBのGPUメモリが必要になる
- 当時の最新LLMは500Bパラメータを超える規模で構成されていた
- 実務では、より小さなタスク特化モデルをデプロイすることが多く、通常は2つの方法が使われる
- ファインチューニング（fine-tuning）: BERTやT5のような事前学習済み小型モデルを、人がラベル付けしたダウンストリームデータで更新する
- 蒸留（distillation）: より大きなLLMが生成したラベルで小型モデルを学習する
- どちらの方法にもコスト負担が残る
- ファインチューニングは人が作成したラベルが必要で、コストと作業量が大きい
- 蒸留は大量のラベルなしデータが必要で、このデータも収集が難しい場合がある
Distilling step-by-stepの中核アイデア
- Distilling Step-by-Step! Outperforming Larger Language Models with Less Training Data and Smaller Model Sizesは、モデルサイズと学習データ収集コストの間のトレードオフを減らそうとする手法である
- distilling step-by-stepは、LLMから自然言語の根拠、つまり中間推論ステップを抽出し、小さなモデルを学習するための追加の教師信号として使う
- 自然言語の根拠は、入力の質問と出力の答えのつながりを明らかにする
- 例えば、部屋の長さと幅、すでに持っているカーペットの面積が与えられたとき、LLMは「Area = length * width」のような中間的な根拠を生成できる
- こうした根拠には、小さなモデルが本来は多くのデータから学ぶ必要があるタスク知識が含まれ得る
- ラベルだけを学習する代わりに、ラベルと根拠を一緒に学習し、小さなモデルがより少ないデータでタスクを習得できるようにする
2段階の学習手順
- 第1段階は、few-shotのCoTプロンプティングでLLMから根拠を抽出するプロセスである
- タスクごとに、入力・根拠・出力の3要素で構成された例をLLMのプロンプトに入れる
- LLMはこの例に従って、新しい入力に対する根拠を生成する
- 常識質問応答の例では、「Sammy wanted to go to where the people are」という質問と選択肢が与えられる
- 正解は「(a) populated areas」である
- 根拠は「多くの人がいる場所でなければならず、選択肢の中でpopulated areasだけが多くの人がいる場所である」というつながりを提供する
- 第2段階では、抽出した根拠を小さなモデルの学習に入れる
- 標準的なラベル予測タスクに加えて、新しい根拠生成タスクを学習する
- モデル入力の前に
[label]または[rationale]のようなタスク接頭辞を付け、2つのタスクを区別する - 根拠生成タスクは、モデルが中間推論ステップを作るように学習させ、結果としてラベル予測をよりうまく行えるよう促す
実験設定と比較対象
- 基準LLMは540B PaLMである
- タスク特化のダウンストリームモデルにはT5モデルを使用する
- CoTプロンプティングは、可能な場合は既存のCoTプロンプトを使い、新しいデータセットには独自に例を構成する
- 評価は3つのNLPタスクにまたがる4つのベンチマークで行われた
- 比較基準は2系統である
- few-shotプロンプトLLMと比較するため、540B PaLMのfew-shot CoTプロンプティングを使用する
- 標準的なファインチューニングと標準的な蒸留も比較対象に含まれ、ブログ本文では標準的なファインチューニングとの比較を中心に扱う
より少ない学習データで標準的なファインチューニングを上回る
- distilling step-by-stepは、標準的なファインチューニングよりはるかに少ない学習データで、より良い性能を出す
- e-SNLIでは、全データセットの**12.5%**だけを使い、全データで学習した標準的なファインチューニングより高い性能を達成した
- 他のデータセットでも、必要なデータ量が減った
- ANLI: データセットサイズを**75%**削減
- CQA: データセットサイズを**25%**削減
- SVAMP: データセットサイズを**20%**削減
- この比較は、さまざまなサイズの人手でラベル付けされたデータセットで、220M T5モデルを使って行われた
より小さなデプロイモデルでPaLM基準を上回る
- distilling step-by-stepは、few-shot CoTプロンプトを使ったLLMよりはるかに小さいモデルで、より良い性能を出す
- e-SNLIでは、220M T5モデルで540B PaLMより高い性能を達成した
- ANLIでは、770M T5モデルで540B PaLMより高い性能を出した
- このモデルはPaLMより700倍以上小さい
- 同じ770M T5モデルは、標準的なファインチューニングだけではPaLMの性能に到達しにくい
- 小さなモデルサイズとLLM基準の性能超過を同時に示す結果である
データとモデルサイズを同時に削減した結果
- ANLIでdistilling step-by-stepは、770M T5と全データの**80%**だけで、540B PaLMのfew-shot性能を上回った
- 同じ条件で、標準的なファインチューニングは全データの**100%**を使ってもPaLMの性能に追いつけなかった
- 粗い探索を通じて、LLMのfew-shot CoT性能を超えるのに必要な最小T5モデルサイズと、最小の人手ラベル例数を確認した
- 結果として、この手法はLLM性能を上回るために必要なデプロイモデルサイズと学習データ量を同時に削減する
提供形態
- distilling step-by-stepはVertex AIでprivate previewとして提供されている
- 利用を希望する場合は、Google Cloud Project番号とユースケースの概要を含めて
vertex-llm-tuning-preview@google.comへ連絡するよう案内されている
1件のコメント
Hacker News のコメント
より小さな専門家モデルが、ほとんどのアプリケーションを支配することになりそう。サイズと使いやすさの間には最適点と微妙なバランスがあり、記事で示されているような複数のメカニズムがその最適点を見つけて実現していくのだと思う
蒸留モデルに T5 を使っている点が興味深い。エンコーダ・デコーダ構造は廃れていく流れだと思っていたが、まだ関連性があるようだ
また、このアイデアが想像もつかないほど奇抜だったり、型破りだったりするわけでもない点も興味深い。まだ探索すべき低いところにある果実が多く残っていて、大規模言語モデルの未来も決まっているわけではないことを示している。本当の解は、このような方法で訓練された専門家混合かもしれない。正しいアイデアの組み合わせさえ見つければ、聖杯に近い目標が達成可能に見えるのはわくわくする
まだ低いところにある果実はたくさん残っている。思考の連鎖、思考ツリー、思考グラフ、self-ask、self-critique、self-plan、self-reflect など、何十もの変種を見た気がする
大規模言語モデル／機械学習／人工知能分野の活動量と進展は本当にすごい。特に Nvidia のようなハードウェアが非常に高価な状況では、こうした最適化はとりわけ価値がある
これは https://arxiv.org/abs/2212.08410 と同じ内容で、1年後に出たものではないのか
研究者ではないが、最も効果的なモデルはマルチモーダルで、核となるカリキュラムを慎重に設計して訓練したものになるだろう、という直感はずっとあった
システムが効果的かつ正確に一般化するために必要な基本構造とスキルを習得し、保持できるようにしたい。そうしたものを維持しつつ、多様なデータを大量に与えて例外やスキルの組み合わせ方を学ばせる、という形だ。ただし、核となるスキルと知識を最後まで保証する方法が必要になる。論文でしているように、最終回答だけでなく、その理解や操作の過程も出力させれば可能かもしれない
例えばコード生成モデルなら、要求されたプログラムの状態機械シミュレーションを出力するよう求めることができる
最初の図で、なぜ大規模言語モデルの訓練データ量が蒸留モデルやタスク特化モデルより少ないのか気になる
それとも著者たちは、大規模言語モデルに必要な訓練データ量を、蒸留／タスク特化モデルに必要な訓練データに含めて計算しているのだろうか
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj...
事前学習済みの大規模言語モデルを持ってこられるなら、その場合に自分が集める必要のあるデータは、そのモデルをファインチューニングするために必要なデータになる
あの巨大な大規模言語モデルたちには、使われていない容量が大量に残っているのだろうか。それとも小さな言語モデルが推論タスクを単にまねているだけなのだろうか。まねをまねているということか？
巨大な大規模言語モデルが訓練されるデータセットには、進歩を妨げるノイズが多い。また、関係のない知識も大量に含まれているため、モデルはそれまで学習または記憶しなければならず、そのせいで途方もない数のパラメータが必要になる
言語モデルに人類の知識の総体を教えようとしているのではなく、高品質に選別されたデータセットを提供するのであれば、スケールの壁ははるかに低くなる
https://arxiv.org/abs/2305.07759
最適なサイズを推定する方法について、どんなアイデアがあり得るのか気になる
興味深い。小さなモデルが最新の大規模言語モデルと同等の性能を出すには、RLHF は必須なのだろうか。出力構造、文体、ドメイン理解に関する問題は指示チューニングで解決できそうだが、小さなモデルの推論能力を向上させるのにも十分かどうかは分からない
1,750億パラメータの大規模言語モデルを1つサービスするには、特殊なインフラ上で最低 350GB GPU メモリが必要だという
Apple は、利用可能な GPU メモリを最大 144GB までサポートする Mac Studio を販売している
もし 300GB 以上を搭載した Mac Pro を出して、大規模言語モデルのサービング市場を掌握したら、かなり面白そうだ
そうでないなら、現時点で大規模言語モデルのホスティングに適していないもう一つの理由にすぎない
いずれにせよ、本当に盤面を揺さぶれるのは Intel だ。理論上は 2x48GB の Arc カードを持ち込み、AMD/Nvidia がプロ向けカードの顧客のために踏み込まない市場を、より低価格で攻められる
正直、それが最新の Apple ハードウェアを避けていた唯一の理由だ。主に机でコンピュータを使っていて、PC ハードウェアは特に GPU が Apple の最高製品でできることを大きく上回っている。仕事には Linux が非常によく合い、仕事が終わればゲームもできるのに、ほぼ4,000ドルを使うのは正当化しにくい
Facebook が全ユーザーの全チャット履歴で大規模言語モデルを訓練できるのか気になる