Bug #13842: L'ordre des publications dans les résultats de recherche ne respecte pas forcément le nombre d'occurrences des termes recherchés - Silverpeas Core - Silverpeas Issues Tracker

Rapports personnalisés

Almanach
Blog
Chat
Forums
Gallery
Hyperlink
Infoletter
Kmelia
Silverpeas-Core

Actions

Copier le lien

Bug #13842

fermé

L'ordre des publications dans les résultats de recherche ne respecte pas forcément le nombre d'occurrences des termes recherchés

Ajouté par David Lesimple il y a 6 mois. Mis à jour il y a 6 mois.

Statut:

Closed

Priorité:

Normal

Assigné à:

Miguel Moquillon

Catégorie:

Moteur de recherche

Version cible:

Silverpeas - Version 6.3.2

Début:

07/11/2023

Echéance:

% réalisé:

100%

Temps estimé:

Navigateur:

Tous

Votre version de Silverpeas:

6.3.1

Système d'exploitation:

Votre base de données:

Toutes

Livraison en TEST:

Livraison en PROD:

Description

Pour reproduire le problème avec cet exemple :

- créer une actualité A avec :
2 fois l'expression mois sans tabac dans l'entête (titre et description)
2 fois l'expression mois sans tabac dans le contenu wysiwyg

- créer une actualité B avec :
2 fois l'expression mois sans tabac dans l'entête (titre et description)
plus de 3 fois l'expression mois sans tabac dans le contenu wysiwyg (5 par exemple)

Résultat observé : l'actualité A remonte avant l'actualité B dans les résultats de recherche,
qu'on recherche avec "mois sans tabac" ou avec mois sans tabac

Résultat attendu : l'actualité B devrait remonter avant l'actualité A car son score de pertinence est supposé être plus élevé que celui de l'actualité A

Demandes liées 1 (0 ouverte — 1 fermée)

Lié à Silverpeas Core - Feature #13448: Paramétrer plus finement la pondération de chaque entité de contribution

Closed

Miguel Moquillon

26/01/2023

Actions

Demande # Retard: jours Annuler

Historique
Notes
Changements

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois

Statut changé de New à In progress...
Assigné à mis à Miguel Moquillon

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois · Edité

Après investigations, les résultats de la recherche retournés par Lucene sont bien triés par score. Et ici c'est l'actualité A qui a le plus haut score (dans mon cas score ~ 22) comparé à l'actualité 2 (dans mon cas score ~ 20) !

Actions

Copier le lien

Mis à jour par David Lesimple il y a 6 mois

Miguel Moquillon a écrit (#note-3):

Après investigations, les résultats de la recherche retournés par Lucene sont bien triés par score. Et ici c'est l'actualité A qui a le plus haut score (dans mon cas score ~ 22) comparé à l'actualité 2 (dans mon cas score ~ 20) !

Il y a bien un problème sur le calcul du score, puisque l'actualité B devrait avoir ici un score plus élevé.

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois

Je ne comprend décidément pas ce qui se passe. Dans le cas d'une publication dans une GED, les résultats d'une recherche retournée par Lucene ont leur score correctement évalué. Mais pas avec une actualité. Et pourtant on passe par le même processus d'indexation (et dont celui du contenu WYSISWYG qui a bien lieu) et par le même mécanisme de recherche. La seule différence notable est que dans Kmelia, il y un champs supplémentaire pour référencer le dossier (stored,indexed,omitNorms,indexOptions=DOCS<path:/0/>) et l'indexation d'une publication est réalisée deux fois (l'une après l'autre !).

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois

En fait, dans une actualité, moins le contenu WYSIWYG contient les termes recherchés, mieux il est évalué dans la recherche !!!!

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois · Edité

Statut changé de In progress... à Feedback

Bon ... J'ai supprimé les actualités. Puis j'ai décidé de réaliser deux tests :

un premier test dans lequel seuls la phrase Mois sans Tabac est écrite telle quel tout en suivant les étapes du descriptif de ce billet
un second test dans lequel c'est un texte qui est écrit, comprenant la phrase "mois sans tabac", aussi bien en entête, dans la description, que dans le texte WYSIWYG des actualité tout en respectant les conditions stipulées dans le descriptif de ce billet.

Il s'avère que cette fois ... ben ça marche !!!! Les billets qui comprennent le plus les termes recherchés sont bien ordonnés correctement.
Les arcanes de Lucene sont décidément bien opaques !

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois · Edité

J'ai réalisé d'autres tests. Cette fois-ci le résultat est plutôt pas aussi satisfaisant mais me permet de mettre en lumière, je pense, le scoring.
En sus des actualités du dernier test (que j'ai gardé cette fois-ci), j'ai créé deux autres actualités selon le test 1. Et il s'avère que ce sont ces deux dernières actualités qui sont remontées en premier alors que ce devrait être le dernier article du précédent test.

Le scoring ne compte pas le nombre de termes recherchées qui sont compris dans les documents indexés. Mais leur fréquence, ou dit plus explicitement, le poids de ceux-ci relatif à la taille du document. Ainsi, un document qui comprend exactement que les termes recherchés (ici mois sans tabac aura plus de poids qu'un document qui comprend un texte avec plusieurs fois les termes recherchés Mois sans tabac jusqu'à à une certaine fréquence (c'est à dire le nombre d'occurrence / à la taille du texte).

Actions

Copier le lien

Mis à jour par Miguel Moquillon il y a 6 mois

Statut changé de Feedback à In progress...

Après investigation, il s'avère que la description d'une publication (et donc d'une actualité) a un poids assez important dans le calcul du score du document remonté par la recherche. Ainsi, si une actualité A a un contenu avec une fréquence bien plus élevée des termes recherchés comparé à une autre actualité B, on s'attend à ce que celle-ci remonte en tête des résultats de la recherche. Or, si A a dans sa description une seule occurrence des termes recherchés noyés dans plusieurs phrases, et B a dans sa description une seule occurrence des termes recherchés dans une seule phrase courte, ce sera B qui sera remonté parmis les premiers résultats de la recherche.

Et ceci même en retirant le facteur de boost dans le calcul du score appliqué sur le texte du champs d'indexation HEADER dédié à la recherche.

Actuellement le champs HEADER est valorisé avec l'intitulé de la publication, sa description et les mots-clés. Or, contrairement au titre et aux mots-clés, la description peut comprendre plusieurs phrases et par conséquent le poids de celle-ci dans le champs HEADER sera plus conséquent. Ce qui influera ainsi plus fortement le calcul du score d'une publication, et ceci d'autant plus que le facteur de boost y est appliqué.

Afin de résoudre le soucis soulevé par ce ticket, il a été choisi de retirer du champs HEADER la description. D'autant plus que celle-ci relève plus du contenu que d'un entête de contribution. D'ailleurs le champs d'indexation CONTENT est déjà valorisé, entre autre, avec la description.

Actions

Copier le lien

#10