Projet IDAPA

Accueil > Bases de données relationnelles et indexation du contenu > Entrepôts de documents XML pour scoring avec Indri

Entrepôts de documents XML pour scoring avec Indri

mardi 14 avril 2009, par Eric Sanjuan

Il est désormais possible de gérer directement un entrepôt de documents XML sans nécessité de référencer ces documents dans une base de données relationnelles eternes.

Principe de Indri

Parmi les outils de gestion de documents XML, l’indexation Indri qui fait partie de la boîte à outils LEMUR est particulièrement efficace. Conçu d’emblée pour fonctionner sur des architectures réparties, il gère facilement des entrepôts de l’ordre du la dizaine de Teras sur des clusters de machines.

Or cet outil du MIT écrit en C++ est totalement libre. Une version professionnelle avec support vient d’ailleurs d’être lancée.

Initialement imaginé pour la recherche d’information, l’intégration du XML décuple les possibilités d’utilisation.
On dispose en effet de trois fonctionnalités :
- un outil d’indexation qui permet de référencer tous le mots, les dates, les ordinaux et les balises XML.
- un langage d’interrogation qui permet de retrouver tout document ou sous-document contenant certains mots ou un intervalle de valeurs (dates ou ordinal).
- un modèle de langage qui permet de rechercher des documents proches.

Les transparents de Don Metzler présentent bien ces différentes fonctionnalités.
On peut trouver les détails techniques sur ces pages :
- on trouve ici le détail du paramétrage des index,
- ici pour interroger directement les index,
- là pour la grammaire du langage d’interrogation,
- enfin, regarder ici pour des outils simples d’interrogation.

Quels sont les avantages du semi-structuré (XML) dans le suivi de la gestion client ?

Imaginons que l’on exporte régulièrement au format XML l’historique de chaque client. De plus en plus de bases de données transactionnelles incorporent cette possibilité. MySQL entre autres.

L’intérêt du XML est qu’il ne suppose pas le pré-existence d’un modèle relationnel intangible. Ainsi, même si le schéma de la base de donnée évolue dans le temps, l’entrepôt peut suivre cette évolution sans qu’on ne doive modifier sa structure. Les éventuels nouveaux champs correspondent simplement à de nouvelles balises XML, qu’il suffit d’ajouter à la liste des balises à indexer. Des opérations telles que le regroupement de dimensions (pliage) peut se faire au niveau du langage d’interrogation sans perte d’efficacité grâce à l’efficacité des index.
Il est ainsi possible de procéder à des recherches complexes et en temps réel dans l’historique clients.

En fait, le principe de l’indexation Indri n’est pas de concevoir un unique index central comme dans les bases de données relationnelles, mais une multitude de petits indexs autonomes qui peuvent être réparties et interrogés simultanément.

D’autre part, l’intégralité du document est compressée avec les index correspondants et disponible pour affiner toute requête. Ainsi une fois le document indexé, il n’est pas nécessaire d’en garder une copie accessible.

Par contre, le moteur SQL disponible sur des index de documents XML est bien sûr très limité sur des données semi-structurées.

Ceci justifie de disposer d’outils qui permettent facilement de passer d’une base relationnelle type MySQL à un index indri, dans les deux sens, avec l’idée que la base relationnelle ne contiendra qu’un (large) échantillon de données pour analyse et exportation vers d’éventuels outils statistiques.
On a donc besoin des fonctionnalités suivantes :
- Création de nouveau historiques.
- Ajout de données dans des historiques existants.
- Constitution d’échantillons à partir de l’historique.

Le problème de scoring vu comme un problème de recherche d’information

Utiliser Indri pour exploiter un entrepôt de données XML est parmi les exemples d’utilisation reconnues de cet outil.

Peut-on envisager d’aller plus loin et se servir de son modèle de langage pour définir de nouvelles applications de scoring ?

L’élaboration d’une fonction de scoring conduit généralement à la pondération de certains critères. Or la fonction weight permet de combiner ces pondérations en une requête unique. Elle calcule le logarithme de la probabilité qu’un document vérifie tous ces critères, en tenant naturellement compte de critères manquants.

D’autre part, l’intégralité du dossier d’un nouveau client peut être codé sous forme de requête. J’ai expérimenté Indri avec des requêtes complexes d’une page. On retrouvera dans notre historique un échantillon de clients similaires que l’on peut exporter et analyser pour classer le nouveau client.

Dans les deux cas on peut espérer améliorer les actuelles fonctions de scoring en intégrant un mécanisme probabiliste plus souple qui permette de prendre en compte en temps réel l’évolution des données (disparition de certains critères caducs, données manquantes, nouvelles informations).

Bon, j’avoue l’idée n’est pas totalement de moi. Elle est aussi très dans le vent sur la côté est des USA depuis que toutes les certitudes sur la gestion des risques se sont effondrées. Pour qu’une fonction de scoring soit efficace, il faut maintenant qu’elle puisse évoluer en temps réel.