artragis
commented
7 years ago Bonjour,
Pour revenir sur la différence boost solr/boost elastic search : le boost solr est forcément normalisé, et la somme des boosts d'un document est égale à 1 (du moins c'est ce que disait la documentation haystack), sur elastic search, tu peux clairement booster plus librement, et quand il y a de la liberté, je suis un fan de la suite de fibonacci. (1, 2, 3, 5, 8, 13, 21... mais je pense que déjà 13 c'est énorme)
Je pense clairement qu'il faut booster les posts en fonction des +/-1. Il ne sert pas de les booster en mode stéroïde mais au moins la pertinence sera accrue.
Sinon je vois que tu as mis un "éventuellement" à "est utile". Je pense qu'il faut clairement indexer ça quitte à booster légèrement.
Autre chose qui m'a clairement choqué : tu n'indexe pas la licence. Pour moi on doit --dans le futur-- donner la possibilité aux gens qui le veulent, surtout si le nombre de contenus augmente toujours, la possibilité de filtrer en fonction des licences. Le libre c'est aussi ça.
Pour l'idée de réduire la granularité de stockage, tu reviens aux origines de la zep-12 qu'on avait dû abandonner à cause de haystack, donc je te soutiens totalement.
pierre-24
Situphen
DevHugo
A-312
philippemilink
Zoyeux nowel les gens !
Puisque c'est enfin noël, donc enfin les vacances, j'ai (enfin) du temps pour m'attaquer à un truc que je garde en tête depuis deux mois : la recherche (voir #4096). En effet, @Spacefox a déjà dit plusieurs fois qu'il vaudrait mieux passer à Elasticsearch (ES), plus puissant (ou en fait plus exploitable, puisque dessous, c'est Lucene à chaque fois) que ce que ZdS utilise actuellement. Bref, une meilleure recherche et un retour de la barre de recherche en barre d’accueil. D'ailleurs, je cite le renard :
Sauf que pour ça, il va falloir répondre à la question "qu'est ce qu'on attend comme résultat d'une recherche".
Quelques éléments avant de continuer
En préambule, il est important de savoir que ES classe ces données en documents, qui correspondent grosso modo à une ligne de BDD (on est dans un contexte NoSQL), donc un post, un topic (qui sont différents types de document), etc.
Scoring et boosting
Avant toute chose, il est bon de comprendre comment ES classe les résultats suite à une recherche. Si on effectue la recherche d'un terme dans l'ensemble des documents, ceux-ci sont classés par score, que ES calcule comme étant le produit
TF * IDF, où la partie TF (term frequencies) est le nombre de fois qu'un terme apparait dans un document et IDF (inverse document frequencies) est l'importance du terme dans l'ensemble des documents.Évidement, l'histoire ne s'arrête pas là, puisqu'on peut modifier le score par différents moyens, qui relèvent du boost:
Actuellement, je n'ai aucune idée de l'ordre de grandeur du facteur de boost, si c'est 2, 5, 10 ou 100, j'ai pas encore eu assez de données pour tester. Dans l'absolu, il faudra ajuster ça empiriquement.
tokenizer(s) et analyzer(s)
Afin d'effectuer ces recherches, le mieux est de ne pas faire des recherches fulltext (passer tout le texte en revue) mais de ne rechercher que certains termes. Par ailleurs, il est toujours mieux d'éviter d'avoir à ce casser la tête avec les problèmes de singulier/pluriel (par défaut "table" et "tables" ne sont pas les mêmes mots).
Du coup, chaque champ indexé passe par un analyzer, découpé en trois étapes :
Et de manière générale, y'a moyen d'expliquer à ES que nous, on cause français, donc c'est plutôt pas mal.
Ici, je propose très clairement d'utiliser un analyzer qui comprend le français (donc qui vire les déterminants et met les mots au singulier), qui vire le HTML, qui passe tout en minuscule et qui remappe tout en ascii standard. Si vous voyez d'autres token filter intéressants, dites le moi.
Et alors ?
Bon, je me répette, le but du jeu, c'est d'avoir la recherche la plus performante possible. Évidement, y'a pas de réponse unique, même Google n'a pas encore trouvé ;)
Quoi ?
Premièrement, il faut se mettre d'accord sur ce qu'on on indexe. Actuellement, il s'agit de
À noter qu'à différents moments, on a également proposé d'indexer les utilisateurs. En soit, c'est pas difficile, mais à part le nom (et éventuellement la biographie), je vois pas trop quoi indexer.
Je propose éventuellement de booster les contenus sur les résultats issus du forum, mais tout dépend ce qu'on cherche à récupérer de la recherche. Je propose également de booster les topics par rapport aux messages et les contenus par rapport à ce qu'ils contiennent. La logiquue étant que si le terme recherché est dans le titre (du topic ou du contenu), il y a beaucoup de chance que la discussion porte dessus.
Comment ?
Deuxièmement, il faut définir ce qu'on indexe pour chacun des modèles (et comment on les boostent, éventuellement). Et troisièmement, il faut définir ce qui affecte les résultats.
Voici une petite proposition (notez que comme j'ai dit, je n'ai aucune idée de la valeur du facteur de boost, je place juste un ordre d'importance).
Topic
Post
Contenus
(en fait les contenus publiés)
(... et de la partie non publiée)
Extraits et conteneurs
Tout d'abord, je propose de ne pas indexer tout les conteneurs et ne pas indexer les extraits tels quels, mais seulement la forme qu'ils ont quand ils sont publiées, soit tout les extraits d'un même chapitre rassemblés.
Cette proposition est assez forte, mais possède selon moi plusieurs avantages:
Mais évidement, ça se discute.
Et du coup,
Et donc ?
Si on suis ce que je viens de dire, ce qu'on obtient est une recherche qui sort en priorité les contenus sur les forums, qui donne la priorité aux tags et au titre envers les différents champs de texte et qui discrimine éventuellement selon différents critères plus ou moins objectifs (date de publication, position, ...).
C'est un peu ma vision de ce que la recherche devrait donner, mais c'est ma vision, donc n'hésitez pas à argumenter.
Bon amusement ;)