Ultralytics YOLO27: Inscreve-te na lista de espera.
Get Started
Crie com a Ultralytics Platform·Implementar e monitorizar·Aula 8/10
Aulaintermediário

Monitore a integridade e a precisão

Consulte as métricas dos endpoints e as estatísticas de previsões da Platform, configure alertas a partir de uma verificação de integridade agendada e detecte desvios de precisão com uma tarefa de holdout.

Um endpoint pode retornar 200 OK em todas as solicitações enquanto sua precisão cai 5 pontos porque a equipe do turno da noite diminuiu a iluminação. A Platform mostra o comportamento de cada endpoint, mas não envia alertas e não consegue avaliar a precisão sem rótulos. Esta lição cria as duas verificações agendadas que resolvem essa lacuna e ensaia o alerta de precisão com um turno da noite simulado.

Resultado

Você pode executar uma verificação agendada do endpoint que retorna um código diferente de zero quando há uma violação de latência, erro ou integridade, além de uma tarefa de holdout que registra o histórico de precisão e alerta sobre uma regressão real.

Via rápida
Se já sabes orientar-te, aqui está a versão resumida.
  1. Acompanhe os cartões de solicitações HTTP, taxa de erros e latência P95; abra Logs com o filtro Errors.

  2. Consulte a integridade e as métricas com o SDK ultralytics-platform a cada 5 minutos; retorne o código 1 quando houver uma violação.

  3. Avalie semanalmente o best.pt implantado usando um holdout rotulado; alerte se a queda passar de 1 ponto de mAP.

  4. Salve exemplos úteis de Monitoring em um conjunto de dados antes que o endpoint reinicie; eles ficam na memória.

Prático

O que a Platform mostra#

Guia Deployments do perfil da Ultralytics Platform, com um mapa-múndi com marcadores de regiões e cartões de visão geral para implantações ativas, solicitações HTTP, taxa de erros HTTP e latência P95 HTTP

SinalOndePor quanto tempo fica disponível
Solicitações HTTP, taxa de erros (4xx e 5xx), latência P95Cartões na página da implantação e na guia Deployments, atualizados a cada minutoOs cartões abrangem 24 horas; a API disponibiliza dados de 1 hora a 30 dias
IntegridadeCartão Endpoint na guia OverviewAo vivo; novas tentativas automáticas enquanto estiver com problemas
LogsGuia Logs: 20 entradas mais recentes, filtro ErrorsA API retorna até 200 entradas por solicitação, com paginação
Estatísticas de previsões e exemplos temporários (até 100 imagens)Guia MonitoringSomente na memória da instância que atende às solicitações

Guia Monitoring da implantação na Ultralytics Platform, mostrando uma galeria de imagens temporárias de exemplo com previsões acima da seção Prediction Statistics

Duas ressalvas determinam todo o resto. As métricas são coletadas somente enquanto o endpoint está Ready, e excluir uma implantação encerra o acesso ao histórico dela. As estatísticas e os exemplos da guia Monitoring são perdidos sempre que o endpoint para, reinicia, é redimensionado ou tem o modelo substituído: é uma visualização ao vivo, não um arquivo.

Exemplo prático: uma verificação agendada do endpoint#

A Platform deixa o cartão de taxa de erros vermelho quando ultrapassa 5%, e o Slack pode anunciar quando uma implantação fica pronta ou falha ao iniciar, mas não há alertas por limite. Execute esta verificação a cada 5 minutos usando cron, CI ou seu agente de monitoramento e envie um alerta se o código de saída for diferente de zero:

from ultralytics_platform import Platform

OWNER, DEPLOYMENT = "your-username", "yolo26n-iowa"  # from the deployment page URL
P95_BUDGET_MS, MAX_ERROR_RATE = 300, 1.0  # errorRate is a percentage

with Platform() as client:  # reads ULTRALYTICS_API_KEY
    health = client.deployments.health(OWNER, DEPLOYMENT)
    summary = client.deployments.metrics(OWNER, DEPLOYMENT, range="1h", view="overview")["summary"]
    print(
        f"healthy={health['healthy']} requests={summary['totalRequests']} "
        f"p95={summary['p95LatencyMs']:.0f} ms errors={summary['errorRate']:.2f}%"
    )
    if not health["healthy"] or summary["p95LatencyMs"] > P95_BUDGET_MS or summary["errorRate"] > MAX_ERROR_RATE:
        for entry in client.deployments.logs(OWNER, DEPLOYMENT, severity="ERROR,WARNING", limit=5)["entries"]:
            print(entry["timestamp"], entry["severity"], entry["message"][:120])
        raise SystemExit(1)  # non-zero exit lets cron, CI, or your pager treat it as an alert

Quando executado com uma API simulada que retorna um endpoint íntegro, o código exibe uma linha e retorna 0; com P95_BUDGET_MS = 100, os mesmos dados retornam 1:

healthy=True requests=1200 p95=180 ms errors=0.40%
  • health verifica o endpoint e retorna healthy, status e latencyMs. Também ativa um endpoint cuja escala chegou a zero, então uma verificação a cada 5 minutos funciona como uma chamada para mantê-lo aquecido.
  • metrics(..., view="overview") retorna totalRequests, errorRate (uma porcentagem) e p95LatencyMs para o intervalo.
  • logs busca os erros e avisos mais recentes, para que o alerta já chegue com uma primeira pista.

Instale o SDK com pip install -U ultralytics-platform (o SDK exige Python 3.11 ou superior). Envie alertas somente para violações persistentes, por exemplo, três verificações com falha consecutivas, e inclua em cada alerta uma entrada de runbook de uma linha.

Exemplo prático: acompanhe a precisão com um holdout#

As métricas das solicitações não mostram a precisão, mas um holdout pode: 200–500 imagens realistas de produção, rotuladas cuidadosamente em uma versão privada própria do conjunto de dados, nunca usadas no treinamento. Avalie semanalmente o checkpoint implantado e acrescente os resultados a um arquivo de histórico:

import json
import sys
from datetime import date
from pathlib import Path

from ultralytics import YOLO

DEPLOYED = "pills-v1.pt"  # the exact best.pt behind the endpoint
HOLDOUT = sys.argv[1] if len(sys.argv) > 1 else "medical-pills.yaml"  # labeled, never trained on

metrics = YOLO(DEPLOYED).val(data=HOLDOUT, split="val", plots=False, verbose=False)
history = Path("holdout_history.jsonl")
rows = [json.loads(line) for line in history.read_text().splitlines()] if history.exists() else []
row = {"date": date.today().isoformat(), "data": HOLDOUT, "map50_95": round(float(metrics.box.map), 4)}
history.write_text("".join(json.dumps(r) + "\n" for r in [*rows, row]))

baseline = rows[0]["map50_95"] if rows else row["map50_95"]
drop = baseline - row["map50_95"]
print(f"holdout mAP50-95 {row['map50_95']:.3f} (baseline {baseline:.3f}, drop {drop:+.3f})")
if drop > 0.01:  # more than 1 mAP point below the deployment-day baseline
    raise SystemExit("ALERT: holdout accuracy regressed - open the retraining runbook")

A primeira execução registra a linha de base do dia da implantação. Em seguida, ensaie o alerta antes de precisar dele: este script cria uma cópia do holdout do "turno da noite", com os mesmos rótulos e imagens a 15% de brilho:

import shutil
from pathlib import Path

import cv2

from ultralytics.data.utils import check_det_dataset

src = Path(check_det_dataset("medical-pills.yaml")["path"])
dst = Path("pills-night")
(dst / "images/val").mkdir(parents=True, exist_ok=True)
for img in (src / "images/val").glob("*.jpg"):  # darken every holdout image to mimic a dim night shift
    cv2.imwrite(str(dst / "images/val" / img.name), (cv2.imread(str(img)) * 0.15).astype("uint8"))
shutil.copytree(src / "labels/val", dst / "labels/val", dirs_exist_ok=True)  # same labels, darker pixels
Path("pills-night.yaml").write_text(f"path: {dst.resolve()}\ntrain: images/val\nval: images/val\nnames:\n  0: pill\n")
print("wrote pills-night.yaml")
$ python holdout_check.py
holdout mAP50-95 0.659 (baseline 0.659, drop +0.000)
$ python simulate_night_shift.py
wrote pills-night.yaml
$ python holdout_check.py pills-night.yaml
holdout mAP50-95 0.609 (baseline 0.659, drop +0.050)
ALERT: holdout accuracy regressed - open the retraining runbook

Todas as solicitações durante o turno da noite ainda retornariam 200 em milissegundos, mas o modelo perdeu 5 pontos de mAP. Só o holdout detecta isso. Atualize o holdout a cada trimestre com novas imagens de produção rotuladas e redefina a linha de base sempre que implantar um novo modelo. O guia de monitoramento de modelos e a lição Observabilidade e deriva abordam testes estatísticos de deriva.

Leia a guia Monitoring para detectar deriva#

Estatísticas de previsões na guia Monitoring da implantação na Ultralytics Platform, com Previsões ao longo do tempo, Tempo de inferência, um gráfico de rosca das principais classes e um histograma de previsões por imagem

Observe o formato dos gráficos na semana da implantação e depois compare. A confiança mede a certeza, não a correção; por isso, analise estes dados junto com o holdout:

PadrãoCausa provávelAção
A confiança cai, o holdout permanece estávelMudança benigna de domínioAcompanhe; salve exemplos para a próxima versão do conjunto de dados
A confiança e o holdout caemRegressão real de precisãoTreine novamente (lição 10)
O tamanho ou a localização das caixas muda de repenteA câmera foi movida, ou a lente ou o local mudouVerifique a câmera antes de mexer no modelo
As previsões por imagem diminuem, mas a confiança permanece estávelCâmera desconectada, cena mais tranquila ou bug no clienteInvestigue os sistemas upstream
A latência P95 aumenta, mas o tempo de inferência permanece estávelProcessamento da solicitação, tamanho do payload ou capacidadeInfraestrutura, não o modelo

Incorpore imagens de produção ao conjunto de dados#

Na guia Monitoring, selecione exemplos e clique em Save to dataset; eles passam pelo processo normal de ingestão, junto com as previsões, e mantêm deploymentId e a região nos metadados. O modelo Collect Uncertain Detections de Agents faz o mesmo para um conjunto de dados inteiro: prevê usando sua implantação e copia as imagens com detecções dentro de um intervalo de confiança para um conjunto de dados de revisão.

Caixa de diálogo Salvar exemplos no conjunto de dados da Ultralytics Platform, com um seletor de conjunto de dados e um botão Salvar 4 imagens sobre a guia Monitoramento

Armadilhas#

Os exemplos de monitoramento desaparecem após a reinicialização

Sintoma: os exemplos que você pretendia rotular desaparecem após redimensionar a instância ou trocar de modelo. Solução: eles ficam na memória da instância de serviço. Salve-os em um conjunto de dados e aguarde a conclusão da ingestão antes de parar, redimensionar ou substituir o modelo.

A linha de base não foi redefinida após uma implantação

Sintoma: o alerta do conjunto de validação é acionado logo após a implantação de um modelo melhor, ou nunca mais é acionado. Solução: a linha de base é a primeira linha do histórico. Inicie um novo holdout_history.jsonl (ou registre uma nova linha de linha de base) sempre que substituir o modelo.

Os erros 429 parecem uma interrupção

Sintoma: a taxa de erros aumenta durante um pico de tráfego, enquanto o estado de saúde permanece normal. Solução: respostas 429 contam como erros, mas significam 'no limite da capacidade'. Confira os registros; se forem erros 429, distribua o tráfego entre mais endpoints ou use um tamanho personalizado maior.

Experimente

Agende endpoint_check.py para verificar sua implantação a cada 5 minutos e confirme que ele termina com o código 1 quando você define P95_BUDGET_MS abaixo do seu P95 real. Execute holdout_check.py com seu best.pt implantado e o conjunto de validação para registrar uma linha de base; em seguida, ensaie o alerta com uma cópia degradada do conjunto de validação (mais escura, mais desfocada ou de uma câmera diferente). Por fim, salve pelo menos 10 exemplos de Monitoramento em um conjunto de dados para revisão.

Concluído quando
Você concluiu a aula quando todos estes critérios forem atendidos.
  • A verificação do endpoint é executada conforme um agendamento, e uma violação forçada termina com o código de status 1.

  • holdout_history.jsonl contém uma linha de base, e uma regressão ensaiada exibiu a linha ALERT.

  • Pelo menos 10 exemplos de produção estão em um conjunto de dados para revisão, com metadados da implantação.

Mostrar solução

Resposta resolvida para o endpoint de pílulas: uma entrada cron */5 * * * * python endpoint_check.py || ./page-oncall.sh com P95_BUDGET_MS = 300 e MAX_ERROR_RATE = 1.0; definir o orçamento como 100 ms diante de um P95 real de 180 ms termina com o código 1 e envia um alerta, portanto, a configuração funciona. O trabalho semanal de CI executa holdout_check.py com DEPLOYED = "pills-v2.pt" na versão privada de 300 imagens do conjunto de validação: linha de base de 0.69. O ensaio do turno da noite reduz esse valor em 0.05 e exibe a linha ALERT com o código de saída 1, o que faz o trabalho de CI falhar e notifica o canal. Doze exemplos de Monitoramento do turno da noite são enviados para pill-review por meio de Salvar no conjunto de dados, cada um marcado com deploymentId e europe-west1.

Próximos passos

Antes de aumentar a escala, defina onde seus dados ficam, quem pode vê-los e como você os excluiria: regiões e conformidade.

Entre para salvar seu progresso