大規模言語モデル開発の進捗まとめ(◯データ整備・△事前学習・△ファインチューニング)

8.2K Views

April 08, 24

スライド概要

10b程度の大規模言語モデルを作るための準備状況に関するスライドです。
データ整備と、事前学習の練習が概ね終わったところです。
開発チーム内での情報共有を主目的に、作りました。

profile-image

化学・材料・データ・AI・ロボット

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

モデル開発の進捗まとめ (データ整備・事前学習・ファイン チューニング) 2024/4/8 Kan Hatakeyama 作業中です。 ミスや、不正確な内容があるかもしれませんので、ご了承ください コメント類は、slackなどでいただけると助かります

2.

アウトライン ● ● スケジュール 事前学習データのクリーニングの紆余曲折 ○ ○ ○ ○ ● 概観 学習データのノイズ依存性 コーパスのカテゴリバランスを調整する カリキュラム学習について ファインチューニングについて

3.

スケジュール

4.

チーム向け: 事前学習データの締め切りが近づいてます! 締め切りに間に合わないと、今回の学習には使えません* ● ● ● ● クリーニングスクリプトの締め切り: 4/10 7:00 事前学習データのアノテーション締め切り: 同上 日本語の事前学習データの締め切り: 4/12 23:59 英語・コード系データの締め切り: 4/14 23:59 *50bには間に合うかも?

5.

直近のスケジュール ● 4/10からクリーニング処理を開始 ● 4/15-22頃から学習を開始 ○ ○ AMD EPYC 7702P 64-Core Processor GCP 作業フロー ● ● 日本語系コーパスの清掃 (2-5 days?) ● 機械学習によるノイズ文章の判定(fasttext) ● ルールベースクリーニング ● 教師なしクラスタリング(1万ジャンル, fasttext) ● 重複削除 (1-2 days?) テキスト統合 ○ ○ ● 上記コーパス + 英語系コーパス (1 day?) この段階で、ルールベースでの軽いテキスト処理を加えることは可能 トークナイズ (1 day?)

6.

データ状況 TODO: まだ処理用のマシンに載せられてないコーパス クリーニング&統合後、全体で1 TB (≒200b token)程度を想定

7.

今後1ヶ月ほどのスケジュール ● 事前学習 (4/15頃~5/10頃) ○ ○ ● 祈り・見守り・トラブル対応 ファインチューニングの準備 (最重要) ■ データ ● 10 BクラスのLLMの能力に関する認識共有 ● 実用(やevaluation)を意識した ■ コード ● エキスパートモデルの切り替え ファインチューニング(5/10頃ー5/21) ○ この期間は、コードを回す &微調整を行うのみ

8.

クリーニングの紆余曲折

9.

概観

10.

なにをどのように、どの程度、 フィルタリングすべきかという問題 NEC独自の大規模言語モデル( LLM)開発の裏側に迫る https://jpn.nec.com/rd/technologies/202310/index.html

11.

実験: クリーニング無しの文章を学習させてみる(0.3b model)

12.

意外と動く

13.

しかし、Webテキストの何割かは性能向上に殆ど寄与しない ような気もする 研究例 NLP2024 https://www.anlp.jp/proceedings/annual_meeting/2024/pdf_dir/P8-6.pdf

14.

学習テキストをクリーニングで半分くらいに減らしても予測性 能はあまり変わらなかったとの報告も。 NLP2024 https://www.anlp.jp/proceedings/annual_meeting/2024/pdf_dir/A3-2.pdf

15.

少なくとも、自動挿入系のテキストはノイズかもしれない 数十b以上のモデルでは、わずか数件の重複データが性能に悪影響を及ぼすとの話もどこかで聞いた気が ...

16.

学習データのノイズ依存性を 定性的に調べる

17.

カリキュラム学習をしてみる (雑食モデル) ● 英語wiki to 雑多な日本語の順に学習 ○ ● Training Loss (y軸)の下がりが、雑多な日本語部分で、 明らかに悪い ○ 0.1, 2.7b modelで挙動を確認 ○ ● 日本語: CommonCrawl系のwebテキストを軽くクリーニ ングしたもの モデルサイズに対して、与える情報量が多い &複雑す ぎる可能性 考察: ノイズとなるテキストを、ある程度は積極的に除く べきかもしれない

18.

徹底的にクリーンなテキストを学習させてみる (温室モデル: 黄色線) ● 温室LLMを試作 ○ ○ ● 雑多な日本語を学習した「雑食モデル」(前 ページ) ○ ● 日英Wiki, NHKニュース,青空文庫,... 学習token数は、わずか 2.8b 30b token 訓練lossは、どちらも同程度 ○ データが異なるので、一概に比較はでき ないが、日本語性能は、意外と同じか も??

19.

出力比較: 雑食モデル vs 温室モデル input: 東京工業大学に 入力に対する perplexity: 雑食で18400.0, 温室で10088.0 雑食: 東京工業大学に在学していた頃、私は「日本学術会議」の会員でした。 【楽天市場】購入者さんの【送料無料】【中古】 (10)(2,489件)>選択してくださいホワイトブラックグレーレッドブルーグリーンイエロ 温室: 東京工業大学に籍を置く。 1982年、東京大学生産技術研究所 (現・東京工芸繊維大学 )を卒業して同大学院修士課程を 修了する。同年 4月、「日本工業規格」の制定に参画し、同機構が発行した「 JIS Z 035 雑食モデルは、学習時のノイズ情報(自動挿入系のテキスト類)で、出力が混乱している印象を受ける

20.

出力比較: 雑食モデル vs 温室モデル input: 地球温暖化はマジでやばい 雑食: 地球温暖化はマジでやばい。 2013年6月8日(金)に、環境省が「気候変動に関する政府間パネル」 (IPCC:Intergovernmental Panel on Climate Change and t 温室: 地球温暖化はマジでやばいきんまんが起こっている。 2014年8月、第3弾『おむすびまんとたまごの国』が発売。『おむ すびまんとたまごのくに』では「たまごの国」を舞台とし、「たまごの国」の舞台である「たまご 温室モデルは、「マジでやばい」のような、カジュアルな表現に(未学習のため)対応できていない

21.

軽くまとめ: 出力のノイズ依存性 ● ● 学習データにノイズが含まれていても、「日本語は喋れる」 しかし、ノイズはモデルには悪影響を及ぼす可能性がある ○ ○ ○ ● 予測性能の向上には、殆ど寄与しない模様 変な出力を行うクセが出る 限られたリソースで学習を行う上で、ノイズを学ばせるのは「コスパが悪い」 3-10b程度のモデルが、雑多なweb文章を学び切るのは難しいかもしれない ○ ○ ○ train lossの低下が、明らかに停滞する (2.7bモデルまでで確認 ) 0.1 to 2.7 bまでモデルサイズを大きくしても、改善はわずか 数十b以上では、更に lossが減るかもしれないが、逆にノイズに過学習してしまうかもしれない

22.

やったこと: ルールベースのノイズ除去 クリーニング前のコーパス クリーニング後のコーパス

23.

脱線話題: 「価値」のある仕事とは? (説教臭くてすみません) 「価値」のある仕事には、大きく2つの傾向がある。 A. 他の人にできない、高度なタスク B. 他の人がやりたがらない、泥臭いタスク 誰でもできる/誰もがやりたがる仕事では、凡庸な成果しか出ない。 経験的に、この傾向は、一般論にとどまらず、研究開発などでも 成立する。 Hatakeyamaは、A.天才的な仕事があまりできないので、専門*を意識しながら、Bをやることを、わりと意識している。 (*特に、自然言語処理については、Hatakeyamaは専門家ですらない) → 泥臭い仕事(データベース整備、ルールベース処理、アノテーション, タスク特化...)に力をいれる

24.

コーパスのバランスを調整する

25.

論点「広告」はノイズか? 持論: ノイズとまでは言い切れないが、学習に「悪 影響」を及ぼす可能性かもしれない ● ● 理由1: 広告サイトが多すぎる 理由2: 似たような文章が多い チームメンバーの方々が協力しながら、common ctawl系のweb ページをアノテーションした結果(現在進行中)

26.

広告サイトが多すぎる問題 ● ● 限られたモデルサイズ、計算リソース*で事前学習を行うにあたり、学習カテゴリとして、広告系サイトばかりを学習 するのは、計算リソースに対するコスパが悪いかもしれない team内で、「広告文を作りたい」という意見もなかった?ので、あえて広告ばかり学ばせる必要もない →学習コーパスのカテゴリバランスを調整したい *H100 x 20枚程度、1ヶ月弱の学習リソースを使用予定。10b 程度のモデルで、200-600 btoken程度は学習させられそ うだが、具体値の推定が難しい(実際のFLOPsや、TransformerEngineの使用有無などがまだよく分かってないため)。

27.

Fasttextによる「ゴミ文章」の除外 ● ● 高速と話題のFasttextで、「ゴミ文章」を除外させたい 4/7現在、600件程度のアノテーションデータが有り ○ ○ ● 分類精度は90%程度 ○ ● 広告、単語の羅列、公序良俗に反する、日本語としてクオリティが低いサイトを noiseと定義 それ以外を goodと定義 少しは「ゴミ文書」があってもよいので、 100%である必要はない。 結果 ○ ○ ○ 体感として、テキストのバランスが良くなった印象 一方、一部のカテゴリでは広告サイトがごっそり残っていたりするので、アノテーションデータの追加が必須 noiseと誤判定された、良質な文書の割合も減らしたい

28.

4/8時点のコーパス 「ノイズ除去」、「カテゴリバランス」ともに、良くなってきたが、あと一息という印象 → 泥臭い作業(除去ルールの追加、アノテーション)をもう少し頑張る!

29.

カリキュラム学習について

30.

基本思想: モデルは全能ではない! ● 数ー数十b程度のモデルに、何でもかんでも突っ込むアプローチは、おそらく、無理筋 ○ ● 例: ドメイン特化モデルの構築 ■ 英語に強い Llama2, Mistral, etcを、日本語ドメインで強化するために継続学習 ■ Code系に強い小型モデル ■ Mixture of Experts (トークンレベルで smaller modelが分業) ■ Branch-Train-Merge (ドメインレベルで smaller modelが分業) 先述の通り、実際にtrain lossの低下が起こりにくくなっている

31.

カリキュラム学習&Branch-Train-Merge(BTM) ● ● BTM: コーパスをドメインごとに分割し、それらに特化したモ デルを訓練し、専門家群を作るアプローチ 元の論文では、専門家モデルを独立に作っているが、計算資 源の面から、少しもったいない ○ ● トークン数を稼いだ方が、モデルそのもの性能は scaling law に従い、わずずつは上昇する 本team: カリキュラム的に、ドメインごとにモデルを継続学習 &チェックポイントで保存するアプローチを取りたい(次のスラ イド)

32.

“一夜漬け作戦” 上質な日英、合成テキストを構築後、 k-meansなどで分割します モデルは過去のことを忘れがちなので、 専門に特化したモデル群を集めて推論する (Mixture of Experts/ Branch-Train-Merge) … = 専門家 の 集合 … 継続学習

33.

実際: カリキュラム学習は、思ったより難しいかも ● 以下の構成でカリキュラム学習(合計30b token 程度) ○ ○ ○ Model 0 ■ 英語Wiki Model 1 ■ +雑多な日本語 Model 2 ■ +日本語wiki 日本語Wikiは100万件ちょっとしか記事がないので 、token数がとても少ない点に注意。 train lossは一気に下がっているが、、、結果は次項

34.

実際: カリキュラム学習は、思ったより難しいかも ● きれいな日本語を最後に少しだけ 学んだmodel 2では... ○ ○ 入力文章に対する予測性能 (perplexity)が、顕著に悪化 日本語の後に、意味不明の英語 が出力されるケースが激増

35.

実際: カリキュラム学習は、思ったより難しいかも ● きれいな日本語を最後に少しだけ 学んだmodel 2では... ○ ○ 入力文章に対する予測性能 (perplexity)が、顕著に悪化 日本語の後に、意味不明の英語 が出力されるケースが激増 定性的にも、model 2がベストと思える出 力事例が見当たらなかった

36.

仮説: 中途半端なカリキュラム学習は悪影響かも? ● ● ● ● BTM系の論文でも、適切なモデル分割数が検討されている 特定のドメインに対して、十分量のテキストを学習させないと、モデルが逆に「混乱」してしまうのかも ?? 仮説: 今回のカリキュラムは、低品質テキスト→高品質テキスト であったが、特定のドメイン(トークン分布) に分割して、カリキュラム学習を行った方がよいのかもしれない 現在: 初心?に返り、データをクラスタリングして訓練を行う方法(c-BTM)を回し中。 lossは順調に減ってます。 (ドメインが切り替わるたび、lossは上がります)

37.

ファインチューニングについて

38.

持論: 大規模言語モデルは万能ではない ● GPT-4などの商用モデル ○ ○ ● 訓練法は全く公開されていない ファインチューニングで相当の労力を使った、もはや事前学習よりも重要、という類の話は非常によく聞く ローカルモデル ○ 後述の通り、人間にとっては当たり前 ?の基本的なことが殆どできない

39.

大半のモデルは、簡単な選択肢問題すら正確に解けない ● ● JCommonSenseQAと呼ばれ るベンチマークを評価 回答を「数値」で答えるという指 示がポイント

40.

GPT3.5は日本語を正しく理解できないケースがある 一部のGPT3.5系モデルは、「数値だけを答えろ」とい う指示を守ることができなかった (詳細はこちら) (大規模&丁寧に作られたGPT3.5ですら、このタスク を解けないということは、それ以下のサイズのモデル は...)

41.

「日本語特化」のモデルの半数以上は、 選択肢問題を全く解けなかった ● ● LLM Nejumi Leaderboardに記載されている JCommonSenseのスコア分布を解析 半数以上のモデルは、「数値を出力しろ」という 指示を守ることができなかった* *zero shot推論

42.

モデルサイズと選択肢問題への回答能力は相関しない ● ● モデルの基礎性能(アルゴリズム・規模)と当該 問題に対する回答能力は相関しなかった (少なくともこの規模のモデルでは) 学習データ が重要であることを示唆する結果

43.

選択肢問題を解けるようになるために必要な訓練内容と量は? ● ● ● llm-jp-13bに、JCommonSenseQAの訓練 データを学習させ、性能を評価 数百件以上のデータでの訓練が必要との結果 選択肢問題以外でファインチューニングを行っ ても、回答性能は殆ど上昇せず ○ ○ dolly-ja, oasst, ichikaraなどでも検証 このサイズのモデルは、恐ろしく汎化性能が 低い可能性

44.

それ以外のタスクでの検証例 ● タスクによって必要なデータ数は異なる ○ ● ただし、総じて数十ー数百件は必要 詳細はこちら

45.

LIMA論文などとの整合性 ● LIMA論文では、ファインチューニングデータの数は少ない(1000件程度)方が良いとの報告 ○ ○ ● ただし7bモデルでは、 2000件がベターであった 噂の情報 ■ ファインチューニングのしすぎは、モデルの思考力を下げてしまう ■ モデルサイズが大きい /事前学習が成功しているほど、ファインチューニングのデータは少なくても良い 仮説 ○ ○ 小さなモデルはあまり賢くないので、それなりのトレーニングが必要 ■ GPT3,4クラスのモデルが、どれくらい・どんな訓練をされてるかはわからない (ただし、相当に注意深くさ れているはずである ) 定型出力を求めるタスクでは、特に多くのトレーニングが必要

46.

モデルの理解度に関する持論 ● ● 大規模言語モデルはまだ理解力が低いので、 懇切丁寧に指導を行ってあげるタスクが必須 努力はできるが、理解力がとても低い生徒を育 てるイメージ ○ タスクごとの ■ 理解力の把握 ■ きめ細やかな訓練 が、おそらくは重要

47.

タスク特化で訓練をすれば、 商用モデルを超える性能も出せる (こちら) ● 定型出力系のベンチマーク(llm-jp-eval)の 訓練データだけを学ばせたモデル ○ ● GPT3.5を超える性能を発揮 ■ 逆にいうと、 GPT3.5などは、指示理 解や定型出力がそれだけ苦手と いうことか ? 既述の通り、10bクラスのモデルの理解力、 汎化性能は限定的である ○ ○ その実力を踏まえず、ざっくり訓練するだけ では、「なにかできそうで、結局使えない」 モ デルが得られる リスクが大きい タスク特化 *でモデルを作る &その経験を 積むのは、 practicalな観点からも有益 *例えば実用に近いところでは、コーディング、定型データの出力 (json)、など。ベンチマークはデータが充実しているので、性能検 証が行いやすい利点がある。 どこまでいけるかは、今後の頑張り次第...

48.

今後にやるべきこと

49.

主なTODO ● データセット ○ 10bモデルのための、最後の詰め ○ 50bモデルを想定したデータ準備は、今からやらないと多分間に合わない ● 事前学習 ○ ● 祈り・トラブル対応 ファインチューニング・評価 ○ ○ ○ ○ データセットの作成 (泥臭いが、もっとも効果的で、世の中に貢献できる仕事 ) しかし、ほぼ未着手 (進捗度1%程度) インストラクションチューニングの条件検討 (colabなどで気軽に試せるようにしたい ) RLHF, DPOなどの活用検討 (明らかに重要らしいが、未着手 ) エキスパートモデルの切り替え手法の検討 (これもあまりやれてない )