Zenn
東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]Publicationへの投稿
🤖

大規模言語モデルを開発するにあたっての事前・事後学習の戦略メモー特に合成データについてー

Kan Hatakeyama
2024/08/30に公開
大規模言語モデル
ローカル LLM
GENIAC
松尾研
tech

関連URL

大規模言語モデルを開発するにあたっての事前・事後学習の戦略メモー合成データを中心にー

はじめに

本記事は、Tanuki-8B および 8x8B モデルの開発過程で得られた事前・事後学習に関する実践的洞察と、特に合成データの活用に焦点を当てたものです。学術的厳密性よりも、現場での経験や直感的理解に基づいた内容が中心となりますが、これらの「モヤモヤとした現場の手応え」が、大規模言語モデル（LLM）開発コミュニティにとって何らかの価値ある情報源となることを期待しています。

これまで: モデル開発に関するこれまでの定説(?)について､個人的に違和感があった点

国内の様々な方と話していると、モデルの事前・事後学習において、次のような主張されている方が多かったように思います。

が、一連の「仮説」は､開発を通した個人の手応えと、そぐわない点がいくつかありました。以下に、いくつかの具体例を記します。

よくある主張(?)A: 事後学習データは少量で良い

これは有名なLIMA論文を発端とする言説のようで、事前学習後を終えた後のファインチューニングデータは少ない方が良いという主張です｡当該論文では､1000-2000件でOKだったとのことでした｡普通は最低でも数万件くらいはやることが多いので､非常に少ない件数です*｡1000件とまでは言いませんが、海外の某トップ企業の研究者の方も、「うまく事前学習されたモデルについては、事後学習のデータは少なくてOK」とおっしゃっていました｡なので､「事後学習データは少量で良い」という仮説は､ある側面においては､正しい主張なのだと思います。

しかし現実問題として、チームで作ったモデルでは、1000件程度でのファインチューニングではまともに動かないという事態に度々､直面しました｡なので､開発の初期段階(Phase1)では､クオリティを問わず､とにかくたくさんの指示データ(>100万件)を学習させるなどの荒業に出ました。

「多量の指示データが必要なのは､事前学習が不十分だからだ」という類のご指摘やアドバイスをいただくこともあります｡ではしかし､現実問題として､限られたリソース制約下で､どのようなデータをどの程度学習させればよいのかについての､実効性のある助言をいただけたことはありませんでした｡*

*これはある意味､当たり前の話です｡なぜなら､プロジェクト期間中､まだ国内では､十分に高性能と呼べる基盤モデルを作った実績のある組織が､おそらく存在しなかったからです(仮にあったとしても､特に会社の場合は､そうしたノウハウは企業秘密として秘匿されるはずです)｡

諸々の試行錯誤の末、LIMA論文の「事後学習データは少量で良い」という主張が成立するためには、特定のモデル条件(素晴らしい事前学習を終えていること)、ファインチューニングデータ(素晴らしいデータであること)、ベンチマーク条件(少量学習の良さが出る計測手法)を満たす必要があるのではないか、という考えに至りました｡

以下､このような仮説に至るまでの経緯を説明していきます｡

よくある主張(?)B: モデルから「知識を取り出すための訓練コスト」はそんなに高くない

先述のように、「事後学習は少数のデータで十分」という主張がしばしば聞かれます。この主張の背後には、暗黙の前提条件が存在するように思われます。それは、「モデルから知識を取り出すのはそれほど困難ではない」という作業仮説です。

この仮説は、主に以下の二つの観点から成り立っていると考えられます：

  1. モデルが少量の事後学習用テキストを学習するだけで、質疑応答や指示追従の能力を獲得する。
  2. 事前学習の段階で、モデルは質疑応答や指示追従の潜在的な能力を自然と獲得している。

これらの仮説の意味を具体的に掘り下げてみます。

事前学習の段階で、モデルは膨大な量のテキストデータを処理します。その中には、「AはBである」といった事実を記述する文章が無数に含まれています。仮説に従えば、こうした事前学習を経たモデルは、事後学習の段階で特定の事項について回答するための能力を、比較的少量のデータで獲得できるはずです。

例えば、事前学習で「東京は日本の首都である」という情報を学習したモデルは、事後学習の段階で「日本の首都はどこですか？」という質問に対して「東京です」と回答する能力を、少量のデータで簡単に身につけられるはずだ、という考え方です。

筆者の仮説

しかし、実際の開発経験は、この仮説に疑問を投げかけるものでした。以下に、実践から得られた洞察を示します：

  1. 知識抽出の困難さ：
    モデルが事前学習で獲得した知識を、望む形で引き出すのは想像以上に困難でした。特定の質問に正確に答えるためには、予想を超える量の事後学習データと訓練が必要となることが分かりました。
  2. 文脈依存性：
    事前学習で獲得した知識は、しばしば特定の文脈や表現形式と強く結びついています。そのため、異なる文脈や表現での質問に対して、適切に知識を適用することが難しい場合があります。
  3. 抽象化の問題：
    事実の単純な暗記と、その知識の柔軟な適用には大きな隔たりがあります。モデルが事実を「知っている」ことと、その事実を様々な状況で適切に利用できることは、別の能力だと考えられます。
  4. 指示追従能力の獲得：
    質疑応答や指示追従の能力は、単に事実を知っているだけでは不十分です。これらの能力には、言語理解、文脈把握、推論など、複雑なスキルの組み合わせが必要です。事前学習だけでこれらの能力を十分に獲得することは難しく、相当量の事後学習が必要となる場合が多いです。

以下に、筆者の経験に基づく、具体的なケーススタディや仮説を例示します。

仮説1: モデルは知識取り出しが苦手である

2023年の秋頃に行った研究*では、指示学習済みのLlama2**に科学論文を読ませてみるという検討をしました。今見返すと、諸々ツッコミどころのある内容であるものの、得られた重要な知見の一つは､「単に科学論文を読ませるだけでは、テキストそのものは記憶できても､内容の理解度を問う問題にはほとんど答えられない」というものでした。

*化学系の某雑誌にリバイズ後の投稿でリジェクトされて半永久的に休眠状態のpreprint

**当時としては最先端のモデル

その研究において、回答精度を高めるためには、単に論文を学習させるだけでは不十分で、GPTやClaudeなどを用いてテキストをスタイル変換させながら､「同一の内容を記述する複数の文章」を生成するのが､最も有効と判明しました｡文章をQ&Aの質問形式に書き換えるアプローチが特に有効でした｡

つまり先述の通り、どうやら大規模言語モデルは「AはBである」という事実データの学習のみから、「BからAを答える」という類の質問に回答するのは､あまり得意ではないということが分かってきました。

これは人間のアナロジーで考えても、自然なことです。一部の天才を除いた多くの人間は、ただ教科書を読んだり授業を聞くだけでは、試験で良い点を取ることはできません。大切なのは、実際に演習問題を解き､習った知識を取り出すための訓練をすることです｡開発した大規模言語モデルの地頭は、普通の人間よりもまだまだ低いはずです。なので、言語モデルにおいても､「知識取り出しのための丁寧な訓練が必要なのではないか?」という仮説が、昨年の段階で生じました。

仮説2: Next token predictionという文脈で、知識習得・知識取り出し・スキル習得に大差はないと考えた

大規模言語モデルは、次に登場する語句(トークン)を予測するシステムです。そしてモデルに知識を習得させる作業は、次に来るべき正確なトークンを間違いなく当てるようにするプロセスです。

ところで、モデルに知識を習得させるためには、有名なPhysics of Language Modelsシリーズの論文で主張されているように、膨大な学習データが必要なことがわかっています。10 B程度のモデルサイズに対しては、1つの事実を記憶として定着させるために、異なるスタイルで書かれた1000種類程度のテキストが必要だったそうです*。

筆者は大規模言語モデルの「知識取り出しや特定のスキル習得においても、知識習得と同じくらいの訓練が必要な可能性がある」という仮説を持っています(必要なデータ量は増減するかもしれません)。何かを覚えたり、回答したり、指示に従うといったタスクは、Next token predictionという文脈において、すべて同じプロセスだからです。

*ちなみに先述の追加学習の研究では、モデルは「単一の事実を記述する数件程度のテキスト」を学習させることで、当該知識を問うクイズに答えられるようになりました。しかし､関係のないデータを同時に数千件程度､学習させてしまうと、回答精度が著しく低下しました。これは､モデル内で十分な記憶定着が生じなかったことを示唆しています｡なので､モデルにとっての確実な知識定着には、Physics…論文が主張する、1000件程度の学習が必要そうだという主張は、筆者の肌感ともあっています。

仮説3: モデルが人間の指示を理解し、正確に従うのは､「めちゃくちゃ難しい」

モデルを人間の思い通りにコントロールするつまり、質問に回答させる・指示に従わせるために､いくつかの試行錯誤を重ねてきました｡

例えば2024年の春頃に、Jasterと呼ばれるベンチマークに､ネットデータを中心に事前学習をした直後の言語モデルが回答できるようになるために必要なデータ量を調べたことがあります(こちら)。Jasterは言語モデルが持つ知識・理解力を多角的に評価することを目的としたベンチマークなのですが､実は数ー数十Bクラスのモデルの大半が､そもそも「知識や理解力を問う以前の段階で躓いている」ことに気づきました(同記事)｡

ここでのポイントは、Jasterベンチマークはモデルの評価コストを下げるため､出力内容を厳格に指定する問題が多いということです｡例えば選択肢番号(=A)だけを答えなさいという問題において､正解の「A」を回答した場合は満点ですが､それ以外の出力形式､たとえば「Aです」､「回答はAの◯◯です｡」､で回答した場合は原則ゼロ点になってしまいます。

ある程度の知性を備えた大人であれば､このような出力形式を守るのは容易なことです。しかし実際問題として、出力形式を守れないモデルが続出しています。ちなみに､数十ー数百Bパラメータを持つと噂されるGPT-3.5ですら､選択肢問題において､正しい回答をできないケースがありました(こちら)｡

一度対応策として、Jasterの各タスクごとに数百件程度ずつdevelopデータを投入する形で､出力形式を学ばせる訓練をしてみたところ､モデルは優れた回答性能を出せることが分かりました*(ちなみに筆者以外のテックブログでも､出力形式を学ぶ重要性が指摘されはじめています)。

*最終モデルにはdevデータは含めていません｡

つまり､大規模言語モデルが人間の指示を理解して従うという作業は､「普通の大人」にとっては簡単そうに見えても､実は､とても難しい作業*なのです｡

*筆者の手触り感でいくと､数十Bクラスの「知性」は、平均的な小学3年生くらいではないかと思います｡例えば小学生3年生に､「1日は何時間か? 次の選択肢から､選択肢番号のみを回答しなさい｡ A.24時間､B.12時間」という試験を出すことを想定します｡おそらく一定数の学童が､ 正解の「A」とは答えずに､「24時間」などと回答してしまうはずです｡それに対し、多くの大人がこの手の問題を苦労せず解けるのは、恐らく、たくさんの選択肢問題を解く経験をしてきたからです。

モデルがJasterで指示追従性を獲得するのに必要なデータが､各タスクごとに数百件程度であったという事実は、上述のPhysics…論文での主張(≒1000件くらいの訓練が必要)とも整合性があります。

以上の経緯より、「知識取り出し」や「指示追従性」の能力獲得のためには､「知識」を習得するのと同量程度(?)の訓練*が必要かもしれない、という仮説の確信度が深まりました。

仮説4: 工学的には、モデルサイズの単なる巨大化よりも、ベターな方法が出現した可能性がある

一連の経緯を踏まえてたどり着いた筆者の主張を、あえて露骨に表現すると、大規模言語モデルの大半は、「これまで(徹底的に)学習した問題しか基本的に解けない」ので、解きたいタスクに対して、「膨大な量の類題をあらかじめ事前学習しておく必要がある」というものです。

先述した挙動などを鑑みると、少なくとも数十B~GPT3.5-turboレベルのモデルにおいては、ベンチマーク問題についても、どこかのタイミングで膨大な量の類題を学ばせておかないと、基本的にタスクを解くことはできないと考えています*。

*当然ながら、このような仮説は、言語モデルの汎化性能、具体的にはzero shot predictionの能力を信じている方にとっては、これは残念な仮説です。

実際、本プロジェクトではモデルの汎化性能が低いという欠点を解決するために、膨大な演習問題や対話データを学ばせるというアプローチをとりました。当然、膨大な演習問題の中には、ベンチマークの類題も含まれることがあります*。となると、当該手法は「カンニング」に近いものであり、本質的な意味での言語能力の向上やスケーラビリティに乏しいアプローチではないか、というご意見を持たれる方がいらっしゃるかもしれません。

*ベンチマークの問題を直接学習させたり、類題を自動合成するなどの作業はしていません｡

しかし筆者は、「膨大な量の対話・演習問題を学習させる」というアプローチは、

今日において、工学上、十分に正当化できるやり方だと考えています。

先述の通り､LIMA論文の主張が成立するためには､a)モデルが少量の事後学習用のテキストを学習させるだけで､質疑応答や指示追従の能力を獲得する､あるいはb)事前学習の段階で､モデルは質疑応答や指示追従の潜在的な能力を自然と獲得している､という前提が成立する必要があります。

しかし､フロンティアモデルの一つであるGPT-3.5ですら､十分な指示追従性を有さないケースがあったことを鑑みると､a,bが成立するためのモデル・事前学習データのハードルは､極めて高いと言わざるを得ません｡具体的には､GPT-4クラスのモデルサイズや､数十Tトークン以上のデータ学習が必要な可能性があります｡この規模の計算資源を投入し続けるのは、経済制約の面でほぼ不可能です。

筆者は、モデル開発の最近の国際的なトレンドは、モデルサイズの巨大化ではなく、焦点を絞ったデータ学習に基づく、サイズの小型化ではないかと考えています*。これを可能にしたのが、言語モデルによるデータ合成です。過去の対話データをもとに、人類がAIに対して行うであろう質問群をあらかじめ列挙し、網羅するというアプローチは、人手の作業では、流石に手間がかかりすぎて実現不可能でした(数十年前のエキスパートシステムの頓挫に似ている?)。

*「巨大AIモデルを用いる時代は終った」というアルトマンの言葉の真意が気になります。

最近は、言語モデルが高品質なデータを多量に作れるようになってきました。vllmなどを使えば、10B程度のモデルから、GPU1枚あたり1秒で1件くらいの速度でデータを生成可能ですし、適切にランダムキーワードなどを設定すれば、特定のドメイン内の対話を概ね網羅したコーパスなども作れます。

ところで、人類はAIと多彩な会話しているような錯覚(?)を感じがちですが、実際のところ、会話の大半は要約、作文、校正、プログラミングなどにパターン化されているようです。なので、ジャンルごとに演習問題を自動生成するのは、実は「途方もなく大変な作業」とまでは言えないのです。AIが身につけるべき「基礎学力」についても、学習指導要領などを参考にすれば、カテゴリ分けしてデータ生成できます。このように、AIに求められる求められる大半の対話・タスクなどは、細分化して書き出すことができます。それらをこなせるようになるための教科書・演習問題をこまめに自動生成すれば、極めて実践的で上質な「チャットボット」の事前学習データが得られます*。

*要するに、「チャットボット」という職業の能力を重点的に伸ばすために、仮想的な教育機関・塾・予備校を作るような取り組みです。

筆者の主観では、今日のモデル開発の世界において、データ面の工夫はほとんど行わず(つまり、チャットボットとしての動作を想定したテキストを作らず)に、とりあえず巨大なモデルを作るというアプローチと、用途をあらかじめ想定して予行演習データを作り、smallerなモデルを作るというアプローチを比較すると、後者に工学的な優位性があるフェーズに入ったように思います。

海外に目を向けてみると、最近のLlama3やgemmaなどのローカルモデルは、モデルサイズの小ささとは裏腹に、商用モデルを凌駕しうる対話性能を出せるようになってきています。恐らくこれは、「人類との対話」に焦点を絞ってテキストデータを大量合成し、学習させた、「対話ドメイン特化型」のプロダクトではないかと推察しています。ビッグテックのノウハウは基本的に公開されておらず、内情をうかがい知るのは難しいですが、合成した指示データを大量に事前学習に投入するというアプローチは、論文レベルでも報告され始めています｡Llama3においても､1000万件を超える指示データでSFT､DPOが行われたとの記載*があります｡つまり､大量に指示データを学習させるという手法は､フロンティアモデルにおける一つの定番になりつつある印象を受けます｡

*ただしhuman annotatedと記載があるので､1000万件の指示データについて､すべて人間が目を通した可能性が高いです｡圧倒的な資金力がなせる業です｡

よくある主張(?)C: AIよりも人間が生成したテキストの方が優れている

これは国際的にも意見が分かれる､センシティブな議題です｡MetaやNvidiaは合成データ派の研究者が多い印象を受けます*｡一方でAIを共著者として認めないNature誌には､「コンピューターサイエンス：生成AIのデータで訓練されたAIモデルが崩壊する可能性」というセンセーショナルな論文が掲載されたりしています｡国内ではどちらかというと､人間の書いたテキストはAIのテキストよりも優れている､という言説が優勢な雰囲気を感じます｡

*Llama3の開発者は､「Webテキストはfull of shit」であり､「これらを学習することは計算資源の無駄」であり､「Llama3のポストトレーニングには原則として人間の文章は使わず､Llama2由来の合成データを使用した」と口述したようです｡NvidiaのNemotronも､人間が書いたノイジーなデータの代わりに､このモデルを使って合成データを生成していきましょう､という意図で構築されたようです｡

本記事を読めば明らかですが､筆者はデータ合成派です。Tanukiモデルの事前・事後学習も後半はほぼ全て､AIが書いたテキストを学習させることになりました｡このような取り組みは「モデル模倣」と呼ばれることもありますが､筆者はメリットがデメリットを上回ると判断しています｡

いくつかの論点について､考えてみます｡

論点A.「モデル模倣」はだめなのか?

モデル模倣を戒める(?)有名な論文は､The False Promise of Imitating Proprietary LLMsというセンセーショナルなタイトルで発表されています｡この論文では.5-13 Bクラスのモデルに対して､0.1 Bトークン程度のChatGPTの出力を学習させたようです｡

評価の結果､モデルは「ChatGPTっぽい出力」をするようになった一方で､本質的な知識はあまり変わらないということが分かったそうです｡しかも､いつもと違うことを学習したせいか､事実に関するハルシネーションが誘発された､とのことでした｡

本論文の結果について､個人的に思うところを書きます｡

  • A.「ChatGPTっぽい出力」をするようになった

これはとても素晴らしいことです｡先述したように､モデルの出力をユーザーが望む形式に変更するのはとても大変な作業で､その実現には､相当の苦労を要します｡ChatGPT*のような先輩モデルは､おそらくは開発者の地の滲むような苦労の末､指示追従性を獲得したわけです｡ユーザーインターフェースとして最重要とも言えるモデルの指示追従性を上げるために､優れたモデルの挙動を真似するという行為は､エンジニアリングの観点から､極めて合理的だと思います｡

*注意点: ChatGPTのデータ自体は､契約上､商用利用可能なモデルの学習に使うことは難しいです｡プロジェクトでは、オープンなライセンスのモデルの出力を使いました。

もちろん､人間が手作業で指示データを生成し､きめ細やかに指導するというアプローチも有りだとは思います。しかしデータ生成や品質管理*に､膨大な手間がかかりますので､スケーラビリティに制約があり、誰でもできるやり方ではありません。

*今回の開発では､結局､大半の人間が書いた文章よりも､Calm3などが作成したテキストのほうが､全体的には丁寧で高品質であるという結論に至りました｡人間が書いた・手を加えた､ややノイジーな文章が少しでも含まれると､モデル性能が悪化してしまうという事態にも遭遇しました｡ある程度､モデルの性能が上がってくると､指示データの品質管理の難易度が一気に上昇することを痛感しました｡

  • B. モデル模倣をしても知識は増えなかった

この挙動は､当たり前のことかもしれません｡先述の通り､モデルが一つの知識をきちんと獲得するためには､1つの事象あたり､1000件程度のテキストが必要です｡わずか0.1 Bトークン程度のデータ学習で､モデルそのものの知識が本質的に増えると期待すべき、合理的な理由がありません｡

  • C. 事実に関するハルシネーションが生じた

これはあまり賢くないモデルに対して､中途半端に高度なことを学ばせると､モデルが混乱して､もともと覚えていた内容の理解も怪しくなるという挙動のようです。人間でも起こりそうな現象です｡多くのローカルモデルにとって､GPT-4の出力は高度過ぎた可能性があります。

実は、このようなハルシネーションを引き起こす恐れのある、学習ドメインのズレ(out of domain)問題は､今回のモデル開発時も論点となりました。

では､今回は論点B,Cの対策としてとったアプローチは何かというと､「とにかく多量のデータで模倣して､本当に身につくまで学習させる」(fake it until you make it)というものでした｡詳細は後述します｡

論点B. 実はデータが既に枯渇していないか?

どうして筆者が合成データの活用にこだわるかというと､人間が書いた文章(特にCommonCrawl)をかき集めても､言語モデルが人類と円滑に対話し､指示を聞くために必要なデータを､十分にはカバーできない可能性が高いと考えている*からです｡

*現段階では､公開情報が少ないため､この命題は論証も反証も困難です｡どちらの考え方・開発指針にベットするかという､スタンスの問題だと思います｡

筆者の仮説では､知識の取り出しやスキルの習得は言語モデルにとっては､非常に難しいタスクなので､相応の訓練データが必要です｡更には､(後述するように)数学や論理のような､出力の厳密さが求められるジャンルでは､通常のトピックよりも更に多くの学習データが必要らしいという手応えが得られてきました｡そのため､一連の作業を行う*ために必要なWebデータは､もはや枯渇してしまったので､新たに生成する必要があるというのが､筆者の持論です｡

*モデルサイズを際限なく大きくすれば､必要なデータ量は減ります｡しかし先述のように､GPT-3.5程度のサイズでは､Webデータのみから十分な学習をこなすことはできないと考えています｡

よくある主張(?)D: 過度な事後学習はモデルの創造性を損なう

これまでの議題から少し脱線しますが､事後学習のやりすぎは､モデルの創造性や出力の多様性を損なう(LIMA論文やこちらなど)という考え方が､あるようです｡

筆者もこの考えには､部分的に賛同します｡例えば多量の指示データ・合成データで学習されたとされるNemotronは､自由な形式で対話データを生成させる際の出力の多様性が乏しい､という意見がプロジェクト内でありました｡

ただし､多様性や創造性以前の問題として､そもそもまともに人間と対話が出来ないモデルは使用価値が低いです。そのため、今回のプロジェクトでは出力の創造性や多様性を吟味するレベルの作り込みには至りませんでした｡

今回: では､どういうモデルを作ったのか?

学習データの内訳

8x8Bモデルは､(up cycling前の学習も含めて)累計で1700 Bトークンを学習させました｡そのうち､100-200 Bトークン程度が合成テキストで､それ以外が､インターネット由来のテキストデータです｡Webデータの大半は､CommonCrawl系の日英テキストです｡

合成テキストは学習の終盤に投入しました｡把握している限り､最終盤の数十Bトークンは､全てが合成データです｡

合成データの効果

以下の図は､開発期間中の8Bモデルの性能推移を示したものです｡Web系のデータを中心にモデルを学習させていた中盤までは､ベンチマークのスコアは3以下で伸び悩んでいました｡この間､1 Tトークン程度のテキストを学習させました｡しかし､驚くほどスコアが伸びませんでした。


図: 開発中のモデルの性能推移(SFTや評価条件などはモデルごとに異なるため､厳密な比較はできない点に注意)

それに対し､対話中心の合成データを本格的に投入するようになってからは､ベンチマークスコアの顕著に伸びるようになってきました｡ベンチマークのみならず､実際のユーザーとの対話試験においても､「それなりに喋れるようになってきた*」という手応えがありましたし､なぜかPhase1ではできなかった四則演算も､結構できるようになるなど､色々と面白い改善がありました｡

指示形式の合成データも､通常のテキスト扱いで事前学習に投入しました｡next token predictionという点で､事前学習・事後学習は大差ありません*が､事前学習で用いる学習システム(今回はmegatron)の方が､事後学習で用いるtransformersライブラリよりも､遥かに高速(数倍以上)だったので､事前学習で投入しました｡

*instruction部分に対するloss maskの差もあります｡今回はmaskをつけずに普通に事前学習しました｡

どのような学習データを入れたのか?

データ合成は主に､Calm3-22B, WizardLM2 7B & 8x22B, Phi-3, Nemotron-4-340Bによって行いました｡特に､Calm3は流暢で素晴らしい日本語を生成できるうえに､サイズが比較的小型だったので､重用しました｡

合成データ作り方

合成データの生成法としては､色々なテクニックがあります(例えばこちら)｡以下に､WizardLM8x22Bモデルに対してランダムな役割やキーワードを与えて､自動で対話文を生成させるプロンプトと出力の例を示します(太字部分はランダムに変更)｡

system: あなたは主婦/主夫です。細かい配慮ができる性格です。

instruction: 複雑なロジックの問題と回答を生成しなさい｡ 問題と回答のみを出力し､それ以外は何も含めないこと｡

output: 問題: あなたは、5人の家族が集まる家庭の主婦です。家族の中には、肉を食べないベジタリアンが2人、魚を食べないペスカタリアンが1人、そして全ての食品を食べるアレルギーがない人が2人います。あなたは今夜の夕食で、トマトベースのスパゲッティ、チキンのグリル、サーモンのグリルを用意する予定です。これらの情報を考慮して、各家族に適切な食事を割り当てる方法を考えなさい

回答: 主婦は、各家族の食事制限を考慮しながら、以下のように食事を割り当てます。 - ベジタリアン1：トマトベースのスパゲッティ（肉が含まれていないことを確認） - ベジタリアン2：トマトベースのスパゲッティ（肉が含まれていないことを確認） - ペスカタリアン：チキンのグリル（魚を食べないため） - アレルギーなし1：サーモンのグリル - アレルギーなし2：サーモンのグリルまたはチキンのグリル（どちらも問題なしため） この割り当てにより、すべての家族の食事制限を満たしつつ、各自が食べられる食事を提供することができます。

以下は､Calm3によって自動生成したマルチターンの会話例です｡指示データとしても使えるデータセットですが､事前学習では､userとassistantの対話形式に変換して学習させることにしました｡

user: 問題: ある都市の不動産市場において、平均的な住宅価格は1,200万円であるとする。しかしながら、近年の経済成長に伴い、その価格が上昇傾向にあると報告されている。この情報を基に、「この都市の住宅価格の上昇傾向は今後も続く可能性が高い」という結論を支持するための論理的な根拠を考えてみましょう。どのような要因がこの傾向を支えると考えられますか？また、これに対する反論として考えられる点は何でしょうか？]

assistant: 「この都市の住宅価格の上昇傾向は今後も続く可能性が高い」という結論を支持する論理的根拠としてはいくつかの要因があります。まず第一に、経済成長そのものが大きな推進力となります。経済が成長すると一般的に人々の所得も増加し、それに伴って購買力も高まります。所得が増えれば、人々はより良い住環境を求めるようになり、その結果として住宅需要が増加します。これが供給を上回る場合、住宅価格が上がるのは自然な流れと言えます。 次に、人口動態の変化も見逃せません。例えば、若年層の人口が増えている都市は、新しい家庭や単身者向けの住居の需要が高まることが予想されます。特に都市圏では、利便性やアクセスの良さが重視されるため、そのようなエリアでの住宅需要はさらに強まるでしょう。さらに、リモートワークの普及により、郊外や地方から都心部へのアクセスが良い地域への関心も高まっているため、これも住宅需要の増加に寄与する要素となりえます。 インフラの整備や公共交通機関の発展もまた重要な要因です。交通の便が良くなると、その地域の価値が高まり、結果として住宅価格も上がります。加えて、政府の政策や住宅ローンの低金利政策なども住宅購入を後押しする要因となることが考えられます。これらの要素が複合的に作用することで、住宅価格の上昇が続く可能性は高いと言えるのです。 一方で、これに対する反論として考慮すべき点もいくつかあります。まず、経済的な不確実性の影響は無視できません。世界的な景気後退や金融危機が発生した場合、住宅市場は大きな影響を受ける可能性があります。このような状況下では、住宅の購入を控える人が増え、逆に売却を考える人も増えるかもしれません。これにより一時的にでも住宅価格が下落する可能性はあります。 また、供給側の要因も重要です。土地の供給には限りがあり、新たな住宅地の開発が進まない場合や既存の土地利用規制が強い地域では、住宅供給が不足し続けることになります。この場合、いくら需要が増えても価格が急激に上昇することは難しいかもしれません。 最後に、社会的な変化も無視できない点です。たとえば、少子高齢化が進む中で若い世代が減少している地域では、長期的には住宅需要が減少し、価格が下がる可能性も否定できません。このように、複数の視点から総合的に判断することが求められますが、現状の経済状況や都市計画などを踏まえれば、少なくとも短期・中期的には住宅価格の上昇が続くと考えるのが妥当ではないかと思われます。

user: 前提を少しだけ変えたときの結論について再検証してください

assistant: もちろん、前提を少し変えて再度検討してみましょう。今回は以下のような変更を加えます： 1. 「近年の平均的な住宅価格は1,500万円で、過去数年間で若干の下降傾向がある。」 2. しかし、今後の経済成長とともに再び上昇に転じる見込みがある。 3. また、特定の地域（例：新興開発地区）の価格動向が異なる場合がある。 4. さらに、政府の住宅支援策が導入されることで全体の市場に影響を与える可能性がある。 この前提に基づいて、「この都市の住宅価格の上昇傾向は今後続く可能性が低い」という結論を再度支持するために必要な論拠を考えます。 ### 住宅価格の上昇が見込まれない理由 1. 過去のトレンドの反転 - 過去数年で見ると住宅価格が減少または横ばいの傾向にあることから、現在の市場は過熱していない状態であると推測できます。これは、需給バランスが取れていることを示唆しており、急激な価格上昇が起こりにくい状況です。 2. 経済的不安定性 - 世界経済の不確実性が依然として高く、グローバルな経済ショックが発生するリスクが存在しています。例えば、貿易摩擦や地政学的緊張などが原因で景気が悪化した場合、住宅需要が一時的に落ち込む可能性が高いです。 3. 供給側の制約 - 新興開発地区での建設プロジェクトが計画通りに進行しない場合や、既存の規制によって新規建設が遅れるケースもあります。こうした供給制約があると、需要が増えたとしても即座に価格に反映されにくくなります。 4. 社会構造の変動 - 少子高齢化の進行により、一部地域で住宅需要が減少することも考えられます。特に高齢者の多い地域では、空き家が増える一方であり、それが全体の需給バランスを崩す原因になることもあります。 ### 反論としてのポイント 1. 限定された地域の例外 - 特定の新しい開発区域や人気のエリアにおいては、引き続き強い需要が見られる可能性があるため、全体としての均衡が崩れた場合でも局所的な価格上昇が起こる可能性があります。 2. 政府の介入 - 政府が新たに導入する予定の住宅支援策（低利率のローン提供や税制優遇措置など）があれば、中長期的に見て住宅市場にポジティブな影響を与え、価格の安定化や上昇を促進する可能性があります。 3. 技術革新によるコスト削減 - 建築技術や材料の進化により、住宅のコスト効率が改善される場合、供給コストが低下し、結果的に販売価格が抑えられる可能性もあります。ただし、これには時間がかかるため即効性は低いですが、長期的な視点では注目に値します。 以上のように、前提条件を変更してもなお、住宅価格の上昇が見込めない理由は複数存在します。これらを考慮に入れることで、より現実的な予測が可能になると言えるでしょう。

合成データのジャンルを絞った

前述の通り､合成データを投入することで､顕著にモデル性能が伸びることが分かりました｡それと同時に､開発モデルには、解くのが苦手なジャンルが存在することに気づきました｡それは､coding, extraction, math, reasoning, (writing)です｡

8x8Bの終盤での性能推移 (図は開発メンバーが作成)

これらのジャンルは､一般に小型のモデルが苦手とするタスクに対応します｡定性的な作文でOKなhumanitiesなどと異なり､厳密な出力が求めらるmathなどのタスクでは､一つでもトークン(例えば計算結果の数値)を間違えると､回答の結論が大きく変わってしまうからであると考えられます*｡

*extraction, writingには、入出力形式が厳密に指定されているタスクが含まれています｡実際､その大半は、適切な演習問題の学習無しには、解くことができませんでした。

いずれにせよ､漫然とランダムなジャンルで合成データを作るだけでは､解けないタスクが残ることが分かりました｡そこで学習の最終盤では､数学・コード・論理推論に焦点を絞ったデータ合成に注力しました｡当該ジャンルの性能はCalm3に近づいてきてしまったことから､数学・論理系では､より賢いモデルであるWizardLMでデータ生成をすることにしました｡

このような焦点を絞った特訓の成果もあって､mathでの性能の底上げなどに成功しました*｡

*とはいえ､まだまだ伸びしろがあり､個人的にはちょっと悔しい結果です｡数学・コード・論理系でCalm3先輩を大きく超えることが目標だったのですが､同等レベルまでしか持っていけませんでした｡

指示学習の戦略: out of domainに気をつける

事前学習の終盤の数十Bトークンは､ほぼ全て､Calm3, WizardLM, Nemotronによって生成された対話形式のデータでした｡

事前学習の段階で多量の対話データを学習済みだったこともあり､SFTでは､Calm3, WizardLM, Nemotronのデータを数万件ほど学習させるにとどめました｡これは文字通り､モデルをチャット形式で喋らせるためのスタイル変換の要素が強かったように思います｡

学習時に気をつけたのは､ドメインのズレ対策でした｡開発時の手応え､そして「モデル模倣」を戒める論文(The False Promise of Imitating Proprietary LLMs)などの結果を鑑み､事前学習から離れすぎたデータをSFTやDPOで使うのは､効果が薄いかもしれない(あるいは逆効果)ことが分かってきました｡

そこで､SFTにおいては､事前学習の段階で大量に学習させたCalm3, WizardLM, Nemotronの出力データを用いました｡また､DPOでは､「理想的な回答ではないが､モデルにとっての負担感が少ないデータ」としてTanuki自身の出力を使うなどの工夫*がありました｡強化学習に近い手法といえます｡

*複数回､Tanukiに出力をさせ､その中で良かったものをNemotronで自動で選ぶアプローチ｡これはチームメンバーが考案したものです｡そのうち記事化される(?)はずです｡

使わなかったデータ: 人間の手が入ったテキスト

把握している限り､人間が作ったテキストは､事前学習の最終盤､SFT､DPOでは一切使いませんでした｡これはある種の､out of domain対策と言えます｡

筆者は､大規模言語モデルはある種の「モノマネシステム」と捉えています｡色々なモノマネは可能ですが､今回は「丁寧な回答をするアシスタント」として振る舞ってもらうことが目的でした｡そのため学習の最終盤では､当該目的から逸れる情報は基本的にノイズになると判断し､入れないように心がけました｡

事前学習から人造データを抜く

モデルは一度覚えたことは意外と覚えている一方で､その重み状態について､「モメンタム」のようなものを持っているように感じます｡例えばネット文章を直前に多量に学習させると､ネット風の文章を出力する傾向にある､という傾向です*｡しかも､この「モメンタム」は数万件程度のデータ学習では変わりきらないことが示唆されました｡

今回のチャットボットにはネット風の文章*を書くことはほとんど期待しておらず、丁寧で正確な返答を期待していました。そこで事前学習の最終盤では､数Bトークン以上､チャットボットとしての対話データのみをひたすら学習させることにしました｡

*CommonCrawlやWikipediaなどに含まれる文章の大半は､明らかにチャットボットとは異なるスタイル・口調で記述されています｡なので､抜くことにしました｡

実際、学習の終盤頃､試しに汚いCommonCrawlデータを学習させたところ､一時的に､同じ表現を繰り返すなど､出力内容が一気に悪化したことがあります(その後､追加で合成データを学習させなおしたところ､幸いなことに挙動は元に戻りました)。この件もあり、モデル構築の最終盤におけるCommonCrawlの学習は避けることにしました(下図)｡


図 モデル構築終盤における､SFT前の8x8BモデルのJapanese MT-Benchのスコア変化・赤棒が､汚めのCommonCrawl系データを学習させた直後の性能 (図は開発メンバーが作成)｡

SFTから人造データを抜く

例えばわかりやすいのが､指示データとして有名なdatabricks-dolly-15k-jaです｡

本データセットには､例として以下のような対話が含まれています｡

Q. 魚の種類はどっち？イコクエイラクブカとロープ

A.イコクエイラクブカ

こちらのやりとりは､返答自体は正しいのですが､ぶっきらぼうすぎます｡もし仮にChatGPTがこのような回答ばかりを返したとしたら､ユーザー数は激減するはずです｡

以上のように､「丁寧な回答をするアシスタント」としての要件を満たさないデータは､モデル性能を著しく悪化させるリスクがあったので､注意深く抜く必要がありました｡

DPOから人造データを抜く

驚いたのが､Calm3などが生成した文章に人間が手を加える行為すら､結果的にはモデルに悪影響だったということです｡プロジェクト中､ChatBotArenaのような形式で､与えられた質問に言語モデルが回答し､ユーザーが評価するというシステムを運用しました｡そこで得られた回答を更に人間がブラッシュアップするという作業も行いながら、丁寧にchosen/rejectedfのDPOデータを作りました。

一見すると､これはかなり高品質なデータに見えます。しかし実際にこのデータを学習させてみると､モデル出力が悪化するという結果しか得られました｡正直､何が悪かったのかの総括までは出来ていませんが､言語モデルのデータに対して下手に修正を加えてしまうと､それがもとでモデルが混乱する可能性もあったのではないかと､考えています｡ある種のout of domain問題です。

まとめと今後の展望

まとめ

本記事では、モデル構築に合成データを積極的に使用するに至った経緯などについて記しました。

実際、今回開発したモデルTanuki-8B, 8x8Bの終盤に投入したテキストは全て､合成データでした｡これは本文中に記載の通り、開発時の手応えや､過去の研究成果などに基づく総合判断によるものです｡

このアプローチが功を奏した(?)ようで､少なくともJapanese MT-Bench上では高得点をマークするモデルが得られました｡ベンチマーク問題のみならず、(時間の都合上､十分な評価はまだ行えていませんが)､実際にチャットボットとして運用した際にも、それなりに良い出力を観測できています｡

今後の展望と課題

  1. 高度なタスク（数学、コーディング、論理的思考）における徹底的な事前学習
  2. 既存の優秀なモデルが存在しない領域での推論能力の向上

これまでは、Calm3やWizardLMといった先行モデルの背中を追いかけることで進歩を遂げられました。しかし、モデルの性能が飛躍的に向上した今は、新たな挑戦に直面しています。それは、優れた教師モデルが存在しない領域、AIにとっても人間にとっても難解なタスクに、いかにして取り組むかという課題です。

この状況は、「専門家レベルの能力を持つ言語モデルの開発」という、海外の先駆者たちが挑戦し続けているフロンティアに足を踏み入れつつあることを示唆しています。やっと、世界レベルで戦うための足がかりができてきた、という状況でしょうか。

おまけ

以下、本文内ではうまくまとめきれなかった、より雑多な事項に関する所感を記します。

理想的な学習データ量を考える:　Chinchilla lawからの脱却

適切な事前学習のデータ量を考える上で、しばしば取り上げられる目安として、Chinchilla lawの論文があります。この論文は、総合的な学習効率やコスパを鑑みると、学習に使うデータのトークン数はモデルサイズの20倍程度が良さそう、という経験則を提起するものです。例えば10 Bパラメータのモデルであれば、200 Bトークンのデータ学習が目安ということになります。

ただしこの論文の主張は歴史的に見ると、「一つの通過点」に過ぎず、今日においては、むしろこの主張に引っ張られすぎない方が良いのではないかと思うようになりました。当該論文のもともとの位置づけは、GPT-3の学習データ数がパラメータ数と同程度だったという当時の「最新知見」に対して、「データ量もっと増やすことができて、パラメータ数の20倍くらいはいけますよ」と提案するものでした。ただしその後､Llamaなどがパラメータ数の100倍以上のデータを学習させる成功事例を次々と報告しています｡つまり､トップレベルのモデル開発において、Chinchilla lawは「過去の遺物」となった印象*です。

*これとは別の視点として、論文のデータ処理などに、そもそも問題があるのではないかと議論する報告も出始めています。

今回の開発を通した手応えでも、Chinchilla lawが勧めるデータ量は全く不十分だったというのが率直な感想です。例えばTanuki 8Bのパラメータ数は7.5Bなので、150 Bトークンのデータ量が目安ということになります。それに対して今回は1300 Bトークン程度のデータを学習させました。そのうち､一般的なWebテキストが1100-1200 Bトークン、合成データが100-200 Bトークン程度です。

今回の取り組みでは､モデルの対話能力を向上させるためだけに、Chinchilla lawが勧めるデータ量(≒合成データ100ー200 Bトークン程度)を学習させる必要がありました。しかも、まだまだモデル性能が伸びそうだという手応えがあります。例えば数学・論理・コード系の合成データを追加で100-200B トークンほど学習させれば、MT-Benchでも高得点を取れるような期待感があります。

そもそもChinchilla lawは、特定のデータセットについて、特定の学習率・データセット・アーキテクチャでlossが効率的に下がる条件を調べることを趣旨とした論文です。それに対し、実際のモデル開発では、生成させたテキストのジャンルごとにターゲットとなるlossが異なるほか*、性能評価はlossという抽象的なパラメータではなく､出力内容そのもの(テキストの品質)で行うなどの違いがあります。雑多なWebテキストを予測する能力が高い(全体的なlossが低い)からといって､デプロイ後の実際の対話で求められるテキストを生成する能力が高いとも限りません｡

以上のように､実際の運用を考えるにあたっては､ざっくりと全体のlossのみを考えるだけでは不十分らしいことが分かってきました｡加えて､しばしば指摘されるように､学習のみならず推論コストも含めた総合的なシステム設計が必要になります｡こうした現実系とのズレを鑑みると､Chinchilla lawは､old-fashionedになりつつあり､あまり囚われすぎない方が良いのではないかと､考えた次第です｡

*例えば数学系のジャンルでは数値の計算ミスがあってはいけないので、lossはゼロを目指すくらいの追い込みが必要そうなことがわかってきました。それに対し、クリエイティビティが求められる作文タスクでは、lossがあまりにも低すぎると出力の多様性が損なわれるリスクが増えます。このように、解きたいタスクやジャンルごとに、要求されるprediction lossが異なる可能性があります｡

理想的なモデルサイズを考える

8B vs. 8x8B どちらが賢いか?

開発を通して、最後までわからずじまいだったのは、大規模言語モデルの理想的なモデルサイズはどのぐらいがよいか、という問いに対する回答です。

今回の開発では、8B (正確には7.5B)、8x8BのMoE (総パラメーター数47B, アクティブパラメータ数13B)のTransformer系のアーキテクチャを選択しました。8x16個のH100 GPUを用いると、8Bは1日あたり60 Bトークン、8x8Bは30 Bトークン程度の学習が可能でした*。

*脱線話題｡今回のプロジェクトにおいて､速度面では､かなり保守的な設定で学習しました。最近はTransformerEngineなどを使った8 bit計算が主流になりつつあるようで、数十%程度の高速化が可能です。しかし今回は学習の安定性を優先して、8 bitの使用は見送りました。その理由として､開発の初期頃にTransformerEngineを使って38Bパラメータモデルを事前学習していたのですが、loss spikeが頻発して中止した経緯があります。そこで安全策を取って、8B, 8x8Bの学習では使用しないことにしました｡loss spikeの発生要因は複合的なので､結局何が悪かったのかは整理しきれていないものの､開発プロジェクトは「絶対に失敗してはいけない」ので､危険な因子は可能な限り､取り除く必要がありました｡このあたりの詳しい経緯についても、どこかのタイミングで執筆できればと思います。学習効率とモデル崩壊のリスクはトレードオフの関係にあることを思い知った経験です。

今回のプロジェクトで構築した2つのモデルは異なる学習履歴を持っています｡累計で8Bは約1300Bトークン、8x8Bは約1600Bトークンを学習させました。ただし、学習の最終盤のRunでは、たまたま、全く同じデータセット(数学・論理・コード系)を投入することになったので､このデータに対する予測性能の差を定量的に比較できます。その際のtrain lossの挙動は以下のとおりです。

8x8Bモデルは、8Bモデルよりも、学習lossが0.1程度小さくなりました。これはモデルがlossの差分だけ、精密にテキストを生成可能なことを意味します。

一方でJapaneseMT-Benchの結果を見てみると、両モデルの性能差は0.4程度と、大きな差はないことが分かりました。

項目別に見ると､顕著な性能差が生じたのはextractionとmathで、8x8Bの方が1程度、スコアが高いという結果になりました*。extractionとmathでは出力の厳密さが特に問われるので、lossが低いモデルほど有利という解釈が成立しそうです。それ以外のジャンルについては、スコアはほぼ同じとなりました。

*ちなみに、この差を出すためにも、かなり苦労しました。多くのファインチューニング条件では、8B, 8x8BでMT-Benchのスコアは同程度になりました。

MT-Bench以外の項目についても見てみます｡Leaderboard3というベンチマークでの総合性能を比べてみると、8Bと8x8Bで有意な性能差(0.1程度)が観測されました。この差は､特にJaster系のベンチマークでの性能差に由来することが分かっています。知識や言語理解の能力､あるいはベンチマーク問題に対する指示追従性が､8x8Bの方が高いことを示唆する結果です｡


ただしここで注意しなければならないのは､Jasterなどのベンチマークは､テキストの生成能力を殆ど評価していないという点です｡対話や作文､プログラミングなどのタスクは含まれておらず､単語を答えるクイズの成否を問うような､実際のチャットボット運用からは､やや離れた評価が大半を占めています｡チャットボットのユーザー体験はJasterというよりは、むしろ実践的な対話を想定したベンチマークであるMT-Benchの性能と強く相関する可能性が高いです｡

以上､8Bと8x8Bにおいて、MT-Benchではmath, extraction項目以外では顕著な性能差が観測されなかったことを鑑みると、実は大半の対話タスクは8Bで十分にこなせるかもしれない､という仮説が生じます｡

8Bと8x8Bの性能差は?

8B, 8x8BモデルはJapanese MT-Bench上では性能差の少なかったので､両者の違いをもう少し多角的に評価する必要が生じました｡そこで最もダイレクトな方法として､構築したモデルと実際にチャットしてみることにしました｡

以下の表は､ユーザーの質問に対して､ランダムに選ばれた2つの言語モデルが生成した回答の優劣をつけるシステムで得られた戦績をまとめたものです*｡

*ChatBotArena的な自家製システムを構築しました｡

まだデータ数などが足りないため､確定的なことは言えませんが､暫定的な性能の序列はCalm3>Tanuki-8x8B>Tanuki-8Bとなりました｡Tanuki-8x8BはMT-BenchでCalm3を超えるケースもあったのですが､総合的な実力では､まだ及ばなかったようです｡残念｡

8x8Bと8Bを比べると､実際の対話タスクでは前者の方が優れていることも分かりました｡

内容の正確性や指示追従性に加えて､総合的な作文の「センス」で差がついている模様でした｡

今後､さらに検証件数を増やした上で､実際のユーザー体験を通した性能序列とベンチマークスコアの関係性などについて､細かく解析していく予定です｡

理想的なモデルサイズは?

今回の開発では8x8Bモデルの性能の方が8Bよりも若干、高性能らしいという結果となりました。この差は､モデルサイズと学習データ量の違いで説明できそうです｡

ところで､シビアな視点で振り返ってみると、学習効率という面では、諸々苦労して8x8Bを学習させるよりも、実は半分の計算コストで学習できる8Bにリソースを全投下して、2倍のトークンを学習させるという戦略の方が、実は合理的だったかもしれない可能性*を捨てきれません。

*これは､モデルサイズー学習効率ー性能限界の関係がまだまだよくわかっていないことに起因する悩みです。今後の体系的な検証が求められます。

言い換えると、今回の開発経験を踏まえてわかったのは、「モデルサイズは不用意に大きくする必要はないかもしれない」という示唆です。最近の国外モデルの動向を見ても、小型のモデルで高性能な推論ができてしまう*ことがわかってきました。実際､無駄に大きなモデルは、学習・推論面でかなり不利です。

*最近の小型の言語モデル(Llama3.1-8bやgemma-9bなど)の躍進は素晴らしいです。このサイズ帯のモデルの性能限界がどこにあるか、本当によくわからなくなってきました。

では現実問題として、何を基準にモデルサイズを決めれば良いのか?

筆者の考えでは、準備できるデータベースのサイズが、一つの重要な制約条件となります。上質なテキスト、特に対話・論理推論・数学・専門知識などは、基本的に枯渇気味なので、データ供給がボトルネックです。

データ不足に対する対応策は、a)頑張って追加データを準備する、b)モデルの学習効率を上げるの2つです。a)については、データ合成の技術が進歩しています。しかしそれでも、供給可能なテキストの質と量には限界があります。一方で学習効率、すなわち供給トークンあたりのlossの低下速度は、単純にモデルサイズを増やすだけで改善可能です。なので、a)データを気合で増やしつつ、b)モデルサイズも大きくする、という合せ技が現実的には必要そうです。

以上をまとめると、単純に推論精度のみを最大化させることを考えた際の理想的なモデルサイズは、

「投入できるコーパスのトークン数」 / 「学習に使える計算リソース」 (x定数)とするのが、良いのではないかということです。

(→ ある意味では当たり前の結論が得られました)

今後のモデル開発の方向性について考える

今後のモデル開発の方向性は大きく2つに分かれそうです。一つ目は、a)GPT-4を超える賢いモデルの追求(さらなる高性能化)、2つ目は、b)GPT-4並に高性能かつ小型なモデルの構築(学習の効率化)です。a)の高性能化は、OpenAIやGoogleなどが社運をかけて目指していそうです。

これに対し、本プロジェクトを含む最近の多くの国際的なモデル開発は、b)GPT-4レベルのモデルにいかに効率的にキャッチアップするかの競争とも位置づけられそうです。その鍵となるのが恐らくデータ合成で、教師となるモデルの出力を、いかに効率的に模倣するかの手腕が問われます。やることは基本的にAIの模倣ですので、あと1-2年以内くらいには、数十Bクラスのモデルサイズで、「GPT-4レベル」のオープンモデルが登場する可能性がありそうです(その公式版が、GPT-4o, miniでしょうか)。

GPT-4はそれなりに賢いので、このレベルの人工知能を低コストで供給し、カスタマイズできるようになれば、社会実装という意味で、十分なインパクトを残せる可能性があります。

b)の効率化に対し、a)GPT-4よりも賢いモデルを作るというタスクは、なかなかチャレンジングです。教師となるモデルが存在しないため、単なるモデル模倣は使えません。ここでは、GPT-4よりも賢い存在(≒専門家など)からフィードバックを集める作業が重要になります。加えて、学習効率を上げるためのモデルサイズの増大や、新たなアーキテクチャの探索なども欠かせません｡

以上､モデルのa)高性能化、b)効率化は、目指すところは異なりますが、上質な学習データを準備して、学習の精度を上げるという方法論自体は共通しています。なので、各組織とも、高性能化と効率化の両輪で、研究開発を行っているような気がしました｡

謝辞

今回の大規模言語モデルの開発にかかる成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業「ポスト５Ｇ情報通信システム基盤強化研究開発事業」（JPNP20017）の結果得られたものです。

東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]
東大松尾・岩澤研究室 | LLM開発 プロジェクト[GENIAC]Publication

東京大学 松尾・岩澤研究室が運営する松尾研LLMコミュニティのLLM開発プロジェクト[GENIAC] の開発記録、情報発信になります。 各種リンクはこちら linktr.ee/matsuolab_community

Discussion