東大LLM開発プロジェクト進捗状況｜ビジネスLLM特化チーム

第1回：週次報告

開発テーマ・概要

• ビジネスで利用可能なLLMの開発
  • ハルシネーションの抑制
  • ビジネス向け日本語データセットの選定
    etc…

チーム全体の開発状況

• ドキュメント構成の熟考（初見でも実施事項が分かりやすいように変更）
• 前処理、データセット、アーキテクチャー、学習・評価方法の調査

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

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

やったこと：Notionの構成を整理、slackでチームの入り口のページを作成中

計算資源へのログインを試した。

次にやること：slurmの検証アイディア出しと環境構築。

サブチーム2（前処理）

やったこと：Common Crowlのデータをきれいにする手法の検討。公開コードなどを用いて実施中。個別の環境で小規模データで実施中。web crawlのコードのテストを実施予定。トークナイズ化の手法についても検討中。

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

やったこと：前処理チームとの業務交通整理

独自データセットの各チームメンバーに割り振ってスクレイビング中

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

やったこと

今後やるタスクを 以下の４つに大きく分けた。

1. LLM実装の全体像の理解(環境構築~事前学習~評価)
2. 松尾研標準コードの理解と動作確認
3. OSS, 有識者のブログ記事を参考に独自のモデル組込みの調査(Llama2, MoE)
4. 松尾研コードの改修

主担当をとりあえずでも決めた方が、各人が作業し易いと考え、20:40~21:15の時間に参加されていたメンバーで、それぞれの主担当を以下のように割り振った。勿論、ヘルプが必要になった場合は、その他のメンバーでフォローする方針で考えている。

1. 前河、李
2. 松永
3. 熊田
4. -

miro link: https://miro.com/app/board/uXjVNgYWJn8=/

LLM実装の全体像のまとめ(環境構築~事前学習~評価)について、まとめて頂くスライドの雛形を作成

    Google slide link:   https://docs.google.com/presentation/d/1yMjt5zqGDWCQlr-_jpHDN1eTFzSntIVVokBZMpbnJaA/edit#slide=id.p

松尾研で用意下さったGPUサーバーで、環境構築を試み中。

畠山さんのnotionを参考に、最初の設定2: 仮想環境のsetupまでは成功。

• https://matsuolab-geniac.notion.site/1gpu-79215be07ad845649cb40b8f602436fa

分かったこと

標準コードを改修するところまで、どのくらい時間がかかるか、懸念ではある。

また、job実行のスラムについても勉強しなくてはいけない。

次やること

LLM実装の全体像のまとめの記載

とりあえず、標準コードの実行まではできることを確認

    LLMモデルの学習コードの調査（継続）

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

やったこと

Megatron deep speedでの学習実行

MoEの調査

ディスカッション

• サブリーダとリーダの打ち合わせ。
• slurmの扱いが難しい。経験者がいれば手伝っていただきたい。
• 運営とのミーティングは？ → 対面での報告ではなく、週次内容を提出。
• 自己紹介記述のためのミーティングについて、ドキュメントチームで検討中。
• データはいつまでに必要か？→4/15迄にはデータ処理が終わって使える形にして欲しい。
• Common crawlやCC100の前処理の扱いは異なるのか？→前処理はどちらも必須で河越チームで実施する。
• データチームと前処理チームの役割は？→一旦2チームで集まっていただいて今後の役割分けを実施していただきたい。
• それをやっちゃだめというリストを作成していただきたい。環境構築のページを作成してそこに追加する。
• 環境構築に関してはハンズオンがビデオとか実施するのがいいか？

第2回：週次報告

開発テーマ・概要

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

  下記6点の実施。

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

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

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

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

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

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

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

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

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

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

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

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

チーム全体の開発状況

• 東工大Swallowプロジェクトにおける大規模日本語Webコーパスの構築に従った前処理の実装
• ビジネス向けデータセットの収集
• モデルアーキテクチャー、松尾研標準コードの調査・確認

暫定スケジュール

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

• Phase1 コンペ終了日時：5/26（日）

• Phase1 採点、インターバル期間：5/27（月）~ 5/31（金）

• Phase2 開始日時：6/1（土）以降順次

• Phase2 終了日時：8/8 (木)

• GCP環境 データバックアップ, 環境削除 8/9 (金) ~8/15 (木)

Phase1の日程：4/22 ~ 5/26（5週間）

• 事前学習（3週間）
• ファインチューニング、アラインメント（2週間）

期限

• 4/22まで

  • モデルの決定。
  • 英語（refinedweb, slimpajama）, コード（The stack v2 + α？）のデータセットの用意。
  • 日本語データセットの用意。
  • 小さなモデルで学習できることを確認。

• 5/12まで

  • ファインチューニングデータ（JMT-benchとllm-jp-evalに似たデータセット。ビジネス系データセット。（他の指標・ビジネスに有用なモデル作成用））
  • アラインメントデータ

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

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

やったこと：週末の対面チーム開発に関して

分かったこと：

次にやること：

各サブチームが、どういったタイミングで成果物の資料を受け渡していただけるのか

• ブログ・ノートとかで発信も可能であれば、行いたい
• 外部公開したいこと。
• エッセイのようなものをいただけると嬉しい。

サブチーム2（前処理）

やったこと：

トークナイザー: sentencepieceの試用

データ選別: 使用できるデータセットの調査

分かったこと：日英語ごとにトークナイザーを変えた場合、英語でのみ性能改善・日本語では変化なし

次にやること：

• アイデアリスト③に基づき，学習データ全量で学習（※これからチーム内に提案）
  • 白書等のデータを優先？
  • mc4などの大型データは全量の30%で学習時間見積もり
• pipelineをpoetryにしたい
  • requirement.txtを自動で作れる
  • 依存関係を正しく管理できる
• 学習データをクリーニング
  • データセット班のデータ処理を待つ
  • 形態素解析を利用する等も考慮中
• Perprexityを指標として利用
• トークナイザーの評価指標の調査

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

やったこと：

• CulturXの処理を整理
  • 日本語判別 + フィルタリング

やるべきこと：

• どれくらいのトークン数学習できるか
• 割合決定
• マージ

現状のデータセット

• slim pajama, refined web（重複削除）
• The stack + open math（フィルタリング）
  • カラムからのフィルタリング（プログラム言語）
  • ライセンス、ライセンスタイプ　←　こちらで
    • こちらのコードを共有いただく。
    • ライセンスだけでかなり、絞られる
    • ライセンス絞るコードを記述
• 上記が合体したデータセットを作成したい。

→ 急ぎ。

• mC4-ja
  • 830GB
  • google の mc4 データセットを allenai が前処理したバージョン
• CC-100
  • 82GB
  • facebook 製 XLM-R 用のデータセット
• wiki40b_ja
  • 1.3GB
• （＋α）CulturaX
  • 107BT
  • mC4とOSCAR
  • これを探っていっても良いかも？
• （＋α）Swallow コーパス（畠山さん）
• ★白書（江國
  • 河越スクリプトでクロール
• ★都道府県別の報告書（吉野さん
• ★国会議案・議事録（和田
• ★国会答弁（インストラクションデータとしても使えそう）（miwa
• ★判例（濱田さん

次にやること：

• 事前学習データセットについて調査実装
  • 事前学習データの環境へのダウンロード
  • ダウンロードコードのパイプラインへの組み込み
• ダウンロード & 日本語抽出
• ダウンロードコードをpipelineに組み込む。

スケジュール

4/4　本日

4/7

• この日までに、日本語データを/persistentshare/storage/team_kawagoshi/datasetsに落とし込みたい。
• 英語、コードデータセットは、河越が落とし込む。
  • 英語（重複処理）
  • コード（ライセンスのフィルタリング）

4/7~4/14

• 日本語データの前処理（重複削除、フィルタリング）
  • 一週間以上、前処理にかかると考えられる。

4/15~22（松尾研環境が使用できるかは予算次第。）

• トークナイゼーションは、時間次第。

  → 出来そうであれば、したい。

• データのマージ。（学習データ完成）

4/22~24　学習準備（出来ればすぐに、学習したい）

4/25~ 10B学習開始

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

やったこと：

• 月曜から進捗ありません。

分かったこと：

次にやること：

• 標準コードで使用されているMegatron-DeepSpeedのソースコードをベースに、llama2に変換する。モデル形式の変換については、　チーム haijimaのソースコード を参考にする。
• その後の優先順位で、github repo: MoE-Recipeを参考にしたMOEの実装を検討する。

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

やったこと：

• マルチGPUでの学習試行。1nodeでは出来た。
• bash 上で複数GPUでの学習確認。
• 複数nodeはエラーも出ずに停止状態。
• Mistralのモデルについて確認。v0.2ではslide attentionが使用されていないので、ほぼLlamaと構造変わらない。rope_thetaの値が少し異なる。

分かったこと：

次にやること：マルチノードを通す。変換後のウェイトの確認。DPO来週。。。

この3つを調査できると良い。（llama, mistralはニシジマさんがほぼ確認済み）

• LLaMA
• Mistral（sliding windowあり？確認いただける方がいれば）
• MoE（アーキテクチャーチームに対応いただきたい。）
  • アーキテクチャーチームにコードのチェックもしていただけると良い。

ディスカッション

• ノード4, 5をニシジマさんが利用。（複数ノードでの実験）
• 4/7(日)にファインチューニング、アラインメントデータについて話し合いたい。
  • 評価データセットに近いデータ（コンペで勝つため）
  • ビジネス的に有用なデータセット（世の中の役に立つ）
    • QAデータセット等（e.g. https://financial-field.com）

第3回：週次報告

チーム全体の開発状況

• クリーニングコードの実装
• 重複削除コードの実装
• 独自データ収集
• 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学習パイプラインの実装
  • moe-scripts: https://github.com/okoge-kaz/moe-recipes の動作確認
• 学習方法の設計に関しても、別途調査中
  • pretrainのモデルサイズ (10Bの学習であれば、2Bほどか？)
  • 実際の各エキスパートの学習に与えるデータ

分かったこと

• チーム中村の方から、ライセンスに関する質問あり

  • moe recipe のライセンスが表示されておらず，プロジェクトとして使えるかどうか気になる

    → ライセンスがないものは、著作権の問題があるため使用不可

• 論文調査

  • https://github.com/XueFuzhao/awesome-mixture-of-experts?tab=readme-ov-file#open-models

• OpenMOE: https://github.com/hpcaitech/ColossalAI/tree/main/examples/language/openmoe

次やること

• 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日間）（全員がモデル学習できる期間にしたい）

第4回：週次報告

チーム全体の開発状況

• 前処理コードの作成
• 重複削除コードの作成
• データのクリーニング
• トークン数の確認
• データ割合決定
• LLaMAモデルの学習

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

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

やったこと:ドキュメント班で発表時のスライド構成を検討
　　　　　 定例MTGのURLをNotionのhomeに

分かったこと:

次やること: 複数GPUを試す会(5/25-26)を検討

サブチーム2（前処理）

やったこと：

• wiki40bに対して、クリーニング

分かったこと：109MBのファイルに対して、1.5分でクリーニング可能

次やること：

• 畠山さんのCommon Crawlに対して、クリーニング（300GB：4500分）
  • 75時間 = 3日間

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

やったこと

• データセットをDLし、jsonlに変換後、順次格納中
  • /persistentshare/storage/team_kawagoshi/datasets/final/jsonl
• クリーニング・重複削除のコード動作確認
• 白書のDL
  • 約5時間でスクレイピング終了
• 日本語トークン数のカウント（作業中）
  • 明日中には数字が出そう
• 評価データセットの調査（作業中）

分かったこと

• データセットの変換に関して

  • クリーニングのコードの関係上、jsonl形式で保存するのが良いということでHuggingFaceからjsonlで保存

    from datasets import load_dataset
    import json
    from time import sleep
    
    dataset = load_dataset('uonlp/CulturaX', 'ja', split='train', streaming=True, token='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')
    
    for data in dataset:
        data['text'] = data['text'].strip()
        with open('CulturaX-ja.jsonl', 'a', encoding='utf-8') as f:
            json.dump(data, f, ensure_ascii=False)
            f.write('\n')
    

    • 大規模なデータセットを読み込むとメモリ不足になったり途中経過が確認できず、何度もjsonlへの変換をやり直し、現在はstreamingで読み込むことで対応したが、計算ノードのアクセス可能時間内（6時間？）だと足りない
    • 畠山チームからCCが保存されてあるgcloudへのアクセス権限をもらったが、計算ノードからではアクセスできない（ログインノードからならできる。計算ノードでもdockerを立ててもいけるのではとアドバイスをもらった）

  • 分かりたいこと

    • —time指定なしだと何時間までOKか？時間制限のないログインノードを使っても良いのか？データセットの楽な保存方法は？

• クリーニングに関して

  • 前処理チームのクリーニングコードで処理すると、英文対応していないので、markdown含めて崩れる。
    • wiki40bに適用した結果
      • /persistentshare/storage/team_kawagoshi/ekunish/preprocessing_test
      • 計算時間は109MBのこのjsonlファイルに対して1.5min程度

次やること

• 引き続きデータセットのjsonl化（江國・吉野）

  • CC-100_ja
  • ✔︎　wiki40b_ja
  • ✔︎　CulturaX
  • CC
  • 各自データセット

• クリーニング・重複処理（江國・吉野・和田）

• 日本語トークン数のカウント（和田）

  • wikipedia-ja-20230720
    • 737,004,907 tokens

  token_count_wikipedia-ja-20230720.csv

• 評価データセットの調査（濱田）

サブチーム4（アーキテクチャー & 学習・評価）

やったこと：LLaMA2周りのコードの確認

TP, PPについて、10Bクラスで適切なものを調査

ハイパーパラメータ調査

分かったこと

次やること

ディスカッション

開発のマイルストーン

ドキュメントチーム：

前処理チーム：

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

データセットチーム：

• 済) 使用データ決定
• 日本語データのトークン数確認
• 英語 & コードデータのトークン数確認
• 日、英、コードデータの割合決定
• 日本語データのマージ完了
• 英語データのマージ完了
• 評価データの調査
• インストラクション、アラインメントデータの方向性決定
• インストラクションデータの完成（数万件）
• アラインメントデータ完成

アーキテクチャーチーム & 学習・評価チーム：

• 済）モデルの調査
• 済）モデルの決定
• 済）LLaMAモデルの実装
• 済）deepspeedの理解
• 済）deepspeedからHuggingfaceへのパラメータ変換
• deepspeedの設定確認
• 済）小さいモデルでの実行
• データセットshuffle機能の削除
• 学習チェックポイントの作成
• GPU停止時のアラート作成（wandb）
• コマンドワンライン（bash OO.sh）で動かせるコード作成
• ハイパーパラメータの決定
• 10B学習

スケジュール

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

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

環境準備：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日間）（全員がモデル学習できる期間にしたい）

第5回：週次報告

チーム全体の開発状況

• 前処理コードの実装（クリーニング、重複削除）
• トークナイザーの調査
• LLaMAコード確認
• 分散処理学習について調査

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

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

やったこと:

• 事務局と執筆チームでのMTG（4/11）
  • 週次報告と外部発信を分ける方向で。
• リーダーと外部発信用MTG録画などの打合せ（4/13）

次やること:

• フェーズ０の原稿着手

サブチーム2（前処理）

やっていること

• ローカル環境でCC100のクリーニング
• range3/cc100-ja at main
  https://huggingface.co/datasets/range3/cc100-ja/tree/main
  • 分担
    • ローカルで動くコード作成 | 塚本さん
    • 0-5 | 小川
    • 6-10 | 志賀さん
    • 11-15 | 許さん
    • 16-20 | 角谷さん
• 許さんと角谷さんは，松尾研環境に正式に登録できた

分かったこと

• 語彙サイズの調査
  • 語彙サイズは32000以上
  • nekomataは15万（中国語LLM Qwenベースだからか）
• トークナイザーの学習実行時間
  • 学習対象ファイルが1GBの場合，処理がkillされて実行できない
  • 100MB=1140秒
• 英語と日本語を学習した既存のトークナイザーを使うか

次やること

• 引き続き語彙サイズの調査
  • rinna社
  • StabilityAI

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

やったこと

• データセットをjsonlに変換し、ストレージ・HFに保存
• クリーニング・重複削除のコード修正
  • クリーニング
    • 逐次処理・レジューム機能追加
• 日本語トークン数のカウント（確認中）
• 評価データセットの調査

分かったこと

• 日本語トークナイザー
  • Llama系でオープンライセンス
    • pfnet/plamo-13b
    • cyberagent/calm2-7b
• 評価データセット
  • llm-jp-evalは完全一致のクイズみたいな感じのベンチマーク, これに特化しすぎると能力が劣化する可能性がある
  • jmt-benchは複数ジャンル, マルチターンの質問に対するllmの回答を評価するベンチマーク. 適切に指示に従って解答する必要があり難しい
  • hatakeyamaさんチームの試験対策の方針について調査
    • 今回のフェーズで開発するモデルでは, いずれの評価データセットに関してもチューニングなしで回答することはほぼ無理っぽい
    • いかに, 質の良い, かつ形式が似ているようなデータセットを探すか構築するかに注目して作業をしている

次やること

• 前処理チームのクリーニングが実装でき次第、処理のヘルプ
• インストラクションデータの準備？

サブチーム4（アーキテクチャー & 学習・評価）

※「04.開発のマイルストーン」にも記述済み

やったこと

• 済）モデルの調査
• 済）モデルの決定
• 済）LLaMAモデルの実装
• 済）deepspeedの理解進が悪いみたい。tensorbordは削除
• 済）小さいモデルでの実行
• 済）学習チェックポイントの作成

分かったこと

• どうやらtensorbordとの相性が悪いみたい。tensorbordは削除
• exampleではgrad_accum_typeはfp32なので追記
• Megatron-DeepSpeed/examples_deepspeed/universal_checkpointing/run_bf16.sh at 3c5f47563f697702c1e305fa01b7563f54b747fc · microsoft/Megatron-DeepSpeed (github.com)

次やること

• データセットshuffle機能の削除

  https://note.com/kan_hatakeyama/n/na8c7d9c58e88
  

• GPU停止時のアラート作成（wandb）

  slackとの連携は可能。運営要領は別途制定が必要。

• コマンドワンライン（bash OO.sh）で動かせるコード作成 (mekwさん)

• ハイパーパラメータの決定(松永さん)

  • バッチ数1024,
  • seqlen 4096,
  • adamw(beta1=0.9, beta2=0.95)
  • lr1.00E-04 minlr3.30E-06 decay 1.00E-01

• https://docs.google.com/spreadsheets/d/14vbBbuRMEHoqeuMHkTfw3uiZVmyXNuoSp8s-aHvfvZk/edit

https://docs.google.com/spreadsheets/d/1NHt5vgrgiH7jFDWg218rKX4FSoLYiRI0SDRMucg-flM/edit?usp=sharing

• 10Bクラスのハイパーパラメータの準備

(8B, 9B, 10B)

• 10B学習(everyone)

• 本番環境での実験項目

  ノード数が何個？

  誰が環境構築するの？

  輪番制どうする？

• Lossスパイク対策(everyone)

A11-2.pdf (anlp.jp)

開発のマイルストーン

前処理チーム：

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

データセットチーム：

• 使用データ決定

  • 英語、コード
    • Slimpajama
    • The Stack v2
  • 日本語
    • CC-100
    • CultureX
    • wiki-40b
    • Common Crawl
    • 国会議事、国会答弁、白書、議事録

• 日本語データのトークン数確認

  • 既存
    • CC-100：12Bトークン
    • wiki-ja：0.7Bトークン
    • CultureX：
    • Common Crawl：　角谷さんと塚本さん
  • ビジネス系（約2Bトークン） (1人)、重複削除(2人)
    • DietRecord： 1.04Bトークン
    • japanese_precedent：0.88Bトークン
    • gizi_tokyogikai： 0.098Bトークン
    • gizi_aitigikai： 0.029Bトークン
    • houkokusyo_tokyo： 0.015Bトークン
    • giji_hakusyo： 0.01Bトークン
    • chatwork： 0.003Bトークン

• 英語 & コードデータのトークン数確認

  • Slimpajama：350Bトークン
  • The Stack v2（商用利用可ライセンス）：1.1Bトークン

• 日、英、コードデータの割合決定 10:5:1→ (120B：60B~：12B)

  (IBM参考：https://japan.zdnet.com/article/35215769/)
  

• コード：（19.3Bトークン）

  • Slimpajama：18.2Bトークン
  • The Stack v2：1.1Bトークン

• 英語：（331.8Bトークン）

  • Slimpajama：331.8Bトークン

• 日本語データのマージ完了

• 英語データのマージ完了

• 評価データの調査

• インストラクション、アラインメントデータの方向性決定

• インストラクションデータの完成（数万件）

• アラインメントデータ完成

アーキテクチャーチーム & 学習・評価チーム：

• 済）モデルの調査

• 済）モデルの決定

• 済）LLaMAモデルの実装

• 済）deepspeedの理解進が悪いみたい。tensorbordは削除

• 進）deepspeedからhuggingfaceへのパラメータ変換 (miwaさん、松永さん)

  1.モデルの一致の確認スクリプト調査

• deepspeedの設定確認 (熊田さん)

どうやらtensorbordとの相性が悪いみたい。tensorbordは削除

exampleではgrad_accum_typeはfp32なので追記

Megatron-DeepSpeed/examples_deepspeed/universal_checkpointing/run_bf16.sh at 3c5f47563f697702c1e305fa01b7563f54b747fc · microsoft/Megatron-DeepSpeed (github.com)

{
  "train_batch_size" : $GLOBAL_BATCH_SIZE,
  "train_micro_batch_size_per_gpu": $MICRO_BATCH_SIZE,
  "steps_per_print": 10,
  "zero_optimization": {
    "stage": $zero_stage
  },
  "bf16": {
    "enabled": true
  },
  "data_types": {
    "grad_accum_dtype": "fp32" 
  },
  "wall_clock_breakdown" : false,
  "wandb": {
    "enabled": true,
    "project": "Llama_111_0414"
  }
}

• 済）小さいモデルでの実行

• データセットshuffle機能の削除

  https://note.com/kan_hatakeyama/n/na8c7d9c58e88
  

• 済）学習チェックポイントの作成

• GPU停止時のアラート作成（wandb）

  slackとの連携は可能。運営要領は別途制定が必要。

• コマンドワンライン（bash OO.sh）で動かせるコード作成 (mekwさん)

• ハイパーパラメータの決定(松永さん)

  • バッチ数1024,
  • seqlen 4096,
  • adamw(beta1=0.9, beta2=0.95)
  • lr1.00E-04 minlr3.30E-06 decay 1.00E-01

• https://docs.google.com/spreadsheets/d/14vbBbuRMEHoqeuMHkTfw3uiZVmyXNuoSp8s-aHvfvZk/edit

https://docs.google.com/spreadsheets/d/1NHt5vgrgiH7jFDWg218rKX4FSoLYiRI0SDRMucg-flM/edit?usp=sharing

• 10Bクラスのハイパーパラメータの準備

(8B, 9B, 10B)

• 10B学習(everyone)

• 本番環境での実験項目

  ノード数が何個？

  誰が環境構築するの？

  輪番制どうする？

• Lossスパイク対策(everyone)

A11-2.pdf (anlp.jp)

スケジュール

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

Phase1 スケジュール (2)

トークナイザー作成用コードGCPでの試走

データセットの前処理

事前学習

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（ 3日）

タスク　4/20以降

リーダー・アーキテクチャーチーム & 学習・評価チーム

• 環境準備の方法共有
• WandB確認方法の共有
• 事前学習のバッチ実行方法共有
• 事前学習のバッチ実行者決定
• ロススパイク時の対処方法調査
• ロススパイク時の対処方法共有
• チェックポイントからの実行方法共有
• 手動チェックポイント作成方法共有
• 運営評価指標の実行
• 自作評価指標の作成
• 自作評価データの取得
• 自作評価データの作成
• ファインチューニング手法の調査
• ファインチューニング手法の実装
• ファインチューニングデータの調査
• ファインチューニングデータの取得
• ファインチューニングデータの作成
• DPO手法の調査
• DPO手法の実装
• DPOデータの調査
• DPOデータの取得
• DPOデータの作成

その他

• 特になし

第6回：週次報告

チーム全体の開発状況

• 前処理コードの実装（クリーニング、重複削除）
• トークナイザーの調査
• LLaMAコード確認
• 分散処理学習について調査

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

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

やったこと:

• 事務局と執筆チームでのMTG調整（5/2）
  • 週次報告と外部発信を分ける方向、外部発信はエッセイ風に
• フェーズ０の原稿着手
• GPU死活監視
• 他チームヒアリング

分かったこと:

次やること:

• 事務局と執筆チームでのMTG（4/25）
• GPU死活監視　復帰方法　ドキュメント作成　sbatch

サブチーム2（前処理）

やっていること

• ローカル環境でCC100のクリーニング
• range3/cc100-ja at main
  https://huggingface.co/datasets/range3/cc100-ja/tree/main
  • 分担
    • ローカルで動くコード作成 | 角谷さん
    • 0-5 | 小川アップロード中
    • 6-10 | 志賀さんDONE
    • 11-15 | 許さんDONE
    • 16-20 | 榎本さん
    • wiki40 | 角谷さんDONE
• トークナイザー
  • llm-jpのモデルに決定

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

やったこと

• データセットをjsonlに変換し、ストレージ・HFに保存
• クリーニング・重複削除のコード修正
  • クリーニング
    • 逐次処理・レジューム機能追加
    • CurturaXクリーニング中
      • 4/26
• 日本語トークン数のカウント
• 評価データセットの調査
• EDINET APIから2023年有価証券報告書のテキストデータを取得

分かったこと

• 日本語トークナイザー
  • Llama系でオープンライセンス
    • pfnet/plamo-13b
    • cyberagent/calm2-7b
• 評価データセット
  • llm-jp-evalは完全一致のクイズみたいな感じのベンチマーク, これに特化しすぎると能力が劣化する可能性がある
  • jmt-benchは複数ジャンル, マルチターンの質問に対するllmの回答を評価するベンチマーク. 適切に指示に従って解答する必要があり難しい
  • hatakeyamaさんチームの試験対策の方針について調査
    • 今回のフェーズで開発するモデルでは, いずれの評価データセットに関してもチューニングなしで回答することはほぼ無理っぽい
    • いかに, 質の良い, かつ形式が似ているようなデータセットを探すか構築するかに注目して作業をしている

次やること

• CalturaXのクリーニング中
• インストラクションデータの準備？

サブチーム4（アーキテクチャー & 学習・評価）

やったこと

• 本番用のスクリプト作成
  • LLaMA3ベース
• 変換コードの調査

分かったこと

• マルチターンのデータがない

次やること

• 入力テンプレートの決定
  • chatテンプレート
• 2048までのシーケンスで良いのか

開発のマイルストーン

ドキュメントチーム：

前処理チーム：

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

データセットチーム：

• 使用データ決定

  • 英語、コード
    • Slimpajama
    • The Stack v2
  • 日本語
    • CC-100
    • CultureX
    • wiki-40b
    • Common Crawl
    • 国会議事、国会答弁、白書、議事録

• 日本語データのトークン数確認

  • 既存
    • CC-100：12Bトークン
    • wiki-ja：0.7Bトークン
    • CultureX：
    • Common Crawl：　角谷さんと塚本さん
  • ビジネス系（約2Bトークン） (1人)、重複削除(2人)
    • DietRecord： 1.04Bトークン
    • japanese_precedent：0.88Bトークン
    • gizi_tokyogikai： 0.098Bトークン
    • gizi_aitigikai： 0.029Bトークン
    • houkokusyo_tokyo： 0.015Bトークン
    • giji_hakusyo： 0.01Bトークン
    • chatwork： 0.003Bトークン
    • edinet： 0.043Bトークン
    • news-ja（atsushi3110/news-ja）： 0.43Bトークン
    • jawiki-news（hpprc/jawiki-news）：0.0013Bトークン
    • annual_reports（amphora/annual_reports_us.ko.ja）：
    • en-ja-corpus（atsushi3110/en-ja-parallel-corpus-augmented）

• 英語 & コードデータのトークン数確認

  • Slimpajama：350Bトークン
  • The Stack v2（商用利用可ライセンス）：1.1Bトークン

• 日、英、コードデータの割合決定 10:5:1→ (120B：60B~：12B)

  (IBM参考：https://japan.zdnet.com/article/35215769/)
  

• コード：（19.3Bトークン）

  • Slimpajama：18.2Bトークン
  • The Stack v2：1.1Bトークン

• 英語：（331.8Bトークン）

  • Slimpajama：331.8Bトークン

• 日本語データのマージ完了

• 英語データのマージ完了

• 評価データの調査

• インストラクション、アラインメントデータの方向性決定

• インストラクションデータの完成（数万件）

• アラインメントデータ完成

アーキテクチャーチーム & 学習・評価チーム：

• 済）モデルの調査

• 済）モデルの決定

• 済）LLaMAモデルの実装

• 済）deepspeedの理解進が悪いみたい。tensorbordは削除

• 進

• へのパラメータ変換 (miwaさん、松永さん)

  1.モデルの一致の確認スクリプト調査

• deepspeedの設定確認 (熊田さん)

• 済）小さいモデルでの実行

• データセットshuffle機能の削除

  https://note.com/kan_hatakeyama/n/na8c7d9c58e88
  

• 済）学習チェックポイントの作成

• GPU停止時のアラート作成（wandb）

  slackとの連携は可能。運営要領は別途制定が必要。

• コマンドワンライン（bash OO.sh）で動かせるコード作成 (mekwさん)

• ハイパーパラメータの決定(松永さん)

  バッチ数1024,

  seqlen 4096,

  adamw(beta1=0.9, beta2=0.95)

  lr1.00E-04 minlr3.30E-06 decay 1.00E-01

• https://docs.google.com/spreadsheets/d/14vbBbuRMEHoqeuMHkTfw3uiZVmyXNuoSp8s-aHvfvZk/edit

https://docs.google.com/spreadsheets/d/1NHt5vgrgiH7jFDWg218rKX4FSoLYiRI0SDRMucg-flM/edit?usp=sharing

• 10Bクラスのハイパーパラメータの準備

(8B, 9B, 10B)

• 10B学習(everyone)

• 本番環境での実験項目

  ノード数が何個？

  誰が環境構築するの？

  輪番制どうする？

• Lossスパイク対策(everyone)

A11-2.pdf (anlp.jp)

スケジュール

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

Phase1 スケジュール (3)

トークナイザー作成用コードGCPでの試走

データセットの前処理

Common Crawl等に対する重複削除

事前学習

英語・コード事前学習

日本語データのマージ

トークナイザー作成用コードGCPでの試走 (1)

データセットの前処理 (1)

事前学習 (1)

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（ 3日）

タスク

リーダー・アーキテクチャーチーム & 学習・評価チーム

• 環境準備の方法共有
• WandB確認方法の共有
• 事前学習のバッチ実行方法共有
• 事前学習のバッチ実行者決定
• ロススパイク時の対処方法調査
• ロススパイク時の対処方法共有
• チェックポイントからの実行方法共有
• 手動チェックポイント作成方法共有
• 運営評価指標の実行
• 自作評価指標の作成
• 自作評価データの取得
• 自作評価データの作成
• ファインチューニング手法の調査
• ファインチューニング手法の実装
• ファインチューニングデータの調査
• ファインチューニングデータの取得
• ファインチューニングデータの作成
• DPO手法の調査
• DPO手法の実装
• DPOデータの調査
• DPOデータの取得
• DPOデータの作成

第7回：週次報告

チーム全体の開発状況

• 日本語データに対する前処理コードの実行（クリーニング、重複削除）
• トークナイザーの実装
• LLaMA2コード実装
• 分散処理学習について試行錯誤
• H100での学習実行開始
  • モデル：llama2ベース (QKの値はllama3を参考) 12.3Bパラメータ
  • 速度：396TFLOPS（1日 約10B）
  • 学習量：200Bトークン（英語・コード100B, 日本語100B程度）
  • 事前学習期間：20.3day
    • 4/28(日)：事前学習開始
    • 5/8(水) ：英語&コード事前学習終了予定
    • 5/18(土) ：日本語（英語&コードを少量含む）事前学習終了予定
  • 語彙数：10万程度（コード2万、英語4万、日本語6万で語彙重複削除）
• ファインチューニングデータの調査

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

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

やったこと:

• フェーズ０の原稿着手中
• GPU死活監視　復帰手順書＆Loss低下？ Notion記事と解説動画作成予定

次やること:

• 事務局と執筆チームでのMTG（5/2）

  → 5/2のミーティングは、21時〜

• フェーズ０の原稿をチーム内共有、フィードバックもらう

サブチーム2（前処理）

• 昨日4月28日の前処理班のミーティングで，前処理・トークナイザー班のタスクが一通り終了したとして，前処理・トークナイザー班を解散し，希望者はデータセット班に合流するのがよいのではないかという議論になった
• 希望者の方はデータセット班などに合流
• データセット班での作業
  • ビジネス向け & コンペでの優勝のために目指すべき評価指標評価用データセットに対して，その評価用データセットでの推論能力向上に寄与するような学習データを探して報告
  • https://www.notion.so/matsuolab-geniac/9560f68a79c94479b8a83807e2de66c3?v=43dcd39ae790470c9afc642e2e417581&pvs=4
  • 重要度が高い評価用データセットに対応する学習データを優先的に探す
  • クリーニング済みで，ある程度量がある事前学習用データを中心に
  • 評価用データセットの種類が多く，かつ個々の評価用データセットの中にも細分化された評価指標があるため，評価指標を細かく見て，対応する学習データを選択

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

やったこと

• CulturaXクリーニング完了
• 事前学習環境の構築
• 評価指標の方針検討・調査

分かったこと

• ‣

次やること

• ファインチューニングデータの準備
• ファインチューニングデータの生成

合意したいこと

• 既存の大規模言語モデルではなく、今回開発するローカルLLMを使ってもらう利点は？
  • 自社などのプライベート情報を入力できること
• 用途は？
  • 業務プロセスQA
  • ビジネス文書添削
  • 会議メモ→議事録・タスク作成
• 上記を踏まえた重視すべき評価項目は？
  • 文章能力
    • 言語理解
    • 自然言語推論
    • 会話
    • 要約
    • 翻訳
  • 知識
    • 一般常識
    • ビジネスドメイン
  • 検索能力
    • エンティティ抽出
    • 情報検索
  • エシカル
    • 制御性
    • 倫理・道徳
    • 真実性
    • 堅牢性
• 事前学習の順位づけについて（順位が高いものほど後ろ
  • 自前のビジネスデータ
  • wikipedia
  • その他（CulturaX, CC100）
• ファインチューニングデータについて
  • 形式は？
    • 数千・万
    • マルチターン対策は？
      • 要調査
  • 評価データセットのtrainとvalidが分かれているものはtrainから学習データをつくる
  • 十分な量がない評価は、他のLLMで生成する？
    • プロンプトイメージ
      • 以下の文章を参考に、新しい質問と回答を日本語で1つ作成してください。

      • 参考

        • 評価データセット内容
    • 商用APIは使えなそう
    • 商用不可の評価データセットをプロンプトに入れて新データを作成するのはルール・著作権問題ないのか？
    • Mixtral 8x7Bをgoogle colaboで回す？

サブチーム4（アーキテクチャー & 学習・評価）

やったこと

• 本番用のスクリプト作成
  • LLaMA3ベース (TP1, PP6)
• 変換コードの調査

分かったこと

• マルチターンのデータがない（ファインチューニングデータ）
• lossスパイクの調査（fp32→bp32）

次やること

• 入力テンプレートの決定
  • chatテンプレート
• 2048までのシーケンスで良いのか
• 他の方が学習実行できるのかどうかの確認

開発のマイルストーン

前処理チーム：

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

データセットチーム：

• 使用データ決定

  • 英語、コード
    • Slimpajama
    • The Stack v2
  • 日本語
    • CC-100
    • CultureX
    • wiki-40b
    • Common Crawl
    • 国会議事、国会答弁、白書、議事録

• 日本語データのトークン数確認

  • 103.7Bトークン
  • 既存
    • CC-100：12Bトークン
    • wiki-ja：0.7Bトークン
    • CultureX：89Bトークン
  • ビジネス系（約2Bトークン） (1人)、重複削除(2人)
    • DietRecord： 1.04Bトークン
    • japanese_precedent：0.88Bトークン
    • gizi_tokyogikai： 0.098Bトークン
    • gizi_aitigikai： 0.029Bトークン
    • houkokusyo_tokyo： 0.015Bトークン
    • giji_hakusyo： 0.01Bトークン
    • chatwork： 0.003Bトークン
    • edinet： 0.043Bトークン
    • news-ja（atsushi3110/news-ja）： 0.43Bトークン
    • jawiki-news（hpprc/jawiki-news）：0.0013Bトークン
    • annual_reports（amphora/annual_reports_us.ko.ja）：
    • en-ja-corpus（atsushi3110/en-ja-parallel-corpus-augmented）

• 英語 & コードデータのトークン数確認

  • Slimpajama：350Bトークン
  • The Stack v2（商用利用可ライセンス）：1.1Bトークン

• 日、英、コードデータの割合決定 10:5:1→ (120B：60B~：12B)

  (IBM参考：https://japan.zdnet.com/article/35215769/)
  

• コード：（19.3Bトークン）

  • Slimpajama：18.2Bトークン
  • The Stack v2：1.1Bトークン

• 英語：（331.8Bトークン）

  • Slimpajama：331.8Bトークン

• 日本語データのマージ完了

• 英語データのマージ完了

• 評価データの調査

• インストラクション、アラインメントデータの方向性決定

• インストラクションデータの完成（数万件）

• アラインメントデータ完成

アーキテクチャーチーム & 学習・評価チーム：

• 済）モデルの調査

• 済）モデルの決定

• 済）LLaMAモデルの実装

• 済）deepspeedの理解進が悪いみたい。tensorbordは削除

• 進

• へのパラメータ変換 (miwaさん、松永さん)

  1.モデルの一致の確認スクリプト調査

• deepspeedの設定確認 (熊田さん)

• 済）小さいモデルでの実行

• データセットshuffle機能の削除

  https://note.com/kan_hatakeyama/n/na8c7d9c58e88
  

• 済）学習チェックポイントの作成

• GPU停止時のアラート作成（wandb）

  slackとの連携は可能。運営要領は別途制定が必要。

• コマンドワンライン（bash OO.sh）で動かせるコード作成 (mekwさん)

• ハイパーパラメータの決定(松永さん)

  バッチ数1024,

  seqlen 4096,

  adamw(beta1=0.9, beta2=0.95)

  lr1.00E-04 minlr3.30E-06 decay 1.00E-01

  • https://docs.google.com/spreadsheets/d/14vbBbuRMEHoqeuMHkTfw3uiZVmyXNuoSp8s-aHvfvZk/edit

• 10Bクラスのハイパーパラメータの準備

(8B, 9B, 10B)

• 10B学習(everyone)

• 本番環境での実験項目

  ノード数

  誰が環境構築するの？

  輪番制どうする？

• Lossスパイク対策(everyone)

A11-2.pdf (anlp.jp)

スケジュール

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

9.5B/day (11万/s) 、2048（seq）、モデルサイズ： 12.3B

200B：（12.2万/s）

英語：11日 4/28~5/8

日本語 ：11日 5/19

Phase1 スケジュール (5)

トークナイザー作成用コードGCPでの試走

データセットの前処理

Common Crawl等に対する重複削除

トークナイザー作成用コードGCPでの試走 (1)

データセットの前処理 (1)

Common Crawl等に対する重複削除 (1)

事前学習 (1)

英語・コード事前学習 (1)

日本語データのマージ (1)

トークナイザー作成用コードGCPでの試走 (2)

データセットの前処理 (2)

Common Crawl等に対する重複削除 (2)

事前学習 (2)

英語・コード事前学習 (2)

日本語データのマージ (2)

トークナイザー作成用コードGCPでの試走 (3)

データセットの前処理 (3)

事前学習 (3)

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（ 3日）

タスク

タスク 4/20以降

環境準備の方法共有

WandB確認方法の共有

事前学習のバッチ実行方法共有

事前学習のバッチ実行者決定

ロススパイク時の対処方法調査

ロススパイク時の対処方法共有

チェックポイントからの実行方法共有

手動チェックポイント作成方法共有

運営評価指標の実行

自作評価指標の作成

自作評価データの取得

自作評価データの作成

ファインチューニング手法の調査

ファインチューニング手法の実装

ファインチューニングデータの調査

ファインチューニングデータの取得

ファインチューニングデータの作成

DPO手法の調査

DPO手法の実装

DPOデータの調査

DPOデータの取得

DPOデータの作成

その他(各メンバー詳細タスク)

担当者	タスク	期限	参考情報	output
小川さん	トークナイザーの特殊トークン確認（llamaモデルのvocabを確認）	4/26 (金)	https://huggingface.co/elyza/ELYZA-japanese-Llama-2-7b/tree/main	使用されている特殊トークン
志賀さん	トークナイザーの特殊トークン確認（llamaモデルのvocabを確認）	4/26 (金)	上に同じ	使用されている特殊トークン
Nishijimaさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
Matsunagaさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
熊田さん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
mekwさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
江國さん
Hamtaryoさん	目標評価指標 & データの重要度決定	4/28(日)		目標評価指標 & データの選定
吉野さん	目標評価指標 & データの重要度決定	4/28(日)		評価指標 & データの選定
和田さん	目標評価指標 & データの重要度決定	4/28(日)		評価指標 & データの選定
miwaさん	CultureX, CC-100に対して重複削除を実施	4/29(月)		重複処理
Enomotoさん	CultureX, CC-100に対して重複削除を実施	4/29(月)		重複処理
Aoiさん	汚いと感じるデータを綺麗にする	4/29(月)		前処理
Ishiharaさん	ファインチューニングコード実装	5/4(土)		Google colabで動作可能
塚本さん	DPOコード実装	5/4(土)		Google colabで動作可能
		5/1(水)
KADOYA RYOTAさん	ロススパイク時の対処方法調査	5/1(水)
kyoさん	ロススパイク時の対処方法調査	5/1(水)

タスク：モデルの最適化 & 学習指針決定

期限：4/25~27（土）

Output：

• 最適なモデルサイズ：学習トークン量がモデルサイズ*20 & 下記の方針で学習ができる
• 高速化のための設定：TP, PP, zero
• 学習方針：

  1. 事前学習→ファインチューニング

     1. 5/15までに事前学習が終わる

  2. 事前学習→（事前学習 & ファインチューニングの並列）

     b. 途中まで3GPUで事前学習、その後2GPUだけ利用して、5/22まで事前学習 & 途中のモデルを利用してファインチューニング

タスク：目標評価指標 & データの重要度決定

期限：4/28 （日）

Output：

1. ビジネス向け & コンペでの優勝のために目指すべき評価指標の決定
2. 評価指標における精度向上のため使用すべき事前学習データセットの重要度決定

補足：

1. 今回のコンペでは、LLM-jp-eval + JMTBench + α （こちらが重くなるかも）

2. wandbのベストプラクティスを確認し、私たちのLLMが目指すべき目標（評価指標）を決定

https://site.wandb.ai/wp-content/uploads/2024/04/LLM-Evaluation-Whitepaper.pdf

• コンペの観点での理想的な評価指標：汎用性の高い評価指標

• ビジネスの観点での理想的な評価指標：下記参照

  ビジネス利用可能：文章要約、Q&A（コールセンター, 社内文章）、議事録・企画書作成

  （どれに着目するかをデータセットから決定するのもOK）

  下記4つの観点で良い出力（https://note.com/kojiro_iizuka/n/na2b385103445）

  • ロバスト性（指示に従ってくれる、入力が多少変わっても正しい出力）
  • 有害性（悪意のある出力をしない）
  • 公平性（差別等を行わない）
  • バイアス （偏った結果を生成をしない）

第8回：週次報告

チーム全体の開発状況（直近1週間で行ったこと）

• H100での英語の事前学習実行
  • モデル：llama2ベース (QKの値はllama3を参考) 12.3Bパラメータ
  • 速度：396TFLOPS（1日 約10B）
  • 学習量：200Bトークン（英語・コード100B, 日本語100B程度）
  • 事前学習期間：20.3day
    • 4/28(日)：事前学習開始
    • 5/8(水) ：英語&コード事前学習終了予定
    • 5/18(土) ：日本語（英語&コードを少量含む）事前学習終了予定
  • 語彙数：10万程度（コード2万、英語4万、日本語6万で語彙重複削除）
• ファインチューニングデータの調査

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

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

やったこと:

• 執筆チームMTG2回目　5/2
  →外部発信
  　外部発信のzenn （継続的に更新、今週来週あたりから開始？）

  • ‣
  • 【ビジネスで利用可能なLLMを開発】チーム体制（組織図、サブチームごとの役割、メンバーごとの分担など）の紹介【Vol.01】
  • チーム発表用スライド（Phase0 & 1）コンペ終了後 5/27（優勝チーム）
    • https://docs.google.com/presentation/d/1HTfZLcRMdM_grhXDkX8HFZcLZzo9K5KVKs2vKKipicY/edit#slide=id.g2cccecef843_0_0

• フェーズ０の原稿着手

上記、発表スライドの一部として

• GPU死活監視　
  復帰手順書＆Loss低下？ Notion記事と解説動画作成予定

分かったこと:

• 優勝チーム以外のメンバーの受け皿として、外部発信してほしい。（Zennなど）
  • 事務局からお題やイベントを共有する予定

次やること:

• フェーズ０の原稿をチーム内共有、フィードバックもらう

https://docs.google.com/presentation/d/1HTfZLcRMdM_grhXDkX8HFZcLZzo9K5KVKs2vKKipicY/edit?usp=sharing

• 上記、外部発信チームzenn記事ドラフトの確認やネタ募集
  https://www.notion.so/matsuolab-geniac/Zenn-4ef59eaa64d34e31971edf6959e7dba1?pvs=4

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

やったこと

• 事前学習データ追加

  • 内閣府の論文要旨
    • https://huggingface.co/datasets/kawagoshi-llm-team/carbinet_office
  • 財務省広報誌（河越さん

• 指示学習データの定義

  • 指示学習データを生成するにあたっての、LLMに求める能力やタスクを整理。各タスクごとに生成プロンプト例も用意

  【松尾研】 Instruction-Tuning.xlsx

• ビジネス系の指示学習データ制作中

  • https://docs.google.com/spreadsheets/d/1T1zvbTRBtUS7GeJ4OOrpOCHlIYpzSIK2SUcEkQ5uKns/edit?usp=sharing)

• self-instruct用のPoC

  • mixtral 8x22B
    • https://docs.google.com/spreadsheets/d/10htM2mRPkJPLBqiz6xpORtXe3CMM96zV/edit?usp=sharing&ouid=111988221745926943744&rtpof=true&sd=true
  • phi3
    • 検証中

わかったこと

• deep infraをを使用すると安価にmixtral 8x22Bが使用可能
• 指示学習データフォーマット
  • system /input / outputで分ける
  • マルチターンも入れたい

次にやること

• self-instructに合わせた形式の事前学習データ例のスプレッドシートを展開（角谷さん
• プロンプトカテゴリの確認（江國
• プロンプト例を作成していく（全員【後で割り振りつつ、一人１カテゴリ1個くらい？
• self-instruct用のモデルをphi3とmixtral 8x22Bで比較し、決定（小川さん
• 使用できそうな指示学習データをピックアップ（江國
• 生成後のアノテーションの案を検討（角谷さん

サブチーム3（アーキテクチャー & 学習・評価）

やったこと

• merge kitの調査
• 評価スクリプトの調査
• ファインチューニング用データセットの調査

分かったこと

• マルチターンのデータについて（llm-jpを確認）
• lossスパイクの調査（fp32→bp32）

次やること

• 入力テンプレートの決定
  • chatテンプレート
• 2048までのシーケンスで良いのか
• 他の方が学習実行できるのかどうかの確認

開発のマイルストーン

前処理チーム：

• 前処理コードの完成
• 重複処理
• クリーニング済み日本語データの完成
• 日本語トークナイザーの作成
  • 下記のような語彙を含む
    • NEC, 日立, 富士通, 東芝, 清水建設, トヨタ, 日産, NTT, ソフトバンク, 原告, 特許, 著作, 会計, 株式会社 etc…

データセットチーム：

• 使用データ決定

  • 英語、コード
    • Slimpajama
    • The Stack v2
  • 日本語
    • CC-100
    • CultureX
    • wiki-40b
    • Common Crawl
    • 国会議事、国会答弁、白書、議事録

• 日本語データのトークン数確認

  • 103.7Bトークン→ 61Bトークン（クリーニング後）
  • 既存
    • CC-100：12Bトークン→ 5.23Bトークン（クリーニング後）
    • wiki-ja：0.7Bトークン→ 0.4Bトークン（クリーニング後）
    • CultureX：89Bトークン→ 55.49Bトークン（クリーニング後）
  • ビジネス系（約3Bトークン）
    • DietRecord： 1.04Bトークン
    • japanese_precedent：0.88Bトークン
    • gizi_tokyogikai： 0.098Bトークン
    • gizi_aitigikai： 0.029Bトークン
    • houkokusyo_tokyo： 0.015Bトークン
    • giji_hakusyo： 0.01Bトークン
    • chatwork： 0.003Bトークン
    • edinet： 0.043Bトークン
    • news-ja（atsushi3110/news-ja）： 0.43Bトークン
    • jawiki-news（hpprc/jawiki-news）：0.0013Bトークン
    • annual_reports（amphora/annual_reports_us.ko.ja）：
    • en-ja-corpus（atsushi3110/en-ja-parallel-corpus-augmented）

• 英語 & コードデータのトークン数確認

  • Slimpajama：350Bトークン
  • The Stack v2（商用利用可ライセンス）：1.1Bトークン

• 日、英、コードデータの割合決定 10:5:1→ (120B：60B~：12B)

  合計 183B（英語 97B, コード 16B, 日本語 70B）

  • 英語：90B + コード：9B = 10: 1 = 99B

  • 英語：7B + コード：7B + 日本語：70B = 1:1:10 = 84B

    (IBM参考：https://japan.zdnet.com/article/35215769/)

• コード：（19.3Bトークン）

  • Slimpajama：18.2Bトークン
  • The Stack v2：1.1Bトークン

• 英語：（331.8Bトークン）

  • Slimpajama：331.8Bトークン

• 日本語データのマージ完了

• 英語データのマージ完了

• 評価データの調査

• インストラクション、アラインメントデータの方向性決定

• インストラクションデータの完成（数万件）

• アラインメントデータ完成

アーキテクチャーチーム & 学習・評価チーム：

• 済）モデルの調査

• 済）モデルの決定

• 済）LLaMAモデルの実装

• 済）deepspeedの理解進が悪いみたい。tensorbordは削除

• 進

• へのパラメータ変換 (miwaさん、松永さん)

  1.モデルの一致の確認スクリプト調査

• deepspeedの設定確認 (熊田さん)

• 済）小さいモデルでの実行

• データセットshuffle機能の削除

  https://note.com/kan_hatakeyama/n/na8c7d9c58e88
  

• 済）学習チェックポイントの作成

• GPU停止時のアラート作成（wandb）

  slackとの連携は可能。運営要領は別途制定が必要。

• コマンドワンライン（bash OO.sh）で動かせるコード作成 (mekwさん)

• ハイパーパラメータの決定(松永さん)

  バッチ数1024,

  seqlen 4096,

  adamw(beta1=0.9, beta2=0.95)

  lr1.00E-04 minlr3.30E-06 decay 1.00E-01

  • ‣

• 10Bクラスのハイパーパラメータの準備

(8B, 9B, 10B)

• 10B学習(everyone)

• 本番環境での実験項目

  ノード数

  誰が環境構築するの？

  輪番制どうする？

• Lossスパイク対策(everyone)

A11-2.pdf (anlp.jp)

スケジュール

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

9.5B/day (11万/s) 、2048（seq）、モデルサイズ： 12.3B

200B：（12.2万/s）

英語：11日 4/28~5/8

日本語 ：11日 5/19

Phase1 スケジュール (7)

英語・コード事前学習

日本語データ事前学習

英語・コード事前学習 (1)

日本語データ事前学習 (1)

トークナイザー作成用コードGCPでの試走 (2)

データセットの前処理 (2)

Common Crawl等に対する重複削除 (2)

トークナイザー作成用コードGCPでの試走 (3)

データセットの前処理 (3)

Common Crawl等に対する重複削除 (3)

事前学習 (3)

英語・コード事前学習 (3)

日本語データのマージ (3)

トークナイザー作成用コードGCPでの試走 (4)

データセットの前処理 (4)

Common Crawl等に対する重複削除 (4)

事前学習 (4)

英語・コード事前学習 (4)

日本語データのマージ (4)

トークナイザー作成用コードGCPでの試走 (5)

データセットの前処理 (5)

事前学習 (5)

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（ 3日）

タスク

4/20以降

環境準備の方法共有

WandB確認方法の共有

事前学習のバッチ実行方法共有

事前学習のバッチ実行者決定

ロススパイク時の対処方法調査

ロススパイク時の対処方法共有

チェックポイントからの実行方法共有

手動チェックポイント作成方法共有

運営評価指標の実行

自作評価指標の作成

自作評価データの取得

自作評価データの作成

ファインチューニング手法の調査

ファインチューニング手法の実装

ファインチューニングデータの調査

ファインチューニングデータの取得

ファインチューニングデータの作成

DPO手法の調査

DPO手法の実装

DPOデータの調査

DPOデータの取得

DPOデータの作成

各メンバータスク

担当者	タスク	期限	参考情報	output
小川さん	トークナイザーの特殊トークン確認（llamaモデルのvocabを確認）	4/26 (金)	https://huggingface.co/elyza/ELYZA-japanese-Llama-2-7b/tree/main	使用されている特殊トークン
志賀さん	トークナイザーの特殊トークン確認（llamaモデルのvocabを確認）	4/26 (金)	上に同じ	使用されている特殊トークン
Nishijimaさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
Matsunagaさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
熊田さん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
mekwさん	モデルの最適化 & 学習指針決定	4/27(土)		最適なモデルサイズ、TP, PP, zeroの設定
江國さん
Hamtaryoさん	目標評価指標 & データの重要度決定	4/28(日)		目標評価指標 & データの選定
吉野さん	目標評価指標 & データの重要度決定	4/28(日)		評価指標 & データの選定
和田さん	目標評価指標 & データの重要度決定	4/28(日)		評価指標 & データの選定
miwaさん	CultureX, CC-100に対して重複削除を実施	4/29(月)		重複処理
Enomotoさん	CultureX, CC-100に対して重複削除を実施	4/29(月)		重複処理
Aoiさん	汚いと感じるデータを綺麗にする	4/29(月)		前処理
Ishiharaさん	ファインチューニングコード実装	5/4(土)		Google colabで動作可能
塚本さん	DPOコード実装	5/4(土)		Google colabで動作可能
		5/1(水)
KADOYA RYOTAさん	ロススパイク時の対処方法調査	5/1(水)
kyoさん	ロススパイク時の対処方法調査	5/1(水)

タスク：モデルの最適化 & 学習指針決定

期限：4/25~27（土）

Output：

• 最適なモデルサイズ：学習トークン量がモデルサイズ*20 & 下記の方針で学習ができる
• 高速化のための設定：TP, PP, zero
• 学習方針：

  1. 事前学習→ファインチューニング

     1. 5/15までに事前学習が終わる

  2. 事前学習→（事前学習 & ファインチューニングの並列）

     b. 途中まで3GPUで事前学習、その後2GPUだけ利用して、5/22まで事前学習 & 途中のモデルを利用してファインチューニング

タスク：目標評価指標 & データの重要度決定

期限：4/28 （日）

Output：

1. ビジネス向け & コンペでの優勝のために目指すべき評価指標の決定
2. 評価指標における精度向上のため使用すべき事前学習データセットの重要度決定

補足：

1. 今回のコンペでは、LLM-jp-eval + JMTBench + α （こちらが重くなるかも）

2. wandbのベストプラクティスを確認し、私たちのLLMが目指すべき目標（評価指標）を決定

https://site.wandb.ai/wp-content/uploads/2024/04/LLM-Evaluation-Whitepaper.pdf

• コンペの観点での理想的な評価指標：汎用性の高い評価指標

• ビジネスの観点での理想的な評価指標：下記参照

  ビジネス利用可能：文章要約、Q&A（コールセンター, 社内文章）、議事録・企画書作成

  （どれに着目するかをデータセットから決定するのもOK）

  下記4つの観点で良い出力（https://note.com/kojiro_iizuka/n/na2b385103445）

  • ロバスト性（指示に従ってくれる、入力が多少変わっても正しい出力）
  • 有害性（悪意のある出力をしない）
  • 公平性（差別等を行わない）
  • バイアス （偏った結果を生成をしない）

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

松尾研LLMコミュニティへのご案内

Slack参加リンクを始めとして、GENIACの概要やLLMコミュニティ主催各イベント等、関連リンクはこちらにまとめられております。
ぜひご覧ください！！
https://linktr.ee/matsuolab_community