DevoxxFR - Jour 1

Ayant eu la chance d'assister au premier jour de DevoxxFR 2017, je vous retranscris ma journée du mercredi. J'ai pu revoir les bases de la Data Science, découvrir les algorithmes génétiques et faire une petite passe sur Serverless.

Université de la Data Science

Une université assez rafraîchissante avec plein de GIFs animés dans la présentation et avec notre Eric Biernat et son livre “Data Science : fondamentaux et études de cas” cité en référence à la fin de la présentation #fierté.

En trois heures, cette université donne une vue d’ensemble de ce qu'on fait en Data Science. Pas de grande révélation, mais ce n'était pas le but. Si vous êtes débutant ou presque, c'est une très bonne introduction. Ça m'a permis de me faire des bons rappels et de creuser un peu certaines notions.

On repasse, classiquement, par l'exemple du Titanic où l’on tente de prédire si une personne survit ou pas en fonction de quelques caractéristiques (on dit "features" en machine learning) comme l'âge, le sexe ou le prix du billet. Pour la démo, on utilise Jupyter, un éditeur de Python qui permet de visualiser en direct les résultats de son code, très pratique comme outil. La démo ne s'est pas contentée de dérouler du code, elle a présenté de nombreux tips et retours d'expériences, le principal étant "bin il faut essayer, vérifier et itérer"

Lors de cette démo, on a pu voir :

• Différentes façon de visualiser les données.

• Un exemple de rajout de feature : en visualisant les "survies" en fonction de l'âge, on voit que les enfants ont l'air de survivre plus en proportion (surement lié au principe "les femmes et les enfants d'abord"). On décide donc de rajouter 2 features "is_child" et "is_adult" ayant des valeurs 0 et 1 en fonction de l'âge.

• La partie entraînement du modèle, où l’on donne toutes les données à notre algorithme pour qu'il apprenne.

• La partie prédiction, où on lui donne une donnée qu'il ne connaît pas et on lui demande une prédiction, ici "est-ce que la personne survit ou pas ?"

• Après la prédiction, ce n'est pas fini, il faut la valider, être sûr qu'on n’a pas prédit n'importe quoi. Ici, l'ennemi est l'over-fitting, on a tellement optimisé notre algorithme sur nos données de tests que sur des nouvelles données, il prédit complètement à côté. Classiquement ce qu’on fait, c’est qu’on n’entraîne pas l’algorithme sur l’ensemble des données, mais on en garde une partie de côté pour valider : on fait les prédictions et comme on connaît le résultat, on peut vérifier.

• Et enfin, la partie tuning, où l’on va faire varier les paramètres de notre algorithme pour trouver les meilleurs. Là, il n’y a pas de secret, on tâtonne et on essaye plein de combinaisons.

Petit rappel au passage sur la différence entre classification et régression. La classification c'est chercher à déterminer dans quelle "classe" va tomber notre individu, par exemple : est-ce qu'il est dans les survivants ou dans les non-survivants ? Et la régression, c'est quand on cherche à prédire une valeur, par exemple essayer de prédire prix du billet, une valeur possible est ici 123,45. Et pour que ce soit encore plus simple, attention aux faux-amis, une régression linéaire est un algorithme de classification, lol.

Après ces rappels, les orateurs ont présenté des exemples concrets qui restent assez connus comme le churn client. Au passage, le problème du churn, c’est que c’est souvent un cas où l’on a quelques individus qui vont “churner”, donc si on ne fait pas attention, l’algorithme a vite fait de se dire “je vais toujours prédire NON et j’obtiens un super score”. Donc, pour éviter ça, on peut sur-échantillonner la population en minorité… mais on risque d’inventer n’importe quoi. On peut aussi sous-échantillonner la population en majorité… mais on n’utilise pas une grande partie de nos données et on peut avoir rapidement une solution over-fittée. Au final, on fait souvent un mix des deux solutions.

Vient ensuite la question de l’interprétabilité : c’est bien d’avoir des résultats, mais bien souvent on a envie de pouvoir les expliquer. C’est pourquoi dans certains cas, on aime bien utiliser des arbres de décision, dans lesquels il est très facile d’expliquer les résultats (c’est finalement une grande succession de “if”. Après les arbres de décision, on passe aux “random forests”qui, en simplifiant un peu, est un ensemble de nombreux petits arbres de décisions qu’on fait ensuite “voter” pour atteindre un résultat final.

Deep Learning, dont tout le monde parle depuis quelques années, ce sont de simples réseaux de neurones. Avant (les réseaux de neurones ont été implémentés pour la première fois dans les années 70) on était rapidement limité par la puissance des processeurs alors que maintenant on peut empiler de nombreuses couches de réseaux de neurones les unes sur les autres, ce qui fait des millions voir des milliards de poids (un pour chaque liaison entre 2 neurones) à calculer. Quand on fait du deep-learning, ce qui est compliqué, c’est de construire la topologie de son réseau de neurones. Heureusement maintenant, on peut utiliser des bouts déjà existants. Et c’est là où apparaissent les frameworks de deep learning, dont TensorFlow est sûrement le plus en vogue aujourd’hui. Mais comme il est un peu compliqué à utiliser, il y a aussi des sur-framework (lol), comme Keras, qui simplifient son utilisation

Dernier conseil pour finir : réduire le périmètre. C’est plus simple de répondre à une question très précise “est-ce que cette image contient une voiture ?” Plutôt que cette image contient un véhicule”. C’est vrai que dit comme ça, ça semble évident, mais les besoins exprimés sont souvent généraux parce qu’on pense à tout ce qu’on voudrait faire. Un exemple concret c’est le besoin d’une entreprise de reconnaître ses 100 employés. Au lieu de faire un algorithme qui reconnaît les 100 personnes, ils ont implémenté 100 algorithmes qui reconnaissent chacun une personne et à chaque fois on appelle les 100 :)

Ce que j’en retire

• La prochaine fois que quelqu’un me demande comment débuter en Data Science, je lui indiquerai cette université.
• Il faut vraiment que je teste TensorFlow.
• Eric Biernat (OCTO) est une référence pour les speakers Devoxx.

A la découverte des algorithmes génétiques

Hands-on de trois heures aussi. Ce sujet m'intriguait depuis longtemps et c'était l'occasion de coder un peu :)

Bon, déjà, déception, on ne fait pas muter le code à proprement dit, mais uniquement les paramètres du programme. Moi qui ne comprenait pas comment on faisait du code qui se modifie tout seul, bin j’ai compris : en fait on ne le fait pas. Donc les algorithmes génétiques, c’est comment “faire une sélection sur un ensemble de solutions”.

Concrètement, ça se résume à la séquence suivante :

• Création d’une population initiale, souvent un ensemble borné (de 100 à 150 individus)
• Evaluation, on donne un score à chacune des solutions
• Sélection en vue de la reproduction. On sélectionne, avec un peu d’aléatoire les individus qu’on va reproduire. L’idée ici, c’est de faire une sorte d’aléatoire où on va favoriser les individus ayant eu un bon score par rapport à ceux ayant eu un moins bon score
• Reproduction. A partir des parents, on produit 2 (ou plus) enfants qui vont avoir une partie des caractéristiques de chacun des parents.
• Mutation. On introduit encore un peu d’aléatoire en faisant muter certains individus (une caractéristique est modifiée). L’idée ici, c’est de sortir d’un maximum local et trouver des solutions qu’on aurait jamais balayé en simplement croisant les individus.
• On obtient une nouvelle population. À noter qu’il est intéressant de garder les meilleurs individus des générations précédentes afin d’éviter de régresser.
• Itération. “Goto (2)”, jusqu’à ce que l’on trouve une solution satisfaisante ou qu’on en ait marre.

La vraie question est “quand utiliser ce genre de méthode ?” Quand l’espace de recherche est grand et qu’on n’arrive pas à trouver d’algorithmes déterministes qui donneraient une solution dans un temps raisonnable et qu’on préfère avoir une solution relativement bonne rapidement. Si vous connaissez l’approche “local search”, ça ressemble quand même pas mal.

Le reste de l’atelier était d’implémenter ces différentes étapes à partir d’un bout de code existant. Je ne vais pas vous faire l’affront de vous montrer notre code (on n’a pas fait de tests).

Ce que j’en retire

• Bon, on fait pas vraiment muter de code, sic :(
• Intéressant uniquement si on ne trouve pas de méthodes déterministes assez rapides et qu’on veut une solution “pas trop mal”.
• Java, franchement, c’est lourd, j’aurais dû partir en Ruby :)

Serverless, le framework que votre lambda AWS attendait

Petite session sur les lambdas et le framework Serverless. Au début on rebalaye les concepts de lambda et serverless. Bon évidemment, il y a toujours des serveurs, juste qu’on ne les voit pas. Le terme server(management)less serait donc plus approprié.

Petite définition d’une lambda : “fonction packagée avec ses dépendances et sa configuration associée comme la RAM utilisée, les variables d'environnement (pour se connecter à des base de données par exemple) répondant à une ou plusieurs sources d'événements (API, mais aussi events sur S3, cloudwatch, etc.)”.

Les grands avantages aux lambdas Facturation, sur AWS EC2 on est facturé à l’heure. Sur les lambdas, c’est à la 10ème de seconde. Scalabilité, elle est gérée par la plateforme, rien a faire de ce côté là. Pas d'infrastructure. On n’y touche pas, pas besoin d'OPS :) Métriques d'usage, comme on déploie des petites fonctions, on a les métriques directement sur ces fonctions. Force au découplage vu que par définition, on déploie des choses plus petites que des microservices. Cycle de développement, on déploie très très vite

Démo sur console AWS, effectivement ça prend trente secondes. Mais comme il y a plein de possibilités, il ne faut pas se tromper. L’intégration des lambdas reste compliqué, on peut utiliser CloudFormation d'AWS, mais il n’y a pas de guidelines particulières. Du coup, Serverless arrive pour faciliter tout ça. Dans la démo, effectivement, on passe d’une configuration d’environ 100 lignes à plus qu’une dizaine de lignes, ça a l’air bien. À noter que Serverless marche sur AWS bien sûr, mais aussi sur d’autres fournisseurs comme Azure et OpenWhisk.

Ce que j’en retire

• Remonter dans ma todo un test de Lambda et de Serverless