Version imprimable
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,
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.
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
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é.
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 )
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 !
Une métrique "vues" n'est effectivement pas triviale si tu prends en compte de possibles fraudes (sinon, les rafraîchissements ne sont pas un problème). Dans tous les cas tu peux au mieux complexifier le processus de fraude.
* Tu pourrais enregistrer les couples (url ; ip du visiteur) des 24 dernières heures pour filtrer les doublons. Evidemment, on peut utiliser plusieurs IP.
* Tu pourrais ne comptabiliser une vue qu'à compter du moment où il y a interaction entre l'utilisateur et la page (scrolling, etc). Ça élimine les bots les plus simples.
* Tu pourrais remplacer la métrique "pages vues" avec une métrique "temps passé à interagir avec la page" (ce que font pas mal de régies de pub) : chaque fois qu'un utilisateur interagit, tu crédites 30s d'attention et tu ignores les interactions des 30 prochaines secondes. Si le fraudeur devine le mécanisme, il lui est tout de même difficile de déterminer la durée exacte créditée et il faut un bot personnalisé et toujours actif. Il y a peut-être de meilleures techniques pour mesurer l'attention, je connais mal le sujet.
* Tu pourrais te baser sur le nombre de secondes de musique écoutées, au moins ça bouffera la bande passante du fraudeur. Et la tienne si ça ne le dissuade pas.
* Tu pourrais ne comptabiliser que les visites des utilisateurs enregistrés. En protégeant l'inscription avec un captcha, tu sécurises plusieurs métriques, donc celle-ci.
Cela dit, tout peut être fraudé : les commentaires, le nb de pages vues, les "j'aime / j'aime pas", etc... Plus ton site a de trafic moins la fraude est significative. En effet, c'est surtout d'une fraude artisanale peu raffinée et à petite échelle dont tu dois te protéger (mais pouvant peser tout de même : 5 vues par seconde, ce sont des dizaines de milliers de vues après 24h), je n'ai jamais entendu dire que les maisons de disque embaucheraient des armées de hackers chinois. Enfin, le secret quant à la méthode que tu utilises pour parer les fraudes est une forme de protection mais ton code html peut contenir des indices selon la méthode.
Encore une fois, vise un système simple mais robuste. Perso, le nb de vues des utilisateurs enregistrés ou les minutes écoutées me semblent pas mal.
Bonsoir,
Ces méthodes sont toutes vraiment très intéressantes. Parmi celles-ci, il y en a deux qui me paraissent plus adaptée à mon problème.
-le couple url/ip avec une vérification de l'affichage sur les X dernières heures. Il faudrait donc que du coté de la base de données il y ait un batch lançant une procédure stockée supprimant les champs ayant plus de 24h ? C'est la solution à laquelle je pense mais ce système ne serait pas trop lourd en terme de charge au niveau des serveurs de base de données ?
-Les interactions avec le lecteur ( un mélange entre les interactions avec la page et le fait de lire la musique ) en effet le lecteur n'étant pas en autoplay si l'utilisateur clique sur play signifie qu'il a fait la démarche de vouloir écouter le morceau.Cependant le lecteur est en flash (jwplayer) et je ne sais pas du tout si c'est possible d'accéder à ces interactions là du fait que le flash soit un langage compilé ?
Pour la solution des couples, la suppression ne doit pas être un problème : il s'agit de vider une table, ça doit être rapide (en principe on se contente de marquer les clusters comme inutilisés et d'éditer le début de chaque index mais si le moteur cafouille et que ça ne l'est pas, supprime et recrée la table). Par contre, à chaque chargement de la page (ou lecture dans ton cas) tu vas devoir parcourir l'index pour éventuellement faire une insertion. Rien de terrifiant cela dit et, sur le long terme si tu as plus de titres que de visiteurs quotidiens, ce seront d'autres tables qui seront les plus gourmandes de toute façon.
Je ne connais pas Flash mais, au vu de ce qu'on voit tous les jours, Flash semble parfaitement capable de recevoir des paramètres et d'interroger le serveur : il te suffit donc de lui transmettre une clé et, une fois la lecture enclenchée, de lui faire appeler une url avec cette clé sans rien attendre en retour. Le serveur prendra alors en charge la mise à jour des vues à partir de la clé reçue.
D'accord je pense donc que la solution la plus simple à implémenter et vers laquelle je vais me diriger serait le couple ip/page.
Juste une dernière précision d'aspect technique :
c'est bien Request.ServerVariables["HTTP_X_FORWARDED_FOR"] et
Request.ServerVariables["REMOTE_ADDR"] qu'on utiliser pour récupérer l'adresse ip du visiteur ?
En tout cas merci beaucoup !!!
De rien. ;)
Pour les variables, en effet : "remote_addr" est l'adresse IP à l'origine de la requête (celle de l'utilisateur ou de son vpn/proxy) tandis que la première est la vraie adresse de l'utilisateur s'il est derrière un proxy transparent (non-anonyme) ; elle est vide ou vaut "UNKNOWN" ou "unknown" sinon. Note que même la "remote_addr" peut avoir ces valeurs invalides, je ne sais pas trop bien pourquoi mais pense à traiter le cas.