PC & Mobile

Le côté obscur des hackathons Data Science – Vers la science des données

Le côté obscur des hackathons Data Science - Vers la science des données


J'ai décrit plusieurs raisons de participer à des hackathons dans la partie précédente de la trilogie. La motivation d’apprendre beaucoup et de gagner de précieux prix attire presque tout le monde, mais bien souvent l’événement échoue et les participants repartent insatisfaits à cause des erreurs des organisateurs ou des entreprises sponsors. Je fournis le poste actuel pour éviter fréquemment de tels incidents déplaisants. La deuxième partie de la trilogie est consacrée aux erreurs des organisateurs.

Le poste actuel est organisé de la manière suivante: dès le début, je parle de l’événement, explique ce qui n’a pas fonctionné et quel en a été le résultat (ou pourrait aboutir à long terme). Ensuite, je fournis ma propre évaluation des choses qui se passent ainsi que de la façon dont j'agirais si j'étais l'organisateur de l'événement. Je ne peux que présumer de la motivation des véritables organisateurs puisque j’étais le participant à tous les événements. Par conséquent, mon évaluation peut être unilatérale. Certains points peuvent sembler erronés, mais en fait, ont été conçus de cette manière.

Il peut sembler au lecteur que l’auteur a décidé de serrer les poings après une bagarre. Mais c’est faux. J'ai réussi à remporter un prix dans la liste de certains hackathons, ce qui ne m'a pas empêché de conclure que l'événement était mal organisé.

Aucune entreprise en particulier ne sera spécifiée dans le message en raison du respect des organisateurs et des participants. Le lecteur attentif peut toutefois deviner (ou google) à qui il est fait référence.

Hackathon # 1. Restrictions

Un hackathon d’analyse de données a été organisé par une grande entreprise de télécommunication il ya six mois à Moscou. Vingt équipes ont eu du mal à obtenir le premier prix. Un ensemble de données pour l’analyse a été fourni à l’événement. Il contient les données sur les appels au service de support de la société, les activités sur les réseaux sociaux ainsi que les données des utilisateurs codées (sexe, âge, etc.). La partie la plus intéressante du jeu de données, à savoir les messages de l’utilisateur et la réponse de l’opérateur (données textuelles), était plutôt «bruyante»; il a donc fallu la nettoyer pour poursuivre l’opération.

Les organisateurs ont défini la tâche suivante: créer quelque chose d’intéressant avec les données fournies. Il était interdit d'utiliser des jeux de données ouverts supplémentaires à partir du réseau ou d'analyser les données soi-même. En outre, il était interdit d'offrir des idées qui n'étaient pas liées à un ensemble de données. En fait, les données fournies étaient assez «médiocres» car il était plutôt difficile de les transformer en produits intéressants. Il est devenu évident que de nombreuses idées, proposées précédemment, ont déjà été mises en œuvre (ou le seront dès que possible) par la société.

En conséquence, l’énorme nombre d’équipes (15 sur 20) a créé des chatbots. Une décision prise lors des discours d'une des équipes était légèrement différente de la précédente. Ensuite, un des membres du jury a demandé à la prochaine équipe: «Ok les gars, avez-vous aussi un chatbot?». Ainsi, ces équipes, qui n’ont pas créé de chatbots, ont remporté les 1re et 2e places sur trois places disponibles.

"Ok, les gars, avez-vous un chatbot aussi?"

Comparons le hackathon, organisé par une société de conseil internationale il y a deux ans pour le cabinet «Qwerty123». Les organisateurs ont parlé des paramètres, car ils sont utilisés par la société «Qwerty123» car la plupart des participants du hackathon n’étaient pas au courant des spécificités de l’activité de la société «Qwerty123» avant l’événement. Ensuite, six ensembles de données d'orientation différents ont été fournis, y compris du texte, des tableaux, des géolocalisations - il y avait une marge de manœuvre pour tous les participants. Les organisateurs n'ont pas interdit l'utilisation d'ensembles de données supplémentaires, mais ont également soutenu de telles initiatives. Dix équipes ayant des décisions différentes se sont battues pour le prix principal. Lors de la finale du concours, toutes les équipes ont utilisé les données fournies par la société (malgré l’interdiction), qui indiquaient un bon potentiel d’obtention de produits de haute qualité.

Moralité

Évitez de limiter le flux des participants à la création. Vous devez fournir du matériel et faire confiance à leur vision et à leur professionnalisme tout en étant organisateur. Toutes les restrictions ou interdictions doivent vous alerter si vous êtes un membre du hackathon. Il s’agit généralement d’une mauvaise preuve d’organisation. Préparez-vous au fait que vous devez créer un projet dans un grand pool de niveaux de concurrence si vous rencontrez toujours des restrictions. Vous devez donc être responsable, ce qui signifie prendre le risque en pareil cas: créer quelque chose de fondamentalement nouveau ou fournir une «fonctionnalité de destruction» inhabituelle afin de différer grandement du cours du projet similaire.

Évitez de limiter le flux des participants à la création. Vous devez fournir du matériel et faire confiance à leur vision et à leur professionnalisme tout en étant organisateur.

Hackathon # 2. Tâches impossibles

Le hackathon à Amadora promettait d'être intéressant. La société qui parraine les fabricants de téléphones a commencé la préparation du hackathon 4 mois avant la date de l’événement. Les événements de relations publiques se déroulaient sur des réseaux sociaux et impliquaient les participants potentiels de réussir un test technique et d'écrire sur leurs projets antérieurs afin d'être sélectionnés pour l'événement en cours. La cagnotte était assez grande. Les mentors ont organisé une session technique afin de donner aux participants suffisamment de temps pour se familiariser avec les spécificités de l'industrie quelques jours avant le hackathon.

Les organisateurs ont fourni un vaste ensemble de données avec des journaux (la taille totale était d'environ 8 Go) lors de l'événement. La tâche consistait en une classification binaire des pannes d'équipement. Ils ont parlé des critères d’évaluation des projets, à savoir la qualité de la classification, la créativité dans la création de fonctionnalités, le travail d’équipe, etc. Mais ce n’est que de la malchance: il n’y avait que 20 exemples dans le train et 5 dans le test pour 8 Go de «fonctionnalités». Enfin, le jeu de données contenait une fuite: les journaux d’équipement, reçus mercredi, contenaient l’erreur d’opération d’équipement, alors que ceux créés, jeudi, ne le contenaient pas (ce qui, d’ailleurs, n’était connu que par deux équipes russes le pays est considéré comme le «pays du datamineur» expérimenté). La tâche était impossible à résoudre malgré la connaissance réelle des étiquettes de test. Les organisateurs n’ont pas réussi à obtenir le résultat escompté. Les participants ont donc passé beaucoup de temps à résoudre une tâche mal composée. Donc, le hackathon actuel a échoué.

Enfin, le jeu de données contenait une fuite: les journaux d’équipement, reçus mercredi, contenaient l’erreur de fonctionnement de l’équipement, alors que ceux qui ont été créés jeudi ne le contenaient pas.

Moralité

Assurez-vous de fournir l'expertise technique des tâches et de vérifier que vos tâches sont adéquates. Il vaut mieux surpayer pour l'examen préliminaire (dans ce cas, tout informaticien confirmerait immédiatement qu'il est impossible de résoudre le problème actuel) pour éviter une telle situation.

Il est préférable de surpayer pour l'examen préliminaire afin d'éviter les échecs de hackathons.

Dans un tel cas, la société a perdu la crédibilité des candidats potentiels en plus du temps et de l’argent dépensés. Soit dit en passant, les participants et l'entreprise doivent informer des résultats de hackathon réussis, ce qui signifie annoncer le plus possible le hackathon. Malheureusement, beaucoup d’entreprises n’ont pas réussi à le faire et se sont limitées à la post-annonce et à quelques photos de l’événement sur Twitter.

Hackathon # 3. À prendre ou a laisser

Récemment, notre équipe a participé au hackathon qui a eu lieu à Amsterdam. Le sujet de l’énergie nous convenait particulièrement, car j’ai la maîtrise de l’énergie (majeure en énergie renouvelable). Le hackathon s'est déroulé en ligne. Nous avons reçu la description de la tâche et un mois à compléter. Le souhait des organisateurs était de mener à bien un projet qui contribuerait à accroître l'efficacité énergétique des maisons d'Amsterdam.

Nous avons réussi à créer une application fournissant une prévision de la consommation d’électricité (j’ai participé à un concours sur le sujet actuel auparavant, où j’ai reçu une solution proche de la solution SOTA), ainsi qu’à la production de panneaux solaires. Ensuite, les performances de la batterie sont optimisées en fonction des prévisions (l’idée actuelle a été partiellement reprise du diplôme de mon master). Notre projet était à la fois parfaitement en accord avec la tâche des organisateurs (comme il nous le semblait alors) et la politique administrative d’Amsterdam dans le domaine des énergies renouvelables pour plusieurs années à venir.

Notre équipe et d’autres lors de l’évaluation des projets ont été informées que cela était contraire aux attentes du client. Nous avons donc été informés que nous devions changer de produit pour avoir une chance de gagner un prix. Mais cela n’a pas changé et a démissionné pour la défaite. Le nombre total d’équipes était de 40, mais nous n’avons pas réussi à faire partie du top 7, même si le choix des organisateurs semblait plutôt étrange. Ils ont choisi l'équipe qui a créé l'application de calcul de la vitesse du vent et de l'irradiance solaire, basée sur les données des capteurs du smartphone: un microphone pour le vent et un capteur de lumière pour l'irradiance solaire. La caractéristique la plus meurtrière était la classification hotdog / not hotdog en trois classes: soleil, vent, eau et article correspondant de Wikipedia (démo).

Laissons le côté moral de la question pendant un certain temps: il est contraire à l’éthique de faire chanter les participants avec l’opportunité de gagner. Il existe un risque que de nombreux participants forts quittent l’événement après avoir entendu de tels commentaires (ce qui est arrivé à notre équipe et aux autres personnes qui ont arrêté la mise à jour de la page de leur projet après avoir écouté le mentor), puisqu’une des motivations de participation du hackathon est (en particulier pour développeurs expérimentés) propre mise en œuvre des idées. Néanmoins, supposons que nous avons accepté le souhait des organisateurs et réussi à modifier notre projet en fonction de leurs besoins. Que pourrait-il arriver ensuite?

Il est contraire à l'éthique de faire chanter les participants avec l'occasion de gagner

Tous les organisateurs ont leur propre idée de «projet idéal». Par conséquent, tous les souhaits (et modifications) mèneront à l’idéal actuel. Les concurrents vont passer leur temps et il sera plus difficile pour eux de refuser toute participation ultérieure (puisque certains efforts ont déjà été faits et il semble que la victoire était si énorme). Mais le fait est que la compétition pour les récompenses augmentera. Par conséquent, les participants devront de plus en plus modifier le projet en fonction des modifications apportées par les organisateurs, dans l’espoir d’obtenir une récompense. Ainsi, les gars qui n’ont pas réussi à remporter les récompenses se rendront compte qu’ils ont participé à la pige sans gagner d’argent, car ils ont apporté des modifications selon les souhaits du client, mais n’ont rien obtenu en retour (à l’exception de l’expérience pertinente, bien sûr).

Ainsi, les gars qui n’ont pas réussi à remporter les récompenses se rendront compte qu’ils ont participé à la pige sans gagner d’argent, car ils ont apporté des modifications selon les souhaits du client, mais n’ont rien obtenu en retour (à l’exception de l’expérience pertinente, bien sûr).

Moralité

Souvent, les souhaits et les retours des organisateurs contribuent au projet. Cependant, dans un tel cas, les participants ne devraient pas compter sur les conseils des mentors. Obtenir des commentaires négatifs des organisateurs signifie que votre participation est complète. Parce que les hackathons ne sont pas indépendants (surtout sans argent).

Obtenir des commentaires négatifs des organisateurs signifie que votre participation est complète. Parce que les hackathons ne sont pas indépendants (surtout sans argent).

Il est préférable de définir votre vision dans le formulaire de spécification d’un pigiste si vous organisez un hackathon avec une vision de projet claire, mais sans les compétences ni la capacité de le mettre en œuvre vous-même. Sinon, vous devrez payer deux fois les services d’un hackathon et d’un pigiste.

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close