Améliorer la recherche sur ZdS

Bonsoir !

Vous le savez très certainement, la recherche sur ZdS n’est pas des plus efficace.

Au lieu de développer une recherche sur mesure, je me dit que l’on pourrais utiliser MeiliSearch pour notre fonction de recherche.

MeiliSearch, c’est une solution gratuite, Open Source et auto hébergée qui est plutôt efficace.

Les seules contraintes que je vois aujourd’hui, sont au nombre de deux :

• Le coût de l’hébergement. Même si la solution est gratuite, il y à le coup de l’hébergement et du stockage des données.
• L’importation des contenus actuels. Pour que la recherche puisse fonctionner, il faut intégrer les contenu dans la base de MeiliSearch. Pour les nouveaux contenus, ça ne poserais pas de problème, il suffit de les ajouter au moment de la création d’un contenu. Mais pour les anciens, je ne sais pas comment peut se faire.

Que pensez-vous de cette proposition ? Y voyez vous d’autres inconvénients ?

Je ne connais pas dans les détails l’infrastructure de ZdS, mais le classique ElasticSearch est déjà assez coûteux à mettre en œuvre et à l’hébergement de base, en général. Peut-être que MeiliSearch n’est donc pas si coûteux en se comparant avec ES.

Pour les inconvénients je ne sais pas, mais je me demande si une telle solution pourrait fonctionner avec notre système de permissions ?
Actuellement le moteur de recherche sur le site intègre la recherche dans les forums Staff / CA / corbeille selon les permissions de l’utilisateur. Comment ça pourrait être fat avec MeiliSearch ?

Bonne question. J’ai peut être un début de solution, mais je ne sais pas si c’est vraiment optimal, il faudrait voir le temps que ça met.

Mais l’idée, ce serait de faire la recherche côté back sur MeiliSearch, puis de filtrer avant de retourner les résultats.

Edit : Sachant que (à vérifier) il faut obligatoirement une clé pour lancer la recherche, donc c’est côté back obligatoirement.

Edit 2 : Alors oui, il faut une clé pour rechercher. Lors de la recherche, on peut aussi ajouter des filtres. Donc pas besoin de re-filtrer derrière, on peut le faire pendant la recherche.

C’est interessant.

Par contre je ne crois pas que le problème de la recherche sur ZdS soit un problème de technologie utilisée. On oublie peut-être avec le temps que ce qui avait été fait/codé (avec Elasticsearch) n’était qu’une première itération. La techno permet de faire beaucoup de trucs (avec l’avantage de l’integration a zds) si on prend le temps d’ajuster les choses.

Je me demande donc si changer de technologie permet de vraiment résoudre le problème (en sachant que ça signifie repartir de presque zéro).

J’irais dans le même sens que @firm1, et j’ajouterai ceci: avant de se poser la question de la techno, je pense qu’on devrait déjà ce poser la question de "qu’est ce qu’on veut?". Autrement dit, "c’est quoi une bonne fonctionnalité recherche".

Et attention, je dis pas ça pour défendre l’implémentation actuelle, tout à fait perfectible et un peu datée (c’est toujours ES5, ce qui commence à faire loin). Mais le choix doit être motivé

EDIT: je me permet d’aller plus loin. Si on regarde un peu le site de MéliSearch, on voit que les avantages mis en avant sont les suivants:

À part la fonctionnalité highlight qui semble sympa et un peu nouvelle, tout le reste est soit déjà présent (stop words et filters) soit implémentable (faceting, et synonym, ce qui, soit dit au passage, demande surtout de la configuration plus que de l’implémentation). Pour moi, l’intérêt est alors que c’est déjà implémenté et que c’est supporté

Par ailleurs, la recherche de ZdS est déjà un peu configurable ici. Or les valeurs ont été proposées au doigt mouillé par ma petite personne … Y’a peut être déjà moyen de faire quelque chose part là

Pour moi et d’expérience, la pertinence de la recherche est un problème de configuration, pas d’outil. ElasticSearch a déjà tout ce qu’il faut, mais comme tous les outils du genre c’est délicat de le régler pour avoir une recherche efficace.

Qu’il qui soit l’outil, il ne peut pas deviner explicitement quels sont les champs importants, les synonymes inhabituels, etc. Donc il faudra toujours le faire, et la pertinence de la recherche dépendra toujours de ça.

Par exemple, de ce que je vois du fichier lié par @pierre_24, je n’ai pas l’impression qu’il y ait de boost sur les titres des messages, etc. Il faudrait vérifier aussi qu’on a bien les analyses, stopwords et synonymes en français (je ne sais pas où c’est fait dans le code).

D’autre part, ElasticSearch permet le highlight.

À noter cela dit que toute la recherche de ZdS est peu ou prou à refaire, car la migration vers les dernières versions d’ElasticSearch nous impose de tout reprendre (on se basait à 100% sur une fonctionnalité d’ES qui a été supprimée). Donc, la réflexion peut se faire, si ça apporte quelque chose ou rend la recherche plus facile à maintenir par exemple.

Mais le vrai problème de notre recherche selon moi c’est surtout la façon dont on présente les résultats, et des ajustements fins ou de la configuration (comme présenté ci-dessus). Donc comme SpaceFox qui a posté en même temps que moi, je pense que c’est pas un changement d’outil qui va magiquement corriger le truc — sans dire que ce n’est pas intéressant pour d’autres raisons, cela dit .

Un comparatif assez complet et objectif de moteurs de recherche, même si fait par l’éditeur de l’un des moteurs comparé.

Si on oublie les problèmes de recherches de contenu non-public, est-ce qu’il ne serait pas plus intéressant de simplement rediriger vers DuckDuckGo¹ avec un site:zestedesavoir.com? Non seulement la qualité des résultats est quasiment garantie d’être meilleur, mais ça réduit nettement le coût d’hébergement et de maintenance de notre côté.