Le Post Infeeny

Les articles des consultants et experts Infeeny

Relevance et Ranking in SharePoint search 2010

Session animée par Victor Poznanski

Dans cette session nous allons aborder les mystères classement et de la pertinence du moteur de recherche SharePoint.

Les challenges de la recherche : la complexité des données.

Les documents sont des éléments complexes.

Autre challenge : quelle est l’intention de l’utilisateur. Différents utilisateurs n’auront pas les mêmes intentions lorsque qu’ils effectuent une recherche.

La qualité de la recherche = la pertinence.

Victor nous présente un exemple concret du processus de recherche: si on recherche « BT network », le moteur de recherche va rechercher British Telecom (grâce au thesaurus) mais aussi network, networks, networked, networking…

Nous voyons ensuite un comparatif des éléments présents dans le moteur d’Office 365, SharePoint server et Fast (tri, best bets, preview des documens, raffinement, …) puis un guideline pour organiser la structure des informations.

Quelques astuces pour l’organisation des données :

  • Eviter les métadonnées multilingues
  • Regrouper les fichiers par langue
  • Spécifier la langue d’une phrase dans Word
  • Encourager les hiérarchies naturelles dans les url (éviter les structures à plat avec un nom de domaine différent pour chaque entité)
  • Utiliser un langage naturelle pour les metadatas (pas d’abréviations) : pour les noms de fichiers par exemple
  • Réserver des zones pour les contenus de référence : glossaire, lexique, données de niche
  • Mettre le contenu important dans SharePoint
  • Supprimer les données obsolètes

Maintenant il faut crawler pour construire l’index…

Le cycle de la qualité est le suivant : identifier le problème des requêtes, diagnostiquer le problème, essayer de fixer, déployer, identifier le problème, …

Pour identifier le problème, on écoute les retours des utilisateurs, regarde les web analitics, l’historique des best bets.

Pour diagnostiquer le problème : on regarder si le document a bien été crawlé, s’il contient bien les termes recherchés ou si le contenu n’est pas extrait.

On peut également consulter les erreurs visibles dans les logs du crawl.

Quelques bonne pratiques: ne pas hésiter à exclure des scopes les données inutiles, ne pas indexer les données de mauvaise qualité, ajouter des best bets.

Dans l’administration centrale, dans les « authoritatives sites », on peut spécifier les sites contenant des informations pertinentes et, au contraire, ceux qui contiennent des informations moins pertinentes (données de référence).

Attention, spécifier les « authoritatives sites» affecte les connexions entre les sites ayant de liens (hyperlinks) les uns vers les autres. Il peut y avoir des effets de bord. Il ne faut pas en abuser !

On répond ensuite e à quelques questions.

Comment de résoudre le problème : mes résultats ne sont pas à jour ?

  • Crawler plus souvent les zone importantes (30 minutes)
  • S’assurer que les sources de contenu ne sont pas trop larges

Comment de résoudre le problème : mon document a été crawlé mais je ne le vois pas ?

  • Utiliser le stemming
  • Utiliser le thesaurus
  • Créer des managed properties

On aborde ensuite les problématiques de langues.

Détection automatique de la langueà sélection automatique des tokenizer

On peut spécifier la langue utilisée dans la Webpart de résultats people mais aussi activer le stemming, supprimer les résultats en doublon.

Le thesaurus permet de remplacer certains termes par d’autres (galleryà jpg, gif) (teflonà tpfe)

Il faut tout de même faire attention avec le thesaurus pour ne pas dégrader la pertinence des résultats.

Nous avons droit à un exemple de thesaurus avec un fichier de configuration xml.

Il explique Comment paramétrer le thesaurus :  dans le dossier 14/data/appications/guid…

Il faut faire attention que le thesaurus soit déployé pour tous les langues.

Il explique le ranking (classement), ce qu’il y a dans le schéma par défaut et comment le ranking fonctionne.  Quelques exemple du ranking attribués aux éléments en fonction de leur localisation (titre, contenu, url, type de fichier,…) Pour résumer en quelques mots, c’est complexe !

On attaque la custo du modèle de ranking. A ne faire que si c’est vraiment nécessaire (ex : on veut intégrer une metadata dans le modèle de ranking).

On étudie en profondeur un fichier xml de paramétrage du ranking et comment spécifier les différents éléments. Le poids de chaque type d’élément par exemple (titre, url, …), le poids en fonction du type de fichier (si on veut qu’un document Excel soit moins important qu’un document Word)

Quelques écritures mathématiques et graphiques pour expliquer le ranking… pas très clair tout ça!

Dans le modèle de ranking, les managed properties sont identifiées par leur PID, il nous montre la commande Powershell pour les récupérer ainsi qu’une autre pour déployer le modèle de ranking.

Pour modifier le modèle de ranking utilisé par la Webpart de résultats de recherche, il suffit de l’exporter, modifier la propriété qui définit l’ID du modèle utilisé puis la réimporter.

Finalement, le moteur de recherche de SharePoint n’est pas si fermé en terme de paramétrage et peut être ajusté pour coller au mieux à nos besoins.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :