lightning mlflow hf
1.0.0
プロセスと情報は、すべてのビジネスの中心にあります。この瞬間の脆弱性と機会は、あなたのビジネスがAIを使用してプロセスを自動化し、そうすることの報酬を享受できるかどうかの問題です。汎用AIであるChatGptは、AIができることに目を向けました。現在重要なのは、AIの力をビジネス上の問題に向け、独自のデータの価値を解き放つことです。このドキュメントでは、その方法をお見せします。
チャットできるAIは欲しくありません。あなたが本当に望んでいるのは、あなたのビジネスを走らせ続ける作業を実行する自動化です。 AIをビジネスプロセスにカスタマイズする実証済みの方法は、データとAIを実行したいアクションでLLMを微調整することです。
このドキュメントで私たちがやろうとしている微調整とその背後にある技術について、具体的に説明しましょう。以下にリストされているのは、広範囲に使用する5つのツールです。
一日の終わりには、このドキュメントから2つのことを取り除く必要があります。
困難で現実世界の問題、機械学習研究者がすでに行っていること、そして私たちが強力でSOTAツールの使用にプッシュすることができた新しいフロンティアについて説明します。クラウド内のGPUでモデルをトレーニングします。また、MLFLOWを使用して実験とパラメーターを整理するために、強力なMLOPSプラクティスを実行する予定です。途中で、このプロジェクトの設計パターンを指摘して、独自の深い学習プロジェクトのコードベースをカスタマイズできるようにします。
問題の背景から始めましょう。
機械学習や質の高いデータセットに適した問題を見つけるための良いプロセスは、ベンチマークでサイトを閲覧することから始めることです。ベンチマークは、モデル開発中の進捗を測定するために使用する機械学習のための問題の難易度のレベルの基準フレームを提供します。十分に確立されたベンチマークを備えた特定のデータセットの1つは、不公平なサービスデータセット（不公平なTOS）です。興味深い問題の声明は次のとおりです。AIを使用して、サービス契約の観点からすべての不公平な条項を見つけます。コンテキストは、不公平な契約に関する欧州消費者法が不公平な条項と異なるタイプの不公平な条項を確立するということです。テキスト分類に最適なものを不公平にしているのは、ヨーロッパの法律で設定されたものに従って手動でラベル付けされていることです。
Chalkidis et al。 （2021）は、8つの異なる機械学習方法を不公平に適用し、75〜83の範囲のマクロF1を取得しました。下の図1では、公開された結果から抜粋しました。
| 方法 | 不公平なトス | |
|---|---|---|
| マイクロF1 | マクロF1 | |
| tfidf-svm | 94.7 | 75.0 |
| バート | 95.6 | 81.3 |
| ロベルタ | 95.2 | 79.2 |
| デバータ | 95.5 | 80.3 |
| 長いフォーマー | 95.5 | 80.9 |
| ビッグバード | 95.7 | 81.3 |
| リーガルバート | 96.0 | 83.0 |
| Caselaw-Bert | 96.0 | 82.3 |
このテーブルから推測できる興味深いことは次のとおりです。
データを見ると、クラスの不均衡が確かに存在します。これは、上記の第1ポイントと2番目のポイントの正当な理由です。
不公平な条項には8つの異なるタイプがあります。その論文の著者は、8つのタイプのマルチラベル分類モデルを開発しましたが、節を公正または不公平として分類するバイナリ分類モデルを構築するだけです。
私たちがそれをどのように行うかをデザインしましょう。
__init__.py 、この例のように、深くサブモジュール化された機能のためにインポートを便利に短縮できるように、モジュールのパブリックAPIを公開します。 from . fine_tune_clsify_head import TransformerModule architectures/__init__.pyは、このような機能がある場所につながるパンくずを覚えておくことなく、 TransformerModuleの外部architecturesをインポートするコードを有効にします。
from architectures import TransformerModuleLightning_mlflowモジュールのルートからプロジェクト構造がどのように見えるかは次のとおりです。
.
├── architectures
│ ├── __init__.py
│ └── fine_tune_clsify_head.py
├── config
│ ├── __init__.py
│ └── train_config.py
├── data
│ ├── __init__.py
│ └── lex_glue.py
└── train.py
重要な問題は、なぜプロジェクトがこのように構成されているのかです。答えは、懸念の分離が3つのサブモジュールと1つのエントリポイントの間に確立されるということです。これらのモジュールのそれぞれを順番に歩きましょう。
architectures ：データを除いて、Pytorchが知っておくべきすべてのことを基本的に指定しますconfig ：すべてのパラメーターを保持し、 train_config.pyおよびinference_config.pyなどに細分化できますdata ：すべてのデータ処理ロジックと設定を保持しますtrain.py ：コントロールの中心点。これは、 architectures 、 config 、 dataを見ることができる唯一のコードです。 mlflow sdkコールはこちらをご覧くださいこの短いイントロが邪魔にならないように、袖をまくり上げて、各モジュールのコードを本当に理解してみましょう。アーキテクチャ/fine_tune_clsify_head.pyから始めましょう。このコードは、すぐ下の図3のように整理されています。
このクラス内の理解する重要な方法は、コンストラクター、ネットワークを通るフォワードパス、メトリック、および手順です。これらのそれぞれについて順番に説明します。コンストラクターから始めましょう。このスニペットは、コードがどのように見えるかです。
ここで本当に重要なのは、コンストラクターが顔を抱きしめることから前処理されたモデルをロードし、パラメーター効率的な微調整（PEFT）を設定することです。 PEFTは、大規模な言語モデルを微調整するための出血エッジの方法であり、量子化、低ランク、アダプターの3つの異なる効率戦略の組み合わせであるQloraの抱き合った顔の実装です。量子化は、単一バイト整数が深い学習における勾配計算に十分な数値精度であるという考えです。低ランクは、マトリックスのランクがベクトル空間の非冗長寸法の数であるという線形代数の概念から来ています。アダプターのチューニングは、多くの層で重みの一部を再補充することにより、ネットワークのヘッドをチューニングする一種の一般化として理解できます。
forward方法を見てみましょう：
ニューラルネットワークにはバックプロップとフィードフォワードの代替が含まれるため、これは前方部分を指定し、注目すべきことは、 forwardの引数はinput_ids 、 attention_mask 、およびlabelです。これらは、ハグする顔のトークナイザーの出力であり、顔とPytorchの稲妻を抱き締めることができます。
次に、 _compute_metricsメソッドを見てみましょう。
ここには注目に値するものがいくつかあります。まず、フォワード関数の評価からロジットがどのように解き放たれ、その後SoftMax関数を介して確率に変換されるかを観察します。これは、バイナリ予測につながります。予測と実際の（ batch["label"] ）を使用して、精度、F1、精度、およびリコールを計算します。
最後に、 training_step 、 validation_step 、およびtest_stepについて話しましょう。
それらはほとんど似ていますが、重要な違いは、 metricsではなくoutputs["loss"] training_stepの返却することです。これは、BackPropが損失を繰り返し最小化しているため、理にかなっています。 training_step 、Pytorch Lightningのトレーニングループの抽象化だけです。
さて、 architecturesが完了しました。config/train_config.pyに飛び込みましょう。
このコードは自明ですが、呼び出すためのいくつかの選択肢があります。 pretrained_model _modelはroberta-baseに設定されており、AutoTokenizerをサポートする抱きしめるフェイスモデル名に変更する場合、すべてが機能するはずです（テスト）。モデルの精度は、 max_lengthとbatch_sizeに最も敏感であることがわかったため、これらは再生する主なハイパーパラメーターであり、どちらも精度と計算負荷の間でトレードオフします。 Azure MLでは、Standard_NC24ADS_A100_V4インスタンスを使用しました。 A100 GPUのVRAMは、これら2つのハイパーパラメーターの制限要因であることが証明されました。私が見つけたのは、256がCUDAにメモリ外のエラーを投げかけない最大のbatch_sizeであるということでした。
条項の大部分がこのトークン制限の下にあったため、128のmax_lengthを決定するのは簡単でした。
最後に、後で見るように、MLFLOWで追跡していた検証F1メトリックがその時点で平らになっていたため、10のmax_epochs試行錯誤によって選択されました。
わかりました、データについて話しましょう。あなたが知る必要があるすべては、 LexGlueDataModuleクラスのデータ/lex_glue.pyであり、これがその構造です。
LexGlueDataModuleにはかなりの数の核心の詳細がありますが、主なアイデアは、 setup方法が顔から直接データを取得することであり、何らかのトークン化が発生しなければならないということです。そのトークン化の詳細は、 _shared_transformメソッドであり、 _preprocessコールバックメソッドの高レベルインターフェイスです。
最後に、すべてのコントロールの中心的なポイントであるTrain.pyの準備ができています。プロジェクトのディレクトリ構造でこのセクションを始めたときのことを覚えていますか？その構造は、重要なメッセージを伝えています。依存関係がディレクトリツリーで下方に解決されることです。言い換えれば、コードは、同じレベル以下の他のコードのみを呼び出すように制限しました。この制限は確かにPythonからのものではありません。それは自己課されています、そしてなぜですか？推測を排除するため。混乱する依存関係チェーンが大きなコードベースで大きな問題であることに疑いの余地はありません。これのすべてが意味するのは、 train.pyが他の各モジュールから機能をインポートし、トレーニングの実行を開始することです。その中心にあるコードの一部を見てみましょう：
Pytorch Lightningトレーナークラスをインスタンス化し、早期停止をオンにし、 precision="bf16-mixed" if torch. cuda.is_available() else "32-true" 。すべてを追跡するようにMLFLOWを構成します。すべてをまとめるために、前述した他の3つのモジュールから機能をインポートします。
from architectures . fine_tune_clsify_head import TransformerModule
from config import TrainConfig
from data import LexGlueDataModuleコア機能は、Pytorch Lightningスーパークラスのサブクラスに包まれているため、それらをインスタンス化します。
model = TransformerModule (
pretrained_model = config . pretrained_model , num_classes = config . num_classes ,
lr = config . lr , )
datamodule = LexGlueDataModule (
pretrained_model = config . pretrained_model , max_length = config . max_length ,
batch_size = config . batch_size , num_workers = config . num_workers ,
debug_mode_sample = config . debug_mode_sample , )そして最後に、 trainerオブジェクトのfitとtest方法を呼び出します。
trainer . fit ( model = model , datamodule = datamodule )
best_model_path = checkpoint_callback . best_model_path
# Evaluate the last and the best models on the test sample.
trainer . test ( model = model , datamodule = datamodule )
trainer . test (
model = model , datamodule = datamodule , ckpt_path = best_model_path , ) test 2回呼び出したので、停止時に最後のモデルとメトリックに応じて最適なモデルの両方をテストするようにしました。これは、Pytorch Lightningに伴う豊富な機能の完璧な例です。
そして、それはコードのウォークスルーをまとめます。それでは、モデルの結果に飛び込みましょう。
これがすべてをまとめるダッシュボードです：
AzureとMLFLOWの密接な統合を活用すると、Azure ML Webコンソールでの容易な消費と視覚化のために、トレーニングの実行からのメトリックが利用可能になりました。 MLFLOWは、単なるメトリックよりもはるかに多くの方法を獲得しましたが、その完全な機能とMLOPのより広範なユースケースは別の日のためです。とりあえず、データの視覚化が私たちに明らかにするストーリーに焦点を当てましょう。
左上チャートから飛び出すことの1つは、トレーニングが検証サンプルの損失を改善することは間違いないことです。さらに、125〜190ステップの間に、曲線が平らになり始めます。これは、さらなるトレーニングが不要である可能性がある潜在的な兆候です。しかし、単調であるため、私たちは単調であるため、オーバーフィッティングはまだ発生していないことがわかります。さらに、曲線は190から210に再び急降下しているので、おそらく別の5つのエポックのために実行する必要がありました。
興味深いことに、右上のプロットも同様の話をします。最も顕著な特性は、精度値がどれだけ高いかであり、ここのユニットはパーセンテージです。データセットが不公平と公正の比率1：9の比率で不均衡なため、行から90％に達していることは理にかなっています。これが、優先メトリックがF1である理由です。これが左下のグラフに表示されるものです。
ここでのF1曲線は、モデルが最初は急速に改善するが、最終的にはリターンが減少するポイントに達する古典的なパターンを示します。 F1曲線によって引き起こされる興味深い質問は、一方が先細りになると提案し、さらに他の人がさらに進むことを提案するときに、損失とF1の間でどのように調整するのかということです。次の理論は、この難問をクラックします。
私たちは、個別のイベントの形で世界を観察しますが、連続的な構造（確率）は数学でより有用であることがよくあります。不公平なTOSデータセットの結果は「公正」または「不公平」でコーディングされており、それらの結果を生成する潜在的な確率分布があります。その潜在的な確率分布は、エントロピー損失関数が機能するものです。したがって、深い学習では、連続メトリックに最適化しますが、連続（潜在）と離散（観測）が互いの近似であるため、モデルが離散メトリックによってどれほど優れているかを判断します。それがアイデアです。
したがって、F1が損失とは異なるストーリーを暗示している場合、ランダム性とクラスの不均衡という2つの説明があります。確かに、それが精度とF1が損失よりもはるかに揮発性である理由です。
ランダム性は、70％の最高の検証F1スコアと78％のテストF1スコア（右下のテーブルから）のギャップの可能性のある説明でもあるようです。
モデル評価メトリックのプレイ分析によるこのプレイにより、このセクションは終了します。次に、このプロジェクトを独自のものにすることを実践してください。以下のインストールガイドは、コードをいじくり回すのに役立ちます。
ステップ1。このリポジトリをローカルワーキングディレクトリにクローンします。
$ git clone https://github.com/zjohn77/lightning-mlflow-hf.git
$ cd lightning-mlflow-hfステップ2。すべてのプロジェクトの依存関係はenvironment.ymlにあり、それのための仮想環境を作成します。以下の指示はconda専用ですが、これらの依存関係にはvenvやpoetryを排除するものはありません。
$ conda env create -n lightning-mlflow-hf -f environment.ymlステップ3。トレーニングの実行の終了時に、 copy_dir_to_abs関数は出力をAzure Blobストレージにコピーします。 Azureが使用しているものでもある場合は、この関数に資格情報を渡すだけで、すべて設定されます。それ以外の場合は、独自のワークフローに置き換えます。
ステップ4。仮想環境では、 train.pyがある場所にIDEに変更するか、実行してください。
$ python train.pyバグがない場合は、抱きしめる顔のメッセージと多くのPytorch Lightningメッセージをコンソールするために印刷されます。数分後、進行状況バーの印刷を開始するはずです。しっかりと座って、それをさせてください。実行が最終的に終了すると、最終モデルの評価メトリックを要約するASCIIテーブルがコンソールに印刷されます。それだけです！
貢献は大歓迎です。コードレビューのためにGitHub Pullリクエストを使用し、ブラックフォーマッタを使用してコードスタイルの一貫性を確保します。
ユニットテストとドキュメントテストも大歓迎です。
ロードマップは進行中です。すぐにチェックしてください。
Ilias Chalkidis、Abhik Jana、Dirk Hartung、Michael Bommarito、Ion Androutsopoulos、Daniel Martin Katz、Nikolaos Aletras。 （2021）。 Lexglue：英語での法的言語理解のためのベンチマークデータセット。 arxivから取得：https：//arxiv.org/abs/2110.00976
