lightning mlflow hf
1.0.0
กระบวนการและข้อมูลเป็นหัวใจสำคัญของทุกธุรกิจ ช่องโหว่และโอกาสของช่วงเวลานี้คือคำถามที่ว่าธุรกิจของคุณสามารถทำให้กระบวนการของคุณโดยอัตโนมัติโดยใช้ AI และเก็บเกี่ยวผลตอบแทนจากการทำเช่นนั้นหรือไม่ CHATGPT ซึ่งเป็นจุดประสงค์ทั่วไปของ AI ได้เปิดตาของเราให้กับสิ่งที่ AI สามารถทำได้ สิ่งที่สำคัญในขณะนี้คือการชี้นำพลังของ AI ไปสู่ปัญหาทางธุรกิจ ของคุณ และปลดล็อคมูลค่าของข้อมูลที่เป็นกรรมสิทธิ์ ของคุณ ในเอกสารนี้ฉันจะแสดงให้คุณเห็นว่า
คุณไม่ต้องการ AI ที่สามารถแชทได้ สิ่งที่คุณต้องการจริงๆคือระบบอัตโนมัติที่ทำงานที่ทำให้ธุรกิจของคุณทำงานได้-พลังผ่านกระบวนการทางธุรกิจที่มีความแม่นยำและมาตราส่วนที่ยอดเยี่ยม วิธีที่พิสูจน์แล้วในการปรับแต่ง AI ให้เข้ากับกระบวนการทางธุรกิจของคุณคือการปรับแต่ง LLM บนข้อมูลของคุณและการกระทำที่คุณต้องการให้ AI ดำเนินการ
พูดคุยกันโดยเฉพาะเกี่ยวกับการปรับแต่งที่ดีที่เราจะทำในเอกสารนี้และเทคโนโลยีที่อยู่เบื้องหลัง รายการด้านล่างเป็นเครื่องมือห้าประการที่เราจะใช้อย่างกว้างขวาง:
ในตอนท้ายของวันคุณควรนำสองสิ่งออกไปจากเอกสารนี้:
ฉันจะอธิบายถึงปัญหาที่ยากลำบากและเป็นจริงให้คุณทราบถึงสิ่งที่นักวิจัยการเรียนรู้ของเครื่องได้ทำไปแล้วและชายแดนใหม่ที่เราสามารถผลักดันให้ใช้เครื่องมือ SOTA ที่ทรงพลัง เรากำลังจะฝึกนางแบบบน GPUs ในคลาวด์ นอกจากนี้เรายังจะนำแนวทางปฏิบัติ MLOPS ที่ทรงพลังมาใช้ในการปฏิบัติ-ใช้ MLFlow เพื่อจัดระเบียบการทดลองและพารามิเตอร์ของเรา และตลอดทางฉันจะชี้ให้เห็นรูปแบบการออกแบบของโครงการนี้เพื่อให้คุณสามารถปรับแต่ง codebase สำหรับโครงการเรียนรู้เชิงลึกของคุณเอง
เริ่มต้นด้วยพื้นหลังปัญหากันเถอะ
กระบวนการที่ดีสำหรับการค้นหาปัญหาที่เหมาะสมสำหรับการเรียนรู้ของเครื่องและชุดข้อมูลที่มีคุณภาพคือการเริ่มต้นด้วยการเรียกดูไซต์ด้วยมาตรฐาน มาตรฐานให้กรอบอ้างอิงสำหรับระดับความยากลำบากของปัญหาสำหรับการเรียนรู้ของเครื่องซึ่งเราใช้ในการวัดความก้าวหน้าของเราในระหว่างการพัฒนาแบบจำลอง ชุดข้อมูลหนึ่งที่มีเกณฑ์มาตรฐานที่จัดตั้งขึ้นเป็นอย่างดีคือชุดข้อมูลที่ไม่เป็นธรรมในการให้บริการ (ไม่เป็นธรรม TOS); นี่คือคำชี้แจงปัญหาที่น่าสนใจสำหรับมัน: ใช้ AI เพื่อค้นหาข้อที่ไม่เป็นธรรมทั้งหมดในแง่ของสัญญาบริการ บริบทคือกฎหมายผู้บริโภคชาวยุโรปเกี่ยวกับสัญญาที่ไม่เป็นธรรมจะกำหนดข้อที่ไม่เป็นธรรมและคำสั่งที่ไม่เป็นธรรมประเภทต่าง ๆ สิ่งที่ทำให้ไม่ยุติธรรมสำหรับการจำแนกประเภทข้อความคือมันได้รับการติดฉลากด้วยตนเองตามสิ่งที่ถูกกำหนดไว้ในกฎหมายยุโรป
Chalkidis และคณะ (2021) ใช้วิธีการเรียนรู้ของเครื่องจักรที่แตกต่างกันแปดวิธีเพื่อไม่เป็นธรรม TOS และได้รับมาโคร F1 ตั้งแต่ 75 ถึง 83 และในรูปที่ 1 ด้านล่างเราตัดตอนมาจากผลลัพธ์ที่เผยแพร่
| วิธี | ไม่เป็นธรรม | |
|---|---|---|
| Micro 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 |
สิ่งที่น่าสนใจที่เราสามารถอนุมานได้จากตารางนี้คือ:
เมื่อดูที่ข้อมูลความไม่สมดุลของชั้นเรียนมีอยู่อย่างแน่นอนซึ่งเป็นเหตุผลที่ดีสำหรับจุดแรกและจุดที่สองข้างต้น
ข้อที่ไม่เป็นธรรมมีแปดประเภทที่แตกต่างกัน ผู้เขียนบทความนั้นพัฒนารูปแบบการจำแนกประเภทหลายฉลากสำหรับแปดประเภท แต่เราจะสร้างแบบจำลองการจำแนกประเภทไบนารีที่จัดประเภทประโยคให้ยุติธรรมหรือไม่ยุติธรรม
มาออกแบบกันเถอะว่าเราจะทำอย่างไร
__init__.py เปิดเผย API สาธารณะของโมดูลที่อยู่ในเพื่อให้เราสามารถลดการนำเข้าได้อย่างสะดวก from . fine_tune_clsify_head import TransformerModule การนำเข้าด้านบนใน architectures/__init__.py ช่วยให้รหัสภายนอก architectures สามารถนำเข้า TransformerModule โดยไม่ต้องจำ breadcrumbs ที่นำไปสู่ตำแหน่งที่ฟังก์ชั่นนี้อยู่เช่นนี้:
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 submodules และ 1 ententpoint ลองเดินผ่านโมดูลเหล่านี้แต่ละอัน:
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 ซึ่งเป็นการรวมกันของกลยุทธ์ประสิทธิภาพที่แตกต่างกันสามประการ ได้แก่ ปริมาณการจัดอันดับต่ำและอะแดปเตอร์ Quantization เป็นความคิดที่ว่าจำนวนเต็มไบต์เดียวนั้นมีความแม่นยำเชิงตัวเลขที่เพียงพอสำหรับการคำนวณการไล่ระดับสีในการเรียนรู้อย่างลึกซึ้ง อันดับต่ำมาจากแนวคิดพีชคณิตเชิงเส้นว่าอันดับของเมทริกซ์คือจำนวนขนาดที่ไม่ซ้ำซ้อนของพื้นที่เวกเตอร์ การปรับจูนอะแดปเตอร์สามารถเข้าใจได้ว่าเป็นลักษณะทั่วไปของการปรับแต่งหัวของเครือข่ายโดย refitting ส่วนหนึ่งของน้ำหนักในหลายชั้น
มาดูวิธี forward :
ในการฝึกอบรมเครือข่ายประสาทเกี่ยวข้องกับการสลับระหว่าง backprop และ feed ไปข้างหน้าสิ่งนี้ระบุส่วนไปข้างหน้าและสิ่งที่น่าสังเกตคือข้อโต้แย้งของ forward คือ: input_ids , attention_mask และ label นี่คือผลลัพธ์ของการกอดใบหน้า tokenizer และพวกเขาช่วยให้เราสามารถผูกใบหน้ากอดและฟ้าผ่า pytorch เข้าด้วยกัน
ถัดไปลองดูที่วิธี _compute_metrics :
มีบางสิ่งที่น่าสังเกตที่นี่ ขั้นแรกให้สังเกตว่า logits ถูกแกะออกจากการประเมินฟังก์ชั่นไปข้างหน้าอย่างไรจากนั้นแปลงเป็นความน่าจะเป็นผ่านฟังก์ชั่น SoftMax ในทางกลับกันสิ่งนี้นำไปสู่การทำนายไบนารี เราใช้การทำนายและชุดจริง ( batch["label"] ) เพื่อคำนวณความแม่นยำ F1 ความแม่นยำและการเรียกคืน
สุดท้ายเรามาพูดถึง training_step , validation_step และ test_step
พวกเขามีลักษณะเกือบเหมือนกันโดยมีความแตกต่างที่สำคัญคือ training_step กลับ outputs["loss"] แทนที่จะเป็น metrics สิ่งนี้สมเหตุสมผลเพราะ backprop เป็นการลดการสูญเสียซ้ำ ๆ training_step เป็นเพียงนามธรรมของ Pytorch Lightning ในการฝึกอบรม
ตกลงตอนนี้เราทำ architectures เสร็จแล้วลองดำน้ำใน config/train_config.py ซึ่งดูเหมือนรูปที่ 7 ด้านล่าง
รหัสนี้อธิบายตนเองได้ แต่มีตัวเลือกบางอย่างให้โทรออก pretrained_model ถูกตั้งค่าเป็น roberta-base และถ้าเราจะเปลี่ยนเป็นชื่อโมเดลใบหน้ากอดใด ๆ ที่รองรับ autoTokenizer ทุกอย่างควรทำงาน (ทดสอบ) ความแม่นยำของโมเดลพบว่ามีความอ่อนไหวต่อ max_length และ batch_size มากที่สุดดังนั้นนี่คือพารามิเตอร์หลักที่จะเล่นด้วยและพวกเขาทั้งคู่แลกเปลี่ยนระหว่างความแม่นยำและภาระการคำนวณ บน Azure ML ฉันใช้อินสแตนซ์ Standard_NC24ADS_A100_V4 VRAM บน A100 GPU พิสูจน์แล้วว่าเป็นปัจจัย จำกัด สำหรับพารามิเตอร์ไฮเปอร์พารามิเตอร์ทั้งสองนี้ สิ่งที่ฉันพบคือ 256 เป็น batch_size ที่ใหญ่ที่สุดที่จะไม่ทำให้ Cuda โยนข้อผิดพลาดนอกหน่วยความจำ
การกำหนด max_length ที่ 128 นั้นง่ายกว่าเนื่องจากประโยคส่วนใหญ่อยู่ภายใต้ขีด จำกัด โทเค็นนี้
ในที่สุดอย่างที่เราจะเห็นในภายหลัง max_epochs จาก 10 ได้รับการคัดเลือกจากการทดลองและข้อผิดพลาดเนื่องจากการตรวจสอบ F1 Metric ที่เราติดตามใน MLFlow นั้นแบนราบไปตามจุดนั้น
ตกลงมาพูดถึงข้อมูลกันเถอะ ทุกสิ่งที่คุณจำเป็นต้องรู้อยู่ในคลาส LexGlueDataModule ใน data/lex_glue.py และนี่คือโครงสร้างของมัน:
มีรายละเอียดเล็กน้อยใน 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ฟังก์ชั่นหลักถูกห่อหุ้มด้วย subclasses ของ superclasses 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 , ) และในที่สุดเราก็เรียกใช้วิธี fit และ test ของวัตถุ trainer :
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 จับวิธีมากกว่าตัวชี้วัด แต่จะลึกลงไปในฟังก์ชั่นเต็มรูปแบบและกรณีการใช้งานที่กว้างขึ้นของ MLOPS เป็นอีกวันหนึ่ง สำหรับตอนนี้เรามามุ่งเน้นไปที่เรื่องราวที่การสร้างภาพข้อมูลของเราเผยให้เราเห็น
สิ่งหนึ่งที่โผล่ออกมาจากแผนภูมิซ้ายซ้ายคือการฝึกอบรมไม่ต้องสงสัยเลยว่าการสูญเสียการตรวจสอบความถูกต้อง นอกจากนี้ระหว่าง 125 ถึง 190 ขั้นตอนเส้นโค้งเริ่มแบนซึ่งเป็นข้อบ่งชี้ที่เป็นไปได้ว่าการฝึกอบรมเพิ่มเติมอาจไม่จำเป็น แต่การเป็นโมโนโทนิกเราเห็นว่าการ overfitting ยังไม่เกิดขึ้นและยิ่งไปกว่านั้นเส้นโค้งก็ลาดชันอีกครั้งจาก 190 ถึง 210 ดังนั้นบางทีเราควรปล่อยให้มันวิ่งไปอีก 5 ยุค
พล็อตด้านบนขวาที่น่าสนใจบอกเล่าเรื่องราวที่คล้ายกัน ลักษณะที่โดดเด่นที่สุดคือค่าความแม่นยำสูงเพียงใดและหน่วยที่นี่เป็นเปอร์เซ็นต์ ว่าบรรทัดกำลังกดปุ่ม 90% จาก Get-Go ทำให้รู้สึกเพราะชุดข้อมูลไม่สมดุลที่อัตราส่วน 1: 9 ระหว่างไม่ยุติธรรมและยุติธรรม มันเป็นเหตุผลว่าทำไมตัวชี้วัดที่ต้องการคือ F1 ซึ่งเป็นสิ่งที่เราแสดงในกราฟด้านล่างซ้าย
เส้นโค้ง F1 ที่นี่แสดงรูปแบบคลาสสิกที่แบบจำลองปรับปรุงอย่างรวดเร็วในตอนแรก แต่ในที่สุดก็มาถึงจุดที่ลดลง คำถามที่น่าสนใจที่เกิดขึ้นจากเส้นโค้ง F1 คือเราจะกระทบยอดระหว่างการสูญเสียและ F1 ได้อย่างไรเมื่อมีคนแนะนำเรียวขณะที่คนอื่น ๆ ออกจากห้องเพื่อไปต่อไป? ทฤษฎีต่อไปนี้จะแตกปริศนานี้
เราสังเกตโลกในรูปแบบของเหตุการณ์ที่ไม่ต่อเนื่อง แต่โครงสร้างอย่างต่อเนื่อง (เช่นความน่าจะเป็น) มักจะมีประโยชน์มากกว่าในวิชาคณิตศาสตร์ ผลลัพธ์ในชุดข้อมูลที่ไม่เป็นธรรม TOS คือรหัส "ยุติธรรม" หรือ "ไม่ยุติธรรม" และมีการกระจายความน่าจะเป็นแฝงที่สร้างผลลัพธ์เหล่านั้น การกระจายความน่าจะเป็นแฝงนั้นคือสิ่งที่ฟังก์ชั่นการสูญเสียข้ามการเข้าร่วมสามารถทำงานได้ด้วย ดังนั้นในการเรียนรู้อย่างลึกซึ้งเราปรับให้เหมาะสมสำหรับการวัดอย่างต่อเนื่อง แต่เราตัดสินว่าแบบจำลองของเราดีเพียงใดโดยการวัดที่ไม่ต่อเนื่องเพราะอย่างต่อเนื่อง (แฝง) และไม่ต่อเนื่อง (สังเกต) เป็นการประมาณของกันและกัน นั่นคือความคิด
ดังนั้นเมื่อ F1 บอกใบ้ในเรื่องที่แตกต่างจากการสูญเสียมีเพียงสองคำอธิบายที่เป็นไปได้: การสุ่มและความไม่สมดุลของชั้นเรียน นั่นเป็นเหตุผลว่าทำไมความแม่นยำและ F1 จึงมีความผันผวนมากกว่าการสูญเสีย
การสุ่มดูเหมือนจะเป็นคำอธิบายที่เป็นไปได้สำหรับช่องว่างระหว่างคะแนนการตรวจสอบ F1 ที่ดีที่สุดที่ 70% และคะแนนการทดสอบ 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 Lightning จำนวนมาก หลังจากนั้นไม่กี่นาทีก็ควรเริ่มพิมพ์แถบความคืบหน้า นั่งแน่นและปล่อยให้มันทำสิ่งนั้น เมื่อการวิ่งเสร็จสิ้นในที่สุดตาราง ASCII จะสรุปการวัดการประเมินผลสำหรับรุ่นสุดท้ายจะถูกพิมพ์ลงในคอนโซล นั่นคือทั้งหมดที่มีอยู่!
ยินดีต้อนรับการบริจาคใด ๆ เราใช้คำขอดึง GitHub สำหรับการตรวจสอบโค้ดและเราใช้ชุดสีดำเพื่อให้แน่ใจว่าสไตล์ความสอดคล้องของรหัส
การทดสอบหน่วยและการทดสอบ 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
