Versionamento, CI/CD e rollback para IA generativa

O post sobre deploy de modelos, lá na série de julho, cobriu a parte de colocar um modelo no ar — infraestrutura de serving, latência, custo por request. O que ficou de fora, de propósito, foi o que acontece depois do primeiro deploy: como você libera uma nova versão do modelo, do prompt ou do pipeline de RAG sem quebrar o que já está funcionando em produção. Esse é o território do MLOps aplicado a IA generativa, e ele tem particularidades que CI/CD de software tradicional não cobre.

O que "versão" significa quando o sistema não é só código

Num sistema de IA generativa, uma "versão" não é só um commit. É a combinação de modelo (ou checkpoint de fine-tuning), prompt, parâmetros de inferência (temperatura, top-p) e, se houver RAG, a versão do índice de embeddings. Mudar qualquer um desses quatro elementos isoladamente já muda o comportamento do sistema. Pipelines de release que versionam só o código e ignoram esses outros três componentes perdem rastreabilidade exatamente quando mais precisam dela — quando algo quebra e ninguém sabe qual mudança causou.

Testes automatizados não são opcionais, mas são diferentes

CI tradicional roda testes determinísticos: mesma entrada, mesma saída esperada. Sistemas de IA generativa não funcionam assim — a mesma entrada pode gerar respostas diferentes entre execuções. O pipeline de CI para esses sistemas precisa rodar o golden dataset (veja o post sobre avaliação de LLMs) a cada mudança e comparar a métrica agregada, não a resposta exata. Uma queda na métrica bloqueia o deploy automaticamente, do mesmo jeito que um teste unitário falho bloquearia um deploy de software tradicional.

Canary release para modelos

Antes de rotear 100% do tráfego para uma nova versão de modelo ou prompt, vale liberar para uma fração pequena e comparar métricas de qualidade e custo contra a versão atual, em produção real, não só no golden dataset. Isso pega problemas que só aparecem com distribuição real de tráfego — picos de latência sob carga, padrões de uso que o dataset de teste não cobria. O canary não precisa ser sofisticado: mesmo rotear 5% do tráfego por algumas horas antes de promover já evita boa parte dos incidentes de release.

Rollback tem que ser mais rápido que o incidente

Quando uma nova versão do modelo começa a produzir respostas ruins em produção, o tempo entre detectar o problema e reverter para a versão anterior é o que determina o tamanho do estrago. Isso exige duas coisas: monitoramento que detecta degradação de qualidade em tempo real (não só erros de infraestrutura, mas queda em métricas de qualidade de resposta) e um mecanismo de rollback que não depende de re-treinar ou reconfigurar nada — só trocar qual versão está ativa, de forma tão simples quanto reverter um deploy de código.

O que isso muda na prática do dia a dia

Times que tratam release de modelo com o mesmo rigor de release de código — versionamento explícito de todos os componentes, testes automatizados via golden dataset, canary antes de promover, rollback de um clique — evoluem seus sistemas de IA com muito mais velocidade e muito menos susto. Times que não fazem isso acabam com medo de mexer no sistema depois que ele está em produção, porque cada mudança é uma aposta sem rede de segurança. E sistema que ninguém tem coragem de mudar é sistema que para de melhorar.