Project

General

Profile

Actions

Bug #13842

closed

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

Added by David Lesimple about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
Moteur de recherche
Start date:
11/07/2023
Due date:
% Done:

100%

Estimated time:
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


Related issues 1 (0 open1 closed)

Related to Silverpeas Core - Feature #13448: Paramétrer plus finement la pondération de chaque entité de contributionClosedMiguel Moquillon01/26/2023

Actions
Actions #2

Updated by Miguel Moquillon about 1 year ago

  • Status changed from New to In progress...
  • Assignee set to Miguel Moquillon
Actions #3

Updated by Miguel Moquillon about 1 year ago · Edited

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 #4

Updated by David Lesimple about 1 year ago

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 #5

Updated by Miguel Moquillon about 1 year ago

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 #6

Updated by Miguel Moquillon about 1 year ago

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

Actions #7

Updated by Miguel Moquillon about 1 year ago · Edited

  • Status changed from In progress... to Feedback
Bon ... J'ai supprimé les actualités. Puis j'ai décidé de réaliser deux tests :
  1. 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
  2. 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 #8

Updated by Miguel Moquillon about 1 year ago · Edited

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 #9

Updated by Miguel Moquillon about 1 year ago

  • Status changed from Feedback to 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 #10

Updated by Miguel Moquillon about 1 year ago · Edited

  • Status changed from In progress... to Resolved

Pour que la correction fasse effet, il est nécessaire de réindexer l'ensemble de la plate-forme.

PR https://github.com/Silverpeas/Silverpeas-Core/pull/1305

Actions #12

Updated by Yohann Chastagnier about 1 year ago

  • Status changed from Resolved to Integration in progress...
Actions #13

Updated by Yohann Chastagnier about 1 year ago

  • Status changed from Integration in progress... to Closed
  • % Done changed from 0 to 100

Validé et intégré en 6.3.x et sur les branches de développement (master et master-jackrabbit).

Actions #14

Updated by David Lesimple about 1 year ago

  • Related to Feature #13448: Paramétrer plus finement la pondération de chaque entité de contribution added
Actions

Also available in: Atom PDF