Pertinence d'un moteur de recherche interne

[zeb]

Bonsoir,

Je bricole un moteur de recherche interne pour un site.

A l'heure qu'il est, je contrôle bien les recherches qui sont réalisées sur la base de données du site qui contient mon contenu.

Mon problème porte sur la pertinence et la façon de l'évaluer.

explication :

je fais deux groupes de requêtes sql sur la table des pages :

- le premier groupe porte sur chaque mot isolé de la chaîne de recherche.
- le second porte sur l'expression complète (groupe de mot ordonné)

ces deux groupes comprenne trois type de requête :

- une sur les keyword de la page
- une sur la description de la page (court texte descriptif du contenu)
- une sur sur le contenu textuel de la page

pour résumer en exemple, si l'utilisateur entre 'événement original' j'aurais 2x3 requêtes pour les mots isolés et 3 autres requêtes pour l'expression complète.
donc 9 résultats de recherche.

Dans mon idée, je me suis dit que les requêtes portant sur la totalité de l'expression recherchée avait plus d'importance que celles sur les mots isolés. (je leur accorde donc 50% du total des points)

Parallèlement les 2x3 requêtes liées aux mots isolés (évènement et original) se voient attribuer les 50% restant des points

pour décomposer ensuite chaque groupe de 3 requêtes (pour chaque mot isolé ou l'expression complète) j'attribue plus d'importance au résultats effectués sur les mot clefs puis sur le résumé et enfin sur le contenu textuel.

c'est cette répartition des 'points' qui me semble 'discutable'

qu'en pensez vous ?

J'espère être clair, c'est pas évident, merci d'avance pour l'usage de vos neurones.

 

[webmasterlamogere]

une recherche FULLTEXT me semble plus pertinente

 

[zeb]

FullText

MATCH (col1,col2,...) AGAINST (expr [IN BOOLEAN MODE | WITH QUERY EXPANSION])

Depuis la version 3.23.23, MySQL propose l'indexation et la recherche sur l'ensemble d'un champ TEXT (full-text). Les index en texte intégral de MySQL sont des index de type FULLTEXT. Les index FULLTEXT sont utilisés avec les tables MyISAM et peuvent être créés depuis des colonnes de types CHAR, VARCHAR, ou TEXT au moment de CREATE TABLE ou plus tard avec ALTER TABLE ou CREATE INDEX. Pour les enregistrements les plus grands, il sera plus rapide de charger les donnés dans une table qui n'a pas d'index FULLTEXT, et ensuite de créer l'index avec ALTER TABLE (ou CREATE INDEX). L'enregistrement de données dans une table qui a déjà des index FULLTEXT sera plus lent.

pas mal je connaissait pas du tout, je vais expérimenter dans ce sens.

Merci

 

[zeb]

sensible aux accents une idée pour contourner le problème ?

 

[KOogar]

Les accents se gerent tout seul. LIKE prend en compte les caracteres speciaux.

<?php   $search = 'LIKE \'%' . $mot . '%\'';   ?>

 

[passion]

Attention l'index en FULLTEXTE n'est utilisable que sur une table en MyIsam.

Si tu utilises des clés étrangères pour InnoDB marchera pas.

 

[webmasterlamogere]

sensible aux accents une idée pour contourner le problème ?

pas chez moi

 

[KOogar]

sensible aux accents une idée pour contourner le problème ?

pas chez moi

Il peut toujours utiliser une fonction qui enleve les accents avant la requete sql.

 

[zeb]

sensible aux accents une idée pour contourner le problème ?

pas chez moi

Il peut toujours utiliser une fonction qui enlève les accents avant la requête sql.

les accent sont dans la base donc pas enlevables si la recherche est faite en fulltext.

 

[zeb]

Attention l'index en FULLTEXTE n'est utilisable que sur une table en MyIsam.

Si tu utilises des clés étrangères pour InnoDB marchera pas.

Pas de problème ma base répond aux critères du fulltext

 

[raljx]

dans le cadre d'une recherche FULLTEXT tu peux aussi parametrer ta variable mysql --> min_word_len à 1 ou à 2 pour plus de pertinence sur les requtes a mots courts ...

 

[zeb]

Les accents se gerent tout seul. LIKE prend en compte les caracteres speciaux.

<?php   $search = 'LIKE \'%' . $mot . '%\'';   ?>

LIKE ne fonctionne pas comme voulu chez moi (je pense que je merde avec) mais bon c'est l'option fulltext que j'ai travaillé et tant pis pour les accents pour le moment (j'aime pas bloquer trop longtemps sur un problème, j'y reviendrais)

 

[zeb]

dans le cadre d'une recherche FULLTEXT tu peux aussi parametrer ta variable mysql --> min_word_len à 1 ou à 2 pour plus de pertinence sur les requtes a mots courts ...

J'ai vue ça mais pas acces au parametrage du serveur SQL donc ça ne me semble pas possible.

En revanche je ne sais pas si c'est une bonne idée dans la mesure ou les resultats sont innodés avec les : de du la le etc ...

 

[zeb]

Bonsoir,

Je bricole un moteur de recherche interne pour un site.

A l'heure qu'il est, je contrôle bien les recherches qui sont réalisées sur la base de données du site qui contient mon contenu.

Mon problème porte sur la pertinence et la façon de l'évaluer.

En fait FullText gère super bien mon problème car c'est le serveur SQL qui prend en charge tous le travail que je faisais en PHP.

Je n'ai qu'une requête a passer pour avoir mes résultats ce qui pouvait m'en prendre beaucoup plus auparavant (mais je gérais les accent a ce moment)

A voir, si en charge, avec une base beaucoup plus volumineuse, le système se comporte toujours aussi bien ...

 

[Leonick]

j'avais testé un moment, mais je ne trouvais pas la pondération des résultats correcte.

 

[raljx]

alors concernant la charge mysql sur de nombreuses requetes :

une recherche FULLTEXT avec par default un min_word_len = 3 ne me pose pas de probleme de charge ( + 100 000 V/jour) par contre dès que je passe à 2 ou 1 c'est la cata au niveau de la charge ... les autres requetes attendent des fois plus de 5 secondes avant d'etre traitées et donc on arrive vite à un "gros bouchon" voire à des "locked" ... a evité donc j'ai reduit à 3 mais je perd en pertinence surtout sur des mots comme K7 ou BD

 

[zeb]

alors concernant la charge mysql sur de nombreuses requetes :

une recherche FULLTEXT avec par default un min_word_len = 3 ne me pose pas de probleme de charge ( + 100 000 V/jour) par contre dès que je passe à 2 ou 1 c'est la cata au niveau de la charge ... les autres requetes attendent des fois plus de 5 secondes avant d'etre traitées et donc on arrive vite à un "gros bouchon" voire à des "locked" ... a evité donc j'ai reduit à 3 mais je perd en pertinence surtout sur des mots comme K7 ou BD

Mon min_word_len est de 3, le site est en phase de conception je pense pas qu'il dépassera les 1000 VU/jour avant 12 mois a partir de maintenant, j'ai donc de la marge pour me triturer las neurones.

En tous cas merci pour ces infos ;-)

Le thème (histoire architecture et patrimoine) me préserve un peut aussi des recherches courtes ou du SMS

 

[Leonick]

Le thème (histoire architecture et patrimoine) me préserve un peut aussi des recherches courtes ou du SMS

quoique pour un devoir d'histoire de jeun's "cé kan ka été construi le chato deversaille" :lol:

 

[KOogar]

oki tu es parti sur fulltext ^^

pour les accent, ca doit etre un probleme de jeu de caractere:

ajoute CONVERT dans ta requete

SELECT CONVERT( _utf8 '$texte_recherche' USING latin1 ) FROM table WHERE...;

 

[zeb]

oki tu es parti sur fulltext ^^

pour les accent, ca doit etre un probleme de jeu de caractere:

ajoute CONVERT dans ta requete

SELECT CONVERT( _utf8 '$texte_recherche' USING latin1 ) FROM table WHERE...;

Mes pages (doctype), la base de données et ma bécane de dev sont tous sur le même jeux de caractère (j'ai galèré lors de l'instal de la dernière mandriva a cause de cela) mais je vais essayer quand même demain si j'ai le temps ou plus tard du coup.

merci en tous cas pour l'idée.

 

[zeb]

Le thème (histoire architecture et patrimoine) me préserve un peut aussi des recherches courtes ou du SMS

quoique pour un devoir d'histoire de jeun's "cé kan ka été construi le chato deversaille" :lol:

Pas de prob en cas de recherche infructueuse je renvoie un message du type :

Tapuka cher ché ayeur

le résultat provisoire visible ici Forteresse de Chatel sur Moselle (si vous avez des idées, conseils ou commentaire n'hésitez pas)