Automatiza el ciclo de reentrenamiento

El ciclo, con una persona responsable de cada paso#

La trazabilidad viene incluida si has seguido las lecciones anteriores: la tarjeta Run Information de un modelo indica su modelo de origen y la versión fijada del conjunto de datos; la pestaña Models del conjunto de datos muestra todos los modelos entrenados con cada versión; y la página de despliegue enlaza al modelo que sirve. Cuando la precisión caiga, empieza por el despliegue y sigue el camino hacia atrás.

Agents automatiza el paso de recopilación. Collect Uncertain Detections predice con tu despliegue y copia las imágenes cuyas detecciones se encuentran dentro de un intervalo de confianza en un conjunto de datos de revisión; Capture and Alert guarda las imágenes coincidentes y publica un mensaje en Slack. Los flujos de trabajo se ejecutan cuando haces clic en Run, así que incluye una ejecución en la revisión semanal.

Ejemplo práctico: un ciclo completo con el modelo de pastillas#

1. Ajusta el modelo desplegado. En Platform, selecciona el modelo desplegado en My Models, activa Save Dataset Version y establece explícitamente el optimizador. En local, el mismo paso es:

from ultralytics import YOLO

model = YOLO("pills-v1.pt")  # el archivo best.pt del modelo desplegado
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")

Este es el ajuste de Train, Read, and Fine-Tune Runs: mAP50-95 0.659 → 0.687.

2. Evalúalo frente al modelo desplegado. Reutiliza gate.py de la lección 6 con el conjunto de reserva y los dos checkpoints:

DATA = "medical-pills.yaml"  # el YAML de tu conjunto de reserva o URI ul://
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt"  # modelo desplegado frente al candidato reentrenado

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

La comprobación termina con el código 0, así que CI puede continuar con el paso de lanzamiento. (En esta demostración, la partición de validación de medical-pills hace las veces de conjunto de reserva; en producción, usa una versión del conjunto de reserva que el modelo nunca haya visto.)

3. Lánzalo. Sube o entrena el candidato en el mismo espacio de trabajo y, después, deja que CI llame a Replace model mediante el SDK ultralytics-platform y confirme qué modelo está sirviendo:

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")

Con una API simulada que informa de deploying una vez y después de ready, se muestra:

deploying - Replacement model is deploying
status=ready model=v2-finetune

deployments.update envía PATCH /api/deployments/{owner}/{deployment} con action: "replace"; el modelo anterior sigue sirviendo hasta que el nuevo esté listo. El ciclo consulta retrieve hasta que el estado deja de ser deploying; después, comprueba el modelo que está sirviendo, porque una implementación fallida también termina en ready, pero conserva el modelo anterior. Para volver atrás, usa el mismo script con NEW_MODEL establecido en la versión anterior. La herramienta de línea de comandos ul cloud que se distribuye con ultralytics utiliza la misma API, y la referencia de la API documenta todas las llamadas.

4. Restablece la referencia. Ejecuta holdout_check.py de la lección 8 con el nuevo checkpoint y un archivo de historial nuevo.

Escribe el manual de operaciones#

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

Reserva en el calendario una revisión semanal de 15 minutos con dos preguntas: ¿hay algo en rojo (comprobación del endpoint, conjunto de reserva, tasa de edición)? ¿Ha cambiado algo en el despliegue y por qué? La mayoría de las semanas, la respuesta a ambas preguntas es no y la reunión dura cinco minutos. Un trimestre típico sería así:

   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.

Errores habituales#