Forem: Cássio Giehl

MLflow: primeiros passos em MLOps

Cássio Giehl — Tue, 17 Feb 2026 20:25:27 +0000

Alcançar uma métrica excelente em um modelo de Machine Learning não é uma tarefa fácil, imagina não conseguir reproduzir os resultados por não lembrar quais hiperparâmetros foram utilizados

A ideia é sair do “treinei um modelo e deu certo” e entrar no mundo de MLOps, onde eu consigo rastrear experimentos, comparar execuções, armazenar artefatos e repetir o processo com confiança.

O que é MLOps?

MLOps é a pratica de aplicar princípios de DevOps em machine learning (ML) projects. O que envolve gerenciar o lifecycle de projetos de ML, desde restreabilidade no desenvolvimento de treinamento até o deploy, monitoramento.

No desenvolvimento de software tradicional, o controle de versão de código (como o git) é suficiente. Em ML, o resultado é o conjunto de desenvolvimento entre Código + Dados + Hiperparâmetros.

Uma ferramenta dedicada pode facilitar o processo de auditoria e colaboração dos modelos, antes do processo de experimentação se tornar caótico. A ausência de um histórico estruturado impede a reprodutibilidade e escala de qualquer projeto de IA.

O que é MLflow

O MLflow é uma ferramenta que ajuda a aplicar MLOps para organizar o ciclo de vida de projetos de ML. Mesmo num projeto simples, ele já ajuda muito porque cria um histórico do que foi feito em cada treino.

Na prática, o MLflow me ajuda a responder perguntas como:

Qual conjunto de parâmetros gerou a melhor métrica?
Quando eu rodei o treinamento e qual foi o resultado?
Onde está salvo o modelo treinado daquela execução?

MLflow como sua camada de Tracking

O MLflow surge para padronizar essa gestão. Nesse momento iremos focar nos três tipos de registros fundamentais:

Parâmetros: Inputs de configuração (ex: learning_rate, n_estimators)
Métricas: Resultados de performance (ex: accuracy, log_loss)
Artefatos: O output binário (o modelo treinado em .pkl ou .onnx)

O MLflow transforma experimentação ad-hoc em um sistema de registro auditável e padronizado.

Hands On: Setup do projeto

Como de costume, irei demonstrar como implementar uma configuração simples do MLFlow:

Backend Store: SQLite (um arquivo mlflow.db) para guardar metadados (experimentos, runs, params, metrics).
Artifact Store: File store (pasta mlruns/) para guardar artefatos (como o modelo salvo).

Setup do Servidor

# Instalação
pip install mlflow

# Inicialização do servidor
mlflow server \
    --backend-store-uri sqlite:///mlflow.db \
    --default-artifact-root ./mlruns \
    --host 0.0.0.0 \
    --port 5000

Parâmetros:

mlflow server: inicia o serviço do mlflow
backend-store-uri: escolhi o sqlite por ser leve, ideal para primeira iteração com a ferramenta
default-artifact-root: path onde serão armazenados os metadados dos experimentos
host e port: caminho no qual o server estará disponível para conexão, inclusiva para uso via UI

Propriedades MLflow:

Quando uso SQLite + file store, é comum ver dois componentes principais no diretório do MLflow:

mlflow.db: banco SQLite com metadados. Armazena experimentos, runs, parâmetros e métricas.
mlruns/: pasta com os artefatos e o conteúdo das runs. Armazena modelos, plots, etc.

Integração no Script de Treino

A biblioteca mlflow do python nos permite conectar facilmente com a ferramenta, sem muito impacto no código, a integração é bem minimalista. Basta setar os parametros iniciais e usar mlflow.start_run():

import mlflow

mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("Customer_Churn_Experiment")

with mlflow.start_run():
    # Treino do modelo...
    mlflow.log_param("max_depth", 10)
    mlflow.log_metric("accuracy", 0.85)
    mlflow.sklearn.log_model(model, "random_forest_model")

Neste cenário, a infraestrutura do MLflow foi desacoplada do código de treinamento, tornando necessária a configuração da URI da instância via set_tracking_uri.

Primeira Interação

Na primeira vez que eu rodo o meu script treinamento:

O experimento Customer_Churn_Experiment é criado automaticamente
Uma run é registrada
Params, metrics e artifacts são enviados para o tracking server

Params e Metrics rastreados

No meu caso, registrei:

Params: n_estimators, max_depth
Metrics: accuracy, recall

y_pred = model.predict(X_test)  
acc = accuracy_score(y_test, y_pred)  
rec = recall_score(y_test, y_pred)  

mlflow.log_param("n_estimators", n_estimators)  
mlflow.log_param("max_depth", max_depth)  
mlflow.log_metric("accuracy", acc)  
mlflow.log_metric("recall", rec)

Isso me permite comparar execuções diferentes sem depender de print no terminal.

Segunda Interação

O valor real do MLOps aparece na análise comparativa entre os modelos que o cientista utilizou bem como o processo percorrido.

Nessa etapa, realizei uma segunda interação, alterando os valores dos hiperparâmetros max_depth e n_estimators. Embora esperasse uma melhora, ao inspecionar a UI do MLflow, percebi que a métrica de accuracy caiu.

Aqui pude perceber o poder real da ferramenta:

Rastreabilidade: Você tem a prova empírica de que a mudanca dos hiperparametros gerou overfitting
Comparação Técnica: Através da UI do MLflow, você compara as duas execuções
Pilar de Reprodutibilidade: Se precisar retornar à versão anterior, o artefato está registrado e pronto para deploy (aprofundarei mais sobre isso no futuro)

Se você ainda está surpreso com o que viu, saiba que essa ferramenta é realmente um divisor de águas. Ela transforma a forma como gerenciamos a rastreabilidade no ciclo de vida de modelos e simplifica a comparação entre diferentes versões, sendo essencial desde os primeiros testes até projetos construídos do zero.

Conferindo metadados no SQLite

Uma parte legal desse tipo de setup local é que eu consigo inspecionar o SQLite pela linha de comando.

Experimentos registrados no SQLite:

Parâmetros e métricas registrados:

Conclusão e Próximos Passos

Dominar a gestão do estado do modelo é um requisito fundamental na Engenharia de MLOps. Enquanto o MLflow soluciona a camada de tracking, o ciclo de vida se estende ao Model Registry e ao Model Serving. Em breve, exploraremos como essas etapas garantem a maturidade de um modelo em produção.

Dominar o rastreamento de experimentos é o alicerce fundamental para implementar Continuous Training (CT) no futuro.

Gostou dessa abordagem técnica?

Este projeto está disponível no meu GitHub: mlops-telco-churn-predict.

E você: já utiliza o MLflow no seu dia a dia? Na sua visão, qual é o maior desafio para garantir a reprodutibilidade total dos modelos?

Vamos debater nos comentários!

MCP: uma abordagem produtiva

Cássio Giehl — Mon, 07 Apr 2025 00:09:26 +0000

Potencializando meu trabalho repetitivo com AI usando MCP

Uma das habilidades mais importantes de um desenvolvedor é a capacidade de analisar logs das aplicações. Visando otimizar minha rotina como desenvolvedor, criei um conjunto de ferramentas automatizadas que transformam essa processo demorado e suscetível a erros em um processo mais inteligente e dinâmico para me auxiliar e vou compartilhar um pouco do processo de desenvolvimento.

CONTEXTO

A pipeline do seu projeto spark começou a apresentar alguns jobs com erro, o que gerou diversos alertas para seu time e você é o encarregado de ajustar essa pipeline. Ao testar o script localmente tudo estava funcionando, mas no ambiente de produção começou a encontrar dados um pouco diferentes do que os usados para desenvolver.
Para analisar o problema, precisa executar basicamente essa ordem de atividades:
- Identificar o job com erro
- Buscar o arquivo de log do processamento com o erro
- ler o traceback de log
- Identificar o erro
Desenvolvimento da solução:
- Aplicar a correção no script pyspark
- subir versão nova com o fix

OBJETIVO

Desenvolver um MCP Server capaz de ler e interpretar arquivos de logs (s3/Minio) do job spark que finalizou com erro.

MCP

O MCP é um protocolo aberto que padroniza como os aplicativos fornecem contexto para LLMs

ARQUITETURA

MCP Server:
- Expor dados atraves de Resources
- Prover funcionalidades atraves de Tools
- Definir padroes de interacao atraves de Prompts
MCP Client
- interage com um ou mais servers, consumindo os Resources, Tools e Prompts disponibilizados
- nesse exemplo não irei desenvolver um MCP Client, pois utilizaremos Claude Desktop para essa finalidade

DESENVOLVIMENTO MCP SERVER

Eu estava desenvolvendo uma conexão manual com o storage, usando boto3, quando encontrei um exemplo de uso do s3 em um mcp server, disponibilizada pela AWS a poucos dias. Eu não curto ficar repetindo código que já existe, então apenas fiz uma adaptação no repositorio de exemplo para realizar a conexão com o Minio executando localmente em um docker container.

Esse projeto conta com dois arquivos principais: server.py e s3_resources.py

`server.py`

Disponibiliza os recursos e ferramentas criados em s3_resources.py através do protocolo MCP, usando annotations. Aqui definimos quais tools a IA será capaz de acessar:

server = Server("s3_service")

@server.list_resources()
async def list_resources(start_after: Optional[str] = None) -> List[Resource]:
    ...

@server.read_resource()
async def read_resource(uri: AnyUrl) -> str:
    ...

@server.list_tools()
async def handle_list_tools() -> list[Tool]:
    return [
        Tool(
            name="list_buckets",
            description="...",
            ...
        ),
        Tool(
            name="list_objects",
            description="...",
            ...
        ),
        Tool(
            name="get_object",
            description="...",
            ...
        )
    ]

@server.call_tool()
async def handle_call_tool(
    name: str, arguments: dict | None
) -> list[TextContent | ImageContent | EmbeddedResource]:
    try:
        match name:
            case "list_buckets":
                buckets = boto3_s3_client.list_buckets(**arguments)
                return [
                    TextContent(
                        type="text",
                        text=str(buckets)
                    )
                ]
            case "list_objects_v2":
                objects = boto3_s3_client.list_objects_v2(**arguments)
                return [
                    TextContent(
                        type="text",
                        text=str(objects)
                    )
                ]
            case "get_object":
                response = boto3_s3_client.get_object(**arguments)
                file_content = response['Body'].read().decode('utf-8')
                return [
                    TextContent(
                        type="text",
                        text=str(file_content)
                    )
                ]
    except Exception as error:
        return [
            TextContent(
                type="text",
                text=f"Error: {str(error)}"
            )
        ]

async def main():
    # Run the server using stdin/stdout streams
    async with mcp.server.stdio.stdio_server() as (read_stream, write_stream):
        await server.run(
            ...
        )

if __name__ == "__main__":
    asyncio.run(main())

`s3_resources.py`

Aqui definimos como os recursos e ferramentas irão interagir com o s3:

class S3Resource:

    async def list_buckets(self, start_after: Optional[str] = None) -> List[dict]:
      ...

    async def list_objects(self, bucket_name: str, prefix: str = "", max_keys: int = 1000) -> List[dict]:
      ...

    async def get_object(self, bucket_name: str, key: str, max_retries: int = 3) -> Dict[str, Any]:
      ...

Como estou utilizando MinIO como storage, tive que adicionar o atributo self.client_config para conseguir fazer a configuração correta para utilização da ferramenta local.

Configuração Claude Desktop

Essa foi a parte que eu mais tive problema, pois o aplicativo precisa ser reiniciado toda vez que fazia alguma alteração no server.

O Claude Desktop é compatível somente com windows e mac, precisei fazer uma configuração um pouco diferente da convencional, pois meu código está rodando em um Ubuntu no WSL:

Caso estiver executando dentro do WSL

{
  "mcpServers": {
    "log-resource": {
      "command": "wsl",
      "args": [
        "-d",
        "Ubuntu",
        "/home/cassiogiehl/.local/bin/uv",
        "--directory",
        "/home/cassiogiehl/dev/mcp/mcp_log",
        "run",
        "server.py"
      ]
    }
  }
}

Com o MCP Server configurado corretamente, podemos iniciar os testes...

Listando Buckets

Interpretando logs de erro

`spark-job.py` original:

from pyspark.sql import SparkSession
from pyspark.sql.functions import col

# Criação de uma Spark session
spark = SparkSession.builder.appName("ErrorAnalysisExample").getOrCreate()

# Exemplo de DataFrame com duas colunas
data = [("Alice", 34), ("Bob", 45), ("Charlie", 29)]
columns = ["name", "age"]

# Criação do DataFrame
df = spark.createDataFrame(data, columns)

df.select(col("salary")).show()

# Fechamento da Spark session
spark.stop()

Correção Sugerida

Próximos passos

Agora que a LLM já tem acesso aos logs de erro e ao código do projeto, a única coisa que falta é a integração com o repositorio. Como upgrade desse projeto irei desenvolver uma solução que altera o código do job e faz o commit no git, restringindo o merge no repositório somente como minha aprovação no pull request.

Conclusão

Neste projeto, demonstramos a integração bem-sucedida entre um servidor MCP (Model Context Protocol) e o Amazon S3 para análise de logs e correção de código. O sistema foi capaz de:

Acessar e listar buckets S3 contendo logs
Identificar erros em códigos Python através da análise dos logs
Sugerir correções apropriadas usando LLM (Large Language Model)

A solução provou ser eficaz para automatizar o processo de debugging, reduzindo o tempo necessário para identificar e corrigir erros em jobs Spark. A arquitetura modular permite fácil extensão para suportar outros tipos de análise e correção de código no futuro.

Disponivel em: https://github.com/cassiogiehl/mcp-log