💻 computer science

How are MLOps Frameworks Used in Open Source Projects? An Empirical Characterization

Este artigo caracteriza empiricamente o uso de oito populares frameworks de MLOps de código aberto ao analisar sua adoção em projetos do GitHub e correlacionar padrões reais de uso de API com solicitações de funcionalidades da comunidade, revelando que os desenvolvedores customizam predominantemente essas ferramentas via APIs em vez de utilizá-las prontas para uso, enquanto buscam melhorias na funcionalidade principal, exposição de API e integração de CI/CD.

Autores originais: Fiorella Zampetti, Federico Stocchetti, Federica Razzano, Damian Andrew Tamburri, Massimiliano Di Penta

Publicado 2026-01-27

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Fiorella Zampetti, Federico Stocchetti, Federica Razzano, Damian Andrew Tamburri, Massimiliano Di Penta

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é um chef tentando administrar um restaurante massivo e de alta tecnologia. Você tem uma receita brilhante (o modelo de Machine Learning), mas levar essa receita da cozinha até a mesa do cliente perfeitamente todas as vezes é um pesadelo. Você precisa rastrear ingredientes, monitorar tempos de cozimento, garantir que a comida não estrague e automatizar o processo de servir.

Os frameworks de MLOps são como esses "sistemas de cozinha inteligentes" projetados para ajudar você a gerenciar esse caos. São ferramentas de software que prometem lidar com todo o ciclo de vida das suas receitas de IA, desde a mistura da massa até o serviço do prato.

Este artigo é como uma investigação forense sobre como 969 "restaurantes" do mundo real (projetos de software de código aberto) estão realmente usando esses sistemas de cozinha inteligentes. Os pesquisadores analisaram oito dos sistemas mais populares (como MLFlow, Wandb e BentoML) para responder a três grandes perguntas: Como eles são usados? Quais partes as pessoas estão realmente utilizando? E do que as pessoas estão reclamando ou o que estão pedindo?

Aqui está o que eles descobriram, dividido em termos simples:

1. O Mito do "Pronto para Uso"

A Expectativa: Você compra um sistema de cozinha inteligente, liga na tomada e aperta um botão "Iniciar". A máquina faz tudo por você.
A Realidade: O artigo descobriu que quase ninguém usa essas ferramentas dessa maneira. Os desenvolvedores raramente apenas as executam a partir de uma linha de comando ou as configuram em um fluxo de trabalho automatizado (como um braço robótico que simplesmente liga).

Em vez disso, os desenvolvedores tratam esses frameworks como conjuntos de LEGO. Eles não usam apenas o castelo pré-construído; eles pegam os tijolos (as APIs de código) e constroem suas próprias estruturas customizadas. Eles estão escrevendo seus próprios scripts para conectar as ferramentas às suas necessidades específicas, em vez de deixar a ferramenta fazer o trabalho pesado automaticamente.

2. O "Canivete Suíço" vs. A "Ferramenta Especializada"

Os pesquisadores notaram que os desenvolvedores frequentemente usam múltiplas ferramentas ao mesmo tempo, como um chef usando uma faca específica para peixe, uma diferente para vegetais e um termômetro para o forno.

Os Rastreadores: Ferramentas como MLFlow e Wandb são as mais populares. Elas são como os "placar de pontuação" e os "cadernos" da cozinha. Os desenvolvedores as utilizam para anotar quais ingredientes usaram, como o prato ficou e para manter um histórico de cada versão da receita.
Os Construtores: Ferramentas como Kedro e Prefect são como os gerentes da linha de montagem. Elas ajudam a organizar as etapas do processo de cozimento.
Os Verificadores de Qualidade: Ferramentas como Deepchecks e Evidently AI são os inspetores de saúde. Elas verificam se os ingredientes estragaram ou se o sabor mudou ao longo do tempo.

O estudo descobriu que as pessoas costumam combinar essas ferramentas. Por exemplo, eles podem usar um "placar" (MLFlow) para rastrear a receita, uma "linha de montagem" (Prefect) para executar as etapas de cozimento e um "inspetor de saúde" (Evidently AI) para garantir que a comida esteja segura. Eles fazem isso porque nenhuma ferramenta sozinha faz tudo perfeitamente.

3. O Problema do "Manual Ausente"

Os pesquisadores também analisaram as "caixas de reclamações" (rastreadores de problemas/issues) onde os usuários dizem aos fabricantes das ferramentas o que desejam. Eles encontraram um padrão claro:

As pessoas querem melhores "placar de pontuação": Os usuários estão pedindo formas melhores de rastrear seus experimentos e monitorar seus modelos.
As pessoas querem "plug-ins" mais fáceis: Como os desenvolvedores estão construindo suas próprias estruturas customizadas (usando as APIs), eles estão pedindo que as ferramentas sejam mais fáceis de conectar às suas construções personalizadas. Eles querem que os "tijolos de LEGO" se encaixem mais facilmente.
As pessoas querem melhor automação: Embora não estejam usando as ferramentas "prontas para uso" ainda, elas estão pedindo melhores formas de integrar essas ferramentas em suas linhas de cozimento automatizadas (pipelines de CI/CD).

A Grande Conclusão

O artigo conclui que, embora esses "sistemas de cozinha inteligentes" existam e sejam poderosos, eles não estão sendo usados como soluções simples e prontas. Em vez disso, os desenvolvedores estão montando peças (hackeando) para construir soluções customizadas porque as ferramentas ainda não se ajustam perfeitamente às suas necessidades específicas.

Os usuários estão dizendo: "Nós amamos as funcionalidades principais (como rastreamento e monitoramento), mas, por favor, facilitem a conexão dessas ferramentas aos nossos fluxos de trabalho customizados e, por favor, nos ajudem a automatizar melhor as partes chatas."

Em resumo, o mundo de MLOps está atualmente em uma fase onde todos estão construindo seus próprios gadgets de cozinha customizados usando o mesmo conjunto de ferramentas, em vez de apenas comprar um eletrodoméstico pré-fabricado. Os fabricantes de ferramentas precisam ouvir os construtores para criar a próxima geração de gadgets mais fáceis de usar.

Resumo Técnico: Como os Frameworks de MLOps são Utilizados em Projetos de Código Aberto? Uma Caracterização Empírica

Definição do Problema
Embora os frameworks de Operações de Aprendizado de Máquina (MLOps) sejam projetados para gerenciar o ciclo de vida de modelos de ML, preenchendo a lacuna entre projetos piloto e produção, sua adoção prática em ecossistemas de código aberto permanece pouco compreendida. Relatórios da indústria indicam que uma maioria significativa de projetos de analytics falha ao transicionar para a produção devido a desafios operacionais e de reprodutibilidade. Apesar da disponibilidade de inúmeros frameworks de MLOps de código aberto, a literatura acadêmica sobre seus padrões de uso reais é limitada. Há uma falta de evidência empírica sobre como os desenvolvedores utilizam essas ferramentas em projetos do mundo real, quais recursos específicos são aproveitados e quais melhorias a comunidade deseja.

Metodologia
Os autores conduziram um estudo empírico envolvendo oito populares frameworks de MLOps de código aberto: BentoML, Deepchecks, Evidently AI, Kedro, Metaflow, MLFlow, Prefach e Wandb. Estes foram selecionados para cobrir componentes principais de MLOps: gerenciamento de fluxo de trabalho, implantação de modelos e monitoramento de produção.

O estudo analisou 969 repositórios GitHub baseados em Python que dependem de pelo menos um desses frameworks. O processo de coleta e análise de dados envolveu três fases principais:

Coleta de Dataset: Os projetos foram identificados via gráfico de dependências do GitHub, filtrados para excluir tutoriais, projetos de brinquedo (menos de 10 estrelas) e repositórios não-Python.
Extração de Uso (RQ1 & RQ2): Os autores analisaram o código-fonte (convertendo Jupyter Notebooks para scripts Python) para detectar o uso dos frameworks via AST de Python. Eles identificaram chamadas de função, instanciações de objetos e acessos a atributos. Também examinaram fluxos de trabalho do GitHub (.yaml) para determinar se os frameworks eram invocados via CLI ou como parte de pipelines de CI/CD. O uso foi categorizado manualmente contra fases de workflow de ML (ex: preparação de dados, treinamento, implantação, governança).
Análise de Solicitação de Recursos (RQ3): O estudo minerou 4.386 issues abertas/resolvidas dos rastreadores de issues dos frameworks, filtrando por solicitações de recursos (feature requests). Uma amostra estatisticamente significativa de 311 issues foi anotada manualmente por especialistas humanos para criar uma taxonomia. Esta taxonomia foi então aplicada ao conjunto de dados completo usando o Gemini 2.5 Pro (um LLM), alcançando um Cohen's $\kappa$ de 0,78.

Principais Contribuições

Análise de Uso: Uma análise abrangente de como 969 projetos clientes utilizam oito frameworks de MLOps, distinguindo entre uso de API, uso de CLI e integração de CI/CD.
Taxonomia de Solicitação de Recursos: O desenvolvimento de uma taxonomia hierárquica de 14 categorias de alto nível e 37 subcategorias de solicitações de recursos, mapeando as necessidades da comunidade para fases específicas de pipeline de MLOps e preocupações de governança.
Correlação de Uso e Demanda: Um mapeamento entre os recursos realmente usados em código de produção e os recursos solicitados pela comunidade, destacando lacunas e alinhamentos.
Pacote de Replicação: Disponibilidade pública dos datasets e scripts utilizados para a análise.

Principais Resultados

Padrões de Uso (RQ1): Frameworks de MLOps são raramente usados "prontos para uso" (out-of-the-box) via Interfaces de Linha de Comando (CLI) ou diretamente dentro de Workflows do GitHub. Em vez disso, os desenvolvedores aproveitam predominantemente as APIs dos frameworks dentro de scripts Python para implementar funcionalidades customizadas. Apenas 24 projetos foram encontrados utilizando esses frameworks como etapas explícitas em Workflows do GitHub.
Utilização de Recursos (RQ2):
- MLFlow e Wandb são os mais amplamente adotados, principalmente para rastreamento de experimentos (log de parâmetros, métricas e artefatos) e governança de infraestrutura.
- BentoML é usado quase exclusivamente para implantação de modelos (empacotamento de modelos em containers).
- Kedro, Metaflow e Prefect são usados para definir e orquestrar pipelines de ML, embora a adoção seja menor do que as ferramentas de rastreamento.
- Deepchecks e Evidently AI (focados em validação e monitoramento) são usados em muito poucos projetos, sugerindo um gap de maturidade em projetos de código aberto no que diz respeito ao monitoramento de produção.
- Co-uso: Desenvolvedores frequentemente combinam múltiplos frameworks (29 projetos encontrados) para aproveitar recursos complementares (ex: usando MLFlow para rastreamento e Prefect para orquestração).
Melhorias Desejadas (RQ3): A taxonomia de solicitação de recursos revela que os usuários buscam principalmente melhorias nos recursos principais em vez de capacidades inteiramente novas. As principais solicitações incluem:
- Exposição de API: Melhores interfaces e documentação para recursos existentes.
- Integração de CI/CD: Melhoria de hooks e automação para integrar frameworks em pipelines.
- Monitoramento: Melhor observabilidade em tempo de execução e rastreamento de saúde do pipeline.
- Segurança e Privacidade: Recursos de autenticação e segurança de dados.

Significância e Alegações
O artigo alega que o estado atual de MLOps em código aberto é caracterizado por uma abordagem pesadamente customizada, onde desenvolvedores constroem workflows sob medida usando APIs de frameworks em vez de depender de soluções padronizadas ou integração de CI/CD. O estudo destaca um descompasso entre a disponibilidade de recursos avançados de MLOps (como monitoramento ao vivo) e sua adoção real em projetos de código aberto.

Os autores sugerem que suas descobertas fornecem uma base para:

Praticantes entenderem padrões de uso típicos e como combinar ferramentas efetivamente.
Criadores de Ferramentas priorizarem melhorias de API, documentação e integração de CI/CD com base na demanda empírica.
Pesquisadores desenvolverem recomendadores para configuração de frameworks.

O artigo mantém um escopo modesto, reconhecendo que seus achados são limitados a projetos Python de código aberto e podem não refletir totalmente a maturidade de aplicações industriais de código fechado. Ele identifica a necessidade de investigações adicionais em ambientes industriais para validar esses padrões.

1. O Mito do "Pronto para Uso"

2. O "Canivete Suíço" vs. A "Ferramenta Especializada"

3. O Problema do "Manual Ausente"

A Grande Conclusão

Resumo Técnico: Como os Frameworks de MLOps são Utilizados em Projetos de Código Aberto? Uma Caracterização Empírica

Mais como este