MLflow com Docker: rastreamento de experimentos de ML

O que o MLflow resolve na prática

O MLflow foi feito para um problema específico: rastreamento de experimentos de ML. Você treinou dezesseis versões de um modelo, variou parâmetros, mediu métricas, e agora precisa saber qual combinação produziu o melhor resultado. Sem uma ferramenta de rastreamento, você faz isso na cabeça ou em planilha, e isso não escala.

A boa notícia é que o MLflow tem uma versão self-hosted que sobe em minutos com Docker. Sem dependência de SaaS externo, sem dados de experimento saindo da sua infraestrutura.

Quando o rastreamento vira necessidade real

Tem um ponto de inflexão claro. Enquanto você está testando um modelo sozinho, em notebook, sem ninguém mais precisando saber o que aconteceu, um arquivo de notas resolve. O problema começa quando:

• Mais de uma pessoa está treinando modelos no mesmo projeto
• Você precisa explicar para alguém por que escolheu um modelo em vez de outro
• O modelo vai para produção e você quer saber a qual run ele corresponde
• Você quer reprovar um modelo automaticamente se a métrica cair abaixo de um threshold

Nesses cenários, a falta de rastreamento não é só inconveniência. É risco operacional. Já vi time descobrir, depois do deploy, que o modelo em produção correspondia a um run sem nome, treinado em dados que ninguém sabia mais identificar. A pergunta "de onde veio esse modelo" não deveria ser difícil de responder.

Como o MLflow organiza o trabalho

Pois é, o MLflow tem quatro componentes principais, mas dois deles resolvem 90% dos problemas agora: Tracking e Model Registry.

Experimentos e runs

O Tracking é onde você registra o que aconteceu em cada experimento. Um experimento agrupa runs relacionados. Cada run registra parâmetros (o que você configurou), métricas (o que você mediu) e artefatos (o modelo salvo, gráficos, arquivos de output).

O ponto que mais importa: você consegue comparar runs lado a lado na interface e filtrar por métrica. Se você treinou dezesseis versões de um modelo variando taxa de aprendizado e profundidade da árvore, o MLflow mostra qual combinação produziu o melhor F1 sem você precisar abrir nenhum notebook.

Model Registry: onde entra a disciplina

O Model Registry é onde você promove um run para produção. Funciona como um controle de versão de modelos com estágios: Staging e Production. Um modelo só vai para Production depois de passar por Staging. Essa barreira simples evita bastante acidente.

Detalhe importante: o Registry não substitui um pipeline de avaliação. Ele garante que você tem rastro, não que o modelo é bom. A decisão de promover ainda precisa de critério claro, seja uma métrica mínima, um teste de sanidade ou revisão manual.

Subindo o MLflow com Docker

O setup mais direto é subir o servidor como container com um volume local para persistência. Quatro comandos resolvem:

• docker pull ghcr.io/mlflow/mlflow
• docker run -d -p 5000:5000 -v $(pwd)/mlruns:/mlruns ghcr.io/mlflow/mlflow mlflow server –host 0.0.0.0
• docker ps
• curl http://localhost:5000/health

A interface fica em http://localhost:5000. Se você já tem Traefik ou outro reverse proxy na frente, basta apontar para a porta 5000 e adicionar autenticação antes de expor para a rede.

Para persistência em produção, faz mais sentido usar PostgreSQL para o backend de metadados e S3 ou MinIO para artefatos, em vez de volume local. O volume local resolve para desenvolvimento e experimentação isolada, mas não escala quando múltiplos pipelines começam a logar ao mesmo tempo.

O que vale registrar (e o que é overhead)

Registrar tudo parece seguro, mas cria ruído. Algumas heurísticas que funcionaram pra mim:

• Parâmetros: registre tudo que muda entre runs. Taxa de aprendizado, hiperparâmetros, features selecionadas, versão dos dados de treino.
• Métricas: registre a métrica de validação que você usa para decisão. Se usa F1 ponderado para decidir, registre F1 ponderado. Accuracy junto só para "ter mais dados" vira poluição.
• Artefatos: o modelo serializado é obrigatório. Gráficos de importância de feature são úteis se alguém vai interpretar. Logs completos de treino raramente valem o espaço.

O critério é simples: se você não vai usar aquela informação para decidir se o modelo vai para produção, não registre. Cada campo extra que você adiciona é campo extra que alguém vai precisar interpretar depois.

MLflow e Langfuse: ferramentas diferentes, momentos diferentes

A confusão aparece com frequência porque as duas têm interface de rastreamento. Mas elas resolvem problemas diferentes.

O MLflow rastreia o processo de treinamento: o que você configurou, o que mediu, qual artefato gerou. É retroativo ao momento do treino. Já o Langfuse, que você pode rodar self-hosted com Docker, rastreia o comportamento do modelo depois que ele está em produção: latência, custo por chamada, entradas e saídas reais.

Se você trabalha com LLMs, vai provavelmente precisar dos dois em momentos diferentes do ciclo. MLflow para organizar experimentos de fine-tuning ou avaliação offline. Langfuse para monitorar o que acontece nas requisições reais. Para definir o que monitorar depois do deploy, combina bem com uma estratégia de avaliação de LLM em produção.

Como saber se o rastreamento está gerando valor

Isso é o que a maioria dos posts sobre MLflow pula. Você sobe a ferramenta e assume que o time vai usar. Não funciona assim.

Algumas métricas que indicam que o rastreamento está funcionando de verdade:

• Tempo médio para responder "qual run gerou o modelo em produção" (deve cair para segundos)
• Percentual de modelos em produção com run correspondente registrado no Registry (meta: 100%)
• Frequência com que o time compara runs antes de promover um modelo (se ninguém está comparando, o tracking não está sendo usado)

Se você tem detecção de drift configurada e um modelo começa a degradar, a primeira pergunta é "qual era o run desse modelo". Sem rastreamento, você procura em notebook, em log, em e-mail. Com rastreamento, você abre o Registry e segue o link.

Perguntas frequentes

O MLflow funciona só com Python e scikit-learn?

Não. O MLflow tem integrações nativas com PyTorch, TensorFlow, XGBoost, LightGBM, Hugging Face e outros. Para frameworks sem integração nativa, você consegue registrar parâmetros e métricas manualmente via API. A documentação oficial do MLflow lista todas as integrações disponíveis e os formatos de artefato suportados.

Preciso de banco de dados externo para começar?

Para desenvolvimento, não. O MLflow usa SQLite por padrão e persiste os dados no diretório mlruns. Para ambiente de equipe ou produção, faz sentido configurar PostgreSQL para metadados e storage externo para artefatos. O volume local não escala bem quando múltiplos pipelines estão logando simultaneamente.

Dá para usar com LLMs e não só com modelos clássicos?

Sim. O MLflow 2.x introduziu suporte a logging de prompts, respostas e métricas de avaliação para LLMs. Você consegue registrar resultados de avaliação offline e comparar versões de prompt. Não substitui o Langfuse para monitoramento em tempo real, mas complementa bem quando você está avaliando modelos antes do deploy.

Comece antes de precisar

O rastreamento de experimentos de ML é uma das práticas de MLOps com menor custo de entrada e maior retorno a longo prazo. O custo de subir o MLflow com Docker hoje é baixo. O custo de reconstruir o histórico de experimentos depois, quando o projeto cresceu e o time mudou, é alto.

Se você já tem monitoramento com Prometheus e Grafana rodando no mesmo host, o MLflow complementa bem: Grafana para o que acontece em runtime, MLflow para o histórico de treinamento.

Sobe o servidor, registra o próximo experimento e verifica se a interface mostra o run com os parâmetros corretos. Essa validação básica já é suficiente para começar.