Observability

A observabilidade é a capacidade de compreender o que acontece dentro de um sistema de software a partir da telemetria que este emite, sobretudo registos, métricas e rastreios, de modo a responder a novas perguntas sobre o seu comportamento sem implementar código novo. O termo vem da teoria de controlo, onde Rudolf Kálmán definiu, em 1960, que um sistema é observável se for possível determinar o seu estado interno a partir das suas saídas. As equipas de software adotaram o conceito na década de 2010, quando os sistemas se dividiram em muitos serviços e as falhas deixaram de corresponder aos painéis criados antecipadamente. Nos sistemas de aprendizagem automática, a observabilidade também abrange os dados e as previsões: que entradas recebe um modelo, que saídas produz, qual é o seu grau de confiança e como ambos mudam ao longo do tempo.

Registos, métricas e rastreios#

Três tipos de telemetria, muitas vezes chamados pilares da observabilidade, respondem a perguntas diferentes:

• Métricas: Séries temporais numéricas, como a taxa de pedidos, a taxa de erros, os percentis de latência, a memória e a utilização de GPU; são económicas de armazenar e adequadas a painéis e alertas. O livro de engenharia de fiabilidade de sites da Google identifica quatro sinais de ouro a medir em cada serviço: latência, tráfego, erros e saturação.
• Registos: Registos de eventos individuais com carimbo temporal, mais úteis quando estruturados em JSON com campos como o ID do pedido, a versão do modelo e o tamanho da entrada, para poderem ser filtrados e contabilizados.
• Rastreios: O percurso de um pedido por todos os serviços que atravessa, registado como uma árvore de intervalos, cada um com um nome, hora de início, duração e atributos, que mostra onde o pedido demorou mais tempo.

O OpenTelemetry, criado em 2019 através da fusão dos projetos OpenTracing e OpenCensus, fornece APIs, SDKs e um protocolo de transmissão independentes de fornecedores (OTLP) para os três sinais; backends como Prometheus, Grafana e Jaeger armazenam-nos e apresentam-nos. Este exemplo rastreia um pedido de classificação de imagem com o SDK OpenTelemetry para Python, registando um intervalo principal para o pedido e um intervalo subordinado para cada etapa:

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

Num CPU Apple M5 Pro, apresenta um intervalo preprocess de 1,0 a 1,4 ms e um intervalo inference de 7 a 9 ms, ambos com predict como elemento principal, e um intervalo predict de 8 a 10 ms; assim, o rastreio atribui a maior parte do tempo do pedido ao modelo. Quando os intervalos são exportados por OTLP, cada serviço que processa um pedido acrescenta intervalos com o mesmo ID de rastreio, e um backend como o Jaeger apresenta-os numa única linha temporal.

Observabilidade vs. monitoramento#

A monitorização de modelos acompanha modos de falha conhecidos com métricas, painéis e limiares de alerta predefinidos, como uma taxa de erros superior a 1% ou uma latência de inferência acima do objetivo. A observabilidade é a propriedade mais abrangente que permite investigar falhas imprevistas, analisando a telemetria detalhada posteriormente por cliente, versão do modelo, câmara ou qualquer outro atributo. O livro Google SRE propõe que a monitorização responda a duas perguntas — o que está avariado e porquê — e uma investigação avança da primeira resposta para a segunda recorrendo aos três sinais:

A IA explicável é uma área distinta que explica por que razão um modelo produziu determinada saída com base nas características de entrada ou nas ativações internas; as atribuições resultantes podem ser registadas como mais um sinal.

Observabilidade para aprendizagem automática#

Os sistemas de aprendizagem automática falham muitas vezes sem dar sinais: um modelo de visão computacional pode responder a todos os pedidos com HTTP 200 enquanto as suas previsões se degradam porque a câmara foi deslocada, a iluminação mudou ou surgiu um produto novo. Por isso, a observabilidade de ML acrescenta telemetria sobre dados e previsões aos sinais de serviço habituais. As equipas registam estatísticas de entrada, como o tamanho e o brilho das imagens, para detetar desvio de dados, acompanham distribuições de previsões, como contagens por classe, resultados vazios e confiança média, e calculam a precisão por segmento quando chegam os rótulos de referência, muitas vezes dias mais tarde. Durante o treino, os callbacks enviam curvas de perda, métricas e utilização do sistema de cada execução para ferramentas de acompanhamento de experiências, como o TensorBoard e o MLflow. Nas aplicações de agentes de IA e modelos de linguagem de grande escala, os rastreios registam cada instrução, etapa de recuperação, chamada de ferramenta e resposta; as convenções semânticas GenAI do OpenTelemetry padronizam atributos como gen_ai.usage.input_tokens, para que as contagens de tokens e os custos sejam consistentes entre ferramentas.

Todos os endpoints dedicados da Ultralytics Platform incluem monitorização da implementação: cartões com a contagem de pedidos, a taxa de erros e a latência p95; um separador Logs com níveis de gravidade e um filtro Errors para entradas de erro e aviso; e estatísticas das previsões que mostram as principais classes, a confiança média ao longo do tempo, as previsões por imagem e o tempo de inferência do modelo, separado da latência dos pedidos. Uma curva de confiança descendente ou uma alteração nas principais classes surge nesses gráficos mesmo que todos os pedidos sejam bem-sucedidos.