Indexation et classification temps réel de petites annonces en ligne

RAPPORT DE STAGE DE 3 ème ANNÉE Indexation et classification temps réel de petites annonces en ligne Effectué du 18 Avril 2011 au 16 Septembre 2011 Sous la supervision de M. Benjamin Devèze 34 rue de Cléry 75002 Paris 01 55 34 96 40 contact@yakaz.com Olivier FAVRE Option IAD

TABLE DES MATIÈRES Table des matières TABLE DES MATIÈRES 1 Présentation de l entreprise 4 1.1 Secteur d activité............................... 4 1.2 Yakaz.com................................... 4 1.3 Cadre..................................... 5 2 Mission réalisée 6 2.1 Besoin originel................................ 6 2.2 Contraintes à satisfaire............................ 6 2.3 Technologies utilisées et préconisées.................... 7 2.4 Collaborateurs et contacts.......................... 7 3 Description des technologies impliquées 8 3.1 Lucene..................................... 8 3.1.1 Présentation............................. 8 3.1.2 Terminologie............................. 8 3.1.3 Requêtage............................... 8 3.1.3.1 Autre types de champs................... 8 3.1.4 Mapping et consistance....................... 10 3.2 ElasticSearch................................. 10 3.2.1 Présentation............................. 10 3.2.2 Souplesse de configuration..................... 10 3.2.3 Terminologie............................. 10 3.2.4 Aspect distribué............................ 11 3.2.5 Développement............................ 12 4 Le plus gros du travail 13 4.1 Configuration................................. 13 4.2 Analyseurs................................... 13 4.2.1 Mapping................................ 13 4.3 Développement de modules......................... 14 4.3.1 Expressivité du champ de recherche................ 14 4.3.1.1 En route vers une contribution.............. 14 4.3.2 Analyse avancée des champs textuels................ 15 4.3.2.1 En route vers une seconde contribution......... 15 4.3.3 Requête sur une phylogénie..................... 16 4.4 Intégration.................................. 17 4.4.1 Traitement des workunits d entrée................. 17 4.4.2 Front................................. 18 4.4.3 Module de présence......................... 18 4.5 Validation................................... 19 4.5.1 Comparaison des résultats...................... 19 4.6 Déploiement................................. 20 Stage de 3 ème année Olivier FAVRE 2

TABLE DES MATIÈRES TABLE DES MATIÈRES 5 Autre sujet traité Classification de requêtes 22 5.1 But recherché................................. 22 5.2 Données.................................... 22 5.2.1 Description.............................. 22 5.2.2 Quelques statistiques......................... 23 5.3 Approches testées............................... 23 5.3.1 Régression logistique......................... 24 5.3.1.1 Description de la méthode................ 24 5.3.1.2 Prise de décision...................... 24 5.3.1.3 Pré-traitements....................... 25 5.3.1.4 Résultats.......................... 25 5.3.2 Classifieur bayésien naïf....................... 25 5.3.2.1 Description de la méthode................ 25 5.3.2.2 Prise de décision...................... 26 5.3.2.3 Pré-traitements....................... 28 5.3.2.4 Post-traitements...................... 28 5.3.2.5 Résultats.......................... 29 5.4 Méthode retenue et déploiement...................... 31 5.4.1 Base de données........................... 31 5.4.2 Extension PHP............................ 32 5.4.3 Gestion des langues......................... 33 5.4.4 Apprentissage incrémental...................... 33 5.4.4.1 L idée générale....................... 33 5.4.4.2 Le procédé......................... 33 5.4.4.3 Optimisations....................... 34 5.4.4.4 Parallélisation....................... 35 5.4.4.5 Export............................ 35 6 Perspectives 37 6.1 Moteur de recherche............................. 37 6.2 Classification de requêtes.......................... 37 6.3 Autres tâches futures............................. 37 6.3.1 Détection des topics......................... 37 6.3.2 Jeux mobiles............................. 37 7 Apports personnels 39 8 Conclusion 40 Stage de 3 ème année Olivier FAVRE 3

1 Présentation de l entreprise Présentation de l entreprise 1.1 Secteur d activité Yakaz est une SARL fondée en Septembre 2005 par Frédéric Mahé et Mathurin Ducastelle, au capital de 17 680 e dans le domaine de la programmation informatique. Le chiffre d affaire 2010 était de 3 240 700 e, en augmentation de 88,74 % par rapport à l année précédente. Avec une rentabilité d exploitation de 47,85 %, l entreprise a augmenté son nombre d employés pour dépasser la vingtaine et embauche toujours actuellement. 1.2 Yakaz.com Yakaz est la société éditrice du site web du même nom : http://www.yakaz.com/. Disponible dans 49 langues et 193 pays, il référence les petites annonces localisées et catégorisées. Ainsi vous pourrez chercher un logement, une voiture, une moto ou même un emploi. Quelque soit le domaine recherché, vous pouvez filtrer par type d annonce : vous cherchez à vendre, à louer, vous donnez, proposez vos services, un emploi ou vous avez une bonne critique, un événement à promouvoir, ou vous recherchez une actualité ou peut être avez-vous une question à poser ou vous lancez une discussion. En plus d avoir un moteur de recherche textuel, vous pouvez filtrer les annonces avec des critères avancés, tels que la superficie minimale d un logement, le nombre de pièces, avec photos, commentaires, des enchères, ou bien même un emploi en intérim ou bien une grosse cylindrée rouge avec un faible kilométrage. Toutes ces informations ont été extraites des annonces et sont disponibles à la recherche. Vous pouvez naturellement poster votre annonce sur Yakaz, mais le site est bien plus que cela car il recense toutes les annonces que vous pourrez trouver sur Internet. L entreprise possède des robots d indexation chargés de parcourir la toile à la recherche de nouvelles sources. Ainsi, à quoi bon aller chercher ailleurs alors que vous avez une énorme base d annonces à portée de clic et que vous pouvez poster la votre gratuitement directement sur notre site? 1.2.1 Philosophie Pertinence C est le maître mot du site web. Elle est cruciale, car il ne rimerait à rien de proposer un service d annonces localisées qui vous sert des résultats à 1000 km de l endroit recherché. Il y a un travail perpétuel pour améliorer la précision des analyses automatiques par lesquelles chaque annonce passe. Il peut être difficile, par exemple, de bien savoir à quoi correspondent certains chiffres donnés lorsque l annonce est rédigée dans un style très laconique. Innovation Nous désirons offrir des fonctionnalités diverses et nombreuses car nous croyons que cela rendra service au client et par voie de conséquence, l attirera vers le produit. Stage de 3 ème année Olivier FAVRE 4

Cadre Présentation de l entreprise Par exemple, nous avons créé un service de chat intégré au site, afin de mieux connecter les annonceurs et les intéressés. Si cela vous rappelle Google, vous n avez pas tort. Par plus d un aspect, le management de l entreprise rappelle celui du géant de l Internet. 1.2.2 Technologies Afin de pouvoir offrir une qualité de service optimale, nous devons servir chaque page aussi rapidement que possible. En passant moins de temps à traiter chaque demande, nous pouvons ainsi répondre à un nombre toujours grandissant de requêtes. Obtenir de bonnes performances nécessite d utiliser les outils les plus adaptés. Par exemple, nous n utilisons pas le serveur web le plus connu Apache HTTPD pour des raisons de performances, mais un serveur web écrit dans un langage fonctionnel, nommé Yaws, qui permet un traitement simultané des requêtes optimales. Une part importante de l optimisation d un service à l échelle mondiale repose également dans l utilisation de caches de grande capacité et de vitesse de réponse très faible. L architecture matérielle a été conçue de manière tout à fait adaptée aux besoins que chaque composant : mémoire vive importante, ou grosse capacité de calcul, ou encore accès réseau rapide. 1.3 Cadre Localisée dans le 2 ème arrondissement, l endroit est aisément accessible et la vie dans le quartier y est agréable car nous jouissons de la proximité de la rue Montorgueil et du boulevard Poissonière, riches en restauration et en lieux culturels. 1.3.1 L équipe L équipe technique est composée de 9 personnes à temps plein, 1 ou 2 freelance ponctuellement. Elle est épaulée par un administrateur système et réseau. Nous devons beaucoup également à notre équipe de recherche et développement composée de 2 personnes. Afin de faire vivre le site web, nous comptons sur une chargée de communication et de son assistant, ainsi que 5 animateurs de communautés étrangers, chargés de surveiller le bon fonctionnement et la pertinence du site en rapport avec leur langue maternelle et pays d origine, mais également de trouver de nouvelles sources à répertorier. L entreprise ne saurait être complète sans les 2 patrons et la secrétaire de direction. 1.3.2 Ambiance Elle y est très décontractée. Le carcan d une rigueur vestimentaire n est imposé à personne, et personne ne se l impose. L entreprise a même offert des tongs Yakaz pour l été! Entre passionnés de technologies, les échanges de connaissance et les débats vont bon train. Enfin je partage des moments entre geeks sans gêner personne. Que ça soit entre geeks ou pas, la bonne humeur est toujours partagée et il est très agréable de travailler dans de telles conditions, surtout sur des sujets passionnants! Stage de 3 ème année Olivier FAVRE 5

Mission réalisée 2 Mission réalisée 2.1 Besoin originel Yakaz utilise actuellement les technologies Exalead pour plusieurs étapes de la chaîne de traitement : Le crawling, ou le parcours d Internet. Cette étape permet de détecter et de lister les pages à traiter, aussi bien à l intérieur d un site web qu en tentant de trouver de nouvelles sources. L analyse des pages crawlées afin d en extraire automatiquement le contenu utile, ainsi que d en effectuer l extraction fine à l intérieur de chaque annonce, pour déterminer par exemple le kilométrage ou la couleur d une voiture. L indexation et la recherche pour finalement pouvoir servir les résultats sur le site web. Les annonces ne sont pas les seuls éléments concernés, les mots clés ainsi que les lieux sont également indexés. Nous voulons nous séparer du joug d une solution propriétaire pour investir dans une solution OpenSource, que nous pourrons faire évoluer plus facilement dans le sens que nous souhaitons. De plus le support d une communauté riche de centaines d enthousiastes assure également que nous ne serons pas laissés pour compte en cas de problème. Investir est doublement le mot exact, car déployer une solution alternative, quelle qu elle soit, prendra du temps, mais aussi parce que certains des développements supplémentaires que ce changement technique impliquera pourront sans difficulté faire l objet d une contribution à la communauté faisant vivre ces solutions. Les développements réalisés dans les parties crawling et analyse ayant été réalisées sur la base du code source propriétaire qu Exalead a accepté de nous ouvrir, pour des raisons historiques ne seront pas trop difficiles à porter, bien qu ils aient été réalisés en ExaScript, langage propriétaire d Exalead, offrant une surcouche au langage Java et se basant sur les mêmes APIs de base. Le chantier commence donc par la partie indexation, et j ai été recruté pour m en occuper à temps plein, épaulé par quelques autres collaborateurs. 2.2 Contraintes à satisfaire Bien entendu, nous ne devons pas perdre en fonctionnalité par rapport à l offre actuelle. Mais d autres contraintes additionnelles entrent en compte : Être plus évolutif que la solution actuelle. Conserver une taille d index dans le même ordre de grandeur que celui d Exalead. Les machines sur lesquelles font tourner le moteur de recherche auront énormément de mémoire vive, mais une quantité limitée de mémoire persistante. Respecter des timings assez agressifs sur les temps de recherche. Cette contrainte est également fortement liée à la suivante. Être intégrable au système de cache très efficace déjà en place. C est un des éléments principaux qui permet de passer à l échelle mondiale en conservant une grande disponibilité de service. Stage de 3 ème année Olivier FAVRE 6

Technologies utilisées et préconisées Mission réalisée 2.3 Technologies utilisées et préconisées À mon arrivée, la question de la technologie de substitution à utiliser avait déjà été abordée. Parmi les moteurs de recherche libre, Lucene semblait l un des mieux placés. Mais surtout, il dispose d une surcouche relativement récente qui démultiplie ses possibilités : ElasticSearch. Si le choix n est pas verrouillé, il semble à priori l un des meilleurs possibles. En effet, il existe d autre moteurs de recherche ainsi que d autres surcouches à Lucene, mais celle ci à l air de correspondre à nos attentes. 2.4 Collaborateurs et contacts Comme je le disais, si je suis la seule personne à travailler à temps plein sur ce chantier, je ne suis pas sans soutien. Benjamin Devèze, le plus ancien employé de Yakaz de l équipe technique, possède une excellente connaissance de toute notre infrastructure, car il a pu suivre, s il n a pas lui-même réalisé la construction de tout l existant. Toujours très disponible, il m a aidé à découvrir les particularités de notre chaîne de traitement. Grâce à ses remarques toujours très pertinentes, nous avons souvent pu avancer dans la bonne direction sans tâtonner et éviter un grand nombre de problèmes. Deux freelances Stéphane Jais et Adbelmajid Boubrik m ont également épaulé durant les trois premiers mois. Ils sont des anciens d Exalead et ont notamment travaillé sur le cœur du moteur de recherche. Ils ont développé un adaptateur permettant de faire le pont entre les formats d entrée d Exalead et d ElasticSearch. Puis l un a porté les changements dans le site web pour le nouveau moteur, tandis que l autre réfléchissait plus aux problèmes d architecture et de portage des fonctionnalités spécifiques dont nous avions besoin. Les communautés construites autour des solutions OpenSource sont également une source de richesse de contenu, pour Lucene, et réactive via leur salon de discussion sur IRC, pour ElasticSearch. J ai d ailleurs eu le privilège de pouvoir rencontrer Shay Banon, auteur d ElasticSearch, car Yakaz nous a proposé, à Benjamin et moi, de suivre la conférence What s Next sur les nouvelles technologies construites autour de Java, qui se tenait à 5 minutes de nos locaux au Grand Rex. En plus de répondre à certaines de nos interrogations sur la réalisation de certaines fonctionnalités, afin d apprécier leur performances potentielles, nous avons pu nouer un meilleur contact qui sera toujours apprécié pour la suite de notre collaboration, en tant qu utilisateur de son logiciel. Stage de 3 ème année Olivier FAVRE 7

Description des technologies impliquées 3 Description des technologies impliquées 3.1 Lucene 3.1.1 Présentation Lucene est un moteur de recherche textuel OpenSource, écrit en Java. Très connu, il est utilisé dans un bon nombre de projets. Étant une bibliothèque fournissant des fonctionnalités de base, ce moteur est facilement intégrable dans une application, elle ne nécessite pas de serveur ni obligatoirement de fichiers sur le disque. 3.1.2 Terminologie Les objets que l on index s appellent des documents. Ils sont constitués d un ou plusieurs champs, totalement arbitraires, éventuellement multi-valués. L index de Lucene répertorie les documents qui possèdent un terme donné, et ce pour chaque terme utilisé. Un terme est rattaché à un champ, ainsi il n y a pas de faux positifs en provenance d un autre champ. Un même terme possède des meta-données pour chaque apparition : position du mot, position exacte en caractères, type (mot, chiffre, idéogramme, etc.), ainsi que des données arbitraires nommées payload. Ces meta-données sont facultatives et les stocker font naturellement grossir la taille de l index. Cependant, noter la position du mot permet de favoriser les documents qui possèdent des termes dans le même ordre ou presque que ceux figurant dans la recherche. Noter la position en caractère permet aussi de pouvoir réaliser une mise en valeur des termes ayant matché avec la requête, comme les extraits avec des passages en gras dans les résultats de Google. 3.1.3 Requêtage Les requêtes Lucene s expriment avec des objets Java. Elles peuvent s imbriquer et devenir assez complexes, mais cela fait également leur puissance. Par exemple vous pouvez rechercher une combinaison précise de plusieurs termes en combinant des requêtes booléennes de la forme (must, should, must not), ce qui correspond généralement aux préfixes +, (vide) et - des moteurs de recherche. Il existe également des requêtes avec des jokers (wildcards) comme? remplaçant un caractère unique et * en remplaçant zéro, un ou plusieurs ; des requêtes approximatives autorisant les termes matchés à différer plus ou moins des termes recherchés ; des requêtes de proximité, comme décrit précédemment ; des requêtes d intervalle de texte, de date comme de nombres ; et toutes les sous-requêtes peuvent être boostée en multipliant leur sous-score par une constante. Naturellement, Lucene possède un type de requête particulier qui permet d analyser un texte écrit dans un champ de recherche, comme sur Google, et d en générer l imbrication de requêtes Lucene correspondant. 3.1.3.1 Autre types de champs Lucene étant un moteur de recherche textuel uniquement, les dates et les champs numériques sont convertis en texte correspondant, en faisant en sorte que le tri alphabétique corresponde au tri numérique. Afin d accélérer l exécution d une requête Stage de 3 ème année Olivier FAVRE 8

Lucene Description des technologies impliquées numérique sur un intervalle d entiers de 120 à 1024, plutôt que d énumérer les 905 termes pouvant exister dans l index, on utilise des termes particuliers rajoutés pour exprimer moins de précision (en enlevant 4 bits par défaut). Quand un intervalle contient tous les termes de plus grande précision contenus dans un autre terme plus large, ce dernier est utilisé. Par exemple de 16 à 31, le second groupe de 4 bits (bits de poids 4 à 7) vaut toujours 0001b, un groupement est donc réalisable. Précision 1 0000 0000 Précision 2 0000 0000 0001 0011 0100 Précision 3 0000 0111 0111 1000 1111 0000 1111 0000 Précision 4 0000 0111 1000 1111 0000 1111 0000 1111 0000 Nombre 0 119 120 127 128 255 256 1023 1024 TABLE 1 Représentation binaire des nombres requêtés. Les éléments en italique sont les termes requêtés. En gris foncé figurent les éléments ignorés car un terme de plus faible précision a été utilisé à la place. En gris clair, les termes dont la précision ne nous intéresse pas La requête générée est décrite par l arbre ci-dessous : 0000 0000 0000 0001 0011 0100 0111 0001 1111 0000 1000 1111 0000 120 à 127 128 à 255 256 à 1023 1024 FIGURE 1 Arbre correspondant aux simplifications effectuées. Les termes requêtés sont en italique. La requête devient donc : 15 termes { }} { 0000 0000 0001 3 0000 0000 1111 3 8 termes { }} { 0000 0000 0000 1000 4 0000 0000 0000 1111 4 3 termes { }} { 0000 0001 2 0000 0011 2 0000 0100 0000 0000 4. Les indices dénotent le niveau de précision du terme. Cette requête n utilise plus que 27 termes. On comprend ainsi, par cet exemple de requête en apparence simple, l importance de bien saisir le mode de fonctionnement du moteur Lucene afin d appréhender les points pouvant être susceptibles de devenir des goulots d étranglement. Stage de 3 ème année Olivier FAVRE 9

ElasticSearch Description des technologies impliquées 3.1.4 Mapping et consistance De plus, l exemple précédent introduit une autre notion que vous n avez peut-être pas remarqué : si Lucene est un moteur de recherche textuel nous pouvons néanmoins utiliser des caractères arbitraires, c est à dire des données binaires. Il ne faudra cependant pas qu il puisse régner de confusion entre des termes textuels et des termes binaires, ni même sur la transformation appliquée aux données initiales pour obtenir un terme. Nous voyons une contrainte qui émerge ici d elle même : l importance de maîtriser le contenu des champs, c est à dire de se fixer un mapping entre chaque champ et un type de données. Ainsi il convient de ne finalement pas mélanger des valeurs textuelles, temporelles et numériques sous un même nom de champ. 3.2 ElasticSearch 3.2.1 Présentation ElasticSearch est une surcouche pour Lucene, qui lui permet un passage à l échelle dynamique et sans accrocs. Sans configuration nécessaire, simple à déployer, il permet de construire une fonctionnalité de recherche basique mais néanmoins puissante en peu de temps. Également écrit en Java, son code est clair et très modulaire. Beaucoup de fonctionnalités supplémentaires sont intégrables sous forme de modules. 3.2.2 Souplesse de configuration La configuration permet de créer plusieurs index et d en détailler le mapping de ses champs, bien qu il soit également possible de lui lancer des documents qu il indexera à la volée en détectant le type probable des différents champs. En se plongeant dans la configuration du mapping, on peut indiquer si un champ doit être analysé ou avant d être indexé, s il doit être indexé tel quel, ou s il ne doit pas l être du tout. Un champ peut également être stocké ou non. Ces deux choix permettent de diminuer la taille de l index en tirant profit d une connaissance au préalable de l utilisation de chaque champ. Il est également possible de configurer la chaîne d analyse très souple que Lucene propose, à partir de la configuration. On référence ensuite un analyseur ainsi construit dans le mapping des champs. Les meta-données des termes tirés de l analyse peuvent ou non être stockées. C est encore un levier supplémentaire sur le compromis entre la taille de l index et la qualité des réponses et du surlignage des mots ayant matché les termes recherchés. En effet, sans information sur la position des mots on ne peut favoriser les termes dans un ordre proche de celui de la requête originelle, si savoir à quelles positions insérer les balises de surlignement. 3.2.3 Terminologie Un cluster peut contenir plusieurs index ; un index est également un index Lucene ; un index peut contenir plusieurs types ayant des mappings de champs différents ; Stage de 3 ème année Olivier FAVRE 10

ElasticSearch Description des technologies impliquées chaque document est associé à un index et un type, et possède un identifiant unique, éventuellement généré automatiquement ; chaque document est également versionné. L identifiant est un champ Lucene comme un autre, mais il possède un sens particulier dans ElasticSearch. Il est préfixé par le type du document. Ceci permet de pouvoir adapter le traitement des différents champs comme le mapping de chaque type l exige. La version de chaque document sert exclusivement à la résolution des conflits de mise à jour, pouvant survenir étant donné la nature distribuée de la plate-forme. Elle ne permet en aucun cas de récupérer une ancienne version dudit document. 3.2.4 Aspect distribué Chaque index ElasticSearch étant distribué, il correspond en réalité à plusieurs index Lucene : un par shard. Le nombre de shard d un index est fixé à sa création et ne peut être changé par la suite sans procéder à une réindexation complète manuelle. L identifiant de chaque document est hashé en un entier qui, modulo le nombre de shard, donne le numéro du shard auquel il appartient. C est une technique très fréquente dans le partitionnement des bases de données distribuées suivant le principe shared nothing. Elle possède l inconvénient de changer la quasi-totalité des affectations clé-shard à chaque changement du nombre de shard. Un technique n ayant pas cet inconvénient s appelle Distributed Hash Table, à base de consistent hashing. Un shard est soit maître soit un replica (une copie). Le nombre de replica par shard maître lui, est changeable dynamiquement. L indexation a lieu dans les shards maîtres, la recherche peut avoir lieu indifféremment dans le shard maître ou dans un replica. Régulièrement, les changements apportés au shard maître sont répercutés dans les replicas, soit en y rejouant les requêtes, l analyse des documents est donc réalisée plusieurs fois, soit en transférant les segments de l index Lucene qui ont été impactés. Un replica permet plusieurs choses : augmenter la disponibilité et donc la performance de la recherche, car on peut contacter n importe lequel des replicas pour répartir la charge d une requête ; avoir une tolérance aux pannes, car un replica étant une copie du shard maître, n importe lequel peut être élu shard maître à son tour, si l ancien a été victime d un crash. Il est possible de rajouter aisément de nouvelles machines à un cluster ElasticSearch existant. Il suffit simplement que la nouvelle instance possède le même nom de cluster. Une découverte automatique sera alors réalisée, et le nouveau nœud ElasticSearch sera alors intégré aux autres. La charge de l index ElasticSearch sera répartie de nouveau en déplaçant certain replicas ou même certains shards maîtres vers le nouveau nœud ElasticSearch, en maximisant la répartition et en minimisant la présence des shards maîtres sur une même machine. Un cluster ElasticSearch possède également un nœud maître. Il est chargé d orchestrer la vie et la répartition des shards dans le cluster. Si le nœud maître devient indisponible, les nœuds esclaves en élisent un nouveau parmi eux. Pour résumer, un cluster ElasticSearch est composé de plusieurs machines pouvant faire tourner plusieurs instances d ElasticSearch appelées des nœuds, qui possèdent le même identifiant de cluster. Dans un cluster existe un seul nœud maître. Un index ElasticSearch est découpé en plusieurs shards maîtres. Pour chaque shard maître il existe Stage de 3 ème année Olivier FAVRE 11

ElasticSearch Description des technologies impliquées un certain nombre de shard replica. Chaque nœud possède plusieurs shards (maître ou replica). Chaque shard est un index Lucene, correspondant donc à une partie d un index ElasticSearch. Tout ceci est quelque peu complexe, mais dans les faits, cela fonctionne de manière entièrement transparente. On peut s adresser à n importe quel nœud ElasticSearch pour effectuer une indexation, une requête, ou une demande d état du cluster, les redirections nécessaires se font automatiquement. 3.2.5 Développement Le développement d ElasticSearch a été quasi-intégralement réalisé par l israélien Shay Banon, dixit kimchy. Ce logiciel est plus ou moins indépendant de celui de Lucene, cependant il suit de très près ses changements de version. Certaines fonctionnalités ont été intégralement créées dans ElasticSearch, et ne sont pas disponibles dans Lucene directement. Par exemple, les facettes qui permettent de collecter des informations et autre statistiques sur les valeurs des champs des documents matchés par la requête, existent dans Solr une autre surcouche, officielle, mais pas dans Lucene même. D autre fonctionnalités, comme un log transactionnel, permettant de survivre à un crash sans perdre aucune des opérations en cours, on été intégrées à Lucene après avoir existé presque depuis les débuts d ElasticSearch. Stage de 3 ème année Olivier FAVRE 12

4 Le plus gros du travail Le plus gros du travail 4.1 Configuration La configuration n est pas l étape qui prend le plus de temps, surtout en environnement de test. Dans un environnement de cluster, il faut faire attention à bien configurer les capacités d auto-détection des nœuds afin d éviter que plusieurs instances rejoignent le même cluster, mais surtout s assurer que tous les nœuds futurs pourront s y joindre. Il faut veiller à configurer convenablement les nombre de nœuds attendus, le nombre de nœuds minimum ainsi que le temps minimum à attendre pour commencer une récupération du cluster. Il est également possible de configurer la persistance de l index afin d utiliser soit des index en mémoire seulement, soit une persistance en fichiers locaux, ou sur un système de gestion de fichier partagés. 4.2 Analyseurs Les différents analyseurs personnalisés utilisables dans les mappings doivent être définis dans la configuration. Ceci est une étape plutôt longue et délicate. Nous avons une centaine de langue à gérer, pour chacune d entre elles, nous devons utiliser les outils les plus appropriés disponibles dans Lucene. L analyseur par défaut permet de découper les mots de manière convenable pour la plupart des langages européens en ignorant la ponctuation et séparant les mots composés avec des tirets. Il permet de conserver les noms de produits en un seul morceaux, ainsi que les adresses e-mails et les noms d hôtes internet. Après le découpage des mots, les mots sont normalisés en supprimant les «s» finaux et les points des acronymes, et sont également mis en minuscule et certains mots clés sont supprimés. Il existe des analyseurs plus spécifiques pour une trentaine de langages. Certains analyseurs sont également disponibles sur Internet et nécessitent d écrire un plugin pour les adapter à ElasticSearch. Plus de détails sont disponibles dans la section 4.3. 4.2.1 Mapping Nos documents possèdent plus de 200 champs. Certains sont propres à Exalead, d autres ont une structure ou ont été adaptés spécialement pour bien fonctionner avec Exalead, la plupart sont plutôt classiques. Un travail long et fastidieux ainsi que difficile à rendre compte dans un rapport a été nécessaire afin de créer le mapping adapté pour ElasticSearch. Avec Benjamin, nous nous y sommes repris à plusieurs fois. Certains champs textuels devaient rester des mot-clés et ne pas être analysés mais devaient être indexés, d autre en revanche devaient être analysés. Parmi ces deux catégories de champs, certains devaient être disponibles dans une recherche sans avoir à en préciser le champ (dans ElasticSearch, ces champs ont la propriété include_in_all, et leur valeur sont recopiées dans un champ particulier nommé _all). Certains champs n ont pas vocation a être indexés car ils ne seront utiles qu une fois le document récupéré. Stage de 3 ème année Olivier FAVRE 13

Développement de modules Le plus gros du travail Certains champs comportent des données numériques, d amplitude variable et donc pouvant bénéficier d optimisations diverses sur le nombre de termes de plus faible précision à indexer. Le défaut d un pas de 4 bits de précision, décrit dans les requêtes numériques Lucene, est effectivement configurable, et la taille de l index ainsi que la rapidité de requêtage en sont affectés. Enfin, certains champs sont hiérarchiques et chaque niveau, avec ses ancêtres, doivent être indexés séparément pour permettre un requêtage séparé et un calcul de statistique différencié. Ceci est géré de base par Exalead, mais le découpage nécessite un analyseur particulier pour Lucene. 4.3 Développement de modules Exalead et ElasticSearch n ayant pas les mêmes particularités, des développements ont naturellement été nécessaires. Certains ont été fait en amont, avant la construction du document JSON, car temporaires, d autre en revanche ont été réalisés sous forme de plugins ElasticSearch, car les adaptations ne devraient pas altérer la forme du document, mais plutôt les traitements qui sont effectués dessus par ElasticSearch. Je décris ici quelques uns de ces développements, d autres, plus spécifiques aux types de données manipulées en interne ne sont pas explicités. 4.3.1 Expressivité du champ de recherche La chaîne de recherche ne s écrit pas de la même façon dans Lucene que dans Exalead pour effectuer une recherche numérique sur un intervalle. Exalead utilise une syntaxe très naturelle «champ>=valeur» alors que Lucene utilise plutôt «champ:[valeur TO *]». On retrouve l utilisation de la première forme en dehors des classes propres à Exalead dans le code source, il me fallait trouver un moyen pour la faire comprendre à ElasticSearch. 4.3.1.1 En route vers une contribution En recherchant sur Internet, je n ai trouvé aucune solution. Plutôt que de me pencher sur un pré-traitement de la chaîne de recherche transformant la première syntaxe en la seconde, j ai préféré regarder du côté du travail de la communauté Lucene. J ai trouvé le ticket LUCENE-1823 dans leur site de gestion des développements, qui avait été créé il y a 2 ans, à l activité très disparate. Mais ce ticket est encore ouvert et fait en fait référence à plusieurs autres patchs. Parmi la wishlist figure «3. Improved RangeQuery syntax : Use more intuitive <=, =, >= instead of [] and {}.», mais aucun patch n avait été proposé. Je me suis donc chargé de cette tâche et ait créé deux patchs pour le ticket LUCENE-3343 que j ai alors ouvert : un pour la version prochaine 3.4 de Lucene, un pour la version future 4.0. Cependant, je ne voulais pas modifier la version de Lucene qu ElasticSearch utilise. J ai préféré opter pour la création d un plugin à part entière. J ai ainsi créé un projet copiant Lucene, en le débarrassant de tout élément superflu non modifié, j ai changé le nom du package et de certaines classes pour éviter les conflits, et j ai recompilé le tout pour me fournir un nouveau module Jar pour Lucene. Il m a suffit de copier l adaptation déjà réalisée dans ElasticSearch pour l adapter afin qu il utilise mon nouveau module Lucene à la place du module dans le cœur de la bibliothèque. Stage de 3 ème année Olivier FAVRE 14

Développement de modules Le plus gros du travail 4.3.2 Analyse avancée des champs textuels Exalead permet d indexer une forme exacte, une forme normalisée ainsi qu une forme lemmatisée de chaque mot. Chacune de ses forme ayant moins de poids que la précédente. Ceci permet de favoriser une correspondance plus exacte sur l orthographe d un mot par rapport à une correspondance par un détour plus important. C est une méthode très intéressante qui n existe malheureusement pas dans Lucene. S il est effectivement possible et géré de sortir plusieurs termes à la même position pour un même mot en entrée, le filtre de synonymes est le seul élément d analyse existant qui permette de le faire, et ça n est clairement pas l outil le plus adapté. Il n est pas possible avec Lucene de combiner le résultat de plusieurs analyseurs. Il est en revanche possible de dédoubler un champ afin qu il subisse plusieurs analyses différentes sous ElasticSearch. Cependant avec cette méthode, il est impossible d effectuer une recherche de conjonction (et logique) de plusieurs termes l utilisation d une disjonction (ou logique) n étant pas intéressant car elle à pour effet de faire remonter de plus en plus de résultats au fur et à mesure que l utilisateur précise sa recherche en rajoutant des mots. C est un défaut que je devais régler pour assurer le bon fonctionnement de notre recherche. 4.3.2.1 En route vers une seconde contribution Ayant déjà expérimenté la création d analyseurs dans mon dernier stage, j avais déjà une idée précise de ce qu il fallait que je fasse. Dans Lucene, un Analyzer est un objet qui renvoie un flux de termes à partir d un nom de champ et d une source de texte. Un flux de terme est créé par un Tokenizer qui découpe une source de texte en flux d attributs décrivant les termes successifs. Une seconde manière d obtenir un flux de terme, est d appliquer un filtre via un TokenFilter, afin d en modifier les attributs, mais également de pouvoir créer ou supprimer certains termes. J ai besoin de créer un Analyzer qui puisse créer à son tour plusieurs flux de termes à partir de sous-analyzers, et qui les regroupe au final en un seul flux, si possible ordonné d une façon naturelle position du mot croissante puis position en caractères croissante puis conservation éventuelle du sous-analyseur source pour conserver une séquence de termes à une même position afin d éviter des bugs potentiels sur d autres composants de la chaîne d analyse parmi laquelle notre analyseur figure éventuellement. Plusieurs obstacles se sont dressés. Le premier est qu une source ne peut être dupliquée à moins de la lire entièrement et de la stocker pour créer ultérieurement plusieurs sources, une par sous-analyseur. J ai développé une optimisation à ce cas le plus défavorable : pour un StringReader (et pour quelques autre classes), de loin la plus utilisée dans Lucene en interne, il est possible d accéder au champ interne déclaré par le JRE de Sun en mettant à profit l API de reflexivité de Java, évitant ainsi une duplication fastidieuse et coûteuse. Une autre optimisation est de déballer (unwrap) un Reader caché à l intérieur d un BufferedReader afin de pouvoir trouver une éventuelle optimisation adaptée au Reader interne. Stage de 3 ème année Olivier FAVRE 15

Développement de modules Le plus gros du travail Le système d optimisation doit pouvoir s appliquer seul, de manière dynamique en fonction des types rencontrés. Ainsi, à base de tables d association entre un type et un cloneur ou un déballeur, en utilisant le type parent quand le sous-type n est pas reconnu, j ai construit une factory de cloneur de Reader, à grand coup de généricité et de binding. Le second obstacle était plus du domaine de la formalité en comparaison. Beaucoup de choses dans Lucene sont faites pour être réutilisable afin d éviter d allouer trop d objets inutilement. Les analyseurs en faisant partie, j ai également tenté de détecter lorsque c était le cas, afin de ne pas ruiner ces optimisations et de réutiliser les objets que j ai moi-même créé. À la clé, plusieurs problèmes de thread safety doivent être gérés. Les attributs de termes sont également de cette catégorie. Ainsi le consommateur d un flux de termes récupère une unique instance de chaque type d attribut, et en lit la valeur, mise à jour après chaque obtention d un nouveau terme. Il m est alors impossible de renvoyer les attributs provenant de mon sous-analyseur actuel. Une détection de présence et une recopie manuelle se sont avérées nécessaires, fort heureusement, la chose a plus ou moins été prévue dans Lucene. À l heure où j écris ces lignes, je n ai malheureusement aucune nouvelle de l ajout de fonctionnalité proposé à la communauté : LUCENE-3392. Je suis conscient que ce patch, avec son module d optimisation, ne sera pas accepté de façon immédiate. Mais je suis persuadé d avoir implémenté la solution la moins pire, une autre ayant nécessité un refactoring massif de code et provoqué un changement d API majeur ayant des répercussions pour tout utilisateur de l indexation de Lucene. Ici encore, j ai implémenté ceci sous la forme d un plugin ElasticSearch. J ai d ailleurs commencé par expérimenter cette fonctionnalité comme cela. Voici le ticket que j ai ouvert pour ElasticSearch : https://github.com/elasticsearch/elasticsearch/ issues/1128. 4.3.3 Requête sur une phylogénie D une manière similaire à l optimisation réalisée dans Lucene sur le requêtage des nombres, nous avons une structure de donnée particulière décrivant un arbre de chaînes de caractères, que nous pouvons requêter avec un formalisme particulier : abcd abefg abefhi abj 1:a 2:b 3:c 4:d 1:a 2:b 3:e 4:f 5:g 1:a 2:b 3:e 4:f 5:h 6:i 1:a 2:b 3:j abcd abefg abefhi abj ab {cd ef {g hi} j} (2) ab {cd ef {g hi} j} 1:a 2:b 3:c 4:d 3:e 4:f { 5:g 5:h 6:i 3:j (3) Stage de 3 ème année Olivier FAVRE 16 (1)

Intégration Le plus gros du travail La relation 1 montre une façon naïve de requêter 4 mots donc chaque lettre devient un terme constitué de sa position et de la lettre. Il y a 18 termes, dont beaucoup sont regardés plusieurs fois. La relation 2 est une réécriture que nous utilisons en interne. La plupart du temps, les phylogénies sont bien plus complexes, dans cet exemple la différence apportée par l optimisation suivante n est encore que faible. Fort de cette réécriture, la relation 3 montre la construction d une requête booléenne optimisée, ne requêtant que 10 termes, sans doublons. c d g a b e f h i j FIGURE 2 La phylogénie correspondant à la requête optimisée. Le parcours en profondeur s effectue avec des et logiques tandis que le parcours en largeur s effectue avec des ou logiques. Cette optimisation est effectivement intéressante sur des phylogénies conséquentes car aucune optimisation n est réalisée par ElasticSearch ou par Lucene sur une requête booléenne du genre a a ou a a. 4.4 Intégration 4.4.1 Traitement des workunits d entrée L indexation d Exalead fonctionne en surveillant un dossier où sont déposées des archives compressées contenant chaque document décrits en XML. Ils appellent workunit ces archives et corporate document ces éléments à indexer. Or ElasticSearch dispose seulement d une interface HTTP via laquelle il faut envoyer des documents JSON. Un développement a donc été nécessaire afin de permettre l indexation des annonces. Stéphane et Majid ont pris en main son développement dès le premier jour de leur mission, alors que je me formais sur ElasticSearch. L outil développé est un démon Java surveillant un répertoire, extrayant chaque corporate document de la workunit avant de les parser et de construire l objet JSON correspondant. Certains champs nécessitent un pré-traitement, comme l extraction de coordonnées GPS à partir d un champ ayant été encodé d une manière à satisfaire les contraintes d Exalead, ElasticSearch pouvant effectuer plusieurs traitement intéressants avec ce genre de données. Ayant acquis une bonne connaissance du moteur d indexation, j ai pu guider le développement en partie ainsi que corriger des bugs trouvés en testant l indexation. J ai surtout amélioré l aspect parallélisation en modifiant le code, ainsi que le transfert FTP pour utiliser un répertoire temporaire suivi d un déplacement atomique, pour se soustraire à un appel coûteux à la commande lsof qui vérifie si un fichier est actuellement utilisé par un autre processus. Ceci afin d augmenter les performances en indexation et saturer ElasticSearch pour le pousser dans ses derniers retranchements. Stage de 3 ème année Olivier FAVRE 17

Intégration Le plus gros du travail Cet outil est normalement temporaire. En effet, les machines réalisant l analyse des annonces peuvent dorénavant directement envoyer le document construit à l indexeur, pour peu qu il soit en JSON. Dans les faits, une grande partie de la chaîne de crawling et d analyse est effectuée grâce aux technologies d Exalead, et a été modifiée en grande partie par nos soins. Ainsi, les corporate documents sont créés en amont de la chaîne de traitement et enrichis au fur et à mesure. Il sera donc plus difficile de s en séparer. 4.4.2 Front Le site web PHP est assez modulable, il a donc été facile de basculer vers l utilisation d autres classes pour changer le moteur de recherches à utiliser. En revanche, l intégration de ce dernier est plus longue. Il faut mapper chaque fonctionnalité pour réaliser l équivalent avec ElasticSearch. Ce dernier possède un langage d expression des requêtes très modulable et très fournis, axé sur une imbrication hiérarchique de plusieurs éléments de requête exprimés également en JSON. Ces requêtes sont plutôt verbeuses et la quasi totalité de la configuration s effectue en leur sein. Exalead au contraire utilise des requêtes totalement plates et dont une bonne partie de la configuration s effectue au préalable dans une page d administration. La construction des requêtes a donc nécessité beaucoup d efforts, et je m y suis repris à plusieurs fois car il n est pas aisé d obtenir des résultats aussi bons que ceux qu Exalead parvient à fournir, après plusieurs années d utilisation et d ajustements réalisés en interne. Cela fait plus de cinq ans que cette technologie a été utilisée exclusivement. Comme nous avons pu le constater, une partie de la logique qui y était propre a fini par glisser dans d autres classes du code du site web, rendant l intégration encore un peu plus difficile. 4.4.3 Module de présence En profitant d une refonte de l architecture logicielle, on m a demandé d évaluer la faisabilité d une nouvelle fonctionnalité. Nous voulons pouvoir mettre plus en avant les annonces postées par les personnes actuellement en ligne sur notre système de chat sur le site, ainsi que les annonces postées par les contacts du client effectuant une recherche. La seconde partie est facile à implémenter en rajoutant une condition facultative aux requêtes, ayant pour effet de booster le score des annonces ayant pour auteur une personne figurant parmi une liste définie. La première partie en revanche s annonce plus complexe, car il n est pas réaliste d attacher l immense liste des personnes connectées à chaque requête. Tout d abord, il me faut vous décrire la façon dont nous pouvons être notifiés de la présence ou de l absence d un utilisateur. Notre système de chat utilise le protocole XMPP servi par un serveur ejabberd dans lequel nous avons déjà implémenté un module de listage et de notification des personnes connectées par opposition à la liste des personnes figurant dans une chatroom, car il est inutile est surtout coûteux en terme d échanges réseau d inscrire systématiquement chaque utilisateur dans un tel salon de discussion factice. Ainsi il suffit de créer un client particulier qui se connecte au serveur Stage de 3 ème année Olivier FAVRE 18

Validation Le plus gros du travail de chat et qui s inscrit à ces notifications, pour pouvoir reconstruire une liste tenue à jour des utilisateurs connectés. La première approche que j ai testé consiste à créer un composant à ElasticSearch qui se connecterait au serveur et maintiendrait une telle liste, ainsi qu un nouveau type de requête qui pour chaque document retourné par la requête principale, récupère les auteurs et teste leur existence dans ladite liste, avant d augmenter ou non leur score. Cette approche s est avérée désastreuse en terme de temps de traitement : il fallait une quarantaine de minutes pour l examen de près de 9 millions de résultats retournés par la requête principale. Le goulot d étranglement réside entièrement dans la récupération de la valeur du champ auteur pour un nombre très important de documents. Une seconde approche, proposée par Majid, consiste à tirer parti d une requête particulière d ElasticSearch : on effectue une recherche sur des documents fils, elle nous retourne les documents pères correspondants. De cette manière, nous sommes obligés de tester la présence d un document fils pour chaque annonce, et de booster le score des annonces correspondantes. Nous avons donc la tâche de créer un service externe car les annonces sont réparties entre les différents nœuds du cluster qui maintient la liste des personnes connectées, et qui, pour chaque changement de statut, liste les identifiants des annonces de ladite personne, et commande soit la création d autant de document fils, soit la destruction des documents fils rattachés. En utilisant cette solution, on est capable de continuer à servir les recherches, tout en pouvant gérer plus de 60 changements d états par seconde, pour une moyenne de 10 annonces par personne. Ces performances lors de la recherche sont également dues à l utilisation de l index. 4.5 Validation Cette étape ultime n a pas encore été réalisé, faute de temps. Cette section se limitera simplement à une description de ce qu il est envisagé de faire. 4.5.1 Comparaison des résultats Afin de s assurer que notre travail est fructueux, il convient d en tester les résultats. En programmation les tests unitaires sont fait pour cela. Ici cependant nous sommes en quelque sorte un peu un niveau au dessus, mais la philosophie des tests reste la même : on fournit une entrée, des traitements à effectuer, cela donne un résultat, et nous en analysons la conformité avec un résultat pré-établit. L entrée consiste en un ensemble de documents à indexer, avec un mapping associé éventuel, la plupart du temps le mapping longuement travaillé que nous utilisons sur nos annonces. À cette entrée doit correspondre une instance d ElasticSearch, la plus fraîche possible. Nous allons donc déployer, exécuter et détruire une instance pour chaque test. La facilité de déploiement d ElasticSearch est grandement appréciée ici. À la fin de l indexation, il ne faut pas oublier un appel de l opération refresh, afin que les documents indexés soient immédiatement accessibles à la recherche. Les traitements sont une série de requêtes JSON a jouer auprès de l instance d ElasticSearch de test. Ces requêtes peuvent aussi bien être de la recherche que des ordres de suppression ou autre. Stage de 3 ème année Olivier FAVRE 19

Déploiement Le plus gros du travail Chaque traitement renvoie une réponse JSON. Une analyse poussée à lieu ici. Nous allons vérifier le nombre de résultats trouvés, ainsi que l ordre d apparition de chaque document, voire son score, bien que ce dernier n ait au final aucune importance pour l utilisateur. En fonction de la divergence des résultats avec ceux attendus, nous donnerons une statistique de qualité. Nous ne sommes effectivement pas dans une optique manichéenne qui voudrait qu une seule réponse ne soit bonne. Parmi les test de conformité seront relevée la présence de tous les champs nécessaires, et des champs supplémentaires. L absence d expiration de délai à la recherche sera également important lorsque l on voudra s assurer que le moteur est capable de répondre dans des temps minimes. Un autre critère sera relevés pour un suivit. Il s agit du temps de réponse à l indexation et à la recherche. Tout ceci pourra être réalisé dans l environnement de test de Jenkins, que nous utilisons déjà en interne. 4.6 Déploiement Naturellement, cette étape n a pas encore été réalisée non plus. Cette section présente le fruit d une réflexion avec Abdelmajid Boubrik, Stéphane Jais, Benjamin Devèze, Frédéric Mahé et moi même. Avant d envisager un déploiement, il faut d abord dimensionner l architecture nécessaire. Nous avons jusqu ici tenté de conserver une taille d index raisonnable pour pouvoir tourner sur un cluster de 8 machines possédant chacune une grappe de disques SSD d un total de 640 Go et 96 Go de mémoire vive. Chaque machine coûte environ 10 000 e. Il n est cependant pas exclu de passer à un nombre beaucoup plus important de machine de moyenne gamme. Si ElasticSearch fonctionne toujours mieux avec une grande quantité de mémoire vive, il n a cependant pas besoin de tourner sur un serveur haut de gamme. Tout cela reste quand même à valider, peut être en créant un cluster sur nos machines de travail afin d avoir une meilleure idée des ressources nécessaires. Le début de la migration peut s effectuer de deux manières : dérouter une partie du trafic vers le nouveau cluster, ou migrer tout un pays à la fois. La première méthode présente l avantage de minimiser l impact d un problème éventuel, et de pouvoir effectuer une transition progressive en augmentant petit à petit la quantité de trafic à dérouter. Cependant il faut définir les critères de façon à ce que l expérience d une client ne soit pas perturbée. De même, il est coûteux d indexer une grande quantité de document, nous devons donc nous assurer qu elle serve, ou en indexer moins. Il est délicat de savoir, a priori, quels documents sont susceptibles d intéresser quels utilisateurs sans faire d erreurs. La solution commence à devenir un peu complexe pour valoir le coup en tant que traitement provisoire. La seconde méthode permet une distinction claire sur les requêtes à intercepter : celles qui ne sont effectuées que dans un seul pays, si ce pays figure parmi une liste fixée. L expérience utilisateur peut éventuellement varier si il recherche successivement dans un pays géré par Exalead et dans un pays géré par ElasticSearch, mais cela devrait rester minime et peu dérangeant. Si un problème survient, en revanche, il faudra être très réactif pour repasser le trafic sur Exalead. Nous pouvons cependant commencer par migrer les pays pour lesquels nous avons le moins d annonce et de trafic, avant Stage de 3 ème année Olivier FAVRE 20

Déploiement Le plus gros du travail de basculer petit à petit des pays plus grand, tant en indexation qu en recherche, vers ElasticSearch. Stage de 3 ème année Olivier FAVRE 21

Autre sujet traité Classification de requêtes 5 Autre sujet traité Classification de requêtes En plus d avoir longuement travaillé sur ElasticSearch, j ai eu le plaisir d aborder un autre sujet. Il s agissait de reprendre le travail d un ancien employé afin de le finaliser et de le mettre en production. J ai travaillé sur ce sujet avec le stagiaire d Ing 1 Dan Forest Barbier qui a intégré Yakaz pour un stage estival. Il avait déjà traité un sujet de fouille de données dans les semaines précédentes, et a même été force de propositions. 5.1 But recherché Le site web Yakaz.com ne vous permet pas de choisir dans quel univers vous désirez effectuer votre recherche. Cinq liens sont visibles sur la page d accueil, quelques variantes à www (auto, moto, immobilier, emploi) sont proposées, mais une fois une recherche effectuée, l utilisateur n a pas la possibilité de préciser lui-même l univers désiré. Bien évidemment, une recherche avancée laisse ce choix, mais cela ne correspond pas à l utilisation la plus courante du site. Le but est de rendre ce choix automatique, de sorte que lorsque vous recherchez «appartement paris 15eme», vous n ayez pas à préciser que vous cherchez effectivement de l immobilier. Une fois l univers indiqué, des outils de filtrage avancés spécifiques à la catégorie recherchée apparaissent. La simple analyse de la recherche tapée doit pouvoir permettre de trouver à coup sûr dans quel univers se restreindre pour effectuer la collecte des résultats. Comme on parle effectivement d une restriction du domaine recherché, nous avons là une contrainte qui se dessine : la prédiction doit se tromper très peu souvent, surtout lorsqu une grande différence s en ferait ressentir dans les résultats. En termes de Data Mining, nous devons obtenir une bonne précision, quitte à sacrifier un peu les exigences en terme de rappel. Nous avons effectivement le choix de ne pas répondre, de renvoyer un univers inconnu, afin de ne pas enclencher de filtrage des résultats. S il s avère que 90 % ou plus des résultats effectifs de la requête sont concentrés dans un univers, nous pouvons fixer l univers a posteriori, comme c est actuellement le cas. Enfin, nous noterons que le système devra fonctionner dans plusieurs langues. 5.2 Données 5.2.1 Description Nos jeux de données sont extraits d une base de données mise à jour en traitant les logs pour collecter des statistiques sur les requêtes que les clients ont cherchés sur le site Yakaz.com. L extrait est disponible au format JSON et contient de nombreux champs dont le pays et la langue de l utilisateur et le nombre de résultats. Certaines requêtes contentant des mots injurieux peuvent être notées comme filtrées. Dans notre étude, il sera donc inutile d en tenir compte. Stage de 3 ème année Olivier FAVRE 22

Approches testées Autre sujet traité Classification de requêtes Certaines requêtes sont retravaillées avant d être jouées dans le moteur de recherche, différents champs décrivent les modifications effectuées. L une de ces modifications la plus importante consiste à définir l univers de la recherche. Lorsque plus de 90 % des réponses figurent dans une même cátégorie, cet enrichissement est effectué. En fait, nos jeux de données contiennent quasiment exclusivement des requêtes modifiées ainsi. Les requêtes échappant à la règle sont celles qui proviennent d une recherche avancée où l utilisateur définit en premier lieu l univers qui l intéresse. 5.2.2 Quelques statistiques JSON étant un format très souple, ne forçant aucun type de données particulières sur ses champs, ni même la présence de ces derniers, nous avons dû évaluer un profil de nos enregistrements. Pour cela nous avons mesuré la présence d un champ (nombre de fois qu il était présent ou bel et bien absent), la quantité de valeurs null, de valeur zéro, la moyenne des valeurs numériques, le nombre de fois que la valeur était un tableau ou un objet, son nombre de sous-éléments moyen, ainsi que la moyenne de leur valeur moyenne, et pour finir deux statistiques sur les champs de répartition, que sont la KL divergence et la valeur maximale moyenne, expliquées plus tard. Si tous les champs utiles sont systématiquement présents, certains sont environ 80 % du temps nulls. Les champs indiquant des modifications sont jusqu à 90 % du temps à zéro, sauf certains qui préfère valoir null. Moins de 5 % des requêtes sont filtrées. Nous avons effectivement ignoré chacune de ces requêtes. On voit effectivement qu un format souple autorise un manque de consistance. Par la suite nous avons considéré que null comme 0 valent false pour les autres indicateurs. Forts de statistiques détaillées par champ que nous avons collectés, nous pouvons séparer plusieurs groupes de données : les données les plus certaines, avec plus de 10 résultats, non retravaillées, ayant plus de 95 % de résultats dans une même catégorie, provenant d une recherche avancée, etc. Nous utiliserons ces différents jeux de données afin d évaluer la robustesse d un modèle à différentes qualité de requêtes. À noter que nous utilisons les requêtes retravaillées, afin d être, par exemple débarrassé d une partie du bruit comme la présence d un lieu fréquent qui pourrait éventuellement devenir significatif dans la prédiction (pensez aux recherches «paris 15eme» pour de l immobilier). 5.3 Approches testées Nos instances, que l on appellera documents, sont des (courtes) chaînes de caractères en tous genres aussi bien des lettres que des nombres que des pictogrammes, suivant les langues. Afin de pouvoir les traiter, quelque soit la méthode, nous devrons en extraire des attributs, notés A i, par exemple la présence d un mot particulier. Notre document se résume donc à une suite d attributs. Stage de 3 ème année Olivier FAVRE 23

Approches testées Autre sujet traité Classification de requêtes 5.3.1 Régression logistique Un projet interne déjà réalisé et utilisé depuis plusieurs années, nommé «automatic classifier», permet de réaliser une analyse textuelle sur plusieurs documents, puis de construire un modèle de classification. Ce projet, écrit en Java, est disponible sous forme de WebService. La marche à suivre consiste à : créer un modèle en lui assignant un triplet langue-pays-type ; déclarer les classes à prédire ; mettre à jour diverses options de configuration ; envoyer des documents pour construire l ensemble d apprentissage ; effectuer la construction du modèle ; envoyer des documents à classifier et évaluer la performance du modèle. D apparence très classique, ce projet permet de partager l apprentissage d une langue à travers différents pays pour éviter des jeux de données trop dépourvus, il évite un déséquilibre trop important entre les différentes classes en ignorant les documents surnuméraires, permet un apprentissage régulier sans avoir à le déclencher manuellement, et surtout cela va avec la fonctionnalité précédente de nourrir l ensemble d apprentissage avec les documents classifiés s ils ont bénéficié d une bonne confiance, ni faible ni trop élevée, lors de la prise de décision. De cette manière, le classifieur est effectivement automatique. Prendre un seuil minimal de confiance un peu trop faible aurait pour conséquence de faire dériver le modèle en prenant pour certitude les erreurs éventuellement commises. Prendre un seuil maximal de confiance trop élevé ne ferait que faire grossir inutilement l ensemble d apprentissage sans apporter beaucoup à l élaboration du modèle. 5.3.1.1 Description de la méthode Le modèle est construit en utilisant une rãl gression logistique pour prédire l appartenance d un document à une classe. La fonction de prédiction donnant la probabilité que le document x appartienne à la catégorie (sortie +1) est la suivante : P (Y = +1 X = x) = 1 1 + e ( w,x +b) (4) Le couple (w, b) est déterminé en optimisant la log-vraisemblance de la fonction 4 en se basant sur l ensemble d apprentissage : ( N ) (w, b ) = argmax log (w,b) P (Y = y i X = x i ) λ w p (5) i=1 où λ est un paramètre de régularisation améliorant les capacités de généralisation. L optimisation de 5 est réalisée grâce à la bibliothèque de fonction Lascar. 5.3.1.2 Prise de décision En utilisant le modèle construit, c est à dire le couple optimal (w, b ), on calcule la probabilité P (Y = +1 X = x) que le document x appartienne à la catégorie à prédire. Si cette probabilité est supérieure ou égale à 0.5, alors x y appartient, sinon il n y appartient pas. Stage de 3 ème année Olivier FAVRE 24

Approches testées Autre sujet traité Classification de requêtes Dans le cas multi-classe, autant de classifieurs binaires sont utilisés qu il y a de classes à prédire. On utilise les modèles construits pour calculer les probabilités P k (Y = +1 X = x) et nous assignons la classe C au document, avec : C = argmax k P k (Y = +1 X = x) Si P C (Y = +1 X = x) est inférieur à 0.5, alors nous répondons que la classe est inconnue, sinon nous prédisons la classe C. 5.3.1.3 Pré-traitements Afin d obtenir le vecteur x décrivant le document, des analyseurs tirés de Lucene sont utilisés. Le texte est découpé par série de lettres successives, puis les accents et la casse sont supprimés, enfin, certains mots clés sont supprimés. 5.3.1.4 Résultats CARS HOUSING JOBS MISC BIKES UNK CARS 95.14 % 0.25 % 0.02 % 0.13 % 4.45 % 65.59 % HOUSING 0.16 % 99.31 % 0.34 % 0.17 % 0.02 % 41.20 % JOBS 0.86 % 2.20 % 96.74 % 0.00 % 0.20 % 69.46 % MISC 18.76 % 10.95 % 1.28 % 58.38 % 10.62 % 95.24 % BIKES 1.74 % 0.21 % 0.01 % 0.57 % 97.47 % 58.60 % TABLE 2 Matrice de confusion pour l apprentissage par régression logistique Les premières colonnes donnent les taux de réponses, quand le classifieur a effectivement répondu autre chose que UNK (inconnu). Ce classifieur possède de très bonnes performances avec 97 % de précision, en mettant à part la catégorie miscellaneous qui est certainement difficile à trouver par sa définition même. Il reste néanmoins bien trop indécis, avec près de 60 % de réponses pour lesquelles il ne se prononce pas. De plus, cette méthode étant complexe et nécessitant de l optimisation non triviale, elle est pénalisée par sa lenteur. 5.3.2 Classifieur bayésien naïf Cette technique avait déjà été expérimentée dans le travail que nous avons repris. Nous l avons donc reprise, nous avons testé différents pré-traitements. 5.3.2.1 Description de la méthode En utilisant les probabilités de différents attributs, nous voulons calculer une probabilité pour chacune des classes : p (C D) = p (C A 1, A 2,..., A n ). Les A i représentent les valeurs mesurées pour chacun des attributs pour l instance à classifier. En utilisant le théorème de Bayes on obtient : p (C D) = p (C) p (D C) p (D) Stage de 3 ème année Olivier FAVRE 25

Approches testées Autre sujet traité Classification de requêtes soit : p (C A 1, A 2,..., A n ) = p (C)p (A 1, A 2,..., A n C) p (A 1, A 2,..., A n ) Nous allons chercher à évaluer la formule 6 pour les différentes classes C i. Nous aurons donc plusieurs fractions à comparer, qui auront toutes le même dénominateur que nous allons donc pouvoir ignorer. Le terme p (A 1, A 2,..., A n C) va pouvoir se réécrire comme suit : p (A 1, A 2,..., A n C) = p (A 1 C) p (A 2, A 3,..., A n C, A 1 ) = p (A 1 C) p (A 2 C, A 1 ) p (A 3, A 4,..., A n C, A 1, A 2 ). = p (A 1 C) p (A 2 C, A 1 ) p (A 3 C, A 1, A 2 )... p (A n C, A 1,..., A n 1 ) Nous faisons intervenir ici une hypothèse forte et grandement simplificatrice : supposons les différents attributs comme indépendants. Ainsi on peut effectuer les simplifications suivantes : p(a i C, A j, A k,...) = p(a i C). Cela nous donne : p (A 1, A 2,..., A n C) = p (A 1 C) p (A 2 C)... p (A n 1 C) p (A n C) n = p (A i C) Ainsi, sous notre hypothèse simplificatrice, la formule 6 se réécrit en : i=1 (6) p (C A 1, A 2,..., A n ) = p (C) n i=1 p (A i C) n i=1 p (A i) (7) soit, conceptuellement : p (C D) = p (C) n i=1 p (A i C) p(d) Ce qui revient à regarder l apparition des mots du documents dans les différentes catégories. Notre problème est donc réduit à un simple problème de comptage de chaque classe, de chaque attribut et enfin de chaque attribut au sein de chaque classe pour obtenir respectivement p (C), p (A i ) et p (A i C). Un problème qui intervient fréquemment est celui des probabilités p (A i C) nulles. Ceci étant notamment le cas des mots ignorés. Nous avons décidé d ignorer ces mots dans le calcul des produits de probabilités, comme si certaines catégories ne partagent pas les mêmes attributs que les autres, l information supplémentaire n étant simplement pas utilisée. 5.3.2.2 Prise de décision Une fois que nous avons les différentes probabilités p (C i D), nous allons pouvoir les comparer entre elles. La règle de décision la plus couramment appliquée est celle du Maximum À Posteriori, qui consiste décider que D appartient à C m avec m = argmax (p (C i D)). i Stage de 3 ème année Olivier FAVRE 26

Approches testées Autre sujet traité Classification de requêtes Nous voyons que seule importe l importance relative des probabilités. Nous pourrons donc ignorer le calcul du dénominateur, pour effectuer une simple normalisation après calcul. Ainsi, on peut calculer p(c i ) comme le nombre de documents associés à la classe C i divisé par le nombre de documents dans tout l ensemble d apprentissage, et p (A i C) comme la valeur moyenne de A i pour les documents associés à la classe C i, par exemple en utilisant la présence d un mot : le nombre de documents associés à C i mentionnant A i sur le nombre de documents mentionnant A i. Le calcul de p(a i ) n est donc plus nécessaire. À cela, nous avons adjoint une règle permettant de ne pas prendre de décision, car nous avons vu qu il vaut mieux ne rien dire que de se tromper pour notre application. Une première possibilité, fréquemment rencontrée, consiste à fixer un seuil minimum sur la probabilité p (C m D). L interprétation est facile : non seulement la catégorie répondue doit être la plus probable, mais on doit avoir moins de 1 sueil chances de se tromper, selon le modèle (cela est effectivement différent de la probabilité effective mesurée à cause de l hypothèse très simplificatrice d indépendance). Une seconde possibilité consiste à prendre en compte la loi de probabilité discrète (p(c i D) p(c i )) 2 obtenue : i, p (C i D), et de calculer le χ 2 = i p(c i mesurant la distance ) entre la loi observée avec la loi de distribution des catégories, a priori. Il suffit enfin comme ci-dessus de comparer χ 2 à un seuil à trouver empiriquement. Une troisième possibilité qui avait été évoquée dans les travaux repris consiste à calculer l espérance et la variance de la loi de probabilité transformée : i 0, card (C) 1, p (i) = p ( C σ(i) D ) où la fonction σ : 0, card (C) 1 0, card (C) 1 trie les C i par probabilité p (C i D) décroissante. Plus la variance est faible, plus la décision est sûre, et plus l espérance est proche de 0, plus la différenciation est nette. Par exemple : p 1 (C 0 ) = 0.8, p 1 (C 1 ) = p 1 (C 2 ) = p 1 (C 3 ) = p 1 (C 4 ) = 0.05 donne une espérance de 0.5 (sur un maximum de card(c)/2 = 2.5 dans le cas équiprobable) et une variance de 0.1125, tandis qu une loi de répartition plus concentrée avec la même probabilité p 2 (C 0 ) = 0.8 : p 2 (C 1 ) = 0.2 et p 2 (C 2 ) = p 2 (C 3 ) = p 2 (C 4 ) = 0 donne une espérance de 0.2 et une variance de 0.12. Une quatrième possibilité enfin, qui avait été utilisée dans les travaux repris utilise un concept rattaché à celui de l entropie, nommé la «KL divergence» : D KL (P Q) = i P (i) log 2 P (i) Q(i) Pour rappel, l entropie de Shannon d une source répondant à la loi de probabilité P est définie par : H = P (i) log 2 P (i) (9) i La quantité H = i P (i) log 2 Q(i) correspond elle au nombre de bits nécessaires pour transmettre notre source d informations, en utilisant un codage optimal optimisé pour une source répondant elle à la loi de probabilités Q. On remarque que D KL (P Q) = H H, qui peut être interprétée comme étant le nombre de bits supplémentaires nécessaires à la transmission d une source suivant P, sur un canal pour Q par rapport à un canal pour P. Encore une fois, l utilisation d un seuil permettra de prendre une décision ou de ne pas répondre. Stage de 3 ème année Olivier FAVRE 27 (8)

Approches testées Autre sujet traité Classification de requêtes En reprenant les loi de probabilités p 1 et p 2 définies dans l exemple précédent, on obtient D KL (p 1 équiprobabilité) = D KL (p 2 équiprobabilité) 2.32. (Attention, cette divergence n est pas symétrique et n est donc pas une distance). On n a donc plus de distinction particulière entre des distributions offrant une différenciation nette ou non, les deux distributions se trompant de la même manière pour les catégories ayant les mêmes importances, elles sont toutes deux aussi divergentes de l équiprobabilité. La décision s effectuant sur un seul critère, elle en est également simplifiée. 5.3.2.3 Pré-traitements Le dernier point à traiter est l extraction des attributs à partir du document. Il suffit bien souvent d extraire un attribut par mot connu : 1 s il est mentionné, 0 sinon. Les requêtes étant très courtes et variées, le nombre de mots mentionnés est négligeable face au nombre de mots connus. Ceci nous force à utiliser une représentation creuse des attributs dans les faits, nous ne nous en soucierons même pas et ferons comme s il n existait que les attributs correspondant aux mots mentionnés, afin d éviter encore une fois le problème des probabilités nulles. Nos requêtes étant courtes, nous avons choisi d utiliser la seule information de la présence d un mot, plutôt que d utiliser son nombre d occurrence, qui introduirait une complication inutile dans le calcul des probabilités p(a i = n) pour n > 1. Nous avons préféré utiliser p (A i ) n à la place, calcul qui se réalise sans y penser en regardant les attributs au fur et à mesure de leur extraction. Une des premières étapes dans le pré-traitement consiste à ignorer la casse et à supprimer les accents des mots. En effet, la plupart des requêtes sont tapées en minuscules et beaucoup de personnes omettent les accents. Le fait d entrer une requête avec une majuscule ne change en rien son sens, et s il existe une trop grande disparité sur l utilisation des accents, qu ils soient significatifs ou non, il vaut mieux les ignorer pour ne pas rajouter de discrimination artificielle. Vient ensuite le découpage, ou l extraction, des mots de la requête. Nous avons testé deux approches : utiliser l espace comme séparateur, et utiliser des règles plus complexes dictées par le consortium Unicode selon la locale de la langue utilisée, qui laisse «c est» en un mot, mais qui sépare «wi-fi» en deux pour le français. On peut également se poser la question de la suppression de la ponctuation, pour la remplacer par un espace ou la supprimer tout simplement. Certains mots blancs, dépourvus de sens particulier peuvent également être ignorés. Toutefois la plupart du temps, ils ne sont pas discriminants et n influencent en rien la prise de décision. Puis on rajoutera aux mots extraits, les n-uplets de mots contigus, souvent les paires, voire les triplets. Cela a pour effet de créer plus de nouveaux attributs, dont certains peuvent s avérer très significatifs, comme «à vendre» ou encore «maison de retraite». 5.3.2.4 Post-traitements Il ne faut pas oublier qu un post-traitement peut également s avérer nécessaire, ne serait-ce que pour alléger le modèle et ainsi le rendre moins consommateur en ressources et donc plus rapide. C est le rôle de la sélection des mots du dictionnaire, qui s opère après avoir dénombré l utilisation de tous les mots des documents de l ensemble d apprentissage. Le but Stage de 3 ème année Olivier FAVRE 28

Approches testées Autre sujet traité Classification de requêtes est d en réduire le nombre, ainsi que de réduire les éventuelles fluctuations superflues qu ils pourraient induire sur la prise de décision. Nous trions les mots par entropie, et ne gardons qu une certaine quantité. Nous pouvons donc utiliser un seuil sur la proportion de mots à garder, ou l entropie minimale, ou bien encore de ne garder que les mots au pire n fois moins bons que celui qui possède la meilleure entropie, ou encore en utilisant l entropie moyenne ou médiane. En pratique, on s aperçoit que garder un nombre important de mots n améliore les prédictions que d une manière tout à fait marginale et diminue même la précision de certaines classes tandis qu elle en améliore un peu le taux d inconnus. 5.3.2.5 Résultats Les résultats suivants sont issus de l analyse des logs sur cinq pays : Frace, États-Unis, Mexique, Allemagne et Italie. Commençons l étude par l utilisation des n-grammes : Taux d erreur (en %) 11 11 10 Sans séparateur 10 9 Avec séparateur 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 1 1 2 3 4 5 6 7 8 9 Taille des n-grammes FIGURE 3 Précision et taux d inconnus par taille de n-grammes. Taux d inconnus (en %) Une taille de n-grammes de 1 caractère ne sert à rien, en effet cela revient à compter le nombre d occurrence de chaque lettre dans chaque catégorie, ce qui n est évidemment pas significatif, donc les nouveaux mot-clés suggérés ne sont par retenus. On se servira donc des valeurs de la première colonne comme référence. Une taille faible de n-grammes rajoute 3.8 % d erreur, mais elle va heureusement en diminuant. Cela peut s expliquer par le fait que les tri-grammes ne comportent pas assez de lettre pour comporter une racine de mot pleine de sens. Il est intéressant de savoir également que les bi- et tri-grammes sont souvent utilisés pour détecter la langue dans un texte. Plus la taille des n-grammes croit plus on capture des racines de mot, comme si on effectuait une lemmatisation. De plus, les n-grammes permettent de résister aux fautes de frappes ou d orthographe, si elle ne sont pas très nombreuses. Le taux d inconnus diminue aussi grandement pour des tailles de n-grammes faibles, pour les mêmes raisons que celle explicitées ci-dessus. En effet, un nouveau mot reconnu permet de prendre beaucoup plus de décisions, et parmi celles-ci, de commettre quelques erreur supplémentaires également. Stage de 3 ème année Olivier FAVRE 29

Approches testées Autre sujet traité Classification de requêtes Enfin, nous pouvons choisir d inclure une marque de début ou de fin du mot dans les caractères du n-gramme. Cependant, si cela nous permet de diminuer jusqu à 0.8 % le taux d inconnus, il augmente aussi le taux d erreur d une quantité presque aussi importante. Notre but étant d être le plus précis possible même si cela revient à être prudent en répondant que l on ne peut pas classifier une requête, nous ne pouvons évidemment pas nous autoriser un troc dans ce sens, aussi peu avantageux. Pour conclure, on voit que les n-grammes, s ils rajoutent un faible pourcentage d erreur, au mieux seulement 0.8 %, ils aident à diminuer le taux d inconnus, jusqu à 6.5 %. Cependant, cela a un coût, car la taille de la base de données en est également très affectée. Voyons maintenant l influence de l utilisation de n-uplets de mots : Précision (en %) Rappel (en %) Inconnus (en %) 100 96 92 88 84 80 100 90 80 70 60 50 40 50 40 30 20 10 0 normal 2-uplets 2-uplets 4 3-uplets 2+3-uplets Overall Cars Bikes Housing Jobs Miscellaneous Overall Cars Bikes Housing Jobs Miscellaneous Overall Cars Bikes Housing Jobs Miscellaneous FIGURE 4 Précision, rappel et taux d inconnus par taille de n-uplets et par classe. 2-uplets 4 indique que nous avons donné 4 fois plus de poids aux 2-uplets, par rapport aux singletons. 2+3-uplets indique la présence de couples et des triplets de mots. Stage de 3 ème année Olivier FAVRE 30

Méthode retenue et déploiement Autre sujet traité Classification de requêtes Si les 2- et 2-uplets 4 font perdre jusqu à 1.2 % de précision, ils permettent en revanche d augmenter le rappel de 10 % en moyene, en divisant le taux d inconnus par 2. Ceci est un troc que nous pouvons largement accepter, car si nous répondons mieux sans les n-uplets, nous répondons correctement moins de fois. En effet, la comparaison doit tenir compte de la précision avec le taux d inconnu, bien plus faible. Les 3-uplets, ainsi que les 2+3-uplets en revanche, bien qu ayant un effet très puissant sur le taux d inconnus en le faisant passer en dessous de 1.5 %, la perte de précision occasionnée rend cette technique mois intéressante pour nos besoins. 5.4 Méthode retenue et déploiement Pour sa rapidité et sa performance, nous avons choisi d utiliser la seconde méthode, le classifieur bayésien naïf. Nous avons retenu les pré-traitements suivants : normalisation, séparation aux espaces, rajout des paires de mots. 5.4.1 Base de données Le modèle n étant d autre qu une base associative enregistrant les probabilités de chaque mot dans chaque classe. Après plusieurs tests, nous avons opté pour utiliser un format de données propre, plutôt que d utiliser une BerkeleyDB comme ce qui était déjà le cas pour d autres besoins internes. À l initiative de Dan, nous avons créé une structure de base de données simple en deux parties : Type long long n float[5] n Contenu nombre d entrées : n hash des mots probas des mots FIGURE 5 Structure de la base de données Les mots sont triés et recherchés dans la première partie de l index par dichotomie. La position dans cet index où la correspondance est éventuellement trouvée, correspond exactement à la position à lire dans la seconde partie de l index, laquelle contient les 5 probabilités associées aux 5 univers à détecter. La séparation en deux de l index permet de garder un alignement sur 64 bits sur la partie la plus accédée, ce qui améliore les performances à l accès mémoire pour le CPU. Les mots eux-mêmes ne sont pas utilisés afin d éviter de trop nombreuses comparaisons lettre à lettre, les premières étant rapides car ne comparant que les quelques premières lettres avant de trouver une différence, mais les dernières étant plus lentes car tous les mots restant à comparer divergent plusieurs lettres plus tard. Nous avons utilisé à la place une somme de hashage qui permet une comparaison instantanée réalisée intégralement par le CPU. La fonction de hashage utilisée est djb2, mise au point par Daniel Berstein, qui s écrit comme suit : hash(i) = hash(i-1)*33 ˆ str[i] hash(0) = 5381 Stage de 3 ème année Olivier FAVRE 31

Méthode retenue et déploiement Autre sujet traité Classification de requêtes avec str[i] étant le i ème caractère du mot et ˆ l opérateur ou-exclusif. La multiplication par 33 est fréquemment écrite en décalage de bits : x 33 = x 5 + x, où dénote un décalage de 5 bits vers la gauche. Cette fonction de hashage est connue pour être très rapide à calculer et avoir de très bonne propriétés de distribution, causant peu de collisions. 5.4.2 Extension PHP Le site web Yakaz.com étant écrit en PHP, il fallait un interfaçage facile avec ce langage. Nous avons tout d abord pensé accéder directement à la base de données avec les appels de lecture de fichier, assez proche du C, mais nous avons rencontré un problème majeur. En effet, le calcul de la somme de hashage ne fonctionnait pas pour les mots dès une dizaine de lettres. Ceci était dû au fait que PHP ne gère pas les nombres de façon conforme à la norme IEEE 754 et effectue une conversion magique en nombre flottant si un calcul dépasse la valeur maximale d un entier long 64 bits signé, soit 2 63 1 = 9 223 372 036 854 775 807. Il a donc fallu soit créer un serveur de détection que l on ferait tourner à côté du serveur web perspective délicate d un point de vue de stabilité très longue durée mais surtout d un point de vue déploiement, soit créer une extension PHP écrite en C ce qui évite comparé à la solution précédente les coûts d une connexion réseau locale, et qui tourne à une vitesse native, les accès mémoires étant réalisés à l intérieur même du processus. Ceci est également une bonne solution car nous n aurions pas à réécrire le code du pré-traitement des requêtes. De plus, la bibliothèque ICU permettant d effectuer la normalisation des chaînes de caractères est déjà intégrée à PHP depuis peu. Un processus PHP peut répondre à plusieurs requêtes avant de se terminer. Un module possède une méthode d initialisation appelée au début du processus, ainsi qu une méthode de réinitialisation appelée au début de chaque requête. Nous pouvons ainsi charger des données qui seront réutilisées à travers plusieurs appels. Il nous est alors venu à l idée de charger en mémoire le contenu entier du fichier. De plus, comme plusieurs processus PHP sont lancés en parallèle par le serveur web, nous pouvons partager la mémoire afin d éviter de charger plusieurs fois la base de données de manière parallèle. Une solution semblait naturellement se dessiner : utiliser la fonction mmap de Linux. Elle permet d établir une projection en mémoire d une portion d un fichier. Nous avons utilisé différentes options afin de charger l intégralité du fichier, de pré-remplir la mémoire autrement remplie à la volée en fonction des besoins, d obtenir une projection en lecture seule, mais surtout d obtenir une projection partagée entre processus. L accès au fichier se réalise après projection avec une arithmétique de pointeurs classiques, ce qui nous facilite d autant plus la tâche pour notre utilisation. Si toutes ces conditions n étaient pas réunies, ouvrir le fichier pour chaque requête, lire simplement les quelques octets nécessaires, et refermer le fichier, aurait été plus rapide, le cache système aidant. Mais l utilisation d une projection persistante, car il y a toujours plusieurs processus PHP lancés en même temps, nous permet de descendre jusqu à 0.1 µs par requête! Stage de 3 ème année Olivier FAVRE 32

Méthode retenue et déploiement Autre sujet traité Classification de requêtes 5.4.3 Gestion des langues Nous manquons parfois cruellement d annonces et de recherches loggées pour certaines langues. Heureusement, s il ne nous est pas possible de construire un modèle adapté à ces langues, les noms de marque et de modèles sont quasi-systématiquement identiques quelle que soit la langue utilisée. Ainsi la base de donnée déjà construite permettra quand même de classer une recherche pour «volkswagen» dans la catégories voitures. D ailleurs, cela vous est peut être déjà arrivé de tomber sur une page en chinois où les seuls mots que vous cherchiez sont ceux que vous parvenez à déchiffrer. Si mélanger les données de sorties est bénéfique, il ne faut pas mélanger les requêtes d apprentissage à l aveugle, car la méthode de sélection des mots peut avoir comme effet de bord de filtrer une très grande partie des mots d une langue. Non pas que l entropie s en trouve biaisée, mais que la méthode de sélection des mots en posttraitement peut devenir trop restrictive. 5.4.4 Apprentissage incrémental 5.4.4.1 L idée générale L étape de construction du modèle étant rapide, il ne sert à rien d élaborer un système complexe permettant l apprentissage au fur et à mesure que les requêtes sont posées. Nous pouvons attendre sans problème la prochaine analyse des requêtes, et déposer les nouvelles requêtes dans un fichier venant compléter la base d apprentissage. Il est plus direct de travailler avec les comptages, desquels on déduit la répartition, plutôt que de passer par des détours et autres pirouettes de calcul. Il est également impossible de travailler sur la base du modèle précédent à cause du filtrage effectué : les mots peu fréquents ou peu discriminants étant oubliés, il sera difficile, voire imprécis de pouvoir en tenir compte ultérieurement. Nous devons donc mémoriser les compteurs de chaque mot dans chaque univers, et mettre à jour ces compteurs en traitant un nouvel export supplémentaire. Cette base incrémentale permet également de se séparer des fichiers d export traités et d économiser de l espace disque : nous avons obtenu 850 Mo de base incrémentale pour 27 Go de fichiers d export traités, soit une compression de 97 %, la totalité des informations initialement présentes ne nous étant pas utile. 5.4.4.2 Le procédé Les fichiers d export proviennent d une base de données mise à jour quotidiennement après une analyse des logs, permettant de suivre l ajout, la suppression mais également les changements de la répartition des résultats dans les différents univers. Du point de vue de l export incrémental, nous sommes donc en présence de plusieurs cas : Création d une nouvelle entrée ; Il nous faut alors au minimum les champs utilisés dans les traitements décrits précédemment. Suppression d une entrée ; Nous avons besoin des anciennes valeurs des champs, et d une indication de la suppression. Stage de 3 ème année Olivier FAVRE 33

Méthode retenue et déploiement Autre sujet traité Classification de requêtes Modification d une entrée existante. Nous devons travailler conjointement avec les anciennes et les nouvelles valeurs des champs. Du point de vue du calcul des apparitions de chaque mot dans chaque univers, plusieurs événements sont importants : Modification de l identité d une requête ; En fonction des règles de préférences, nous ne choisissons plus la même requête à analyser. Il va donc falloir décrémenter les compteurs des anciens mots clés, et incrémenter ceux des nouveaux. Modification de l univers d une requête ; Il faut décrémenter les compteurs des mots clés dans l ancien univers, et incrémenter ceux du nouvel univers. Modification du filtrage de la requête ; Un requête est filtrée lorsqu elle est blacklisted ou lorsque son univers est all (inconnu). Si la requête n est plus filtrée, l entrée compte pour un ajout, si c est l inverse, elle compte pour une suppression. Bien évidemment les ajouts et suppressions des entrées. Au final, grâce à la présence des anciennes et des nouvelles valeurs des champs, l algorithme reste très simple : Récupérer la nouvelle identité de la requête courante, ainsi que l ancienne identité, d après les anciennes valeurs. De même, récupérer le nouvel et l ancien univers, ainsi que les nouvelles et anciennes valeurs *blacklisted. Si l ancienne et la nouvelles identité, univers et valeurs de blacklistage sont identiques, passer à la requête suivante. Si l ancien univers existe, et qu il n est ni all (inconnu) ni null (non précisé, pas encore calculé) et si les anciennes valeurs des champs de blacklistage sont à 0 Analyser l ancienne identité. Pour chaque mot clé, décrémenter le compteur associé dans l ancien univers. Si le nouvel univers n est ni all ni null et si les nouvelles valeurs des champs de blacklistage sont à 0 Analyser la nouvelle identité. Pour chaque mot clé, incrémenter le compteur associé dans le nouvel univers. 5.4.4.3 Optimisations La base de données incrémentale après analyse de l export initial fait déjà dans les 850 Mo. Sa construction nécessite en revanche des structures plus volumineuses en mémoire car elles doivent être facilement modifiables, plus de 6 Go environ. Nous avons donc dû éviter d avoir à charger en mémoire l intégralité du contenu de l ancienne base pour la modifier. Nous avons considéré de ne conserver que les différences observées sur les compteurs modifiés. Mais cette méthode est lente quand nous devons calculer le nombre d éléments présents dans la base finale, car nous devons supprimer les entrées nulles et que le format de la base observe un décalage en fonction du nombre d éléments contenus. Nous avons pensé ensuite à utiliser un cache en mémoire. Chaque entrée modifiée Stage de 3 ème année Olivier FAVRE 34

Méthode retenue et déploiement Autre sujet traité Classification de requêtes était préalablement lue sur le disque ce qui reste très rapide grâce à l index puis montée dans la même structure en mémoire que précédemment, avant d y appliquer les différences de comptage. Les entrées nulles sont ensuite dénombrées entièrement en mémoire, avant d entamer l écriture de la base finale en suivant le procédé d un tri par fusion. Afin d éviter le problème initial du chargement complet des structures dynamiques en mémoire, il ne nous reste plus qu à effectuer l apprentissage initial petit à petit, sur un nombre d entrées réduit à la fois. 5.4.4.4 Parallélisation Ceci était satisfaisant, mais nous nous sommes vite aperçus qu il était facile d aller plus vite. En effet, un seul processeur était utilisé, et nous ne saturions pas les entrées/sorties disques. Nous avons tenté d utiliser les fonctions d incrémentation et de décrémentation atomiques sur une mémoire commune à plusieurs processeurs, mais cette solution s est très vite montrée plus lente qu escompté pour une utilisation très intense. Un mélange entre les deux idées précédentes répond parfaitement à nos attentes, en appliquant la stratégie MapReduce : Chaque fil d exécution traitant une partie des entrées met à jour un compteur des différences à appliquer (Map) ; À la fin de son exécution, nous récupérons les différences et appliquons une fusion de plusieurs de ces données à la fois (Reduce) ; La fusion de ces compteurs différentiels est appliquée à une copie de cache en mémoire vive de la base de données. Si le cache principal dépasse une certaine quantité de mémoire, afin de ne pas trop être gourmand en ressources, nous entamons un export de la base de données incrémentale. Une fois toutes les entrées traitées, un export final de la base de données incrémentale est effectué. Le goulot d étranglement de cet algorithme réside dans l écriture du cache dans la base incrémentale, mais c est une étape incontournable, et également un moyen de réguler la consommation de ressources. 5.4.4.5 Export À la fin de toute cette aventure de mise à jour incrémentale, nous écrivons une nouvelle base de données du modèle de prédiction, laquelle applique le filtrage des mots utiles et contient leur répartition dans les différents univers. Cette nouvelle base est copiée sur un serveur, et sera poussée sur les machines faisant tourner le site web, lors de la prochaine mise en production. Si la base incrémentale est quelque peu volumineuse, la base du modèle de prédiction elle est bien plus petite (environ 20 octets de moins par entrée) et contient surtout moins d entrées. À noter que la copie de la base est elle-même optimisée grâce à l utilisation de la copie différentielle de l utilitaire rsync qui tente de ne copier que les octets modifiés. Grâce à un système de somme de contrôle partielle, il calcule une signature par partie de fichier, et ne transmet que les zones modifiées par le réseau. Or notre base de donnée évolue relativement peu au final : l index est quasiment stable Stage de 3 ème année Olivier FAVRE 35

Méthode retenue et déploiement Autre sujet traité Classification de requêtes sauf pour quelques insertions et suppressions, et les données sont peu nombreuses à être modifiées. Elle se prête donc très bien à cette copie optimisée. Stage de 3 ème année Olivier FAVRE 36

6 Perspectives Perspectives 6.1 Moteur de recherche Une fois le moteur de recherche des petites annonces portées sur ElasticSearch, nous pourrons continuer à migrer tous les autres index que nous utilisons pour identifier les mots clés ou encore les lieux géographiques. Chacun avec leur spécificités, ils nécessiteront certainement quelques développements supplémentaires afin d optimiser le fonctionnement du moteur aux différents besoins, aussi bien en terme de réactivité que de souplesse de requêtage. 6.2 Classification de requêtes Un tel système de classification pourrait gagner à être développé sous la forme d un serveur autonome et permettant l apprentissage interactif, de manière similaire à l automatic-classifier, éventuellement sous la forme d un algorithme alternatif pour ce dernier. 6.3 Autres tâches futures 6.3.1 Détection des topics Dans sa prochaine version, le site web Yakaz.com possédera des profils plus complets, ainsi qu une dimension sociale supplémentaire. Parmi ces changements figureront des badges mesurant la participation d une personne à divers types d annonces, questions, événements et autres contenus, lesquels seront catégorisés dans différents thèmes, appelés de façon anglicisée «topics». Si cette mission semble beaucoup se rapprocher de la classification de requêtes, elle diffère premièrement par la taille du texte analysé, une éventuelle analyse sémantique à en tirer, mais surtout par l aspect catégorisation, par opposition à classification. La catégorisation est un apprentissage non supervisé, il nous incombera donc de trouver un moyen pour que l algorithme utilisé découvre par lui-même qu un certain nombre de topics ressortent, et qu il en propose une caractérisation, voire même jusqu à proposer quelques libellés. Cette affectation s inscrit dans la même lignée que mon Projet de Fin d Études, qui catégorisait des articles de presse, afin de faire ressortir différentes tendances de l actualité. 6.3.2 Jeux mobiles Dans une démarche de diversification des activités afin de favoriser la croissance de l entreprise, nous avions entamé des séances de brainstorming dirigées par un consultant, Franck Debane, afin d imaginer le prochain service que notre entreprise pourrait développer. L équipe dirigeante a finalement opté pour se lancer dans la création de jeux vidéos pour plateforme mobile. Nous ne possédons pas beaucoup de connaissance dans ce domaine, n ayant réalisé que l application Yakaz pour Android et ios, mais les compétences techniques polyvalentes de notre équipe de développement nous permettront de Stage de 3 ème année Olivier FAVRE 37

Autres tâches futures Perspectives relever le défi. Le choix d un tel secteur économique a également été guidé par la volonté de dépendre d autres lois de marché, afin de réduire les risques éventuelles d une crise de secteur. Stage de 3 ème année Olivier FAVRE 38

7 Apports personnels Apports personnels Après une bonne quantité d années d étude et quelques stages, me voici enfin dans le monde professionnel. Je dois avouer être très content, et j imagine être très bien tombé avec Yakaz. Je me retrouve dans mon élément dans une entreprise où ce que l on demande c est essentiellement d être à l aise et d avoir envie de toucher à n importe quelle technologie. Cette expérience m a permis également de goûter enfin à la collaboration, ayant surtout travaillé seul dans mes missions précédentes. J ai en effet travaillé durant trois mois avec deux consultants à raison d un jour par semaine, et un mois entier avec Dan, sur un projet à temps plein. Il me reste certainement beaucoup à apprendre car j ai trouvé difficile de se coordonner avec des collaborateurs autonomes lorsque l on a peu d interaction, par exemple quand l un avance sur un sujet en parallèle du sujet qui m occupait principalement. Avec Dan j ai pu appréhender le partage des tâches, tantôt en y participant, tantôt en supervisant. D un aspect plus professionnel, j ai approché les sysèmes répartis en étudiant le fonctionnement d ElasticSearch. Cette caractéristique donne une dimension supplémentaire à la programmation, et est vecteur d une réelle puissance. Je pense qu un tel aspect, peut aider à dénicher des informations autrement plus difficiles à révéler en Data-Mining. Certains algorithmes de fouille de données sont certes déjà distribués, mais faire vivre les données en les faisant interagir entre elles peut résulter en une résonance particulière locale qui n aurait pas été détectée autrement. Même en conservant un modèle simpliste, il est possible de construire un système en Data-Mining obtenant de bonnes performances de prédiction. J ai une fois de plus vu que le travail en amont sur les données fait souvent toute la différence entre un modèle adapté et un modèle balbutiant. Mais il faut également veiller à ne pas trop les transformer car cela peut les dénaturer alors même que le processus à l air plus adapté. J ai découvert un peu mieux les langages fonctionnels et des traitements hautement asynchrones, sans pour autant en avoir utilisé. Si l inconvénient d une immuabilité des données me gêne aux premiers abords, surtout d un point de vue optimisation de l utilisation mémoire, les gains de parallélisation gratuit que cela semble apporter apportent beaucoup pour un traitement d une très grande quantité de requêtes concurrentes. Arriver à un même résultat est plus verbeux en programmation procédurale, et plus sujet à des oublis, ou autre bugs. Stage de 3 ème année Olivier FAVRE 39

8 Conclusion Conclusion Nous avons approché la structure d un moteur de recherche distribué et vu son déploiement dans une optique de grande envergure. De même nous avons abordé une méthode de prédiction de résultats, afin d améliorer l expérience utilisateur sans avoir besoin d effectuer plusieurs requêtes dans le moteur de recherche. Sans être tout à fait optimales, les solutions que nous avons développées sont puissante et exploitent bien les performances offertes par le matériel informatique actuel à travers notamment la parallélisation et la répartition des calculs en sein d un cluster de machines. Dans un monde où tout tend à la mondialisation, un traitement distribué des données est en passe de devenir une condition sine qua non pour la réussite d un service grand public ou une brique de traitement de données interne. Avec ElasticSearch, il semble que la relève du monde de l OpenSource est assurée vis à vis des solutions de recherche professionnelles propriétaires. Stage de 3 ème année Olivier FAVRE 40