日本語MoEモデルの開発と「実りある失敗」

はじめに

ELYZA 研究開発チームのSam (@SamPassaglia)、平川 (@h__must__)です。

本記事では、日本語に特化した Mixture of Experts (MoE)モデル構築への挑戦、およびアプローチの転換を余儀なくされた経緯について解説します。

ELYZA は、日本の生成AIの開発力強化を目的とした経済産業省主導のプログラムである Generative AI Accelerator Challenge (GENIAC) に採択され、H100数百基をはじめとする計算資源の利用や関係者間の連携促進等のご支援をいただきながら、2024年5月から8月までの約3ヶ月間に渡り日本語汎用基盤モデルの開発を行いました。

私たちの当初の計画は、オープンソースの MoE モデルの最高峰である Mixtral 8x22B をベースに、日本語に特化した高性能な MoE モデルを構築することでした。しかし、実験の途中経過は予想外の展開を見せ、アプローチを転換することになったのです。最終的には、以下のブログ記事にあるように、Depth-Up Scaling を活用して Llama-3-120B という強力なモデルを構築することができました。

Depth Up-Scalingを用いた「Llama-3-ELYZA-JP-120B」の開発

ここでは、Mixtral 8x22B を採用した背景、Mixtral 8x22B の日本語最適化に向けた予備実験、そしてMoEモデル構築というアプローチから方向転換せざるを得なくなった経緯について詳しく説明します。

なお、本ブログに関する研究開発は、中村 (@tyo_yo_)、佐々木 (@hikomimo)、大葉 (@dai0NLP)、Sam、平川で取り組み、Sam、平川が代表して執筆しました。プロジェクトにおける開発環境の整備等は、developmentチームの堀江 (@eemon18) と高橋が担当しました。

Mixture of Expertsとは

GENIACのために構築したモデルの説明に入る前に、MoE とは何か、そしてなぜ言語モデルコミュニティでこれほど認知を獲得しているのかを解説します。

モデルサイズを大きくすることは、モデルの能力を向上させる確実な方法の一つです。しかしながら、モデルサイズを大きくすると訓練と推論のコストが増加するため、限界が生じてしまいます。MoE では、全パラメータの一部だけでトークンを処理することで、この問題の解決を試みています。

典型的な MoE モデルでは、Transformer の Feed Forward 層が Expert と呼ばれる複数のサブセットに分割されます。Feed Forward 層への各入力トークンは、すべてのExpertではなく、一部のExpertによってのみ処理されます。これにより、トークンあたりのアクティブな Expert 数（i.e., 計算コスト）を一定に保ちつつ、 Expert の総数を増やすことで、モデルの総パラメータ数を増やすことができます。

（https://arxiv.org/abs/2401.04088 ）

ベースモデル選定

最適化の際は、ルーティング層が各入力をどの Expert に送るかも最適化の対象とします。Expert は異なるタイプの入力を扱うよう暗黙的に学習されるため、MoE モデルは標準的な Transformer モデルよりも少ない訓練計算量で同等の Loss に到達できることが経験的に示されています（Switch Transformer）。同様に、一定の推論コスト予算内では、MoE モデルは一般的に密なモデルよりも優れたパフォーマンスを発揮します。

私たちも、言語モデルを低価格でかつ高速に推論できる手法として MoE に着目していました。

ELYZA の戦略は、強力な事前学習済みのオープンモデルをベースに、日本語に特化した言語モデルを構築することです。このプロジェクトを計画していた時、幸運なことに強力な MoE モデルが利用可能になりました。それが Mixtral です。

フランスのスタートアップ、Mistral AI社が開発した Mixtral は、MoE に基づいて最先端の性能を実現した最初のオープンモデルの一つです。Mixtral は2つのモデルサイズでリリースされており、小さい方の Mixtral 8x7B モデルが2023年12月に、次いで大きい方の 8x22B モデルが2024年4月に公開されました。

このプロジェクトの計画を始めた時点で、Mixtral 8x22B は様々なベンチマークで最高水準の性能を達成した強力なオープンソースモデルでした。革新的なアーキテクチャ、高い性能、寛容なライセンスが、私たちの実験のベースモデルとして最適だと考えられました。

「Mixtral 8x22B」という名前は、その構造を反映しています。8つのExpertと、22Bパラメータの垂直スタック（埋め込み層、Attention 層、Feed Forward 層ごとに1つの Expert）があります。各入力は層ごとに2つの Expert によって処理され、モデルは入力トークンの処理に39Bパラメータを使用します。これは「アクティブパラメータ」数と呼ばれ、総パラメータ数141Bよりもかなり小さくなっています。

MoE の訓練における技術的課題

MoE モデルを効率的に訓練することは技術的に困難です。通常、1つの GPU に乗せきれないサイズのモデルを学習する際は、複数 GPU に分割して計算する分散並列学習を行う必要があります。

分散並列学習でしばしば問題となるのは、GPU 間の通信オーバーヘッドによる処理速度の低下です。しかし、MoE における各 Expert は入力を処理するために互いに通信する必要がないため、Expert を異なる GPU に配置することで、GPU 間の通信を最小限に抑えることができます。

各 GPU に異なる Expert を配置してモデルを分割するこのアプローチは、Expert Parallelism と呼ばれます。Expert Parallelism では、各 Expert が入力に対して均等に割り当てられるほど、GPUを効率的に使用することができます。しかし、実際には割り当てが特定の Expert に集中してしまう現象が見られることが知られています。対策として、訓練中に負荷分散 Loss を適用するなどの手法も提案されていますが、依然として MoE を使用する上での技術的な課題として残っています。

私たちは NVIDIA の Megatron-LM ライブラリを使用してモデルを構築・訓練しました。Megatron-LM には、Expert Parallelism や Tensor Parallelism、Pipeline Parallelism、Data Parallelism、Optimizer Sharding などの技術が実装されています。内部的に、Megatron-LM はNVIDIA の最適化された Transformer Engine カーネルを使用して高速な演算を可能にしています。

Megatron-LM の最適化により、Mixtral 8x7B を 3000トークン/秒/GPU(~250 TFlops/GPU)で、Mixtral 8x22B を 840トークン/秒/GPU(~210 TFlops/GPU)で訓練することができました。

Megatron 形式で保存した Mixtral を、より一般的に使用されている Hugging Face (HF) 形式との間で変換するために、Alibaba の Pai-Megatron-Patch コンバーターを使用しました。2つの実装間の一貫性を確保するため、同一の入力シーケンスに対する HF モデルと Megatron モデル の Loss を比較し、1%未満の差異しかないことを確認しました。

Mixtral-8x7B を用いた予備実験

本番の事前学習に先立ち、Mixtral-8x7B-Instruct-v0.1 を用いて、Tokenizer および事前学習コーパスの設定に関する予備実験を実施しました。

Tokenizer の語彙拡張

Mixtral の Tokenizer に含まれる語彙 (約32Kトークン) には日本語特有のトークンがほとんど含まれておらず、日本語テキストを対象とした学習・推論効率については改善の余地があります。私たちは Mixtral Tokenizer の語彙に日本語トークンを追加する以下3つのアプローチを検証しました。

• BPE-50K: 日本語の事前学習コーパスを用いて訓練された BPE Tokenizer（最大 50,000トークン）から、Mixtral の tokenizer に存在しないトークンを追加。結果として、日本語Wikipedia におけるトークン効率が1.9倍効率化
• Sudachi-C-50K: 日本語形態素解析器 Sudachiの「長単位」設定のもと日本語事前学習コーパスを用いて訓練された BPE Tokenizer（最大 50,000トークン）から、Mixtral の tokenizer に存在しないトークンを追加。結果として、日本語Wikipedia におけるトークン効率が1.7倍効率化
• Sudachi-A-15K: 日本語形態素解析器 Sudachiの「短単位」設定を用い、日本語事前学習コーパスで訓練された15,000トークンを含む BPE Tokenizer からのトークンを追加。結果として、日本語Wikipedia におけるトークン効率が1.5倍効率化

新しいトークンの埋め込みは、既存トークンの埋め込み平均によって表現しました。具体的には、新規追加トークン（e.g., “東京”）を Mixtral Tokenizer で表現した際に得られるトークン列（e.g., [“東”, “京”]）の埋め込みを平均し、利用しました。

本予備実験では、50B トークン分 (Mixtral Tokenizer 換算) の事前学習コーパスを用いて Mixtral-8x7B-Instruct-v0.1 の追加事前学習を行い、到達したベンチマーク評価の性能をもって各語彙拡張アプローチの良し悪しを判断しました。ベースラインとして、元の Mixtral Tokenizer を用いた場合との比較も行いました。

評価にあたっては、追加事前学習後に指示学習データセットのサブセットでSFTを行いました。ベンチマークには、ELYZA-tasks-100 や Stability AI社の Japanese MT-Bench を含む複数ベンチマークを採用し、それらの平均スコアを見ました。実験結果は以下の通りです:

Tokenizer	トークン効率の改善幅 (wiki-ja)	平均ベンチマークスコア (/5)
Mixtral Tokenizer	-	3.51
+ Sudachi-A-50k	1.5倍	3.48
+ BPE-50k	1.9倍	3.37
+ Sudachi-C-50k	1.7倍	3.28

語彙拡張を行った全てのモデルは、元の Mixtral Tokenizer を使用しているモデルに比べて若干の性能低下を見せましたが、検討した語彙拡張アプローチの中では Sudachi-A-50K が最も良い性能を示しました。また、トークン効率が最も良い BPE-50k アプローチはそれよりも少し性能が劣るも結果となり、トークン効率と性能差には一定のトレードオフがあることが示唆されました。

今回の取り組みでは Tokenizerの効率も重要視していたため、検討の末、BPE-50k アプローチを採用するという決定をしました。

事前学習コーパスの構成

事前学習コーパスの構築方法についても、設定の候補がいくつか考えられました。今回の取り組みでは、訓練速度と計算資源の割り当て期間に基づいて500Bトークンの事前学習を目標とし、設定を検討しました。

設定の検討にあたっては、Tokenizerの予備実験と同様に、50Bトークンでの追加事前学習とSFTを行った結果を比較することとしました。予備実験のベースモデルとしては、Mixtral-8x7B-Instructを使用しました。なお、事前学習コーパスに関する本予備実験では Tokenizer に語彙拡張を行っておりません。

様々なコーパスでの予備実験を行なった結果、LLM-jp-corpus v2 と FineWeb-Edu を組み合わせ、一部LLMによる加工を行なったコーパスが最も良い性能を示したため、このコーパスで本実験を行うことにしました。参考までに、予備実験の結果は以下の表の通りです。

Model	平均ベンチマークスコア(/5)
Mixtral-8x7B-Instruct	3.39
+ pre-training + SFT	3.72

50Bトークンの追加事前学習とSFTにより、ベースモデルであるMixtral-8x7B-Instructから約10%のスコア向上が見られました。なお予備実験では、数学やコーディングに関するデータや、コーパスにドメイン名などのメタデータを付与する実験も行いました。しかし、それらによる性能改善はあまり見られなかったため、今回は採用を見送りました。

Mixtral-8x22Bでの本実験と研究方針の転換

上記の予備実験を踏まえ、Mixtral+BPE-50k Tokenizerを使用し、8x22Bの事前学習を開始することにしました。しかし、結果的にはSFT後の性能に問題が生じ、GENIACプログラムでのアプローチを変更することを余儀なくされました。

本セクションでは、Mixtral-8x22Bをベースとした実験の問題の発覚から、複数のアプローチで問題の切り分けを行い、最終的にアプローチを変更するに至った過程を紹介します。

事前学習の開始と問題の発見

学習を開始すると、Lossは着実に減少していきました。Lossの急激な上昇（スパイク）も発生しましたが、モデルは素早く元のLossに回復したため、問題なく学習が進んでいるように思われました。

学習を開始して2日が経った段階（7,500steps; 約30B tokens）で、事前学習の動作確認のため、一度事前学習を停止してSFTを実行しました。過去の社内での研究開発で、Lossを見る限りは事前学習が順調に進んでいるにも関わらず、事後学習後の性能が低く、生成する日本語が不自然になってしまう現象に遭遇したことがあったからです。それ以降、ELYZAでは事前学習時のLossだけでなく、事後学習後の性能を軽く確認する習慣ができました。

Model	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ BPE-50k + 7,500steps + SFT	3.29

ここでは、学習に要する時間やリソースの都合から、最終的に使用したSFTデータの一部のサブセットを使用して実験を行いました（最終的なSFTデータの内訳はこちら）。結果としては、ベースとなるMixtral-8x22B-Instruct-v0.1から、ベンチマークスコアが10%以上低下する結果となりました。語彙拡張を行ったことにより、スコアが低下することはあり得るものの、出力結果を定性的に分析しても、明らかにモデルの日本語性能が落ちているのが見て取れる結果でした。

出力結果が崩壊している例

### 入力

木曜日の5日後は何曜日でしょう？

### 正解例

順番に曜日を数えていきます。

- 1日後: 金曜日
- 2日後: 土曜日
- 3日後: 日曜日
- 4日後: 月曜日
- 5日後: 火曜日

よって木曜日の5日後は火曜日です。

### モデル出力

木星の5日先は、木星 + 5 = 10 と計算すれば、土曜日だとわかります。

また、このスコアは予備実験でのMixtral-8x7B + BPE-50kのスコアより低い結果となっているため、何らかの問題が生じていると判断しました。この結果を受けて、プロジェクトのメンバー総出でデバッグ作業を行うことになりました。この段階では、様々な可能性が考えられたため、順を追ってデバッグを行い、問題を切り分ける必要がありました。

• 事前学習に問題がある
  • 直前のLossスパイクでモデルが崩壊した可能性
  • 事前学習の設定に問題がある
• SFTに問題がある
  • SFTのコードに問題がある
  • SFTの設定に問題がある
• 推論に問題がある
  • 推論コードに問題がある
  • 推論時のdtypeに問題がある
• モデル自体に問題がある
  • Megatron->HFのモデル変換が間違っている可能性
  • 語彙拡張が間違っている可能性
  • 語彙拡張が悪さをしている可能性

まず即座に試せる部分として、推論コードの問題や、推論時のdtypeの問題についての確認を行いましたが、問題ないことが確認されました。Megatron -> HFのモデル変換や、語彙拡張についても同様に問題はありませんでした。

なお、この段階ではまだ事前学習には問題がない可能性が残っていることや、デバッグの期間計算資源を余してしまうこと、一旦Mixtralの事前学習自体は継続する方針としました。

Lossスパイクでモデルが崩壊したのかどうかの検証

事前学習の問題を探る上で気になる点として、6,400-6,500stepsの間あたりで、Lossスパイクが起こっていました。SFTは7,500stepでのcheckpointを使用していたので、Lossスパイクの影響を受けて既にモデルが崩壊していた可能性があります。そのため、6,000stepsあたりのcheckpointを使用して再度SFTを行い、評価しました。

	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ BPE-50k + 7,500steps + SFT	3.29
+ BPE-50k + 6,000steps + SFT	3.46

結果としては、6,000stepsの方がわずかにスコアが高かったのですが、定性分析の結果を踏まえると、7,500stepsの場合と大差はありませんでした。これにより、「特定のロススパイクから性能が悪くなっている」可能性については棄却されました。また、可能性として「事前学習するほど悪くなっている」説も浮上しました。

SFTに問題があるかの確認

続いて、SFTのプロセスに問題があるのかどうかを確認するために、事前学習や語彙拡張を一切していないMixtral-8x22B-Instruct-v0.1にSFTをする実験を行いました。コードベースやSFT時の設定は上記の実験と同様の設定で行いました。

	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ BPE-50k + 7,500steps + SFT	3.29
+ BPE-50k + 6,000steps + SFT	3.46
+ SFT	2.57

この時点で、SFTには何らか問題があることが発覚しました。注意する点として、SFTに問題があることがわかっただけで、事前学習にも問題がある可能性は棄却できていません。

今回のSFTは、Megatron-LMをベースに独自に作成したコードを使用して実行していました。このコード自体に問題がある可能性があるため、まずは別のコードベースを使用してSFTの実行を試すことで、コードの問題とモデルや学習プロセスの問題を切り分けることにしました。

SFTを実行するためのコードベースに求められる要件として、MoEアーキテクチャに対応しており、かつマルチノードでの分散学習が行える必要がありました。そのような要件を踏まえ、コードベースの候補を下記の3つに絞りました。

• mistral-finetune: Mistral AIが公開している、Mistralモデルをfinetuningするためのコードベース。Mixtral-8x22Bを開発したMistal AIが提供しているため、MixtralベースのMoEモデルの分散学習にも対応している
• llama-recipes: Metaが公開している、Llamaモデルを学習するためのライブラリ。FSDPを用いたマルチノードでの分散学習には対応しているが、MoEモデルに対する公式のサポートは未実装
• TRL: Huggingfaceが提供している、LLMの事後学習を行うためのライブラリ。TRLを使用してMixtral-8x7Bをfinetuningしているblog postが存在

今回はMixtral-8x22Bベースのモデルを扱っていたため、まずはmistral-finetuneでのSFTを試すことにしました。しかし、結論から言うとmistral-finetuneでのSFTは断念することになりました。理由としては、主に以下の点が挙げられます。

• mistral-finetuneのコードベースでは、モデルをconsolidated.safetensors という形式で扱い、保存・読み込みを行います。しかし、その後の評価プロセスを実行するためには、HuggingFace (HF) 形式に変換する必要があるのですが、当時の段階では、HF ↔ consolidated間の変換をMixtral-8x22Bで実行可能なスクリプトが存在しませんでした。
• 同様に、Tokenizerについても独自実装されたものが使われており（参考）、仮にモデル変換の問題が解消されたとしても、Tokenizerの語彙拡張が困難なことが想定されました。

以上より、mistral-finetuneでのSFTを断念し、llama-recipesでの検証に移りました。llama-recipesを選択した理由としては、元々社内で事前学習や事後学習を行うために整備していたllama-recipesベースのレポジトリが存在していたためです。llama-recipesを使用したところ、一部のコードをMixtralアーキテクチャ用に書き直すことで、SFTを実行することができました。

	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ SFT (Megatron-LM)	2.57
+ SFT (llama-recipes)	3.47

結果として、Megatron-LMでSFTをした場合よりも大幅にスコアは改善し、llama-recipesでは正常にSFTが動作していることが確認されました。依然としてベースのMixtral-8x22B-Instruct-v0.1よりはスコアが低いですが、英語をベースとして学習されたモデルに少量の日本語SFTを行うだけでは、スコアが悪化してしまうというのは自然に思えます。

	平均ベンチマークスコア(/5)
Mixtral-8x7B-Instruct	3.39
+ SFT (llama-recipes)	3.01
+ pre-training + SFT (Megatron-LM, 予備実験から引用)	3.72

参考のため、Mixtral-8x7B-Instructに対しても同様のSFTを行いました。結果としては、Mixtral-8x7Bに関しても、SFTを実行するとベースモデルよりスコアが下がる現象が確認されました。しかし、予備実験の結果から、8x7Bでは追加事前学習の後にSFTを行なった場合には、スコアが向上することがわかっています。（なお、8x7Bの予備実験では、Megatron-LMベースのコードでSFTを行っていたにも関わらず、スコア悪化の問題が表出していない理由は不明です。）

仮説として、MoEモデルでは、新たな言語で少量の学習を行うとRouting Layerが上手く学習し切れず、汎化性能が低下してしまった可能性が考えられます。そのため、事前学習後のMixtral-8x22Bに対して、llama-recipesベースのコードでSFTを行う実験を実施しました。

※ ここまでの結果を踏まえると、SFT自体の質が悪く、単にSFTをしたことで元のInstructモデルから性能が下がった可能性も考えられます。しかし、過去に同様のデータでLlama2やLlama3を学習した際に問題なく日本語性能が向上していたことから、今回はMoEアーキテクチャやMixtralモデル特有の要因が存在していると判断しました。

(補足) Megatron-LMベースのSFTコードのデバッグ

llama-recipesによるSFTを検証するのと並行して、Megatron-LMベースのSFTコードのデバッグも行っていました。

Megatron-LMベースのSFTコードと、今までELYZAで実施していたSFTのコードとの大きな差分として、Megatron-LMではデータを生成する際にexample packingを行っているという点が挙げられました。一般的にはexample packingを行ったとしても、正常に学習は行えるはずなので、そこまで気にしてはいませんでした。しかし、デバッグ中のメンバーが、学習中のAttention maskに注目し、Cross-context contaminationと呼ばれる問題を指摘しました。

https://github.com/huggingface/transformers/issues/27640

これは、Example packingにより複数のinstructionデータを同一のcontext内に結合した際、モデルがn個目のサンプルを見るときに、n-1個目までのサンプルに対するAttentionも張ってしまう現象を指します。実際に、Megatron-LMベースのSFTコードでは、このCross-context contaminationを考慮していないAttention maskを使用していました。

早速Attention maskに関する修正を行い、またInstruction部分のLossを取らないなどの細かい修正も加えました。そして再度SFTを回した結果、Megatron-LMでもllama-recipesと同様の結果を得ることができました。

	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ SFT (Megatron-LM)	2.57
+ SFT (llama-recipes)	3.47
+ SFT (Megatron-LM修正後)	3.43

事前学習ステップごとの確認

上記の議論を踏まえ、Mixtral-8x22Bの事前学習中に保存された各checkpointに対して、llama-recipesを使用してSFTを行い、評価しました。

	平均ベンチマークスコア(/5)
Mixtral-8x22B-Instruct-v0.1	3.77
+ BPE-50k + 5,000steps + SFT	3.40
+ BPE-50k + 10,000steps + SFT	3.34
+ BPE-50k + 15,000steps + SFT	3.30
+ BPE-50k + 20,000steps + SFT	3.37
+ BPE-50k + 24,500steps + SFT	3.25

しかし、結果としてはSFT後のベンチマークスコアが大きく改善することはありませんでした。SFTコードのバグを解消する、事前学習ステップを増やす、といった打ち手を講じたものの、依然としてMixtral-8x7B-BPE-50kと同等かそれ以下のスコアしか達成できませんでした。目ぼしいコード上の不備は取り除き、また基本的に8x7Bと同様の設定で学習を行っていたため、残るは8x7Bと8x22Bの間での性質の違いに関する仮説を立て、一個一個可能性を潰していくしかない状況でした。

しかし、この時点で7月初週に差し掛かっており、計算資源の割り当て期間が8月中旬までであることを踏まえると、研究計画を大幅に変更するにはギリギリのタイミングでした。最終的には、メンバー間での議論の末、GENIACプログラムでのアプローチを変更することになりました。

以降の取り組みの内容や成果は、以下ブログ記事にて詳しく解説しています。ぜひ併せてご一読いただければと思います。

• Depth Up-Scalingを用いた「Llama-3-ELYZA-JP-120B」の開発

• 日本特有の知識に特化した大規模言語モデルの学習および評価

今回の失敗を踏まえた学び

Mixtral-8x22Bの実験は期待通りの結果を得ることができず、根本的な要因を特定することは出来ませんでしたが、今回の失敗を経て下記のような学びを得ることができました。この学びを共有することで、本ブログを読んだ皆様が、同じ轍を踏まないことを祈ります。

• 予備実験は可能な限り本実験と同じモデルで検証する: LLMの開発においては、小さいパラメータ数のモデルで起こったことが、必ずしも大きいモデルでも同様に起こるとは限りません（※）。これは逆もまた然りで、同じデータで学習したとしても、小さいモデルでは獲得出来なかった能力を、大きいモデルが獲得できることもあります。そのため、予備実験では可能な限り本実験と同様のモデルを使用するのが望ましいです。
• 事前学習の動作確認はSFT後の性能も見る: 今回は、事前学習のロスは順調に下がっていたにも関わらず、SFTをすると極端に性能が下がる、という現象が起こりました。LLMを学習するにあたり最終的に目指すのは、事後学習やdownstreamタスクに関する学習を行った後の性能向上であるため、早い段階で後段の学習も含めての動作確認を行うことが望ましいです。

※ 特に継続学習の場合は、小さいモデルと大きいモデルの差分はパラメーター数だけでなく、事前学習のコーパス・量・設定などにも存在する可能性があるため、より予測が困難になります

おわりに

本記事では、日本語に特化した MoE（Mixture of Experts）モデル構築への挑戦と、アプローチの転換を余儀なくされた経緯について紹介しました。ELYZA では引き続き、最先端の研究開発に取り組んでいくとともに、その研究成果を可能な限り公開・提供することを通じて、国内における LLM の社会実装の推進、並びに自然言語処理技術の発展を支援してまいります。

ここまでお読みいただき、ありがとうございました。ELYZAはMLエンジニアはもちろん、ソフトウェアエンジニアやAIコンサルタントなど、様々な職種で一緒に事業を前に進めてくれる仲間を募集しています。詳しくは下記をご覧ください。

https://open.talentio.com/r/1/c/elyza/homes/2507

謝辞: なお今回の成果は、国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) の「ポスト 5G 情報通信システム基盤強化研究 開発事業」(JPNP 20017) の助成事業の結果得られたものです。