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
100%
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
Mis à jour par Miguel Moquillon il y a 6 mois
- Statut changé de New à In progress...
- Assigné à mis à Miguel Moquillon
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) !
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é.
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 !).
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 !!!!
Mis à jour par Miguel Moquillon il y a 6 mois
· Edité
- Statut changé de In progress... à Feedback
- 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 !
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).
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.
Mis à jour par Miguel Moquillon il y a 6 mois
· Edité
- Statut changé de In progress... à Resolved
Pour que la correction fasse effet, il est nécessaire de réindexer l'ensemble de la plate-forme.
Mis à jour par Yohann Chastagnier il y a 6 mois
- Statut changé de Resolved à Integration in progress...
Mis à jour par Yohann Chastagnier il y a 6 mois
- Statut changé de Integration in progress... à Closed
- % réalisé changé de 0 à 100
Validé et intégré en 6.3.x et sur les branches de développement (master et master-jackrabbit).
Mis à jour par David Lesimple il y a 5 mois
- Lié à Feature #13448: Paramétrer plus finement la pondération de chaque entité de contribution ajouté