MLOps para IoT: Monitorando Modelos de Machine Learning em Campo via MQTT

MLOps para IoT é a prática de implantar, monitorar e atualizar modelos de machine learning que rodam em dispositivos que você não consegue ver. Neste guia, você vai construir um ciclo de monitoramento leve: dispositivos de borda publicam métricas de inferência via MQTT, um serviço Python central mede o drift e modelos degradados disparam alertas em um topic dedicado.

Por que os modelos em campo se degradam

Um modelo que teve boa pontuação no laboratório começa a perder precisão no dia em que é implantado. Em IoT, os motivos são físicos e muitas vezes lentos:

• Envelhecimento e recalibração de sensores. Um sensor de vibração sofre deriva, a lente de uma câmera acumula poeira, um microfone passa a captar um ventilador novo.
• Mudanças de processo. Um material novo, uma escala de turnos diferente, uma nova variante de produto ou a passagem da safra para a entressafra em uma usina desloca a distribuição das entradas.
• Sazonalidade. A temperatura e a umidade ambiente alteram as linhas de base dos sensores ao longo dos meses.
• Divergência de implantação. A quantização ou um build de firmware diferente altera ligeiramente as saídas em relação ao modelo avaliado.

Em um serviço web, você pode registrar cada requisição e comparar as previsões com o feedback dos usuários. Em campo, geralmente não há rótulo algum, a banda é limitada e os dispositivos ficam offline. É por isso que o MLOps para IoT se apoia em sinais indiretos: estatísticas das entradas, distribuições das saídas, confiança e latência.

O que medir no dispositivo

Enviar janelas brutas de sensores para a nuvem a cada inferência anula o propósito da edge AI. Em vez disso, cada dispositivo agrega alguns números por intervalo e publica uma mensagem compacta de métricas.

Um payload de métricas pode ser assim:

{
  "device": "press-07",
  "model": "vib-classifier",
  "modelVersion": "1.4.2",
  "window": "2026-10-16T10:00:00Z/PT1M",
  "inferences": 600,
  "inputMean": {"rms": 0.42, "peakHz": 118.0},
  "inputStd": {"rms": 0.05, "peakHz": 6.1},
  "classCounts": {"normal": 588, "imbalance": 9, "bearing": 3},
  "confMean": 0.91,
  "confP10": 0.74,
  "latencyMsP95": 14.2
}

Design de topics para MLOps em IoT

Mantenha a telemetria dos modelos separada da telemetria do processo, para que dashboards e consumidores possam assinar com precisão:

connectmq/plant1/ml/<model>/<device>/metrics
connectmq/plant1/ml/<model>/<device>/status        (retained: version, loaded at)
connectmq/plant1/ml/<model>/alerts
connectmq/plant1/ml/<model>/<device>/cmd           (rollout or rollback commands)

Reter o topic de status significa que qualquer novo assinante descobre imediatamente qual versão do modelo cada dispositivo está rodando, que é a pergunta mais comum durante um incidente.

Publicando métricas a partir de um dispositivo de borda

O script abaixo simula um dispositivo de borda que roda um classificador e publica uma mensagem de métricas por intervalo. Em hardware real, você acumularia as estatísticas dentro do seu loop de inferência. Ele usa o servidor MQTT público broker.connectmq.com, adequado para testes e protótipos, não para dados de produção; substitua o prefixo pelo seu próprio ID aleatório.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/mlops-91bc/plant1/ml/vib-classifier"
DEVICE = "press-07"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"{DEVICE}-{uuid.uuid4().hex[:6]}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

status = {"modelVersion": "1.4.2", "loadedAt": time.time()}
client.publish(f"{PREFIX}/{DEVICE}/status", json.dumps(status), qos=1, retain=True)

drift = 0.0
while True:
    drift += 0.002  # slowly shift the input to simulate sensor aging
    rms = [random.gauss(0.42 + drift, 0.05) for _ in range(600)]
    conf = [min(1.0, max(0.0, random.gauss(0.91 - drift, 0.06))) for _ in range(600)]
    conf.sort()
    msg = {
        "device": DEVICE,
        "modelVersion": "1.4.2",
        "inferences": len(rms),
        "inputMean": {"rms": sum(rms) / len(rms)},
        "inputHist": {"rms": [sum(1 for v in rms if lo <= v < lo + 0.05)
                              for lo in [0.25 + 0.05 * i for i in range(10)]]},
        "confMean": sum(conf) / len(conf),
        "confP10": conf[len(conf) // 10],
        "ts": time.time(),
    }
    client.publish(f"{PREFIX}/{DEVICE}/metrics", json.dumps(msg), qos=1)
    time.sleep(10)

O histograma com bins fixos é o que torna o drift mensurável de forma centralizada sem enviar dados brutos.

Detectando drift de forma centralizada

O monitor assina todos os dispositivos, compara cada histograma recebido com um histograma de referência capturado na implantação e calcula o Population Stability Index (PSI). Uma regra prática comum considera PSI abaixo de 0,1 como estável, de 0,1 a 0,25 como digno de atenção e acima de 0,25 como uma mudança significativa, mas ajuste essas faixas com os seus próprios dados.

import json
import math
import uuid

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/mlops-91bc/plant1/ml/vib-classifier"
reference = {}  # device -> reference histogram
CONF_FLOOR = 0.70


def psi(expected, actual, eps=1e-4):
    e_total, a_total = sum(expected) or 1, sum(actual) or 1
    score = 0.0
    for e, a in zip(expected, actual):
        e_p = max(e / e_total, eps)
        a_p = max(a / a_total, eps)
        score += (a_p - e_p) * math.log(a_p / e_p)
    return score


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/metrics", qos=1)


def on_message(client, userdata, msg):
    m = json.loads(msg.payload)
    dev, hist = m["device"], m["inputHist"]["rms"]
    if dev not in reference:
        reference[dev] = hist
        print(f"reference captured for {dev}")
        return
    score = psi(reference[dev], hist)
    status = "ok"
    if score > 0.25 or m["confP10"] < CONF_FLOOR:
        status = "degraded"
    elif score > 0.1:
        status = "watch"
    print(f"{dev} psi={score:.3f} confP10={m['confP10']:.2f} -> {status}")
    if status != "ok":
        alert = {"device": dev, "modelVersion": m["modelVersion"],
                 "psi": round(score, 3), "confP10": round(m["confP10"], 3),
                 "status": status}
        client.publish(f"{PREFIX}/alerts", json.dumps(alert), qos=1)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"mlops-monitor-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Rode os dois scripts e você verá o status passar de ok para watch e depois para degraded à medida que o drift simulado se acumula. Em produção, o histograma de referência deve vir dos dados de validação usados para aprovar o modelo, armazenados junto com o artefato do modelo, e não da primeira mensagem após a inicialização.

Agindo sobre os alertas

Um alerta só é útil se alguém ou algo responder a ele. Opções, da mais simples à mais automatizada:

1. Notificar uma pessoa. Um fluxo Node-RED ou um pequeno serviço assina o topic de alertas e envia e-mails ou mensagens de chat.
2. Alertas visuais no portal do broker. Em um broker privado do ConnectMQ, você pode definir regras de alerta por limite em um campo numérico como psi e revisar as ocorrências no registro de alertas.
3. Coletar rótulos. Quando um dispositivo sofre drift, peça que ele envie algumas amostras brutas em um topic separado para que os engenheiros as rotulem e treinem o modelo novamente.
4. Fazer rollback. Publique um comando no topic cmd do dispositivo para carregar a versão anterior do modelo e depois confirme pelo topic de status retido.

O lado do rollout, ou seja, como os modelos chegam aos dispositivos, é abordado em implantação de modelos de ML em dispositivos de borda.

Rollouts canário e modelos sombra

O monitoramento diz quando um modelo se degrada; a disciplina de rollout impede que um modelo novo piore as coisas. Dois padrões funcionam bem com topics MQTT.

Rollout canário. Envie o novo modelo primeiro a um pequeno grupo de dispositivos, por exemplo cinco por cento da frota ou uma linha por fábrica. Como toda mensagem de métricas carrega modelVersion, o monitor pode comparar confiança, distribuição de classes e drift entre o grupo canário e o restante no mesmo período. Promova somente quando o canário parecer pelo menos tão saudável quanto o modelo em produção, e faça rollback pelo mesmo topic de comando se não parecer.

Modo sombra. Rode o novo modelo ao lado do atual no mesmo dispositivo, mas aja somente com base na saída do modelo atual. Publique as duas previsões na mensagem de métricas ou publique uma taxa de concordância contínua entre as duas. Um modelo sombra que discorda do modelo de produção em uma grande parcela das entradas merece uma análise mais cuidadosa antes de assumir, mesmo que os dois modelos pareçam confiantes.

Nenhum dos padrões exige do broker algo além de entrega confiável e topics claros. Eles também facilitam a análise pós-incidente: quando um alerta dispara, a primeira pergunta é se ele se correlaciona com uma mudança de versão, e os topics de status retidos respondem isso na hora.

Uma observação prática sobre banda: uma mensagem de métricas por minuto de cada dispositivo é minúscula, mas uploads de amostras brutas para rotulagem não são. Mantenha os uploads em um topic separado, dispare-os somente sob demanda e respeite o limite de tamanho de mensagem do seu plano.

Checklist de MLOps para IoT

1. Toda mensagem carrega o nome e a versão do modelo.
2. Os dispositivos publicam estatísticas agregadas das entradas, não dados brutos, em um intervalo fixo.
3. Uma distribuição de referência é armazenada com cada modelo lançado.
4. Os limites de drift e de confiança são documentados e revisados após cada incidente.
5. Os alertas vão para um topic, e pelo menos um consumidor os transforma em notificações para pessoas.
6. O rollback é um comando testado, não um plano.
7. Os dados para retreinamento são coletados de forma deliberada quando ocorre drift.
8. Em produção, métricas e alertas trafegam por TLS com credenciais por dispositivo.

Infraestrutura para monitoramento de toda a frota

Métricas de centenas de dispositivos, um monitor, dashboards e ferramentas de rollout compartilham um único barramento de mensagens. Operar esse barramento por conta própria significa aplicar patches, gerenciar certificados e planejar capacidade. Um broker MQTT gerenciado elimina esse trabalho, e um broker MQTT na nuvem é acessível a partir de dispositivos em qualquer rede. As shared subscriptions do plano Serverless pago permitem rodar várias instâncias do monitor que dividem a carga de métricas.

O mesmo fluxo de métricas também alimenta trabalhos específicos de modelos, como a manutenção preditiva com machine learning, e as verificações de drift são parentes próximas da detecção de anomalias em IoT: uma observa a máquina, a outra observa o modelo. Para o panorama completo de IA na borda e na nuvem, veja o guia de IA e IoT.

Monitore os seus modelos em campo com o ConnectMQ

Crie um broker privado no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, aponte os seus dispositivos para ele com as credenciais geradas na porta 8883 e veja as métricas dos modelos chegando no explorador de topics ao vivo. Adicionar o monitor de drift é só rodar o script acima com um username e uma senha.

Perguntas frequentes

Em que o MLOps para IoT difere do MLOps tradicional?

Dispositivos em campo raramente têm rótulos, têm banda limitada e podem ficar offline, então o monitoramento se baseia em estatísticas agregadas de entradas e saídas em vez de logs por requisição. A implantação e o rollback também precisam funcionar em conexões pouco confiáveis.

Com que frequência os dispositivos devem publicar métricas do modelo?

Uma vez por minuto ou a cada algumas centenas de inferências é um bom ponto de partida. É frequente o bastante para detectar drift em poucas horas e pequeno o bastante para ficar bem dentro dos limites de taxa de mensagens.

Qual métrica de drift devo usar?

O Population Stability Index e os testes de Kolmogorov-Smirnov são comuns para as entradas, e acompanhar a confiança de percentil baixo detecta muitos problemas nas saídas. Use mais de um sinal, já que cada um deixa passar alguns modos de falha.

O broker pode detectar drift por mim?

Não. O broker transporta as métricas; a detecção de drift roda no seu próprio serviço, que as assina. As regras de alerta por limite no portal do ConnectMQ podem sinalizar limites numéricos simples assim que o seu serviço publicar uma pontuação de drift.