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

Colocar machine learning em produção exige mais do que publicar uma API: é necessário controlar dados, código, modelos, infraestrutura, métricas e resposta a incidentes como partes de um único sistema. O SLA contratual deve refletir aquilo que a arquitetura e a operação conseguem medir e sustentar, separando disponibilidade técnica, latência, qualidade preditiva e atualização do modelo.

Por que um bom protótipo ainda não é um produto

Um notebook pode demonstrar que existe sinal preditivo nos dados, mas normalmente não responde às perguntas essenciais de produção: como reproduzir o treinamento, validar novas versões, detectar dados anômalos, reverter uma implantação ou manter o serviço durante uma falha externa?

A passagem do protótipo para produção muda o critério de sucesso. Durante a experimentação, métricas como F1-score, precisão, recall, MAE ou AUC costumam dominar a análise. Em produção, o modelo passa a integrar um sistema que também precisa cumprir requisitos como:

• disponibilidade e latência;
• capacidade de processamento;
• segurança e privacidade;
• rastreabilidade das previsões;
• custo por inferência;
• recuperação após falhas;
• qualidade e atualidade dos dados;
• processo seguro de atualização.

Um modelo com excelente AUC pode ser inadequado se levar três segundos para responder a uma operação que exige 200 milissegundos. Da mesma forma, uma API com 99,9% de disponibilidade pode entregar previsões inúteis caso a distribuição dos dados tenha mudado silenciosamente.

O que MLOps precisa controlar

MLOps aplica práticas de engenharia, automação e observabilidade ao ciclo de vida de machine learning. O objetivo não é instalar uma ferramenta específica, mas tornar cada versão reproduzível, testável, implantável e auditável.

Versionamento completo

Versionar apenas o arquivo do modelo não basta. Uma versão reproduzível deve ligar, no mínimo:

1. código de preparação e treinamento;
2. referência ou versão do conjunto de dados;
3. parâmetros e hiperparâmetros;
4. ambiente e dependências;
5. métricas de validação;
6. artefato gerado;
7. regras de transformação das features;
8. autor, data e aprovação da execução.

Esse vínculo permite responder qual código e quais dados produziram uma previsão. Para casos regulados ou decisões de alto impacto, também é importante registrar a entrada, a saída, a versão do modelo e as regras posteriores aplicadas — respeitando requisitos de privacidade e retenção.

Pipeline de integração e entrega

O pipeline de CI/CD para ML deve testar software e comportamento estatístico. Uma sequência prática inclui:

• testes unitários das transformações;
• validação de esquema, tipos e faixas dos dados;
• detecção de features ausentes ou inesperadas;
• teste de treinamento em amostra controlada;
• comparação com o modelo de referência;
• análise de vulnerabilidades e dependências;
• criação de imagem ou pacote imutável;
• implantação em homologação;
• testes de carga, integração e segurança;
• aprovação automática ou humana antes da produção.

Uma nova versão não deve ser promovida apenas porque superou o modelo anterior em uma métrica. Ela pode aumentar falsos negativos, piorar um segmento específico ou exigir mais infraestrutura. O critério de promoção precisa combinar limites estatísticos, requisitos técnicos e impacto de negócio.

Arquitetura de inferência: online, assíncrona ou em lote

A escolha do modo de inferência afeta diretamente custo, latência e SLA.

Inferência online

É indicada quando a resposta precisa voltar durante a interação, como classificação de uma solicitação ou recomendação em tempo real. Exige API disponível, escalabilidade, timeouts, circuit breakers e estratégia para indisponibilidade.

O orçamento de latência deve considerar todo o caminho: autenticação, busca de features, pré-processamento, inferência, pós-processamento e rede. Se o SLA define 500 ms, não é seguro reservar os 500 ms apenas para o modelo.

Processamento assíncrono

É adequado quando o pedido pode entrar em uma fila e ser processado depois. Filas desacoplam produtores e consumidores, absorvem picos e facilitam novas tentativas. Em contrapartida, exigem idempotência, controle de mensagens duplicadas, dead-letter queue e métricas de atraso.

Inferência em lote

Funciona bem para previsões periódicas, como pontuação diária de uma carteira. Costuma ser mais econômica, mas seu compromisso operacional deve ser expresso como janela de conclusão: por exemplo, “95% dos registros processados até determinado horário”, e não como latência por requisição.

Do SLI ao SLA contratual

Um SLA não deve nascer de uma porcentagem escolhida comercialmente. Primeiro são definidos os indicadores mensuráveis, depois os objetivos internos e, por fim, o compromisso contratual.

• SLI: indicador observado, como percentual de respostas válidas em até 500 ms.
• SLO: objetivo operacional interno para esse indicador.
• SLA: compromisso formal, incluindo escopo, exclusões, forma de medição e consequências do descumprimento.

Se o serviço promete 99,9% de disponibilidade mensal, o limite teórico de indisponibilidade é de aproximadamente 43 minutos em um mês de 30 dias. Em 99,5%, são cerca de 3 horas e 36 minutos. Essa diferença altera arquitetura, plantão, redundância e custo.

SLIs relevantes para machine learning

Um contrato pode combinar diferentes dimensões, mas elas não devem ser misturadas em um único número:

• Disponibilidade: proporção de requisições elegíveis atendidas com sucesso.
• Latência: percentis p50, p95 e p99, não apenas média.
• Freshness: idade máxima dos dados ou das features.
• Throughput: volume sustentado por segundo ou por janela.
• Conclusão de lote: percentual concluído dentro do prazo.
• Taxa de erro: falhas técnicas, timeouts e respostas inválidas.
• Recuperação: RTO para restabelecimento e RPO para perda tolerável de dados.

Qualidade preditiva merece tratamento separado. Em muitos contextos, o rótulo real chega dias ou meses depois, impedindo garantia instantânea de precisão. Nesse caso, o contrato pode definir frequência de avaliação, janela amostral, métricas, população analisada e gatilhos de revisão, sem prometer uma acurácia permanente que a mudança do mundo torna impossível assegurar.

Observabilidade para dados, modelos e serviço

Monitorar CPU, memória e erros HTTP cobre apenas a infraestrutura. Uma operação de ML precisa de quatro camadas de observabilidade.

Serviço

Acompanhe disponibilidade, latência por percentil, taxa de erro, saturação, filas, timeouts e custo. As métricas devem ser segmentadas por versão do modelo e tipo de requisição.

Dados

Monitore schema, valores ausentes, cardinalidade, faixas, categorias desconhecidas e atraso de atualização. Uma quebra de contrato de dados deve interromper o pipeline ou direcionar registros para tratamento, em vez de contaminar silenciosamente o modelo.

Modelo

Avalie distribuição das previsões, confiança, drift de features e drift da saída. Quando os rótulos estiverem disponíveis, calcule desempenho real por período e por segmentos relevantes. Drift não prova degradação, mas indica necessidade de investigação.

Negócio

A métrica técnica deve ser ligada ao resultado operacional. Um classificador pode manter o F1-score e ainda perder valor se o custo de uma ação mudar ou se a equipe não conseguir tratar o volume de alertas. Taxa de adoção, alertas aproveitados e resultado por decisão ajudam a revelar essa diferença.

Estratégias de implantação e rollback

Substituir 100% do tráfego de uma vez aumenta o risco. As estratégias mais usadas são:

• Shadow: a nova versão recebe cópia do tráfego, mas não influencia a decisão.
• Canary: uma pequena parcela das requisições usa o novo modelo.
• Blue-green: dois ambientes completos permitem troca e retorno rápidos.
• Champion-challenger: o modelo atual é comparado continuamente a candidatos.

O rollback precisa ser testado, não apenas documentado. Isso inclui restaurar o artefato anterior, as transformações compatíveis e a configuração de roteamento. Quando há mudança de schema, a reversão pode falhar mesmo que o arquivo antigo ainda exista.

Também deve haver um modo degradado. Dependendo do risco, a indisponibilidade pode acionar uma regra determinística, uma resposta em cache, processamento manual ou fila para execução posterior. Em decisões críticas, retornar uma previsão sem dados confiáveis pode ser pior do que declarar indisponibilidade.

Checklist antes de assumir um SLA

Antes de assinar um compromisso de produção, verifique:

• [ ] carga de pico e sazonalidade foram testadas;
• [ ] SLIs têm fórmula, fonte e janela de medição definidas;
• [ ] dependências externas e exclusões contratuais estão explícitas;
• [ ] alertas possuem responsável e procedimento de resposta;
• [ ] RTO e RPO são compatíveis com backups e arquitetura;
• [ ] rollback foi executado em ambiente realista;
• [ ] dados, código, features e modelos estão versionados;
• [ ] logs permitem rastrear uma previsão sem exposição indevida;
• [ ] drift e desempenho por segmento são monitorados;
• [ ] existe orçamento de erro para mudanças planejadas;
• [ ] custos foram testados no volume contratado;
• [ ] segurança, retenção e acesso seguem o risco dos dados.

Um SLA sustentável deve ser inferior ou igual à capacidade comprovada do sistema, deixando margem entre o objetivo interno e o compromisso externo. Se o SLO interno for idêntico ao SLA, qualquer desvio elimina a margem de operação.

Como a Predictor Solutions resolve isso

A Predictor Solutions estrutura projetos de machine learning como sistemas de produção, combinando engenharia de dados, inteligência artificial aplicada, cloud/DevOps, segurança e desenvolvimento sob medida. O trabalho cobre pipelines reproduzíveis, APIs e processamento em lote, observabilidade, implantação gradual, rollback e definição de SLIs, SLOs e SLAs alinhados ao risco operacional.

Essa experiência também aparece em produtos próprios: o Predictor Health trabalha com dashboards de saúde e wearables, enquanto o Predictor AI Hospitals aplica predição de sepse, infarto e pneumonia em UTI. Em sistemas de saúde, a empresa também atua com integrações HL7 v2 e FHIR, nas quais rastreabilidade, qualidade dos dados e interoperabilidade fazem parte da confiabilidade do modelo.

Nos projetos realizados, a Predictor Solutions atendeu 9 empresas de médio e grande porte, com resultados informados de R$ 1,32 milhão de economia média por cliente ao ano, aumento médio de 70% de produtividade e crescimento de lucro de 43% em seis meses. Esses números não substituem a definição de métricas específicas para cada novo projeto; servem como histórico operacional para orientar metas verificáveis.

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