松尾研LLM開発 チームZoo(三内チーム)におけるコーパス構築

チームZoo(三内チーム)におけるコーパス構築

この記事ではチームZoo(三内チーム)(GENIACチーム紹介)のサブチームの一つである自動コーパス構築チームの活動を、サブチームメンバーのソウがまとめる。

コーパス構築の方針

チームZooが提案するモデルの特徴として、MoE(Mixture of Experts)(ref)の構成がある。特定のドメインを扱うExpertモデルを複数用意し、入力に応じたExpertモデルを使用(複数Expertモデルも含む)して、出力を生成する。

上記のエキスパートモデルを念頭に、学習に用いるデータセットとして大きく以下のことを検討し、データを作成する。

1. 必要とするデータ量と日英データ混合
2. エキスパートのためのカテゴリ分類
3. その他の手法・検討事項

以下でそれぞれについて簡単にまとめる。

1. データセット量と日英データについて

作成するモデルのパラメータ量10B(1B=10億)規模であることから、おおよそ必要なデータセット量を検討した。また、日本語のみのデータではなく、比較的潤沢にある英語のデータセットも含めることで言語間の知識転移も狙う。

行ったこと

• 既存の日本語対応のLLMを調査し、日英の割合やどのようなデータセットを学習しているかの状況把握。
  • LLM-jp-13BやWeblab-10Bは日英比率1:1、PLaMo-13Bは7:1 などモデルによって比率は異なる。
  • 調査の際に、日英のトレーニングデータの入れ方や順序への工夫。カリキュラムラーニングに関する文献もあった。

わかったこと・方針

• 日英の言語比率はさまざまあること、日本語データは少ない傾向にあることから、日本語を優先して収集してから英語のデータを足すという方針でデータを収集。
• Chinchillaスケーリング則 (Hoffmann, 2022)にのっとり、モデルパラメータ数1Bあたり20Bのトークン数の学習データの関係にある。したがって、10Bモデルパラメータのために200Bトークンの学習データが必要になる。コーパスのフィルタリング処理をすると1/10になることがわかっていたので、日英合わせて2000Bトークンのコーパスを集めるという目標値の概算を得た。

2. エキスパートのためのカテゴリ分類

最適なエキスパートの数は人手で決めたり、クラスタリングの数など(100以上)で決定するなどが考えられるが、データセットにおいてはざっくりコーパスの内容やその形態に応じて、9つのカテゴリ(ドメイン)でデータセットをまとめることにした。

• カテゴリ

  • カテゴリの分類は論文 (Gururangan, 2022)を参考にした。
  • コーパスの内容で以下のカテゴリに当てはまるようデータを収集。なお、一部のデータはSFT用のデータやQAのデータ形式などがある。

  カテゴリ	説明
  1B	Webクローリングした記事
  CS	学術関連テキスト、論文など
  LEGAL	法律関連、政府が公開するデータなど
  MED	医療関連
  BOOK	本、小説など
  NEWS	新聞、ニュース
  REVIEWS	商品レビューなど
  CODING	プログラミングコード
  MATH	算数、数学

  • 事前学習用データに加え、SFT用のデータも上記カテゴリに従い収集した。

行ったこと

• 上記のカテゴリを満たすデータを主にhuggingfaceデータセットや、論文などの情報を使ってデータセットを選択。その際に、言語がなんであるか、どの規模の大きさか、ライセンスを調査、洗い出した。

わかったこと・方針

• 英語は比較的ライセンスがゆるく、カテゴリに該当するデータが見つかったが、日本語についてBOOK, NEWS, REVIEWSについて利用可能なデータセットは限られた。

3. その他の手法や検討事項

上記以外に検討したことや、データ整備を行う上でおこなったことをまとめる。

クラスタリングによるテキスト分類

• モチベーションに、クローリングデータから設定するカテゴリのデータの自動抽出があった。
• BERTMultilingualでテキストの埋め込み表現を得たうえでのクラスタリングを実行。
  • 日本語の3カテゴリでおこなった分類ではまずまずだったが、カテゴリ数を増やした場合や、最終的なエキスパートモデルの数などの検討不足があり、実行を断念。

ASK-LLMによるフィルタリングの検討

• Webクローリングの記事テキストは、広告やキーワードのみの羅列といったノイズが大いにのっており、LLMの事前学習に適さないと考えられます。そこで何らかの記事をフィルタリングする必要がある。
• ASK-LLM (Sachdeva, 2024) という手法では、テキストの有用性をLLMに判断させることを行います。特に日本語のデータについて、何のLLMを用いてASK-LLMを行うかで、予算上やライセンスの観点で利用可能なもの、環境構築作業の問題から取り組めずに断念。
  • ルールベースのフィルタリング処理に加え、自動でフィルタリングする仕組みがあれば、サブチーム名によりふさわしい"自動"コーパス構築になったと思う。

コーパスクリーニングについて

• ASK-LLMの利用のモチベーションともかぶるが、有益なテキストの選別、電話番号といった個人情報や卑猥なテキストの排除といったフィルタリング、また重複した文を削除する必要がある。
• 英語の1Bカテゴリ相当するコーパスFalcon RefinedWeb (Penedo, 2023)があり、すでにフィルタリング、重複処理作業がされていた。主に日本語テキストについてフィルタリングは松尾研が提供する標準コード(github)を使用して行った。その際、GCP環境でマルチプロセスが処理できるよう工夫も行った。日本語のクローリングデータmc4に対して行うとフィルタリング後、概ね元のデータの1/10の量になった。
• 重複除去(deduplication)処理として、C++で実装されたコード(github)をGCP環境で動かした。わかったこととして、日本語のクローリングデータmc4に対して、上記のフィルタリングを行ったうえで重複除去すると、フィルタリング前から1%未満の重複が除去できた。GCP上での環境整備や処理時間コストと得られる効果の関係で日本語テキストへの重複処理は見送った。

集めるにあたって苦労したこと

メンバーや他のサブチームとのすりあわせ

• 我々のサブチームには稼働が長くできるコアメンバーが在籍しておらず、時間がとれない状況で、週一回の定例ミーティングで状況報告し、メンバーでタスクを切り出すとともに、分担し作業をすすめた。
• また、LLM開発においてコーパスは根幹である。例えば、エキスパートモデルやTokenizerの試作を作成するうえで、複数カテゴリのコーパスを必要とした。早急にDLし、利用可能な状態にするなどLLM開発ステップにおいて早い時点で物事をすすめる必要があった。

開発関連の制約

• GCP上でLLM開発の多くを行う必要があるが、共有マシンであることからsudo権限がないこと、使いたいツールやプログラムが自由に使えない状況があり、開発環境も考慮する必要があった。
• ストレージについても、クローリングデータは大容量であり、また、フィルタリング処理、重複処理など各ステップの結果を保持するとすぐにストレージ容量がパンクした。huggingface経由でDLすると、cacheディレクトリにもデータがDLされることから注意も必要だった。
• コンペのルールでlicenseの規定があるため、各データセットのライセンスを調べ、ライセンス情報とともにデータセット名やそのURL、保存先などをスプレッドシート上で管理した。商用利用可能でOpenなライセンスを調査するうえで、コンペルールで指定された確認ページは有益だった。
  • OSSライセンス
  • Open Dataライセンス (RECOMMENDED CONFORMANT LICENSESを使用)

おわりに

LLM開発の早い段階からさまざまなコーパスに関連する調査を行いつつ、コーパスを利用可能な形式まで変換する必要があり、メンバーと協力しテキパキと作業が必要だった。多忙にもかかわらず、手を動かすのが早いメンバーに恵まれ議論や開発できたこと、チームメンバーの方々にここで感謝します。

収集したコーパスすべてを最終的なエキスパートモデルの学習データに利用できなかったことは留意するとともに、この点が課題として残った。

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