En décembre dernier, nous avons organisé notre propre hackathon de startups avec six autres entreprises de Skolkovo. Sans sponsors d'entreprise ni aucun soutien externe, nous avons rassemblé deux cents participants de 20 villes de Russie grâce aux efforts de la communauté de programmation. Ci-dessous, je vais vous raconter comment nous avons réussi, quels pièges nous avons rencontrés en cours de route et pourquoi nous avons immédiatement commencé à collaborer avec l'une des équipes gagnantes.
Interface de l'application qui contrôle les modules Watts Battery des finalistes du morceau « Wet Hair »
société
Notre société Watts Battery crée des centrales électriques portables modulaires. Le produit est une centrale électrique portable de 46x36x11 cm, capable de fournir de 1,5 à 15 kilowatts par heure. Quatre de ces modules peuvent assurer la consommation énergétique d'une petite maison de campagne pendant deux jours.
Bien que nous ayons commencé à expédier des échantillons de production l’année dernière, Watts Battery est de toute évidence une startup. L'entreprise a été fondée en 2016 et est depuis la même année résidente du cluster des technologies économes en énergie de Skolkovo. Aujourd'hui, nous avons 15 employés et un énorme retard dans les choses que nous aimerions faire à un moment donné, mais pour le moment, il n'y a pas il est temps pour ça.
Cela inclut également les tâches purement logicielles. Pourquoi?
La tâche principale du module est de fournir un approvisionnement énergétique ininterrompu et équilibré à un coût optimal. Si vous rencontrez une panne de courant pour des raisons indépendantes de votre volonté, vous devez toujours disposer d'une réserve afin d'alimenter pleinement la charge réseau requise pendant la durée de la panne. Et lorsque l’alimentation électrique est bonne, vous pouvez utiliser l’énergie solaire pour économiser de l’argent.
L'option la plus simple est que vous puissiez charger la batterie au soleil pendant la journée et l'utiliser le soir, mais exactement au niveau nécessaire pour qu'en cas de panne de courant, vous ne vous retrouviez pas sans électricité. Ainsi, vous ne vous retrouverez jamais dans une situation où vous avez alimenté l'éclairage à partir d'une batterie toute la soirée (car c'est moins cher), mais la nuit, l'électricité a été coupée et votre réfrigérateur a dégivré.
Il est clair qu’une personne est rarement capable de prédire avec une grande précision la quantité d’électricité dont elle a besoin, mais un système doté d’un modèle prédictif le peut. L’apprentissage automatique en tant que tel est donc l’un de nos domaines prioritaires. C’est juste que nous nous concentrons actuellement sur le développement matériel et que nous ne pouvons pas allouer suffisamment de ressources à ces tâches, c’est ce qui nous a amené au Startup Hackathon.
Préparation, données, infrastructure
En conséquence, nous avons suivi deux voies : l'analyse des données et le système de gestion. En plus des nôtres, il y avait sept autres morceaux de collègues.
Même si le format du hackathon n'était pas déterminé, nous pensions créer « notre propre atmosphère », avec un système de points : les participants font certaines choses qui nous semblent difficiles et intéressantes et reçoivent des points pour cela. Nous avions beaucoup de tâches. Mais au fur et à mesure que nous construisions la structure du hackathon, d'autres organisateurs ont demandé de tout mettre sous une forme commune, ce que nous avons fait.
Ensuite, nous sommes arrivés au schéma suivant : les gars créent un modèle basé sur leurs données, puis ils reçoivent nos données, que le modèle n'avait pas vues auparavant, il apprend et commence à prédire. On supposait que tout cela pouvait être fait en 48 heures, mais pour nous, c'était le premier hackathon sur nos données, et nous avons peut-être surestimé les ressources en temps ou le degré de préparation des données. Lors des hackathons spécialisés en apprentissage automatique, un tel calendrier serait la norme, mais le nôtre n'était pas comme ça.
Nous avons déchargé autant que possible le logiciel et le matériel du module et créé une version de notre appareil spécifiquement pour le hackathon, avec une interface interne très simple et compréhensible que tout développeur pourrait prendre en charge.
Pour la piste basée sur le système de contrôle, il était possible de créer une application mobile. Pour éviter aux participants de se creuser la tête sur ce à quoi elle devrait ressembler et de perdre du temps supplémentaire, nous leur avons donné une présentation de l'application, ultra-légère, afin que ceux qui le souhaitent puissent simplement y « étendre » les fonctions dont ils ont besoin. . Pour être honnête, nous ne nous attendions pas à des dilemmes moraux ici, mais une des équipes l'a pris de telle manière que nous limitions leur envolée, nous voulions obtenir gratuitement une solution toute faite, et ne pas les tester en pratique. Et ils sont partis.
Une autre équipe a choisi de créer une application complètement différente à partir de zéro, et tout s'est bien passé. Nous n'avons pas insisté pour que l'application soit exactement comme ça, nous avions juste besoin qu'elle contienne quelques éléments démontrant le niveau technique de la solution : graphiques, analyses, etc. La conception finale était également un indice.
Étant donné que l'analyse d'un module de batterie Watts en direct lors d'un hackathon prendrait trop de temps, nous avons donné aux participants une tranche de données prêtes à l'emploi pendant un mois, extraites des modules réels de nos clients (que nous avons soigneusement anonymisés au préalable). Comme nous étions en juin, rien ne permettait d’intégrer les changements saisonniers dans l’analyse. Mais à l'avenir, nous leur ajouterons des données externes, telles que des caractéristiques saisonnières et climatiques (c'est aujourd'hui la norme de l'industrie).
Nous ne voulions pas créer d'attentes irréalistes parmi les participants, c'est pourquoi nous avons dit directement dans l'annonce du hackathon : le travail sera aussi proche que possible du travail sur le terrain : des données bruyantes et sales, que personne n'a spécialement préparées. Mais cela avait aussi un côté positif : dans un esprit agile, nous étions constamment en contact avec les participants et avons rapidement modifié la tâche et les conditions d'admission (plus de détails ci-dessous).
De plus, nous avons donné aux participants l'accès à Amazon AWS (si activement qu'Amazon a bloqué une région pour nous, nous découvrirons quoi faire à ce sujet). Là, vous pouvez déployer une infrastructure pour l'Internet des objets et, sur la base de modèles Amazon même simples, créer une solution à part entière en une journée. Mais au final, absolument chacun a suivi son propre chemin, faisant tout par lui-même au maximum. Dans le même temps, certains ont réussi à respecter le délai, d’autres non. Une équipe, Nubble, a utilisé Yandex.cloud, quelqu'un l'a développé sur son hébergement. Nous étions même prêts à donner des domaines (nous en avons enregistré), mais cela n'a pas été utile.
Pour déterminer les gagnants de la piste analytique, nous avons prévu de comparer les résultats, pour lesquels nous avons préparé des métriques numériques. Mais cela n’a finalement pas été nécessaire puisque, pour diverses raisons, trois des quatre participants n’ont pas atteint la finale.
Quant à l'infrastructure domestique, le Technoparc de Skolkovo nous a aidé en nous fournissant (gratuitement) une de ses salles modulaires confortables avec un mur vidéo pour les présentations et quelques salles plus petites pour un espace de loisirs et pour organiser la restauration.
Analytique
Tâche: un système d'auto-apprentissage qui identifie les anomalies de consommation et de fonctionnement des modules à partir des données de contrôle. Nous avons délibérément gardé la formulation aussi générale que possible afin que les participants puissent réfléchir avec nous à ce qui pourrait être fait sur la base des données disponibles.
Spécificité: Le plus complexe des deux morceaux. Les données industrielles présentent certaines différences par rapport aux données des systèmes fermés (par exemple, le marketing numérique). Ici, vous devez comprendre la nature physique des paramètres que vous essayez d’analyser ; considérer tout comme des séries de nombres abstraites ne fonctionnera pas. Par exemple, la répartition de la consommation électrique tout au long de la journée. C'est comme un rituel : le rasoir électrique est allumé le matin en semaine, et le mixeur est allumé le week-end. Puis l’essence des anomalies elles-mêmes. Et n'oubliez pas que la batterie Watts est destinée à un usage personnel, chaque client aura donc ses propres rituels, et un modèle universel ne fonctionnera pas. Trouver des anomalies connues dans les données n’est même pas une tâche ; créer un système qui recherche de manière autonome les anomalies non étiquetées est une autre affaire. Après tout, tout peut être une anomalie, y compris le facteur humain insidieux. Par exemple, dans nos données de test, il y a eu un cas où le système a été forcé par l'utilisateur à passer en mode batterie. Sans aucune raison, les utilisateurs font parfois cela (je réserve que cet utilisateur teste le module pour nous et c'est pour cette raison qu'il a accès au contrôle manuel des modes ; pour les autres utilisateurs le contrôle est complètement automatique). Comme il est facile de le prévoir, dans une telle situation, la batterie se décharge assez activement et si la charge est importante, la charge se terminera avant le lever du soleil ou l'apparition d'une autre source d'énergie. Dans de tels cas, nous nous attendons à voir une sorte de notification indiquant que le comportement du système s'est écarté du comportement normal. Ou bien la personne est partie et a oublié d’éteindre le four. Le système voit qu'habituellement à cette heure de la journée la consommation est de 500 watts, mais aujourd'hui - 3,5 mille - une anomalie ! Comme Denis Matsuev dans l'avion : "Je ne comprends rien aux moteurs d'avion, mais sur le chemin, le moteur sonnait différemment."
Graphique d'un modèle prédictif sur le réseau neuronal open source Yandex CatBoost
De quoi l’entreprise a-t-elle réellement besoin ?: système d'autodiagnostic à l'intérieur de l'appareil, analyse prédictive, y compris sans infrastructure réseau (comme le montre la pratique, tous nos clients ne sont pas pressés de connecter les batteries à Internet - pour la plupart, il suffit que tout fonctionne de manière fiable), identification d'anomalies dont on ne connaît pas encore la nature, un système d'auto-apprentissage sans professeur, le clustering, les réseaux de neurones et tout l'arsenal des méthodes analytiques modernes. Nous devons comprendre que le système a commencé à se comporter différemment, même si nous ne savons pas exactement ce qui a changé. Lors du hackathon lui-même, il était très important pour nous de voir qu'il y a des gars qui sont prêts à se lancer dans l'analyse industrielle ou qui y sont déjà, et qui recherchent de nouveaux domaines pour appliquer leurs capacités. Au début, j'ai été surpris qu'il y ait autant de candidats : après tout, il s'agit d'une cuisine très spécifique, mais peu à peu, tous les participants sauf un ont abandonné, donc dans une certaine mesure, tout s'est mis en place.
Pourquoi n’est-ce pas réalisable à ce stade ?: Le principal problème des tâches d'exploration de données est le manque de données. Il existe aujourd’hui plusieurs dizaines d’appareils Watts Battery en service dans le monde, mais beaucoup d’entre eux ne sont pas connectés au réseau, nos données ne sont donc pas encore très diverses. Nous avons à peine réussi à rassembler deux anomalies - et celles-ci se sont produites sur des prototypes : la batterie industrielle Watts fonctionne de manière assez stable. Si nous avions un ingénieur interne en apprentissage automatique et que nous savions - oui, cela peut être extrait de ces données, mais nous voulons obtenir une meilleure qualité de prédiction - ce serait une histoire. Mais jusqu’à présent, nous n’avons rien fait avec ces données. De plus, cela nécessiterait une immersion profonde des participants dans les spécificités du fonctionnement de notre produit, une journée et demie ne suffit pas pour cela.
Comment avez-vous décidé ?: Ils n’ont pas immédiatement fixé la tâche finale exacte. Au lieu de cela, pendant 48 heures, nous avons dialogué avec les participants, découvrant rapidement ce qu'ils pouvaient obtenir et ce qu'ils ne pouvaient pas obtenir. Sur cette base, dans un esprit de compromis, la tâche a été finalisée.
Qu’avez-vous obtenu comme résultat ?: les gagnants de la piste ont pu nettoyer les données (en même temps ils ont trouvé les « fonctionnalités » de calcul de certains paramètres que nous n'avions pas remarqués nous-mêmes auparavant, puisque nous n'avons pas utilisé certaines données pour résoudre nos problèmes) , mettre en évidence les écarts par rapport au comportement attendu des modules Watts Battery et mettre en place un modèle prédictif capable de prédire la consommation d'énergie avec un haut degré de précision. Oui, il ne s'agit que d'une étape de faisabilité pour développer une solution industrielle ; il faudra ensuite des semaines de travail technique minutieux, mais même ce prototype, créé directement lors du hackathon, peut constituer la base d'une véritable solution industrielle, ce qui est rare.
La principale conclusion: Sur la base des données dont nous disposons, il est possible de mettre en place des analyses prédictives, nous l'avions supposé, mais n'avions pas les ressources pour vérifier. Les participants au hackathon ont testé et confirmé notre hypothèse, et nous continuerons à travailler avec les vainqueurs du parcours sur cette tâche.
Graphique d'un modèle prédictif sur le réseau de neurones open source Facebook Prophet
Conseils pour l'avenir: lors de l'élaboration d'une tâche, vous devez regarder non seulement votre feuille de route de production, mais aussi l'intérêt des participants. Étant donné que notre hackathon n'a pas de prix en espèces, nous jouons sur la curiosité naturelle des data scientists et le désir de résoudre de nouveaux problèmes intéressants dans lesquels personne n'a encore rien montré ou où ils peuvent se montrer meilleurs que les résultats existants. Si vous prenez immédiatement en compte le facteur d’intérêt, vous n’aurez pas à changer d’orientation en cours de route.
Gestion
Tâche: (application) qui gère un réseau de modules Watts Battery, avec un compte personnel, un stockage des données dans le cloud et un suivi de l'état.
Spécificité: dans cette piste, nous ne recherchions pas une nouvelle solution technique, nous disposons bien sûr de notre propre interface consommateur. Nous l'avons choisi pour le hackathon afin de démontrer les capacités de notre système, de nous y immerger et de vérifier si la communauté est intéressée par le thème du développement de systèmes intelligents et d'énergies alternatives. Nous avons positionné l'application mobile comme une option ; vous pouviez la faire ou non à votre discrétion. Mais à notre avis, cela montre bien comment les gens ont réussi à organiser le stockage des données dans le cloud, avec un accès simultané à partir de plusieurs sources différentes.
De quoi l’entreprise a-t-elle réellement besoin ?: une communauté de développeurs qui proposeront des idées commerciales, testeront des hypothèses et créeront des outils de travail pour leur mise en œuvre.
Pourquoi n’est-ce pas réalisable à ce stade ?: Le volume du marché est encore trop faible pour la formation organique d'une telle communauté.
Comment avez-vous décidé ?: Dans le cadre d'un hackathon, nous avons mené une sorte d'étude physique pour voir s'il était possible de proposer non seulement des fonctionnalités, mais aussi des modèles économiques à part entière autour de notre produit très spécifique. De plus, pour que les personnes capables de mettre en œuvre un prototype puissent le faire, après tout, ici - je ne veux offenser personne - ce n'est pas le niveau de programmation d'une LED clignotante sur Arduino (même si cela peut être fait avec des innovations) , des compétences assez spécifiques sont ici requises : développement de systèmes backend et frontend, compréhension des principes de construction de systèmes Internet des objets évolutifs.
Qu’avez-vous obtenu comme résultat ?: deux équipes ont proposé des idées commerciales à part entière pour leur travail : l'une s'est davantage concentrée sur le segment russe, l'autre sur le segment étranger. Autrement dit, dans la finale, ils n'ont pas seulement raconté comment ils avaient créé l'application, mais en étaient essentiellement venus à faire des affaires autour de Watts. Les gars ont expliqué comment ils envisagent l'utilisation de Watts dans plusieurs modèles commerciaux, ont fourni des statistiques, ont montré quelles régions ont quels problèmes, quelles lois sont adoptées où, ont décrit la tendance mondiale : il est démodé d'extraire des bitcoins, il est à la mode d'extraire des kilowatts. Ils se sont délibérément tournés vers les énergies alternatives, ce qui nous a beaucoup plu. Le fait que les participants, en plus de cela, aient pu créer une solution technique fonctionnelle suggère qu'ils peuvent lancer une startup de manière indépendante.
La principale conclusion: Il existe des équipes prêtes à prendre Watts Battery comme base de leur modèle économique, à le développer et à devenir partenaires/compagnons de l'entreprise. Certains d’entre eux savent même identifier le MVP d’une idée d’entreprise et travailler dessus en premier, ce qui fait aujourd’hui défaut partout dans l’industrie. Les gens ne comprennent pas quand s’arrêter, quand lancer une solution sur le marché, même si elle est précoce, mais qui fonctionne. En fait, l'étape de perfectionnement de la solution ne se termine souvent pas, techniquement la solution franchit la ligne de complexité raisonnable, elle entre sur le marché surchargée, on ne sait plus quelle était l'idée originale, quel est le ciblage des clients, quels sont les modèles commerciaux inclus. Comme dans la blague sur Akounine, qui a écrit un autre livre en signant le précédent pour quelqu'un. Mais ici, cela a été fait dans sa forme la plus pure : voici un graphique, voici un compteur, voici des indicateurs, voici une prédiction - c'est tout, rien d'autre n'est nécessaire pour le faire fonctionner. Avec cela, vous pouvez vous adresser à un investisseur et recevoir de l’argent pour démarrer une entreprise. Ceux qui ont trouvé cet équilibre sont sortis vainqueurs de la piste.
Conseils pour l'avenir: au prochain hackathon (nous le prévoyons ), il est peut-être judicieux d'expérimenter avec du matériel. Nous avons notre propre développement matériel (un des avantages de Watts), nous contrôlons entièrement la production et les tests de tout ce que nous faisons, mais nous n'avons pas suffisamment de ressources pour tester certaines hypothèses « matérielles ». Il se peut très bien que dans la communauté des programmeurs système et de bas niveau et des développeurs de matériel, il y ait ceux qui nous aideront dans ce domaine et deviendront à l'avenir notre partenaire dans ce domaine.
personnes
Lors du hackathon, nous attendions ceux qui veulent s'essayer dans un nouveau domaine (par exemple, les diplômés de diverses écoles de programmation) plutôt que ceux qui se spécialisent dans ce type de développement. Mais nous nous attendions quand même à ce qu'avant le hackathon, ils fassent un petit travail préparatoire, lisent comment la consommation d'énergie est prévue en général et comment fonctionnent les systèmes Internet des objets. Pour que chacun vienne non seulement pour s'amuser, à la recherche de données et de tâches intéressantes, mais aussi avec une immersion préalable dans le domaine. De notre côté, nous comprenons que pour cela il faut publier au préalable les données disponibles, leur description et des exigences plus précises pour le résultat, publier des modules API, etc.
Tout le monde avait à peu près le même niveau technologique, plus ou moins les mêmes capacités. Dans ce contexte, le niveau d’harmonie n’était pas le dernier facteur. Un certain nombre d'équipes n'ont pas tiré parce qu'elles ne pouvaient pas se diviser clairement en zones de travail. Il y avait aussi ceux dans lesquels une personne faisait tout le développement, les autres étaient occupés à préparer la présentation, dans d'autres, quelqu'un se voyait confier des tâches qu'il accomplissait, probablement pour la première fois de sa vie.
La plupart des participants étaient jeunes, cela ne signifie pas qu'il n'y avait pas parmi eux d'ingénieurs et de développeurs compétents en apprentissage automatique. La plupart sont venus en équipe, il n'y avait pratiquement pas d'individus. Tout le monde rêvait de gagner, quelqu'un voulait trouver un emploi dans le futur, environ 20 % en ont déjà trouvé un, je pense que ce chiffre va augmenter.
Nous n’avions pas assez de passionnés de matériel, mais nous espérons rattraper ce retard lors du deuxième hackathon.
Progrès du hackathon
Comme je l'ai écrit ci-dessus, nous avons accompagné les participants pendant la majeure partie des 48 heures du hackathon et, surveillant leurs succès aux points de contrôle, avons essayé d'adapter la tâche et les conditions d'acceptation de la première piste analytique afin que, d'une part, le les participants pouvaient le terminer dans le temps restant, et d'un autre côté, cela nous intéressait.
La dernière clarification de la tâche a eu lieu aux alentours du dernier point de contrôle, samedi après-midi (la finale était prévue dimanche soir). Nous avons tout simplifié un peu plus : nous avons supprimé l'obligation de recalculer le modèle sur de nouvelles données, laissant les données avec lesquelles les équipes travaillaient déjà. Comparer les métriques ne nous donnait plus rien, ils avaient déjà des résultats prêts à l'emploi basés sur les données disponibles, et le deuxième jour, les gars étaient déjà fatigués. Nous avons donc décidé de moins les torturer.
Cependant, trois participants sur quatre n'ont pas atteint la finale. Une équipe s'est rendu compte dès le début qu'elle était plus intéressée par la trace de nos collègues, l'autre, juste avant la finale, s'est rendu compte qu'au cours du processus de traitement, elle avait filtré à l'avance les données nécessaires et a refusé de présenter son travail.
L’équipe « 21 (Wet Hair Effect) » a participé à nos deux morceaux jusqu’à la toute fin. Ils voulaient tout couvrir à la fois : l'apprentissage automatique, le développement, l'application et le site Web. Jusqu'à ce que nous les menacions de retrait au dernier moment, ils croyaient qu'ils faisaient tout à temps, même si dès le deuxième point de contrôle, il était évident qu'avec l'essentiel - l'apprentissage automatique - ils ne pouvaient pas faire de progrès significatifs : ils faisaient généralement face à le deuxième bloc, mais on ne pouvait pas prédire la consommation d'électricité, n'était pas prêt. En conséquence, lorsque nous avons déterminé la tâche minimale pour se qualifier pour la première, ils ont quand même choisi la deuxième piste.
Fit-predict avait une composition équilibrée adaptée à l'analyse des données, ce qui leur a permis de tout surmonter. Il était visible que les gars étaient intéressés à « toucher » de vraies données industrielles. Ils se sont immédiatement concentrés sur l'essentiel : analyser, nettoyer les données, traiter chaque anomalie. Le fait qu’ils aient pu construire un modèle fonctionnel pendant le hackathon est une grande réussite. Dans la pratique professionnelle, cela prend généralement des semaines : pendant que les données sont nettoyées, pendant qu'ils les approfondissent. C’est pourquoi nous travaillerons certainement avec eux.
Dans le deuxième parcours (gestion), nous attendions que chacun fasse tout en une demi-journée et vienne demander à rendre la tâche plus difficile. En pratique, nous avons à peine eu le temps d’accomplir la tâche de base. Nous avons travaillé sur JS et Python, ce qui reflète l'état actuel de l'industrie.
Ici aussi, les résultats ont été obtenus grâce à des équipes bien coordonnées dans lesquelles la division du travail était construite, il était clair qui faisait quoi.
La troisième équipe, FSociety, semblait avoir une solution, mais finalement ils ont décidé de ne pas montrer leur développement, ils ont dit qu'ils ne considéraient pas que cela fonctionnait. Nous respectons cela et n’avons pas discuté.
Le gagnant a été l'équipe des « Strippers de Bakou », qui a su s'arrêter, non pas pour courir après des « bibelots », mais pour créer un MVP qui n'a pas honte de le montrer et qui est clair qu'il peut être développé et mis à l'échelle. Nous leur avons immédiatement dit que nous n'étions pas trop intéressés par des opportunités supplémentaires. S'ils souhaitent s'inscrire via QR code, reconnaissance faciale, laissez-les d'abord créer des graphiques dans l'application, puis prendre les graphiques facultatifs.
Dans ce morceau, « Wet Hair » est entré en finale avec confiance et nous avons discuté de la poursuite de la coopération avec eux et « Hustlers ». Nous avons déjà rencontré ce dernier au cours de la nouvelle année.
J'espère que tout se passera bien et nous avons hâte de voir tout le monde au deuxième hackathon en mars !
Source: habr.com