Machine learning em produção: do protótipo ao SLA contratual com MLOps

Um protótipo de machine learning só está pronto para produção quando se torna um serviço observável, reproduzível, seguro e operável sob falhas. MLOps conecta dados, modelos, infraestrutura e governança para converter métricas experimentais em SLOs mensuráveis e, quando necessário, em um SLA contratual com responsabilidades e consequências explícitas.

Por que uma boa métrica no notebook não basta

Um experimento normalmente pressupõe dados disponíveis, ambiente controlado e avaliação sobre uma base estática. Em produção, o modelo passa a depender de APIs, bancos, pipelines, permissões, infraestrutura, comportamento dos usuários e mudanças no processo que gera os dados.

Um classificador com F1-score de 0,92 pode falhar operacionalmente se:

• a API ultrapassar o tempo máximo de resposta;
• atributos chegarem nulos ou com unidades diferentes;
• houver diferença entre a transformação usada no treino e na inferência;
• o perfil da população mudar;
• a versão do modelo não puder ser rastreada;
• uma atualização impedir rollback;
• previsões forem armazenadas sem os controles exigidos pela LGPD.

Portanto, existem pelo menos três dimensões separadas de qualidade:

1. Qualidade preditiva: precisão, recall, F1, AUC, MAE, RMSE ou outra métrica compatível com o problema.
2. Qualidade operacional: disponibilidade, latência, taxa de erros, throughput e tempo de recuperação.
3. Qualidade de governança: rastreabilidade, segurança, explicabilidade, aprovação e retenção de evidências.

A passagem para produção exige critérios mínimos nas três dimensões, não apenas na primeira.

De requisitos de negócio a SLOs mensuráveis

Antes de escolher ferramentas, a equipe deve identificar qual decisão o modelo apoia, quanto custa um erro e em quanto tempo a resposta precisa estar disponível. Isso determina arquitetura, métricas e nível de operação.

SLA, SLO e SLI não são sinônimos

• SLI, ou Service Level Indicator: medição observada, como a proporção de requisições respondidas em até 300 ms.
• SLO, ou Service Level Objective: meta interna, como manter 99,9% das inferências dentro desse limite.
• SLA, ou Service Level Agreement: compromisso contratual, incluindo escopo, método de medição, exceções e possíveis compensações.

O SLO interno deve ser mais rigoroso que o SLA. Se o contrato promete 99,5% de disponibilidade, operar exatamente nessa fronteira elimina a margem para incidentes, manutenção e erros de medição.

A disponibilidade mensal pode ser calculada como:

requisições válidas atendidas / total de requisições válidas

O contrato precisa esclarecer o que é uma requisição válida, quais janelas são excluídas e se a medição ocorre no gateway, no serviço de inferência ou na aplicação do cliente.

Nem toda métrica de modelo deve virar SLA

Latência e disponibilidade podem ser medidas imediatamente. Já recall, precisão e taxa de falsos negativos dependem de rótulos verdadeiros, que frequentemente chegam dias ou meses depois. Além disso, podem variar quando a população ou o processo operacional muda.

Nesses casos, uma estrutura mais segura separa:

• SLA do serviço online;
• SLO de qualidade dos dados de entrada;
• avaliação periódica do desempenho preditivo;
• gatilhos para investigação, recalibração ou retreino;
• responsabilidade pelo fornecimento de rótulos confiáveis.

Em saúde, fraude ou manutenção preditiva, essa distinção evita garantir uma métrica impossível de verificar em tempo real.

Arquitetura mínima de MLOps para produção

Não existe uma pilha universal, mas os componentes devem cumprir funções claras:

1. Versionamento: código, dados ou referências imutáveis, configuração, dependências e artefatos do modelo.
2. Rastreamento de experimentos: parâmetros, métricas, base de avaliação e origem de cada execução.
3. Pipeline de dados: validação de esquema, tipos, faixas, cardinalidade e tratamento de valores ausentes.
4. Registro de modelos: estágio, proprietário, aprovação, métricas e vínculo com o código de treinamento.
5. CI/CD/CT: testes, empacotamento, implantação e, quando aplicável, treinamento contínuo controlado.
6. Serving: inferência em lote, síncrona ou assíncrona, conforme latência e volume.
7. Observabilidade: logs, métricas, traces, qualidade de dados, drift e desempenho posterior.
8. Gestão de incidentes: alertas acionáveis, runbooks, responsáveis e mecanismo de rollback.

Uma feature store pode reduzir inconsistências entre treino e inferência, mas adiciona custo operacional. Ela faz sentido quando várias equipes reutilizam atributos, há computação complexa ou é necessário servir features online com baixa latência. Para um único modelo em lote, transformações versionadas no próprio pipeline podem ser suficientes.

Pipeline do protótipo à implantação

1. Reproduzir o treinamento

O treinamento deve rodar fora do notebook por um comando ou pipeline determinístico. A execução precisa registrar versão do código, configuração, período dos dados, semente aleatória quando aplicável, dependências e hash do artefato.

Contêineres ajudam na portabilidade, mas não garantem reprodutibilidade dos dados. É necessário preservar snapshots, partições imutáveis ou consultas com critérios temporais documentados.

2. Criar uma suíte de testes

Uma pipeline de ML deve combinar diferentes testes:

• unitários para transformações e regras de negócio;
• contrato para schemas de entrada e saída;
• integração para bancos, filas e APIs;
• qualidade de dados para nulos, faixas e categorias;
• regressão preditiva contra um modelo de referência;
• carga para latência, throughput e consumo de recursos;
• segurança para autenticação, autorização e dependências vulneráveis.

O modelo candidato não deve ser promovido apenas porque supera uma métrica. Ele também precisa respeitar limites de tamanho, custo, latência e degradação em segmentos relevantes.

3. Definir gates de promoção

Um gate de produção pode exigir, por exemplo:

• nenhuma quebra de contrato de dados;
• métrica principal superior ao baseline definido;
• ausência de degradação acima do limite nos segmentos críticos;
• latência p95 dentro do orçamento;
• artefato assinado e registrado;
• aprovação humana para casos de alto impacto;
• rollback testado.

Os valores devem vir do risco e do processo de negócio. Não há justificativa técnica para adotar 0,80 de F1-score ou 200 ms de latência como números universais.

4. Liberar progressivamente

Implantações blue-green, canary e shadow reduzem o risco de substituição direta. Em shadow, o modelo novo recebe uma cópia do tráfego sem influenciar a decisão. Em canary, atende uma fração controlada e pode ser comparado ao modelo atual.

A reversão deve considerar modelo, código de pré-processamento e schema. Voltar apenas o arquivo do modelo pode preservar a incompatibilidade que causou o incidente.

Monitoramento que detecta falhas úteis

Monitorar CPU e memória não revela se o modelo perdeu validade. A observabilidade precisa cobrir quatro camadas:

• Serviço: disponibilidade, latências p50, p95 e p99, erros, filas e saturação.
• Dados: volume, frescor, nulos, faixas, categorias desconhecidas e violações de schema.
• Predições: distribuição das saídas, confiança, taxa de abstenção e concentração por segmento.
• Desempenho real: métricas calculadas quando os rótulos verdadeiros estiverem disponíveis.

Drift não significa automaticamente perda de desempenho. Uma mudança na distribuição pode ser legítima, enquanto a relação entre atributos e resultado permanece estável. O alerta deve iniciar diagnóstico, não necessariamente retreino automático.

Alertas também precisam ser acionáveis. Cada um deve indicar severidade, proprietário, runbook, dados para diagnóstico e condição de encerramento. Sem isso, a equipe acumula alarmes ignorados e reduz a capacidade de responder a incidentes reais.

Error budget, incidentes e capacidade operacional

Se o SLO mensal é 99,9%, o error budget é 0,1% do período ou das requisições, conforme a definição adotada. Esse orçamento orienta decisões: enquanto o consumo está controlado, a equipe pode acelerar mudanças; quando está próximo do limite, deve priorizar confiabilidade.

O plano operacional precisa responder:

• Quem recebe o alerta fora do horário comercial?
• Qual é o tempo de reconhecimento e de restauração esperado?
• Existe fallback por regra, modelo anterior ou revisão humana?
• Como decisões afetadas serão identificadas e corrigidas?
• Quais evidências serão preservadas para auditoria?

Em sistemas de alto impacto, indisponibilidade e previsão incorreta são incidentes diferentes. Cada categoria exige severidade, comunicação e procedimento próprios.

Checklist para um SLA contratual de ML

Antes da assinatura, valide se o documento define:

• serviço, endpoint, regiões e horários cobertos;
• disponibilidade e latência por percentis, não somente pela média;
• origem oficial das medições;
• volume e padrão de carga previstos;
• limites, exclusões e manutenções programadas;
• qualidade e formato dos dados fornecidos pelo cliente;
• frequência de avaliação preditiva e atraso dos rótulos;
• processo de mudança, aprovação e versionamento;
• RTO para restauração e RPO quando houver estado persistente;
• segurança, privacidade, retenção e resposta a incidentes;
• suporte, escalonamento e compensações;
• critérios para encerramento ou renegociação.

O principal trade-off é econômico: elevar disponibilidade, reduzir latência e manter atendimento contínuo exige redundância, capacidade ociosa e operação especializada. O SLA deve refletir o impacto real da falha, evitando tanto subdimensionamento quanto infraestrutura desnecessária.

Como a Predictor Solutions resolve isso

A Predictor Solutions estrutura projetos de ML desde a engenharia de dados até serving, observabilidade, cloud/DevOps e segurança ofensiva. Em aplicações de saúde, trabalha também com integrações HL7 v2 e FHIR; seus produtos Predictor Health e Predictor AI Hospitals aplicam essa base a dashboards, wearables e modelos voltados à predição de sepse, infarto e pneumonia em UTI.

A execução começa pela definição de decisão, risco, baseline e SLOs. Depois são implementados pipelines reproduzíveis, testes, registro de modelos, implantação progressiva, monitoramento e runbooks compatíveis com o SLA. A empresa, sediada em Lavras, Minas Gerais, já atendeu 9 organizações de médio e grande porte; os resultados consolidados informados incluem economia média de R$ 1,32 milhão por cliente ao ano, aumento médio de 70% na produtividade e crescimento de lucro de 43% em seis meses.

Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246