Ultralytics YOLO27: Trag dich in die Warteliste ein.
Get Started
Mit der Ultralytics Platform entwickeln·Bereitstellen und überwachen·Lektion 10/10
LektionFortgeschrittene

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.

Lernergebnis

Du kannst einen Nachschulungszyklus von Anfang bis Ende durchlaufen: Feinabstimmung mit einer neuen Datensatzversion, die Freigabeprüfung im Vergleich zum bereitgestellten Modell bestehen, das Modell mithilfe eines Skripts mit „Modell ersetzen“ veröffentlichen und in einem Schritt zurücksetzen.

Schnellkurs
Wenn du dich bereits auskennst, findest du hier die Kurzfassung.
  1. Auslöser: Einbrüche beim Holdout, eine steigende Bearbeitungsrate oder Drift im Tab „Monitoring“.

  2. Sammeln mit „In Datensatz speichern“ oder Agents, Beschriften mit Batch Annotation, prüfen und versionieren.

  3. Führe eine Feinabstimmung des bereitgestellten Modells mit einem ausdrücklich festgelegten Optimierer und lr0 durch.

  4. Prüfe den Kandidaten anhand des bereitgestellten Modells und veröffentliche ihn mit deployments.update(action="replace").

  5. Setze zurück, indem du das vorherige Modell einsetzt; lösche es niemals, solange es dein Rücksetzungsziel ist.

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.

Models-Tab des Ultralytics Platform-Datasets „Logistics Safety“ mit den darauf trainierten Modellen sowie Spalten für Status, Aufgabe, Epochen, mAP50 und mAP50-95

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.

Canvas von Ultralytics Platform Agents mit einem Eingabebild-Block, der mit einem YOLO-Block zur Personenerkennung, einer Bedingung „wenn eine Person erscheint“, einem Sprachmodell-Block zur Szenenbeschreibung und einem Ausgabe-Block verbunden ist

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 Kandidat
PASS 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 candidate

Die 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-finetune

deployments.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#

Das Modell für ein Rollback löschen

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.

Eine schrittweise Einführung erwarten

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.

Das Gate anhand der Trainingsdaten prüfen

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.

Ausprobieren

Verfasse das Runbook deines Projekts im obigen Format. Es muss einen messbaren Auslöser, Schritte mit der jeweiligen Platform-Funktion und dem Skript, ein Rollback und verantwortliche Personen benennen. Führe dann einen vollständigen Zyklus durch: Trainiere das bereitgestellte Modell mit einer neuen Dataset-Version weiter, führe gate.py damit auf deinem Holdout aus und gib es bei erfolgreicher Prüfung mit release.py frei (oder verwende Replace model in der Benutzeroberfläche). Setze anschließend die Holdout-Ausgangsbasis zurück.

Commit
git add retraining-runbook.md gate.py release.py && git commit -m "ops: add retraining runbook, promotion gate, and release script"
Abgeschlossen, wenn
Du hast die Lektion abgeschlossen, wenn alle folgenden Punkte zutreffen.
  • Dein Runbook enthält einen messbaren Auslöser, nummerierte Schritte, ein Rollback und benannte Verantwortliche.

  • gate.py hat für einen echten Kandidaten ein Urteil im Vergleich zu deinem bereitgestellten Modell ausgegeben.

  • Der Endpunkt stellt das geprüfte Modell bereit, das vorherige Modell ist weiterhin im Projekt vorhanden und es gibt eine neue Zeile für die Holdout-Ausgangsbasis.

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.

Wie es weitergeht

Kurs abgeschlossen – lege die Abschlussprüfung ab, um das Zertifikat Build with Ultralytics Platform zu erhalten. Vertiefe anschließend dein Wissen über Bereitstellungen am Netzwerkrand und selbst gehostete Bereitstellungen mit Ultralytics YOLO in Production.