Discussion :

[scartik]

Bonsoir,

Je travaille actuellement sur un site en c# où des morceaux sont ajoutés par des utilisateurs. Lors de l'affichage des morceaux, j'aimerai faire apparaître les morceaux du "meilleur" au "moins bon" par rapport à certains critères :
-date d'ajout
-nombre de commentaires
-nombre de vue
- etc....

J'ai pensé à utiliser un algorithme génétique mais je ne sais pas si c'est une solution vraiment adapté à mon problème.

En vous remerciant d'avance de vos avis,

[DonQuiche]

Bonsoir et "non". Un algorithme génétique est utile lorsqu'il n'y a pas d'algorithme traditionnel adapté au problème, typiquement parce que le nombre de solutions potentielles au problème est trop grand pour qu'elles soient toutes explorées de façon déterministe. Le problème du voyageur de commerce par exemple.

Je ne sais pas trop bien comment cette idée t'es venue ni ce que tu veux vraiment faire. Est-ce parce que tu ne sais pas comment prendre en compte tous les facteurs pour déterminer la note finale ? C'est une preuve de plus qu'un algorithme génétique ne te servirait à rien : le recours à un tel algorithme nécessite que tu disposes d'une façon systématique de comparer la qualité des résultats produits par deux algorithmes semi-aléatoires. Or, ici, il n'y a qu'un humain qui puisse évaluer la pertinence d'un classement.

Tu n'as pas le choix, il faut que tu décides quelle importance donner à chaque critère et comment les intégrer. Typiquement, pour des morceaux musicaux, je dirais que les deux facteurs importants sont :
* Le degré de conformité entre la requête textuelle envoyée et le titre du morceau ou de l'album, ou du nom de l'auteur. Pense aux requêtes exactes, aux requêtes incomplètes (un seul mot), à celles ayant des fautes de frappe, etc.
* La popularité du morceau. Si tu programmes un site social, autant te servir de tes utilisateurs. Un bon vieux "j'aime/j'aime pas" fait des miracles.

[scartik]

Oui après avoir réfléchi un peu plus à la question, donner une note à chaque attribut et un coefficient pour finalement calculer la note qui servira au classement.
Le problème des "j'aime/j'aime pas" est que tant que le nombre d'adhérent n'est pas assez important, le j'aime/j'aime pas peut être aussi lié à du copinage...
et donc pas assez objectif

[DonQuiche]

Dans ce cas tu pourrais moduler le poids des retours utilisateurs par le nombre de vues : plus le nb de vues est élevé, plus le poids des retours utilisateurs est important. Pour un faible nb de vues, la popularité est estimée en fonction du nb de vues.

Exemple simple : les 10.000 premières vues valent 1, les suivantes sont multipliées par un coefficient R, entre 0 et 1, qui serait la moyenne des retours utilisateurs. Voire simplement se contenter du nombre de vues comme seul index de recherche (la requête la plus vue est celle qui a le plus de chance de correspondre après tout)

Après, je ne suis pas sûr que le nb de commentaires ou la date d'ajout soit pertinent, ça gêne plus la recherche que ça ne la sert. A mon avis il faut se concentrer sur l'essentiel : correspondance avec la requête et popularité. Et éventuellement offrir la possibilité de trier par date d'ajout.

Enfin, la meilleure façon d'avoir une liste des résultats pertinents et facilement explorables est sans doute d'éliminer les doublons du site. Pas facile mais mieux vaut 50 résultats triés simplement que 5000 résultats avec un algo de tri raffiné.

[scartik]

Bonsoir,

tout d'abord merci de cette explication ! par contre je voulais préciser que ce n'est pas dans le cadre d'une recherche mais en fait une page qui afficherait des morceaux en fonctions de l'actualité de la base de données ( les plus récents )

[scartik]

De plus, comment est interprétée une vue ? un affichage de la page ? dans le cas ou des personnes ne cesseraient d'actualiser... le poids de la vue n'aurait plus d'importance.
Mais effectivement modifier le coefficient de "j'aime/j'aime pas" en fonction de tranche de vues est vraiment intéressant !