Colocar machine learning em produção exige transformar um modelo experimental em um serviço observável, reproduzível, seguro e operável sob falhas. O SLA contratual deve cobrir não apenas disponibilidade e latência, mas também qualidade dos dados, comportamento preditivo, atualização, rollback e responsabilidades entre fornecedor e cliente.
Por que um bom protótipo pode falhar em produção
Um notebook comprova que determinado padrão pode ser aprendido com uma amostra de dados. Ele não demonstra, sozinho, que a solução continuará funcionando com tráfego real, mudanças de comportamento, integrações instáveis e restrições de custo.
Os principais motivos de falha são:
- Diferença entre treino e produção: campos, escalas, categorias ou regras de preenchimento mudam.
- Data drift: a distribuição das entradas se afasta da distribuição usada no treinamento.
- Concept drift: a relação entre entradas e resultado muda, mesmo que os dados pareçam semelhantes.
- Training-serving skew: a transformação aplicada durante o treino difere daquela executada na inferência.
- Dependências externas: APIs, bancos de dados, filas ou sistemas legados ficam lentos ou indisponíveis.
- Ausência de rollback: um modelo novo substitui o anterior sem caminho rápido de reversão.
- Métrica inadequada: a equipe melhora acurácia média, mas ignora falsos negativos, calibração ou desempenho por segmento.
- Falta de ownership: ninguém sabe quem deve agir quando a qualidade degrada fora do horário comercial.
A passagem para produção é, portanto, um problema de engenharia de sistemas. O modelo é somente um dos componentes.
SLI, SLO e SLA para serviços de machine learning
Os três conceitos devem ser separados no projeto e no contrato:
- SLI, ou Service Level Indicator: medida observada, como disponibilidade mensal ou latência p95.
- SLO, ou Service Level Objective: objetivo interno para o indicador.
- SLA, ou Service Level Agreement: compromisso contratual, incluindo escopo, exclusões, suporte e consequências do descumprimento.
Um SLO interno deve ser mais rigoroso que o SLA. Se o contrato exige 99,5% de disponibilidade, por exemplo, operar com objetivo interno idêntico elimina a margem necessária para manutenção e incidentes.
A disponibilidade pode ser calculada como:
disponibilidade = requisições válidas atendidas / requisições válidas recebidas
Essa definição costuma ser mais útil para APIs do que considerar apenas o tempo em que um processo permaneceu ligado. Um serviço pode estar ativo e, ainda assim, retornar erros ou previsões inutilizáveis.
Indicadores que podem compor o contrato
| Dimensão | SLI possível | Critério que precisa ser definido |
|---|---|---|
| Disponibilidade | Percentual de requisições válidas atendidas | Janela mensal, regiões e exclusões |
| Latência | p95 ou p99 do tempo de resposta | Endpoint, carga e tamanho da entrada |
| Erros | Taxa de respostas 5xx e timeouts | O que conta como erro do fornecedor |
| Dados | Percentual de registros válidos | Schema, campos obrigatórios e tolerâncias |
| Predição | Precisão, recall, F1, MAE ou calibração | População, limiar e janela de avaliação |
| Atualização | Prazo para implantar ou reverter modelo | Aprovação, testes e disponibilidade de dados |
| Incidente | Tempo de reconhecimento e recuperação | Severidade e horário de cobertura |
Valores como 99,9% de disponibilidade ou latência p95 abaixo de 300 ms podem servir como exemplos de desenho, mas não devem ser copiados sem teste de carga e análise do processo. Quanto maior a exigência, maior tende a ser o custo de redundância, plantão, capacidade ociosa e observabilidade.
Do notebook ao serviço operacional
A evolução deve ocorrer por estágios com critérios objetivos de saída.
1. Tornar o experimento reproduzível
O primeiro passo é retirar regras críticas do notebook e convertê-las em código versionado. O pacote deve registrar:
- versão do código, dados e hiperparâmetros;
- ambiente e dependências;
- seed e condições de execução;
- métricas globais e por segmento relevante;
- artefato resultante e sua assinatura;
- origem e período da base de treinamento.
Reexecutar o pipeline com as mesmas entradas deve produzir resultado equivalente dentro de uma tolerância documentada.
2. Criar testes além da acurácia
Uma esteira de integração contínua deve validar código, dados e comportamento do modelo. O conjunto mínimo inclui:
- testes unitários das transformações;
- validação de schema e faixas permitidas;
- teste de compatibilidade entre produtor e consumidor;
- comparação com um modelo baseline;
- teste de desempenho por subgrupo;
- verificação de latência, memória e tamanho do artefato;
- varredura de dependências e segredos;
- teste de carga e falhas de serviços externos.
O modelo candidato só deve avançar se superar critérios previamente definidos. Aprovação baseada apenas em “parece melhor” não é auditável.
3. Separar implantação de liberação
Implantar um artefato não significa enviar imediatamente todo o tráfego para ele. Estratégias seguras incluem:
- shadow: o novo modelo recebe uma cópia do tráfego, mas sua resposta não afeta o usuário;
- canary: uma pequena parcela das solicitações usa a nova versão;
- blue-green: dois ambientes completos permitem troca e reversão rápida;
- champion-challenger: o modelo atual é comparado continuamente com candidatos.
O rollback deve ser automatizado e acionável por erro, latência ou degradação de métrica. Se restaurar a versão anterior exige reconstrução manual, a organização ainda não possui um processo confiável de release.
Observabilidade em quatro camadas
Monitorar CPU e memória não revela se uma predição continua útil. Uma operação de MLOps precisa observar quatro camadas relacionadas.
Infraestrutura e aplicação
Acompanhe disponibilidade, saturação, uso de memória, filas, erros, timeouts, latência p50, p95 e p99. Logs devem conter identificadores de correlação, versão do modelo e resultado da validação da entrada, sem expor dados pessoais desnecessários.
Qualidade dos dados
Monitore campos ausentes, categorias inéditas, cardinalidade, duplicidade, atraso, faixas inválidas e alterações de schema. Contratos de dados ajudam a impedir que uma mudança silenciosa em um sistema de origem chegue ao modelo.
Comportamento estatístico
Compare distribuições de produção e treinamento com métricas adequadas ao tipo de variável. PSI, distância de Jensen-Shannon e Kolmogorov-Smirnov podem sinalizar drift, mas seus limites precisam ser calibrados para o contexto; um alerta estatístico não prova perda de qualidade.
Resultado de negócio e qualidade preditiva
Quando os rótulos chegam depois de horas, dias ou meses, métricas de qualidade serão necessariamente atrasadas. A arquitetura deve ligar cada predição ao desfecho observado para recalcular recall, precisão, erro, calibração e indicadores do processo.
Em saúde, fraude e risco, a média global pode esconder falhas graves. É necessário avaliar coortes, períodos, unidades de operação e classes de maior impacto, respeitando privacidade e governança.
Retreinamento não deve ser automático por padrão
Retreinar semanalmente não garante melhoria. Dados recentes podem estar incompletos, contaminados por incidentes ou refletir um evento temporário.
Um gatilho responsável combina:
- volume mínimo de novos exemplos rotulados;
- sinal persistente de drift ou degradação;
- validação contra baseline e modelo vigente;
- testes por segmento e análise de regressões;
- aprovação automática ou humana conforme o risco;
- implantação gradual com rollback.
Casos de baixo risco e alto volume admitem automação mais ampla. Decisões clínicas, financeiras ou com impacto legal normalmente exigem trilha de auditoria e aprovação humana mais rígida.
O que precisa estar no SLA contratual
Um SLA de ML deve evitar expressões vagas como “alta precisão” ou “resposta rápida”. O documento precisa especificar:
- endpoints, ambientes, regiões e horários cobertos;
- fórmula, fonte e janela de cada indicador;
- volume esperado, picos e limites de requisição;
- versões de schema e responsabilidades sobre os dados;
- métrica preditiva, população avaliada e prazo de chegada do rótulo;
- severidades de incidente e canais de comunicação;
- tempo para reconhecimento, mitigação e recuperação;
- política de manutenção, atualização e depreciação;
- retenção de logs, auditoria e tratamento de dados pessoais;
- RTO e RPO quando houver estado ou processamento em lote;
- exclusões, como falha de origem externa ou entrada fora do contrato;
- créditos, penalidades ou demais consequências acordadas.
A qualidade preditiva não deve ser prometida sem controlar a qualidade e a representatividade dos dados enviados pelo cliente. Uma solução prática é separar o SLA técnico, mensurável em tempo real, de objetivos de qualidade avaliados em janelas compatíveis com a disponibilidade dos rótulos.
Checklist para entrada em produção
Antes da liberação, confirme:
- [ ] código, dados, configuração e artefato estão versionados;
- [ ] existe registro de modelo com metadados e aprovação;
- [ ] treino e inferência compartilham transformações consistentes;
- [ ] schemas e contratos de dados são validados;
- [ ] testes funcionais, de carga, segurança e regressão passaram;
- [ ] dashboards cobrem aplicação, dados, modelo e negócio;
- [ ] alertas possuem limiar, responsável e procedimento de resposta;
- [ ] canary, shadow ou estratégia equivalente foi definida;
- [ ] rollback foi executado em teste, não apenas documentado;
- [ ] RTO, RPO, SLI, SLO e SLA foram aprovados;
- [ ] custos por mil inferências ou por lote são acompanhados;
- [ ] runbooks e escalonamento de incidentes estão acessíveis.
Como a Predictor Solutions resolve isso
A Predictor Solutions estrutura projetos de IA aplicada com engenharia de dados, APIs, cloud/DevOps, segurança e observabilidade, levando o modelo do experimento até uma operação mensurável. Em sistemas de saúde, também trabalha com integrações HL7 v2 e FHIR, contexto no qual contratos de dados, rastreabilidade e tolerância a falhas são particularmente relevantes.
A execução começa pela definição das métricas técnicas e de negócio, segue para pipelines reproduzíveis, testes, registro de artefatos, implantação gradual, monitoramento e runbooks. O SLA é desenhado a partir da carga, criticidade, dependências e disponibilidade dos rótulos, em vez de aplicar percentuais genéricos.
A empresa, sediada em Lavras, Minas Gerais, já atendeu 9 organizações de médio e grande porte. No conjunto de projetos informado pela Predictor Solutions, os resultados incluem economia média de R$ 1,32 milhão por cliente ao ano, aumento médio de 70% na produtividade e crescimento de 43% no lucro em seis meses; esses números abrangem seu portfólio e não substituem a definição de indicadores específicos para cada projeto de MLOps.
Contato: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.