I desember i fjor holdt vi vårt eget startup hackathon med seks andre Skolkovo-selskaper. Uten bedriftssponsorer eller ekstern støtte, samlet vi to hundre deltakere fra 20 byer i Russland gjennom innsatsen fra programmeringsfellesskapet. Nedenfor vil jeg fortelle deg hvordan vi lyktes, hvilke fallgruver vi møtte underveis, og hvorfor vi umiddelbart begynte å samarbeide med et av vinnerlagene.
Grensesnitt for applikasjonen som kontrollerer Watts Battery-moduler fra finalistene på banen, "Wet Hair"
selskap
Vårt firma Watts Battery lager modulære bærbare kraftstasjoner. Produktet er en bærbar kraftstasjon 46x36x11 cm, i stand til å levere fra 1,5 til 15 kilowatt i timen. Fire slike moduler kan gi energiforbruket til et lite landsted i to dager.
Selv om vi begynte å sende produksjonsprøver i fjor, er Watts Battery etter alt å dømme en oppstart. Selskapet ble grunnlagt i 2016 og har siden samme år vært hjemmehørende i Skolkovo Energy Efficient Technologies Cluster. I dag har vi 15 ansatte og et enormt etterslep av ting som vi ønsker å gjøre på et tidspunkt, men akkurat nå er det ingen tid for det.
Dette inkluderer også rene programvareoppgaver. Hvorfor?
Hovedoppgaven til modulen er å gi uavbrutt, balansert energiforsyning til en optimal kostnad. Hvis du opplever strømbrudd på grunn av årsaker utenfor din kontroll, bør du alltid ha en reserve for å fullføre den nødvendige nettverksbelastningen så lenge strømbruddet varer. Og når strømforsyningen er god, kan du bruke solenergi for å spare penger.
Det enkleste alternativet er at du kan lade batteriet fra solen på dagtid og bruke det om kvelden, men akkurat til det nivået som er nødvendig for at du i tilfelle strømbrudd ikke skal stå uten strøm. Så du vil aldri finne deg selv i en situasjon der du drev belysningen fra et batteri hele kvelden (fordi det er billigere), men om natten gikk strømmen og kjøleskapet ditt tint.
Det er klart at en person sjelden er i stand til å forutsi med stor nøyaktighet mengden elektrisitet han trenger, men et system bevæpnet med en prediktiv modell kan. Derfor er maskinlæring som sådan et av våre prioriterte områder. Det er bare det at vi for øyeblikket er fokusert på maskinvareutvikling og kan ikke allokere nok ressurser til disse oppgavene, som er det som førte oss til Startup Hackathon.
Forberedelse, data, infrastruktur
Som et resultat tok vi to spor: dataanalyse og styringssystem. I tillegg til vårt var det sju flere spor fra kolleger.
Selv om formatet på hackathonet ikke var bestemt, tenkte vi å skape "vår egen atmosfære", med et poengsystem: deltakerne gjør noen ting som virker vanskelige og interessante for oss, og får poeng for det. Vi hadde mange oppgaver. Men mens vi bygde strukturen til hackathonet, ba andre arrangører om å bringe alt til en felles form, noe vi gjorde.
Så kom vi til følgende opplegg: gutta lager en modell basert på dataene deres, så mottar de dataene våre, som modellen ikke hadde sett før, lærer den og begynner å forutsi. Det ble antatt at alt dette kunne gjøres på 48 timer, men for oss var dette det første hackathonet på dataene våre, og vi kan ha overvurdert tidsressursene eller graden av beredskap til dataene. Ved spesialiserte maskinlæringshackathons ville en slik tidslinje være normen, men vår var ikke slik.
Vi lastet ut programvaren og maskinvaren til modulen så mye som mulig, og laget en versjon av enheten vår spesielt for hackathon, med et veldig enkelt og forståelig internt grensesnitt som enhver utvikler kunne støtte.
For sporet basert på kontrollsystemet var det mulighet for å lage en mobilapplikasjon. For å hindre deltakerne i å gruble seg til hvordan det skulle se ut og kaste bort ekstra tid, ga vi dem et designoppsett av applikasjonen, superlett, slik at de som ønsker det ganske enkelt kan "strekke" funksjonene de trenger på den . For å være ærlig forventet vi ingen moralske dilemmaer her, men et av teamene tok det på en slik måte at vi begrenset fantasien deres, vi ønsket å få en ferdig løsning gratis, og ikke teste dem i praksis. Og de tok av.
Et annet team valgte å lage en helt annen søknad fra bunnen av, og alt ordnet seg. Vi insisterte ikke på at applikasjonen skulle være akkurat slik, vi trengte bare at den skulle inneholde noen elementer som demonstrerer det tekniske nivået til løsningen: grafer, analyser osv. Det ferdige designoppsettet var også et hint.
Siden det ville være for tidkrevende å analysere en levende Watts-batterimodul på et hackathon, ga vi deltakerne et ferdig stykke data for en måned hentet fra kundenes virkelige moduler (som vi nøye anonymiserte på forhånd). Siden det var juni, var det ingenting å ta med sesongmessige endringer i analysen. Men i fremtiden vil vi legge til eksterne data til dem, for eksempel sesongmessige og klimatiske egenskaper (i dag er dette industristandarden).
Vi ønsket ikke å skape urealistiske forventninger blant deltakerne, så i kunngjøringen av hackathonet sa vi direkte: arbeidet vil være så nært feltarbeidet som mulig: bråkete, skitne data, som ingen spesielt forberedte. Men dette hadde også en positiv side: I smidighetens ånd var vi hele tiden i kontakt med deltakerne, og gjorde raskt endringer i oppgaven og opptaksvilkårene (mer om dette nedenfor).
I tillegg ga vi deltakerne tilgang til Amazon AWS (så aktivt at Amazon blokkerte én region for oss, vi vil finne ut hva vi skal gjøre med det). Der kan du distribuere infrastruktur for tingenes internett og, basert på selv enkle Amazon-maler, lage en fullverdig løsning i løpet av en dag. Men til slutt gikk absolutt alle sin egen vei, og gjorde alt på egenhånd til det maksimale. Samtidig klarte noen å overholde fristen, andre ikke. Ett team, Nubble, brukte Yandex.cloud, noen tok det opp på hostingen deres. Vi var til og med klare til å gi domener (vi har registrerte), men de var til ingen nytte.
For å avgjøre vinnerne i det analytiske sporet, planla vi å sammenligne resultatene, som vi utarbeidet numeriske beregninger for. Men til slutt var det ikke nødvendig å gjøre dette, siden tre av de fire deltakerne av ulike årsaker ikke kom til finalen.
Når det gjelder husholdningsinfrastrukturen, hjalp Skolkovo Technopark til her ved å gi oss (gratis) et av sine koselige modulrom med en videovegg for presentasjoner og et par mindre rom for et rekreasjonsområde og for å organisere catering.
Analytics
Oppgave: et selvlærende system som identifiserer uregelmessigheter i forbruk og moduldrift basert på kontrolldata. Vi har bevisst holdt ordlyden så generell som mulig slik at deltakerne sammen med oss kunne tenke over hva som kunne gjøres basert på tilgjengelige data.
Spesifisitet: Det mer komplekse av de to sporene. Industrielle data har noen forskjeller fra data i lukkede systemer (for eksempel digital markedsføring). Her må du forstå den fysiske naturen til parameterne du prøver å analysere; å se på alt som abstrakte tallserier vil ikke fungere. For eksempel fordelingen av strømforbruket gjennom dagen. Det er som ritualer: den elektriske barberhøvelen slås på om morgenen på hverdager, og mikseren slås på i helgene. Så essensen av anomaliene selv. Og ikke glem at Watts-batteriet er beregnet for personlig bruk, så hver klient vil ha sine egne ritualer, og en universell modell vil ikke fungere. Å finne kjente anomalier i data er ikke engang en oppgave; å lage et system som autonomt søker etter umerkede anomalier er en annen sak. Tross alt kan alt være en anomali, inkludert den lumske menneskelige faktoren. For eksempel, i våre testdata var det et tilfelle der systemet ble tvunget av brukeren til batterimodus. Uten noen grunn gjør brukere dette noen ganger (jeg tar forbehold om at denne brukeren tester modulen for oss, og det er av denne grunn at han har tilgang til manuell kontroll av moduser; for andre brukere er kontrollen helt automatisk). Som det er lett å forutsi, utlades batteriet i en slik situasjon ganske aktivt, og hvis belastningen er stor, vil ladningen avsluttes før solen står opp eller en annen energikilde dukker opp. I slike tilfeller forventer vi å se en form for melding om at systematferden har avviket fra den normale. Eller personen gikk og glemte å slå av ovnen. Systemet ser at vanligvis på denne tiden av dagen er forbruket 500 watt, men i dag - 3,5 tusen - en anomali! Som Denis Matsuev på flyet: "Jeg forstår ingenting om flymotorer, men på veien dit hørtes motoren annerledes ut."
Graf over en prediktiv modell på det åpne kildekode-nevrale nettverket Yandex CatBoost
Hva trenger bedriften egentlig?: selvdiagnostisk system inne i enheten, prediktiv analyse, inkludert uten nettverksinfrastruktur (som praksis viser, har ikke alle våre kunder det travelt med å koble batterier til Internett - for de fleste er det nok til at alt bare fungerer pålitelig), identifisering av anomalier, som vi ennå ikke kjenner til, et selvlærende system uten lærer, klynging, nevrale nettverk og hele arsenalet av moderne analytiske metoder. Vi må forstå at systemet begynte å oppføre seg annerledes, selv om vi ikke vet nøyaktig hva som har endret seg. På selve hackathonet var det veldig viktig for oss å se at det er gutter som er klare til å gå inn i industriell analyse eller allerede er i det, og de leter etter nye områder å bruke evnene sine på. Først ble jeg overrasket over at det var så mange søkere: Dette er tross alt et veldig spesifikt kjøkken, men etter hvert falt alle unntatt én av de fire deltakerne fra, så til en viss grad falt alt på plass.
Hvorfor er det ikke mulig på dette stadiet?: Hovedproblemet med datautvinningsoppgaver er ikke nok data. Det er flere dusin Watts-batterienheter i drift rundt om i verden i dag, men mange av dem er ikke koblet til nettverket, så dataene våre er ennå ikke veldig forskjellige. Vi skrapte knapt sammen to anomalier - og de skjedde på prototyper; industrielle Watts-batterier fungerer ganske stabilt. Hvis vi hadde en intern maskinlæringsingeniør, og vi visste – ja, dette kan presses ut av disse dataene, men vi ønsker å få en bedre kvalitet på prediksjon – ville det vært én historie. Men til nå har vi ikke gjort noe med disse dataene. I tillegg vil dette kreve en dyp fordypning av deltakerne i detaljene rundt driften av produktet vårt; halvannen dag er ikke nok for dette.
Hvordan bestemte du deg?: De satte ikke den nøyaktige siste oppgaven umiddelbart. I stedet, gjennom hele 48 timer, var vi i dialog med deltakerne, og fant raskt ut hva de kunne få og hva de ikke kunne. På bakgrunn av dette, i kompromissens ånd, ble oppgaven ferdigstilt.
Hva fikk du som resultat?: Vinnerne av sporet var i stand til å rydde opp i dataene (samtidig fant de "funksjonene" ved å beregne noen parametere som vi selv ikke hadde lagt merke til før, siden vi ikke brukte noen av dataene til å løse problemene våre) , fremhev avvik fra forventet oppførsel til Watts batterimoduler, og sett opp en prediktiv modell som kan forutsi energiforbruk med høy grad av nøyaktighet. Ja, dette er bare et gjennomførbarhetsstadium for å utvikle en industriell løsning; da vil det være behov for uker med møysommelig teknisk arbeid, men selv denne prototypen, opprettet direkte under hackathonet, kan danne grunnlaget for en ekte industriell løsning, noe som er sjeldent.
hovedkonklusjon: Basert på dataene vi har er det mulig å sette opp prediktiv analyse, vi antok dette, men hadde ikke ressurser til å sjekke. Hackathon-deltakerne testet og bekreftet hypotesen vår, og vi vil fortsette å jobbe med banevinnerne om denne oppgaven.
Graf av en prediktiv modell på opensource nevrale nettverket Facebook Prophet
Råd for fremtiden: når du utarbeider en oppgave, må du ikke bare se på produksjonsveikartet, men også på deltakernes interesse. Siden hackathonet vårt ikke har noen pengepremier, spiller vi på dataforskernes naturlige nysgjerrighet og ønsket om å løse nye, interessante problemer der ingen ennå har vist noe eller hvor de kan vise seg bedre enn eksisterende resultater. Hvis du umiddelbart tar hensyn til faktoren av interesse, trenger du ikke å skifte fokus underveis.
administrasjon
Oppgave: (applikasjon) som administrerer et nettverk av Watts batterimoduler, med en personlig konto, datalagring i skyen og statusovervåking.
Spesifisitet: i dette sporet var vi ikke ute etter noen ny teknisk løsning; vi har selvfølgelig vårt eget forbrukergrensesnitt. Vi valgte ham til hackathon for å demonstrere egenskapene til systemet vårt, fordype oss i det og sjekke om samfunnet er interessert i temaet utvikling for smarte systemer og alternativ energi. Vi posisjonerte mobilapplikasjonen som et alternativ; du kan gjøre det eller ikke gjøre det etter eget skjønn. Men etter vår mening viser det godt hvordan folk klarte å organisere datalagring i skyen, med tilgang fra flere forskjellige kilder samtidig.
Hva trenger bedriften egentlig?: et fellesskap av utviklere som vil komme opp med forretningsideer, teste hypoteser og lage arbeidsverktøy for implementering av dem.
Hvorfor er det ikke mulig på dette stadiet?: Markedsvolumet er fortsatt for lite for den organiske dannelsen av et slikt fellesskap.
Hvordan bestemte du deg?: Som en del av et hackathon gjennomførte vi en slags fysiskhetsstudie for å se om det var mulig å komme opp med ikke bare funksjoner, men fullverdige forretningsmodeller rundt vårt helt spesifikke produkt. Dessuten, for at folk som er i stand til å implementere en prototype skal gjøre dette, her - jeg vil ikke fornærme noen - er dette ikke nivået for å programmere en blinkende LED på Arduino (selv om dette kan gjøres med innovasjoner) , ganske spesifikke ferdigheter kreves her: utvikling av backend- og frontend-systemer, forståelse av prinsippene for å bygge skalerbare Internet of Things-systemer.
Hva fikk du som resultat?: to team foreslo fullverdige forretningsideer for sitt arbeid: ett fokuserte mer på det russiske segmentet, det andre på det utenlandske. Det vil si at i finalen fortalte de ikke bare hvordan de kom opp med søknaden, men kom i hovedsak for å gjøre forretninger rundt Watts. Gutta skisserte hvordan de ser på bruken av Watts i flere forretningsmodeller, ga statistikk, viste hvilke regioner som har hvilke problemer, hvilke lover er vedtatt hvor, skisserte den globale trenden: det er umoderne å utvinne bitcoins, det er mote å utvinne kilowatt. De kom bevisst til alternativ energi, som vi likte veldig godt. At deltakerne i tillegg til dette klarte å lage en fungerende teknisk løsning, tyder på at de selvstendig kan starte en startup.
hovedkonklusjon: Det er team som er klare til å ta Watts Battery som grunnlag for sin forretningsmodell, utvikle den og bli partnere/ledsager til selskapet. Noen av dem vet til og med hvordan de skal identifisere MVP-en til en forretningsidé og jobbe med den først, noe som mangler overalt i bransjen i dag. Folk forstår ikke når de skal stoppe, når de skal slippe en løsning til markedet, om enn tidlig, men fungerer. Faktisk slutter ikke stadiet med å polere løsningen, teknisk sett krysser løsningen grensen for rimelig kompleksitet, den kommer overbelastet inn i markedet, det er ikke lenger klart hva den opprinnelige ideen var, hva kundemålretting er, hva forretningsmodeller er. inkludert. Som i vitsen om Akunin, som skrev en annen bok mens han signerte den forrige for noen. Men her ble det gjort i sin reneste form: her er et diagram, her er en teller, her er indikatorer, her er en prediksjon - det er alt, ingenting annet er nødvendig for å kjøre det. Med dette kan du gå til en investor og motta penger for å starte en bedrift. De som fant denne balansen kom ut av banen som vinnere.
Råd for fremtiden: ved neste hackathon (vi planlegger det ), kanskje det er fornuftig å eksperimentere med maskinvare. Vi har vår egen maskinvareutvikling (en av fordelene med Watts), vi kontrollerer produksjonen og testingen av alt vi gjør fullt ut, men vi har ikke nok ressurser til å teste noen "hardware"-hypoteser. Det kan godt hende at det i fellesskapet av system- og lavnivåprogrammerere og maskinvareutviklere er de som vil hjelpe oss med dette og i fremtiden vil bli vår partner på dette området.
Folk
På hackathon forventet vi de som ønsker å prøve seg på et nytt felt (for eksempel nyutdannede fra ulike programmeringsskoler) i stedet for de som spesialiserer seg på denne typen utvikling. Men allikevel forventet vi at de før hackathonet ville gjøre et lite forberedende arbeid, lese om hvordan energiforbruk forutses generelt og hvordan tingenes internett-systemer fungerer. Slik at alle kommer ikke bare for moro skyld, på jakt etter interessante data og oppgaver, men også med en foreløpig fordyping i fagområdet. For vår del forstår vi at for dette er det nødvendig å publisere tilgjengelige data på forhånd, deres beskrivelse og mer presise krav til resultatet, publisere API-moduler, etc.
Alle hadde omtrent samme teknologiske nivå, pluss eller minus samme evner. På denne bakgrunnen var ikke harmoninivået den siste faktoren. En del lag skjøt ikke fordi de ikke klarte å dele seg inn i arbeidsområder. Det var også de der en person gjorde all utviklingen, resten var opptatt med å forberede presentasjonen, i andre fikk noen oppgaver som de gjorde, sannsynligvis for første gang i livet.
De fleste av deltakerne var unge, dette betyr ikke at det ikke var noen sterke maskinlæringsingeniører og utviklere blant dem. De fleste kom i lag; det var praktisk talt ingen individer. Alle drømte om å vinne, noen ønsket å finne en jobb i fremtiden, omtrent 20% har allerede funnet en, jeg tror dette tallet vil vokse.
Vi hadde ikke nok maskinvarenerder, men vi håper å gjøre opp for det på det andre hackathonet.
Hackathon fremgang
Som jeg skrev ovenfor, var vi sammen med deltakerne i det meste av de 48 timene av hackathonet, og vi overvåket suksessene deres ved sjekkpunkter, og prøvde å tilpasse oppgaven og betingelsene for å akseptere det første, analytiske sporet slik at på den ene siden deltakerne kunne fullføre den på gjenværende tid, og på den annen side var den av interesse for oss.
Den siste avklaringen til oppgaven ble gjort et sted rundt siste sjekkpunkt, lørdag ettermiddag (finalen var berammet til søndag kveld). Vi forenklet alt litt mer: vi fjernet kravet om å beregne modellen på nytt på nye data, og la dataene som teamene allerede jobbet med. Sammenligning av beregninger ga oss ikke lenger noe, de hadde allerede ferdige resultater basert på tilgjengelige data, og på den andre dagen var gutta allerede slitne. Derfor bestemte vi oss for å torturere dem mindre.
Tre av fire deltakere kom imidlertid ikke til finalen. Det ene teamet skjønte allerede i starten at de var mer interessert i sporet til kollegene våre, det andre, rett før finalen, innså at de under behandlingsprosessen hadde filtrert ut nødvendige data på forhånd og nektet å presentere arbeidet sitt.
"21 (Wet Hair Effect)"-teamet deltok i begge sporene våre helt til slutten. De ønsket å dekke alt på en gang: maskinlæring, utvikling, applikasjon og nettside. Inntil vi truet dem med tilbaketrekning i siste øyeblikk, trodde de at de gjorde alt i tide, selv om det allerede ved det andre sjekkpunktet var åpenbart at med det viktigste - maskinlæring - kunne de ikke gjøre betydelige fremskritt: de taklet generelt den andre blokken, men kunne ikke forutsi strømforbruket var ikke klar. Som et resultat, da vi bestemte minimumsoppgaven for å kvalifisere oss til det første, valgte de fortsatt det andre sporet.
Fit-predict hadde en balansert sammensetning skreddersydd for dataanalyse, slik at de var i stand til å overvinne alt. Det var merkbart at gutta var interessert i å "røre" ekte industrielle data. De konsentrerte seg umiddelbart om det viktigste: å analysere, rense dataene, håndtere enhver anomali. Det at de klarte å bygge en fungerende modell under hackathonet er en stor prestasjon. I praksis tar dette vanligvis uker: mens dataene blir renset, mens de fordyper seg i dem. Derfor vil vi definitivt samarbeide med dem.
I andre spor (ledelse) forventet vi at alle skulle gjøre alt på en halv dag og komme og spørre for å gjøre oppgaven vanskeligere. I praksis hadde vi knapt tid til å fullføre grunnoppgaven. Vi jobbet med JS og Python, som gjenspeiler den nåværende tilstanden i bransjen.
Også her ble resultatene oppnådd av godt koordinerte team der arbeidsdelingen var bygget opp, det var tydelig hvem som gjorde hva.
Det tredje teamet, FSociety, så ut til å ha en løsning, men til slutt bestemte de seg for ikke å vise utviklingen sin, de sa at de ikke anså det for å fungere. Vi respekterer dette og kranglet ikke.
Vinneren ble laget “Strippers from Baku”, som klarte å stoppe seg selv, ikke for å jage etter “pynt”, men for å skape en MVP som ikke skammer seg over å vise og som er tydelig på at den kan videreutvikles og skaleres. Vi fortalte dem umiddelbart at vi ikke var så interessert i flere muligheter. Ønsker de registrering via QR-kode, ansiktsgjenkjenning, la dem først lage grafer i applikasjonen, og deretter ta på seg de valgfrie.
I dette sporet gikk «Wet Hair» selvsikkert inn i finalen, og vi diskuterte videre samarbeid med dem og «Hustlers». Sistnevnte har vi allerede møtt på nyåret.
Jeg håper alt ordner seg, og vi gleder oss til å se alle på det andre hackathonet i mars!
Kilde: www.habr.com