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

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

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

スケジュール

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

直近のスケジュール ● 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?)

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

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

クリーニングの紆余曲折

概観

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

• https://jpn.nec.com/rd/technologies/202310/index.html

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

意外と動く

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

• https://www.anlp.jp/proceedings/annual_meeting/2024/pdf_dir/P8-6.pdf

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

• https://www.anlp.jp/proceedings/annual_meeting/2024/pdf_dir/A3-2.pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• https://arxiv.org/abs/2208.03306

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

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

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

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

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

• https://arxiv.org/abs/2208.03306
• https://arxiv.org/pdf/2303.14177.pdf

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

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

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

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

• https://note.com/kan_hatakeyama/n/n890f25c6fd07

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

• https://note.com/kan_hatakeyama/n/n2f1a8dfeebfa

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

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

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

• https://note.com/kan_hatakeyama/n/n2f1a8dfeebfa

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

• https://arxiv.org/abs/2305.11206

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

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

• https://note.com/kan_hatakeyama/n/n5a85700bf46c

今後にやるべきこと

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