lightning mlflow hf
1.0.0
流程和信息都是每個業務的核心。這一刻的脆弱性和機會是您的業務是否可以使用AI自動化流程，並獲得這樣做的回報。通用AI Chatgpt睜開了眼睛，對AI可以做什麼。現在重要的是將AI的力量引向您的業務問題並解鎖您的專有數據的價值。在本文檔中，我將向您展示如何。
您不想要可以聊天的AI；您真正想要的是執行工作的自動化，從而使您的業務運行 - 通過業務流程的準確性和規模來推動。將AI自定義為業務流程的驗證方法是在數據和希望AI執行的操作上微調LLM。
讓我們專門討論我們將在本文檔及其背後的技術中進行的微調。下面列出的是我們將廣泛使用的五個工具：
歸根結底，您應該從本文檔中取出兩件事：
我將向您描述一個棘手的現實問題，機器學習研究人員已經做了什麼以及我們能夠推動使用功能強大的SOTA工具的新邊界。我們將在雲中的GPU上訓練模型。我們還將將強大的MLOP實踐付諸實踐 - 使用MLFlow來組織我們的實驗和參數。在此過程中，我將指出該項目的設計模式，以便您可以為自己的深度學習項目自定義代碼庫。
讓我們從問題背景開始。
尋找適合機器學習和高質量數據集問題的好過程是從瀏覽基準測試的站點開始。基準為機器學習難度的水平提供了參考框架，我們用來衡量模型開發過程中的進度。一個具有良好基準的特定數據集是服務數據集的不公平條款（不公平的TOS）；這是一個有趣的問題聲明：使用AI在服務合同方面找到所有不公平條款。背景是，歐洲消費者關於不公平合同的法律確定了不公平的條款和不同類型的不公平條款。不公平的TOS非常適合文本分類的原因是，它是按照歐洲法律所設定的手動標記的。
Chalkidis等。 （2021）將八種不同的機器學習方法應用於不公平的TOS，並獲得了從75到83的宏F1，在下面的圖1中，我們從它們發布的結果中摘錄。
| 方法 | 不公平的 | |
|---|---|---|
| 微F1 | 宏F1 | |
| TFIDF-SVM | 94.7 | 75.0 |
| 伯特 | 95.6 | 81.3 |
| 羅伯塔 | 95.2 | 79.2 |
| Deberta | 95.5 | 80.3 |
| longformer | 95.5 | 80.9 |
| 大鳥 | 95.7 | 81.3 |
| 法律 - 伯特 | 96.0 | 83.0 |
| Caselaw-Bert | 96.0 | 82.3 |
我們可以從此表中推斷出的有趣的事情是：
查看數據，班級不平衡當然是存在的，這是上述第一點和第二點的一個很好的理由。
有八種不同類型的不公平條款。該論文的作者為八種類型開發了多標籤分類模型，但是我們只是要構建一個將子句歸類為公平或不公平的二進制分類模型。
讓我們設計一下我們將如何做。
__init__.py揭示了該模塊的公共API，因此我們可以方便地縮短以下示例的深層插入功能的導入： from . fine_tune_clsify_head import TransformerModule architectures/__init__.py使代碼可以外部architectures導入TransformerModule ，而不必記住麵包屑，導致此功能所在的位置，例如：
from architectures import TransformerModule這是項目結構從Lightning_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是微調大語言模型的出血邊緣方式，並且是Qlora的擁抱面孔實現，這是三種不同效率策略的組合：量化，低級和適配器。量化是單字節整數具有足夠的數值精度，可以在深度學習中進行梯度計算。低等級來自線性代數概念，即矩陣的等級是向量空間的非冗余維度的數量。適配器調整可以理解為通過在許多層中重新裝飾一部分權重來調整網絡頭的一種概括。
讓我們看一下forward方法：
當訓練神經網絡涉及向後求和饋送之間的交替時，這指定了前部部分，值得注意的是， forward的論點是： input_ids ， attention_mask和label 。這些是擁抱臉令牌的輸出，它們使我們能夠將擁抱的臉和Pytorch Lightning綁在一起。
接下來，讓我們看一下_compute_metrics方法：
這裡有一些值得注意的事情。首先，觀察如何從前向功能評估中解開邏輯，然後通過軟磁函數轉換為概率。反過來，這導致了二進制預測。我們使用預測和實際（ batch["label"] ）來計算準確性，F1，精度和召回率。
最後，讓我們談談training_step ， validation_step和test_step 。
它們看起來幾乎相似，重要的區別是training_step返回outputs["loss"]而不是metrics 。這是有道理的，因為反向推銷可以迭代地降低損失。 training_step只是Pytorch Lightning的訓練循環的抽象。
好的，現在我們已經完成了architectures ，讓我們深入研究config/train_config.py，它看起來像下面的圖7。
該代碼是不言自明的，但是有一些選擇要召集。 pretrained_model _model設置為roberta-base ，如果我們將其更改為支持自動傳動器的任何擁抱面部模型名稱，則一切都應該可以工作（測試）。發現模型精度對max_length和batch_size最敏感，因此這些是要使用的主要超參數，並且在精度和計算負載之間均進行了折衷。在Azure ML上，我使用了standard_nc24ads_a100_v4實例。 A100 GPU上的VRAM被證明是這兩個超參數的限制因素。我發現256是最大的batch_size ，不會導致Cuda丟下不可存儲的錯誤。
由於絕大多數子句在該令牌限制之下，因此確定max_length為128。
最後，正如我們稍後將看到的那樣，通過反複試驗選擇了10的max_epochs作為驗證F1度量，我們在MLFlow中跟踪的驗證f1度量已在此點之前變平。
好的，讓我們談談數據。您需要知道的所有內容都在數據/lex_glue.py中的LexGlueDataModule類中，這是其結構：
LexGlueDataModule中有很多細節的細節，但是主要思想是， setup方法直接從擁抱面中獲取數據，然後必鬚髮生某種令牌化。該令牌化的詳細信息在_shared_transform方法中，這只是_preprocess回調方法的高級接口。
最後，我們已經準備好訓練Train.py，這是一切控制的中心點。還記得我們從項目目錄結構開始本節時嗎？該結構傳達了一個重要的消息：依賴關係在目錄樹中向下解析。換句話說，我們將代碼限制為僅調用其他級別或更低級別的代碼。這種限制當然不是來自Python。這是自我強加的，為什麼？消除猜測。毫無疑問，令人困惑的依賴鍊是大型代碼庫中的主要問題。所有這些都意味著train.py將從每個其他模塊中導入功能，然後將訓練運行設置為運動。讓我們看一下它核心的代碼：
我們正在實例化Pytorch Lightning Trainer課程，提前停止，並根據機器設置精度，我們通過precision="bf16-mixed" if torch. cuda.is_available() else "32-true" 。我們配置MLFLOW以跟踪所有內容。為了將所有內容整合在一起，我們從我們前面描述的其他三個模塊中導入功能：
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 ，以便根據我們的指標測試最後一個模型和最佳模型。這是Pytorch Lightning帶來的豐富功能的完美示例。
這總結了代碼演練。現在，讓我們研究模型結果。
這是一個儀表板，將所有內容融合在一起：
利用Azure和MLFlow之間的緊密整合，我們的培訓運行中的指標已被提供在Azure ML Web控制台中易於消費和可視化。 MLFlow捕獲的方式不僅僅是指標，但是更深入地介紹了其全部功能和更廣泛的MLOP用例，這是另一天。就目前而言，讓我們關注我們的數據可視化向我們揭示的故事。
從左上圖中彈出的一件事是，訓練毫無疑問改善了驗證樣本的損失。此外，在125到190步之間，曲線開始變平，這可能是不必要的進一步訓練的潛在跡象。但是，以單調的態度，我們看到尚未發生過度擬合，而且，此外，曲線再次從190到210，所以也許我們應該讓它再進行5個時代。
有趣的是，右上角的情節講述了類似的故事。最值得注意的特徵是準確性值的高度，而這裡的單元是百分比。從一開始就達到90％的線是有意義的，因為數據集在不公平和公平之間的比率下不平衡。這就是為什麼首選度量是F1的原因，這就是我們在左下圖中顯示的內容。
這裡的F1曲線展示了經典模式，其中模型起初會迅速改善，但最終達到了回報率的減少。 F1曲線引起的一個有趣的問題是，當一個人建議逐漸變細而另一個人留出進一步的空間時，我們如何調和損失和F1之間？以下理論將破壞這個難題。
我們以離散事件的形式觀察世界，但是連續構造（例如概率）通常在數學中更有用。不公平的數據集中的結果被編碼為“公平”或“不公平”，並且有一個潛在的概率分佈生成這些結果。該潛在概率分佈是交叉滲透損失函數可以使用的。因此，在深度學習中，我們對連續度量進行了優化，但是我們通過離散度量來判斷我們的模型的良好程度，因為連續（潛在）和離散（觀察到的）是彼此的近似值。那就是主意。
因此，當F1暗示一個與損失不同的故事時，只有兩個可能的解釋：隨機性和階級失衡。的確，這就是為什麼準確性和F1比損失更易變的原因。
隨機性似乎也可能是對最佳驗證F1分數的差距的可能性解釋，而測試F1得分為78％（從右下表）。
通過對模型評估指標的播放分析將此部分結束。接下來，動手實踐自己的項目。下面的安裝指南將幫助您開始修補代碼。
步驟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。在您的虛擬環境中，您將更改或將IDE指向train.py所在的位置：
$ python train.py如果沒有錯誤，它將打印以安慰一些擁抱的面部消息和許多Pytorch閃電消息。幾分鐘後，它應該開始打印進度欄。坐著，讓它做事。當運行最終完成時，將將最終模型評估指標的ASCII表打印到控制台上。這就是一切！
歡迎任何貢獻。我們使用GitHub拉動請求進行代碼審核，並使用Black Formatter來確保代碼樣式的一致性。
單位測試和DOC測試也非常歡迎。
路線圖正在進行中。盡快回來。
Ilias Chalkidis，Abhik Jana，Dirk Hartung，Michael Bommarito，Ion Androutsopoulos，Daniel Martin Katz，Nikolaos Aletras。 （2021）。 Lexglue：用英語理解法律語言理解的基準數據集。取自Arxiv：https：//arxiv.org/abs/2110.00976
