Análise de Múltipla Correspondência no R para o problema de Churn

Via Data Science Plus

Analytical challenges in multivariate data analysis and predictive modeling include identifying redundant and irrelevant variables. A recommended analytics approach is to first address the redundancy; which can be achieved by identifying groups of variables that are as correlated as possible among themselves and as uncorrelated as possible with other variable groups in the same data set. On the other hand, relevancy is about potential predictor variables and involves understanding the relationship between the target variable and input variables.
Multiple correspondence analysis (MCA) is a multivariate data analysis and data mining tool for finding and constructing a low-dimensional visual representation of variable associations among groups of categorical variables. Variable clustering as a tool for identifying redundancy is often applied to get a first impression of variable associations and multivariate data structure.
The motivations of this post are to illustrate the applications of: 1) preparing input variables for analysis and predictive modeling, 2) MCA as a multivariate exploratory data analysis and categorical data mining tool for business insights of customer churn data, and 3) variable clustering of categorical variables for the identification of redundant variables.

Análise de Múltipla Correspondência no R para o problema de Churn

Previsões para Deep Learning para 2017

Por James Kobielus da IBM.

(…)The first hugely successful consumer application of deep learning will come to market: I predict that deep learning’s first avid embrace by the general public will come in 2017. And I predict that it will be to process the glut of photos that people are capturing with their smartphones and sharing on social media. In this regard, the golden deep-learning opportunities will be in apps that facilitate image search, auto-tagging, auto-correction, embellishment, photorealistic rendering, resolution enhancement, style transformation, and fanciful figure inception. (…)

(…)A dominant open-source deep-learning tool and library will take the developer community by storm: As 2016 draws to a close, we’re seeing more solution providers open-source their deep learning tools, libraries, and other intellectual property. This past year, Google open-sourced its DeepMind and TensorFlow code, Apple published its deep-learning research, and the OpenAI non-profit group has started to build its deep-learning benchmarking technology. Already, developers have a choice of open-source tools for development of deep-learning applications in Spark, Scala, Python, and Java, with support for other languages sure to follow. In addition to DeepMind and TensorFlow, open tools for deep-learning development currently include DeepLearning4J, Keras, Caffe, Theano, Torch, OpenBLAS and Mxnet.(…)

(…)A new generation of low-cost commercial off-the-shelf deep-learning chipsets will come to market: Deep learning relies on the application of multilevel neural-network algorithms to high-dimensional data objects. As such, it requires the execution of fast-matrix manipulations in highly parallel architectures in order to identify complex, elusive patterns—such as objects, faces, voices, threats, etc. For high-dimensional deep learning to become more practical and pervasive, the underlying pattern-crunching hardware needs to become faster, cheaper, more scalable, and more versatile. Also, the hardware needs to become capable of processing data sets that will continue to grow in dimensionality as new sources are added, merged with other data, and analyzed by deep learning algorithms of greater sophistication. (…)

(…)The algorithmic repertoire of deep learning will grow more diverse and sophisticated: Deep learning remains a fairly arcane, specialized, and daunting technology to most data professionals. The growing adoption of deep learning in 2017 will compel data scientists and other developers to grow their expertise in such cutting-edge techniques as recurrent neural networks, deep convolutional networks, deep belief networks, restricted Boltzmann machines, and stacked auto-encoders. (…)

Previsões para Deep Learning para 2017

Novo pacote do R – forecastHybrid

Direto do Peter Stats Blog

The new forecastHybrid package for R by David Shaub and myself provides convenient access to ensemble time series forecasting methods, in any combination of up to five of the modelling approaches from Hyndman’s forecast package. These are auto-selected autoregressive integrated moving average; exponential smoothing state space (both ets and tbats); feed forward neural network with a single hidden layer and lagged inputs; and forecasts of loess-based seasonal decomposition.

Background and motivation
In an earlier post I explored ways that might improve on standard methods for prediction intervals from univariate time series forecasting. One of the tools I used was a convenience function to combine forecasts from Rob Hyndman’s ets and auto.arima functions. David Shaub (with a small contribution from myself) has now built and published an R package forecastHybrid that expands on this idea to create ensembles from other forecasting methods from Hyndman’s forecast package.

The motivation is to make it easy to improve forecasts, both their point estimates and their prediction intervals. It has been well known for many years that taking the average of rival forecast methods improves the performance of forecasts. This new R package aims to make it as easy for people to do this as to fit the individual models in the first place.

Novo pacote do R – forecastHybrid

Gradient Boosted Trees Model no Microsoft R Server

Direto do Revolutions Blog

R is an open source, statistical programming language with millions of users in its community. However, a well-known weakness of R is that it is both single threaded and memory bound, which limits its ability to process big data. With Microsoft R Server (MRS), the enterprise grade distribution of R for advanced analytics, users can continue to work in their preferred R environment with following benefits: the ability to scale to data of any size, potential speed increases of up to one hundred times faster than open source R.

In this article, we give a walk-through on how to build a gradient boosted tree using MRS. We use a simple fraud data data set having approximately 1 million records and 9 columns. The last column “fraudRisk” is the tag: 0 stands for non-fraud and 1 stands for fraud. The following is a snapshot of the data.

Gradient Boosted Trees Model no Microsoft R Server

DL-Learner – Framework para Aprendizado de Máquina

The DL-Learner software learns concepts in Description Logics (DLs) from examples. Equivalently, it can be used to learn classes in OWL ontologies from selected objects. It extends Inductive Logic Programming to Descriptions Logics and the Semantic Web. The goal of DL-Learner is to provide a DL/OWL based machine learning tool to solve supervised learning tasks and support knowledge engineers in constructing knowledge and learning about the data they created.

Purposes of Class Expression Learning

  1. Learn Definitions for Classes: Based on existing instances of an OWL class, DL-Learner can make suggestions for class definitions to be included as an owl:equivalentClass or rdfs:subClassOf Axiom. As the algorithm is biased towards short and human readable definitions, a knowledge engineer can be supported when editing the TBox of an ontology (see Protege Plugin).
  2. Find similar instances: DL-Learner’s suggested class expressions can be used to find similar instances via retrieval (Concept definitions as search). Scalable methods allow the generation of recommendations on the fly, e.g. in a web scenario (see DBpedia Navigator – in experimental stage).
  3. Classify instances: The learned class descriptions can be used in a typical classification scenario, i.e. to decide for unknown instances whether they belong to a certain class. Common ILP benchmarks have been tested with DL-Learner. On the Carcinogenesis page, DL-Learner competes with other state-of-the-art ILP algorithms.


  1. Instance Classification: A user maintains a list of favorites. Based on these favorites, OWL Concepts are learned with DL-Learner and presented to the user in Natural Language. Such a concept could be all articles about proteins that are written by researchers from Germany (e.g. in Manchester syntax: Proteins and hasAuthor some (Person and hasLocation some Germany)). New articles, which fall in this category and are added to the knowledge base, are presented to the user automatically, like a customized RSS feed.
  2. Protégé: In a family ontology, a Protégé user wants to create a definition for the Concept ‘Father’. He / She already asserted some instances to the class Father. Now, the DL-Learner Protege plugin presents the definition (in Manchester OWL syntax): Male and hasChild some Thing.


The application is written in Java. A user manual can be found PDF Documenthere. Also there is an overview, a page about its architecture, and a feature list Features. DL-Learner is available as Open-Source at Sourceforge.

It has different learning algorithms, which offer several parameters for fine-tuning. It can solve four closely related learning problems: learning based on positive and negative examples, positive only learning, and learning definitions and subclass relationships in ontologies.


As reasoning is heavily used by DL-Learners algorithms, special methods were introduced to increase performance:

  1. Fast Instance Checker is a reasoning component, that is custom tailored for the needs of DL-Learner. After an initial reasoning step on the basis of Pellet, results are pre-calculated and cached. Besides the significant performance boost, the component can optionally apply a form of closed world reasoning, which allows to learn expressions like forall and max/min cardinality. It is an approximate reasoning method, where as usual rare cases of incomplete reasoning results are justified by a huge increase in performance.
  2. DL-Learner can also provide class suggestions for very large knowledge bases, since it uses local fragment reasoning, i.e. only the relevant part (which is small) is used for learning new classes. This enables class learning in real time on knowledge bases like DBpedia. More information can be found PDF Documenthere.
DL-Learner – Framework para Aprendizado de Máquina

Análise Exploratoria de Dados utilizando gráficos

É fato que a inconsistência de dados acaba com qualquer tipo de modelagem em Data Mining.

Dessa forma, ANTES de qualquer experimento com data mining é sempre desejável que se faça uma análise exploratória de dados utilizando estatísticas descritivas, gráficos, formulação de hipóteses para uma definição clara de quais técnicas serão utilizadas.

Esse post do Eli Bressert apresenta um tutorial muito bom usando R para a utilização de gráficos na análise exploratória de dados.

Análise Exploratoria de Dados utilizando gráficos

Comparação entre R e Python utilizando Florestas Aleatórias e Classificação

Neste post do blog do Yhat tem o código, os dados e os resultados.

Pessoalmente gosto muito da abordagem dos autores em comparação de classificadores usando as métricas de Acurácia, Erro Quadrático Médio e  para regressão e tempo de treinamento.

Para projetos curtos de avaliação de uma série de classificadores essas medidas são suficientes para dar uma linha de base. Essas medidas podem auxiliar na escolha de quais modelos estão com melhor convergência e podem indicar um melhor tratamento dos dados em termos de quais variáveis são pertinentes ao modelo escolhido.



Comparação entre R e Python utilizando Florestas Aleatórias e Classificação

Minerando grandes bases de dados no WEKA

Um dos maiores problemas quando lidamos com o Weka é a irritante limitação do Java Heap Siza de 2gb, e sendo expansível de acordo com o método descrito aqui até o volume de memória físico da plataforma de ensaios. 

No entanto, nesse excelente comunicado dos desenvolvedores do Weka eles informam que como solução para economia de recursos é sempre preferível usar linha de comando; e que há atualmente bibliotecas que estão trabalhando com subamostragem para tornar mais escalável o uso do Weka para mineração de bases de dados com um alto volume de registros.

Minerando grandes bases de dados no WEKA

Pedindo ajuda sobre o Weka

Como alguns sabem o Weka é uma GUI de código aberto e ao contrário de algumas empresas que ostentam títulos de líderes de mercado (cof, cof, cof) tem uma comunidade ativa em volta da aplicação.

Há duas maneiras de pedir ajuda:

1) Cadastrando-se na lista e enviando a solicitação em e-mail em inglês (sim, o inglês é o novo latim como eu coloquei aqui em 2012) que é algo extremamente rápido.


2) Buscando nos arquivos da lista. Aqui é a melhor chance de achar algo para sanar uma dúvida. E o melhor de tudo: Dá para fazer download de tudo de graça!!!

Agora acabaram-se as desculpas para ficar travado naquele probleminha com a LMT ou com o Naive Bayes.

Pedindo ajuda sobre o Weka

Não terceirize a Normalização/Padronização dos Dados

Na literatura de mineração de dados muitos autores afirmam que o pré-processamento é uma fase que ocupa 80% do tempo e que os algoritmos são as grandes estrelas com as suas inúmeras formas de descoberta de padrões, regras e associações; e que por isso detêm os 20% mais importantes no que diz respeito à mineração de dados.

Baseado em experiências empíricas acredito que o pré-processamento ocupa 90% do tempo, e que também é responsável por 95% do resultado; dentro da perspectiva da mineração de dados no qual:

Resultado = Custo Computacional  + Consistência dos Resultados + Reprodutibilidade

Onde o custo computacional é definido como:

 Custo Computacional = Custo Espacial + Custo Temporal

Dito isso, vejo que em fóruns e até mesmo palestras que devido ao grau de dificuldade de trabalhar com os dados, ocorre a famosa terceirização da normalização/padronização dos dados. Isso se dá na forma em que os algoritmos/soluções de análise de dados pegam todos os dados e simplesmente ‘fazem a mágica acontecer’ (acreditem, eu vi um ‘Sales Engineer’  de uma das top 3  ferramentas de Business Intelligence (pela Gartner) falar isso).

No entanto, em alguns pré-experimentos com MARS (Multivariate Adaptive Regression Splines) no Statistica 10 e MLPRegression no Weka observei que muitos valores das variáveis de resposta (i.e. valores para realizar o teste e/ou checagem matemática do algoritmo) estavam com números que não faziam sentido algum, e pior: não davam a reprodutibilidade necessária para exercer um simples hindcast (não confundam com backtesting).

Vejamos dois casos práticos a respeito disso.

Neste primeiro caso vejam o resultado do RBF Regressor no Weka que está abaixo:

=== Run information === 
Scheme:       weka.classifiers.functions.RBFClassifier -N 2 -R 0.01 -L 1.0E-6 -C 1 -G -A -P 1 -E 1 -S 1 
 Relation:     WekaExcel-weka.filters.unsupervised.attribute.Remove-R8-weka.filters.unsupervised.attribute.Remove-R1,
 Instances:    671 
 Attributes:   5 
 Test mode:    evaluate on training data 
 === Classifier model (full training set) === 
 Output weights for different classes: 
 -0.658867061591664 0.7268781531574563 
 Unit center: 
 1.103191478913074 0.3187908580844808 1.339867551710916 -2.348360195617461 
 Output weights for different classes: 
 7.294836535867017 -7.294947917203681 
 Unit center: 
 0.001306958680758934 -0.001914844611731498 6.641791379162694E-4 1.0009616503748857 
 Attribute weights: 
 1.2177544598559824 1.0557440195728327 1.6425390340750194 3.7580013072113965 
 Bias weights for different classes: 
 -1.1716428958295801 1.171406635309079 
 Time taken to build model: 0.33 seconds


Até aí nada demais, basta ver qual é o teste dos coeficientes regressores e substituir os coeficientes para posteriormente realizar o cálculo, certo?

Até aí perfeito, mas tem um pequeno problema: todas as variáveis do modelo são nominais e o classificador já fez a normalização os dados. Ou seja, neste exato momento você transformou o modelo em black box, mesmo com todos os coeficientes expostos. Ou seja, a transparência do modelo foi trocada pelo fato da não normalização dos dados.

Neste segundo exemplo vamos ver o resultado de uma RBFNetwork no Weka.

=== Classifier model (full training set) ===
 Radial basis function network
(Linear regression applied to K-means clusters as basis functions):
 Linear Regression Model
 Dummy_Paid =
      -0.2146 * pCluster_0_0 +
      0.2148 * pCluster_0_1 +

Neste caso, estou ainda com as mesmas variáveis nominais.

Uma das propriedades da RBFNetwork no Weka, é que a grosso modo o algoritmo permite a escolha do número de clusters e porteriormente implementa uma função de base radial (i.e. realiza a atribuição de valores partindo do distanciamento de um centro) para realizar a classificação.

Abaixo a descrição do algoritmo:

Class that implements a normalized Gaussian radial basisbasis function network.
It uses the k-means clustering algorithm to provide the basis functions and learns either a logistic regression (discrete class problems)
or linear regression (numeric class problems) on top of that. Symmetric multivariate Gaussians are fit to the data from each cluster. 
If the class is nominal it uses the given number of clusters per class. It standardizes all numeric attributes to zero mean and unit variance.

debug -- If set to true, classifier may output additional info to the console.
ridge -- Set the Ridge value for the logistic or linear regression.
maxIts -- Maximum number of iterations for the logistic regression to perform. Only applied to discrete class problems.
clusteringSeed -- The random seed to pass on to K-means.
minStdDev -- Sets the minimum standard deviation for the clusters.
numClusters -- The number of clusters for K-Means to generate.

A frase mais importante é “It standardizes all numeric attributes to zero mean and unit variance.”

Isso é, o algoritmo realiza a padronização (a re-escala) de todos os atributos numéricos dentro de um range numérico que supõe que os dados estejam em uma distribuição normal padrão que tem média zero e que a unidade variação tem como base a variância.

Sabendo isto, rodei o meu experimento com os seguintes parâmetros.


Nesta imagem, como tinha controle do pré-processamento dos dados propositalmente coloquei a variável de decisão como a geradora dos centroides dos dois clusters. Após isso fiz uma pergunta ao Eibe Frank que é um dos desenvolvedores do Weka sobre o testes dos coeficientes do Output e obtive a seguinte resposta:

pCluster_0_0 and pCluster_0_1 are cluster membership probabilities. RBFNetwork internally uses clusters build using SimpleKMeans. They are not output, so you can’t manually reproduce the classifications generated by RBFNetwork


Ou seja, se não tivesse inserido (ou mesmo a percepção do que o algoritmo fazia) a minha variável de decisão, jamais saberia como o algoritmo chegou ao resultado.

Neste caso o pré-processamento foi feito de uma maneira reprodutível, ou no mínimo rastreável o que ajudou na compreensão do modelo, e de quebra me permitiu ganhar um midset para trabalhar com problemas de função de base radial e clustering. Mais um item no cinto de utilidades do batman minerador de dados.

O grande aprendizado é que quem tem o controle do pré-processamento tem o controle do modelo, seja na velocidade de execução do algoritmo, como também exerce influência nos resultados do modelo. Então, não terceirize a normalização de dados.


Não terceirize a Normalização/Padronização dos Dados

Amostragem: Precisamos mesmo de 3 divisões amostrais (treinamento, validação e teste)?

Neste artigo do Dan Steinberg ele responde de forma clara:

“The short answer to this question is “no” we do not think that the 3-way partition is mandatory for SPM core models such as CART and TreeNet.”

Confesso que fiquei assustado com a resposta, mas abaixo no próprio artigo ele coloca a justificativa:

“The question we address here is whether this is really enough when the process of model development is lengthy and may involve the building of dozens, hundreds, or even thousands of models. If each model is evaluated on the second data partition one might argue that we are in fact learning from it. The learning may be limited and indirect, but the cumulative effect of intensive model development and evaluation blunts the independence of the second partition data.”

Uma das lutas mais ingratas de quem está trabalhando em um modelo de dados é o fantasma do Overfitting em qualquer modelo de descrição/predição.

O ponto principal do autor é que nem sempre em cenários nos quais os dados são escassos a utilização de amostras ‘holdout‘, isto é, fora do conjunto de dados (treinamento e teste) é necessária.

No artigo tem os resultados de um teste em que houve a construção de um modelo com holdout e sem holdout, e tirando-se as diferenças entre as curvas ROC dos modelos chegou-se ao ótimo resultado de apenas de – 0.00216 em relação ao modelo sem holdout.

Questionamentos metodológicos, e principalmente em relação à possível (ou a ausência de) variância do dados, o ponto é importante e vale a pena ser refletido.

Como é de conhecimento geral, nem sempre na construção de modelos preditivos/descritivos tem-se acesso completo aos dados, e em muitas vezes o volume de dados é extremamente pequeno.

Uma das alternativas para esse tipo de problema é a aplicação do método de Cross-Validation (k=10) que gera resultados satisfatórios.

No entanto, como o autor coloca em questão, um modelo deve ser sempre refinado de forma iterativa e incremental; o que significa que nenhum modelo ‘nasce’ sujeito a erros, mesmo se não houver representatividade das instâncias de ‘validação’.

Neste outro post tem um artigo bem interessante sobre o tema também.

Amostragem: Precisamos mesmo de 3 divisões amostrais (treinamento, validação e teste)?