MLOps em 2026: MLflow, Model Registry e Perguntas de Entrevista Técnica

As perguntas de entrevista de MLOps deixaram de ser uma especialidade de nicho para se tornarem parte central das contratações em ciência de dados e engenharia de machine learning em 2026. As equipes não perguntam mais apenas como um modelo é treinado; elas investigam como ele é rastreado, versionado, implantado e monitorado quando o tráfego real chega até ele. Este guia percorre as perguntas recorrentes em entrevistas de MLOps, agrupadas por etapa do ciclo de vida, com exemplos de MLflow que espelham configurações de produção.

Perguntas de Entrevista de MLOps sobre o Ciclo de Vida de Machine Learning

Q1: O que é MLOps e como ele difere do DevOps?

O MLOps aplica princípios de DevOps como automação, CI/CD e monitoramento a sistemas de machine learning e, então, acrescenta três preocupações que o software tradicional não tem: versionamento de dados, versionamento de modelos e validação contínua contra distribuições de dados reais. No DevOps clássico, o código é o único artefato que muda. No MLOps, código, dados e o modelo treinado versionam de forma independente, e qualquer um dos três pode degradar silenciosamente a qualidade da saída sem que uma única linha de código mude. O frequentemente citado artigo Hidden Technical Debt in Machine Learning Systems destaca que o código do modelo é uma pequena fração de um sistema de ML real, com pipelines de dados, monitoramento e configuração dominando a maior parte da superfície.

Q2: Percorra as etapas de um ciclo de vida de ML em produção.

Uma boa resposta nomeia cinco etapas e o artefato que cada uma produz: ingestão e validação de dados (um dataset versionado), experimentação (runs rastreados com métricas), registro do modelo (um modelo versionado e promovível), deploy (um endpoint de serving ou um job em batch) e monitoramento (telemetria de drift e desempenho que realimenta o retreinamento). Os entrevistadores prestam atenção ao ciclo de feedback: o monitoramento precisa se conectar de volta à experimentação, caso contrário o sistema é um pipeline de mão única que apodrece com o tempo.

Rastreamento de Experimentos com um Exemplo de Tutorial de MLflow

O rastreamento de experimentos é a base sobre a qual a maioria das perguntas de MLOps se apoia, então uma resposta em estilo de tutorial de MLflow que mostra logging real tem peso. O MLflow registra parâmetros, métricas e artefatos por run, o que torna qualquer resultado reprodutível a partir do seu run ID.

Q3: Como o rastreamento do MLflow captura um experimento, e por que o run ID importa?

Cada chamada a mlflow.start_run() abre um run que registra hiperparâmetros, métricas e o modelo serializado. O run ID é o identificador imutável que amarra uma métrica ao código, aos parâmetros e ao snapshot de dados exatos que a produziram, e é isso que torna um experimento reprodutível meses depois.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

O argumento name substitui o artifact_path, agora descontinuado, no MLflow 3.x, uma mudança que vale mencionar para demonstrar familiaridade com a API atual. Candidatos que fazem referência ao rastreamento de features e datasets por meio de padrões de validação de pipeline de ML tendem a pontuar mais, porque a reprodutibilidade depende de todo o pipeline, não apenas do modelo.

Model Registry 2026: Versionamento e Promoção

O MLflow Model Registry transforma o artefato de um run em um objeto governado e promovível. A maior mudança recente, e um alvo frequente de perguntas em entrevistas de 2026, é o abandono dos stages nomeados.

Q4: Como o MLflow Model Registry promove um modelo, e o que mudou em 2026?

Versões anteriores do MLflow promoviam modelos por meio de stages fixos chamados Staging, Production e Archived. O MLflow 3.x descontinua esses stages em favor de aliases e tags, porque uma lista de stages fixa no código não conseguia expressar topologias reais de deploy como champion, challenger ou shadow. Um alias é um ponteiro mutável para uma versão, então a promoção passa a ser reatribuir o alias em vez de alterar o modelo.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

Como os consumidores carregam models:/churn-classifier@champion, um rollback é uma única reatribuição de alias para uma versão anterior, sem redeploy. A documentação oficial do MLflow Model Registry aborda em profundidade a governança de aliases e os gatilhos por webhook.

Padrões de Deploy de Machine Learning e Serving

Perguntas sobre deploy separam candidatos que já colocaram modelos em produção daqueles que apenas os treinaram. A escolha do padrão segue o orçamento de latência, não a preferência pessoal.

Q5: Compare os padrões de deploy de machine learning em batch, online e streaming.

| Padrão | Latência | Caso de uso típico | Superfície de serving | |---------|---------|------------------|-----------------| | Batch | De horas a diária | Score de churn, atualização de recomendações | Job agendado gravando em uma tabela | | Online (tempo real) | Dezenas de milissegundos | Verificação de fraude, ranqueamento no momento da requisição | Endpoint REST ou gRPC | | Streaming | Subsegundo, contínuo | Detecção de anomalias em fluxos de eventos | Consumidor em uma fila de mensagens |

A pergunta seguinte quase sempre indaga como servir o caso online. Um modelo MLflow empacota seu próprio ambiente, então servi-lo é um único comando apontando para uma URI do registry.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: Como os deploys blue-green e canary reduzem o risco no rollout de um modelo?

O blue-green mantém dois ambientes idênticos e comuta todo o tráfego de uma vez depois que o novo modelo passa nas verificações, oferecendo um caminho de rollback instantâneo. O canary direciona uma pequena porcentagem do tráfego para a nova versão, observa métricas em tempo real e então aumenta a proporção gradualmente. Para modelos, o canary costuma ser mais seguro porque problemas de qualidade do modelo só aparecem diante de entradas reais, e um canary limita o raio de impacto a uma fração dos usuários.

Testes e CI/CD para Pipelines de Machine Learning

Q7: O que o CI/CD testa em um pipeline de ML que um pipeline de software convencional não testa?

Um pipeline de CI de software roda testes unitários e de integração no código. Um pipeline de ML adiciona testes de dados e de modelo por cima: validação de schema nos dados de entrada, verificações de distribuição para que um treinamento não ingira silenciosamente features corrompidas e um portão de qualidade do modelo que reprova o build quando um candidato pontua abaixo do champion atual em um conjunto de holdout fixo. A entrega contínua para ML, portanto, promove um artefato de modelo, não apenas uma imagem de container, e o portão de promoção é um limiar de métrica, não apenas uma suíte de testes verde. Um pipeline rigoroso também fixa snapshots de dados e versões de dependências para que qualquer reexecução seja determinística, o que é o que separa um build reprodutível de um que apenas por acaso passa hoje.

Monitoramento, Data Drift e Retreinamento de Modelos

Um modelo em produção se degrada à medida que o mundo muda sob ele, então as perguntas sobre monitoramento são onde o sinal de senioridade aparece.

Q8: Como o data drift é detectado, e qual métrica o quantifica?

Data drift significa que a distribuição das entradas em produção se afastou da distribuição de treinamento. O Population Stability Index (PSI) é uma medida comum e agnóstica a framework: ele divide uma distribuição de referência em bins, compara as frequências de produção contra esses bins e soma as diferenças logarítmicas ponderadas.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

Além de uma métrica implementada à mão, as equipes de produção recorrem a ferramentas como o Evidently para acompanhar drift de features, drift de target e qualidade de dados de forma agendada. Uma resposta completa distingue data drift (as entradas mudam) de concept drift (a relação entrada-saída muda), porque o segundo não pode ser detectado apenas observando as entradas e exige resultados rotulados.

Q9: O que deve disparar um pipeline de retreinamento?

O retreinamento baseado em tempo, em uma cadência fixa, é a opção mais simples, mas desperdiça computação quando nada mudou e reage lentamente quando algo quebra. Gatilhos melhores são baseados em métricas: retreinar quando o PSI ultrapassa um limiar, quando uma métrica de avaliação em tempo real cai abaixo de um piso ou quando um backtest agendado sobre dados recém-rotulados regride. O job de retreinamento então registra um challenger, que um rollout canary compara com o champion atual antes que qualquer alias seja reatribuído.

Perguntas de Entrevista de System Design de MLOps

Q10: Projete uma plataforma que sirva centenas de modelos com features consistentes.

A peça central esperada é um feature store, que resolve o training-serving skew ao calcular as features uma única vez e servir os valores idênticos tanto ao treinamento quanto à inferência. Ferramentas como o Feast oferecem um store offline para treinamento e um store online de baixa latência para serving. Um design completo também nomeia um model registry para versionamento, um tracking server para linhagem, um orquestrador para pipelines e uma camada de monitoramento que fecha o ciclo de volta ao retreinamento. Fundamentar a resposta em trabalho real com features, como os tradeoffs abordados neste guia de entrevista sobre feature engineering, sinaliza experiência prática em vez de memorização de diagramas.

Conclusão

• Enquadre o MLOps como DevOps somado ao versionamento de dados e de modelos: reprodutibilidade, segurança na promoção e monitoramento são os três eixos que os entrevistadores avaliam
• Conheça a mudança de API do MLflow 3.x: aliases e tags substituem os stages descontinuados Staging e Production, e log_model agora recebe name em vez de artifact_path
• Ajuste o padrão de deploy ao orçamento de latência e prefira canary a blue-green nos rollouts de modelos, porque problemas de qualidade só aparecem diante de entradas reais
• Quantifique o drift com uma métrica concreta como o PSI e distinga data drift de concept drift, já que apenas um é visível sem rótulos
• Dispare o retreinamento com base em métricas, não no calendário, e conduza o challenger resultante por um canary antes de reatribuir o alias champion
• Nomeie um feature store em qualquer resposta de system design para fechar a lacuna do training-serving skew antes que ela seja levantada como pergunta seguinte