Pipeline de ML, model registry e model serving são as três peças que transformam um modelo treinado em sistema que funciona todo dia: a esteira que prepara dados e treina, o catálogo que versiona os modelos com seus metadados, e a camada que entrega previsões para quem consome. Parecem detalhe de engenharia e são a maior parte do trabalho — o que um artigo clássico da NeurIPS estabeleceu em 2015 numa frase que virou referência: apenas uma pequena fração de um sistema real de aprendizado de máquina é composta pelo código de ML. Todo o resto é configuração, coleta de dados, extração de atributos, verificação, gerenciamento de recursos, infraestrutura de entrega, monitoramento e análise. O mesmo trabalho registra que é comum incorrer em custos massivos e contínuos de manutenção nesses sistemas.
⚠️ O “5%” que não existe
Uma nota de procedência, porque este é um caso exemplar de número que ganhou vida própria. Circula amplamente a afirmação de que “apenas 5% do código de um sistema de ML é o modelo, segundo Sculley et al.”.
Esse percentual não está no artigo. O texto diz “uma pequena fração”, e a figura que ilustra a ideia é um diagrama esquemático de caixas proporcionais — não uma medição. Alguém leu o desenho, estimou a proporção da caixa menor e publicou como dado; daí em diante virou citação.
O achado continua verdadeiro e continua útil sem o número inventado. E o próprio caso serve de aviso: quando um dado vier com atribuição acadêmica precisa e valor redondo, vale abrir a fonte.
As três peças, e o que cada uma resolve
- Pipeline de ML — a sequência automatizada que vai do dado bruto ao modelo treinado. Existe para que treinar de novo não dependa de alguém lembrar a ordem dos passos.
- Model registry — armazena centralmente os modelos treinados junto de seus metadados. Guarda duas coisas: o artefato e o registro de como ele foi produzido. É o que permite responder “qual versão estava no ar em março”.
- Model serving — a entrega das previsões, configurável para propósitos distintos: inferência em tempo real para resposta imediata, ou em lote para grandes volumes. Costuma ser exposta como API.
Note que a escolha entre tempo real e lote não é técnica — é a mesma decisão de latência e throughput, e ela determina o custo da operação.
O que isso muda na prática
A consequência mais direta para quem contrata: o difícil não é treinar o modelo — é operá-lo. Projetos de IA em marketing costumam ser orçados pelo esforço de construção e naufragam no custo de manutenção que ninguém previu.
Quatro perguntas que revelam se um fornecedor pensou nisso:
- Como o modelo é retreinado, e com que frequência? Se a resposta for “manualmente, quando alguém perceber que piorou”, o sistema vai envelhecer sem aviso — assunto de concept drift.
- Onde ficam as versões? Sem registro, não há como voltar atrás quando uma versão nova piora o resultado.
- O que é monitorado em produção? Não só se a API respondeu — se a qualidade da previsão se manteve.
- Quem é avisado quando degrada, e em quanto tempo? Modelo que erra em silêncio erra por meses.
Para uma equipe de marketing sem time dedicado de infraestrutura, isso costuma ser argumento a favor de usar API pronta em vez de manter modelo próprio — a conta está em inferência.
Fontes
- Hidden Technical Debt in Machine Learning Systems — Sculley et al., NeurIPS 2015
- Machine Learning Operations (MLOps): Overview, Definition, and Architecture — definições de registry e serving
Leitura das fontes em 17/08/2026.