Sur cette page, il est possible de voir le statut de la dernière compilation nocturne. Si ce statut indique une compilation réussie, la procédure pour obtenir et compiler les sources est la suivante :

Créer un répertoire de travail :

mkdir ~/solr-4.0

Se placer dans ce répertoire et récupérer les sources :

cd ~/solr-4.0
svn checkout http://svn.apache.org/repos/asf/lucene/dev/trunk

Compiler les sources :

cd ~/solr-4.0/modules
ant compile
cd ~/solr-4.0/lucene
ant dist
cd ~/solr-4.0/modules
ant dist

Le tour est joué !

Lucene et différentes contributions permettent de disposer d’analyzer et même de « stemmer » pour un grand nombre de ces langues. Avec Solr, le seul moyen pour associer le bon analyzer à chaque langue est d’avoir autant de champs dans le shema qu’il y a de langues possibles et d’associer à chaque champ le bon analyzer. Pour Hurisearch, cela aurait donc fait 60 champs pour le contenu des documents et 60 champs pour les titres. L’autre problème dans ce cas est également de ne pas pouvoir chercher lors d’une même requête dans la totalité des langues  simultanément. Autant dire que ces contraintes et limitations ne sont pas acceptables.

Il est impératif d’utiliser un champ unique pour toutes les langues. Comme il est possible d’associer un seul analyzer à ce champ, ce dernier doit donc s’adapter à la langue du texte en cours d’indexation et à la langue de la requête (il faut également traiter la requête en fonction de sa langue). Deux analyzers ont donc été développés afin de traiter le texte au mieux en fonction de sa langue : un analyzer pour indexer le texte sans le « stemmer » et un en le « stemmant » lorsque cela est possible (voici une explication en anglais de ce qu’est un stem).

Le dernier point à résoudre a été de trouver comment indiquer à l’analyzer la langue du texte qu’il va traiter. Avec Lucene, cela n’est pas un problème car les constructeurs (classes java) des analyzers  peuvent posséder une paramètre qui indique la langue. Par contre, avec Solr, cela n’est pas possible, les paramètres passés aux constructeurs des analyzers sont figés dans le fichier shema.xml. La solution a donc été de passer cette information en en-tête du texte lors de l’indexation et de la requête lors de la recherche.

En conclusion, nous avons été en mesure d’indexer un grand nombre de langues tout en pouvant rechercher simultanément dans tous les documents quelque soit leur langue et en offrant la possibilité de retrouver les mots indépendamment de leurs formes (genre, nombre, conjugaisons, …). Aujourd’hui, Hurisearch crawle 5400 sites Web sites qui représentent plus de 10 millions de pages indexées pas Solr.

* créer un répertoire de travail

mkdir /tmp/solr

* copier solr.war dans /tmp/solr

* extraire le contenu de solr.war et effacer solr.war

cd /tmp/solr
jar -xvf solr.war
rm solr.war

* remplacer dans /tmp/solr/WEB-INF/lib tous les fichiers lucene-…-2.9.0.jar par leurs équivalents en version 2.9.3.

* astuce pour les utilisateurs de mac os, il faut supprimer les fichiers cachés « .DS_Store » qui ont été créés dans chaque répertoire

find . -name .DS* -print -exec rm -rf {} \;

* reconstruire solr.war

jar cvf solr.war .

Pour consulter la liste des évolutions et corrections depuis Lucene 2.9.0, vous pouvez consulter le « Lucene Change Log« .

Dans les précédents articles consacrés à Solr, j’en décris les principes (Présentation de Lucene Solr) et comment installer et configurer de façon très basique Solr afin de pouvoir indexer et rechercher dans le jeu de données de test fourni dans la distribution (Solr – Installation et configuration (1)).

Dans ce nouvel article, je vais expliquer plus en détail les points suivants :

• Le contenu de la distribution
• Les fichiers de configuration
• Comment gérer plusieurs indexes ?
• Comment gérer plusieurs applications ?

Le contenu de la distribution

Une fois récupérée et décompressée dans un répertoire, la distribution de Solr contient différents répertoires.

Mettre en place un environnement d’exécution de Solr à partir des éléments de la distribution est très simple. Il faut :

1. créer un environnement d’exécution en copiant le répertoire « /example/solr », sous par exemple « /opt/solr » (Linux) ou « c:/solr » (windows)
2. copier le fichier solr.war contenu dans le répertoire webapps des exemples vers le répertoire approprié du serveur d’application (répertoire webapps par exemple pour Tomcat)
3. configurer le serveur d’application pour qu’il soit lancé avec la variable d’environnement solr.home.home pointant vers le répertoire d’exécution (par exemple : -Dsolr.solr.home=/opt/solr) et le redémarrer

Dans le répertoire pointé par la variable d’environnement « solr.solr.home », on retrouve donc les répertoires « bin » (scripts utilitaires pour un environnement Linux), « conf » (fichiers de configuration) et « data » (y sera entre autres localisés l’index Lucene des données indexées).

Les fichiers de configuration

Les fichiers de configuration sont localisés dans le répertoire « /conf ». Il s’agit principalement de solrconfig.xml et schema.xml.

solrconfig.xml

Il s’agit du fichier qui contient l’essentiel des paramètres liés au fonctionnement de Solr et plus particulièrement des paramètres de l’API Lucene qu’utilise Solr (longueur maximale d’une champs, taille des buffer mémoire, fréquence de commit, …) . Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entière dans le wiki Solr.

schema.xml

Il s’agit du fichier qui décrit comment seront indexées les données dans Solr. Il définit les types de données, les champs, les manipulations sur les données lors de l’indexation, les champs obligatoires, le champ de requête par défaut, …

Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entiere dans le wiki Solr.

Exemple de déclaration d’un type

<fieldType name=”string” class=”solr.StrField” sortMissingLast=”true” omitNorms=”true”/>

Ce type a pour nom « string », il sera pris en charge lors de l’indexation par la classe « solr.StrField », lors d’un tri du résultat sur ce champ, les documents ne le possédant pas seront positionnés en dernier (sortMissingLast= »true ») et lors de l’indexation les informations de normalisation basées sur la taille du champ seront calculées et stockées (omitNorms= »true »).

Exemple de déclaration d’un champ

<field name=%u201Dword%u201D type=%u201Dstring%u201D indexed=%u201Dtrue%u201D stored=%u201Dtrue%u201D/>

Les données indexées dans Solr par le service d’indexation sont contenues dans un datagramme de type XML. Lorsque Solr traite ce datagramme, il rapproche le nom de chaque élément XML avec le nom d’un champ. Il manipule alors la donnée associé à cet élément comme cela est défini par la définition du champ.
Ce champ est du type « string » (donc il hérite des propriétés de ce type). Il est indexé (donc les recherches peuvent porter sur son contenu) et les données de ce champs sont stokées (donc elles peuvent être récupérées au moment de l’affichage d’une liste de résultats par exemple). D’autres paramètres importants peuvent également être définis lors de la déclaration d’un champ. Il s’agit de la méthode d’analyse lors de ‘indexation ou de la recherche. La méthode d’analyse permet de définir comment seront traitées les données du champ, à savoir son mode de découpage en mots (tokenizer) et les filtres qui lui seront appliqués (filter). Les filtres permettent par exemple de supprimer les mots vides, de mettre tous les mots en minuscule, de convertir les mots accentués en leurs équivalents sans accent, …

Exemple de déclaration d’un champ dynamique

Une déclaration de champ dynamique permet d’associer un traitement à des éléments du datagramme XML même si ces derniers ne sont pas spécifiquement déclarés comme champs.

<dynamicField name=%u201D*_s%u201D  type=%u201Dstring%u201D  indexed=%u201Dtrue%u201D  stored=%u201Dtrue%u201D/>

Tout élément du datagramme XML dont le nom se termine par « _s », est considéré comme un élément de nom « string ».

Comment gérer plusieurs indexes ?

Par défaut, une instance Solr ne peut manipuler qu’un index. Comment faire si mon application doit permettre l’indexation de plusieurs types de données comme par exemple un annuaire de personnes et les messages d’un forum de discussion ? Jusqu’à la version de 1.2 de Solr, il existait 2 solutions : associer un type à chaque document dans l’index (personne, message, …) ou utiliser plusieurs webapps dans le serveur J2EE et les faire pointer vers des environnements différents (-D=solr.solr.home=…). L’association d’un type à chaque document permet lors de la recherche de filtrer la liste de résultats en se limitant aux documents d’un ou plusieurs types. Utiliser plusieurs webapps permet d’utiliser un index distinct pour chaque type de documents. Avec la version 1.3 de Solr est apparue la notion de « SolrCore » multiples. Un « SolrCore » est un environnement complet Solr (configuration et index) qui est exécuté par une webapps du serveur j2EE. Il est donc possible au moyen d’une seule webapps Solr de gérer plusieurs « SolrCore ». les SolrCore sont déclarés dans un fichier XML « solr.xml » localisé dans le répertoire solr.solr.home associé à la webapp.

Exemple d’un environnement mono-core

solr.solr.home=/opt/solr  

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /bin
        /conf
        /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Les urls d’accès à l’administration et aux web service Solr sont :

Exemple d’un environnement multi-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt

    /solr
        solr.xml
        /core0
            /bin
            /conf
            /data
        /core1
            /bin
            /conf
            /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Dans le répertoire pointé par solr.solr.home, on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="core0" instanceDir="core0" />
        <core name="core1" instanceDir="core1" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr des cores 0 et 1 sont :

Comment gérer plusieurs applications ?

Imaginons que vous souhaitez indexer des données issues de différentes applications, pour l’exemple, un outil de gestion de contenu (ECM) et un forum de discussion. Chacune de ces applications nécessitant l’indexation de 2 types de données totalement différentes, pour l’exemple, des utilisateurs et des documents (ECM) ou des messages (forum).

Dans ce cas, je propose d’utiliser une webapp par application et un core par type de données.

On a donc un environnement comme celui-ci :

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt

    /solr
        /ecm
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /documents
                /bin
                /conf
                /data
        /forum
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /messages
                /bin
                /conf
                /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier ecm.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/ecm" override="true" />
</Context>

et le fichier forum.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/forum" override="true" />
</Context>

Dans le répertoire « /opt/solr/ecm », on place de fichier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="documents" instanceDir="documents" />
    </cores>
</solr>

Dans le répertoire « /opt/solr/forum », on place de fichier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="messages" instanceDir="messages" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr de l’application ECM sont :

Les urls d’accès à l’administration et aux web service Solr de l’application Forum sont :

Sous Linux, une optimisation peut être de factoriser le répertoire « bin » de chaque core car il contient exactement les mêmes scripts. On place un répertoire « bin » dans « /opt/solr » et dans chaque core, on créer un lien symbolique nommé « bin » et qui pointe sur « /opt/solr/bin ».

Pour synthétiser les différents cas de figure lors du choix d’une configuration de Solr, voici un tableau récapitulatif.

Suite au premier article Présentation de Lucene Solr, voici un article sur la mise en oeuvre de ce moteur de recherche. Les différents sujets abordés seront :

• L’installation
• La configuration
• L’indexation
• La recherche

Cette première partie a pour but l’installation et la configuration minimum afin de pouvoir rechercher dans les documents d’exemple fournis dans la distribution de Solr.

Pré-requis

• Installer Java 1.6 update 11 ou supérieur. Pour récupérer Java SE, c’est ici.
• Installer Tomcat. Pour récupérer Tomcat 5.5, c’est ici.
• Récupérer une distribution de Solr. C’est ici pour la version officielle et ici et pour les derniers builds nocturnes.

Installation

Décompresser l’archive dans un répertoire de travail. Pour cet article, il s’agit de « d:\solr ». Un sous-répertoire est créé. Selon la version de Solr que vous aurez récupéré, ce répertoire peut s’appeller « apache-solr-nightly » ou « apache-solr-1.4.0″. Je suggère donc pour simplifier de renommer ce répertoire en « apache-solr ».

Configurer Solr pour un fonctionnement avec Jetty

Pour faire fonctionner avec la version de Jetty fournie avec Solr, il n’y a pas vraiment de configuration. Pour démarrer Jetty, il faut ouvrir une console et se placer dans le répertoire « d:\solr\apache-solr\example » et exécuter la commande suivante :

java -jar start.jar

Une fois que vous voyer apparaître la ligne suivante, le serveur est démarré :

INFO: [] Registered new searcher Searcher@d642fd main

On accède alors à l’administration de Solr avec l’url suivante :

http://localhost:8983/solr/admin

Pour une utilisation avec une instance existante de Jetty, la page du wiki qui explique la configuration est ici.

Configurer Solr pour un fonctionnement sous Tomcat 5.5

1. Afin de pouvoir passer en mode HTTP-GET des critères de recherche utilisant des caractères internationaux (code supérieur à 127) il est nécessaire d’éditer le fichier conf/server.xml de Tomcat et d’ajouter l’attribut suivant à l’élément Connector approprié : URIEncoding="UTF-8".

Il s’agit à priori du connecteur correspondant au port 8080, ce qui donne quelque chose comme ceci :

<Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150"
 minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
 redirectPort="8443" acceptCount="100" connectionTimeout="20000"
 disableUploadTimeout="true" URIEncoding="UTF-8" />

2. Copier le fichier « d:\solr\apache-solr\example\webapps\solr.war » dans le répertoire webapps de Tomcat.

3. Au moyen de la console Tomcat (dans le system tray), ajouter le paramètre

-Dsolr.solr.home=d:\solr\apache-solr\example\solr

4. Redémarrer Tomcat.

On accède alors à l’administration de Solr avec l’url suivante :

http://localhost:8080/solr/admin

Indexer un jeu de données en exemple

La distribution de Solr inclue un jeu de documents de test pour l’indexation. Il est possible de les indexer au moyen du package java post.jar.

Ouvrir une console et se placer dans le répertoire « d:\solr\apache-solr\example\exampledocs »

Avec Jetty, lancer la commande :

java -jar post.jar *.xml

Avec Tomcat, lancer la commande :

java -Durl=http://localhost:8080/solr/update -jar post.jar *.xml

Pour obtenir la liste de toutes les options de cet utilitaire, la commande est :

java -jar post.jar -help 

Exécuter des recherches

Solr est maintenant fonctionnel et des données sont indexées. Il est donc possible d’exécuter les premières recherches avec le formulaire suivant :

http://localhost:8080/solr/admin/form.jsp

Vous pouvez constater que les résultats sont fournis au format XML. C’est effectivement à l’application appelant Solr de mettre en forme ces résultats.

Conclusion

Dans cet article, nous avons installé et fait fonctionné Solr dans un environnement Tomcat sous Windows. Par la suite j’aborderai plus en détail la configuration, les options de recherche et l’exploitation des résultats.

Dans cet article, je présente une solution afin de générer un nuage de tags (ou nuage de mots clefs) à partir d’un flux de données textuelles. Pour l’exemple, il s’agit de titres d’articles stockés dans un fichier texte.

Le but est d’afficher les mots ou expressions de 2 ou 3 termes les plus fréquents dans les titres. Tous les termes ou expressions ne sont pas à conserver dans le nuage de tag. Une des étapes consiste en un filtrage selon des règles définies dans fichiers de règles : suppression des mots vides (je, le, pour, …), suppression des expressions commençant ou se terminant par un mot vide (”ne mange”, “termes les”, …), suppression des nombres, …

Les étapes nécessaires à la mise en œuvre de cette solution sont :

• Etape 1 : indexation des titres dans Lucene
• Etape 2 : extraction des termes ou expressions de l’index
• Etape 3 : filtrage des termes ou expressions
• Etape 4 : affichage du nuage en PHP

Les 3 premières étapes sont réalisées en java avec Lucene et donne comme résultat un fichier de termes ou expressions retenues dans le nuage de tags avec leur fréquence d’apparition.

La 4ème étape est réalisée en PHP et exploite le fichier résultat des étapes précédentes afin de mettre en forme le nuage de tags.

Pourquoi utiliser Lucene (étapes 1 et 2) ?

La génération du nuage de tags nécessite 2 étapes que Lucene est à même de réaliser : analyser et découper le texte servant à générer le nuage de tags et indiquer la fréquence d’apparition de chaque mot ou expression.

Lucene utilise des analyzers afin d’indexer le texte. Ces analyzers ont pour rôle principal de découper le texte en « token ». Selon les analyzers utilisés les tokens sont séparés par des espaces, des ponctuations, des caractères spéciaux (#, @, …), des chiffres, …

Par exemple, pour la phrase suivante : « Parcours du Tour de France », les tokens seraient sans doute : « parcours », « du », « tour », « de » et « France ».

Dans notre nuage de tags, nous ne voulons pas uniquement des mots simples, mais également des expressions de 2 ou 3 mots. Il nous faut donc extraire toutes les combinaisons possibles de tokens de 1, 2 ou 3 mots, c’est-à-dire : « parcours », « du », « tour », « de », « France », « parcours du », « du tour », « tour de », « de France », « parcours du tour », « du tour de » et « tour de France »

Un analyzer permettant de faire cela est disponible non pas dans la distribution standard de Lucene, mais à l’adresse suivante : http://issues.apache.org/jira/browse/LUCENE-400. Inutile de récupérer cet analyzer, j’en fournie les sources modifiés afin de fonctionner avec Lucene 2.3.2

Pour une présentation plus complète de Lucene, voir mon article « Introduction à Lucene« .

Pourquoi filtrer les termes ou expressions (étape 3) ?

Dans l’exemple indiqué ci-dessus, les termes ou expressions obtenues sont : « parcours », « du », « tour », « de », « France », « parcours du », « du tour », « tour de », « de France », « parcours du tour », « du tour de » et « tour de France ». On remarque immédiatement des éléments que l’on ne souhaite pas voir apparaître dans le nuage : « du », « de », « parcours du », « du tour », « tour de », « de France » et « du tour de ». Il s’agit des mots-vides ou expression commençant ou se terminant par un mot-vide. Il reste donc les éléments suivants : « parcours », « France », « parcours du tour » et « tour de France ».

Nous pousserons le nettoyage jusqu’à supprimer les mots simples ou expressions apparaissants déjà dans une expression constituée de plus de mots. En effet, imaginons des données à analyser contenant une ou plusieurs fois les expressions suivantes : « tour de France », « tour d’Italie » et « tour d’Espagne », mais jamais ou peu de fois les mots « tour », « France », « Italie » et « Espagne » hors de ces expressions. Sans ce nettoyage, le nuage de tags contiendrait certainement « tour », « Italie », « France » et « Espagne » (très fréquents) et sans doute mais sans certitude « tour de France », « tour d’Italie » et « tour d’Espagne » (moins fréquents). Le nuage de tags serait alors complètement faux.

Ainsi nettoyé, le nuage devient « parcours du tour » et « tour de France » et est beaucoup plus pertinent que ce que nous avions obtenu avant le filtrage.

L’algorithme de nettoyage utilisant un fichier de règles est adapté de l’algorithme décrit dans l’article « Lucene Tag Cloud Generator » de Richard Friedman.

Le fichier de règles est principalement constituer de la liste des mots vides mais commence par 5 paramètres pouvant être désactivés (en mettant les lignes en commentaires avec un #). Il s’agit de :

• -smallwords : pour retirer les mots de 3 caractères ou moins
• -numbers : pour retirer les nombres
• -dashes : pour retirer les mots contenant un tiret (« – »)
• -period : pour retirer les mots contenant un point
• -include : pour retirer les mots ou expressions incluent dans une autre expression. J’ai mis cette option pour le principe, mais en la désactivant les résultats sont généralement très décevants.

Code source des étapes 1, 2 et 3

Le code source java est disponible ici sous forme d’un projet Eclipse. Il contient les fichiers suivants :

• NGramAnalyzerWrapper.java et NGramFilter.java (analyzer Lucene)
• TagCloud.java (classe principale avec l’algorithme de filtrage)
• input.txt (les données exemples à analyser)
• rules.txt (le fichier de règles)

Pour lancer l’analyse d’un fichier de données, l’usage est le suivant :

Usage: org.apache.demo.TagCloud -input [inputfile] -output [outputfile] -rules [rulesfile] -count [count] -boost [boost] -minfreq [minfreq] -maxterm [maxterm]
 
    input    - input file with data to be clouded
    output   - output file with cloud data
    rules    - rules file
    count    - max number of items within the cloud (default = 1000)
    boost    - boost value for multi-terms tags (default = 1)
    minfreq  - minimum frequence for a ngram (default = 2)
    maxterms - maximum number of terms in expressions in the cloud (default = 3)
 
Example: java org.apache.demo.TagCloud -input /tmp/input.txt –output /tmp/output.txt -rules /tmp/rules.txt -count 100 -boost 1 -minfreq 3 -maxterm 4

Etape 4 : affichage du nuage en PHP

La mise en forme du nuage de tags utilise le fichier généré par le programme précédent. Une classe PHP réalise cette mise en forme (lecture du fichier et génération du code html) et une feuille de style définie les styles d’affichage.

La classe PHP est une adaptation du code proposé dans l’article « Tagcloud Font Distributor« .

Le code source disponible ici est constitué des fichiers suivants :

• cloud_tag.inc.php : la classe de génération du nuage de tags en html
• tagcloud.css : la feuille de styles pour l’affichage de nuage de tags
• cloud_tag_display.php : un script d’exemple utilisant la classe et la feuille de styles.

Résultats

Voici quelques exemples de résultats obtenus à partir du fichier de données exemple et en faisant varier quelques paramètres.

Exemple 1 : paramètres par défaut

Exemple 2 : paramètres par défaut sauf boost = 3

On remarque un plus grand nombre d’expressions de plus de 1 mot

Exemple 3 : paramètres par défaut sauf maxterm = 5 et boost = 5

On remarque des expressions jusqu’à 5 mots et presque plus de mots seuls

Stratégies de mise à jour du nuage de tags

La stratégie de mise à jour du nuage de tags dépend de plusieurs paramètres :

• type de données (presse, forums, …)
• la fréquence de mise à jour des données (chaque seconde, une fois par heure, une fois par jour, …)
• le dynamisme que l’on veut donner au nuage

Par exemple, pour des données peu changeantes et en faible quantité, on peut choisir de créer le nuage sur les données des 30 derniers jours avec régénération du nuage une fois par jour. Par contre, pour des données très changeantes comme un site de presse avec des données nouvelles toutes les secondes, on peut choisir de générer le nuage sur les données de la dernière journée voir des dernières heures avec régénération du nuage chaque heure voir chaque quart d’heure.

Conclusions

Je pense que des règles de filtrage basées sur des expressions régulières pourraient être ajoutées. Par exemple, une simple règle indiquant de ne pas accepter les mots avec des points ou des tirets remplacerait les règles « -dashes » et « -period », une autre remplacerait « -number ». On pourrait mettre en place un grand nombre de règles supplémentaires comme par exemple le rejet des dates.

Je suis ouvert à toutes suggestions afin d’améliorer de la solution proposée.

La nouvelle version 1.4.0 de Solr est enfin disponible. Cette sortie est l’occasion de présenter Solr à ceux qui ne le connaissent pas encore.

Solr (on prononce « solar ») est une outil open source permettant de mettre en place des fonctionnalités de recherche dans différents types d’applications et notamment des sites web (mais pas seulement). Solr est basé sur Lucene qui est présenté dans un précédent article. Cette nouvelle version bénéficie des dernières évolutions de Lucene 2.9.

Comme Lucene, Solr est développé en Java. Il étend les fonctionnalités de Lucene et en simplifie la mise en oeuvre. Sorl fournit principalement 3 choses :

• un web service d’indexation des données
• un web service de recherche
• une interface web d’administration

Avec Solr, les documents sont ajoutés à une collection via « XML over HTTP » (une requête HTTP en mode POST qui envoit des données XML décrivant le document à indexer), et les recherches sont faites avec au moyen d’une requête HTTP qui retourne un résultat au format XML (les documents correspondants à la requête). Le traitement des requêtes HTTP par Solr se fait au moyen d’une servlet (installé sous Tomcat par exemple).

Les 3 principaux avantages à utiliser Solr et non pas Lucene seul sont :

• Le fonctionnement en mode services WEB (REST), c’est à dire, la possibilité d’indexer et de rechercher des documents sans la moindre ligne de code si ce n’est la construction des données XML pour l’indexation et l’exploitation des données XML retournées par une recherche
• l’utilisation dans des applications écrites dans n’importe quel langage et permettant de communiquer en HTTP
• Solr étend et optimise Lucene (performances, analyseurs de texte, monitoring, …)

Les fonctionnalité principales ajoutées à Lucene sont :

• Configuration au moyen de fichiers XML
• Mise en évidence des termes trouvés (Hit highlighting)
• Navigateurs dans les résultats (Faceted search)
• Gestion de cache
• Une interface d’administration Web
• Architecture extensible basée sur des plugin
• Optimisation pour des hauts trafics Web
• Statistiques

Pour comprendre le fonctionnement de Solr, je vous conseil ces articles (en anglais) :

• Le tutorial de Solr
• Solr: Indexing XML with Lucene and REST
• Une première présentation sous forme de slides
• Une seconde présentation sous forme de slides

Voici une série de 3 articles (toujours en anglais) d’une très grande qualité écrit par Grant Ingersoll. Les 2 premiers articles sont une présentation détaillée de Solr et le troisième présente les nouveautés de la version 1.3 sortie en septembre 2008.

Mai et Juin 2007 :

• Search smarter with Apache Solr, Part 1: Essential features and the Solr schema
• Search smarter with Apache Solr, Part 2: Solr for the enterprise

Septembre 2008 :

• What’s new with Apache Solr (1.3)
  

Bonne lecture.

Il s’agit bien d’une librairie avec laquelle il n’est pas fourni d’outils permettant l’indexation de données en quelques clics de souris et quelques paramétrages. Il faut donc en passer par du code Java afin de mettre en place une solution sur mesure de recherche plein-texte.

Principe

Lucene indexe et retrouve des « documents ». Par document, on ne parle pas de fichiers Excel, Word, PDF ou HTML, mais d’une structure de données constituée de champs. Un champ est une donnée possédant un nom (titre, auteur, date de publication, contenu, ..) et à laquelle est associé du texte. C’est ce texte qui est indexé, recherchable et affichable. Les documents indexés sont regroupés au sein d’une collection de documents appelée « index ». Un index peut contenir plusieurs centaines, milliers ou millions de documents et il est possible de créer autant d’index différents que le nécessite votre ou vos applications. Physiquement, un index est un répertoire (que vous spécifiez) hébergeant un nombre variable de fichiers (ça c’est l’affaire de Lucene).

Si le texte qui est à indexé est contenu dans des fichiers Excel, Word, PDF ou HTML, c’est de votre ressort d’en extraire de contenu textuel qui sera indexé. Il est possible d’utiliser par exemple pdftotext pour les fichiers PDF, Antiword pour les fichiers Microsoft Word ou tout simplement la boite à outils Tika qui permet l’extraction du contenu d’un grand nombre de format de fichiers.

Obtenir et utiliser Lucene

La version actuelle de Lucene est la 2.9 et est disponible ici. La fichier lucene-x.x.x.zip est suffisant, mais le fichier lucene-x.x.x-src.zip avec les sources devient vite intéressant lorsque l’on veut étendre les possibilités de lucene et disposer d’exemples de code.

Dans la suite de cet article nous allons voir un exemple minimaliste illustrant comment indexer et rechercher des données. Cet exemple nous permet d’introduire les concepts de base de Lucene : document, field, analyzer, query, hits, …

La première chose à faire afin de pouvoir développer des classes Java utilisant Lucene, c’est de créer un projet dans votre environnement de développement et d’y inclure la librairie principale de Lucene : lucene-core-x.x.x.jar. J’utilise pour ma part Eclipse. A noter qu’un bug dans Sun Java 1.6 a posé problème avec Lucene (détails ici), ce bug a été corrigé à partir de la version 1.6.0_10-rc-b28.

Un peu de pratique

L’exemple qui suit est constitué d’une unique classe LuceneIntroduction.java dont voici le projet Eclipse complet dans un fichier zip.

Squelette de la classe

Le code suivant constitue le squelette de la classe. Il déclare les packages nécessaires et la méthode main qui exécute successivement une méthode pour l’indexation et une méthode pour la recherche.

import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.*;
import org.apache.lucene.index.IndexWriter;
 
import org.apache.lucene.search.Query;
import org.apache.lucene.search.Hits;
import org.apache.lucene.search.Hit;
import org.apache.lucene.queryParser.QueryParser;
import org.apache.lucene.search.IndexSearcher;
 
import java.io.File;
import java.util.*;
 
public class LuceneIntroduction {
  static final String INDEX_DIR = "c:\\temp\\index_test";
  public static void main(String[] args) {
    if (!index())
      System.exit(1);
    if (!searchAndDisplay("titi"))
      System.exit(1);
    if (!searchAndDisplay("bla"))
      System.exit(1);
  }
  // ...
}

Indexer des données

L’indexation de données met en oeuvre 4 classes Lucene.

Le code suivant créer un index et ajoute 3 documents dans cet index. La méthode createDocument est plus particulièrement dédiée à la création d’un objet Document Lucene constitué de 3 champs : id, titre et texte.

public static boolean index () {
 
  File dir = new File (INDEX_DIR);
 
  if (dir.exists()) {
    System.out.println("Impossible de créer l'index dans le répertoire '"
                       + INDEX_DIR
                       + "', veuillez le supprimer d'abord.");
    return false;
  }	
 
  try {
    // Création de l'index
    IndexWriter writer = new IndexWriter(INDEX_DIR,
                                         new StandardAnalyzer(),
                                         true);
 
    // Création et indexation d'un premier document
    Document doc = createDocument ("1", "Titre 1", "bla bla");
    writer.addDocument(doc);
 
    // Création et indexation d'un second document
    doc = createDocument ("2", "Titre 2", "titi tutu");
    writer.addDocument(doc);
 
    // Création et indexation d'un troisième document
    doc = createDocument ("3", "Titre 3", "bla bla titi tutu");
    writer.addDocument(doc);
 
    // Fermeture de l'index
    writer.close();
 
  } catch (Exception e) {
    e.printStackTrace();
    return false;
  }	    
 
  return true;
}
 
private static Document createDocument (String id, String titre,
                                        String texte) {
 
  // Créer un document vide
  Document doc = new Document();
 
  // Créer le champ id
  doc.add(new Field ("id", id,
                     Field.Store.YES, Field.Index.UN_TOKENIZED));
 
  // Créer le champ titre
  doc.add(new Field ("titre", titre,
                     Field.Store.YES, Field.Index.TOKENIZED));
 
  // Créer le champ texte
  doc.add(new Field ("texte", texte,
                     Field.Store.NO, Field.Index.TOKENIZED));
 
  return doc;
}

On remarque que l’analyzer utilisé est spécifié au constructeur de l’objet IndexWriter. Et qu’un ensemble d’attributs importants sont spécifiés au constructeur de l’objet Field.

Le premier attribut est le mode de stockage de la donnée associée au champ : Field.Store.YES (stocké) ou Field.Store.NO (non stocké). Pour être indexé, une donnée ne doit pas forcément être stockée. On stockera un titre et un auteur par exemple car il doivent pouvoir être récupérés afin d’être affichés dans une liste de résultats. La totalité du texte d’un document PDF de 100 pages ne sera pas stocké mais juste indexé.

Le second attribut est le mode d’indexation de la donnée associée au champ : Field.Index.NO (non indexé), Field.Index.TOKENIZED (indexé avec découpage en mots), Field.Index.UN_TOKENIZED (indexé sans découpage en mots).

Rechercher

La recherche met en oeuvre 6 classes Lucene.

Le code suivant recherche les documents correspondant au critère et les affiche.

public static boolean searchAndDisplay (String criteria) {
 
  try {
    IndexSearcher searcher = new IndexSearcher(INDEX_DIR);
    QueryParser parser = new QueryParser("texte", new StandardAnalyzer());
    Query query = parser.parse(criteria);
    Hits hits = searcher.search(query);
 
    System.out.println("Résultats pour '" + criteria + "': " + hits.length());
    Iterator iter = hits.iterator();
    while(iter.hasNext()) {
      Hit hit = iter.next();
      Document doc = hit.getDocument();
      System.out.println(doc.get("titre"));
    }
  }
  catch (Exception e) {
    e.printStackTrace();
    return false;
  }	    	    
 
return true;
}

Résultat de l’exécution

Résultats pour 'titi': 2
Titre 2
Titre 3
Résultats pour 'bla': 2
Titre 1
Titre 3

Et si mes applications ne sont pas écrites en Java ?

Si vous acceptez de ne pas utiliser la toute dernière version de Lucene, vous pouvez utiliser une version portée dans votre langage de programmation préféré. Il existe de nombreux portages : Perl, Python, Ruby, C, C++, .NET, Common Lisp et PHP (recherche uniquement).

Si comme moi vous préférez utiliser la version originale Java en permanente évolution grâce à sa grande communauté de développeurs, voici ma suggestion : les Services Web.

Vous avez écrit une application Web dont l’interface est en PHP et les données sont dans une base SQL. Vous n’avez pas le choix, il faut développer votre moteur de recherche avec Java. Par contre, il faut également interfacer ce moteur de recherche avec votre application PHP pour lancer les recherches et afficher les résultats.

Pour la partie indexation des données il n’est pas nécessaire de s’interfacer avec le PHP, une application Java autonome peut être développée. Par contre, pour la recherche il faut interfacer le code PHP avec le code Java. La solution consiste en la mise en place de Services Web écrits en Java et fonctionnants sous Tomcat. Il n’est pas nécessaire de se lancer dans des Services Web au standard SOAP, le standard REST est largement suffisant. En gros une requête HTTP est envoyée à une servlet qui elle même retourne des résultats au format XML. Cette méthode permet d’interfacer la recherche Java/Lucene à tous types d’applications (WEB ou non WEB) et écrites dans n’ importe quel langage.

Extensions de Lucene

L’exemple présenté est comme je l’ai déjà dit « minimaliste ». Les possibilités offertes par Lucene sont très larges et se rapprochent des moteurs de recherche les plus puissants. En effet, il existe de nombreuses extensions fournies dans la distribution : analyzers avancées, corrections orthographiques, mise en évidence des termes recherchés dans les résultats, …

En voici la présentation dans la Sandbox Lucene

Utilitaires

Voici deux utilitaires intéressants en phase de développement.

Luke – outils de monitoring et de consultation des index

Limo – outils de monitoring des index

Documentation

La documentation est disponible ici. En plus de la javadoc, on y trouve une FAQ, un Wiki et différents articles intéressants.

jGuru fournit une FAQ Lucene intéressante.

Et enfin, il existe un livre en anglais basé sur une déjà ancienne version 1.4 : Lucene in Action (2004). La second édition du livre doit être disponible prochainement.

Support et assistance

Lucene est un projet open source, il n’existe pas de support à proprement parlé, mais il existe une mailing-list et un forum très actifs qui permettent d’obtenir de l’aide et des suggestions pour les problèmes les plus pointus.

Projets utilisant Lucene

Solr

eXtensible Text Framework (XTF)

Hibernate Search

Avant de pouvoir offrir une page de recherche et des résultats, il est nécessaire de réaliser certaines tâches comme par exemple la création d’un index des données. En simplifiant, les étapes de la mise en place d’une solution de recherche sont :

• accéder aux données à indexer : système de fichiers, sites web (crawler), base de données, messagerie, …
• parser les données à indexer afin d’en extraire le texte, diverses propriétés (titre, auteur, date de publication, … ) et pour un site web les liens vers d’autres pages
• supporter différents jeux de caractères et différentes langues (et éventuellement être capable de détecter la langue du document)
• créer l’index proprement dit qui est la plus part du temps constitué d’un ensemble de fichiers et de structures de données de type B-trees.
• paramétrer la solution au moyen de listes de mots vides, de dictionnaire de synonymes, de thésaurus, …
• Mettre en place la sécurité : authentification et droits d’accès
• administrer la solution au moyen d’outils de manipulation des index (création, suppression, optimisation, sauvegarde, réindexation, …)
• créer une interface de recherche Web ou embarquée dans une application non Web
• mettre en place des fonctionnalités facilitant l’accès à la bonne information : alertes, filtres, entités nommées

Lors de l’apparition des premières solutions commerciales à la fin des années 80 (avec BRS/Search ou Lotus magellan par exemple), les moteurs de recherche permettent d’indexer uniquement des fichiers de format simple (texte) localisés dans un système de fichiers. Avec le temps, ils ont appris à accéder à des sources d’informations variées, à traiter un très grand nombre de formats de fichiers, à tenir compte des droits d’accès aux données et bien d’autres choses encore.

Les moteurs de recherches sont très connus au travers des solutions WEB telles que Google ou Yahoo mais ils sont également présents dans des outils d’entreprise (Gestion de contenu, CRM, Gestion documentaire, Outils de veille) et des outils grands publics tel que la messagerie ou le « Desktop search » (Google Desktop, Copernic, …).

Fonctionnement d’un moteur de recherche

L’index

La brique de base d’un moteur de recherche c’est l’index. Il s’agit d’une structure de données organisée afin de permettre au moteur de retrouver très rapidement les documents correspondants a une requête de l’utilisateur. Il s’agit dans la plupart des cas d’un ensemble de fichiers. Ces fichiers ont pour rôle de mémoriser l’emplacement de TOUS LES MOTS présents dans l’ensemble des données indexées (soit plusieurs milliers à plusieurs millions d’occurrences de mots). Un index ne contient pas une entrée par document avec la liste des mots du document, mais il contient une entrée par mot avec la liste des documents ou se trouve ce mot ET pour chaque occurrence d’un mot, sa position exacte dans les documents.

Imaginons par exemple un tous petit corpus de 4 documents contenant seulement une phrase chacun.

On constate que certains mots sont présents plusieurs fois. En considérant les mots « l », « que », « je », « est », « bien », « suis », « sur », « mon », « m », « a » et « de » comme vides, et en utilisant la notation « identifiant document / position » pour décrire les positions des mots, ceci donnerait dans l’index :

On constate tout d’abord que l’utilisation de mots vides permet de réduire considérablement la taille d’un index et donc d’optimiser les temps d’indexation puis de recherche. On comprend également que lorsque le nombre de documents va augmenter, le nombre de mots nouveaux va avoir tendance à se stabiliser car les mots des documents ajoutés seront souvent déjà présents dans l’index. La taille de l’index va croître moins vite car pour les mots déjà présents dans l’index, seules la référence des documents et la position des mots sont à ajouter au fichier d’index.

Dans un index, les mots ne sont pas classés alphabétiquement comme dans mon exemple, mais placés dans une structure de données de type B-Tree. Ajouter, trouver et supprimer un élément dans une telle structure est infiniment plus rapide que dans une liste ordonnée.

Un moteur de recherche peut gérer simultanément plusieurs index (pour des données distinctes d’une même application, pour des applications différentes d’une même société, pour séparer des données dans des langues différentes, …).

Les requêtes

Fort de cet index, le moteur de recherche est à même de répondre aux requêtes des utilisateurs. Il existe deux types de requête : les requêtes booléennes et les requêtes en « langage naturel ».

Les requêtes booléennes ont toujours existé dans les moteurs de recherche. Elles permettent de décrire les documents désirés au moyen d’opérateurs tels que : ET, OU, SAUF, PROCHE, PHRASE EXACTE, TRONCATURE, …

Voici quelques exemples de requêtes et de résultats basés sur notre index

Ce type de requête utilise uniquement des éléments statistiques fournis par l’index : présence, position et occurrences des mots. Le gros inconvénient de ce type de requête est la nécessitée pour l’utilisateur de connaître la syntaxe booléenne propre à l’outil utilisé ou pour les concepteurs de fournir des écrans de recherche complexes guidant l’utilisateur (comme par exemple la recherche avancée de Google)

Les requêtes en langage naturel sont apparues plus tard. Le premier but est de permettre à l’utilisateur d’interroger le système à l’aide d’expressions ou de phrases plus ou moins précises mais surtout de ne pas être obliger l’utilisateur à connaître une syntaxe booléenne complexe et rébarbative.

Par exemple, l’utilisateur qui s’intéresse à la dégustation des avocats saisit la requête « Comment déguster un avocat ? ». Bien que « comment » et « déguster » ne soient présents dans aucun document, le moteur va sans doute trouver des résultats. En effet, les moteurs retirent les mots vides de la question et aussi les mots ou expressions typiques d’une question : « comment », « pourquoi », « je cherche … ». Exit donc le mot « comment ». Ensuite, si aucun document ne correspond exactement, le moteur doit fournir les documents les plus proches possible de la requête et doit utiliser tous les mots de la requête pour orienter le résultat. Dans cet exemple, « déguster » doit orienter vers un avocat qui se mange et donc retourner les documents 1 et 2. Bien sur cela impose un index plus complexe qui contienne une information complémentaire sur la nature des avocats. Ce qui donne par exemple l’index suivant :

Pour ce type de requête, le moteur utilise les éléments statistiques de l’index, mais également des informations sémantiques (sens des mots), morphologiques (forme des mots) et syntaxique (mots composés et expressions) après analyse du texte indexé et de la requête.

Pertinence des résultats

Une fois obtenue la liste des documents correspondants à une requête, ce que l’on demande à un moteur est de nous fournir les résultats classés par « pertinence ». Il s’agit de retourner en premier les documents qui répondent le mieux à la requête et là encore, le moteur s’appuie sur son index pour calculer la pertinence. Selon les moteurs, il existe plusieurs algorithmes de calcul de pertinence. Par exemple, l’algorithme qui privilégie les documents qui contiennent le plus de mots de la requête. Dans ce cas, pour la requête « avocat OU pourri », le moteur va retourner le document 2 en premier.

Deux autres indicateurs majeurs de pertinence sont la proximité et le bon ordonnacement des mots de la requête dans le document.

Les algorithmes peuvent être très variés. Par exemple, le très célèbre « Page Rank » de Google n’est pas basé que sur la fréquence d’apparition des mots recherchés au sein des documents trouvés, mais grandement sur la popularité du site hébergeant le document en tenant compte du nombre des autres sites pointant sur lui.

Certains moteurs savent également, par des algorithmes d’analyse grammaticale dépendants de la langue, déterminer si l’expression recherchée (dégustation d’avocat, par exemple) est un sujet central dans le document ou bien traitée en aparté. Dans le premier cas, le document sera considéré comme plus pertinent.

Les propriété associées aux documents (metadonnées)

Aux documents indexés sont généralement associées un minimum de métadonnées : titre, auteur, mots-clés, date de publication, …. Ces métadonnées sont gérées dans une application métier (messagerie, CRM) et saisies par des utilisateurs. Une partie d’entre elles sont indexées par le moteur et donc elles peuvent être utilisées comme critère de recherche ou de tri des résultats (par exemple, pour rechercher tous les documents sur les avocats et publiés après une certaine date) et affichées dans la liste de résultats.

Il existe par exemple un schéma de metadonnées normalisé (ISO 15836) appelé Dublin Core. Le Dublin Core permet de décrire des ressources numériques ou physiques et d’établir des relations avec d’autres ressources. Il comprend officiellement 15 éléments de description formels (titre, créateur, éditeur), intellectuels (sujet, description, langue, …) et relatifs à la propriété intellectuelle.

Faut-il choisir un moteur « statistique » ou « sémantique » ?

Comme cela a été dit précédemment, tous les moteurs sont statistiques à la base. La question doit donc être « Faut-il choisir un moteur avec des fonctionnalités sémantiques ? ». Plusieurs paramètres sont à prendre en considération afin de répondre à cette question.

Quelle est la nature des données (spécifique à un métier, généraliste) ?

Les moteurs sémantiques mettent en oeuvre des algorithmes d’analyse du texte qui nécessitent des dictionnaires. Le rôle de ces dictionnaires est de fournir des informations sur les mots : nature (nom, adjectif), synonymes, …. Si le ou les domaines couverts par les documents indexés sont multiples, vastes et évolutifs, ces dictionnaires seront plus longs (donc coûteux) à élaborer et à maintenir.

Les moteurs sémantiques sont donc plus adaptés à des moteurs spécialisés qu’à des moteurs généralistes. Il est toutefois possible de mettre en oeuvre une « couche sémantique » généraliste et légères qui ne demande pas trop de maintenance des dictionnaires. Mais, avec une couche sémantique légère, il ne faudra pas attendre de miracles avec des applications métiers (domaine médical, scientifique ou financier par exemple).

Quel est le volume des données ?

Sans doute pas le paramètre le plus important, mais il faut savoir que les étapes d’analyse sémantique des documents en phase d’indexation entraînent des temps de traitement plus long. C’est à prendre en compte donc si les temps d’indexation sont critiques et/ou les documents très nombreux.

Quel type de population va utiliser le moteur de recherche ?

Il faut savoir que les moteurs généralistes traitent 80% de requêtes constituées d’un seul mot. Contrairement à la requête « Comment déguster un avocat ? », la requête « avocat » ne fournira pas d’information sur la nature de l’avocat recherché. Ces requêtes sont par défaut de type booléen et la couche sémantique du moteur n’est dans ce cas d’aucune utilité.

Sur des sites spécialisés utilisés par des spécialistes, les requêtes seront globalement plus précises et là, la couche sémantique donnera sa pleine puissance.

Quel investissement matériel, logiciel et humain peut être alloué au projet ?

Bien sur, il faut tenir compte des coups de licences et de matériels imposés par la solution évaluée, mais il faut surtout bien évaluer les ressources humaines nécessaires à la mise en oeuvre de la solution. Un moteur sémantique nécessite souvent un travail important en amont du projet pour constituer ou enrichir les dictionnaires. En phase d’exploitation, il est aussi nécessaire de bien suivre l’utilisation faite du moteur afin de déterminer les ajustements à apporter dans les dictionnaires (quelles requêtes sont posées, quelles requêtes ne remontent pas de documents et pourquoi, …).

Quel est l’impact sur l’interface utilisateur et sa complexité d’utilisation ?

Plus haut je disais qu’un moteur sémantique permet de mettre en place une interface plus simple. C’est vrai pour la zone de saisie de la requête, mais d’autres éléments peuvent venir s’ajouter à la liste de résultats :

• des navigateurs (liste d’auteurs, liste de thèmes, listes de lieux) qui vont permettre à l’utilisateur d’affiner sa requête. Les données affichées par ces navigateurs sont relatives aux documents trouvés et peuvent soit provenir des métadonnées, soit avoir fait l’objet d’une détection par le moteur dans le flux textuel des documents. Cette détection d’entités nommées est automatique (par calcul statistique) et/ou basée sur des dictionnaires.
• une liste de questions proches et suggérées par le moteur.

A prioris, ces fonctions sont des plus, mais elles complexifient l’interface.

Choix et mise en oeuvre d’une solution

La mise en place d’une solution de recherche se fait en deux temps : la recherche et la sélection d’un moteur, puis sa mise en oeuvre. La seconde phase sera bien sur plus simple, plus rapide et avec moins de surprises si la première phase a été bien menée.

Le choix d’une solution passe par l’écriture d’un cahier des charges, la rencontre des éditeurs et après une première sélection la réalisation de un ou deux prototypes pour valider les fonctionnalités critiques.

En phase de définition et de validation du prototype, une personne connaissant parfaitement le corpus de données et le métier doit être impliquée. De même plus tard en phase d’exploitation de la solution cette personne aura pour rôle d’évaluer régulièrement le bon fonctionnement du système : documents trouvés à tort (bruit), documents non trouvés et requêtes sans réponse (silence), pertinence des réponses.

Dès la phase d’élaboration du cahier des charges, il est souhaitable de se faire assister pas des spécialistes des solutions de recherche. Cette phase a également la vertu d’être pédagogique et donc permet de mieux conduire la sélection et la mise en oeuvre future.

Quelques paramètres à prendre en compte dans le choix d’une solution :

• fonctionnalités
• langages supportés
• volumétrie acceptée
• performance en indexation et en recherche (coût de la couche sémantique)
• ergonomie de l’interface de recherche
• pertinence des résultats
• ouverture de la solution (API) et extensions possibles (connexion à une source de données spécifique)
• gestion de la sécurité et confidentialité des données
• architecture préconisée (nombre de serveurs, mémoire, processeurs, espace disque), système d’exploitation, gestion de la monté en charge et autres pre-requis (matériels et logiciels)
• administration et paramétrage du produit (charge de travail devant être en adéquation aux ressources disponibles en phase d’exploitation)
• compétences à acquérir

Sites spécialisés dans les outils de recherche

Je n’ai pas trouvé de site Français vraiment pertinent sur le sujet, je vous suggère donc uniquement Searchtools.com (anglais). Un classique, mais les fiches produits ne sont pas toujours à jour (et oui ça bouge beaucoup). Il est accompagné d’un blog actif.