La semaine dernière, alors que le jury délibérait, certains participants n’ont pas résisté à l’envie de partager leur création. Et vu la qualité des projets, le choix du vainqueur risque de se finir à coups de pelles : ça ne sera pas simple.

Mediarena, conçue et développée par Nils Grünwald, Stéphane Raux, Alexis Jacomy et Ronan Quidu est une bonne “datagifle”. Tout est là au premier coup d’œil : l’angle est clairement identifiable – comment les principaux médias en ligne traitent la présidentielle – et la prise en main plus qu’intuitive. En quelques clics, on joue avec les données et on fait défiler sur ce ring les noms des grands titres. Le cadeau bonux, c’est que derrière cette simplicité gage de lisibilité, Mediarena nous donne accès à bon nombre de données qui donnent du relief et de la profondeur à l’angle choisi.

Autre concurrent en lice, les concepteurs de “partie de campagne” (joli hommage à Raymond Depardon et son film “1974, une partie de campagne”). Si le design de leur web-app est un peu moins léché, leur mise en scène des données est vraiment intéressante et innovante. On entre par un nuage de tags qui donne un aperçu des principaux thèmes abordés par les médias et par les politiques (avec un petit graphique les comparant au survol de chaque mot).

Une fois le choix défini, le second écran nous immerge dans le “delta” (version HTML5 + canvas), les pieds dans la thématique et ses sujets affluents. En cliquant sur chaque terme on accède aux données : analyse de la tendance, affichage des sources (politiques et médiatiques) et même un listing des vidéos Youtube référentes. De quoi fouiller le sujet.

La team haploid a choisi elle un angle légèrement plus ludique, du moins dans la visualisation des données, avec son “Qui sera parachuté à l’Élysée ?”. Les candidats sont physiquement parachutés vers l’Élysée, point de gravité qui les attire tous, inexorablement. La base data pour chaque candidat étant son compte Twitter officiel associé à celui de sa formation politique, une corrélation entre le nombre de followers et le nombre de retweets permet de déterminer en live lequel est le plus proche du Saint-Graal.

Autour d’eux flottent les planètes des thématiques quotidiennes identifiées sur Twitter. L’interaction est, là aussi, assez intuitive avec, au survol, un affichage des liens entre candidats-volants et planètes-thématiques et, au clic sur chaque élément, l’affichage du fil Twitter correspondant.

La bonne data derrière ces premiers exemples, c’est que ce concours #Googleviz a déjà permis de remarquer de sacrées équipes. De quoi émoustiller le timide milieu de la dataviz hexagonal.

Open Data sans data

Avant de filer vers les datas non-hexagonales, sortons le saint-tag #opendata pour regarder du côté de ceux qui essaient de nous faire préférer le train. data.sncf.com, dix lettres et deux points qui ont de quoi faire saliver quelques csv-dépendants. Seulement voilà, une fois la page d’accueil chargée, on reste pantois : pas un seul jeu de données à se mettre sous l’tableur. Le site est un appel à débat comme le souligne cette bondissante baseline : “Open data, open débat”. Pour le modèle “gagnant-gagnant” prôné dans le court texte de présentation, on repassera.

Chers transporteurs d’humanités, sachez que l’Open Data est un débat depuis quelques temps déjà et que le meilleur moyen de le faire avancer eût été de nous lâcher vos données. Pour l’innovation, côté des détenteurs de données, on attendra.

Traquer les rumeurs

Prenons l’avion pour aller faire un tour outre-manche. Nos amis du Guardian, qu’on ne présente plus en matière de journalisme de données, ont encore fait joujou avec quelques chiffres pour notre plus grand plaisir. Le concept de longue traîne ne leur étant pas non plus inconnu, ils sortent une très belle visualisation interactive sur un événement qui a près de quatre mois : les émeutes londoniennes.

Alastair Dant et ses collègues ont décidé d’analyser l’évolution des rumeurs sur Twitter pendant ces évènements. “Les émeutiers ont libérés les animaux du zoo de Londres”, “les émeutiers se font leurs propres sandwichs dans les Mc Do”… À vous de choisir parmi sept rumeurs – cinq fausses, une infondée et une avérée – pour visualiser leur évolution. Le replay est intelligemment construit, avec notamment l’identification visuelle des tweets favorables, opposés, interrogatifs ou simplement commentant les faits et la mise en avant de moments clés où la diffusion de la rumeur se modifie. Et, comme au Guardian ils aiment partager, ils nous livrent un making of de cette datavisualisation qui permet notamment de comprendre l’importance d’un travail d’équipe intégrant : journalistes, développeurs, designers et universitaires.

Unes VS Twitter

Direction le sud de l’Europe et l’Espagne : autre mouvement, OccupyWallStreet, et autre visualisation signée Numeroteca. Si le rendu manque cruellement de possibilités d’interaction pour mieux saisir les données, le principe mérite que l’on s’y arrête. Le but est de matérialiser un comparatif entre le traitement du sujet à la une des grand journaux américains et le nombre de tweet/jour sur ce même sujet. Le rendu visuel permet non seulement de comparer les deux présences médiatiques sur un graphique mais on visualise également la place physiquement accordée sur la page de une. Le même type de travail a été mené pour comparer le traitement à la une des principaux journaux espagnols et sur Twitter du printemps arabe.

Des recherches à suivre, notamment lorsque l’on sait qu’un Hackathon sur le sujet #OccupyData s’est tenu le 9 décembre dernier et que les pistes qui s’y sont dessinées sont accessibles directement dans un GoogleDoc en libre accès.

Au-delà du chaos

Passons outre-atlantique pour aller crowdsourcer le futur de l’informatique. C’est ce que propose le New York Times à travers une efficace timeline verticale qui répartit le sujet sur quatre grands thèmes : calcul, intelligence artificielle, transports et mode de vie et communication. Rien ne sortant de rien, ce sont les bases qui apparaissent en premier avec tout l’historique de l’informatique au sens large depuis les bâtons de Napier en 1617 jusqu’à 2011 année historique où Waston, super-ordinateur conçu par IBM, a battu les deux champions du jeu américain “Jeopardy!”.

Puis c’est le grand saut. De quoi demain sera fait ? À partir de 2012, c’est un grand tableau noir où s’affichent les prédictions proposées par les audiences. L’espace pour laisser sa propre prospective est aujourd’hui clos mais vous pouvez toujours interagir de deux façons différentes. Soit en déplaçant les événements affichés sur la timeline post-2011, soit en votant pour les propositions qui vous semblent les plus intéressantes, réalistes #oupas. Les mieux notées seront progressivement insérées dans la partie prédictive de la timeline.

DataTriche et WTF

L’hiver approche et avec lui le cliché des longues soirées au coin feu qu’il va bien falloir occuper. Si certain(e)s d’entre vous aiment le jeu, possible que vous ressortiez dans les semaines qui viennent ce bon vieux Monopoly qui prend la poussière depuis un an. Alors laissez-moi vous donner un tuyau. Il y a un développeur californien nommé Ben Jones qui s’est amusé à modéliser les statistiques issues de 60.000 parties aléatoires. Son “Dominate Family Game Night” présente un tableau de bord des différentes stratégies de jeu en fonction de grandes tendances. Chut, je ne vous ai rien dit.

Avant de finir, on ne va pas, nous aussi, lancer un concours mais juste un appel : saisissez-vous des données WTF ! L’Internet mondial en est rempli et elles n’attendent que de folles petites équipes pour être visualisées. Tiens par exemple : les meilleures ventes de 45T/Singles de tous les temps (merci @Pirhoo) ou comment refaire un TOP50 2.0 avec en tête Tino Rossi et J.J Lionel.
Ou encore, pour rester dans le domaine des mélodies inoubliables, toute la correspondance de Wolfgang Amadeus Mozart et sa famille. Près de 1 400 lettres triées en fonction des dates, lieux, expéditeurs, destinataires, œuvres mentionnées. De quoi scrapper…

BRooeimn hhaapdsy

Reprenant la chronologie inversée du précédent “Les data en forme“, terminons cette semaine en musique avec une dataviz pour les oreilles. C’est du Queen et c’est la mythique Bohemian Rhapsody qui est joliment destructurée. Dans Bohemian Rhapsicord, créée lors du Music Hack Day de Boston, Jennie and Paul Lamere ont concrètement morcelé le morceau en une multitude de séquences pour nous laisser le rejouer à notre manière. Soit vous appliquez un des filtres qu’ils proposent (durée, volume, inversion, similarité), soit vous définissez une touche de votre clavier pour chaque segment et à vous de reconstruire le puzzle musical. Seul bémol : la web-app ne fonctionne que sous Chrome.

Allez, que l’#opentata et le #dadajournalisme vous inondent et à la semaine prochaine.

—

Retrouvez les précédents épisodes des Data en forme !

Pourtant, curieusement, battre un champion d’échec est plus facile pour une machine que de battre un champion de Jeopardy!. Les principes de résolutions d’un problème d’échec relève de la recherche opérationnelle « relativement »  simple. Les algorithmes utilisés, l’élagage alpha-beta ou l’algorithme Negascout peuvent en effet se résumer en quelques lignes de pseudo-code. Par contre, pour gagner à Jeopardy! la tâche est plus complexe.

Cliquer ici pour voir la vidéo.

Jeopardy! est un jeu de questions/réponses

La réponse est : Qu’est ce que Jeopardy! ?

Jeopardy! est un jeu très populaire aux Etats-Unis qui a eu son heure de gloire en France, avec l’inénarrable Philippe Risoli à la présentation. L’originalité de Jeopardy!  repose sur le fait que la réponse est la question :

Par exemple, le présentateur propose :

• C’est l’homme le plus classe du monde

Et le candidat doit trouver :

• Qui est Georges Abitbol ?

Pour être à égalité avec les humains, il a été décidé que Watson ne pourrait se servir que des connaissances stockées dans sa base de données et ne pouvait donc effectuer de recherches sur internet.

Les algorithmes utilisés pour résoudre ce type de problème relèvent donc d’une autre branche du domaine de l’intelligence artificielle que la résolution du jeu d’échec : le natural language processing, qui consiste à analyser correctement le langage humain. L’un des items les plus connus de cette discipline est le fameux test de Turing.

Pour autant, malgré le côté sexy et impressionnant, est-ce-que ce challenge d’IBM est une réelle avancée dans le domaine des intelligences artificielles ? Deux aspects sont à considérer. Pour gagner au Jeopardy!, il faut bien sûr trouver la bonne réponse mais aussi pouvoir répondre avant les autres candidats. Ces deux aspects renvoient à deux questions différentes mais imbriquées.

• Quels sont les algorithmes utilisés ?
• Comment ces algorithmes ont été implémentés ?

C’est l’algorithme utilisé par Watson

La réponse est : Qu’est ce que DeepQA ?

D’une manière très très grossière, répondre à une question revient à piocher des mots-clés dans ladite question, puis les mettre en relation par le biais de différents algorithmes pour extraire de la base de données à disposition les informations pertinentes.

Pour parvenir à produire un algorithme convenable, les équipes d’IBM ne sont pas parties de zéro et ont bien évidemment bénéficié de l’état de l’art. Deux outils ont tout d’abord été appliqués au challenge Jeopardy! :

- PIQUANT, une première solution de natural language processing développée quelque années auparavant par IBM

- OpenEphyra, une autre solution développée par l’Université Carnegie Mellon, en partenariat avec IBM

Toutefois, les performances de ces algorithmes ne satisfaisaient pas aux critères pour gagner. IBM a donc développé un nouvel algorithme : DeepQA

DeepQA est un pipeline modulaire

La réponse est : Quelle est l’architecture de DeepQA ?

A l’image de l’architecture de PIQUANT ou d’OpenEphyra, la clé du succès pour aboutir au résultat escompté est d’avoir conçu DeepQA comme un pipeline complet et modulaire pour y intégrer différents composants. Pour parvenir à cette architecture souple,  le framework Appache UIMA qui intègre ces composants a été utilisé. Il avait été développé quelques années plus tôt par la même équipe.

Le processus de réponse de DeepQA peut alors se décomposer en divers blocs. A chaque étape, des dizaines d’algorithmes différents sont mobilisés. Certains provenant directement de la littérature, certains de PIQUANT ou OpenEphyra, certains ont été améliorés, d’autres ont été imaginés par l’équipe de IBM.

Architecture de DeepQA

En suivant le graphique ci-dessus, le processus de réponse peut être décomposer de la sorte :

• Analyse de la question (Question analysis) : le système effectue une analyse syntaxique en  extrayant des mots-clés pour déterminer comment la question sera traitée
• Décomposition de la requête (Query decomposition) : la question est décomposée en sous-problèmes traités séparément
• Génération d’hypothèses (Hypothetis generation) : le système propose plusieurs réponses possibles en cherchant dans sa base de donnée
• Filtrage grossier (Soft filtering) : Afin de gérer au mieux les ressources de calcul, un premier tri est effectué pour éliminer les réponses les moins pertinentes
• Évaluation des hypothèses et des preuves (Hypothesis and evidence scoring) : les réponses candidates restantes sont analysées plus en détail
• Synthèse finale et classification (Synthesis and Final merging and ranking) : parmi toutes les réponses possibles, le système calcule la confiance accordée à chaque réponse, et classe celles-ci pour obtenir la plus probable
• Réponse et confiance (Answer and confidence) : la réponse finale est donnée avec un niveau de confiance que le système a calculé

Tout la difficulté a été de gérer ce patchwork d’algorithmes.  C’est pourquoi un gros travail a été accompli pour doter le système d’une métrique mesurant la pertinence des  résultats apportées par les différentes méthodes.

Le code a été porté sur un supercalculateur

La réponse est : Comment la rapidité de Watson a été améliorée ?

La première mouture du code permettait de répondre à une question en 2 heures. Ce qui est bien insuffisant pour vaincre un compétiteur humain. Pour pouvoir répondre en moins de 3 secondes, le code a été porté sur un cluster (IBM bien sûr), regroupement de plusieurs ordinateurs appelés nœuds, travaillant de concert à la résolution du problème.

Le cluster mis à disposition est une belle bête de compétition : 90 noeuds  Power 750 contenant chacun 4 processeurs octo-coeurs de 3.5 GHz ; le tout comportant 2,880 coeurs  et 16 TeraOctet de mémoire RAM pour une puissance théorique de 80 teraflops (soit 80×10¹²ou 80 millions de  millions d’opérations par seconde).

Lorsque l’on regarde le top500 des ordinateurs les plus puissants au monde, cela le classerait aux alentours de la 110ème place. Cette puissance était d’ailleurs trop importante au regard des besoins. C’est ce qu’affirme Edward Epstein, chef du département « information non structurée » à IBM research, dont dépend le projet Watson. Durant le jeu, Watson n’a utilisé au plus que 30% des processeurs disponibles.

Porter un code sur un supercalculateur et en optimiser les performances et une tâche désormais classique dans la recherche et l’industrie. Cette étape là ne présente pas de verrous technologiques mais demande un travail important et également beaucoup d’astuces.

Afin d’en optimiser les performances :

• les données ont été mise à disposition en RAM et non sur les disques dures pour accélérer les temps d’accès
• le code comportant  750,000 lignes a été parallélisé
• le processus d’allocation de la mémoire, avec une architecture NUMA, a été optimisé

NaN

La réponse est : Est ce que c’est nouveau ?

Au vu de ce qui précède, le challenge Jeopardy! n’apporte pas d’avancées fondamentales dans le domaine théorique du Natural Language Processing. IBM n’a effectivement pas apporté de solution miracle au problème ou d’algorithmes révolutionnaires mais c’est appuyé sur les nombreux travaux qui existaient déjà (y compris ceux de l’entreprise elle-même).

Pour autant, il apporte bien des nouveautés. Produire une machine capable de gagner à Jeopardy! n’avait jamais été réalisé. L’intégration dans un pipeline n’avait jamais atteint ce degré d’efficacité. De plus, ce pipeline et la méthode proposée peuvent être réutilisés pour aborder d’autres domaines moins futiles.

Les limites entre ingénierie et science sont floues mais IBM apporte bien sa  contribution au domaine.  En fait, l’apport d’IBM est conforme au fonctionnement classique de la recherche scientifique.

C’est avant tout un très beau projet de communication

La réponse est : Que représente le le challenge Jeopardy! pour IBM ?

Sous mon clavier le terme de communication n’est pas une critique. Le travail fourni est réel et conséquent et sur bien des points du domaine, il a permis d’apporter des améliorations incrémentales indéniables. Le challenge Jeopardy! a été conçu et conduit comme un projet industriel de recherche dont l’objectif premier est  de faire parler de l’entreprise. La résolution  d’une véritable problématique scientifique vient en second plan.

C’est d’ailleurs le but avoué[pdf] de David Ferruci, le chef du projet Watson :

Roughly three years ago,IBM Research was looking for a major research challenge to rival the scientific and popular interest of Deep Blue, the computer chess-playing champion [..], that also would have clear relevance to IBM business interests.

IBM construit en effet sa stratégie de communication sur une image d’innovation radicale. Cette image permet de conquérir des marchés en faisant parler de l’entreprise. IBM se place ainsi comme un acteur majeur du Natural Language Processing et promet dans un second temps des applications concrètes, comme l’aide au diagnostic médical. Durant ces trois ans, IBM s’est aussi rapproché des acteurs scientifiques du domaines en montant par exemple un workshop sur le sujet en 2008, ce qui lui a permis de rassembler autours de lui la communauté de chercheurs du domaine.

Sur le long terme, une telle stratégie permet d’attirer des talents et des collaborations avec de brillants éléments qui rêvent de travailler avec IBM. En interne, cela est source de satisfaction et de cohésion pour tous les éléments du groupe y compris ceux qui travaillent très loin de ces sujets. Travailler dans une entreprise ayant une bonne image est valorisant. C’est également un élément de motivation et de promotion interne. Il permet de faire miroiter à des ingénieurs, qui ont une tâche routinière au quotidien, l’opportunité de pouvoir un jour rejoindre ce type de projets au sein du groupe.

Dans ce cas là, ne pourrait-on pas dire que Watson est un projet qui permet à IBM de gagner sur de nombreux tableaux ? Tout comme à Jeopardy!, la réponse est dans la question.

Pour aller plus loin :

• Building Watson: An Overview of the DeepQA Project [pdf], AI Magazine Vol 31, N°3, p. 59-79,  l’article principal utilisé pour ce billet. Rédigé par l’équipe en charge de Watson, il explique leur démarche et le fonctionnement détaillé de deepQA.

• La page d’accueil d’IBM research sur ses activités de natural language processing

• Le blog d’IBM research

• La page Quora sur le Watson Jeopardy Challenge

• La page wikipedia (eng) sur Watson

• Watson Takes a Turn on Wall Street, résumé de la rencontre entre Edwar Epstein et Michael Feldman, éditeur de  HPCwire.

• Elémentaire, mon cher Watson , le billet de de Choux Romanesco

>> Photo Flickr CC-BY-NC-SA  par jntolva

>> Article initialement publié sur Nanostelia