MLOps

Objetivos de aprendizagem #

• O1. Versionar dado, código e modelo de forma que um resultado seja reproduzível meses depois.
• O2. Implantar um modelo atrás de uma API com contrato e validação de entrada.
• O3. Distinguir drift de covariáveis de drift de conceito e detectar cada um.
• O4. Projetar um plano de rollback antes do deploy, e não durante o incidente.

O problema: aprovado na validação, reprovado em produção #

O modelo passou na validação. Foi para produção. Três semanas depois, o desempenho medido no mundo real é bem pior que o do relatório — e ninguém consegue explicar.

A tentação é reabrir o modelo. É quase sempre o lugar errado de procurar. A causa costuma não estar no modelo: está em dois intervalos que ninguém mediu. O intervalo entre treinar e servir — onde o atributo calculado de um jeito no notebook é calculado de outro jeito na API, o mesmo vazamento do capítulo 02 reaparecendo com outro nome. E o intervalo entre servir hoje e servir daqui a três meses — onde o mundo muda e o modelo não sabe disso.

Este capítulo é a sequência direta do capítulo 15: lá, o diagnóstico de que o sistema é maior que o modelo; aqui, o procedimento para operá-lo.

De onde isto veio #

O aperto. Times de ML entregando modelos como quem entrega um relatório — a mão, um arquivo por vez — e descobrindo que o artefato entregue apodrece sozinho. 📖

O que se fazia antes. Entrega manual; retreino por calendário ou, na prática, por reclamação: alguém do negócio nota que "está estranho" e o time retreina. ⏳

A virada. Aplicar entrega contínua a um artefato que muda em três eixos, não em um: código, modelo e dado. É a tese declarada de Sato, Wider & Windheuser em "Continuous Delivery for Machine Learning" (martinfowler.com, 2019) ✓ᵐ — e a razão de o pipeline de entrega contínua tradicional não bastar. Um pipeline que só reage a commit não vê dois dos três eixos.

A ideia reaproveitável. O que muda sozinho precisa ser testado sozinho. Software comum se degrada quando alguém edita; modelo se degrada quando ninguém edita. A inversão é o coração do capítulo: se a degradação não é disparada por uma ação humana, nenhum gatilho humano vai detectá-la. 📖

O nome que ninguém cunhou #

Aqui está o achado mais desconfortável do capítulo — e ele é sobre o próprio nome da disciplina.

A versão repetida em dezenas de fontes de indústria é que "MLOps foi cunhado no artigo de 2015 de Sculley et al.". Extraímos o texto integral do artigo e buscamos: a palavra "MLOps" não aparece nenhuma vez. Também não aparecem "feature store" nem "training/serving skew". Selo ✓ — é uma verificação negativa feita sobre o texto primário, e verificação negativa é das mais fortes que existem: não depende de interpretação, só de leitura.

A filiação a DevOps, essa sim, está documentada: "The first devopsdays was held in Ghent, Belgium in 2009", com Patrick Debois listado como fundador na página oficial ✓ᵃ. Já a história de a abreviação "#devops" ter nascido da necessidade de caber numa hashtag de Twitter é ⏳ — consistente entre fontes secundárias, sem primária.

A leitura (📖): este é o sexto caso do padrão "crédito segue o vocabulário" que atravessa o livro — e o mais extremo. Nos cinco anteriores (Gauss × Legendre no cap. 05, Linnainmaa × Rumelhart no 18, Harris × Firth no 03, o double descent no 01 e o k-means com seis pretendentes no 08), o crédito foi para a pessoa errada.

Aqui o campo não tinha um autor para o nome e fabricou um retroativamente, escolhendo o artigo mais citado da vizinhança. E a atribuição sobreviveu apesar de ser falsificável em trinta segundos por quem tivesse o PDF aberto e uma busca de texto.

Concept drift tem nome desde 1986. Schlimmer & Granger publicam naquele ano dois trabalhos: "Beyond Incremental Processing: Tracking Concept Drift" (AAAI-86 — o termo está no título) e "Incremental learning from noisy data" (Machine Learning 1(3):317–354). O survey que organizou o campo é o de Gama, Žliobaitė, Bifet, Pechenizkiy & Bouchachia (ACM Computing Surveys 46(4), art. 44, 2014) ✓ᵐ. De 1986 a 2014: vinte e oito anos entre o nome e a síntese.

E o procedimento veio rápido. The ML Test Score — Breck, Cai, Nielsen, Salib & Sculley, IEEE Big Data 2017 — traz 28 testes e necessidades de monitoramento pontuados ✓ᵐ. Repare no subtítulo: "…and Technical Debt Reduction". É explicitamente a continuação do capítulo 15: mesmo autor sênior, dois anos depois, transformando o diagnóstico em checklist. Diagnóstico (2015) → procedimento (2017): dois anos. Compare com as décadas do resto do livro — quando o diagnóstico é preciso e já existe infraestrutura, o procedimento chega rápido. É o mesmo fio dos capítulos 07 e 12.

Procedência das afirmações desta seção:

Fundamentos: versionar, registrar, servir #

Versionar o quê. Reproduzir um resultado meses depois exige cinco coisas, não uma: código, dado, modelo, configuração (hiperparâmetros, limiar, regras de negócio) e ambiente (versões de biblioteca). Faltando qualquer uma, o número do relatório não volta. Dado costuma ser versionado por hash de conteúdo, não por cópia — o que se guarda é a impressão digital que prova qual dado foi usado.

Registro de modelos e linhagem. Um registro de modelos responde a três perguntas em segundos: qual versão está em produção, de qual dado e de qual código ela saiu, e quem a promoveu. A pergunta da linhagem é a que salva auditoria e incidente. Um modelo sem linhagem é um binário anônimo: você pode desligá-lo, mas não pode explicá-lo.

Servir. Três formas, escolhidas pelo requisito e não pelo gosto:

A escolha manda no resto da arquitetura. Batch tolera atributo caro; online não — se calcular o atributo custa 800 ms, o modelo online já perdeu, por mais preciso que seja.

Monitorar em três camadas #

Monitoramento de ML não é um painel: são três painéis, com donos e tempos diferentes.

1. Saúde do serviço — taxa de erro, latência, disponibilidade. Quebra em segundos e é a camada que todo time já sabe montar.
2. Qualidade do dado de entrada — esquema, faixas, proporção de nulos, cardinalidade de categóricas. Quebra em horas e é a que mais pega falha real, porque a maior parte dos incidentes de ML é um campo que mudou de unidade ou passou a chegar vazio (ver capítulo 20).
3. Desempenho do modelo — a métrica do capítulo 04. E aqui está a dificuldade central: ela só pode ser calculada quando o rótulo chega, o que pode levar semanas ou meses.

Os três tipos de drift. Drift de dados (ou de covariáveis): a distribuição da entrada muda — chegam clientes de outro perfil. Drift de conceito: a relação entre entrada e saída muda — o mesmo perfil de cliente passa a se comportar de outro jeito. Drift de rótulo: a distribuição da saída muda — a fraude que era 0,3% da base virou 2%.

O drift é exatamente a quebra da hipótese que o capítulo 01 coloca na fundação: treino e produção vindo da mesma distribuição. Nada no modelo protege contra isso, porque a hipótese é anterior ao modelo.

Detectar sem rótulo. Enquanto o rótulo não chega, sobra o que não depende dele: comparar a distribuição da entrada de hoje com a de referência (a janela de treino), atributo a atributo, e comparar a distribuição da saída — o histograma das probabilidades previstas. Se o modelo começa a prever positivo com o dobro da frequência de antes, algo mudou, mesmo que ninguém ainda saiba se ele está certo. É um alarme, não um veredito: drift de entrada não implica queda de desempenho, e queda de desempenho pode acontecer sem drift visível na entrada.

Retreinar e implantar sem quebrar #

Retreino por gatilho ou por calendário? Por gatilho — quando o monitoramento acusa drift ou queda de métrica — é a resposta certa quando existe monitoramento confiável e o rótulo chega em tempo útil. Por calendário é o padrão honesto quando não existe: um retreino mensal é uma aposta, mas é melhor que esperar a reclamação. Os dois exigem a mesma coisa: o retreino precisa ser um pipeline que roda sozinho, não um notebook que alguém reabre.

E vale a regra que o capítulo 25 impõe: retreinar não é a única resposta. Se o que mudou foi o custo do erro, recalcule o limiar; o modelo pode continuar o mesmo.

Implantação segura. Três instrumentos, do mais barato ao mais caro:

• Sombra: o modelo novo recebe o tráfego real e responde, mas a resposta é descartada — serve só para comparar com a do modelo atual. Risco zero para o usuário.
• Canário: uma fatia pequena do tráfego real vai para o novo. Aqui o usuário já é afetado, então há critério de parada definido antes.
• Reverter: voltar à versão anterior em minutos, sem retreinar nada. Só é possível se a versão anterior continua registrada e servível.

O plano de rollback é o item que quase todo time escreve durante o incidente, quando já é tarde. Escreva antes: qual métrica dispara a volta, qual é o limite, quem tem autoridade para acionar e quanto tempo leva. Um plano que depende de retreinar não é plano de rollback — é um segundo incidente.

Síntese — o que levar #

• A falha em produção quase nunca está no modelo. Está entre treinar e servir, e entre servir hoje e servir em três meses.
• O que muda sozinho precisa ser testado sozinho. Software se degrada quando alguém edita; modelo se degrada quando ninguém edita.
• A aplicação muda em três eixos — código, modelo e dado. Pipeline que só reage a commit enxerga um terço do problema.
• Reprodutibilidade exige cinco versionamentos: código, dado, modelo, configuração e ambiente.
• Linhagem é a pergunta que salva auditoria: de qual dado e de qual código saiu este artefato?
• Monitore em três camadas: serviço, dado de entrada, desempenho. A terceira só existe quando o rótulo chega.
• Sem rótulo, monitore distribuição de entrada e de saída. Isso é alarme, não veredito.
• Drift de dados ≠ drift de conceito ≠ drift de rótulo. O que muda é diferente, e a resposta também.
• Escreva o plano de rollback antes do deploy. Sombra, canário e reverter — nessa ordem de custo.
• E o nome da disciplina não foi cunhado onde todo mundo diz. Atribuição repetida não é atribuição verificada.

Verificação #

1. Um colega propõe versionar apenas o código e o modelo, porque "o dado é grande demais". Que pergunta ele deixa de conseguir responder — e como o hash de conteúdo resolve isso sem copiar o dado?
2. O painel mostra drift claro na distribuição de duas entradas, mas a métrica de desempenho medida sobre os rótulos que já chegaram está estável. Retreinar ou não? Justifique usando a diferença entre drift de covariáveis e drift de conceito.
3. Descreva o plano de rollback do último sistema em que você trabalhou — métrica de disparo, limite, responsável e tempo de execução. Se algum dos quatro não existir, diga o que aconteceria no incidente.