MLOps: versionamento, CI/CD/CT, serving, data drift × concept drift, feature store

A ideia que organiza o assunto

Esta nota é escrita sobre a evidência mais fina do corpus, e isso precisa vir antes de qualquer afirmação. O tópico tem dois itens. Os dois são Certos. Não há um único item Errado aqui — portanto não há distorção medida, não há frequência, não há percentual, e nenhuma frase desta nota deve ser lida como “a banca costuma”. O título promete versionamento, CI/CD/CT, serving, data drift × concept drift e feature store; a medição sobre os 16.161 itens do corpus diz o seguinte:

• drift — zero ocorrências, em enunciado ou comando, no corpus inteiro;
• feature store — zero;
• serving, no sentido de servir modelo — zero;
• CI/CD — oito itens, todos em tópicos de DevOps, GitLab, Kubernetes e infraestrutura como código, nenhum sobre esteira de modelo;
• versionamento — quatro itens, nenhum sobre ativo de aprendizado de máquina;
• MLOps — dois itens: um deles é o item 63 deste tópico; o outro está classificado em BI e é o único item Errado de sabor MLOps do corpus.

Ou seja: três das cinco promessas do título do tópico não são testadas por item nenhum. Elas continuam nesta nota porque são o núcleo da disciplina e podem cair a qualquer prova, mas cada uma vem marcada como não medida. É o mesmo cuidado que se aplicou a um tópico de rodada anterior que anunciava drift e não tinha item algum sobre isso.

A ideia que organiza o assunto é uma só, e ela deriva tudo o mais: MLOps é DevOps acrescido de duas coisas que software comum não tem. A primeira é que o artefato depende de dados: o mesmo código, treinado sobre outra extração, produz outro modelo — então reproduzir um resultado exige versionar dado, código, configuração, modelo e ambiente, e não apenas o código. A segunda é que o modelo se degrada sem que ninguém mude nada: o mundo muda debaixo dele, e um sistema que ninguém tocou piora sozinho — então monitorar em produção e retreinar não são manutenção corretiva, são parte do ciclo normal. Do primeiro ponto sai a reprodutibilidade e a auditabilidade; do segundo, o monitoramento e o retreinamento contínuo. Os dois itens medidos são exatamente uma face de cada um.

Por que se usa (e o que custa)

Ganha-se a passagem do experimento para o serviço: o modelo que existia em um caderno na máquina de um analista passa a ter esteira, registro, versão, responsável e caminho de volta. Ganha-se sobretudo rastreabilidade — poder dizer, meses depois, com qual recorte de dados, qual código e quais hiperparâmetros aquele modelo que negou um pedido foi treinado. Em ambiente regulado, essa é a diferença entre um modelo utilizável e um modelo indefensável.

Paga-se em três moedas. Infraestrutura e disciplina: esteira, repositório de artefatos, registro de modelos e monitoramento são sistemas a manter, e cada etapa automatizada é uma etapa a testar. Armazenamento: versionar dados significa guardar recortes, não só o último estado — o custo cresce com o histórico. Risco de automação: automatizar o retreinamento sem validar a entrada automatiza também o erro; um lote de dados corrompido vira, sem supervisão, um modelo pior promovido à produção. Por isso a promoção de versão mantém porta de validação, e por isso monitorar não é opcional em quem automatizou.

Como funciona

O ciclo, ponta a ponta. Ingestão dos dados → validação e pré-processamento → engenharia de atributos → treinamento → avaliação e validação do modelo → registro do modelo → implantação → monitoramento → (novo) retreinamento. É sequência e é laço: o monitoramento realimenta a ingestão. O item medido deste tópico descreve exatamente esse percurso, “da ingestão de dados até a implantação”, incluindo pré-processamento, treinamento e validação — e é Certo por descrever o ciclo inteiro sem excluir etapa nenhuma.

O que se versiona. Não é o código apenas. São cinco famílias de ativo: o dado (o recorte usado no treino), o código (preparação e treinamento), a configuração (hiperparâmetros, sementes aleatórias, parâmetros da esteira), o modelo (o artefato treinado, com suas métricas) e o ambiente (dependências, imagem, versões de biblioteca). Versionar os cinco é o que entrega as duas propriedades que o item medido nomeia: reprodutibilidade — repetir o treino e obter o mesmo modelo — e auditabilidade — demonstrar depois o que foi feito e com o quê. O registro de modelos é o catálogo desses artefatos com estágio (em avaliação, em produção, aposentado), métricas e linhagem de origem.

CI, CD e CT. A integração contínua, aqui, testa mais do que código: valida esquema e qualidade dos dados, executa o treino em amostra, verifica métricas mínimas e compara com o modelo em produção. A entrega contínua publica a esteira e o modelo, não só o binário da aplicação. O CT — treinamento contínuo é a peça que não existe em DevOps: o retreinamento disparado por agenda, por chegada de dado novo ou por degradação observada. Quem trata CT como sinônimo do segundo C perdeu justamente o que distingue a disciplina. (Não medido: nenhum item do corpus cobra a sigla CT.)

Serving — como o modelo é consumido. (Não medido.) Em lote, as predições são calculadas periodicamente e gravadas para consulta posterior — latência alta, custo baixo, bom para escore de carteira inteira. Online ou síncrono, o modelo responde por API a cada requisição — latência de milissegundos, infraestrutura sempre ativa. Em fluxo, consome eventos continuamente. Embarcado, roda no dispositivo, sem rede. As estratégias de implantação são as mesmas do DevOps — canary, blue-green, shadow (o modelo novo recebe o tráfego real e não responde ao usuário), teste A/B.

Monitoramento e desvio. (Não medido quanto ao vocabulário do desvio.) Monitoram-se três camadas distintas: a operacional (latência, erro, uso de recurso), a de qualidade das entradas (esquema, nulos, faixas) e a de desempenho do modelo (métricas contra o rótulo verdadeiro, que costuma chegar com atraso). Quando o rótulo demora, observa-se a distribuição no lugar do acerto — e é aí que entram os dois desvios: data drift, quando muda a distribuição das entradas mas a relação entre entrada e saída continua válida; e concept drift, quando muda a própria relação, e o modelo fica errado mesmo recebendo entradas familiares. A distinção importa porque a resposta é diferente: o primeiro pode pedir apenas recalibração ou nova amostra; o segundo exige retreinar contra a realidade nova, e às vezes remodelar.

Feature store. (Não medido.) Repositório central de atributos já calculados e versionados, servindo dois consumidores com a mesma definição: o treinamento, que precisa do valor como era na data do evento, e a inferência, que precisa do valor atual com baixa latência. Sua razão de existir é eliminar a divergência entre o atributo calculado no treino e o calculado na produção — o desvio treino-serviço — e evitar que a mesma regra seja reescrita em cada projeto.

O que decide os itens

Os cinco ativos do versionamento — e o que cada um garante:

ativo	sem ele, perde-se
dado (recorte de treino)	reprodutibilidade: o mesmo código dá outro modelo
código	rastreio da transformação e do treino
configuração (hiperparâmetros, semente)	repetição exata do experimento
modelo registrado (artefato + métricas)	saber o que está em produção e desde quando
ambiente (dependências, imagem)	repetição fora da máquina original

CI × CD × CT:

	dispara	entrega
CI — integração contínua	mudança em código, dado ou configuração	testes de código, de dados e de modelo aprovados
CD — entrega contínua	artefato aprovado	esteira e modelo implantados
CT — treinamento contínuo	agenda, dado novo ou degradação observada	modelo retreinado, candidato à promoção

DevOps × MLOps — o que muda de verdade:

	DevOps	MLOps
artefato	código compilado	código mais dado mais modelo
teste	unitário, integração, aceitação	acrescenta validação de dados e de métricas do modelo
degradação	só com mudança no código ou no ambiente	ocorre sem mudança alguma, por mudança do mundo
ciclo	integrar, entregar, operar	acrescenta treinar continuamente e monitorar desempenho

Data drift × concept drift (não medido):

	data drift	concept drift
o que muda	a distribuição das entradas	a relação entre entrada e saída
o modelo	continua válido, mas opera fora do domínio visto	fica errado sobre entradas familiares
sintoma	distribuição de entrada se desloca	métrica cai quando o rótulo chega
resposta	nova amostra, recalibração, retreino	retreino obrigatório, possível remodelagem

Monitoramento — o que não pode faltar. É o único ponto deste tópico com evidência de item Errado no corpus, ainda que classificado em outro tópico: restringir o monitoramento em produção a métricas técnicas como latência, e tratar a detecção de viés como preocupação restrita ao desenvolvimento, é Errado. Produção monitora as três camadas — operação, dados e desempenho — e o viés é uma delas.

Como a CEBRASPE derruba você aqui

A medição terminou — os dois itens do tópico estão explicados — e tem um resultado incômodo que deve ser dito: dos dois itens do tópico, nenhum é Errado. Não existe, neste tópico, uma única distorção medida. Qualquer afirmação sobre “como a banca derruba você aqui” seria extrapolação — e esta nota não a fará.

O que os dois itens Certos mostram é a forma que a banca deu ao assunto até agora: descrição ampla, sóbria e sem exclusividade. Um percorre o ciclo “da ingestão de dados até a implantação” e lista pré-processamento, treinamento e validação, sem dizer que são só esses nem que a ordem é rígida. O outro diz que o controle de versão “abrange o monitoramento das mudanças nos ativos de aprendizado de máquina” com vistas à reprodutibilidade e à auditabilidade — de novo, abrangente e sem restrição. Frase que enumera etapas e finalidades, sem palavra de exclusão, tende a ser Certa; o erro costuma morar na palavra que restringe. Com dois casos, isso é hipótese, não regra.

A única evidência de item Errado disponível em MLOps está fora deste tópico, classificada em BI, e confirma essa leitura pelo avesso: ela restringe — o monitoramento em produção que “deve centrar-se nas métricas de desempenho técnico como a latência”, com a detecção de viés algorítmico como “preocupação restrita à fase de desenvolvimento do modelo”. O item descreve atividades reais e erra ao amputá-las. Quando aparecer um item deste tópico com apenas, somente, restrito a, basta, é ali que a decisão está.

Não medido, registrado por conhecimento do assunto. Três confusões são as candidatas óbvias de qualquer prova sobre MLOps, e nenhuma delas caiu ainda: trocar data drift por concept drift; tratar CT como se fosse o segundo C de CI/CD; e supor que versionar o código basta para reproduzir um treinamento. Estude-as como conteúdo, não como padrão da banca — porque, neste tópico, padrão da banca ainda não existe.

Erros clássicos

Achar que MLOps é DevOps com outro nome. Duas diferenças bastam para desmontar a equivalência: o artefato inclui dado, e o sistema piora sozinho. Qualquer item que descreva MLOps sem uma das duas está descrevendo DevOps.

Supor que um modelo em produção só falha se alguém mexer nele. Ele falha porque o mundo mudou. É a razão de o monitoramento e o retreinamento serem parte do ciclo, e não uma resposta a incidente.

Confundir data drift com concept drift. Entradas novas × relação nova. Se a pergunta é sobre o que o modelo recebe, é data; se é sobre o que o modelo deveria responder, é concept.

Achar que reprodutibilidade se resolve versionando o código. Sem o recorte de dados, sem a semente e sem o ambiente, o mesmo código produz outro modelo — e “outro modelo” é justamente o que a auditoria não pode ouvir.

Reduzir monitoramento a latência e disponibilidade. Isso é monitoramento de serviço. Modelo se monitora por distribuição de entrada, por métrica de desempenho quando o rótulo chega e por comportamento entre grupos.

Tratar o registro de modelos como repositório de código. Um guarda versões de texto-fonte; o outro guarda artefatos treinados com métricas, estágio e origem — e é ele que responde “o que está em produção agora”.

Automatizar o retreinamento sem porta de validação. Retreino automático que promove qualquer modelo novo entrega à produção o resultado do primeiro lote ruim de dados. Automatizar sem monitorar é automatizar o erro.