Alguns pensamentos teóricos e aleatórios com relação à Machine Learning (sem código, sem matemática e sem papas na língua)
Photo by XPS on Unsplash

Alguns pensamentos teóricos e aleatórios com relação à Machine Learning (sem código, sem matemática e sem papas na língua)

Originalmente, esse artigo seria somente uma postagem no LinkedIn, mas eu me empolguei e escrevi mais do que o permitido para uma simples postagem.

Hoje é domingo. Não tinha muita coisa pra fazer e, de praxe, comecei a olhar vídeos no YouTube e caí neste vídeo da Julia Silge sobre modelagem: Modeling hotel bookings in R using tidymodels and recipes. Essa mulher é simplesmente fantástica e é uma das principais desenvolvedoras do RStudio. No segundo 24:10 deste vídeo, ela aplica uma técnica popular em Machine Learning chamada rebalanceamento sem dar maiores detalhes do que era e aquilo me deixou levemente inquieto.

Como estatístico de formação, eu gostaria de colocar em discussão alguns pontos e queria saber a opinião de outras pessoas com relação à eles e se estou falando bobagem, pois certamente tem gente mais experiente e inteligente do que eu que vai ler isso.

Ponto 1) Na maioria esmagadora dos casos, não há nenhum problema em treinar um modelo com dados desbalanceados e o uso de "Upsampling", "Downsampling", "SMOTE", etc., etc., não é justificado. Manter o desbalanceamento muitas vezes é bom, tendo em vista que o balanceamento artifical muda a distribuição dos dados o que exige tratamento posterior após ajuste da modelagem. Isto pode ser desastroso caso este detalhe não seja levado em consideração. Por exemplo, as probabilidades geradas por um modelo rebalanceado não podem ser usadas diretamente e exige tratamento posterior para voltar à escala original (para maiores discussões, clique em Probability Calibration for Imbalanced Classification).

No entanto, o rebalanceamento pode ser justificado em dois casos:

  • Quando existe uma assimetria de custos entre falsos positivos e falsos negativos e seu modelo deve levar isso em consideração.
  • Quando você usa uma métrica mais "dura" para avaliar o modelo como por exemplo a Acurácia em tabela de confusão com um ponto de corte fixo (mas quem usaria somente a Acurácia como métrica de avaliação?)

O melhor link para essa discusão que encontrei é este What is the Root Cause of the Class Imbalance Problem?. Neste link, um parágrafo me chamou a atenção na discussão:

"A survey of the standard texts in machine/statistical learning turns up little:
- Elements of Statistical Leaning and Introduction to Statistical Learning do not contain "class imbalance" in the index.
- Machine Learning for Predictive Data Analytics also does not contain "class imbalance" in the index.
- Murphy's Machine Learning: A Probabilistic Perspective does contain "class imbalance" in the index. The reference is to a section on SVM's, where I found the following tantalizing comment:
"It is worth remembering that all these difficulties, and the plethora of heuristics that have been proposed to fix them, fundamentally arise because SVM's do not model uncertainty using probabilities, so their output scores are not comparable across classes."

Ponto 2) Com relação à estratégias de validação, sempre achei curioso essa ideia de "jogar fora" uma parte dos dados no modelo final. A divisão entre treino e teste é importante para validação do modelo e saber como que ele vai se comportar fora da amostra. Mas, uma vez o modelo está treinado e "decidido" com relação aos hyperparâmetros, não faria mais sentido usar todos os dados? Toda a discussão entre "vício x variância" entre predições gira em torno do grau de complexidade do modelo e não do tamanho da amostra usada pra treino. Em geral, acredito que a estratégia de validação mais comumente utilizada segue o diagrama abaixo:

A fluxo mais famoso de estratégia de validação

No livro clássico "The Elements of Statistical Learning" do Hastie & Tbishirani Cp.7, pg.222, 2nd Edition, essa discussão aparece no contexto de "data-rich situation" o que me parece ser o caso no mundo de Big Data. Logo, não teria problema em "jogar fora" uma quantidade de dados. Segue esse trecho abaixo:

No alt text provided for this image

No entanto, me parece que fazer um cross-validation (CV) com toda a base original e usar as métricas do CV para medir performance do modelo é correto, mas o modelo final (quando "decidido") ser treinado com toda a amostra original, faria mais sentido. Porém, essa visão tem a ressalva de que o "melhor modelo" não estaria validado em dados nunca antes visto...

Lendo algumas coisas na internet cheguei em algumas postagens interessantes. A primeira, e mais interessante, é esta: Train Final Machine Learning Model. Neste blog, um ponto que me chamou a atenção foi esta discussão:

"Won’t the performance of the model trained on all of the data be different?
I think this question drives most of the misunderstanding around model finalization.
Put another way:
If you train a model on all of the available data, then how do you know how well the model will perform?
You have already answered this question using the resampling procedure.
If well designed, the performance measures you calculate using train-test or k-fold cross validation suitably describe how well the finalized model trained on all available historical data will perform in general.
If you used k-fold cross validation, you will have an estimate of how “wrong” (or conversely, how “right”) the model will be on average, and the expected spread of that wrongness or rightness."

Outro link interessante sobre essa discussão é este: How to Choose a Predictive Model After K-Fold Cross Validation. Alguns pontos interessantes deste outro link:

"Overfitting has to do with model complexity, it has nothing to do with the amount of data used to train the model."
"Let's get some terminology straight, generally when we say 'a model' we refer to a particular method for describing how some input data relates to what we are trying to predict. We don't generally refer to particular instances of that method as different models. So you might say 'I have a linear regression model' but you wouldn't call two different sets of the trained coefficients different models. At least not in the context of model selection."

Talvez a melhor justificativa que eu encontrei sobre o uso da base de teste tenha sido essa resposta desse blog. A resposta parece fazer sentido quando leva-se em consideração todo o pipeline de criação de um modelo.

Ponto 3) Creio que a Area Under the Curve (AUC) é mais robusta que a estatística de Kolmogorov-Smirnov (o famoso KS). Em geral, o KS é uma medida boa para qualidade de modelos, mas quando existe sobreposição de distribuições e, principalmente, se as distribuições acumuladas "se cruzam" ela se torna um problema. A explicação geral pode ser sumarizada nesse comentário do principal criador do caret/tidymodels, Max Kuhn, neste link do GitHub:

No alt text provided for this image

Ponto 4) "Iterate over your data and not over your model" é uma máxima bem importante. Acredito que vale muito mais a pena despender energia pensando na base de dados e no problema a ser solucionado, do que no modelo a ser estimado, tunagem de hyperparâmetros, etc. Um vídeo super didático de um dos maiores speakers nas principais conferências de Python do mundo, Vincent Warmerdam, exemplifica esse ponto de maneira muito didática neste vídeo: Winning with Simple, even Linear, Models.

Enfim, galera, esses eram alguns pontos que queria registrar aqui. Qualquer contribuição é bem-vinda! Abraço!

Gennaro Anesi

Data Science Manager @ Meta

3 a

Quase esqueço de comentar: lembro de discutir o ponto 1 nos idos de 2016 (!) ao discutir abordagens para modelagem de oferta de produtos. Fui voto vencido na ocasião - agora teria um aliado de peso para defender a minha posição 😂. Meu entendimento é que uma boa parte dos modelos não possui uma suposição sobre uma distribuição equivalente das classes, o que levanta dúvidas sobre a necessidade de balanceamento. Tentando identificar a origem desses consensos metodológicos, parece-me que eles surgem com um escopo - corretamente - mais limitado (por exemplo, “em situação X o KS é uma boa medida”), mas a popularidade e facilidade de implementação terminam por remover essas restrições ao longo do tempo.

Cristiane Quadros dos Santos

Servidora Pública Municipal/Economista | Gestão de Pessoas | Gestão de Projetos | Turismóloga | Marketing Digital | Apaixonada por viagens!

3 a

Excelente conteúdo do teu artigo! parabéns!!!

Felipe S.

Superintendente de Políticas de Crédito no Inter | Credit Data & Analytics | Decision Intelligence

3 a

Bacana demais Renan! Esse tipo de discussão é bem relevante. O ponto 4, em particular, ajuda a explicar o que, na minha opinião, contribui para reduzir a geração de valor em um projeto de ML: preocupação excessiva com a tecnologia/algoritmo combinado com pouco entendimento e qualidade dos dados.

Daniel Adornes

ML Ops | Stanford GSB | MSc. Computer Science

3 a

Top, Renan! O ruim do teu artigo é que ele termina! :) Obrigado por compartilhar! Abraço

Entre para ver ou adicionar um comentário

Outras pessoas também visualizaram

Conferir tópicos