Tavaly decemberben megtartottuk saját startup hackathonunkat hat másik skolkovói céggel. Vállalati szponzorok és külső támogatás nélkül kétszáz résztvevőt gyűjtöttünk össze Oroszország 20 városából a programozói közösség erőfeszítéseivel. Az alábbiakban elmondom, hogyan sikerült, milyen buktatókkal találkoztunk az út során, és miért kezdtünk el azonnal együttműködni az egyik győztes csapattal.
Az alkalmazás felülete, amely a Watts Battery moduljait vezérli a szám döntősei közül, a „Wet Hair”
társaság
Cégünk, a Watts Battery moduláris, hordozható erőműveket hoz létre. A termék egy 46x36x11 cm-es hordozható erőmű, amely óránként 1,5-15 kilowatt leadására képes. Négy ilyen modul képes egy kis vidéki ház energiafogyasztását két napra biztosítani.
Bár a gyártási minták szállítását tavaly kezdtük meg, a Watts Battery minden tekintetben induló vállalkozás. A cég 2016-ban alakult, és ugyanettől az évtől a Skolkovo Energy Efficient Technologies Klaszter rezidense. Ma már 15 alkalmazottunk van, és hatalmas lemaradásunk van, amit valamikor szeretnénk elvégezni, de jelenleg nincs ideje arra.
Ez magában foglalja a tisztán szoftveres feladatokat is. Miért?
A modul fő feladata a zavartalan, kiegyensúlyozott energiaellátás biztosítása optimális költséggel. Ha Önön kívül eső okok miatt áramkimaradást tapasztal, mindig legyen tartaléka a szükséges hálózati terhelés teljes ellátásához a kimaradás idejére. Ha pedig jó az áramellátás, akkor pénzt takaríthat meg napenergiával.
A legegyszerűbb megoldás, hogy napközben töltheted az akkumulátort, este pedig használhatod, de pontosan addig a szintig, amennyire szükség van, hogy áramszünet esetén se maradj áram nélkül. Így soha nem fog olyan helyzetbe kerülni, hogy egész este akkumulátorról táplálta a világítást (mert olcsóbb), de éjszaka elment az áram, és leolvadt a hűtőszekrénye.
Nyilvánvaló, hogy az ember ritkán képes nagy pontossággal megjósolni a számára szükséges villamos energia mennyiségét, de egy prediktív modellel felvértezett rendszer igen. Ezért a gépi tanulás mint olyan az egyik kiemelt területünk. Csupán arról van szó, hogy jelenleg a hardverfejlesztésre koncentrálunk, és nem tudunk elegendő erőforrást allokálni ezekre a feladatokra, ez vezetett el minket a Startup Hackathonhoz.
Előkészítés, adatok, infrastruktúra
Ennek eredményeként két irányvonalat választottunk: adatelemzést és menedzsmentrendszert. A miénken kívül még hét szám volt a kollégáktól.
Míg a hackathon formátuma nem volt meghatározva, a „saját atmoszféra” kialakításában gondolkodtunk, pontrendszerrel: a résztvevők olyan dolgokat csinálnak, amelyek számunkra nehéznek és érdekesnek tűnnek, pontokat kapva érte. Rengeteg feladatunk volt. Ám miközben felépítettük a hackathon felépítését, a többi szervező azt kérte, hogy mindent közös formába hozzunk, ami sikerült is.
Aztán a következő sémához jutottunk: a srácok az adataik alapján modellt készítenek, majd megkapják az adatainkat, amiket a modell még nem látott, megtanulja és elkezd jósolni. Feltételezték, hogy mindezt 48 óra alatt meg lehet tenni, de számunkra ez volt az első hackathon az adatainkon, és lehet, hogy túlbecsültük az időforrásokat vagy az adatok készültségi fokát. A speciális gépi tanulási hackathonokon ilyen idővonal lenne a megszokott, de nálunk nem ilyen volt.
A modul szoftverét és hardverét a lehetőségekhez mérten kipakoltuk, és a készülékünkből egy kifejezetten a hackathonra készült verziót készítettünk, nagyon egyszerű és érthető belső felülettel, amit bármelyik fejlesztő támogatni tudott.
Az irányítási rendszerre épülő pályához lehetőség volt mobil alkalmazás készítésére. Annak elkerülése érdekében, hogy a résztvevők azon törjenek a fejükben, hogy hogyan nézzen ki, és ne veszítsenek extra időt, egy szuperkönnyű tervezési elrendezést adtunk nekik az alkalmazásból, hogy aki akarja, egyszerűen „ráfeszíthesse” a szükséges funkciókat. . Őszintén szólva nem számítottunk morális dilemmára, de az egyik csapat úgy vette a dolgot, hogy korlátoztuk a képzeletüket, ingyen akartunk egy kész megoldást kapni, nem pedig tesztelni őket. gyakorlatban. És felszálltak.
Egy másik csapat úgy döntött, hogy egy teljesen más alkalmazást készít a semmiből, és minden sikerült. Nem ragaszkodtunk ahhoz, hogy az alkalmazás pontosan ilyen legyen, csak arra volt szükség, hogy tartalmazzon néhány olyan elemet, amely a megoldás technikai színvonalát mutatja: grafikonok, elemzések stb. A kész tervezési elrendezés is utalás volt.
Mivel egy élő Watts Battery modul elemzése egy hackathonon túl időigényes lenne, egy hónapra kész adatszeletet adtunk a résztvevőknek ügyfeleink valós moduljaiból (amelyeket előzetesen gondosan anonimizáltunk). Mivel június volt, a szezonális változásokat nem lehetett beépíteni az elemzésbe. De a jövőben külső adatokat is hozzáadunk hozzájuk, például szezonális és éghajlati jellemzőket (ma ez az iparági szabvány).
Nem akartunk irreális elvárásokat kelteni a résztvevők között, ezért a hackathon kiírásában egyenesen azt mondtuk: a munka a lehető legközelebb lesz a terepmunkához: zajos, koszos adatok, amelyeket külön senki nem készített elő. De ennek volt egy pozitív oldala is: az agilis jegyében folyamatosan kapcsolatban voltunk a résztvevőkkel, azonnal változtattunk a feladaton és a felvételi feltételeken (erről lentebb).
Ezenkívül hozzáférést biztosítottunk a résztvevőknek az Amazon AWS-hez (olyan aktívan, hogy az Amazon letiltott egy régiót számunkra, majd kitaláljuk, mit tegyünk vele). Ott telepítheti a Dolgok Internetének infrastruktúráját, és akár egyszerű Amazon-sablonok alapján is egy nap alatt teljes értékű megoldást hozhat létre. De végül abszolút mindenki a maga útját járta, mindent a maga erejéből csinált meg maximálisan. Ugyanakkor egyeseknek sikerült betartani a határidőt, másoknak nem. Az egyik csapat, a Nubble a Yandex.cloudot használta, valaki felvetette a tárhelyén. Készek voltunk még domaint is adni (van regisztrált is), de nem voltak hasznosak.
Az elemző pálya győzteseinek meghatározásához az eredmények összehasonlítását terveztük, amelyhez számszerű mérőszámokat készítettünk. De végül erre nem volt szükség, hiszen különböző okok miatt a négy résztvevő közül három nem jutott be a döntőbe.
Ami a háztartási infrastruktúrát illeti, itt a Skolkovo Technopark segített nekünk (ingyenesen) az egyik hangulatos moduláris szobáját, videófallal prezentációkhoz, valamint néhány kisebb helyiséget rekreációs területnek és vendéglátás megszervezéséhez.
Analitika
Feladat: öntanuló rendszer, amely vezérlési adatok alapján azonosítja a fogyasztás és a modul működésének anomáliáit. Szándékosan megőriztük a megfogalmazást a lehető legáltalánosabbnak, hogy a résztvevők velünk együtt átgondolhassák, mit lehetne tenni a rendelkezésre álló adatok alapján.
Sajátosság: A két sáv közül az összetettebb. Az ipari adatok némileg eltérnek a zárt rendszerek adataitól (például digitális marketing). Itt meg kell értened az elemezni kívánt paraméterek fizikai természetét; ha mindent elvont számsornak tekintünk, az nem fog működni. Például a villamosenergia-fogyasztás elosztása a nap folyamán. Olyan ez, mint a rituálék: hétköznap reggel az elektromos borotva, hétvégén pedig a mixer. Aztán maguknak az anomáliáknak a lényege. És ne felejtsük el, hogy a Watts Battery személyes használatra készült, így minden ügyfélnek megvan a saját rituáléja, és egy univerzális modell nem fog működni. Az adatok ismert anomáliáinak felkutatása nem is feladat, más kérdés egy olyan rendszer létrehozása, amely önállóan keresi a címkézetlen anomáliákat. Hiszen bármi lehet anomália, beleértve az alattomos emberi tényezőt is. Például tesztadatainkban volt olyan eset, amikor a felhasználó akkumulátoros üzemmódba kényszerítette a rendszert. A felhasználók időnként ezt minden ok nélkül megteszik (Fenntartást teszek, hogy ez a felhasználó nálunk teszteli a modult, és ezért van hozzáférése a módok kézi vezérléséhez; más felhasználóknál a vezérlés teljesen automatikus). Amint azt könnyű megjósolni, ilyen helyzetben az akkumulátor meglehetősen aktívan lemerül, és ha nagy a terhelés, a töltés véget ér, mielőtt felkelne a nap vagy más energiaforrás. Ilyen esetekben valamilyen értesítést várunk arról, hogy a rendszer viselkedése eltért a normáltól. Vagy az illető elment, és elfelejtette kikapcsolni a sütőt. A rendszer úgy látja, hogy általában ebben a napszakban a fogyasztás 500 watt, de ma - 3,5 ezer - anomália! Mint Denis Matsuev a gépen: „Semmit sem értek a repülőgép-hajtóművekhez, de útközben a motor másként szólt.”
A Yandex CatBoost nyílt forráskódú neurális hálózat prediktív modelljének grafikonja
Mire van valójában szüksége a cégnek?: öndiagnosztikai rendszer a készüléken belül, prediktív analitika, akár hálózati infrastruktúra nélkül is (mint a gyakorlat azt mutatja, nem minden ügyfelünk siet az akkumulátorok internetre csatlakoztatásával - a legtöbbnek elég, ha minden megbízhatóan működik), anomáliák azonosítása, amelyek természetét még nem ismerjük, öntanuló rendszer tanár nélkül, klaszterezés, neurális hálózatok és a modern analitikai módszerek teljes arzenálja. Meg kell értenünk, hogy a rendszer másként kezdett viselkedni, még akkor is, ha nem tudjuk, mi változott pontosan. Magán a hackathonon nagyon fontos volt számunkra, hogy lássuk, vannak olyan srácok, akik készen állnak az ipari analitika felé, vagy már benne vannak, és új területeket keresnek, ahol kamatoztatni tudják képességeiket. Először meglepődtem, hogy ennyi a jelentkező: elvégre ez egy nagyon sajátos konyha, de fokozatosan egy kivételével mindenki kiesett, így valamennyire minden a helyére került.
Miért nem kivitelezhető ebben a szakaszban?: Az adatbányászati feladatok fő problémája, hogy nincs elegendő adat. Ma már több tucat Watts Battery készülék üzemel szerte a világon, de ezek közül sok nem csatlakozik a hálózathoz, így adataink még nem túl változatosak. Alig kapartunk össze két anomáliát – és azok a prototípusokon történtek, az ipari Watts Battery elég stabilan működik. Ha lenne egy belső gépi tanulási mérnökünk, és tudnánk – igen, ezt ki lehet csikarni ezekből az adatokból, de jobb minőségű előrejelzést szeretnénk kapni –, az egy történet lenne. De ez idáig nem tettünk semmit ezekkel az adatokkal. Ehhez ráadásul az is kellene, hogy a résztvevők mélyen elmerüljenek termékünk működési sajátosságaiban, ehhez másfél nap nem elég.
Hogyan döntöttél?: Nem tűzték ki azonnal a pontos végső feladatot. Ehelyett az egész 48 óra alatt párbeszédet folytattunk a résztvevőkkel, és azonnal kiderítettük, mit kaphatnak és mit nem. Ez alapján a kompromisszum jegyében a feladat véglegesítésre került.
Mit kaptál ennek eredményeként?: a pálya győztesei kitisztíthatták az adatokat (egyúttal megtalálták a paraméterek kiszámításának olyan „tulajdonságait” is, amelyeket mi magunk sem vettünk észre korábban, hiszen az adatok egy részét nem használtuk fel problémáink megoldására) , kiemeli a Watts Battery modulok elvárt viselkedésétől való eltéréseket, és felállít egy prediktív modellt, amely nagy pontossággal képes előre jelezni az energiafogyasztást. Igen, ez még csak egy megvalósíthatósági szakasza egy ipari megoldás fejlesztésének, akkor hetekig tartó fáradságos műszaki munkára lesz szükség, de akár ez a közvetlenül a hackathon során készült prototípus is igazi ipari megoldás alapját képezheti, ami ritka.
fő következtetés: A rendelkezésünkre álló adatok alapján lehet prediktív elemzést beállítani, ezt feltételeztük, de nem volt forrásunk az ellenőrzéshez. A hackathon résztvevői tesztelték és megerősítették hipotézisünket, a pályagyőztesekkel folytatjuk a munkát ezen a feladaton.
A Facebook Prophet nyílt forráskódú neurális hálózat prediktív modelljének grafikonja
Tanácsok a jövőre nézve: a feladat összeállításakor nem csak a gyártási ütemtervére kell figyelnie, hanem a résztvevők érdeklődésére is. Mivel hackathonunknak nincs pénzdíja, az adattudósok természetes kíváncsiságára és az új, érdekes problémák megoldásának vágyára játszunk, amelyekben még senki nem mutatott fel semmit, vagy ahol a meglévő eredményeknél jobban meg tudja mutatni magát. Ha azonnal figyelembe veszi az érdeklődési tényezőt, akkor nem kell áthelyeznie a hangsúlyt az út során.
vezetés
Feladat: (alkalmazás), amely Watts Battery modulokból álló hálózatot kezel személyes fiókkal, adattárolással a felhőben és állapotfigyeléssel.
Sajátosság: ezen a pályán nem valami új technikai megoldást kerestünk, természetesen van saját fogyasztói felületünk. Azért választottuk a hackathonra, hogy bemutassuk rendszerünk képességeit, elmerüljünk benne, és ellenőrizzük, érdekli-e a közösséget az intelligens rendszerek fejlesztése és az alternatív energia. Lehetőségként pozícionáltuk a mobilalkalmazást, saját belátása szerint megteheti vagy nem. De véleményünk szerint jól mutatja, hogyan sikerült az embereknek megszervezniük az adattárolást a felhőben, egyszerre több forrásból is.
Mire van valójában szüksége a cégnek?: fejlesztők közössége, akik üzleti ötletekkel állnak elő, hipotéziseket tesztelnek és munkaeszközöket készítenek azok megvalósításához.
Miért nem kivitelezhető ebben a szakaszban?: A piaci volumen még túl kicsi egy ilyen közösség szerves kialakításához.
Hogyan döntöttél?: Egy hackathon keretein belül egyfajta fizikai vizsgálatot végeztünk, hogy megnézzük, lehetséges-e nemcsak funkciókkal, hanem teljes értékű üzleti modellekkel előállni a nagyon specifikus termékünk köré. Sőt, ahhoz, hogy egy prototípust megvalósítani képes emberek ezt megtegyék, elvégre itt - nem akarok senkit megbántani - ez nem az a szint, amikor egy villogó LED-et programoznak az Arduino-ra (bár ez újításokkal megoldható) , itt meglehetősen speciális készségekre van szükség: backend és frontend rendszerek fejlesztése, a méretezhető Internet of Things rendszerek felépítésének elveinek ismerete.
Mit kaptál ennek eredményeként?: két csapat teljes értékű üzleti ötleteket javasolt a munkájukhoz: az egyik inkább az orosz, a másik a külföldi szegmensre koncentrált. Vagyis a fináléban nem csak azt mondták el, hogyan találták ki az alkalmazást, hanem lényegében Watts körüli üzletelésre jöttek. A srácok felvázolták, hogyan látják több üzleti modellben a Watt használatát, statisztikát adtak, bemutatták, mely régiókban milyen problémák vannak, hol milyen törvényeket fogadnak el, felvázolták a globális trendet: nem divat bitcoint bányászni, divat kilowattot bányászni. Szándékosan az alternatív energiához jutottak, ami nagyon tetszett nekünk. Az a tény, hogy a résztvevők ezen felül működő műszaki megoldást tudtak létrehozni, arra utal, hogy önállóan is indíthatnak startupot.
fő következtetés: Vannak olyan csapatok, amelyek készek arra, hogy a Watts Battery-t üzleti modelljük alapjául vegyék, fejlesztik azt, és a cég partnerei/társaivá váljanak. Néhányan még azt is tudják, hogyan lehet azonosítani egy üzleti ötlet MVP-jét, és először dolgoznak rajta, ami ma mindenhol hiányzik az iparágból. Az emberek nem értik, mikor kell abbahagyni, mikor kell piacra dobni egy megoldást, bár korán, de működőképes. Valójában a megoldás csiszolásának szakasza sokszor nem ér véget, a megoldás technikailag átlépi az ésszerű komplexitás határát, túlterhelten lép be a piacra, már nem világos, mi volt az eredeti ötlet, mi az ügyfélcélzás, milyen üzleti modellek beleértve. Mint az Akuninról szóló viccben, aki írt egy másik könyvet, miközben aláírta valakinek az előzőt. De itt a legtisztább formában készült: itt egy diagram, itt egy számláló, itt vannak mutatók, itt egy előrejelzés - ez minden, semmi más nem szükséges a futtatásához. Ezzel befektetőhöz fordulhat, és pénzt kaphat vállalkozás indításához. Akik megtalálták ezt az egyensúlyt, azok nyertesként kerültek ki a pályáról.
Tanácsok a jövőre nézve: a következő hackathonon (tervezzük ), talán van értelme hardverrel kísérletezni. Saját hardverfejlesztéssel rendelkezünk (a Watt egyik előnye), minden tevékenységünk gyártását és tesztelését teljes mértékben ellenőrizzük, de nincs elég erőforrásunk néhány „hardveres” hipotézis tesztelésére. Könnyen lehet, hogy a rendszer- és alacsony szintű programozók, hardverfejlesztők közösségében vannak olyanok, akik ebben segítenek, és a jövőben partnerünkké válnak ezen a területen.
Emberek
A hackathonra inkább azokat vártuk, akik új területen szeretnék kipróbálni magukat (például különböző programozó iskolák végzettjeit), mintsem az ilyen jellegű fejlesztésekre szakosodottakat. De mégis arra számítottunk, hogy a hackathon előtt végeznek egy kis előkészítő munkát, olvasnak arról, hogyan jósolják általában az energiafogyasztást, és hogyan működnek a dolgok internetes rendszerei. Hogy mindenki ne csak szórakozásból jöjjön, érdekes adatokat, feladatokat keresve, hanem előzetes elmélyüléssel is a tárgykörben. A magunk részéről megértjük, hogy ehhez előzetesen közzé kell tenni a rendelkezésre álló adatokat, azok leírását és az eredményre vonatkozó pontosabb követelményeket, közzé kell tenni API modulokat stb.
Mindenki megközelítőleg azonos technológiai szinttel, plusz-mínusz azonos képességekkel rendelkezett. Ennek fényében a harmónia szintje sem volt utolsó tényező. Számos csapat azért nem lőtt, mert nem tudták egyértelműen felosztani magukat a munkaterületekre. Voltak olyanok is, ahol egy ember végezte az összes fejlesztést, a többiek a prezentáció elkészítésével voltak elfoglalva, másokban pedig olyan feladatokat kapott valaki, amit ő csinált, valószínűleg életében először.
A résztvevők többsége fiatal volt, ez nem jelenti azt, hogy ne lennének közöttük erős gépi tanulási mérnökök és fejlesztők. A legtöbben csapatban jöttek, gyakorlatilag nem voltak egyéniek. Mindenki a győzelemről álmodott, valaki a jövőben munkát akart találni, körülbelül 20%-uk talált már, szerintem ez a szám növekedni fog.
Nem volt elég hardveres geekünk, de reméljük, a második hackathonon bepótoljuk.
Hackathon haladás
Ahogy fentebb is írtam, a hackathon 48 órájának nagy részében együtt voltunk a résztvevőkkel, és az ellenőrző pontokon figyelemmel kísérve sikereiket, igyekeztünk az első, elemző pálya elfogadásának feladatát és feltételeit úgy alakítani, hogy egyrészt a a résztvevők a hátralévő idő alatt teljesíthették, másrészt érdekes volt számunkra.
A feladat utolsó pontosítása valahol az utolsó ellenőrző pont környékén történt, szombat délután (a döntő vasárnap estére volt kiírva). Kicsit leegyszerűsítettünk mindent: megszüntettük a modell újraszámításának követelményét az új adatokon, meghagyva azokat az adatokat, amelyekkel a csapatok már dolgoztak. A mutatók összehasonlítása már nem adott nekünk semmit, a rendelkezésre álló adatok alapján már kész eredményeik voltak, és a második napra már elfáradtak a srácok. Ezért úgy döntöttünk, hogy kevésbé kínozzuk őket.
Négy résztvevőből három azonban nem jutott be a döntőbe. Az egyik csapat már az induláskor felismerte, hogy jobban érdekli kollégáink pályája, a másik a döntő előtt vette észre, hogy a feldolgozás során idő előtt kiszűrte a szükséges adatokat, és nem hajlandó bemutatni munkáit.
A „21 (Wet Hair Effect)” csapat mindkét pályánkon részt vett a végsőkig. Mindent egyszerre akartak lefedni: gépi tanulást, fejlesztést, alkalmazást és weboldalt. Amíg az utolsó pillanatban kivonulással nem fenyegettük őket, addig azt hitték, hogy mindent időben csinálnak, bár már a második ellenőrzőpontnál nyilvánvaló volt, hogy a fő dologgal - a gépi tanulással - nem tudnak jelentős előrelépést elérni: általában megbirkóztak A második blokk, de nem tudta megjósolni az áramfogyasztást, nem voltak készen. Ennek eredményeként, amikor meghatároztuk az elsőre való kvalifikáció minimális feladatát, még mindig a második pályát választották.
A Fit-predict kiegyensúlyozott, az adatelemzésre szabott összetételű volt, így mindent le tudtak győzni. Észrevehető volt, hogy a srácokat a valódi ipari adatok „megérintése” érdekelte. Azonnal a lényegre koncentráltak: az adatok elemzésére, tisztítására, minden anomália kezelésére. Az, hogy a hackathon során működőképes modellt tudtak építeni, óriási eredmény. A munkagyakorlatban ez általában hetekig tart: amíg az adatokat tisztogatják, addig elmélyülnek benne. Ezért mindenképpen együtt fogunk dolgozni velük.
A második pályán (menedzsment) azt vártuk, hogy mindenki fél nap alatt csináljon meg mindent és jöjjön kérni, hogy nehezítse a feladatot. Gyakorlatilag alig volt időnk elvégezni az alapfeladatot. JS-en és Pythonon dolgoztunk, ami az iparág jelenlegi állapotát tükrözi.
Itt is jól összehangolt csapatok értek el eredményeket, amelyekben a munkamegosztás kiépült, látszott, ki mit csinál.
A harmadik csapat, az FSociety látszólag megvan a megoldás, de végül úgy döntöttek, nem mutatják be a fejlődésüket, azt mondták, hogy nem tartják működőképesnek. Ezt tiszteletben tartjuk, és nem vitatkoztunk.
A győztes a „Strippers from Baku” csapata lett, amely képes volt megállítani magát, nem a „csecsebecséket” kergetni, hanem egy olyan MVP-t alkotni, amelyet nem szégyell felmutatni, és egyértelmű, hogy tovább fejleszthető, méretezhető. Azonnal közöltük velük, hogy nem érdekelnek minket túlságosan a további lehetőségek. Ha QR-kóddal, arcfelismeréssel szeretnének regisztrálni, először készítsenek grafikonokat az alkalmazásban, majd vállalják az opcionálisakat.
Ebben a számban a „Wet Hair” magabiztosan bejutott a döntőbe, velük és a „Hustlers”-szel megbeszéltük a további együttműködést. Utóbbival az új évben már találkoztunk.
Remélem minden sikerül, és mindenkit szeretettel várunk a márciusi második hackathonon!
Forrás: will.com