サイバーエージェントが手がける日本語LLM開発　MLエンジニアが語る「Weights & Biases」の活用

登壇者の自己紹介とアジェンダの紹介

石上亮介氏：それではサイバーエージェントの石上から、「CyberAgentにおける日本語LLMの開発」というタイトルで発表いたします。

あらためまして自己紹介ですが、私は石上と申します。現在は、サイバーエージェントの基盤モデルプロジェクトのリードを担当しています。

基盤モデルというのは、大規模なAIでさまざまなタスクがこなせるという、いわゆるすごいAIなんですね。今日は特にLLMですね。大規模言語モデルについて、どういう取り組みをしているかをお話しいたします。

サイバーエージェントのLLMの開発に関するリリースをいくつか出しています。例えばH100ですね。「NVIDIA DGX H100」というGPUリソースを社内に導入しました。

あとは2023年5月ですかね。（2023年5月に）、68億パラメーターの日本語LLMを一般公開したというところで、いくつかリリースを出しています。本日は、特にこの右側のLLMの開発についてや、2023年6月以降にどういった進展があったかについてをお話しさせていただきたいと思います。

そもそも大規模言語モデルとは何か？

トップバッターということで、そもそも大規模言語モデルとはどういうものだっけ？　とか、どういうふうに学習させるんだっけ？　というのを簡単に振り返りたいと思います。

まずは、大規模言語モデルの中で代表的なGPT-3についてですが、GPT-3はOpenAI社が2020年に発表した大規模言語モデルです。学習の仕方ですが、ある文章に続く文章を予測するタスクを解かせるということで、例えば「サイバーエージェントは」という入力があった時に、その続きとして、「21世紀を代表する会社を創る」という文章を予測する、非常にシンプルなタスクを解かせています。

非常にシンプルではありますが、文章生成、要約、翻訳など、さまざまなタスクが解けるようになっています。1億パラメーターから1,750億パラメーターという非常に大きなサイズでこのような学習を行うことによって、このようなさまざまなタスクが解けるようになったと報告されています。

（スライドを示して）こちらがいわゆる大規模言語モデルにおける事前学習と呼ばれるステップなのですが、事前学習を行ったLLMには課題があります。事前学習を行っただけの素のLLMは、指示を出してもうまく従わないことが多いです。私たちが「ChatGPT」などといわゆる対話を行う時というのは「〇〇について教えてください」とか「〇〇してください」と指示をして、それに対するアウトプットをもらうという使い方をしていると思うんです。

ですが事前学習を行っただけだと、なかなか指示に従ってくれないというところが知られています。こちらですが、Webのテキストを中心に学習されているので、いわゆる文章の続きを生成したり、似たような文章を繰り返してしまう傾向や、文章をどこで終わらせるかがうまく判断できないという特徴があります。

こうした性質は、Googleの開発した「PaLM」と呼ばれる、5,400億パラメーターという非常に大きなモデルでも知られていて、素のLLMにはこうした課題があります。一方で、そうしたモデルに対してInstruction Tuningという指示形式の学習を行うことにより、適切な応答を返すようになります。

ChatGPTのいわゆる賢さに対して私たちユーザーが思うところは、まずは1つ目として指示チューニング、Instruction Tuningが非常に大きな部分を占めています。

Instruction Tuningの他に、さらに性能を上げるコツとして、Alignment Tuningという手法があります。手法というか概念、コンセプトですね。

より人間にとって使い勝手を良くしたり、より人間の価値観に合う出力をさせたりするために、例えばHelpful、Honest、Harmlessのような、人間にとってより正しいとされる基準を基にチューニングを行うというのがAlignment Tuningです。

具体的な手法として、レインフォースメントラーニング。強化学習のような手法が使われることもあります。というわけで、私たちが使っているChatGPTのような便利なLLMは、元をたどると大規模言語モデルというのがあって、これは事前学習として文章の続きを予測させるという、非常にシンプルなタスクを解かせています。

そうして出来上がったLLMに対して、指示形式でのチューニングや、より人間の価値観に合わせる学習や、対話形式ですね。チャットの場合は対話形式でチューニングを行うことによって、ChatGPTのような便利なLLMはできています。というわけで、ここまでが5分でわかるLLMでした。

事前学習をうまく行うためにはコーパスが必要

というわけで本題ですが、CyberAgentLM（CALM）の開発について、ここからお話ししたいと思います。

先ほども述べたとおり、言語モデルの開発の流れというのは事前学習、それから指示データによる追加学習というステップを踏みます。

事前学習をうまく行うためには、学習のデータであるコーパスというものを整備する必要があります。例えばLLMの学習に使われるコーパスとしては、（スライドを示して）このようなものが挙げられます。日本語のデータセットとしては、Wikipedia、mc4、CC100のようなデータがありますし、海外の英語のデータセットとしては、Pile、Redpajama、それからRefinedwebと言われるようなデータセットがあります。サイズを比較してみると、最近出てきたRedpajamaやRefinedwebは5TBということで、非常に大きなコーパスとして存在しています。

一応日本語でも、例えば830GBのmc4など、そこそこのサイズのコーパスはありますが、実はこのmc4に関してはかなりノイジーなデータ、汚いデータが含まれているので、コーパスのクリーニングを行う必要があります。

コーパスのクリーニングというのは、例えば左側が元データとしてあった時に、メールアドレス、Webサイト、コメント送信などの不要な文字列を削除してあげたり、そもそもそのページ全体がLLMの学習には適さないというのも多分に含まれているので、こうしたものに対して事前にクリーニングを行う必要があります。

実はこのコーパスのクリーニングは、LLMの学習にとっては非常に重要なポイントとなっていて、例えば先ほど挙げたRefinedwebというデータセットだと、このように何段階もフィルタリング処理を経て、より高品質なデータセットを作るということを行っています。こうして出来上がったデータを使って、次はLLMの事前学習を行っていきます。

今現在、事前学習のためによく使われているライブラリとして、（スライドを示して）このようなものが挙げられると思います。例えばNVIDIAのMegatron-LMは、非常に有名なライブラリで、microsoft/Megatron-DeepSpeedやgpt-neoxというライブラリは、基本的にこのMegatron-LMをベースにして作られています。

あとは最近だと、mosaicmlからllm-foundryという新しいライブラリも出てきています。最近は弊社も含めて、日本語のLLMもいろいろ出ていると思いますが、開発でよく使われているのは、このgpt-neoxかと思います。

CyberAgentLMでは「Weights＆Biases」を活用

というわけで、ようやくCyberAgentLMの話です。5月に公開したCyberAgentLMは、パラメーター数がモデルの大きさを表す指標になっていて、CALM-Smallから130億パラメーターまでを構築しています。学習データとしてはWikipedia、mc4、CC100などを使っていて、学習にはNVIDIA A100を数週間から数ヶ月、それぞれ使っています。

pplというのはざっくりと言うと、性能を表す指標と考えていただいていいのですが、それが小さいほど良いということで、パラメーター数が増えていくごとに性能が上がっていることが確認できます。この中で70億パラメーターまでのモデルを「Huggingface Hub」にて、5月に公開したというニュースが、冒頭で紹介したリリースです。

実際に開発を行っていくと難しい部分が非常に多くあり、例えば学習途中で勾配爆発で失敗してしまうということがあります。こちらはロス曲線ということで、下がっていくと学習がうまくいっているよというところになるのですが、横軸が時間ですね。時間が減るごとにロスが下がっているように見えるのですが、突然爆発してしまうということが起きてしまいます。

こうなってしまうと、やり直しがきく場合もありますが、きかない場合ももちろんあります。そうなるとコストや時間をかけた実験が無駄になってしまうということで、非常に大きな問題となっています。こうした問題というのは、例えばAIベンチャーのABEJAさんや、アカデミアの方々のLLMを作る取り組みの中でも報告がされていて、うまく学習させるようにいろいろと試行錯誤をする必要があります。

ちなみにこうしたモニタリングや、実験がうまくいっているかというところで役に立つのが、「Weights＆Biases」というサービスです。具体的にWeights＆Biasesで具体的に使っている部分として、例えば実験の比較ということで、さまざまな条件を変えて実験を比較してどういう違いがあるかを視覚的に非常にわかりやすく可視化できます。

あとはこのような実験をレポートする機能があって、レポートにまとめることで、チーム、もしくは外部の人向けにわかりやすくそのまま伝えることができるので、非常に欠かせないものになっています。

あと、個人的に非常に重宝しているのが、学習失敗時にメールで通知をしてくれる機能です。こちらは「学習が失敗して何分後」という設定ができるのですが、失敗したらこういうふうにメールが届いて、例えば出先であってもすぐに確認して、接続して、実験をやり直すことも可能です。ちなみにこちらの通知機能は、メール以外にも「Slack」や、その他の媒体にも通知を飛ばすことができるので、いつでも学習を見守ることができ、LLMの学習の際には非常に役立つ機能となっています。

学習の最後の段階でCALMのInstruction Tuningということで、最後に指示形式でCALMをInstruction Tuningしてみました。ということで、（スライドの）左側が学習データとなっていて、例えば「小規模なビジネスの起業についてアドバイスを教えてください」。「小規模ビジネスを起業するには、以下のアドバイスがあります」というような、指示と応答形式のデータを学習させる。

学習させることによって、（スライドの）右側が生成例になるのですが、例えば「魅力的な広告を作るコツを教えてください」と書くと、「以下のようなコツがあります」ということで、指示にうまく従って回答してくれるようになりました。ということで、事前学習からInstruction Tuningまで日本語モデルを作って、そこから指示形式でチューニングを行うことができたというのが結果です。

次の世代の言語モデル「CALM2」を開発中

というわけでここまでが、6月までにやっていたり、紹介していたことなのですが、ここから新しい取り組みについてお話ししたいと思います。

今現在、CALM2と呼ばれる次の世代の言語モデルを開発しています。（スライドの）左側がCALM1、そして右側がCALM2ということで比較しています。大きな違いとしては、アーキテクチャがLLaMaベースに変わったり、あとはcontext_lengthが2,048から4,096と2倍になっていたりします。

他に大きな違いとしては、学習データ量を10倍以上、1兆トークンと10倍以上に増やして学習を行っています。ちなみに（スライドの）右側が、CALM2の学習曲線なのですが、1兆トークンまで学習させてもロスがどんどん下がっている状況で、学習データをどんどん増やしてもまだまだ性能が伸びそうだぞということがわかってきています。

ちなみにCALM1の時はA100を使って1,000億トークン学習させていたのですが、CALM2は社内にH100と呼ばれる新しいGPUを導入して、1兆トークンという大きなデータ量も学習させられるようになっています。H100とA100の速度比較を社内で行いました。（スライドを示して）こちらがLLMの学習においてA100、8枚と、H100、8枚を比較したものです。

いろいろ指標はあるのですが、例えばflops計算で計算すると、だいたい約2.57倍というところで、かなり効率的に学習ができるようになっています。H100の新たな機能として、Transformer Engineと呼ばれる機能があり、こちらはトランスフォーマーアーキテクチャの学習により特化して効率的に学習が行える機能で、ちょっとまだ検証はできていませんが、こちらを導入することで、さらに高速化するんじゃないかと期待をしています。

CALM1とCALM2で性能はどう違うのか

というわけで、CALM1とCALM2で、どのくらい性能が変わったのかという話ですが、こちらは複数タスクで評価を行っています。（スライドの）左側のJGLUE、OpenQA、RCQAが日本語のタスク、それからARC、HellaSwag、TruthfulQAが英語のタスクです。CALM1とCALM2を比較すると、平均スコアがだいたい20ポイント以上上がっていて、かなり性能が高くなっています。

例えばJGLUEで見てみると、20ポイントほど性能が上がっていて、学習データ量や学習自体にも工夫をいろいろと取り入れているのですが、行うことによってかなり性能が高くなっています。

次は、Ablation studyということで検証したものですが、英語データと、日本語データのサンプリングの割合の違いを検証してみました。ここでは2つのモデルを比較しています。1つ目が日本語を中心に学習したモデル、2つ目が英語を中心に学習したモデルで、それぞれパラメーター数は70億パラメーターで、学習データ量は1,000億トークンとなっています。

その内訳として、モデルA（日本語中心）は日本語が57パーセント、英語が31パーセント。英語中心のモデルは日本語が33パーセント、英語が55パーセントという割合になっています。（スライドの）下に結果を載せていて、このタスクについては先ほどのスライドと同様で、わかりやすいと言えばわかりやすい結果なのですが、モデルAについて日本語を中心に学習したモデルは日本語のスコアが高い。

英語を中心に学習させたモデルは、英語のスコアが高いことがわかりました。当たり前と言えば当たり前かもしれませんが、ここで考えるべきことは、じゃあ実際にそのLLMを大規模に学習させていく場合、英語データと日本語データをどのぐらいの割合でサンプリングしたらいいのか。これは考えないといけないことかなと思っています。

いろいろ考え方はありますが、例えば海外、中国で、いわゆる英語と中国語のバイリンガルモデルの学習において、学習初期には英語を中心に学習させつつ、学習を進めていく上で中国語ですね、第一言語を増やしていくというやり方がされている場合もあります。なので、どういうダウンストリームタスクなのかにもよりますが、どういう性能を伸ばしていくために、どういう割合でそれぞれサンプリングしていくかとは非常に重要なポイントかなと思います。

FullファインチューニングとLoRAチューニングを比較

最後に、実験結果をもう1つ。CALM2-7Bを指示データセットでFullファインチューニングした場合と、LoRAチューニングした場合を比較しています。こちらはタスクとしてStability AIの方が公開してくださっている、LLM Judgeと呼ばれるものを使っています。

例えばMath、Coding、Reasoningのような、それぞれのカテゴリについて指示に対する応答結果をGPT-4で評価するものになっています。なのでここでは8タスクですね、8タスクのそれぞれの指示の応答結果の平均のスコアをGPT-4に評価してもらっています。

CALM2-7Bを指示データでLoRAチューニングをした場合、LoRAチューニングは、効率的な学習手法となっています。一方で、Fullファインチューニングは、パラメーターをすべて学習させる場合です。結果を比較すると、LoRAチューニングの場合はスコアが3.49、Fullファインチューニングの場合はスコアが4.95ということで、実はLoRAチューニングとFullファインチューニングでも、けっこう大きな差が出る場合があります。

ちょっと注意が必要なのは、LoRAチューニングは社内でもけっこう検証を行っているのですが、LoRAチューニングはけっこうデータの質、データの量、それからハイパーパラメーターの選択の仕方によって、かなりスコアにばらつきが出てしまうので、さらに深掘りする必要があります。

データの種類や性質によっては、Fullファインチューニングのほうが性能が出る場合もあるので、じゃあどうすればいいのかという話なのですが、計算リソースが限られている場合は、LoRAチューニングを選ぶ。計算リソースに余裕がある場合はどちらも検証してみて、ダウンストリームタスク、実際のタスクで、どういうふうに性能が出るのかを検証すべきかなと思います。

まとめ

というわけでまとめです。サイバーエージェントにおけるLLM開発について紹介しました。性能の高いLLMの構築には、データと計算リソースがポイントということで、飛躍的に性能を伸ばすためには、例えば1,000億トークンから1兆トークンに増やしたり、計算リソースをきちんと確保して大規模に学習を行うことが大事です。

今日は時間が限られているので、すべてを話しきることができなかったのですが、今後はトランスフォーマー以外の新しいアーキテクチャや、マルチモーダル化など、まだまだLLMの発展のためにやるべきことはたくさんあるので、引き続きサイバーエージェントとしても取り組んでいきますし、こうした機会でこうした知見をどんどんと共有していければなと思っています。というわけでご清聴ありがとうございました。

（会場拍手）