Já pensou em colocar um LLM pra julgar outro LLM?

Se os modelos de linguagem generativa já estão respondendo perguntas, escrevendo e-mails e até montando código por conta própria, por que não deixá-los também avaliar uns aos outros?

É exatamente essa a proposta do DeepEval — um framework open-source criado para facilitar a avaliação de sistemas baseados em LLMs. Com ele, você consegue medir se a resposta de um modelo faz sentido, se está coerente com a fonte, se não está alucinando fatos, e até se carrega viés ou toxicidade. E o mais curioso? Em muitos casos, quem faz essa avaliação é outro LLM, cuidadosamente instruído para atuar como um “juiz”.

Se você está desenvolvendo sistemas com RAG (Retrieval-Augmented Generation), se preocupa com qualidade de resposta em produção, ou simplesmente quer garantir que suas alterações de prompt não pioraram tudo sem querer… o DeepEval pode virar seu melhor amigo.

Neste artigo, vamos explorar como o DeepEval funciona, por que ele vem ganhando espaço em projetos sérios (e até em pipelines de CI/CD), e como você pode começar a usá-lo para dar mais confiança às suas aplicações com IA generativa.

Desenvolvido pela Confident AI, o DeepEval é um framework open-source projetado para avaliar aplicações que utilizam modelos de linguagem (LLMs) de forma similar ao pytest, mas voltado para saídas probabilísticas, permitindo testes unitários e regressões automáticas de desempenho. Com mais de 400 mil downloads mensais e cerca de meio milhão de avaliações por dia, já é amplamente usado em ambientes de CI/CD por empresas como Microsoft, BCG e AstraZeneca.

Principais Capacidades

Métricas de Avaliação

DeepEval oferece um conjunto robusto de métricas integradas, cobrindo diversos aspectos importantes:

• G-Eval: métrica customizável baseada em LLMs como “juízes” para avaliação de critérios livres;
• Métricas RAG: relevância da resposta, fidelidade (faithfulness), recall/contextual precision, contextual relevancy, além de RAGAS.
• Hallucination, viés, toxidez e coerência sem referência textual.

LLM-as-a-Judge

Uma inovação central do DeepEval é o uso de LLMs como avaliadores. Você pode configurar julgamentos de saída única (single-output) ou comparações entre saídas (pairwise), onde o LLM atribui nota ou escolhe a resposta melhor de acordo com critérios definidos no prompt. Isso supera limitações de métodos tradicionais como BLEU ou ROUGE e substitui parcialmente a avaliação humana, tornando os testes mais escaláveis e semânticos.

Integração com RAG e Testes Automatizados

Pipelines RAG

Ao avaliar sistemas Retrieval-Augmented Generation (RAG), DeepEval permite medir:

• Relevância da resposta ao contexto recuperado,
• Fidelidade factual, e precisão de contexto,
• Recall contextual e RAGAS, todos ajustáveis por thresholds

Testes no Pytest / CI

DeepEval é compatível com o ecossistema Python e pode ser integrado a pipelines de CI/CD como um teste unitário tradicional:

• Criação de datasets sintéticos ou manuais de casos de teste;
• Automatização de comparações entre versões de prompts ou modelos;
• Detecção de regressões através de comparação de resultados históricos.

Plataforma Confident AI

Embora DeepEval funcione localmente, a Confident AI oferece uma plataforma cloud opcional que complementa o framework com:

• UI para visualização de relatórios, comparativos de versões, análise de distribuição de métricas;
• Observabilidade de LLM apps em produção (tracing, login detalhado, métricas em live);
• A/B testing e coleta de feedback humano.

Exemplo de código

from deepeval import assert_test
from deepeval.metrics import GEval, HallucinationMetric
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

def test_llm_response():
    test_case = LLMTestCase(
        name="verificar relevante e sem alucinações",
        input="Pergunta X",
        actual_output="Resposta gerada"
    )

    test_case.add_metric(GEval(
        name="relevância",
        model="gpt-4",
        threshold=0.5,
        evaluation_steps=["Avalie a relevância da resposta"],
        evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT]
    ))

    test_case.add_metric(HallucinationMetric(name="checar-alucinação"))
    assert_test(test_case)

Para cenários sem dependência de APIs externas, é possível usar modelos open-source como Llama, GPT4All ou Mixtral como avaliadores, mantendo tudo de forma local e preservando privacidade dos dados.

Considerações e Boas Práticas

• Responsabilidade de Prompt Design: LLM-as-a‑Judge depende da qualidade do prompt; é fundamental definir exemplos claros e testar com exemplos variados.
• Limitações de avaliadores open‑source: Ainda que promissores, modelos LLM open‑source podem ter menor capacidade de julgamento profundo! Casos de uso crítico devem ser avaliados com cautela.
• Proteção contra vieses: é ideal regularmente revisar métricas de viés e toxidade, ajustando prompts e thresholds.
• Atualização constante: aevolução de métricas e funcionalidade está contínua, recomendo demais acompanhar o repositório GitHub e blogs da Confident AI pra ajudar a te manter atualizado em relação ao framework.

Fontes

• Repositório GitHub DeepEval (framework open-source para avaliação de LLMs, com métricas como G‑Eval, hallucination, answer relevancy, RAGAS etc.)
• Blog “How I Built Deterministic LLM Evaluation Metrics for DeepEval” por Confident AI, detalhando o uso de LLM-as‑a‑Judge, downloads mensais e escala de uso.
• Artigo “LLM‑as‑a‑Judge Simply Explained” (Confident AI, jul/2025), explicando o paradigma LLM‑as‑a‑Judge, tipos de julgamento (single-output, pairwise) e pontuação.
• Guia “LLM Evaluation Metrics: The Ultimate Guide” (Confident AI, jun/2025), cobrindo métricas como answer relevancy, faithfulness, contextual precision/recall e RAGAS.
• Blog “Leveraging Open Source Models for AI Evaluation with DeepEval” (ChristopherGS, fev/2024), sobre uso de modelos open‑source e execução local de testes.
• Artigo “Evaluating LLM Responses with RAG and DeepEval” (Medium, 3 meses atrás), mostrando avaliação automática com métricas de relevancy, bias, toxicity em pipelines RAG.
• Tutorial prático “Evaluate LLMs Effectively Using DeepEval” (DataCamp, jan/2025), com G‑Eval, integração pytest e benchmarking.
• Página Confident AI explicando a plataforma LLM Evaluation & Observability suportando DeepEval como backend.

DeepEval: avalie LLMs com framework Open‑Source was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Robustez, confiança… Conheça métricas para avaliar a qualidade de modelos pós deploy

Quando se fala em métricas de avaliação, os clássicos são os primeiros a vir à cabeça: precision, recall, f1-score, acurácia, r2… Dependendo do problema, uma regra matemática que nos diz a eficácia da modelagem sendo implementada.

Chip Huyen destaca no livro Designing ML Systems ((O’Reilly). Copyright 2022 Huyen Thi Khanh Nguyen, 978–1–098–10796–3) que ‘ao avaliar um modelo, é importante diferenciar um “bom sistema” de um “sistema útil”’. Um bom sistema não é necessariamente útil, e um sistema ruim não é necessariamente inútil. Um veículo autônomo pode ser bom se for pelo menos tão bom quanto os motoristas humanos. Em alguns casos, mesmo que um sistema de Machine Learning funcione melhor do que um ser humano médio, as pessoas ainda podem não confiar nele, o que neste caso torna-o inútil. Por outro lado, um sistema que prevê a próxima palavra que um usuário digitará em seu telefone pode ser considerado ruim se for muito pior do que um falante nativo. No entanto, ainda pode ser útil se suas previsões puderem ajudar os usuários a digitar mais rápido!

Em desafios e competições, ao avaliar modelos de ML, cientistas tendem a se fixar em suas métricas de desempenho. No entanto, quando falamos de um modelo em produção, também queremos que os nossos modelos sejam robustos, bem calibrados e, em geral, que façam sentido para o usuário que o consome. Pensando nisso, apresento algumas métricas de avaliação pouco conhecidas que podem auxiliar (e muito!) a medir a sanidade de modelos já implementados (alô, observabilidade? Corre aqui!).

Perturbation Tests

Os testes de perturbação são uma técnica poderosa para avaliar a robustez de um modelo quando o assunto são pequenas alterações nos dados de entrada. Os testes envolvem introduzir perturbações nos dados de teste, como por exemplo adicionar ruído ou modificar ligeiramente os valores, e observar como o modelo responde a tais mudanças. Se o modelo for robusto, pequenas perturbações não devem afetar significativamente suas predições, indicando uma maior confiança na capacidade de generalização do nosso sistema.

Invariance Tests

Os testes de invariância são projetados para verificar se um modelo mantém suas previsões consistentes em diferentes contextos ou cenários. Essa métrica é particularmente útil em situações onde certas características dos dados podem mudar, mas as previsões do modelo devem permanecer estáveis. Um modelo de detecção de objetos em imagens deve ser invariante a mudanças de iluminação ou rotação, por exemplo. Realizar testes de invariância ajuda a garantir que o modelo seja confiável em diferentes condições e adversidades.

Directional Expectations Tests

Expectativas direcionais são úteis para avaliar se um modelo está seguindo as expectativas esperadas em relação às mudanças nos inputs de entrada. Por exemplo, se o valor de uma variável de entrada aumenta, espera-se que a previsão do modelo também aumente (ou diminua, dependendo do contexto). Se aumentarmos propositalmente a variável metro quadrado em um modelo de previsão de preço de apartamentos, espera-se que os preços também subam. Testes de expectativas direcionais ajudam a identificar se o modelo está se comportando conforme o esperado e se está capturando corretamente a relação entre as variáveis de entrada e saída.

Slice-Based Evaluation

A avaliação baseada em fatias (slice-based evaluation) é uma abordagem que envolve analisar o desempenho de um modelo em diferentes segmentos ou subgrupos dos dados. Isso é especialmente útil em problemas onde o desempenho do modelo pode variar significativamente entre diferentes grupos de dados, como em casos de desequilíbrio de classes ou vieses indesejados. Ao avaliar o modelo em fatias específicas dos dados, os cientistas de dados podem identificar áreas de melhoria e garantir que o modelo funcione de maneira justa e eficaz para todos os grupos de interesse. Se ajustarmos a variável gênero para que todos os labels indiquem ‘feminino’, por exemplo, o que acontece com as predições do nosso modelo? Testes como esse nos auxiliam no controle de ‘fairness’ do algoritmo e proporcionam uma gestão ativa de possíveis vieses.

Métricas de avaliação para modelos em produção was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ou: o que o Kaggle não te ensina

A interseção entre a academia e o mercado de trabalho na área de ciência de dados e machine learning é maravilhosa — e complexa. Enquanto em projetos pessoais e competições somos convidados a nos concentrar na elaboração de algoritmos inovadores e na obtenção de pontuações impressionantes e precisas, no ambiente empresarial, os desafios vão muito além da simples construção de modelos. Algumas leituras recentes (que serão compartilhadas ao final deste texto!) despertaram esta reflexão sobre as principais diferenças entre a construção de algoritmos em contextos acadêmicos/portfólios pessoais e sua construção dentro de grandes corporações. A engenharia de software (especialização que optei fazer, é importante que se diga! Imparcialidade passou longe) pode desempenhar um papel crucial na implementação prática de sistemas de ML.

Para entender melhor tais diferenças, recorro ao excelente livro “Designing Machine Learning Systems”, de Chip Huyen, que oferece insights valiosos sobre as complexidades envolvidas na implementação de sistemas de Machine Learning em ambientes de produção. Uma das diferenças fundamentais é a ênfase na escalabilidade e na manutenção dos sistemas que acontece no mercado de trabalho, em contraste com a busca constante pela otimização de métricas, que costuma dominar o cenário acadêmico/competições/portfólio. Enquanto os desafios propostos em competições como Kaggle geralmente envolvem aprimorar um único modelo para maximizar a precisão (ou outra métrica de desempenho), no mercado, os cientistas de dados enfrentam a tarefa de integrar estes modelos em sistemas maiores, lidando com preocupações como escalabilidade, eficiência computacional, explicabilidade da solução e manutenção a longo prazo. Isso significa que, sim, muitas vezes se abre mão de alguns pontos percentuais de precisão (ou até da escolha do próprio modelo) por uma integração mais fluida com o sistema como um todo.

O livro também ressalta a importância da colaboração interdisciplinar e da comunicação eficaz no ambiente de trabalho, onde os cientistas de dados frequentemente precisam colaborar com engenheiros de software, analistas de negócios e outros profissionais para desenvolver soluções que atendam às necessidades e restrições do negócio. Essa colaboração contrasta fortemente com a natureza mais ‘individualista’ do ambiente acadêmico ou de competições, onde os participantes muitas vezes trabalham de forma independente para desenvolver suas soluções.

No entanto, uma das diferenças mais significativas entre a abordagem acadêmica e a prática profissional está na ênfase dada à etapa de preparação e manutenção dos dados. Em projetos pessoais ou desafios, muitas vezes o foco está principalmente na modelagem em si, com grande parte do tempo e dos recursos dedicados à experimentação com algoritmos, técnicas de feature engineering e otimização de hiperparâmetros. Essa abordagem tende a subestimar a importância da qualidade dos dados e todo o tempo gasto em sua preparação, labelização, validação com negócio e afins.

Vale lembrar que a necessidade de garantir a qualidade e a consistência dos dados não é apenas um obstáculo inicial: ela persiste ao longo de todo o ciclo de vida do sistema de ML. Um aspecto particularmente relevante é o conceito de “model drift” (mudança do modelo), que se refere à deterioração do desempenho do modelo ao longo do tempo devido a possíveis variações nos dados de entrada. Essas mudanças podem ser causadas por uma variedade de fatores, como alterações nos padrões de comportamento dos usuários, alterações nas condições operacionais… Lidar com model drift requer uma vigilância contínua e estratégias de monitoramento eficazes, além de uma manutenção proativa dos modelos em produção.

Foi pensando em todas essas diferenças (e após atuar o último ano inteiro em um projeto focado em manutenção e monitoramento de modelos), que optei por fazer uma especialização em Engenharia de Software. A habilidade de compreender e aplicar os princípios de ES em projetos de Machine Learning permite esse olhar além da simples construção de modelos e aborda os desafios mais amplos associados à implementação de soluções de IA em ambientes reais.

Uma das principais vantagens de se aprofundar no universo Ops é a capacidade de desenvolver sistemas de ML mais robustos e escaláveis. Aprofundar meu conhecimento em práticas de desenvolvimento de software amplia a visão e possibilita a adoção de uma abordagem mais estruturada e modular na concepção e na implementação de pipelines de dados e modelos. Isso torna os sistemas mais fáceis de dar manutenção e escalar à medida que as demandas do negócio podem evoluir.

Hoje temos o papel do Engenheiro de Machine Learning, que, metido até as canelas com engenharia de dados e de software, traz esse olhar para os processos de implementação e MLOps de forma muito mais ativa do que o Cientista de Dados. Bato na tecla, todavia, que essas são habilidades das quais todos os cientistas se beneficiariam em ter: proporcionam uma compreensão mais abrangente das melhores práticas em termos de testes e de integração contínua e entrega contínua (CI/CD) — que são fundamentais para garantir a qualidade e a confiabilidade do modelo. Também ampliam o olhar em termos do trade off custos x escalabilidade, facilidade na manutenção do ciclo de vida x complexidade e até no entendimento dos usuários sobre o funcionamento da solução (que, dependendo do negócio, pode ser a métrica mais importante). No fim do dia, são conhecimentos que te tornam mais capacitado para desenvolver modelos de forma útil e absolutamente viável para a empresa que irá implementá-lo — e, no final do dia, é sobre isso.

Segue uma lista de cursos, livros, referências e tudo mais que tenho lido sobre o tema:

Designing Machine Learning Systems, by Chip Huyen (O’Reilly). Copyright 2022 Huyen Thi Khanh Nguyen, 978–1–098–10796–3.

Production Machine Learning Systems, curso do path Machine Learning Engineer, disponível no Google Cloud Skills Boost.

MLOps Best Practices, Medium Article.

Architecture of a real-word ML system, Medium Article.

3 Building Blocks of ML you should know as a Data Scientist, Analytics Vidhya.

Modelos de portfólio x modelos em produção was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Boas práticas da Engenharia de Prompt para adotar no seu dia a dia

Recebo muitas perguntas de quem está entrando na área questionando se o chat GPT irá roubar nossos empregos. A resposta é tão simplista quanto a pergunta: não. Inclusive, na consultoria onde trabalho, as demandas por profissionais de Data Science aumentaram desde as evoluções do chatGPT — mas é claro, não é uma demanda qualquer: a procura é por profissionais que tenham conhecimento sobre como trabalhar com essa ferramenta.

Antes de entrarmos nas várias utilidades que é possível extrair do GPT dentro da ciência e do desenvolvimento de código, vamos começar com algo simples e, ainda sim, extremamente importante: engenharia de prompt.

Engenharia de prompt nada mais é do que o estudo de técnicas e práticas pensando na interação com prompts de IA — ou seja, com o chat do GPT, ou com o discord do Midjourney, e por aí vai. Apesar do nome rebuscado, nada mais é do que um conjunto de boas práticas que vão garantir uma interação mais segura e efetiva com o modelo, aumentando as chances de ter um retorno correto e evitar os temidos delírios (erros) de resposta. Pessoalmente, acredito que a Engenharia de Prompt irá compor os futuros manuais de compliance das empresas, assim como temos style guides para designers com as cores e fontes da marca, teremos direcionamentos quanto ao uso de prompts de IA.

Abaixo, algumas dicas bem simples para implementar na hora de interagir com inteligências artificiais! Lembrando que nenhuma delas garante 100% uma resposta correta — ainda é o seu trabalho verificar a acuracidade do retorno da ferramenta, mas tais boas práticas podem minimizar bastante as alucinações dos modelos.

1. Trabalhe com exemplos
   Fornecer exemplos em seu prompt ajuda o modelo a compreender o contexto e gerar respostas mais precisas. Por exemplo: “Escreva uma breve história do Python, assim como foi feita a história do Java descrita neste artigo (insira o link do artigo de inspiração)”. Isso não apenas dá à IA um tópico claro, mas também um ponto de referência de como prosseguir. Fornecer um exemplo bem estruturado também pode economizar muito tempo ao explicar o resultado que você espera receber. Sem um exemplo, sua sugestão pode ser muito genérica, permitindo muita liberdade na interpretação.
2. Quebre as instruções em tópicos menores
   Já tentou montar um móvel sem olhar o manual de instruções desenhadas que normalmente acompanha o item? É um pouco assim para modelos de IA que lidam com solicitações complexas, muitas etapas separam o seu pedido do resultado final, logo, são muitas as variáveis ​​a serem consideradas. Em vez de, por exemplo, pedir ao modelo para “Aplicar um modelo regressivo na base de dados do kaggle”, divida-o em tarefas menores e mais gerenciáveis, como “Etapa 1: Identificar variável target, Etapa 2: Coletar e preparar dados” e assim por diante. Dessa forma, a IA pode abordar cada etapa individualmente e gerar resultados mais coerentes.
3. Dê uma saída em caso de emergência
   Para evitar que a IA dê uma resposta falsa pra sua pergunta, inclua ao final do questionamento uma frase de segurança, por exemplo “se a sua resposta não for baseada em fatos verificados, retorne ‘não consigo responder”. Isso é bastante útil pra perguntas que envolvem fatos históricos, por exemplo, ao perguntar ‘quem inventou o MLOps’ e evitar um retorno do tipo Mariah Carey. Se não houver registros sobre o inventor do MLOps, a prompt simplesmente retorna ‘não consigo responder’.

A dica final não chega a ser capaz de evitar alucinações, mas eu acho ela bastante útil na hora de traduzir processos complexos em apresentações de negócio: inclua ‘explique {insira um tema complicado aqui} como se fosse para uma criança de 5 anos’. O resultados têm sido ótimos e é interessante inclusive para auxiliar nos estudos, fazendo do GPT um verdadeiro ‘tutor’ a quem recorrer de vez em quando.

Jamais inclua informações da sua empresa no chat GPT. Consulte seu empregador sobre a possibilidade do uso da ferramenta dentro do escopo de trabalho.

3 dicas para minimizar ‘AI hallucination’ no chatGPT was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

O resumão da vida pra tirar a certificação Microsoft Azure

Quem me conhece sabe que diploma ou certificado não é minha forma favorita de demonstrar conhecimento. Aprendi tanto ou mais em tutoriais do YouTube do que muitos cursos com certificação por aí! Mas, vez ou outra, me rendo à provas e simulados quando faz sentido.

Entender sobre cloud em dados é, hoje, mandatório. Infelizmente, o melhor modo de aprender é trabalhando com elas — tendo que consultar dados em um banco nativo no BigQuery, construir um modelo no AI Platform e deployar utilizando alguma ferramenta como Airflow ou Kubernetes. Felizmente, você não precisa estar empregado em um projeto desse porte pra colocar a mão na massa! É possível criar free accounts e testar a maioria dos serviços em nuvem pra se familiarizar com o processo.

Sou fã de GCP e já tive muito contato com AWS, mas acabei selecionando Azure pra tirar a certificação. Apesar de não ‘provar’ necessariamente minhas habilidades reais, é uma maneia interessante de estudar todas as possibilidades que esses players disponibilizam! Estudando para a prova, aprendi muito sobre funcionalidades e recursos que não conhecia e que muitas vezes desenvolvia do zero ao invés de utilizar um recurso cloud. Além do conhecimento, é interessante comercialmente para o mercado empregar alguns profissionais com certificação — especialmente no caso de consultorias, brilha os olhos de alguns clientes que o profissional alocado seja certificado nesta ou naquela nuvem.

Sem mais delongas, segue o cheat sheet construído com base no Study Guide mais recente disponibilizado pela Microsoft e a partir do Learning Path gratuito que eles disponibilizam pra quem pretende realizar a prova. No final coloquei alguns links de simulados grátis pra você se sentir preparado antes do teste :) Bons estudos!

Este guia foi escrito em inglês para evitar traduções equivocadas dos nomes dos recursos. Recomendo estudar na língua nativa do learning path!

O material abaixo foi construído usando minha ferramenta de estudos preferida, o Notion, e o link de acesso direto pra ela está aqui: https://purrfect-cabinet-533.notion.site/AI-900-cheat-sheet-fde01351e339439a850dd0733c09ab81

AI-900 cheat sheet

Praticar é tudo → confere algumas das perguntas que podem aparecer na prova e treine de graça!

AI-900: Perguntas de exemplo dos fundamentos da IA do Microsoft Azure;

Simulado Exam Topics;

Practice Assestment da própria MS.

AI-900 cheat sheet was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Largando os cadernos: de notebooks à scripts .py

Como a Engenharia de Software me auxiliou a dar o próximo passo no desenvolvimento de modelos ML

Que os notebooks são indispensáveis na vida de um cientista de dados, isso é inegável. Seja localmente em um Jupyter Lab, através de um Google Colab ou mesmo dentro de estruturas Cloud, essa oitava maravilha da ciência é o que possibilita a visualização imediata do resultado da execução de um bloco de código, facilitando e muito a etapa de análise exploratória — e todo o desenvolvimento de um projeto de Machine Learning.

Na hora de produtizar esse modelo, no entanto, é que as coisas ficam complexas. Como o próprio nome já diz, estamos colocando esse modelo em produção, ou seja, tornando-o uma solução-produto que irá alimentar a empresa de previsões e insights. Em resumo, um software — que processa dados e contém modelos de Machine Learning — mas ainda sim, um software. E, quando o assunto é software, notebooks não se sustentam.

Orientação à objetos
Nada mais satisfatório, após desenvolver um modelo eficiente, do que vê-lo em ação sendo útil para seu propósito! Por isso, fui estudar como tornar minhas soluções (quase sempre, notebooks) soluções altamente produtizáveis e prontas para serem deployadas no ambiente que fosse necessário. Acaba sendo divertido: literalmente elevar o código a um próximo nível. Quando o modelo está feito em Python, a primeira coisa a ser feita é transformar os blocos de código desse notebook em algo orientado à objetos — ou seja, utilizando técnicas de construção de classes, métodos e atributos. Veja o exemplo abaixo que faz uma leitura de dados:

# atributing dataset to a dataframe df
df = pd.read_csv('FuelConsumptionCo2.csv')
df.head()

Seguindo a orientação à objetos, o bloco acima se torna algo nessa linha:

class Loader:

    def load_data(self, url: str):
        """ Carrega o arquivo e retorna um DataFrame.
        :url: string com  o nome/endereço do file
        """  
        return pd.read_csv(url)

# Instanciação das Classes
loader = Loader()

# Parâmetros
url_dados = ('FuelConsumptionCo2.csv')

# carga
data = loader.load_data(url_dados) 

Fica outra coisa né? Além de muito organizado e elegante, eu consigo reutilizar a classe Loader para qualquer projeto que envolva a leitura de dados neste formato, ou mesmo reutilizar essa classe nesse mesmo projeto na hora de ler dados novos, por exemplo.

Decidi pegar um projeto antigo da Pyrentena, o modelo de previsão de emissão de carbono em veículos (que você pode conferir aqui a primeira versão) e transformá-lo em uma solução produtiva. Aproveitei outros recursos que aprendi desde que fiz esse projeto e adicionei uma parte de AutoML na solução, que automatizou a seleção do modelo testando uma série de opções diferentes pensando em, quem sabe, encontrar um resultado superior ao que eu já tinha.

Revisite seus códigos
Leva tempo, mas vale a pena! Com uma boa dose de estudos, refiz os código do notebook antigo em classes que executassem o que eu precisava, e o resultado foi muito interessante. No processo, ainda atualizei o modelo e melhorei sua performance! Na versão 1, eu cheguei em um modelo de Regressão Linear com um r2-score de 68%. Suficiente, mas nada sensacional.

Aproveitei a biblioteca TPOT, de AutoML, pra testar uma série de modelos automaticamente e verificar se havia algum outro que tivesse um desempenho melhor. E claro, tudo isso dentro das classes:

class MLModel:

    def select_best_model(self, cv, X_train, Y_train):
        """ Utiliza AutoML para identificar o melhor modelo de regressão.
        :cv: define a validação cruzada
        :X_train: features da base de treino
        :Y_treino: variável target da base de treino
        """

        # define busca do melhor modelo de regressão
        model = TPOTRegressor(generations=5, population_size=50, scoring='r2', cv=cv, verbosity=2, random_state=1, n_jobs=-1)
        model.fit(X_train, Y_train)
        model.export('best_model.py')
        
        # display resultados do AutoML
        resultado = pd.DataFrame(model.evaluated_individuals_)
        resultado.columns = list(map(lambda x: x[0], resultado.columns.str.split('(')))
        return print(resultado.T)

    def model_trainning(self, X_train, Y_train):
        """ Cria pipeline de treinamento do melhor modelo encontrado na etapa de search.
        :X_train: features da base de treino
        :Y_treino: variável target da base de treino
        """
        best_pipeline = ExtraTreesRegressor(bootstrap=False, max_features=0.25, min_samples_leaf=1, min_samples_split=5, n_estimators=100)
        best_pipeline = best_pipeline.fit(X_train, Y_train)
        return best_pipeline 

Essa é a classe que seleciona o melhor modelo (select_best_model) com o TPOT e já faz o treinamento dele na função abaixo (model_trainning), considerando a métrica que eu escolhi. Depois de criada a classe, instanciei ela e apliquei nos meus dados:

# Instanciação das Classes
model = MLModel()

# Parâmetros
cv = RepeatedKFold(n_splits=10, n_repeats=3, random_state=1) # indicado pelo tpot

# Busca e seleção do melhor modelo com Auto ML
best_model_report = model.select_best_model(cv, X_train, Y_train)

# Treinamento do melhor modelo
best_pipeline = model.model_trainning(X_train, Y_train)

O sentimento é de paz terrível quando a solução vai tomando esse formato. Organização &a possibilidade de reutilização são maravilhas da orientação à objetos e das boas práticas de desenvolvimento de software que não podemos ignorar na hora de desenvolver soluções realmente efetivas. E pra fechar com chave de ouro: a bilbioteca de AutoML encontrou com o modelo ExtraTreesRegressor um desempenho ainda melhor do que a solução tinha: um r2-score de 87%. Nada mal para uma atualização!

Aqui tem o link completo para o notebook atualizado com orientação à objetos. O ideal, após feita essa parte, é separar cada classe em seu próprio script .py e importá-las dentro de um script executor:

from loader import Loader
from pre_processor import PreProcessor
from model_trainning import MLModel
from model_evaluator import MLEvaluator
from model_export import ModelExport

No meu caso, criei um script executor chamado de run_pipeline.py, que importa as classes que eu criei e executa na ordem correta cada uma das etapas:

# Instanciação das Classes
loader = Loader()
pre_processor = PreProcessor()
model = MLModel()
performance_evaluator = MLEvaluator()
export_model = ModelExport()

# Parâmetros
url_dados = ('FuelConsumptionCo2.csv')
redundant_cols = ['MODELYEAR','MAKE','MODEL','VEHICLECLASS','TRANSMISSION','FUELTYPE']
percentual_teste = 0.2
cv = RepeatedKFold(n_splits=10, n_repeats=3, random_state=1) 

def main():
    # Execução do pipeline de treinamento

    # carga
    data = loader.load_data(url_dados) 

    X_train, X_test, Y_train, Y_test = pre_processor.pre_process_data(data, percentual_teste,redundant_cols) 

    # Busca e seleção do melhor modelo com Auto ML
    best_model_report = model.select_best_model(cv, X_train, Y_train)

    # Treinamento do melhor modelo
    best_pipeline = model.model_trainning(X_train, Y_train)

    # Resultados de performance considerando r2 score
    performance_evaluator.avaliar_r2_score(best_pipeline, X_test, Y_test)

    # Export do modelo treinado
    loaded_pkl_model = export_model.export_best_model(best_pipeline)
    
if __name__ == '__main__':
    main()

A estrurua completa do projeto você pode conferir aqui. Cada classe tem seu próprio script: load de dados, pré processamento dos dados, modelo (seleção e treinamento) e avaliação dos resultados — muito mais organizado e fácil de ser deployado do que um notebook! Aproveitei e criei um pipeline bem simples de produção, simulando como seria a utilização contínua do modelo. Pra isso, salvei o modelo em pickle file e criei uma classe que aplica esse modelo na leitura de novos dados (reutilizando a classe Loader).

# Instanciação das Classes
loader = Loader()
preprocess_deploy = PreProcessorDeploy()
generate_output = Output()
load_model = LoadModel()

# Parâmetros
redundant_cols = ['MODELYEAR','MAKE','MODEL','VEHICLECLASS','TRANSMISSION','FUELTYPE']
new_file = "brand_new_data.csv"
pkl_model_file = 'model.pkl'

def main():
    # Execução do pipeline de produção

    # carga
    new_data = loader.load_data(new_file) 

    # processamento dos novos dados
    X = preprocess_deploy.pre_process_new_data(new_data, redundant_cols)

    # load do modelo treinado
    loaded_pkl_model = load_model.load_trained_model(pkl_model_file)

    # aplicação do modelo já treinado
    predicoes = loaded_pkl_model.predict(X)

    # geração e export do arquivo de predições em csv
    generate_output.create_output_dataframe(new_data, predicoes)

if __name__ == '__main__':
    main()

Vale lembrar que cada ambiente ou empresa tem sua própria forma de produtizar as soluções, com especificidades bastante particulares. Mas te garanto que utilizar a orientação à objetos e organizar sua solução em scripts .py, da mesma forma que um software é 80% do caminho andado na hora de qualquer deploy!

Os scripts da versão 2 do modelo de previsão de emissão de carbono estão disponíveis aqui. Vale comparar com a versão 1, também disonível para consulta.

Largando os cadernos: de notebooks à scripts .py was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Testei mais de 10 modelos ao mesmo tempo com essa biblioteca

Quando ouço a palavra automatização relacionada à ciência de dados, confesso que fico desconfiada. Otimizar e automatizar a parte matemático-estatística sempre parece uma boa ideia, mas como automatizar uma interpretação baseada em conceitos de negócio? Em entendimento do problema? Dois passos pra traz parecem necessários quando ouço esse tipo de promessa.

Foi com muito entusiasmo e uma bolsa cheia de ressalvas que testei uma das ferramentas de AutoML disponíveis no mercado: o TPOT, um verdadeiro assistente de ciência de dados. TPOT é uma ferramenta de aprendizado de máquina automatizado em Python, cujo foco é otimizar pipelines de Machine Learning utilizando programação genética(!).

Meu desafio era um problema de classificação, por isso importei o TPOT Classifier, mas tem a opção de regressores também. A ideia dessa lib é que, ao passar seu dataset de treino e teste e setar alguns parâmetros de comparação (como por exemplo, qual métrica de avaliação você quer utilizar) o próprio pacote testa mais de 10 modelos diferentes &gera um dataframe com a performance de cada um. Em seguida, é só exportar seu ‘best_model’ em um arquivo .py, também gerado automaticamente pelo TPOT. Incrível né?

Implmentando o TPOT no seu pipeline

Antes de tudo, é preciso splitar seu dataset já limpo e tratado em treino e teste, setando sua coluna de ‘id’ como index para que o TPOT possa identificar corretamente as colunas.

X_treino = X_treino.set_index('id')
X_teste = X_teste.set_index('id')
y_treino = y_treino.set_index('id')
y_teste = y_teste.set_index('id')

Feito isso, importamos o TPOTClassifier, que pode ser chamado após instalar localmente a bilbioteca no seu notebook via !pip install. Primeiro, criamos nosso classificador dentro da variável ‘tpot’ preenchendo os parâmetros necessários. Nesse caso, por exemplo, setei como tempo máximo de teste 120 minutos e métrica de avaliação a ROC_AUC.

from tpot import TPOTClassifier
import numpy as np

tpot = TPOTClassifier(verbosity=3, n_jobs=-1, max_time_mins=120, scoring='roc_auc', random_state=0, cv=6, generations=None, population_size=100, early_stop=True, log_file='tpot_classifier.txt')

Em seguida, fitamos nossos dados de treino no tpot e chamamos a função ‘score’ em cima dos nossos dados de teste, printando os resultados obtidos pra que possamos avaliá-los:

tpot.fit(X_treino, y_treino.values.reshape(-1,))

print(tpot.score(X_teste,y_teste.values.reshape(-1,)))

Para uma melhor visualização dos resultados, o código abaixo vai colocar seus resultados em formato de dataframe, formatar as colunas e transpor a visualização

resultado = pd.DataFrame(tpot.evaluated_individuals_)
resultado.columns = list(map(lambda x: x[0], resultado.columns.str.split('(')))
resultado.T

O resultado final se parece com o print abaixo: os nomes dos modelos são o index, as colunas são os parâmetros que setamos para teste do modelo e a última coluna é a performance do modelo em si. Nesse exemplo, o modelo ExtraTreeClassifier foi o que melhor performou nos meus dados de teste, retornando uma curva roc de 0.85. Para exportar o modelo de melhor perfomance automaticamente em um arquivo py, basta executar a linha tpot.export(best_model.py)

Foi uma experiência muito interessante trabalhar com o TPOT. Vale ressaltar que os parâmetros setados para teste e avaliação dos modelos são extremamente importantes e vão definir o sucesso da sua seleção! Para entender exatamente o que cada um deles significa, confira a documentação oficial. Existem outras ferramentas de AutoML por aí, além das disponibilizadas dentro das próprias clouds! Vou compartilhando minhas percepções conforme for testando :)

Model selection com AutoML was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Cases e ferramentas para uma gestão ativa do viés em IA

Eu sempre lembro da Catarina, radiante de trazer a Alexa pra casa — e no minuto seguinte gritando pelos corredores tentando com que a IA entendesse seu sotaque nordestino carregado.

Fazer uma gestão ativa do viés em aplicações de dados não é só importante, é mandatório pra construir produtos que contemplem o tamanho desse mundo.

Contei no GB Tech alguns cases que mexeram comigo, soluções e frameworks que encontrei na academia & algumas reflexões do curso de ML Ethics da FastAI (gratuito, tem link no final do texto).

Trabalhar com dados também é trabalhar com gente.

Pra ler o artigo completo só clicar aqui.

Data Ethics e o desenvolvimento de soluções inclusivas was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

Onde vivem, do que se alimentam e ferramentas pra você conhecer!

Machine Learning Ops tá na crista da onda, e esse conceito se refere a nada mais nada menos do que o processo de transformar um modelo experimental de Machine Learning em um sistema de produção — bebendo nas melhores práticas de desenvolvimento de software que a galera de DevOps traz à tona.

MLOps toca em um tema que tem me interessado bastante ultimamente: software AI. Como transformar nossos modelos em aplicações digitais otimizadas e verdadeiros produtos completos? Afinal, uma coisa é desenvolver um modelo localmente no nosso Jupyter Notebook de todo dia e ter um bom f1 score nas predições — outra, um tanto diferente, é implementar esse algoritmo na vida real para ser consumido por um — ou vários — times de negócio.

A palavra é um composto de “Aprendizado de Máquina” e a prática de desenvolvimento contínuo de DevOps, área de software que garante um bom versionamento e qualidade das aplicações a partir da integração entre os devs (ou cientistas de dados) e a equipe de infraestrutura.

Na prática, MLOps inclui avaliação das estruturas de desenvolvimento e deploy de uma empresa (é Cloud? Se sim, qual delas?), o entendimento da estratégia de negócio dessa empresa (onde esse cliente quer chegar? Custo é uma questão? Ou a curva de aprendizado do time é mais importante, por exemplo?) e, por fim, o desenho de uma arquitetura ou esteira que contemple as ferramentas/práticas/processos ideais para que a empresa atinja seus objetivos e tenha qualidade nos modelos de Machine Learning que ela possui.

4 características que a sua esteira de MLOps precisa ter

1. Reprodutibilidade & escalabilidade
Quanto mais reutilizável sua estrutura for, melhor! Isso significa que ela atende a diferentes tipos de modelos, sejam eles construídos com Tensorflow, Scikit Learn, PyTorch, Spark… Boas práticas de conteinerização e encapsulamento podem facilitar a transição do modelo do ambiente de desenvolvimento para o ambiente de produção e facilitar o reuso da esteira por diferentes squads das empresas. O Kubeflow é uma ferramenta open source que permite o reuso de pipelines e roda em Kubernetes, garantindo a escalabilidade do processamento da aplicação.

2. Tracking de experimentos
A experimentação pode envolver o teste de diferentes combinações de código (métodos de pré-processamento, treinamento e avaliação), dados e hiperparâmetros. Um modelo com os hiperparâmetros default, modelo pós aquele fine tunning maroto…. Cada combinação produz métricas específicas que você precisa saber para comparar com seus outros experimentos e selecionar o modelo que teve melhor performance! Além disso, mudanças nas condições (ambiente) em que o experimento é executado podem alterar as métricas obtidas. Algumas ferramentas interessantes para fazer esse tracking de modelos de forma intuitiva e automatizada são MLFlow e Neptune.

3. Versionamento
Modelagem não se finaliza, se abandona: podemos sempre querer melhorar gradualmente a precisão ou a área de aplicação do modelo. Assim, o algoritmo está sempre evoluindo como código — e deve ser tratado dessa forma. Isso significa que a escolha do modelo (e seus hiperparâmetros) deve ter seu próprio versionamento garantido. Quando se trata de controle de versão, devemos tratar o modelo de maneira semelhante a como tratamos versionamento de código: com boas práticas de abertura de Pull Request em uma branch secundária, aprovação de outros desenvolvedores antes de merge na branch principal, etc. Com essa abordagem, você é capaz de reverter os modelos com facilidade e até ter um versionamento dos metadados gerados. Uma ferramenta interessante para fazer esse versionamento, além do GitLab da massa, é o Data Version Control.

4. Monitoramento
O mundo gira, pandemias acontecem, e o seu projeto envelhece, deixando de fornecer previsões condizentes. Felizmente, esse sistema de scoragem e monitoramento existe pra que possamos saber exatamente quando intervir em um modelo — ou refazê-lo por completo! Algumas métricas como PSI e CSI podem verificar se a sua população de dados se modificou, dando aquele check nas variáveis e avaliando se elas ainda estão refletindo a sua base de dados com eficácia e servindo para o bom funcionamento do modelo. Ferramentas como Elastic Search e Prometheus fazem o monitoramento de métricas de execução e contemplam o disparo de trigger que te avisam quando a performance cair.

Esses são alguns conceitos pra ter em mente na hora de desenhar uma esteira de MLOps — tem muitos outros e vai depender da maturidade & estratégia da empresa quais são as essenciais no momento! O arsenal de ferramenta open source é enorme, se divirta na experimentação:)

Esse tal de MLOps was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.

É menos sobre data e mais sobre science.

Quando te oferecem a oportunidade de tocar o front de um projeto de Inteligência Artificial, não é hora de pensar se você dá conta — é hora de fazer o pinguim de Madagascar e sorrir&acenar que sim, vamos nessa! Afinal, uma chance dessas não bate na porta todos os dias. Além disso, se o mundo acha que tu consegue, quem é você pra dizer que não?

As dores e as delícias de estar na linha de frente são muitas, e o aprendizado então… Nem se fala. Compartilho aqui um pouco do que absorvi com essa baita experiência que, no fim do dia, é muito mais sobre as soft do que sobre as hard skills.

Não dispense os processos — nem no mais apertado dos prazos.

Atrasar uma entrega é muitas vezes desenhado como o pior cenário, mas acredite, nenhuma bomba vai explodir se você precisar de uma semana a mais. Especialmente se esse tempo extra garantir consistência e qualidade! Pra ‘entregar mais rápido’ muitas vezes podemos atropelar processos essenciais, que vão definir a qualidade da sua aplicação em produção. Respeitar o ciclo do new branch — pull request — revisão do Github é importantíssimo pra garantir um bom versionamento do código e facilitar a vida lá na frente, quando as alterações inevitavelmente surgirem. Testes constantes dos scripts, confirmação por escrito das pendências e até uma rápida ata das reuniões enviadas aos participantes por e-mail, por que não? São processinhos como esse de confirmação de demandas que facilitam o alinhamento de expectativas, mantendo todo mundo na mesma página e, principalmente, falando a mesma língua. É surpreendente o tanto de mal entendido e erros que podem ser evitados simplesmente confirmando se estamos alinhados que A é A e B e B.

Traçar limites é tarefa sua.

Ninguém é obrigado a saber até onde você aguenta. Isso significa que, enquanto você estiver aceitando, as demandas vão sim continuar vindo — e é nessa hora que saber dizer não é de suma importância. Pessoalmente foi um processo novo pra mim, acostumada a dizer sim primeiro e me virar sobre como fazer, depois. A verdade é que sempre vai ter coisa pra fazer, sempre vai ter algo que poderia estar mais adiantado do que está hoje e que, se você não souber ‘desligar’ e virar a chavinha no final de semana, simplesmente vai emendar uma semana na outra e ser engolido pelas pré-ocupações. Meditar ajuda bastante, pratico há alguns anos e é uma âncora de paz em meio ao caos. Aconselho ter em mente que dizer ‘não’, não faz de você um mal profissional ou uma pessoa ruim! É simplesmente um traçado de limite, dizendo que, a partir daqui, hoje não. Talvez amanhã sim, mas hoje não. E presta atenção: quem se incomodar demais com seus limites é quem se beneficiava quando você não tinha eles bem definidos!

Peça ajuda.

Líder ou não líder, já se acostume com a ideia de que você não vai acertar sempre E não vai ter todas as respostas. Fazer as pazes com os erros é urgente pra dormir à noite e confia, eles fazem de você humano, não um incompetente. Não é porque você é o frontend que tem que ter todas as soluções, pelo contrário: acredito muito que as melhores lideranças são aquelas fundadas no pilar da humildade, que, ao deparar-se com algo que não sabem resolver, consultam a equipe, seus superiores, o cliente, os universitários e quem mais for preciso pra fazer uma boa entrega. Não é sobre você, sobre se proteger, se blindar — é sobre o projeto, e garantir uma aplicação de sucesso muitas vezes significa ser vulnerável, pedir ajuda, ou admitir que não sabe pra onde ir. A gente é melhor junto do que separado e tem muita gente boa nesse mundo! Ser inacessível é fora de moda e pouco produtivo.

Pra fechar, um conselho do jornalismo pra vida: negocia esse deadline, que o não você já tem :)

3 coisas que aprendi liderando projetos de Data Science was originally published in Joguei os Dados on Medium, where people are continuing the conversation by highlighting and responding to this story.