Automatize o ciclo de retreinamento
Transforme uma implantação em um ciclo repetível: um runbook, uma verificação de promoção com script, uma versão automatizada com reversão e uma revisão semanal.
A primeira implantação é um projeto; todas as seguintes são um processo. As equipes que automatizam o ciclo com scripts fazem o retreinamento em uma tarde sempre que o alerta do conjunto de validação dispara; as equipes que não fazem isso reconstroem o processo de memória sob pressão e lançam regressões. Nesta lição, o ciclo é executado de ponta a ponta uma vez no modelo de pílulas — ajuste fino, verificação e lançamento — e você cria o runbook que tornará as próximas execuções rotineiras.
Prático
O ciclo, com um responsável por cada etapa#
A linhagem vem incluída se tiveres seguido as lições anteriores: o cartão Run Information de um modelo indica o modelo de origem e a versão fixada do conjunto de dados, o separador Models do conjunto de dados lista todos os modelos treinados em cada versão, e a página de implantação tem um link para o modelo que está a servir. Quando a precisão diminuir, começa na implantação e percorre o caminho inverso.
Agents automatiza a etapa de recolha. Collect Uncertain Detections faz previsões através da tua implantação e copia para um conjunto de dados de revisão as imagens com deteções dentro de um intervalo de confiança; Capture and Alert guarda imagens correspondentes e publica uma mensagem no Slack. Os workflows são executados quando clicas em Run, por isso inclui uma execução na revisão semanal.
Exemplo prático: um ciclo completo no modelo de comprimidos#
1. Faz o fine-tuning a partir do modelo implantado. Na Platform, escolhe o modelo implantado em My Models, ativa Save Dataset Version e define explicitamente o otimizador. Localmente, o mesmo passo é:
from ultralytics import YOLO
model = YOLO("pills-v1.pt") # o best.pt do modelo implantado
model.train(data="medical-pills.yaml", epochs=5, imgsz=320, optimizer="SGD", lr0=0.001, name="v2-finetune")Este é o fine-tuning de Treinar, ler e fazer fine-tuning de execuções: mAP50-95 0.659 → 0.687.
2. Compara-o com o modelo implantado. Reutiliza gate.py da lição 6 com o conjunto de validação reservado e os dois checkpoints:
DATA = "medical-pills.yaml" # o YAML do teu conjunto de dados reservado ou URI ul://
BASELINE, CANDIDATE = "pills-v1.pt", "pills-v2.pt" # modelo implantado vs. candidato retreinadoPASS 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 candidateA verificação termina com o código 0, por isso a CI pode avançar para a etapa de lançamento. (Nesta demonstração, a divisão val do conjunto medical-pills serve de substituto para um conjunto de validação reservado; em produção, usa uma versão de validação reservada que o modelo nunca tenha visto.)
3. Lança-o. Carrega ou treina o candidato no mesmo espaço de trabalho e, em seguida, permite que a CI chame Replace model através do SDK ultralytics-platform e confirma o que está a servir:
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")Contra uma API simulada que comunica deploying uma vez e depois ready, apresenta:
deploying - Replacement model is deploying
status=ready model=v2-finetunedeployments.update envia PATCH /api/deployments/{owner}/{deployment} com action: "replace"; o modelo antigo continua a servir até o novo estar pronto. O ciclo consulta retrieve até o estado deixar de ser deploying e, depois, verifica o modelo em serviço, porque uma implantação falhada também termina em ready, mas com o modelo antigo. A reversão é o mesmo script com NEW_MODEL definido para a versão anterior. A ferramenta de linha de comandos ul cloud, distribuída com ultralytics, usa a mesma API, e a referência da API documenta todas as chamadas.
4. Redefine a linha de base. Executa holdout_check.py da lição 8 com o novo checkpoint e um ficheiro de histórico novo.
Escreve o 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.Reserva 15 minutos na agenda para uma revisão semanal com duas perguntas: há algo a vermelho (verificação do endpoint, conjunto reservado, taxa de edição) e houve alguma alteração na implantação; se sim, porquê? Na maioria das semanas, a resposta a ambas é não, e a reunião dura cinco minutos. Um trimestre típico é assim:
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.Armadilhas#
Sintoma: uma versão é lançada com problemas, e o modelo anterior desapareceu. Solução: mantenha no mínimo os dois modelos de produção mais recentes no projeto. Excluir um modelo o move para a Lixeira, e excluir um modelo permanentemente também remove qualquer implantação que ainda o esteja servindo.
Sintoma: você planejou uma implantação canário de 10%/50%/100%, mas Substituir modelo muda todo o tráfego de uma vez. Solução: os endpoints servem um único modelo. Para uma implantação canário, implante o candidato em um segundo endpoint e divida o tráfego no seu próprio roteador; depois, substitua o modelo e exclua o segundo endpoint.
Sintoma: todos os candidatos passam pelo critério, mas o desempenho em produção ainda regride. Solução: o critério só é confiável com uma versão de validação que nenhuma execução usou para treinamento. Mantenha o conjunto de validação em seu próprio conjunto de dados privado e nunca o mescle aos dados de treinamento.
Mostrar solução
Ciclo prático para a linha de comprimidos. Acionador: a verificação do conjunto reservado do turno da noite caiu 0.05. Recolha: 180 exemplos do turno da noite do Monitoring guardados em pill-review, mais 120 do agente Collect Uncertain Detections; Batch Annotation a 0.35 com o v2-finetune implantado, taxa de edição de 18%; revisão e fusão concluídas; auditorias sem problemas; versão v6: +300 night-shift frames. Faz fine-tuning de v3-night a partir de v2-finetune, SGD, lr0 0.001, 20 épocas. Verificação no conjunto reservado de 300 imagens, incluindo 100 imagens noturnas: mAP50-95 0.66 → 0.71, sem classes fracas, 4 ms: PASS. release.py com NEW_MODEL = "v3-night" comunica status=ready model=v3-night; holdout_check.py grava uma nova linha de base de 0.71. v2-finetune permanece no projeto como alvo de reversão, e o runbook, a verificação e o script de lançamento são submetidos juntos.