Dés 16h, la Cantine se remplit très vite, et ça déborde de la salle. L'auditoire est super attentif, et refuse de faire des pauses pour ne rien perdre de son gavage haut de gamme. Le niveau est costaud, les intervenants passionnés.
Première intervention, par François-Régis Chaumartin, travaillant dans une startup issue de Paris VII. Présentation de l'état de l'art sur l'analyse de sens par une machine. Ils travaillent pour la grande distribution, font de la surveillance de marque, répondent à des mails, lisent des CV pour l'APEC. L'intervenant donne de beaux contrexemples sur les finasseries du français qui se fait martyriser par les simplifications traditionnellement appliquées par les moteurs de recherche. L'importance des accents : "maïs / mais", "pâte / pâté", "total / Total". L'importance des stop words (adverbes, articles, pronoms...) que l'on retrouve trop souvent dans les textes : "par des enfants / pour des enfants". La polysémie "Le chirurgien opère un calcul" (il y a en moyenne 2.3 sens par mot en français), et enfin les constructions de phrases ambigües "je mange une pizza avec des anchois / je mange une pizza avec une fourchette". Les expressions "le stade se lève". L'ordinateur n'est décidément pas prêt pour apprécier la littérature. Un certain nombre de données sont disponibles en ligne, comme Wordnet, base lexicale de référence en anglais. L'intervenant a participé à son annotation en français (75 000 mots, pour le moment). Wikipedia permet aussi de faire de l'analyse de sens. Pour les entités nommées, OpenCalais permets d'obtenir 90% de reconnaissance. L'intervenant enchaine ensuite sur des explications sur les relations entre entités (qui fonctionne même de manière non continue). L'ordinateur suit donc un cours de Français niveau CM1, avec les COD, COI et autres acronymes barbares. Un peu de jargon poétique pour compenser : "appliquer un patron morpho syntaxique". Tout ça pour obtenir 30 à 40% de reconnaissance de phrase. Pour la reconnaissance de sentiment, on peut monter à 75%, mais l'ironie, la litote, et autre forme d'esprit restent hermétique aux machines. Un peu comme le Terminator dans le 2° opus. Un peu de chiffres sur le matériel utilisé, ils travaillent sur du cloud Azure, 10 serveurs octoprocesseurs avec entre 16 et 32Go de RAM. L'analyse de 2 millions de documents prend un weekend.
Intervention d'un chantre Elastsic Search, David Pilato. Ancien adepte de SQL travaillant pour les douanes, il est maintenant employé par elasticsearch.com. Quand il a dû interdire l'usage de la commande LIKE sur sa base de données, pour ne plus bloquer le flot d'insertion de données, il est allé voir les solutions d'indexation existantes et à découvert Elastic Search. Je pensai bien connaitre ce produit, que je suis depuis longtemps, mais en fait non, je me suis fait surprendre. Principal intérêt de ce genre de soirée, se faire surprendre et secouer sur des choses que l'on pense maitriser (et découvrir des choses que l'on ignore complètement). L'intervenant insiste peu sur le côté moteur de recherche, domaine acquis, mais plus sur le côté explorateur de contenu. Les facettes permettent de faire des choses très puissantes, de produire des statistiques, et en les assemblant, leur puissance se multiplie. Elastic Search permet de farfouiller ses données. L'intervenant milite pour l'éradication des formulaires avec trop de champs, définis selon les besoins de l'ingénieur, et non de l'utilisateur. Un simple champ accompagné d'une interface incitant aux itérations, aux essais sera bien plus efficace. Si en prime on peut éradiquer les likes des bases de données, ce ne serait pas plus mal. Bien que fiable et pérenne, Elastic Search ne recommande pas son usage comme référentiel de données. Les utilisateurs font des usages non prévus d'Elastic Search, et certains ont dépassé la centaine de noeuds dans leurs clusters. Au début le travail d'un seul homme, Elastic Search est maintenant une entreprise et un travail d'équipe. Elastic Search s'oriente vers l'exploration de données, bien au dela de la seule recherche full text (domaine de Lucene, qui évolue tranquillement de son coté et qu'il suffit d'intégrer au rythme de ses innovations).
Intervention de Renaud Boutet, de Focusmatic, spécialiste de l'analyse temps réel de données marketing. Ils suivent un ensemble de flux par client (rss, twitter, facebook...), les filtre pour enlever du bruit, font ensuite de l'analyse dans de multiples dimensions. Comme exemple de bruit : un client travaillant dans les maisons en ossatures bois, récupérait des évènements parlant de la maison de la belle au bois dormant. L'interface mise à disposition des clients leur permet aussi d'annoter les résultats (spam, sentiment positif/négatif...) pour améliorer les résultats suivants, l'histoire n'étant pas réécrite.
Leur outil est entièrement basé sur le modèle acteur, représenté par Scala. Ils ont du nodejs pour les interfaces utilisateurs, du Mongodb pour la persistance (ricanement dans la salle sur la pérennité de cette solution) et de l'Elasticsearch pour l'exploration. Chaque client est modélisé par un flot de 5000 à 300 000 évènements par jour. Les évènements, de simples JSON, parcourent un certain nombre de traitements. De la persistance est appliqué aux étapes clefs. Elastic search est utilisé via une rivière branchée sur Mongodb. Il est possible de rerépartir la charge allouée à chacun des filtres, en cas de "bouchon", selon la particularité des évènements à traiter. Zookeeper est utilisé pour coordonner le cluster. Un an d'historique est conservé par client. L'interface, très réactive, permet au client de naviguer dans les évènements, et d'affiner les règles d'apprentissage. Techniquement, l'apprentissage est modélisé par du "maximum entropy" et du "naive bayesian".
Intervention de Yann Schwartz de Shopping adventure est un site permettant de rechercher des produits dans des stocks. La recherche est construite sur du Riak Search. Riak est un très bon produit pour faire du stockage clef/valeur, profitant de l'expertise d'Erlang OTP, il fait peu de surprises en production avec des temps de réaction prévisibles. Par contre, son moteur de recherche est un peu rude. Erlang n'est pas du tout à l'aise dans le traitement des chaines de caractères. Très peu de filtres sont proposés pour la tokenisation, et Shopping Adventure confie cette tâche à NLTK, une bibliothèque Python pour le traitement automatique du langage. Riak search ne propose pas de recherches géolocalisées, Shopping Adventure a implémenté une version relativement naïve, basé sur le principe de l'escargot (pour élargir la zone de recherche) qui offre des résultats très satisfaisants. Pas de jointures dans Riak, ce qui est une des concessions des bases clefs/valeur, mais il est possible de faire une implémentation maison à base de mapreduce. Le développeur a appris Erlang sur le tas (avec une expérience dans plusieurs langages dont C# et le lisp), et apprécie sa robustesse et les outils de cluster qu'offre OTP, bien plus simple qu'un Zookeeper. L'application web utilise webmachine, et squatte la passerelle HTTP de Riak. "Webmachine est très facile à utiliser, pour peu que l'on ait déjà implémenté un serveur et un client HTTP." Riak a fait le choix, pour des raisons de performances d'avoir ses index sur une seule machine de la grappe ce qui pose des problèmes de fiabilité. Riak n'a pas vocation à créer un moteur de recherche full text. Un projet outsider Yokozuna peut sauver la donne. Yokozuna permet d'utiliser Solr comme complément au stockage de Riak. Riak se contente de faire ce qu'il fait bien : coordination, supervision, distribution et synchronisation. Solr ne s'occupe que de la recherche, qui n'est pas une spécialité de Basho. Du coup, toute l'usine à gaz de Solr Cloud est remplacée par de l'Erlang. L'intervenant annonce que Basho va lâcher sa recherche un peu bancale en faveur de Yokozuna. Ce serait un scoop, ainsi qu'une bonne nouvelle.
Intervention de Rand Hindi sur la prédiction à partir d'analyse de data, et la responsabiltié morale que ça implique : "Big data, big vision". De fait, ils se sont spécialisés dans la recherche de données disponibles (libres ou achetés), puis dans leur nettoyage et leur croisement. En croisant des données fiables sans rapport direct avec ce que l'on cherche, il est souvent possible d'obtenir un résultat plus pertinent qu'une source directe. L'intervenant vante la qualité d'Open Street Map, à qui il doit une partie de son business. Un point sur l'éthique, le big data est qualifié de nucléaire 2.0 . Il est possible d'obtenir pratique à partir de big data, comme trouver où se garer, choisir où aller dans une rame de métro pour avoir une place assise, réduire de 30% les cambriolages juste en envoyant patrouiller la police dans les zones statistiquement à risque. Mais il est aussi possible de basculer du coté obscur, comme le high frequency trading (évoqué rapidement sous le terme flou de banquaire), et le ciblage publicitaire indiscret, comme cette prédiction de grossesse pour une fille de 18 ans, habitant chez ses parents, et qui a reçu des publicités ciblées sans qu'elle n'ait rien demandé, ni même être effectivement enceinte. Le big data a créée un nouveau métier, le "data creative", qui a les connaissances nécessaires en programmation et mathématiques pour brasser de la donnée, mais surtout de l'inventivité pour imaginer des croisements et des traitements pour faire apparaitre de nouvelles informations à partir de données existantes. Techniquement, ils travaillent avec du Scala et du Python, sans avoir trouvé la base de donnée de leur rêve. De toute façon, ils semblent avoir une approche pragmatique, s'adaptant à la spécificité de leurs projets, sur des échéances courtes. Ils revendiquent ne pas avoir la tranquillité d'un chercheur universitaire.
Une présentation de Spark, par Sam Bessalah. C'est à cette présentation que la plupart des cerveaux de l'audience ont fondu. Intervention brillante et magistrale sur un thème très technique : le gain en performance dans le traitement de flot dans un environnement massivement distribué en suivant les principes de la programmation fonctionnelle, immutabilité et idempotente. Solution basé sur la maturité de la JVM et l'élégance de Scala, en utilisant discrètement de la modification de bytecode, pour offrir une interface simple et limpide. Spark se positionne comme un concurrent de Hadoop et de son modèle map reduce qui s'appuie beaucoup trop sur le disque dur. Spark essaye d'optimiser l'utilisation de la RAM. Dans Spark, les données sont des collections sur lesquels on applique des filtres. Le cache sur disque se fait de manière explicite. En cas de soucis, il est toujours possible de réappliquer le filtre sur le dernier état des données, reprenant la logique de la persistance par journal, où l'on ne stocke pas un état, mais de quoi le reconstruire rapidement. Il est possible de créer des filtres en python (en jython, en fait, ils passeront dans la moulinette à bytecode de Spark), et aussi en Java, mais sa syntaxe se prête très mal à la programmation fonctionnelle. Le travail en cluster est relativement masqué pour l'utilisateur qui a créé son code comme s'il allait tourner sur sa propre machine. Pour pouvoir aller plus loin dans les optimisations, un certain nombre d'outils sont mis à disposition, comme la possibilité de broadcaster des variables (immuables) dans tous les noeuds. Spark propose de simplifier fortement la gestion du calcul distribué, mais il n'y a pas de miracles, il faut se méfier des contextes trop gros, principale cause de crash. L'intervenant a utilisé Spark sur de l'EC2 et du stockage S3, mais préfère les performances stables des clusters bare metals, parlant de cinquantaine de noeuds dans ses exemples. Pour peu que l'on bufferise un peu, il est tout à fait possible d'effectuer des traitements en flux. Spark commence à avoir des applications spécifiques. Shark (Hive on Spark), permet de requêter ses big datas dans un dialecte ressemblant fortement à du SQL. Bagel, un clone du Pregel de Google, est un outil pour travailler sur des graphes de données. Spark est capable de collaborer avec Storm ou Kafka, outils que connait bien l'intervenant.
J'ai ensuite malheureusement dû quitter la conférence, ratant ainsi de belles choses. Les graphes et la sémantique pour lire des recettes, par Antoine Durieux de chefjerome. L'avantage de l'immutabilité et de l'idempotence pour le traitement des données, par Jonathan Winandy. La parallélisation du machine learning en Python sur EC2 par Olivier Grisel. Une présentation pragmatique de R, par François Guillem. J'éspère pouvoir trouver les présentations de toutes ces belles choses en ligne.
