Zenn
松尾研| GENIAC LLM開発 プロジェクトPublicationへの投稿
📑

[週次報告] 第3回 Team ビジネス

松尾研 LLM開発 GENIAC
2024/04/15に公開
#
LLM
#
大規模言語モデル
#
geniac
#
週次報告
#
松尾研
tech

開発テーマ・概要

  • ビジネスで利用可能なLLMの開発

    下記6点の実施。

    • データの前処理によるハルシネーションの抑制（前処理チーム）

      • 東工大Swallowと同様の処理を実施

    • 日本語向けトークナイザーの開発（前処理チーム）

      • 日本語データ全量を使用したトークナイザーの学習

    • 継続事前学習の実施（データセットチーム）

      • 英語、コードデータ(slimpaja, stack v2, math)で学習後、日本語データで学習

    • ビジネス向け日本語データセットの利用（データセットチーム）

      • 白書、国会答弁、議事録等のデータセットの利用

    • ファインチューニング、アラインメントデータの検討（データセットチーム）

      • コンペ・ビジネス向けのデータセットを利用

    • LLaMA、MoEモデルの検討（アーキテクチャーチーム）

      • 多くの企業で検証済みのLLaMAの利用 or 性能が高いとされるMoEの利用

チーム全体の開発状況

  • クリーニングコードの実装
  • 重複削除コードの実装
  • 独自データ収集
  • LLaMAコードの実装

サブチームからの情報共有

サブチーム1（ドキュメント）

やったこと:

  • 4/7対面開発ミーティング
  • 発表形式のドキュメントフォーマット検討
  • 事務局に週次報告

分かったこと:

  • 特になし

次やること:

  • マルチGPUの計算資源を動かしてみようを検討中

サブチーム2（前処理）

やったこと

  • 東工大Swallowコーパスで言うところの工程5—9まで作った
    • Step 5 品質に基づくフィルタリング | KenLMによるPerplexity
    • Step 6 重複除去 | Hash変換でチェック
  • トークナイザー実験

    • 実験内容

      • 以下、Google Colabで検証。
        データは日本語／英語それぞれのc4の一部（headで10,000行取得して、松尾研標準コードのフィルタリングと重複削除を実施）を使用。評価には青空文庫の羅生門を使用。
        なお、毎回「ランタイムを接続解除して削除」をして実施。ランタイムタイプはCPU。
      • 検証①　日本語(24MB)／英語(13MB)
      Vocab Size 網羅率 未知語率 平均トークン長 処理時間(s) モデルサイズ
      32000 0.9706 0.0294 70.86 293.93 0.73MB
      65535 0.9689 0.0311 66.96 227.34 1.31MB
      130000 0.9680 0.0320 65.21 161.68 2.47MB
      • 検証②　日本語(12MB)／英語(6.7MB)
      Vocab Size 網羅率 未知語率 平均トークン長 処理時間(s) モデルサイズ
      32000 0.9652 0.0348 72.00 144.42 0.74MB
      65535 0.9632 0.0368 68.07 115.01 1.36MB
      130000 0.9623 0.0377 66.46 65.50 2.55MB
      • 検証③　日本語(6MB)／英語(3.3MB)
      Vocab Size 網羅率 未知語率 平均トークン長 処理時間(s) モデルサイズ
      32000 0.9677 0.0323 74.07 60.27 0.77MB
      65535 0.9654 0.0346 69.13 46.25 1.38MB
      130000 0.9626 0.0374 64.00 31.62 2.49MB

      【考察】

      • 網羅率（未知語率）はデータ量が多いほど精度が良い
        →検証②と③は精度が逆転しているのは置いておいて、検証①が圧倒的に良い
      • 平均トークン長もデータ量が多いほど短いため適切にトークン化されていると推察
      • 処理時間はデータ量が2倍になると処理時間も約2倍
      • モデルサイズは語彙数で決まるため、語彙数に比例して増える
        →大したサイズではないので気にするほどのものではない
      • 語彙サイズが大きくなるほど網羅率は下がって処理時間が早くなる

      よって、事前学習データをすべて使うと精度が良くなる可能性はある。
      処理時間はこの小さいデータセットのサイズでの検証では単純に比例する用に見えるが、もう少し多いデータで検証したい。

      語彙サイズについては実験結果からは何が正しいのか判断できず。一般的には32,000が多いようだが、以下の記事があったので65,535がよいのかもしれない。

分かったこと

  • 事前学習データをすべて使用してトークナイザーを作成すると精度が良くなる可能性はある。

次やること

  • 前処理：松尾研GCP環境での実行
  • トークナイザー：10GB・50GB・100GBのデータで処理時間を見積もり

サブチーム3（データセット）

やったこと

  • データセットの調査・選定
  • 公開データセットのDL
  • 独自データ収集

分かったこと

  • 特になし

次やること

  • 学習に向けたデータセットの整備
  • クリーニング・重複削除（前処理チームと連携）

サブチーム4（アーキテクチャー）

やったこと

  • MoE学習パイプラインの実装
  • 学習方法の設計に関しても、別途調査中
    • pretrainのモデルサイズ (10Bの学習であれば、2Bほどか？)
    • 実際の各エキスパートの学習に与えるデータ

分かったこと

次やること

  • moeのタスクを進める。

サブチーム5（学習・評価）

やったこと

  • マルチノード学習の実行
  • TP/MP/Zeroの影響確認
    • Zeroのハイパラの設定確認
    • MP2での変換作業確認。

分かったこと

  • Llamaをhugging faceまで上げてSFTまでできることを確認済み。
    • ただし0.3B程度のせいか、全くFTにならず。

次やること

  • DPOの組み込み
  • ハイパーパラメータについての議論
  • 本番環境での連絡体制。
  • wandbからのエラーをslackで拾ってその日の当番が対応する？（どのようにGWで体制を組むか）

開発のマイルストーン

前処理チーム

  • 前処理コードの完成
    • クリーニング処理
    • 重複処理
  • クリーニング後日本語データの完成
  • 日本語トークナイザーの作成

データセットチーム

  • 済) 使用するデータ決定。
  • 学習データの用意
  • 日本語のトークン数の確認
  • 日、英、コードデータの割合決定
  • 日本語データのマージ完了
  • 評価データの調査
  • インストラクション、アラインメントデータの方向性決定
  • インストラクションデータの完成（可能であれば、数万件）
  • アラインメントデータ完成

アーキテクチャーチーム

  • モデルの調査
  • モデルの決定
  • モデルの実装

学習・評価チーム

  • 小さいモデルでの実行
  • LLaMAモデルの実装確認
  • 学習のチェックポイントの作成
  • 学習開始
  • wandbでGPU停止時のアラートの作成（いつ誰が見るのかを決定）
  • deepspeedの理解

スケジュール

  • Phase1 コンペ開始日時：4/22（月）
  • Phase1 コンペ終了日時：5/26（日）

Phase1：4/22~5/26 の42日間

環境準備：4/22~4/24（3日間）

事前学習：4/25~5/13（19日間）11*19 = 209Bトークンの学習。

ABEJA 100Bモデル 384GPU (H100) 17.8Bトークン/day
Preferred Elements 100Bモデル 400GPU (H100) 24Bトークン/day
Stockmark 100Bモデル 384GPU (H100) 23.8Bトークン/day
私たち 10Bモデル 24GPU (H100) 17.8/16*10=約11Bトークン/day

ファインチューニング：5/14~5/18（5日間）

DPO：5/19~5/23（5日間）

バッファ：5/24（1日）

学びの期間：5/25~26（2日間）（全員がモデル学習できる期間にしたい）

松尾研| GENIAC LLM開発 プロジェクト
松尾研| GENIAC LLM開発 プロジェクトPublication

Discussion