[Bug] Recherche topoguide - résultats non pertinents

Bon je relance une dernière fois le sujet… Je suis en train de me pencher sur une mise à jour des spots de dry, et c’est juste l’enfer :


La majorité des résultats ne sont pas pertinents.

Ca serait cool de faire un hack temporaire pour désactiver la recherche proche. Ca je sais le faire, j’en avais parlé en MP. Vous aviez parlé de modifications en cours, sauf que ça fait des mois que c’est à l’arrêt, et c’est vraiment trop chiant, pour tout le monde.
Je recopie grosso modo ce que j’avais envoyé en MP :

Le hack le plus simple pour jouer là dessus serait de modifier la fuzziness du multimatch :
https://github.com/c2corg/v6_api/blob/master/c2corg_api/search/ init .py#L101
Si on se réfère à la doc elasticsearch :
https://www.elastic.co/guide/en/elasticsearch/reference/2.4/common-options.html#fuzziness
Elle est actuellement en auto, et pour des termes de 3 ou plus caractères (approximativement 100% des mots importants), ça autorise un edit.

Le hack le plus simple serait de désactiver complètement ce paramètre. Sinon autoriser 1 edit à partir de 6-7 lettres je dirais. Et surtout jamais 2.

Petit rappel du fonctionnement du mode actuel :

 AUTO

    generates an edit distance based on the length of the term. For lengths:

    0..2
        must match exactly 
    3..5
        one edit allowed 
    >5
        two edits allowed 

Et la modif proposée :

        "fuzziness": 1,
        "prefix_length": 6,

Le plus important serait de faire une modif « temporaire » rapidement, car ça fait bien trop longtemps que c’est un sacré merdier, qui ne convient à personne.

2 Likes

En effet ce n’est pas pertinent.
Mais dans ton cas, recherche « dry tooling ».
Tous les spots de dry et uniquement les spots de dry : Camptocamp.org

Je sais bien, je voulais modifier les spots mal référencés. Exemple : Camptocamp.org

OK. Mais dans cet exemple, on ne risquait pas de trouver « dryland » avec la recherche de mot exact « dry ».
Par ailleurs j’ai corrigé 3 noms « drytooling » en « dry-tooling ».

Allez une dernière relance. Le hack est rapide et facile il me semble (pour le coup je suis assez sûr de mon coup !)

Juste pour le plaisir, même si ça a déjà été posté :


https://www.camptocamp.org/routes/487432/fr/cogne-valeille-lau-bij

1 Like

Ou pas, ça fait tellement longtemps qu’on se traîne ce sujet très impactant… Il ne faut surtout pas se lasser de le rappeler!

1 Like

J’ai du mal à comprendre si c’est sarcastique ou non. En tous cas dans mon usage c’est effectivement très impactant. (et très simple à corriger avant un fix propre)

Ah non, zéro sarcasme! Simplement, C2C ça fonctionne sur la base de très peu de personnes effectivement investies, et donc beaucoup de choses ne parviennent malheureusement pas à être faites

2 Likes

Comment on fait pour avancer dans ce problème de recherche ?
Pourquoi ne pas tester la proposition d’Adrien pendant quelque temps et la valider ou non après test ?
Les recherches non abouties sont un problème sérieux je trouve.

4 Likes

Très bonne question

C’est quand même dommage que le fonctionnement classique de la plupart des utilisateurs soit de passer par une recherche google pour retrouver les itinéraires, simplement car la recherche interne ne fonctionne pas correctement. J’en ai parlé autour de moi, et je ne suis clairement pas le seul à passer par google…

6 Likes

Idem
Ça fait longtemps que j’ai abandonné la recherche interne et passe par Google.
Pour info la recherche sur le site promogrimpe est juste parfaite…
C’est pourtant pas un gros truc comme c2c…
Étrange.
S’en inspirer serait un gros plus.

Petit up rituel.

Et une question au passage : pourquoi ma suggestion n’est pas implémentée ? En vrai, ça ne coûte rien, c’est quelques lignes à modifier, un retour en arrière est facile, et si ça casse la recherche, ce n’est pas trop gênant vu comme elle fonctionne mal actuellement. Et de toute manière, vu la complexité de la modif, ça ne risque pas vraiment de casser quoi que ce soit…

2 Likes

@Adrien_le_bouquetin Demande à passer dans l’équipe de développeurs !

On en avait parlé, mais je ne suis pas dev, je n’ai actuellement pas assez de connaissances. Sinon j’aurais push un truc sur github. Mais je ne sais pas encore faire.

Et sinon, une alternative pour l’instant, que je viens de créer : ajouter un moteur de recherche via les options du navigateur, avec comme requête spécifique
https://www.google.com/search?q=site%3Acamptocamp.org%2Froutes+%s
Associé à un mot clé pratique, ça permet facilement de faire une recherche, uniquement sur les itinéraires (et pas les sorties)

image

1 Like

Sinon sur google il y a (aussi pour les sorties) la requete, par exemple pour le mot « bonjour » sur les sorties Camptocamp :

« bonjour » -diff site:www.camptocamp.org/outings

il suffit de mettre « routes », « waypoints » ou « articles » a la place de « outings » - selon le cas.

Merci de vous pencher enfin dessus ! Par contre honnêtement, le fix est discutable (même le mien donnerait de meilleurs résultats je crois) :
image
image
Des résultats stricts seraient bien plus propres, vu que dès qu’il y a une modif d’une lettre, ça implose.

Si quelqu’un veut bien m’expliquer comment faire mes propres modifs à la maison, je suis preneur.

edit : j’ai un peu regardé, visiblement Elasticsearch ne supporte pas fuzziness avec type=« phrase » dans une requête multi_match.
edit2 : en fait quand il y a plusieurs mots, l’autocomplétion saute. Je comprends la raison qui vous a poussé à tenter ça mais c’est peu abouti pour l’instant. Donc du ngram basique serait potentiellement mieux, malgré le bruit.

Dans ton exemple, tu recherches « mon blanc » (au lieu de « mont blanc »).
Pas de bol, « mon » est un mot supprimé des mots clés, comme le, la , du, … A moins que ce soit parce qu’il n’a que 3 lettres ?

Par contre quand on cherche « roch blanc » au lieu de « rocher blanc », on trouve bien tout plein de Rocher Blanc.

C’est une grosse amélioration.
Quand on teste les mots clés de ton 1er post (« lau bij »), on trouve direct la voie « Lau Bij ».

En fait en voulant prendre l’exemple le plus banal (et cherché), j’ai pris le pire cas particulier haha

Par contre je ne vois pas d’explication rationnelle au « mont blan » qui n’affiche aucun résultat, et qui soit cohérente avec ce que tu racontes. Pour moi c’est lié au problème du fuzziness qui ne fonctionne plus avec les phrases, comme dit plus haut. Sauf que ça a l’air de fonctionner pour le premier mot. Bref

Bonjour,

Nous avons mis en production hier soir une première version de l’amélioration de la recherche.
C’est particulièrement compliqué car nous souffrons de la vétusté de l’infrastructure.

La ré-indexation de tous les documents est toujours en cours, d’où les comportements erratique, le temps que ce soit réglé.

D’autres évolutions de la recherche sont prévues, avec la montée en version du composant qui gère cela, mais nous la ferons dans un deuxième temps.

6 Likes

Effectivement, le comportement est différent selon que ce soit un mot, ou une phrase