Pretraining (408) — 3/3


Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Supervised-FineTuning (SFT) #AES(AutomatedEssayScoring) #Surface-level Notes Issue Date: 2024-11-28 Comment

SASでは回答データが限られているので、限られたデータからより効果的に学習をするために、事前に他のデータでモデルをpre-finetuningしておき、対象データが来たらpre-finetuningされたモデルをさらにfinetuningするアプローチを提案。ここで、prompt中にkeyphraseを含めることが有用であると考え、実験的に有効性を示している。

image

image



BERTでfinetuningをした場合は、key-phraseを含めた方が性能が高く、特にfinetuningのサンプル数が小さい場合にその差が顕著であった。

image



次に、LLM（swallow-8B, 70B）をpre-finetuningし、pre-finetuningを実施しない場合と比較することで、pre-finetuningがLLMのzero-shot、およびICL能力にどの程度影響を与えるかを検証した。検証の結果、pre-finetuningなしでは、そもそも10-shotにしてもQWKが非常に低かったのに対し、pre-finetuningによってzero-shotの能力が大幅に性能が向上した。一方、few-shotについては3-shotで性能が頭打ちになっているようにみえる。ここで、Table1のLLMでは、ターゲットとする問題のpromptでは一切finetuningされていないことに注意する（Unseenな問題）。

image



続いて、LLMをfinetuningした場合も検証。提案手法が高い性能を示し、200サンプル程度ある場合にHuman Scoreを上回っている（しかもBERTは200サンプルでサチったが、LLMはまだサチっていないように見える）。また、サンプル数がより小さい場合に、提案手法がより高いgainを得ていることがわかる。

image



また、個々の問題ごとにLLMをfinetuningするのは現実的に困難なので、個々の問題ごとにfinetuningした場合と、全ての問題をまとめてfinetuningした場合の性能差を比較したところ、まとめて学習しても性能は低下しない、どころか21問中18問で性能が向上した（LLMのマルチタスク学習の能力のおかげ）。

image

[Perplexity(hallucinationに注意)]( https://www.perplexity.ai/search/tian-fu-sitalun-wen-wodu-mi-ne-3_TrRyxTQJ.2Bm2fJLqvTQ#0)




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Blog #OpenWeight #Japanese #One-Line Notes Issue Date: 2024-11-25 Comment

MoE Layerの説明、Sparse Upcyclingの説明、MoEモデルを学習する際に、学習時の学習率の設定が大きすぎると初期に損失が増大し、小さすぎると損失の増大は防げるがlong runで学習した際の性能向上が小さかったこと、元のモデルのパラメータを毀損しないように、Upcyclingをした元モデルの最終的な学習率を踏襲して学習をし、学習率をさらに減衰させていったこと、などが記載されている。

また、性能評価として同等のactivation parameter数を持つモデルと日本語のQAタスクで比較した結果も載っている。

- [Paper Note] Sparse Upcycling: Training Mixture-of-Experts from Dense Checkpoints, Aran Komatsuzaki+, ICLR'23

MoE Layerについては
- [Paper Note] Mixtral of Experts, Albert Q. Jiang+, arXiv'24, 2024.01

も参照のこと




Paper/Blog Link My Issue
#Article #EfficiencyImprovement #NLP #Supervised-FineTuning (SFT) #One-Line Notes #Reference Collection Issue Date: 2024-11-07 Comment

ZeROの説明がわかりやすい

こちらの記事もわかりやすい

https://zenn.dev/turing_motors/articles/d00c46a79dc976

DeepSpeedのコンフィグの一覧

https://www.deepspeed.ai/docs/config-json/

transformersにおけるdeepspeedのドキュメント:
https://huggingface.co/transformers/v4.9.2/main_classes/deepspeed.html

参考: deepspeedの使い方まとめ
https://note.com/fukudawataru/n/n5152e6f587c8

ZeRO Stage3を使う場合、ページ後方にしれっととんでもなく重要なことが書いてあるので気をつけましょう。。。。

https://huggingface.co/docs/transformers/v4.17.0/en/main_classes/deepspeed#constructing-massive-models



image

ZeROはparameterとoptimizerのmemory footprintの最適化を頑張っていて、activation memory footprint（バッチをforward passに流す時に消費されるメモリ）の削減は、tiling, activation/gradient checkpointingとかで頑張ってねという



という話が本家issueの4047に記載されている。

結論: つまづいたらDeepSpeedのIssueをエラーメッセージで検索かけるのが一番効果的




Paper/Blog Link My Issue
#Article #Tutorial #NLP #LanguageModel #Blog #KeyPoint Notes Issue Date: 2024-07-08 Comment

LLMの事前学習における知見がまとまっている記事とのこと

・Megatron LMで学習
　→ 3D Parallelismなどの分散学習手法によりHF Trainerより高速
　→ Data Parallelim、Tensor Parallelism、 Pipeline Parallelismを組み合わせたもの
・GPUメンテナンス、不良で学習が継続できなかった場合はcheckpointをロードして学習
・学習曲線が安定しているように見えるがSpikeは発生している。発生時はgradient normが急激に上昇する
・LlamaなどのLLMからの継続的事前学習ではなくfrom scratchから学習しているので透明性が高い
・Transformer engineを利用
・AdamWを利用
・attention dropout, hidden dropoutは0.0

>この際、 通信を多く必要とする分散手法のワーカー（Tensor Parallelワーカー）はノード内に配置するようにMegatron-LMのデフォルトではなっているため、今回もそれを利用しました。このようにする理由は、ノード内の通信はNVLinkにより、ノード間通信よりも高速であるためです。また、Data Parallelの勾配平均化のための通信を考慮して、Data Parallelワーカーも可能な限りノード内に配置するMegatron-LMデフォルトの挙動を利用しました。
Pipeline Parallelismは他の並列化手法と比較して通信量が少ないP2P(Point-to-Point)通信であるため、パイプラインステージはノード間で配置するようにしました。これも、Megatron-LMデフォルトの挙動です。

勉強になる

・通常のデータ並列はoptimizer stateをworker間で複製するので遅い。Deep Speed Zero 1のように分散して保有することで高速化
・Tensor Parallelでself attention, MLPの計算を並列化できる
・LayerNormalization, Dropoutの演算もメモリ効率の観点から並列化
・学習を安定させるためにz-lossを利用
・batch skippingとは、gradient clippingを行っていてもなおspikeが生じる場合に、100 step前に戻り、spikeが生じた付近のデータを数百iteration程度スキップすること