Sidste december afholdt vi vores eget startup hackathon med seks andre Skolkovo-virksomheder. Uden virksomhedssponsorer eller nogen ekstern støtte samlede vi to hundrede deltagere fra 20 byer i Rusland gennem programmeringsfællesskabets indsats. Nedenfor vil jeg fortælle dig, hvordan det lykkedes, hvilke faldgruber vi stødte på undervejs, og hvorfor vi straks begyndte at samarbejde med et af de vindende hold.
Interface til applikationen, der styrer Watts Battery-moduler fra finalisterne på banen, "Wet Hair"
selskab
Vores firma Watts Battery skaber modulære bærbare kraftværker. Produktet er et bærbart kraftværk 46x36x11 cm, der kan levere fra 1,5 til 15 kilowatt i timen. Fire sådanne moduler kan levere energiforbruget til et lille landsted i to dage.
Selvom vi begyndte at sende produktionsprøver sidste år, er Watts Battery efter alt at dømme en startup. Virksomheden blev grundlagt i 2016 og har siden samme år været bosiddende i Skolkovo Energy Efficient Technologies Cluster.I dag har vi 15 ansatte og et kæmpe efterslæb af ting, som vi gerne vil lave på et tidspunkt, men lige nu er der ingen tid til det.
Dette omfatter også rene softwareopgaver. Hvorfor?
Modulets hovedopgave er at sørge for uafbrudt, afbalanceret energiforsyning til en optimal pris. Hvis du oplever en strømafbrydelse på grund af årsager uden for din kontrol, bør du altid have en reserve for fuldt ud at kunne strømforsyne den nødvendige netværksbelastning under afbrydelsens varighed. Og når strømforsyningen er god, kan du bruge solenergi til at spare penge.
Den enkleste mulighed er, at du kan oplade batteriet fra solen i løbet af dagen og bruge det om aftenen, men præcis til det niveau, der er nødvendigt, så du i tilfælde af strømsvigt ikke står uden strøm. Så du vil aldrig finde dig selv i en situation, hvor du tændte for belysningen fra et batteri hele aftenen (fordi det er billigere), men om natten gik strømmen ud, og dit køleskab afrimede.
Det er klart, at en person sjældent er i stand til med stor nøjagtighed at forudsige mængden af elektricitet, han har brug for, men et system bevæbnet med en forudsigelsesmodel kan. Derfor er machine learning som sådan et af vores prioriterede områder. Det er bare, at vi i øjeblikket er fokuseret på hardwareudvikling og kan ikke allokere nok ressourcer til disse opgaver, hvilket er det, der bragte os til Startup Hackathon.
Forberedelse, data, infrastruktur
Som et resultat tog vi to spor: dataanalyse og ledelsessystem. Ud over vores var der yderligere syv numre fra kollegaer.
Selvom formatet for hackathonet ikke var fastlagt, tænkte vi på at skabe "vores egen atmosfære" med et pointsystem: Deltagerne gør nogle ting, der virker vanskelige og interessante for os, og modtager point for det. Vi havde mange opgaver. Men da vi byggede strukturen af hackathonet, bad andre arrangører om at bringe alt til en fælles form, hvilket vi gjorde.
Så kom vi til følgende skema: fyrene laver en model baseret på deres data, så modtager de vores data, som modellen ikke havde set før, lærer den og begynder at forudsige. Det blev antaget, at alt dette kunne klares på 48 timer, men for os var dette det første hackathon på vores data, og vi kan have overvurderet tidsressourcerne eller graden af parathed af dataene. Ved specialiserede maskinlæringshackathons ville sådan en tidslinje være normen, men vores var ikke sådan.
Vi lossede modulets software og hardware så meget som muligt, og lavede en version af vores enhed specifikt til hackathonet, med en meget enkel og forståelig intern grænseflade, som enhver udvikler kunne understøtte.
For banen baseret på styresystemet var der mulighed for at lave en mobilapplikation. For at forhindre deltagerne i at tude over, hvordan det skulle se ud og spilde ekstra tid, gav vi dem et designlayout af applikationen, superlet, så dem, der ønsker det, simpelthen kunne "strække" de funktioner, de har brug for, på den. . For at være ærlig, forventede vi ikke nogen moralske dilemmaer her, men et af holdene tog det på en sådan måde, at vi begrænsede deres fantasi, vi ville have en færdiglavet løsning gratis og ikke teste dem i praksis. Og de lettede.
Et andet hold valgte at lave en helt anden ansøgning fra bunden, og alt fungerede. Vi insisterede ikke på, at applikationen skulle være præcis sådan her, vi havde bare brug for, at den skulle indeholde nogle elementer, der demonstrerer det tekniske niveau af løsningen: grafer, analyser osv. Det færdige designlayout var også et hint.
Da det ville være for tidskrævende at analysere et live Watts Battery-modul på et hackathon, gav vi deltagerne et færdigt udsnit af data i en måned taget fra vores kunders rigtige moduler (som vi omhyggeligt anonymiserede på forhånd). Da det var juni, var der intet at indarbejde sæsonmæssige ændringer i analysen. Men i fremtiden vil vi tilføje eksterne data til dem, såsom sæsonbestemte og klimatiske funktioner (i dag er dette industristandarden).
Vi ønskede ikke at skabe urealistiske forventninger blandt deltagerne, så i annonceringen af hackathonet sagde vi direkte: arbejdet vil være så tæt som muligt på feltarbejdet: larmende, snavsede data, som ingen specielt forberedte. Men dette havde også en positiv side: I den agile ånd var vi konstant i kontakt med deltagerne og lavede prompte ændringer i opgaven og optagelsesbetingelserne (mere om dette nedenfor).
Derudover gav vi deltagerne adgang til Amazon AWS (så aktivt, at Amazon blokerede en region for os, vil vi finde ud af, hvad vi skal gøre ved det). Der kan du implementere infrastruktur til Internet of Things og, baseret på selv simple Amazon-skabeloner, skabe en fuldgyldig løsning inden for en dag. Men i sidste ende gik absolut alle deres egen vej og gjorde alt på egen hånd til det maksimale. Samtidig lykkedes det nogle at overholde tidsfristen, andre ikke. Et hold, Nubble, brugte Yandex.cloud, nogen rejste det på deres hosting. Vi var endda klar til at give domæner (vi har registreret dem), men de var ikke nyttige.
For at afgøre vinderne i det analytiske spor planlagde vi at sammenligne resultaterne, som vi udarbejdede numeriske målinger til. Men i sidste ende var det ikke nødvendigt at gøre dette, da tre af de fire deltagere af forskellige årsager ikke nåede finalen.
Med hensyn til husholdningsinfrastrukturen hjalp Skolkovo Technopark her ved at give os (gratis) et af sine hyggelige modulopbyggede rum med en videovæg til præsentationer og et par mindre rum til et rekreativt område og til at organisere catering.
Analytics
Opgave: et selvlærende system, der identificerer uregelmæssigheder i forbrug og moduldrift baseret på kontroldata. Vi holdt bevidst formuleringen så generel som muligt, så deltagerne sammen med os kunne tænke over, hvad der kunne gøres ud fra de tilgængelige data.
Specificitet: Det mere komplekse af de to spor. Industrielle data har nogle forskelle fra data i lukkede systemer (for eksempel digital markedsføring). Her skal du forstå den fysiske karakter af de parametre, du forsøger at analysere; at se på alt som abstrakte talserier vil ikke fungere. For eksempel fordelingen af elforbruget i løbet af dagen. Det er ligesom ritualer: den elektriske barbermaskine tændes om morgenen på hverdage, og mixeren tændes i weekenden. Så essensen af selve anomalierne. Og glem ikke, at Watts-batteriet er beregnet til personlig brug, så hver klient vil have deres egne ritualer, og en universel model vil ikke fungere. At finde kendte anomalier i data er ikke engang en opgave; at skabe et system, der autonomt søger efter umærkede anomalier er en anden sag. Alt kan trods alt være en anomali, inklusive den snigende menneskelige faktor. For eksempel var der i vores testdata et tilfælde, hvor systemet blev tvunget af brugeren til batteritilstand. Uden nogen grund gør brugere nogle gange dette (jeg tager forbehold for, at denne bruger tester modulet for os, og det er af denne grund, at han har adgang til manuel kontrol af tilstande; for andre brugere er kontrollen fuldstændig automatisk). Som det er let at forudsige, aflades batteriet i en sådan situation ret aktivt, og hvis belastningen er stor, vil opladningen ophøre, før solen står op, eller en anden energikilde dukker op. I sådanne tilfælde forventer vi at se en form for meddelelse om, at systemets adfærd har afviget fra den normale. Eller personen gik og glemte at slukke for ovnen. Systemet ser, at forbruget normalt på dette tidspunkt af dagen er 500 watt, men i dag - 3,5 tusind - en anomali! Som Denis Matsuev på flyet: "Jeg forstår ikke noget om flymotorer, men på vejen dertil lød motoren anderledes."
Graf over en forudsigelig model på opensource neurale netværk Yandex CatBoost
Hvad har virksomheden egentlig brug for?: selvdiagnosesystem inde i enheden, forudsigende analyse, inklusive uden netværksinfrastruktur (som praksis viser, har ikke alle vores kunder travlt med at forbinde batterier til internettet - for de fleste er det nok til, at alt bare fungerer pålideligt), identifikation af anomalier, hvis natur vi endnu ikke kender , et selvlærende system uden lærer, klyngedannelse, neurale netværk og hele arsenalet af moderne analytiske metoder. Vi skal forstå, at systemet begyndte at opføre sig anderledes, selvom vi ikke ved, hvad der præcist har ændret sig. På selve hackathonet var det meget vigtigt for os at se, at der er fyre, der er klar til at træde ind i industriel analyse eller allerede er i gang med det, og de leder efter nye områder til at anvende deres evner. Først var jeg overrasket over, at der var så mange ansøgere: Det er trods alt et meget specifikt køkken, men efterhånden faldt alle på nær én af de fire deltagere fra, så til en vis grad faldt alt på plads.
Hvorfor er det ikke muligt på nuværende tidspunkt?: Hovedproblemet med datamining-opgaver er ikke nok data. Der er flere dusin Watts-batterienheder i drift rundt om i verden i dag, men mange af dem er ikke forbundet til netværket, så vores data er endnu ikke særlig forskelligartede. Vi har knap nok skrabet to uregelmæssigheder sammen - og dem opstod på prototyper; industrielt Watts-batteri fungerer ganske stabilt. Hvis vi havde en intern maskinlæringsingeniør, og vi vidste - ja, dette kan presses ud af disse data, men vi ønsker at få en bedre forudsigelseskvalitet - ville det være én historie. Men indtil nu har vi ikke gjort noget med disse data. Derudover ville dette kræve en dyb fordybelse af deltagerne i detaljerne i driften af vores produkt; halvanden dag er ikke nok til dette.
Hvordan besluttede du dig?: De satte ikke umiddelbart den nøjagtige endelige opgave. I stedet var vi gennem hele 48 timer i dialog med deltagerne, hvor vi prompte fandt ud af, hvad de kunne få, og hvad de ikke kunne. På baggrund af dette, i kompromisets ånd, blev opgaven afsluttet.
Hvad fik du som resultat?: Vinderne af sporet var i stand til at rydde op i dataene (samtidigt fandt de "funktionerne" ved at beregne nogle parametre, som vi selv ikke havde bemærket før, da vi ikke brugte nogle af dataene til at løse vores problemer) , fremhæve afvigelser fra den forventede opførsel af Watts batterimoduler, og opstil en forudsigelig model, der er i stand til at forudsige energiforbrug med en høj grad af nøjagtighed. Ja, dette er kun et gennemførlighedstrin for at udvikle en industriel løsning; så vil der være brug for ugers omhyggeligt teknisk arbejde, men selv denne prototype, skabt direkte under hackathonet, kan danne grundlag for en rigtig industriel løsning, hvilket er sjældent.
hovedkonklusion: Baseret på de data vi har, er det muligt at opsætte prædiktiv analyse, det antog vi, men havde ikke ressourcerne til at tjekke. Hackathon-deltagerne testede og bekræftede vores hypotese, og vi vil fortsætte med at arbejde med banevinderne om denne opgave.
Graf af en forudsigelig model på opensource neurale netværk Facebook Prophet
Råd for fremtiden: Når du udarbejder en opgave, skal du ikke kun se på din produktionskøreplan, men også på deltagernes interesser. Da vores hackathon ikke har nogen pengepræmier, spiller vi på data scientists naturlige nysgerrighed og ønsket om at løse nye, interessante problemer, hvor ingen endnu har vist noget, eller hvor de kan vise sig bedre end eksisterende resultater. Hvis du med det samme tager hensyn til interessefaktoren, behøver du ikke flytte dit fokus undervejs.
ledelse
Opgave: (applikation), der administrerer et netværk af Watts batterimoduler, med en personlig konto, datalagring i skyen og statusovervågning.
Specificitet: I dette spor ledte vi ikke efter en ny teknisk løsning; vi har selvfølgelig vores egen forbrugergrænseflade. Vi valgte ham til hackathonet for at demonstrere vores systems muligheder, fordybe os i det og tjekke, om samfundet er interesseret i emnet udvikling af smarte systemer og alternativ energi. Vi placerede mobilapplikationen som en mulighed; du kan gøre det eller ikke gøre det efter dit skøn. Men efter vores mening viser det godt, hvordan folk formåede at organisere datalagring i skyen, med adgang fra flere forskellige kilder på én gang.
Hvad har virksomheden egentlig brug for?: et fællesskab af udviklere, der vil komme med forretningsideer, teste hypoteser og skabe arbejdsredskaber til deres implementering.
Hvorfor er det ikke muligt på nuværende tidspunkt?: Markedsvolumen er stadig for lille til den organiske dannelse af et sådant fællesskab.
Hvordan besluttede du dig?: Som en del af et hackathon gennemførte vi en slags fysisk undersøgelse for at se, om det var muligt at komme med ikke bare funktioner, men fuldgyldige forretningsmodeller omkring vores helt specifikke produkt. Desuden, for at folk, der er i stand til at implementere en prototype, kan gøre dette, her - jeg vil ikke fornærme nogen - er det ikke niveauet for programmering af en blinkende LED på Arduino (selvom dette kan gøres med innovationer) , ret specifikke færdigheder kræves her: udvikling af backend- og frontend-systemer, forståelse af principperne for opbygning af skalerbare Internet of Things-systemer.
Hvad fik du som resultat?: to teams foreslog fuldgyldige forretningsideer til deres arbejde: det ene fokuserede mere på det russiske segment, det andet på det udenlandske. Det vil sige, at de i finalen ikke bare fortalte, hvordan de kom med ansøgningen, men i det væsentlige kom til at gøre forretninger omkring Watts. Fyrene skitserede, hvordan de ser brugen af Watts i flere forretningsmodeller, leverede statistikker, viste, hvilke regioner der har hvilke problemer, hvilke love der vedtages hvor, skitserede den globale tendens: det er umoderne at mine bitcoins, det er på mode at mine kilowatt. De kom bevidst til alternativ energi, som vi virkelig kunne lide. Det faktum, at deltagerne udover dette var i stand til at skabe en fungerende teknisk løsning, tyder på, at de selvstændigt kan lancere en startup.
hovedkonklusion: Der er teams klar til at tage Watts Battery som grundlag for deres forretningsmodel, udvikle den og blive partnere/ledsagere af virksomheden. Nogle af dem ved endda, hvordan man identificerer MVP'en for en forretningsidé og arbejder på den først, noget der mangler overalt i branchen i dag. Folk forstår ikke, hvornår de skal stoppe, hvornår de skal frigive en løsning til markedet, om end tidligt, men det virker. Faktisk slutter stadiet med at polere løsningen ofte ikke, teknisk set krydser løsningen grænsen for rimelig kompleksitet, den kommer ind på markedet overbelastet, det er ikke længere klart, hvad den oprindelige idé var, hvad kundemålretning er, hvad forretningsmodeller er. inkluderet. Som i vittigheden om Akunin, der skrev en anden bog, mens han signerede den forrige for nogen. Men her blev det gjort i sin reneste form: her er et diagram, her er en tæller, her er indikatorer, her er en forudsigelse - det er alt, intet andet er nødvendigt for at køre det. Med dette kan du gå til en investor og modtage penge til at starte en virksomhed. De, der fandt denne balance, kom ud af banen som vindere.
Råd for fremtiden: ved næste hackathon (vi planlægger det ), måske giver det mening at eksperimentere med hardware. Vi har vores egen hardwareudvikling (en af fordelene ved Watts), vi kontrollerer fuldt ud produktionen og testningen af alt, hvad vi laver, men vi har ikke nok ressourcer til at teste nogle "hardware"-hypoteser. Det kan meget vel være, at der i samfundet af system- og lavniveau-programmører og hardwareudviklere er dem, der vil hjælpe os med dette og i fremtiden vil blive vores partner på dette område.
Mennesker
Ved hackathonet forventede vi dem, der ønsker at prøve sig inden for et nyt felt (for eksempel kandidater fra forskellige programmeringsskoler) frem for dem, der specialiserer sig i denne form for udvikling. Men alligevel forventede vi, at de inden hackathonet ville lave lidt forberedende arbejde, læse om hvordan energiforbrug forudsiges generelt og hvordan Internet of Things-systemer fungerer. Så alle kommer ikke bare for sjov, på udkig efter interessante data og opgaver, men også med en foreløbig fordybelse i fagområdet. For vores del forstår vi, at det til dette er nødvendigt på forhånd at offentliggøre de tilgængelige data, deres beskrivelse og mere præcise krav til resultatet, offentliggøre API-moduler mv.
Alle havde omtrent det samme teknologiske niveau, plus eller minus de samme muligheder. På den baggrund var harmoniniveauet ikke den sidste faktor. En del hold skød ikke, fordi de ikke klart kunne opdele sig selv i arbejdsområder. Der var også dem, hvor en person stod for hele udviklingen, resten havde travlt med at forberede præsentationen, i andre fik nogen opgaver, som de var i gang med, sandsynligvis for første gang i deres liv.
De fleste af deltagerne var unge, det betyder ikke, at der ikke var stærke maskinlæringsingeniører og udviklere blandt dem. De fleste kom i hold; der var praktisk talt ingen personer. Alle drømte om at vinde, nogen ønskede at finde et job i fremtiden, omkring 20% har allerede fundet et, jeg tror, dette tal vil vokse.
Vi havde ikke nok hardware-nørder, men vi håber at kompensere for det ved det andet hackathon.
Hackathon fremskridt
Som jeg skrev ovenfor, var vi sammen med deltagerne i det meste af hackathonets 48 timer, og vi overvågede deres succeser ved checkpoints og forsøgte at tilpasse opgaven og betingelserne for at acceptere det første, analytiske spor, så på den ene side deltagerne kunne gennemføre det på den resterende tid, og til gengæld var det interessant for os.
Den sidste afklaring af opgaven blev lavet et sted omkring det sidste kontrolpunkt, lørdag eftermiddag (finalen var planlagt til søndag aften). Vi forenklede det hele lidt mere: Vi fjernede kravet om at genberegne modellen på nye data, og efterlod de data, som holdene allerede arbejdede med. Sammenligning af målinger gav os ikke længere noget, de havde allerede færdige resultater baseret på de tilgængelige data, og på den anden dag var fyrene allerede trætte. Derfor besluttede vi at torturere dem mindre.
Tre ud af fire deltagere nåede dog ikke finalen. Det ene hold indså allerede i starten, at de var mere interesserede i vores kollegaers spor, det andet, lige før finalen, indså, at de under behandlingsprocessen havde filtreret de nødvendige data fra før tid og nægtede at præsentere deres arbejde.
"21 (Wet Hair Effect)"-holdet deltog i begge vores numre til det sidste. De ønskede at dække alt på én gang: maskinlæring, udvikling, applikation og hjemmeside. Indtil vi truede dem med tilbagetrækning i sidste øjeblik, mente de, at de gjorde alt i tide, selvom det allerede ved det andet kontrolpunkt var tydeligt, at med det vigtigste - maskinlæring - kunne de ikke gøre væsentlige fremskridt: de klarede generelt den anden blok, men kunne ikke forudsige elforbruget var ikke klar. Som et resultat, da vi bestemte minimumsopgaven for at kvalificere sig til det første, valgte de stadig det andet spor.
Fit-predict havde en afbalanceret sammensætning skræddersyet til dataanalyse, så de var i stand til at overkomme alt. Det var bemærkelsesværdigt, at fyrene var interesserede i at "røre" rigtige industrielle data. De koncentrerede sig straks om det vigtigste: at analysere, rense dataene, håndtere enhver anomali. At de var i stand til at bygge en fungerende model under hackathonet er en stor præstation. I praksis tager dette normalt uger: mens dataene bliver renset, mens de dykker ned i det. Derfor vil vi helt sikkert arbejde sammen med dem.
I andet spor (ledelse) forventede vi, at alle gjorde alt på en halv dag og kom og spurgte for at gøre opgaven sværere. I praksis havde vi knap nok tid til at klare den grundlæggende opgave. Vi arbejdede på JS og Python, som afspejler branchens nuværende tilstand.
Også her blev resultaterne opnået af velkoordinerede teams, hvor arbejdsdelingen var bygget op, det var tydeligt, hvem der lavede hvad.
Det tredje hold, FSociety, så ud til at have en løsning, men til sidst besluttede de sig for ikke at vise deres udvikling, de sagde, at de ikke anså det for at virke. Vi respekterer dette og skændtes ikke.
Vinderen blev holdet “Strippers from Baku”, som var i stand til at stoppe sig selv, ikke for at jage efter “trinkets”, men for at skabe en MVP, der ikke skammer sig over at vise, og som er tydelig, at den kan videreudvikles og skaleres. Vi fortalte dem straks, at vi ikke var så interesserede i yderligere muligheder. Hvis de ønsker registrering via QR-kode, ansigtsgenkendelse, så lad dem først lave grafer i applikationen, og tag derefter de valgfrie op.
I dette nummer gik "Wet Hair" selvsikkert ind i finalen, og vi diskuterede yderligere samarbejde med dem og "Hustlers." Sidstnævnte har vi allerede mødt i det nye år.
Jeg håber alt lykkes, og vi glæder os til at se alle til det andet hackathon i marts!
Kilde: www.habr.com