lightning mlflow hf
1.0.0
프로세스와 정보는 모든 비즈니스의 핵심입니다. 이 순간의 취약성과 기회는 비즈니스가 AI를 사용하여 프로세스를 자동화 할 수 있는지에 대한 문제이며, 그렇게하는 보상을 거두는 것입니다. 범용 AI 인 Chatgpt는 AI가 할 수있는 일에 우리의 시선을 열었습니다. 이제 중요한 것은 AI의 힘을 비즈니스 문제로 지시하고 독점 데이터의 가치를 잠금 해제하는 것입니다. 이 문서에서는 방법을 보여 드리겠습니다.
당신은 채팅 할 수있는 AI를 원하지 않습니다. 당신이 정말로 원하는 것은 비즈니스 프로세스를 통해 비즈니스 프로세스를 통해 비즈니스를 계속 운영하는 작업을 수행하는 자동화입니다. 비즈니스 프로세스에 AI를 사용자 정의하는 입증 된 방법은 데이터와 AI가 수행하려는 조치에 대해 LLM을 미세 조정하는 것입니다.
이 문서에서 우리가 할 미세 조정과 그 뒤에있는 기술에 대해 구체적으로 이야기합시다. 다음은 광범위하게 사용할 5 가지 도구입니다.
하루가 끝나면이 문서에서 두 가지를 제거해야합니다.
나는 당신에게 어렵고 실제적인 문제, 기계 학습 연구자들이 이미 한 일, 그리고 우리가 강력한 SOTA 도구를 사용하여 추진할 수 있었던 새로운 국경을 설명 할 것입니다. 우리는 클라우드에서 GPU에 대한 모델을 훈련시킬 것입니다. 우리는 또한 우리의 실험과 매개 변수를 구성하기 위해 MLFLOW를 사용하는 강력한 MLOPS 관행을 행동에 넣을 것입니다. 그리고 그 과정에서, 나는이 프로젝트의 디자인 패턴을 지적하여 자신의 딥 러닝 프로젝트에 대한 코드베이스를 사용자 정의 할 수 있도록하겠습니다.
문제 배경부터 시작하겠습니다.
기계 학습 및 품질 데이터 세트에 적합한 문제를 찾는 좋은 프로세스는 벤치 마크가있는 사이트를 탐색하는 것입니다. 벤치 마크는 기계 학습의 문제의 어려움 수준에 대한 참조 프레임을 제공하며, 이는 모델 개발 중 진행 상황을 측정하는 데 사용합니다. 벤치 마크가 잘 확정 된 특정 데이터 세트 중 하나는 불공정 서비스 이용 약관 데이터 세트 (불공정)입니다. 흥미로운 문제 설명은 다음과 같습니다. 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 |
| Longformer | 95.5 | 80.9 |
| 빅 버드 | 95.7 | 81.3 |
| 합법적 인 베트 | 96.0 | 83.0 |
| Caselaw-Bert | 96.0 | 82.3 |
이 테이블에서 우리가 추론 할 수있는 흥미로운 것은 다음과 같습니다.
데이터를 살펴보면 클래스 불균형이 확실히 존재하며, 이는 위의 첫 번째와 두 번째 지점의 좋은 이유입니다.
불공정 한 조항에는 8 가지 유형이 있습니다. 이 논문의 저자는 8 가지 유형에 대한 다중 표지 분류 모델을 개발했지만, 우리는 단순히 절을 공정하거나 불공평 한 절을 분류하는 이진 분류 모델을 구축 할 것입니다.
우리가 어떻게 할 것인지 디자인합시다.
__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 개의 EntryPoint 사이에 우려의 분리가 확립된다는 것입니다. 이러한 모듈 각각을 차례로 걸어 봅시다.
architectures : 데이터를 제외하고 Pytorch가 알아야 할 모든 것을 본질적으로 지정합니다.config : 모든 매개 변수를 보유하고 train_config.py 및 inference_config.py 및 기타로 세분화 할 수 있습니다.data : 모든 데이터 처리 로직 및 설정을 보유합니다.train.py : 중심 통제 지점; 이것은 architectures , config 및 data 볼 수있는 유일한 코드입니다. mlflow sdk 통화는 여기로 이동합니다이 간단한 소개가 끝나면 슬리브를 굴려서 각 모듈의 코드를 실제로 이해하려고 노력해 봅시다. 아키텍처/fine_tune_clsify_head.py부터 시작하겠습니다. 이 코드는 바로 아래 그림 3과 같이 구성됩니다.
이 클래스 내에서 이해할 주요 방법은 생성자, 전방 통과 네트워크, 메트릭 및 단계라는 것이 분명합니다. 우리는 이들 각각에 대해 차례로 논의 할 것입니다. 생성자부터 시작하겠습니다. 이 스 니펫은 코드의 모습입니다.
여기서 정말로 중요한 것은 생성자가 포옹 얼굴에서 사전 각인 모델을로드하고 PEFT (Parameter Efficial Fine Tuning)를 설정한다는 것입니다. PEFT는 대형 언어 모델을 미세 조정하는 출혈 가장자리 방법이며, 양자화, 낮은 순위 및 어댑터의 세 가지 효율 전략의 조합 인 Qlora의 포옹 얼굴 구현입니다. 양자화는 단일 바이트 정수가 딥 러닝에서 그라디언트 계산에 충분한 수치 정밀도라는 아이디어입니다. 낮은 순위는 선형 대수 개념에서 매트릭스의 순위가 벡터 공간의 중복되지 않은 치수의 수라는 것입니다. 어댑터 튜닝은 많은 레이어에서 가중치의 일부를 다시 설정하여 네트워크 헤드를 조정하는 일종의 일반화로 이해 될 수 있습니다.
forward 방법을 살펴 보겠습니다.
신경망을 훈련시키는 것은 백 프롭과 피드 포워드 사이의 교대를 포함하기 때문에, 이것은 전방 부분을 지정하고, 주목할만한 것은 forward 의 인수가 다음과 같습니다. input_ids , attention_mask 및 label 입니다. 이것들은 포옹 페이스 토큰 화기의 출력이며, 우리는 포옹 얼굴과 파이토치 번개를 함께 묶을 수 있습니다.
다음으로 _compute_metrics 메소드를 살펴 보겠습니다.
여기에 주목할만한 몇 가지가 있습니다. 먼저, 로그가 전방 함수 평가에서 포장을 풀고 SoftMax 함수를 통해 확률로 변환되는 방법을 관찰하십시오. 이것은 결국 이진 예측으로 이어집니다. 우리는 예측과 실제 ( batch["label"] )를 사용하여 정확도, F1, 정밀도 및 리콜을 계산합니다.
마지막으로 training_step , validation_step 및 test_step 에 대해 이야기 해 봅시다.
그들은 거의 비슷해 보이며, 중요한 차이는 training_step metrics 대신 outputs["loss"] . 역전이 반복적으로 손실을 최소화하기 때문에 이것은 의미가 있습니다. training_step 은 Pytorch Lightning의 교육 루프 추상화입니다.
자, 이제 우리는 architectures 완료했습니다. 아래 그림 7과 같은 구성/train_config.py로 뛰어 들자.
이 코드는 자체 설명이지만 호출 할 몇 가지 선택이 있습니다. pretrained_model 은 roberta-base 로 설정되었으며 Autotokenizer를 지원하는 포옹 페이스 모델 이름으로 변경하면 모든 것이 여전히 작동해야합니다 (테스트). 모델 정확도는 max_length 및 batch_size 에 가장 민감한 것으로 밝혀 졌으므로 이들은 주변과 함께하는 주요 하이퍼 파라미터이며 정확도와 계산 부하 사이의 트레이드 오프입니다. Azure ML에서는 Standard_NC24ADS_A100_V4 인스턴스를 사용했습니다. A100 GPU의 VRAM은이 두 하이퍼 파라 미터의 제한 요인으로 입증되었습니다. 내가 찾은 것은 256이 Cuda가 메모리가없는 오류를 던지지 않는 가장 큰 batch_size 라는 것입니다.
max_length 128의 결정이 더 쉬웠습니다. 대부분의 조항 이이 토큰 한도에 따라 있었기 때문입니다.
마지막으로, 나중에 볼 수 있듯이, 10의 max_epochs 는 MLFlow에서 추적 한 검증 F1 메트릭으로 인해 시행 착오에 의해 선택되었습니다.
자, 데이터에 대해 이야기합시다. 당신이 알아야 할 모든 것은 data/lex_glue.py의 LexGlueDataModule 클래스에 있으며, 이것이 구조입니다.
LexGlueDataModule 에는 꽤 많은 세부 사항이 있지만, 주요 아이디어는 setup 메소드가 데이터를 껴안는 얼굴로부터 직접 가져온 다음 어떤 종류의 토큰 화가 발생한다는 것입니다. 해당 토큰 화의 세부 사항은 _shared_transform 메소드에 있으며 _preprocess 콜백 메소드의 높은 레벨 인터페이스입니다.
마지막으로, 우리는 모든 것에 대한 중심 통제 지점 인 Train.py를 준비했습니다. 프로젝트의 디렉토리 구조 로이 섹션을 시작했을 때를 기억하십니까? 이 구조는 중요한 메시지를 전달하고 있습니다. 의존성은 디렉토리 트리에서 아래쪽으로 해결됩니다. 다시 말해, 코드는 동일한 레벨 이하의 다른 코드 만 호출하도록 제한했습니다. 이 제한은 확실히 파이썬에서 나오지 않습니다. 그것은 자체적으로 부과되는데 왜? 추측을 제거합니다. 혼란스러운 의존성 체인이 대형 코드베이스의 주요 문제라는 데는 의문의 여지가 없습니다. 이 모든 의미는 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 Superclass의 서브 클래스에 싸여 있으므로 우리는이를 인스턴스화합니다.
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 Console에서 쉽게 소비하고 시각화 할 수 있도록 교육 실행의 메트릭이 제공되었습니다. MLFLOW는 단순한 메트릭 이상의 길을 캡처했지만 전체 기능에 더 깊이 들어가고 MLOPS의 광범위한 사용 사례는 또 다른 날입니다. 지금은 데이터 시각화가 우리에게 드러난 이야기에 초점을 맞추겠습니다.
왼쪽 상단 차트에서 튀어 나오는 한 가지는 훈련이 검증 샘플에서 손실을 향상 시켰다는 것입니다. 또한, 125 ~ 190 단계 사이에서 곡선이 평평 해지기 시작하며, 추가 훈련이 불필요 할 수 있다는 잠재적 표시입니다. 그러나 단조로운 일이기 때문에 우리는 오버 피트팅이 아직 발생하지 않았으며, 그 곡선이 190에서 210까지 다시 가파 웠으므로 아마도 다른 5 개의 시대를 위해 실행해야 할 것입니다.
상단 오른쪽 줄거리는 흥미롭게도 비슷한 이야기를 들려줍니다. 가장 주목할만한 특성은 정확도 값이 얼마나 높고, 여기의 단위는 백분율입니다. 데이터 세트가 불공정과 공정 사이의 1 : 9 비율로 불균형이기 때문에 라인이 get-go에서 90%에 도달한다는 것은 의미가 있습니다. 선호하는 메트릭이 F1 인 이유입니다. 이는 왼쪽 하단 그래프에 표시됩니다.
여기서 F1 곡선은 모델이 처음에는 빠르게 향상되지만 결국 수익률 감소 지점에 도달하는 고전적인 패턴을 나타냅니다. F1 곡선이 유발하는 흥미로운 질문은 손실과 F1 사이를 어떻게 조정 하는가, 다른 하나는 더 나아갈 공간을 떠나는가? 다음과 같은 이론은이 수수께끼를 깨뜨릴 것입니다.
우리는 세상을 개별 사건의 형태로 관찰하지만 지속적인 구성 (예 : 확률)은 종종 수학에서 더 유용합니다. 불공평 한 데이터 세트의 결과는 "공정"또는 "불공평"으로 코딩되며, 이러한 결과를 생성하는 잠재 확률 분포가 있습니다. 잠복 확률 분포는 교차 엔트로피 손실 함수와 함께 작동 할 수있는 것입니다. 따라서 딥 러닝에서는 연속 메트릭을 최적화하지만 연속 (잠재적)과 개별 (관찰)이 서로 근사치이기 때문에 모델이 개별 메트릭에 의해 얼마나 좋은지 판단합니다. 그것이 아이디어입니다.
따라서 F1이 손실과 다른 이야기를 암시 할 때, 무작위성과 클래스 불균형이라는 두 가지 가능한 설명 만 있습니다. 실제로, 정확도와 F1이 손실보다 훨씬 더 변동성이있는 이유입니다.
무작위성은 또한 70%의 최상의 검증 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 Storage에 복사합니다. Azure가 사용하는 것인 경우 자격 증명을이 기능에 전달하면 모두 설정됩니다. 그렇지 않으면 자신의 워크 플로로 교체하십시오.
4 단계. 가상 환경에서는 train.py 있는 곳으로 IDE를 변경하거나 가리킬 수 있습니다.
$ python train.py버그가 없으면 포옹 페이스 메시지와 많은 Pytorch Lightning 메시지를 콘솔로 인쇄합니다. 몇 분 후에 진행률 표시 줄을 인쇄하기 시작해야합니다. 꽉 앉아서 그 일을하도록하십시오. 실행이 마침내 끝나면 최종 모델의 평가 메트릭을 요약 한 ASCII 테이블이 콘솔에 인쇄됩니다. 그게 전부입니다!
모든 기여를 환영합니다. 우리는 코드 검토를위한 github pull 요청을 사용하고 블랙 포맷터를 사용하여 코드 스타일 일관성을 보장합니다.
단위 테스트 및 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
