gérer les caractères accentués lors de la recherche de catégories #1888

image

image

@pmiossec c'est toi qui connait le mieux cet algorithme, pourras tu regarder plus largement si les catégories définies avec des accents sont bien trouvées quand on ne met pas les accents ?

En attendant pour ce cas précis, j'ajoute karton dans le dictionnaire.

un autre exemple, plus problématique

idem avec la nouvelle catégorie papèterie : l'accent est obligatoire pour la trouver...

L'option ignoreDiacritics devrait gérer ça dans Fusejs. https://www.fusejs.io/api/options.html#ignorediacritics

https://codeberg.org/cartes/web/src/branch/master/app/QuickFeatureSearch.tsx#L80

Donc ce serait un bug à investiguer ?

je me suis encore fait avoir hier en cherchant des vêtements.

qui veut bien regarder ? @laem ? @pmiossec ? @severo ?

je regarde

de ce que je peux tester, le souci c'est le seuil sur le score rendu par fuse qui est trop strict.

Quand on a une correspondance exacte, on a score=0 (ou 0.000000000001). Mais si on met "vetements" ou "vêtements" (même résultat, grâce à ignoreDiacritics qui marche comme prévu), la catégorie "vêtements et chaussures" a un score de 0.018, qui est supérieur au seuil de 0.0001. Donc : écarté.

MAIS

ce n'est pas la seule manière de trouver une correspondance, il y a trois tests en parallèle. Les deux autres sont des regex sur le nom de la catégorie et sur les termes reliés (dictionary), pour chercher une correspondance exacte. Et donc, pour "vêtements", on trouve une correspondance exacte avec "vêtements et chaussures".

Donc... à mon avis, remonter le seuil, genre à 0.05, ça a l'air de bien marcher. Pas sur qu'on ait besoin des autres tests (regex) pour être honnête (je n'ai pas vu d'exemples où ça serait le critère qui inclut un résultat dans la liste).

j'ai créé #2190. Je vous laisse vérifier et merger si ça vous va.

On avait changé le seuil parce qu'on avait le pb inverse : trop de hits.
Faudrait retrouver la PR de @pmiossec je crois me souvenir qu'il avait galéré à trouver un bon compromis, ça doit être tracé dans la pr ou le ticket correspondant.

@etienneJr wrote in #1888 (comment):

qu'il avait galéré à trouver un bon compromis,

Oui, effectivement mais je garantie pas que c'était le bon et cet exemple montre qu'il faut ajuster la valeur.

Par contre, je suis contre de retirer la regex car c'est un backup au cas où.

Mais je me demande si il ne faudrait pas traiter les accents d'une façon particulière par augmenter le score de matching et donc pouvoir réduire la valeur limite...

Tant qu'on est là dessus, y'a un autre bug qui m'embête : le fait que la catégorie "vélo en libre service" sorte super souvent. C'est un pb de regexp ?

@etienneJr wrote in #1888 (comment):

Tant qu'on est là dessus, y'a un autre bug qui m'embête : le fait que la catégorie "vélo en libre service" sorte super souvent. C'est un pb de regexp ?

Non, c'est quand j'ai fait la catégorie, j'ai pas voulu faire de discrimination et j'ai mis les noms de tous les vélo en libre service de France et du coup, ça match un peu trop souvent.

Le truc, c'est que je ne sais pas trop quoi enlever car je trouve beaucoup plus pratique de taper 'velib' par exemple et que ça doit être sensiblement pareil pour les autres....

Oui c'est un sujet complexe. On touche au coeur de ce qui fait que Google est apprécié, une recherche perfectionnée.

Idéalement, il faudrait qu'on écrive un jeu de tests. Car changer le paramètre a des conséquences sur d'autres requêtes. Il se peut aussi que Fuse ne soit pas le meilleur moteur...

Au sujet de "vetement" : remarquons que c'est le s en moins qui casse la recherche ici.

Fuse n'a pas l'intelligence d'un moteur de recherche qui enlèverait le s dans les chaines de caractères à comparer.

Ce que je pige pas, c'est que "vêtement" déclenche bien le résultat. Donc c'est le combo accent et pas de s qui casse. Or ignoreDiacritics devrait marcher... Y a une couille dans le pâté...

Trois choses à considérer :

• fuse a été MAJ en version 7.3 récemment, avec plein de nouveautés, on est sur la 7.1
• la 7.4 est en beta, elle devrait pas améliorer les résultats de recherche, mais sa fonctionnalité web workers devrait nous permettre d'ajouter plus d'éléments (dicos) sans ralentir la recherche
• j'avais déjà fait un ticket sur les embeddings, très prometteurs. Il se trouve que Fuse a écrit un petit article sur ça !

Clairement pour notre problème, les embeddings pourraient être utiles. Ils rempliraient de base ce qu'on essaie de reproduire avec nos dictionnaires. Un hybride serait sûrement la meilleure solution.

Et gardons en tête la possibilité d'avoir une LLM qui va encore plus loin en créant la requête overpass si aucune n'est trouvée.

Je MAJ fuse #2191 et je tente un fix pour vetement.