webleads-tracker

Polyspot a lancé l’InfoWarehouse. Mais … C’est quoi au juste?

 

Par Sonia Heimann, Chef de projet, Sollan France.

On a décortiqué pour vous le principe de “l’entrepôt d’info” ou “InfoWarehouse” de Polyspot. Parce qu’au début on ne comprenait pas bien de quoi il en retournait. En fait, ce n’est pas si compliqué et c’est surtout bien pensé.

Explications :

 

Un moteur de recherche, comment ça marche ?

Un moteur de recherche tel que PolySpot fonctionne en deux sous-systèmes :

  • Un sous-système est dédié à l’indexation : il s’agit de parcourir un corpus documentaire (fichiers, bases de données, sites Internet, …), pour constituer des fichiers d’index à des formats optimisés pour les recherches plein texte. Cette constitution d’index doit s’exécuter une première fois, puis ensuite, fonctionner en différentiel, pour re-parcourir le corpus et mettre à jour uniquement ce qui a changé.
  • Un sous-système est dédié à la recherche : lorsqu’un utilisateur recherche un mot dans un champ de saisie, le moteur interroge ces fichiers d’index (et non directement le corpus documentaire) pour proposer des réponses. Ce sous-système peut également proposer des fonctionnalités avancées (filtrage des résultats, alertes, recherches sauvegardées…).

Avoir deux sous-systèmes permet d’assurer des délais de réponse acceptables au moment de la recherche : il s’agit de minimiser les calculs à exécuter pour fournir une réponse pertinente au moment de la recherche, en les déportant à un moment ou ils ne sont pas pénalisants.

 

 

La première indexation, c’est un peu long.

Le fait de préparer les données en amont apporte son lot de contraintes.

Prenons un cas de figure simple : l’indexation d’un disque réseau partagé par tous les collaborateurs de la société.

Si le corpus documentaire à indexer compte des centaines de milliers de documents (et un disque réseau partagé atteint vite ces volumétries !), et si des fonctionnalités d’extraction sémantique ou de génération de vignettes ont été mises en place, on peut facilement attendre des semaines avant d’en avoir réalisé la première indexation. Dans un projet, nous avons constaté un ratio x20 du temps d’indexation en ajoutant ces fonctionnalités … c’est à dire qu’on peut passer d’une journée d’indexation à 3 semaines !

 

Utilisateur attendant la fin d’une indexation initiale (allégorie)

 

 

Ensuite, il s’agit de rafraîchir régulièrement les index en effectuant des indexations dites différentielles. Dans notre exemple de l’indexation d’un disque réseau, il faut re-parcourir tous les documents et comparer un par un leur date de dernière modification avec celle stockée dans l’index. Une indexation différentielle peut donc, elle aussi, prendre quelques heures et parfois, suivant la volumétrie, il n’est pas envisageable de rafraîchir les index plus d’une fois par jour.

 

Différentiel, ça présuppose… une différence !

Lorsqu’on indexe un disque réseau sans fonctionnalités complémentaires, détecter une différence est simple : si la date du fichier a changé, on sait que le fichier a changé.

Mais le plus souvent, on souhaite profiter de la mise en place d’un moteur de recherche pour ajouter de l’intelligence à l’indexation, en implémentant des processus de traitement.

Un exemple simple de traitement est d’indiquer la nature d’un document en fonction d’éléments contenus dans son chemin ou dans son nom (ex : les documents dont le nom contient “propositions” ou “contrats” reçoivent la nature “Documents Commerciaux”).

Un exemple plus abouti est d’effectuer des extractions sémantiques à partir du contenu du document : extraction d’entités nommées, détection de thèmes…

 

Données utilisateur non structurées (allégorie)

 

 

Ces traitements ne dépendent pas du document lui même, ils constituent un enrichissement additionnel. Ils sont calculés au moment de l’indexation des documents, et ajoutés aux méta-données du document.

Cependant, les règles de traitement peuvent évoluer. Dans notre exemple ci-dessus, on peut imaginer qu’après quelques semaines, on souhaite affiner la règle de détection des “Documents Commerciaux” pour la rendre plus pertinente. Mais les documents déja indexés ne sont pas en eux mêmes modifiés (leur date n’a pas changé…), donc une indexation différentielle ne les verra pas comme modifiés, et ne permettra pas de les re-catégoriser.

Si on souhaite modifier un enrichissement (ajout d’un nouveau traitement, changement d’un algorithme sémantique), on ne peut pas se reposer sur une indexation différentielle puisque le document physique n’a pas changé. Il n’y a pas le choix, il faut tout réindexer. Et c’est reparti pour une ré-indexation complète… parfois, pour un simple re-calcul d’une seule métadonnée.

 

 

Et si on ne re-calculait que l’enrichissement modifié ?

Pour être plus efficace, il suffirait de pouvoir recalculer uniquement l’enrichissement qui a été modifié, sans avoir à re-parcourir et ré-indexer l’intégralité du corpus documentaire….

Et c’est exactement ce que PolySpot a mis en place, avec l’InfoWarehouse.

 

Polyspot terrassant les temps d’indexation avec son InfoWareHouse, sous le regard de l’utilisateur (allégorie)

 

Le principe mis en place par PolySpot est de découpler le temps de la récupération de données du temps de l’enrichissement des données, et de garder dans un stockage intermédiaire (l’InfoWarehouse) le résultat de la récupération et des enrichissements. Ceci permet de garder à disposition les données, sous un format accessible (noSQL), afin de pouvoir mettre à jour ou calculer des nouveaux enrichissements.

Cela nécessite cependant un peu de code, la plupart des enrichissements étant propres à chaque corpus et chaque cas d’utilisation, il est difficile d’en proposer une librairie “standard”. Dans le cas du système d’enrichissement PolySpot, ceux-ci peuvent être codés en Java ou en Groovy, et une interface graphique permet de les configurer.

Bien entendu, lorsqu’on souhaite modifier un enrichissement, il faut toujours ré-appliquer le calcul de l’enrichissement sur toutes les données. Mais le mécanisme de l’InfowareHouse permet de ne re-calculer que l’enrichissement modifé, en conservant intouchés tous les autres calculs déja effectués. Si vous avez indexé des centaines de milliers de documents et que vous avez calculé une vignette de prévisualisation pour chacun d’entre eux, le gain de temps est manifeste.

On pourrait également imaginer, pour les traitements longs (ex : calcul de vignette), de mettre à disposition l’information brute (sans vignette) aux utilisateurs, tout en lançant en parallele le calcul de vignette dans l’InfowareHouse. Cet élément de confort visuel apparaîtra donc au fur et à mesure, mais très rapidement, on aura pu fournir aux utilisateurs l’essentiel : la donnée brute.

 

 

La solution idéale ?

Si l’InfowareHouse permet de répondre à des problématiques de mise à jour plus rapide des index dans un contexte de mise en oeuvre d’enrichissements, son utilisation implique certaines contraintes.

Espace Disque : puisque le résultat intermédiaire de la récupération des données est stocké pour réutilisation ultérieure, l’espace disque nécessaire au moteur de recherche prend de l’ampleur - en effet on doit stocker à la fois les index consultables, et le résultat intermédiaire..

Supervision : La mise en oeuvre d’enrichissements dans l’InfowareHouse apporte une complexité supplémentaire. Au lieu de déclencher un processus d’indexation qui va tout gérer et calculer les enrichissements à la volée, on doit gérer des processus indépendants : récupération, enrichissement, indexation full-text du produit de l’enrichissement, et s’assurer de leurs bon déroulements et déclenchements synchrones.

Complexité de mise en oeuvre : le fait de pouvoir modifier à la volée les données de l’InfowareHouse par des requêtes de type “base de données” donne une grande puissance au système, mais on est loin de la simplicité du drag and drop !

 

 

 

En conclusion

 

La mise en oeuvre d’un tel dispositif apporte une grande richesse et une forte maîtrise des données indexées. La décision de mise en oeuvre devront cependant être évaluée au cas par cas. Pour une indexation simple et aux contours figés, cet outil ne nous semble pas forcément nécessaire au regard des contraintes apportées. En revanche, dans un contexte de corpus documentaire fortement évolutif, le cout initial de mise en oeuvre de l’InfoWarehouse sera plus facilement rentabilisé.

 

 

 

 

Crédits icono :
http://commons.wikimedia.org/wiki/File:Portrait_de_Suzanne_Valadon_par_H...
http://commons.wikimedia.org/wiki/File:To_the_Unknown_Voice.JPG 

http://commons.wikimedia.org/wiki/File:Jost_Haller_-_Saint_George_slayin...