[SPIP Zone] Recherche sur contrib

Archives Zone
1

Pouet,

ça fait plusieurs fois que je me fais la remarque : la recherche sur contrib est trop stricte.
Par exemple, je cherchais le plugin Métas + dont parlait Izo, je cherche "méta" -> nada.
Il faut utiliser "métas" ou "méta*"

Avec ou sans accent, ok, mais je pense que les recherches seraient beaucoup plus intuitives si le mode de recherche avec l'astérisque finale * était le mode standard.

Avec en plus un surlignage des termes quand on ouvre la page cible, pour bien les identifier.

Qu'en pensez vous ?

--
nicod_

2

Oui.

:slight_smile:

--
RastaPopoulos

3

Le 11/06/2017 à 15:55, RastaPopoulos a écrit :

Oui.

:slight_smile:

En fait c'est une spécificité de Fulltext, donc c'est de ce côté qu'il faudrait prévoir un mécanisme qui permette de débrayer (constante ou config).
Je regarde ça.

--
nicod_

4

Le 11/06/2017 à 16:31, nicod_ a écrit :

Le 11/06/2017 à 15:55, RastaPopoulos a écrit :

Oui.

:slight_smile:

En fait c'est une spécificité de Fulltext, donc c'est de ce côté qu'il faudrait prévoir un mécanisme qui permette de débrayer (constante ou config).

Je propose ce patch, qui ajout une étoile sur tous les termes qui n'en contiennent pas déjà une, ni de parenthèses :
http://spip.pastebin.fr/50184

Avec un define('_FULLTEXT_ASTERISQUE_PARTOUT', true) dans les options du squelette, chez moi ça marche.

--
nicod_

5

Bon, c'est fait pour la recherche moins stricte :
http://zone.spip.org/trac/spip-zone/changeset/104831
http://zone.spip.org/trac/spip-zone/changeset/104832

Si c'est ok, il faudrait mettre à jour Fulltext et le squelette sur contrib.spip.net (ping Cerdic ou Benny_b ou b_b)

Pour le surlignage dans les pages ouvertes depuis la page de résultat, j'ai testé avec ça :

define('_SURLIGNE_RECHERCHE_REFERERS',true);
if (isset($_REQUEST['recherche'])) {
  $_GET['var_recherche'] = $_REQUEST['recherche'];
}

mais il faut aussi passer la valeur de #RECHERCHE en GET dans l'url ouverte depuis recherche.html, non ?

--
nicod_

6

nicod_ a écrit le 11/06/2017 à 18:29 :

Bon, c'est fait pour la recherche moins stricte :
Connexion · GitLab
Connexion · GitLab

Si c'est ok, il faudrait mettre à jour Fulltext et le squelette sur contrib.spip.net (ping Cerdic ou Benny_b ou b_b)

Pour le surlignage dans les pages ouvertes depuis la page de résultat, j'ai testé avec ça :

define('_SURLIGNE_RECHERCHE_REFERERS',true);
if (isset($_REQUEST['recherche'])) {
     $_GET['var_recherche'] = $_REQUEST['recherche'];
}

mais il faut aussi passer la valeur de #RECHERCHE en GET dans l'url ouverte depuis recherche.html, non ?

Non.
En principe, ça doit utiliser le HTTP_REFERER (cf PHP: $_SERVER - Manual)
Si ça ne marche plus dans SPIP, c'est un bug :wink:

--
RealET

7

Le 11/06/2017 à 18:35, RealET a écrit :

En principe, ça doit utiliser le HTTP_REFERER (cf PHP: $_SERVER - Manual)
Si ça ne marche plus dans SPIP, c'est un bug :wink:

Un bug dans SPIP ? calomnie ! :stuck_out_tongue:

--
nicod_

8

Pour info j'avais fait un filtre pour un peu le même problème

il s'utilise avec un
{recherche #ENV{recherche}|fulltext_recherche_naturelle_fr}

Parce que le coup de l'asterisque ça suffit pas, rapidement tu te rends compte que tu as le problème inverse : quand tu mets le mot au pluriel il te ramène pas le singulier etc…

--
Cédric

nicod_ a écrit :

Le 11/06/2017 à 16:31, nicod_ a écrit :

Le 11/06/2017 à 15:55, RastaPopoulos a écrit :

Oui.

:slight_smile:

En fait c'est une spécificité de Fulltext, donc c'est de ce côté qu'il
faudrait prévoir un mécanisme qui permette de débrayer (constante ou
config).

Je propose ce patch, qui ajout une étoile sur tous les termes qui n'en
contiennent pas déjà une, ni de parenthèses :
http://spip.pastebin.fr/50184

Avec un define('_FULLTEXT_ASTERISQUE_PARTOUT', true) dans les options du
squelette, chez moi ça marche.

9

Le 12/06/2017 à 09:42, Cédric Morin a écrit :

Pour info j'avais fait un filtre pour un peu le même problème
Connexion · GitLab

il s'utilise avec un
{recherche #ENV{recherche}|fulltext_recherche_naturelle_fr}

Parce que le coup de l'asterisque ça suffit pas, rapidement tu te rends compte que tu as le problème inverse : quand tu mets le mot au pluriel il te ramène pas le singulier etc…

Bon, j'avais laissé ça de côté mais je viens de tester sur un site avec du contenu, et j'obtiens en fait moins de résultat avec une étoile que sans, ce qui est contre intuitif.

lycée -> 77 articles
lycées -> 77 articles
lycée* -> 51 articles
lycé* -> 51 articles
lyc* -> 51 articles

action -> 60 articles
actions -> 36 articles
action* -> 26 articles
actio* -> 26 articles

En cherchant les raisons, je tombe sur cette réponse sur Stackexchange, très intéressante :

Je teste donc sans Fulltext (avec donc une recherche en LIKE), et je trouve beaucoup plus de résultats :

lycée -> 208 articles
lycées -> 77 articles

action -> 226 articles
actions -> 139 articles

(à faire : tester avec LOCATE)

La doc de Fulltext indique :

Pertinence
Les résultats sont beaucoup plus pertinents, puisque si on tape deux mots (ou plus), le moteur FULLTEXT va trouver comme avant l’ensemble des articles contenant ces deux mots, mais attribuera un score plus important à ceux qui disposent de ces deux mots consécutifs. Ce score est comptabilisé par la balise #POINTS.

Je ne cherche pas des mots consécutifs, et il ne me semble pas que ce soit une façon de chercher naturelle : on tape plutôt un ou deux mots sur des thématiques.

Je teste donc avec deux mots :

action lycée, avec Fulltext -> 73 articles
action lycée, sans Fulltext -> 372 articles

On a donc là aussi plus de résultats sans Fulltext.

Par contre, le temps de calcul est beaucoup plus long.
Avec 1 mot : 1.5 secondes sans Fulltext au lieu de 0.7 secondes avec
Avec 2 mots : 3 secondes contre 0.9
(chaque test fait en var_mode=recalcul)

Ps : les index fulltext sont bien en place sur la table spip_articles
   FULLTEXT KEY `titre` (`titre`),
   FULLTEXT KEY `tout` (`surtitre`,`titre`,`soustitre`,`chapo`,`texte`,`ps`,`nom_site`,`url_site`,`descriptif`)

--
nicod_

10

Salut nicod_ :

11

Le 13/06/2017 à 20:05, nicod_ a écrit :

Je teste donc avec deux mots :
action lycée, avec Fulltext -> 73 articles
action lycée, sans Fulltext -> 372 articles
On a donc là aussi plus de résultats sans Fulltext.
Par contre, le temps de calcul est beaucoup plus long.
Avec 1 mot : 1.5 secondes sans Fulltext au lieu de 0.7 secondes avec
Avec 2 mots : 3 secondes contre 0.9
(chaque test fait en var_mode=recalcul)

Quand il y a 2 mots ou plus et sans fulltext, spip prétraite la requête
pour faire une requête qui combine toutes les recherches possibles :
- chaque mot seul
- tous les mots ensemble
(ce qui est pénalisant et inutile cf perf mysql : ne pas surcharger les recherches (#3916) · Tickets · spip / spip · GitLab)

JL

12

Le 13/06/2017 à 20:16, Gildas Cotomale a écrit :

il faut vraiment en avoir besoin (genre base de données documentaire) pour que ce soit pertinent (eh non ce n'est pas une solution miracle mais une solution à un besoin)

Ah ben il faut revoir l'argumentaire marketing alors, parce que c'est pas comme ça que c'est vendu :

Ce plugin permet d’une part d’exploiter le mode de recherche FULLTEXT de MySQL en améliorant ainsi énormément les recherches par rapport au fonctionnement natif (et naïf) de SPIP,

Remboursez !

--
nicod_

13

nicod_ a écrit :

Ce plugin permet d’une part d’exploiter le mode de recherche FULLTEXT
de MySQL en améliorant ainsi énormément les recherches par rapport au
fonctionnement natif (et naïf) de SPIP,

Remboursez !

Mais pourquoi "Remboursez" ?
La qualité d'un moteur ne se mesure pas au nombre de résultats de recherche (c'est pas celui qui en trouve le plus qui est le mieux), mais à la pertinence de ce qui remonte, non ?

Je pense que le fait que fulltext prenne les débuts de mot est plutot mieux que le LIKE mysql qui prend tout ce qui ressemble, sans notion de mot.
Après sur la gestion du * dans fulltext il faut faire attention, en particulier sur les mots courts qui peuvent être stopwords. C'est pour ça que j'avais fait un filtre qui ajoutait le * en prenant des précautions.

Globalement fulltext améliore les choses par rapport au natif naïf, mais ça reste assez basique par rapport à ce que fait un vrai moteur de recherche, en effet.

--
Cédric

14

Le 14/06/2017 à 14:47, Cédric Morin a écrit :

Remboursez !

Mais pourquoi "Remboursez" ?

Désolé, j'ai oublié le smiley :slight_smile:
(humour par rapport à l'argumentaire, toussa...)

La qualité d'un moteur ne se mesure pas au nombre de résultats de recherche (c'est pas celui qui en trouve le plus qui est le mieux), mais à la pertinence de ce qui remonte, non ?

Je pense que le fait que fulltext prenne les débuts de mot est plutot mieux que le LIKE mysql qui prend tout ce qui ressemble, sans notion de mot.

Tout à fait, j'en suis arrivé à la même conclusion en testant mieux.

D'autant que Fulltext a une fonctionnalité très utile, la possibilité de définir des clauses supplémentaires dans le where, avec les constantes _FULLTEXT_WHERE_*
Pour exclure en fonction de dates, de rubriques, etc...

Et qu'il est beaucoup plus rapide.

Après sur la gestion du * dans fulltext il faut faire attention, en particulier sur les mots courts qui peuvent être stopwords. C'est pour ça que j'avais fait un filtre qui ajoutait le * en prenant des précautions.

Oui mais ça reste quand même étonnant que lycée remonte plus de résultats que lycée*, on s'attendrait intuitivement à l'inverse.

--
nicod_