Tự động hóa quy trình huấn luyện lại
Biến một deployment thành quy trình lặp lại được: runbook, cổng thăng cấp bằng script, phát hành tự động có rollback và rà soát hằng tuần.
Deployment đầu tiên là một dự án; mọi deployment sau đó đều là một quy trình. Các nhóm viết script cho quy trình có thể huấn luyện lại chỉ trong một buổi chiều mỗi khi cảnh báo tập holdout kích hoạt; các nhóm không làm vậy phải dựng lại quy trình từ trí nhớ trong lúc áp lực cao và phát hành các phiên bản hồi quy. Bài học này thực hiện trọn quy trình một lần trên model viên thuốc — tinh chỉnh, kiểm tra cổng và phát hành — đồng thời viết runbook để những lần sau trở thành công việc thường lệ.
Thực hành
Quy trình lặp, với người phụ trách cho từng bước#
Bạn có sẵn thông tin về nguồn gốc nếu đã học các bài trước: thẻ Run Information của model ghi tên model cha và phiên bản dataset được ghim; tab Models của dataset liệt kê mọi model được huấn luyện trên từng phiên bản; và trang deployment liên kết đến model đang được sử dụng. Khi độ chính xác giảm, hãy bắt đầu từ deployment rồi lần ngược lại.

Agents tự động hóa bước thu thập. Collect Uncertain Detections chạy dự đoán qua deployment của bạn và sao chép các ảnh có detection trong một khoảng confidence vào dataset để xem xét; Capture and Alert lưu ảnh khớp điều kiện và gửi thông báo lên Slack. Workflow chỉ chạy khi bạn nhấp Run, vì vậy hãy đưa một lần chạy vào lịch đánh giá hằng tuần.

Ví dụ thực hành: Một chu kỳ hoàn chỉnh trên model viên thuốc#
1. Fine-tune từ model đang được triển khai. Trên Platform, chọn model đang được triển khai trong My Models, bật Save Dataset Version và chỉ định rõ optimizer. Thực hiện tương tự ở môi trường local như sau:
from ultralytics import YOLO
model = YOLO("pills-v1.pt") # model best.pt đang được triển khai
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")Đây là lần fine-tune trong Train, Read, and Fine-Tune Runs: mAP50-95 tăng từ 0.659 lên 0.687.
2. Đánh giá model với model đang được triển khai. Dùng lại gate.py trong bài 6 với tập holdout và hai checkpoint:
DATA = "medical-pills.yaml" # YAML của dataset holdout hoặc URI ul:// của bạn
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt" # model đang triển khai so với ứng viên được huấn luyện lạiPASS mAP50-95 0.659 -> 0.687 beats noise
PASS every class keeps 90% of its AP (weak: none)
PASS inference 4.0 ms within 100 ms
verdict: ship the candidateBước đánh giá kết thúc với mã thoát 0, vì vậy CI có thể tiếp tục đến bước phát hành. (Trong bản demo này, tập val của medical-pills được dùng thay cho tập holdout; trong môi trường production, hãy dùng phiên bản holdout mà model chưa từng thấy.)
3. Phát hành model. Tải ứng viên lên hoặc huấn luyện ứng viên trong cùng workspace, sau đó để CI gọi Replace model thông qua SDK ultralytics-platform và xác nhận model nào đang phục vụ:
import time
from ultralytics_platform import Platform
OWNER, DEPLOYMENT = "your-username", "pill-detector-st-ghislain"
PROJECT, NEW_MODEL = "pill-inspection", "v2-finetune"
with Platform() as client: # reads ULTRALYTICS_API_KEY
body = {"action": "replace", "project": PROJECT, "model": NEW_MODEL}
reply = client.deployments.update(OWNER, DEPLOYMENT, body=body)
print(reply["status"], "-", reply["message"]) # "deploying" while the new model starts
while (deployment := client.deployments.retrieve(OWNER, DEPLOYMENT)["deployment"])["status"] == "deploying":
time.sleep(15)
print(f"status={deployment['status']} model={deployment.get('model')}")
if deployment.get("model") != NEW_MODEL: # a failed rollout leaves the previous model serving
raise SystemExit("Replacement failed; the previous model is still live")Khi dùng API giả lập, API này báo deploying một lần rồi báo ready, kết quả in ra là:
deploying - Replacement model is deploying
status=ready model=v2-finetunedeployments.update gửi PATCH /api/deployments/{owner}/{deployment} cùng với action: "replace"; model cũ tiếp tục phục vụ cho đến khi model mới sẵn sàng. Vòng lặp kiểm tra retrieve cho đến khi trạng thái không còn là deploying, rồi kiểm tra model đang phục vụ, vì một lần triển khai thất bại cũng kết thúc ở ready, chỉ khác là vẫn dùng model cũ. Khôi phục sử dụng cùng script, với NEW_MODEL được đặt thành phiên bản trước đó. Công cụ dòng lệnh ul cloud đi kèm ultralytics bao bọc cùng API, và tài liệu tham khảo API mô tả mọi lệnh gọi.
4. Đặt lại baseline. Chạy holdout_check.py trong bài 8 với checkpoint mới và một file lịch sử mới.
Viết runbook#
# Retraining runbook: pill-detector
## Trigger
- Holdout mAP50-95 more than 1 point below baseline for 2 consecutive weeks, OR
- Batch Annotation edit rate above 25% on a new batch.
## Steps
1. Collect: Save to dataset from Monitoring, plus the "Collect Uncertain Detections" agent into pill-review.
2. Label: Batch Annotation with the deployed model at the swept threshold; review every image; record the edit rate.
3. Merge into the training dataset; rerun the duplicate check, class audit, and Clustering.
4. Create dataset version v(n+1) with a description of what changed.
5. Fine-tune from the deployed model with Save Dataset Version on; optimizer SGD, lr0 0.001.
6. Run gate.py against the deployed model on the holdout. Stop here on any FAIL.
7. ML lead approves; CI runs release.py.
8. Watch endpoint_check.py for 24 hours; start a new holdout baseline.
## Rollback
- Run release.py with NEW_MODEL set to the previous version. Never delete that model while it's the rollback target.
## Owner
- ML lead approves step 7. On-call runs steps 1-6 and 8.Đưa buổi đánh giá hằng tuần kéo dài 15 phút vào lịch, với hai câu hỏi: có điều gì đang báo đỏ không (kiểm tra endpoint, tập holdout, tỷ lệ chỉnh sửa), và deployment có thay đổi gì không, vì sao? Hầu hết các tuần, câu trả lời cho cả hai đều là không, và cuộc họp chỉ mất năm phút. Một quý điển hình sẽ như sau:
Week 1 : Holdout alert. Collect, label, retrain, gate, release v(n+1).
Week 2-3 : Quiet. Checks green.
Week 4 : New defect class requested. Label, new version, retrain v(n+2).
Week 5-7 : Quiet.
Week 8 : Second plant in Poland. Check regions; add an endpoint in europe-central2.
Week 9-11: Quiet.
Week 12 : Quarterly holdout refresh and review.Các lỗi thường gặp#
Triệu chứng: một bản phát hành gặp sự cố và model trước đó không còn nữa. Cách khắc phục: giữ lại ít nhất hai model production gần nhất trong project. Xóa model sẽ chuyển model đó vào Trash; nếu xóa vĩnh viễn model, mọi deployment vẫn đang phục vụ model đó cũng sẽ bị xóa.
Triệu chứng: bạn lên kế hoạch canary 10%/50%/100%, nhưng thao tác Replace model lại chuyển toàn bộ lưu lượng cùng lúc. Cách khắc phục: mỗi endpoint chỉ phục vụ một model. Để chạy canary, hãy triển khai model ứng viên lên endpoint thứ hai và phân chia lưu lượng bằng router của riêng bạn, sau đó thay model và xóa endpoint thứ hai.
Triệu chứng: mọi ứng viên đều vượt qua cổng kiểm định, nhưng production vẫn suy giảm. Cách khắc phục: cổng kiểm định chỉ đáng tin cậy trên một version holdout mà không lần chạy nào dùng để huấn luyện. Hãy giữ holdout trong dataset riêng tư của nó và tuyệt đối không gộp holdout vào dữ liệu huấn luyện.
Hiển thị lời giải
Chu kỳ thực tế cho dây chuyền viên thuốc. Ngưỡng kích hoạt: kết quả kiểm tra tập holdout ca đêm giảm 0.05. Thu thập: 180 ví dụ ca tối từ Monitoring được lưu vào pill-review, cùng với 120 ví dụ từ agent Collect Uncertain Detections; Batch Annotation ở mức 0.35 với v2-finetune đang được triển khai, tỷ lệ chỉnh sửa là 18%; đã xem xét và hợp nhất; kiểm tra đạt yêu cầu; phiên bản v6: +300 night-shift frames. Fine-tune v3-night từ v2-finetune, SGD, lr0 0.001, 20 epoch. Đánh giá trên tập holdout 300 ảnh, trong đó có 100 ảnh ban đêm: mAP50-95 tăng từ 0.66 lên 0.71, không có lớp yếu, 4 ms: ĐẠT. release.py với NEW_MODEL = "v3-night" báo cáo status=ready model=v3-night; holdout_check.py ghi baseline mới là 0.71. v2-finetune vẫn nằm trong project để làm mục tiêu khôi phục; runbook, bước đánh giá và script phát hành được commit cùng nhau.