Den Nachschulungsprozess automatisieren
Verwandle ein Deployment in einen wiederholbaren Prozess: mit einem Runbook, einem skriptgesteuerten Freigabekriterium, einer automatisierten Veröffentlichung mit Rollback und einer wöchentlichen Überprüfung.
Das erste Deployment ist ein Projekt; jedes weitere ist ein Prozess. Teams, die den Ablauf skripten, können an einem Nachmittag nachtrainieren, sobald der Holdout-Alarm ausgelöst wird. Teams ohne Skripte müssen den Ablauf unter Druck aus dem Gedächtnis rekonstruieren und veröffentlichen Regressionen. In dieser Lektion durchläufst du den gesamten Prozess einmal mit dem Pillenmodell – Feinabstimmung, Freigabeprüfung und Veröffentlichung – und erstellst das Runbook, das den nächsten Durchlauf zur Routine macht.
Praxisnah
Der Ablauf – mit einer verantwortlichen Person für jeden Schritt#
Die Modellherkunft ist automatisch dokumentiert, wenn du die vorherigen Lektionen angewendet hast: Die Karte Run Information eines Modells nennt das übergeordnete Modell und die festgelegte Dataset-Version, der Tab Models des Datasets listet alle Modelle auf, die mit den einzelnen Versionen trainiert wurden, und die Bereitstellungsseite verlinkt auf das Modell, das sie bereitstellt. Wenn die Genauigkeit sinkt, beginne bei der Bereitstellung und gehe die Schritte rückwärts durch.

Agents automatisiert den Sammelschritt. Collect Uncertain Detections führt Vorhersagen mit deiner Bereitstellung aus und kopiert Bilder mit Erkennungen innerhalb eines Konfidenzbereichs in ein Prüf-Dataset; Capture and Alert speichert passende Bilder und sendet eine Nachricht an Slack. Workflows werden erst ausgeführt, wenn du auf Run klickst. Nimm daher einen Durchlauf in die wöchentliche Überprüfung auf.

Durchgespieltes Beispiel: ein vollständiger Zyklus mit dem Pill-Modell#
1. Vom bereitgestellten Modell aus weitertrainieren. Wähle auf Platform unter My Models das bereitgestellte Modell aus, aktiviere Save Dataset Version und lege den Optimierer ausdrücklich fest. Lokal sieht derselbe Schritt so aus:
from ultralytics import YOLO
model = YOLO("pills-v1.pt") # best.pt des bereitgestellten Modells
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")Das ist das Weitertrainieren aus Train, Read, and Fine-Tune Runs: mAP50-95 0.659 → 0.687.
2. Mit dem bereitgestellten Modell vergleichen. Verwende gate.py aus Lektion 6 erneut – mit dem Holdout und den beiden Checkpoints:
DATA = "medical-pills.yaml" # deine Holdout-Dataset-YAML-Datei oder ul://-URI
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt" # bereitgestelltes Modell vs. erneut trainierter KandidatPASS 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 candidateDie Prüfung endet mit dem Exitcode 0, sodass CI mit dem Freigabeschritt fortfahren kann. (In dieser Demo dient der Val-Split von medical-pills als Holdout; in der Produktion solltest du eine Holdout-Version verwenden, die das Modell noch nie gesehen hat.)
3. Freigeben. Lade den Kandidaten in denselben Arbeitsbereich hoch oder trainiere ihn dort. Lass dann CI über das SDK ultralytics-platform Replace model aufrufen und bestätige, welches Modell bereitgestellt wird:
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")Bei einer simulierten API, die einmal deploying und danach ready zurückgibt, wird Folgendes ausgegeben:
deploying - Replacement model is deploying
status=ready model=v2-finetunedeployments.update sendet PATCH /api/deployments/{owner}/{deployment} mit action: "replace"; das alte Modell bleibt aktiv, bis das neue bereit ist. Die Schleife fragt retrieve so lange ab, bis der Status nicht mehr deploying lautet, und prüft anschließend das bereitgestellte Modell, denn auch ein fehlgeschlagener Rollout endet mit ready – dann allerdings mit dem alten Modell. Für ein Rollback verwendest du dasselbe Skript und setzt NEW_MODEL auf die vorherige Version. Das mit ultralytics ausgelieferte Befehlszeilenprogramm ul cloud kapselt dieselbe API. Die API-Referenz dokumentiert jeden Aufruf.
4. Ausgangsbasis zurücksetzen. Führe holdout_check.py aus Lektion 8 mit dem neuen Checkpoint und einer frischen Verlaufsdatei aus.
Das Runbook verfassen#
# 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.Trage eine wöchentliche Überprüfung von 15 Minuten in den Kalender ein und stelle dabei zwei Fragen: Ist irgendetwas rot (Endpunktprüfung, Holdout, Bearbeitungsrate)? Hat sich etwas an der Bereitstellung geändert, und warum? In den meisten Wochen lautet die Antwort auf beide Fragen Nein, und das Meeting dauert fünf Minuten. Ein typisches Quartal sieht so aus:
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.Stolperfallen#
Symptom: Eine Veröffentlichung läuft schief, und das vorherige Modell ist nicht mehr vorhanden. Lösung: Behalte mindestens die letzten beiden Produktivmodelle im Projekt. Beim Löschen eines Modells wird es in den Papierkorb verschoben. Wird ein Modell endgültig gelöscht, werden auch alle Bereitstellungen entfernt, die es noch verwenden.
Symptom: Du hast eine schrittweise Einführung mit 10 %/50 %/100 % geplant, doch „Modell ersetzen“ leitet den gesamten Datenverkehr auf einmal um. Lösung: Jeder Endpunkt stellt genau ein Modell bereit. Für einen Canary-Release stelle das Kandidatenmodell auf einem zweiten Endpunkt bereit und teile den Datenverkehr über deinen eigenen Router auf. Ersetze anschließend das Modell und lösche den zweiten Endpunkt.
Symptom: Jeder Kandidat besteht das Gate, doch im Produktivbetrieb verschlechtert sich die Leistung trotzdem. Lösung: Das Gate liefert nur dann ein verlässliches Ergebnis, wenn es anhand einer Holdout-Version geprüft wird, mit der kein Lauf trainiert wurde. Bewahre die Holdout-Daten in einem eigenen privaten Datensatz auf und füge sie niemals den Trainingsdaten hinzu.
Lösung anzeigen
Durchgespielter Zyklus für die Pill-Linie. Auslöser: Die Holdout-Prüfung der Nachtschicht sank um 0.05. Sammeln: 180 bei der Überwachung gespeicherte Beispiele aus der Abendschicht in pill-review sowie 120 vom Agenten Collect Uncertain Detections; Batch Annotation mit 0.35 und dem bereitgestellten v2-finetune, Bearbeitungsrate 18 %; geprüft und zusammengeführt; Prüfungen ohne Beanstandungen; Version v6: +300 night-shift frames. v3-night mit SGD, lr0 0.001 und 20 Epochen aus v2-finetune weitertrainieren. Prüfung mit dem Holdout aus 300 Bildern, darunter 100 Nachtaufnahmen: mAP50-95 0.66 → 0.71, keine schwachen Klassen, 4 ms: BESTANDEN. release.py mit NEW_MODEL = "v3-night" meldet status=ready model=v3-night; holdout_check.py speichert eine neue Ausgangsbasis von 0.71. v2-finetune bleibt als Rollback-Ziel im Projekt. Runbook, Prüfung und Freigabeskript werden gemeinsam eingecheckt.