Data Mining with Rattle and R

Data mining with Rattle and R est un livre que j’ai bien apprécié. L’auteur Graham Williams non seulement possède son sujet mais sait le rendre intéressant et simple.

R est un environnement open-source qui permet de réaliser des analyses statistiques qui rencontre un succès important dont témoignent les nombreux livres écrits à son sujet.

Rattle est une extension de R qui permet de réaliser des fouilles de données et par exemple de générer des arbres de décisions à partir d’un ensemble de cas connus. Selon Graham, le but du data mining est de construire un modèle qui capture l’essentiel des savoirs contenus dans les données.
La volonté de l’auteur est de faciliter la compréhension et la mise en oeuvre de ces techniques d’analyse.
Ce livre sent le vécu. Il intéressera les les experts et les débutants en analyse de données. Les experts y trouveront une structure et des capacités pédagogiques. Les débutants y verront facilement plus clair, il n’est d’ailleurs pas nécessaire d’être statisticien ou informaticien pour comprendre le data mining, il faut néanmoins s’intéresser a minima à chacun de ces domaines.

Le livre est structuré selon le cycle de vie d’une analyse. A chaque étape du processus la finalité, les pièges et la mise en oeuvre avec Rattle et R sont décrites.

L’exemple pris est celui d’une prévision météo, une vingtaine de facteurs sont pris en compte pour prévoir si demain il pleuvra.

Autour de cet exemple l’auteur présente de manière intéressante les intérêts de différentes techniques d’analyse permettant d’aboutir à des modèles descriptifs et prédictifs pertinents.
L’auteur insiste sur la capacité à prendre en compte les résultats d’une multiplicité d’analyse.


Il détaille les différentes méthodes d’évaluation des résultats et met en lumière combien cette étape d’évaluation est importante et parfois trompeuse.



Pour terminer, j’illustre le style, l’intérêt et le niveau requis pour lire ce livre d’un exemple. Celui  que j’ai choisi porte sur une famille de meta-algorithmes qui comparent plusieurs modèles pour les combiner et en générer un meilleur :

“ The random forest algorithm tends to produce quite accurate models because the ensemble reduces the instability that we can observe when we build single decisions trees. This can often be illustrated simply by removing a very small number of observations from the training dataset to see quite a change in the resulting decision tree.”

De l’utilité d’une automatisation partielle

Il y a un cas où l'automatisation partielle est utile. C'est celui où vous n'êtes pas pleinement en mesure de formaliser toute votre logique d'une façon interprétable par la machine ou lorsque les experts ne sont pas vraiment des experts.
Dans ce cas, vous demandez à la machine d’être en mesure de déterminer le niveau de difficulté de la question posée. Si la question posée est un trop difficile la machine est alors capable de dire "je démissionne", si elle est facile, elle répond alors à la question posée, de manière partielle ou complète.
Par exemple, lorsque la couleur est le noir-noir, il est facile de dire que la couleur est noire, lorsque la couleur est le blanc-blanc, il est facile de décider que la couleur est blanche, lorsque la couleur est grise, il n'est pas facile de choisir entre le noir et blanc.
La capacité de dire "je renonce" est utile car vous pouvez commencer à automatiser une décision sans totalement maîtriser la logique de cette décision. Vous pouvez automatiser les réponses faciles et laisser les réponses les plus difficiles aux experts. Avec l'aide de ce modèle, vous pouvez ainsi avoir du temps pour améliorer vos systèmes en continu. Il vous laisse du temps pour formaliser des logiques complexes ou, plus raisonnablement, pour acquérir un peu plus d’expertise.

Automatisation partielle

Toutes les décisions ne peuvent pas être automatisées, mais beaucoup peuvent l’être. Entre ces deux extrêmes une frontière existe. Quelle est-elle ? Comment la caractériser ?

Raja Parasuraman et Thomas Seidon ont écrit un article il y a une dizaine d’’années pour tenter de modéliser cette frontière. Il est intitulé “A Model for Types and Levels of Human Intercation with Automation. Cet article est tout à fait intéressant et a d’ailleurs été récemment commenté par Vijay Pandiarajan et James Taylor.

Pour faire simple ce modèle identifie 10 niveaux d’automatisation, les voici :

10. L’ordinateur décide de tout.
9. L’ordinateur décide d’informer ou pas les humains.
8. L’ordinateur informe les humains si ceux-ci le lui demande
7. L’ordinateur informe de toute manière les humains.
6. L’ordinateur donne du temps aux humains pour mettre un veto
5. L’ordinateur fait des suggestions que l’humain approuve
4. L’ordinateur propose des alternatives
3. L’ordinateur restreint l’espace de recherche et propose un nombre réduit de possibilités
2. L’ordinateur propose la totalité des alternatives possibles
1. L’humain décide et agit sans l’aide de l’ordinateur

Cette liste est intéressante du fait que de prime abord quand on pense automatisation on pense surtout à une automatisation complète et peu à une automatisation partielle. Elle est donc un moyen simple pour exprimer qu’il existe beaucoup de possibilités entre ces deux extrêmes.

James Taylor propose deux autres cas :

1. le cas où le rôle de l’ordinateur se limite à sélectionner les données utiles à la prise de décision
2. et le cas où l’ordinateur propose différentes alternatives en mettant l’emphase sur celle qu’il préfère.

Je suggère un troisième cas. La formalisation de règles n’est pas toujours facile à réaliser comme en témoigne la note de  Ken Orr . Ken Orr a écrit de manière claire que la difficulté de formaliser des règles croit nettement plus vite que la difficulté du problème et donc qu’il existe bon nombre de problèmes dont la résolution automatique n’est pas pour demain soit parce que la logique de résolution est connue mais difficile à formaliser soit parce que cette logique n’est pas connue ou mal connue
L’automatisation partielle est une réponse à cette préoccupation.
Le troisième cas consiste à donner à l’ordinateur la mission de savoir déterminer s’il sait ou non résoudre le cas qui lui est présenté. A charge pour lui de résoudre les cas simples et à charge aux humains de traiter les cas difficiles.

Je terminerais cette note en signalant que dans de nombreux cas l’automatisation partielle n’est pas possible, il s’agit par exemple de cas où la décision doit être prise de manière extrêmement rapide ou, plus simplement, de cas où l’homme n’est pas joignable.

Ergonomie de visual rules modeler

Visual Rules édité par Bosch Software dispose d’un outil de modélisation dont l’ergonomie est particulièrement intéressante. Cette ergonomie permet de spécifier des raisonnements logiques de manière très intuitive c’est-à-dire sans nécessiter beaucoup de préalables techniques.
Vous n’avez ni besoin d’avoir préalablement formalisé votre vocabulaire, ni besoin d’avoir défini la structure de données, ni besoin d’avoir préalablement conçu votre modèle exécutable (XOM), ni non plus, besoin dans dans un premier temps, d’utiliser un langage formel prédéfini.

Dans une perspective de réappropriation de l’outil informatique par les métiers, le fait de  nécessiter peu de préalables est intéressant à plusieurs titres, il permet à de nombreux acteurs de démarrer sans beaucoup d’investissements intellectuels et  surtout il permet d’éviter ou de limiter le passage par des experts techniques souvent peu disponibles et pouvant, parfois, manquer d’expertise pédagogique.

Pour décrire votre logique vous utilisez une représentation arborescente et vous décrivez le sens de chaque noeud dans le langage de votre choix.
Un noeud de l’arbre équivaut à un test et une feuille à un résultat ou une action à lancer.
A tout moment vous pouvez écrire à côté du texte en clair un texte plus formel destiné à être interprété par la machine.

Bien que le formalisme “arbre de décisions” soit aussi utilisable avec jrules (ilog-ibm) ou de drools (red-hat). Cette approche est assez différente de celles de jrules (ilog-ibm) ou de drools (red-hat), elle est n’a pas que des avantages mais elle a celui de la simplicité. Les outils comme jrules ou drools ont plus tendance à nécessiter la mise en place préalable de domaines métiers (vocabulaire métier + structure objet ), sans pour autant d’ailleurs que ce soit indispensable.

Il faut signaler que visual rules n’utilise pas de moteur de règles à proprement parler, il permet d’éditer des règles sous des formes claires et lisibles, il permet de concevoir des logiques de décisions ou de raisonnement mais lorsque vous placez un test vous devez déterminer à l’avance où ce test ce déclenchera.



A titre d’exemple voici un arbre de décision qui permet de décider si une personne est ou n’est pas l’oncle d’une autre personne. La définition du concept “oncle” ou “tante” est réalisée à partir des relations de parenté “soeur”, frère, “fils” et fille.

Cette arborescence n’est pas exécutable au sens où les noeuds de l’arbre ne contiennent pas  encore de code formel (cet exercice sera réalisé dans un autre billet) mais elle constitue une première de familiarisation avec l’outil et avec la modélisation des logiques de raisonnement.

L’étape suivante est l’écriture d’expressions formelles avec son ensemble de préalables (structures de donnée, structures objets) exécutables par la machine. Cette deuxième étape aura tendance à remettre en cause, au moins partiellement une partie des travaux déjà réalisés. Que cela ne vous incite pas, pour autant,à sacrifier la première étape, elle est très utile pour éviter quelques allers-retours des plus ennuyeux !