Yeniden Eğitim Döngüsünü Otomatikleştir
Tek bir dağıtımı tekrarlanabilir bir döngüye dönüştür: bir çalışma kılavuzu, betikle çalışan bir sürüme alma eşiği, geri alma olanağı içeren otomatik sürüm yayımlama ve haftalık inceleme.
İlk dağıtım bir projedir; ondan sonraki her dağıtım bir süreçtir. Döngüyü betiklerle otomatikleştiren ekipler, doğrulama kümesi uyarısı tetiklendiğinde bir öğleden sonra içinde yeniden eğitim yapar; otomatikleştirmeyen ekipler ise baskı altında süreci hatırladıklarından yeniden kurar ve gerilemelere yol açan sürümler yayımlar. Bu derste hap modeli üzerinde ince ayar yapıp eşik uygulayarak ve sürüm yayımlayarak döngüyü baştan sona bir kez çalıştıracak, sonraki seferi rutin hâle getirecek çalışma kılavuzunu yazacaksın.
Uygulamalı
Her Adımın Bir Sorumlusunun Olduğu Döngü#
Önceki dersleri izlediysen model kökeni bilgileri hazırdır: modelin Run Information kartında üst modeli ve sabitlenmiş veri kümesi sürümü belirtilir, veri kümesinin Models sekmesinde her sürüm üzerinde eğitilmiş tüm modeller listelenir ve dağıtım sayfasında sunulan modele bağlantı verilir. Doğruluk düştüğünde dağıtım noktasından başlayıp geriye doğru ilerle.

Agents toplama adımını otomatikleştirir. Collect Uncertain Detections, dağıtımın üzerinden tahmin yapar ve güven aralığında tespitler içeren görselleri bir inceleme veri kümesine kopyalar; Capture and Alert eşleşen görselleri kaydeder ve Slack'te paylaşım yapar. İş akışları Run'a tıkladığında çalışır; bu nedenle haftalık incelemeye bir çalıştırma ekle.

Uygulamalı Örnek: Hap Modelinde Tam Bir Döngü#
1. Dağıtılmış modelden ince ayar yap. Platform'da My Models altından dağıtılmış modeli seç, Save Dataset Version'ı etkinleştir ve optimizer'ı açıkça belirle. Yerel ortamda aynı adım şöyledir:
from ultralytics import YOLO
model = YOLO("pills-v1.pt") # dağıtılmış modelin best.pt
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")Bu, Train, Read, and Fine-Tune Runs dersindeki ince ayardır: mAP50-95 0.659 → 0.687.
2. Dağıtılmış modele göre geçiş koşulunu uygula. 6. dersteki gate.py öğesini holdout ve iki kontrol noktasıyla yeniden kullan:
DATA = "medical-pills.yaml" # holdout veri kümesi YAML dosyan veya ul:// URI'n
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt" # dağıtılmış model ve yeniden eğitilmiş adayPASS 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 candidateGeçiş koşulu 0 koduyla çıkar; bu nedenle CI sürüm adımına devam edebilir. (Bu demoda medical-pills doğrulama bölmesi holdout yerine kullanılıyor; üretimde modelin daha önce görmediği bir holdout sürümü kullan.)
3. Sürüme al. Adayı aynı çalışma alanına yükle veya eğit, ardından CI'ın ultralytics-platform SDK'sı üzerinden Replace model çağırmasına izin ver ve hangi modelin sunulduğunu doğrula:
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")Önce deploying, ardından ready bildiren sahte bir API'ye karşı çalıştırıldığında şunu yazdırır:
deploying - Replacement model is deploying
status=ready model=v2-finetunedeployments.update, action: "replace" ile PATCH /api/deployments/{owner}/{deployment} gönderir; yeni model hazır olana kadar eski model sunulmaya devam eder. Döngü, durum deploying değerinden çıkana kadar retrieve öğesini yoklar, ardından sunulan modeli kontrol eder; çünkü başarısız bir dağıtım da ready ile sona erer, ancak eski model sunulmaya devam eder. Geri alma işlemi, NEW_MODEL önceki sürüme ayarlanarak aynı betiğin çalıştırılmasıdır. ultralytics ile gelen ul cloud komut satırı aracı aynı API'yi sarmalar ve API başvurusu tüm çağrıları belgeler.
4. Başlangıç değerini sıfırla. Yeni kontrol noktası ve yeni bir geçmiş dosyasıyla 8. dersteki holdout_check.py öğesini çalıştır.
Çalıştırma Kılavuzunu Yaz#
# 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.Takvimine haftalık 15 dakikalık bir inceleme ekle ve iki soru sor: kırmızı olan bir şey var mı (uç nokta kontrolü, holdout, düzenleme oranı) ve dağıtımda bir şey değişti mi, değiştiyse neden? Çoğu hafta her iki sorunun yanıtı da hayırdır ve toplantı beş dakika sürer. Tipik bir çeyrek şöyle görünür:
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.Yaygın Hatalar#
Belirti: Bir sürüm yayını ters gidiyor ve önceki model artık yok. Çözüm: Projede üretimdeki en az son iki modeli tut. Bir modeli silmek onu Çöp Kutusu'na taşır; kalıcı olarak silinen bir model, modeli sunmaya devam eden dağıtımları da kaldırır.
Belirti: %10/%50/%100'lük bir canary dağıtımı planladın, ancak Modeli değiştir seçeneği tüm trafiği bir kerede değiştiriyor. Çözüm: Uç noktalar tek bir model sunar. Canary dağıtımı için adayı ikinci bir uç noktaya dağıt ve trafiği kendi yönlendiricinde böl; ardından modeli değiştirip ikinci uç noktayı sil.
Belirti: Her aday geçiş koşulunu karşılıyor, ancak üretim sonuçları yine de geriliyor. Çözüm: Geçiş koşulu yalnızca hiçbir çalıştırmanın eğitimde kullanmadığı ayrılmış bir sürüm üzerinde güvenilirdir. Ayrılmış kümeyi kendi özel veri kümesinde tut ve asla eğitim verileriyle birleştirme.
Çözümü göster
Hap üretim hattı için tamamlanmış döngü. Tetikleyici: gece vardiyası holdout kontrolü 0.05 düştü. Topla: Akşam vardiyasından 180 Monitoring örneği pill-review öğesine kaydedildi; Collect Uncertain Detections ajanından 120 örnek daha alındı; dağıtılmış v2-finetune ile 0.35 değerinde Batch Annotation uygulandı, düzenleme oranı %18 oldu; örnekler incelenip birleştirildi; denetimler temiz; sürüm v6: +300 night-shift frames. v2-finetune üzerinden SGD, lr0 0.001 ve 20 epoch ile v3-night modeline ince ayar yap. Gece görüntülerinden 100'ünü içeren 300 görüntülük holdout üzerinde geçiş koşulunu uygula: mAP50-95 0.66 → 0.71, zayıf sınıf yok, 4 ms: PASS. NEW_MODEL = "v3-night" ile release.py, status=ready model=v3-night bildiriyor; holdout_check.py, 0.71 değerinde yeni bir başlangıç değeri yazıyor. v2-finetune geri alma hedefi olarak projede kalıyor ve çalıştırma kılavuzu, geçiş koşulu ve sürüm betiği birlikte işleniyor.