Afgelopen december hielden we onze eigen startup-hackathon met zes andere Skolkovo-bedrijven. Zonder bedrijfssponsors of enige externe steun hebben we dankzij de inspanningen van de programmeergemeenschap tweehonderd deelnemers uit twintig Russische steden verzameld. Hieronder vertel ik hoe het ons is gelukt, welke valkuilen we onderweg tegenkwamen en waarom we meteen zijn gaan samenwerken met een van de winnende teams.
Interface van de applicatie die Watts Battery-modules bestuurt van de finalisten van de track, “Wet Hair”
vennootschap
Ons bedrijf Watts Battery maakt modulaire draagbare energiecentrales. Het product is een draagbare krachtcentrale van 46x36x11 cm, die 1,5 tot 15 kilowatt per uur kan leveren. Vier van dergelijke modules kunnen twee dagen lang het energieverbruik van een klein landhuis leveren.
Hoewel we vorig jaar zijn begonnen met het verzenden van productiemonsters, is Watts Battery in alle opzichten een startup. Het bedrijf werd opgericht in 2016 en is sinds datzelfde jaar inwoner van het Skolkovo Energy Efficient Technologies Cluster. Tegenwoordig hebben we 15 medewerkers en een enorme achterstand aan dingen die we op een gegeven moment graag zouden willen doen, maar op dit moment is er geen tijd daarvoor.
Dit omvat ook puur softwaretaken. Waarom?
De hoofdtaak van de module is het bieden van een ononderbroken, evenwichtige energievoorziening tegen optimale kosten. Als u te maken krijgt met een stroomstoring die buiten uw macht ligt, moet u altijd over een reserve beschikken om de vereiste netwerkbelasting voor de duur van de storing volledig van stroom te kunnen voorzien. En als de stroomvoorziening goed is, kun je zonne-energie gebruiken om geld te besparen.
De eenvoudigste optie is dat je de accu overdag kunt opladen via de zon en 's avonds kunt gebruiken, maar wel precies op het niveau dat nodig is zodat je bij een stroomstoring niet zonder stroom komt te zitten. Je komt dus nooit in een situatie terecht waarin je de hele avond de verlichting via een batterij hebt gevoed (want dat is goedkoper), maar ’s nachts de elektriciteit uitvalt en je koelkast ontdooit.
Het is duidelijk dat een mens zelden in staat is om met grote nauwkeurigheid de hoeveelheid elektriciteit te voorspellen die hij nodig heeft, maar een systeem gewapend met een voorspellend model kan dat wel. Daarom is machinaal leren als zodanig een van onze prioriteitsgebieden. Het is gewoon dat we momenteel gefocust zijn op de ontwikkeling van hardware en niet genoeg middelen kunnen toewijzen aan deze taken, wat ons naar de Startup Hackathon bracht.
Voorbereiding, data, infrastructuur
Als gevolg hiervan hebben we twee sporen gevolgd: data-analyse en managementsysteem. Naast de onze waren er nog zeven nummers van collega's.
Hoewel het format van de hackathon nog niet vaststond, dachten we erover om “onze eigen sfeer” te creëren, met een puntensysteem: deelnemers doen dingen die ons moeilijk en interessant lijken en krijgen daarvoor punten. We hadden veel taken. Maar toen we de structuur van de hackathon opbouwden, vroegen andere organisatoren om alles in een gemeenschappelijke vorm te brengen, en dat hebben we gedaan.
Toen kwamen we tot het volgende schema: de jongens maken een model op basis van hun gegevens, vervolgens ontvangen ze onze gegevens, die het model nog niet eerder had gezien, het leert en begint te voorspellen. Er werd aangenomen dat dit allemaal binnen 48 uur zou kunnen worden gedaan, maar voor ons was dit de eerste hackathon op onze data, en mogelijk hebben we de tijdbronnen of de mate van gereedheid van de data overschat. Bij gespecialiseerde machine learning-hackathons zou zo’n tijdlijn de norm zijn, maar die van ons was niet zo.
We hebben de software en hardware van de module zoveel mogelijk ontladen en speciaal voor de hackathon een versie van ons apparaat gemaakt, met een zeer eenvoudige en begrijpelijke interne interface die elke ontwikkelaar zou kunnen ondersteunen.
Voor de baan op basis van het besturingssysteem bestond de mogelijkheid om een mobiele applicatie te maken. Om te voorkomen dat de deelnemers hun hersens zouden breken over hoe het eruit zou moeten zien en extra tijd zouden verspillen, hebben we ze een ontwerplay-out van de applicatie gegeven, superlichtgewicht, zodat degenen die dat willen er eenvoudigweg de functies die ze nodig hebben erop kunnen 'uitrekken'. . Eerlijk gezegd hadden we hier geen morele dilemma's verwacht, maar een van de teams pakte het zo aan dat we hun fantasie beperkten, we wilden gratis een kant-en-klare oplossing krijgen en deze niet testen. in praktijk. En ze vertrokken.
Een ander team koos ervoor om helemaal opnieuw een applicatie te maken, en alles werkte. We stonden er niet op dat de applicatie precies zo zou zijn, we wilden alleen dat deze enkele elementen bevatte die het technische niveau van de oplossing demonstreerden: grafieken, analyses, enz. De uiteindelijke ontwerplay-out was ook een hint.
Omdat het analyseren van een live Watts Battery-module tijdens een hackathon te tijdrovend zou zijn, hebben we de deelnemers een maand lang een kant-en-klaar stukje data gegeven uit de echte modules van onze klanten (die we vooraf zorgvuldig hebben geanonimiseerd). Omdat het juni was, was er niets dat seizoensveranderingen in de analyse kon opnemen. Maar in de toekomst zullen we er externe gegevens aan toevoegen, zoals seizoens- en klimatologische kenmerken (tegenwoordig is dit de industriestandaard).
We wilden geen onrealistische verwachtingen wekken bij de deelnemers, dus zeiden we bij de aankondiging van de hackathon direct: het werk zal zo dicht mogelijk bij het veldwerk liggen: luidruchtige, vuile data, die niemand speciaal heeft voorbereid. Maar dit had ook een positieve kant: in de geest van agile hadden we voortdurend contact met de deelnemers en brachten we snel wijzigingen aan in de taak en de toelatingsvoorwaarden (meer hierover hieronder).
Daarnaast hebben we deelnemers toegang gegeven tot Amazon AWS (zo actief dat Amazon één regio voor ons heeft geblokkeerd, we gaan uitzoeken wat we eraan kunnen doen). Daar kunt u infrastructuur voor het Internet of Things inzetten en, op basis van zelfs eenvoudige Amazon-sjablonen, binnen een dag een volwaardige oplossing creëren. Maar uiteindelijk ging absoluut iedereen zijn eigen weg en deed alles maximaal alleen. Tegelijkertijd slaagden sommigen erin de tijdslimiet te halen, anderen niet. Eén team, Nubble, gebruikte Yandex.cloud, iemand had het op hun hosting gezet. We waren zelfs bereid om domeinen te geven (we hebben geregistreerde domeinen), maar die waren niet nuttig.
Om de winnaars in het analytische traject te bepalen, waren we van plan de resultaten te vergelijken, waarvoor we numerieke statistieken hadden voorbereid. Maar uiteindelijk was dit niet nodig, aangezien drie van de vier deelnemers om verschillende redenen de finale niet bereikten.
Wat de huishoudelijke infrastructuur betreft, heeft het Skolkovo Technopark hier geholpen door ons (gratis) een van zijn gezellige modulaire ruimtes ter beschikking te stellen met een videowall voor presentaties en een paar kleinere ruimtes voor een recreatieruimte en voor het organiseren van catering.
Analytics
Taak: een zelflerend systeem dat op basis van controlegegevens afwijkingen in verbruik en modulewerking identificeert. We hebben de formulering bewust zo algemeen mogelijk gehouden, zodat deelnemers samen met ons konden nadenken over wat er gedaan kon worden op basis van de beschikbare gegevens.
Specificiteit: De meest complexe van de twee nummers. Industriële data verschillen op enkele punten van data in gesloten systemen (bijvoorbeeld digitale marketing). Hier moet u de fysieke aard begrijpen van de parameters die u probeert te analyseren; alles bekijken als abstracte getallenreeksen zal niet werken. Bijvoorbeeld de verdeling van het elektriciteitsverbruik over de dag. Het lijkt op rituelen: het elektrische scheerapparaat wordt doordeweeks 's ochtends aangezet en in het weekend de mixer. Dan de essentie van de afwijkingen zelf. En vergeet niet dat de Watts-batterij bedoeld is voor persoonlijk gebruik, dus elke cliënt heeft zijn eigen rituelen en één universeel model zal niet werken. Het vinden van bekende afwijkingen in data is niet eens een taak; het creëren van een systeem dat autonoom zoekt naar ongelabelde afwijkingen is een andere zaak. Alles kan immers een anomalie zijn, inclusief de verraderlijke menselijke factor. In onze testgegevens was er bijvoorbeeld een geval waarin het systeem door de gebruiker in de batterijmodus werd gedwongen. Zonder enige reden doen gebruikers dit soms (ik reserveer dat deze gebruiker de module voor ons test en om deze reden heeft hij toegang tot handmatige bediening van modi; voor andere gebruikers is de bediening volledig automatisch). Zoals gemakkelijk te voorspellen is, wordt de batterij in een dergelijke situatie behoorlijk actief ontladen, en als de belasting groot is, zal het opladen eindigen voordat de zon opkomt of een andere energiebron verschijnt. In dergelijke gevallen verwachten we een melding te zien dat het systeemgedrag is afgeweken van het normale gedrag. Of de persoon ging weg en vergat de oven uit te zetten. Het systeem ziet dat het verbruik op dit tijdstip gewoonlijk 500 watt bedraagt, maar vandaag - 3,5 duizend - een anomalie! Zoals Denis Matsuev in het vliegtuig: “Ik begrijp niets van vliegtuigmotoren, maar onderweg klonk de motor anders.”
Grafiek van een voorspellend model op het opensource neurale netwerk Yandex CatBoost
Wat heeft het bedrijf echt nodig?: zelfdiagnostisch systeem in het apparaat, voorspellende analyses, ook zonder netwerkinfrastructuur (zoals de praktijk laat zien, hebben niet al onze klanten haast om batterijen op internet aan te sluiten - voor de meesten is het voldoende om alles gewoon betrouwbaar te laten werken), identificatie van afwijkingen waarvan we de aard nog niet kennen, een zelflerend systeem zonder leraar, clustering, neurale netwerken en het hele arsenaal aan moderne analytische methoden. We moeten begrijpen dat het systeem zich anders begon te gedragen, ook al weten we niet wat er precies is veranderd. Tijdens de hackathon zelf was het erg belangrijk voor ons om te zien dat er jongens zijn die klaar zijn om in industrial analytics te stappen of daar al mee bezig zijn, en die op zoek zijn naar nieuwe gebieden om hun vaardigheden toe te passen. In eerste instantie was ik verrast dat er zoveel aanmeldingen waren: dit is tenslotte een heel specifieke keuken, maar geleidelijk vielen op één na alle vier deelnemers af, waardoor alles tot op zekere hoogte op zijn plek viel.
Waarom is dit in dit stadium nog niet haalbaar?: Het grootste probleem met dataminingtaken zijn niet voldoende gegevens. Er zijn tegenwoordig enkele tientallen Watts Battery-apparaten in gebruik over de hele wereld, maar veel daarvan zijn niet verbonden met het netwerk, dus onze gegevens zijn nog niet erg divers. We hebben nauwelijks twee afwijkingen bij elkaar geschraapt - en die kwamen voor bij prototypes; industriële Watts-batterijen werken redelijk stabiel. Als we een interne machine learning-ingenieur hadden, en we wisten – ja, dit kan uit deze gegevens worden geperst, maar we willen een betere kwaliteit van voorspellingen krijgen – zou het één verhaal zijn. Maar tot nu toe hebben we niets met deze gegevens gedaan. Bovendien zou dit een diepe onderdompeling van de deelnemers in de specifieke kenmerken van de werking van ons product vereisen; hiervoor is anderhalve dag niet genoeg.
Hoe heb je besloten?: Ze bepaalden niet meteen de exacte eindtaak. In plaats daarvan waren we gedurende de hele 48 uur in dialoog met de deelnemers, waarbij we er snel achter kwamen wat ze wel en niet konden krijgen. Op basis hiervan werd, in de geest van compromis, de taak afgerond.
Wat heb je als resultaat gekregen?: de winnaars van het nummer konden de gegevens opschonen (tegelijkertijd vonden ze de “kenmerken” van het berekenen van enkele parameters die we zelf nog niet eerder hadden opgemerkt, omdat we sommige gegevens niet hadden gebruikt om onze problemen op te lossen) , afwijkingen van het verwachte gedrag van Watts Battery-modules benadrukken en een voorspellend model opzetten dat het energieverbruik met een hoge mate van nauwkeurigheid kan voorspellen. Ja, dit is slechts een haalbaarheidsfase van het ontwikkelen van een industriële oplossing; daarna zijn weken van nauwgezet technisch werk nodig, maar zelfs dit prototype, dat direct tijdens de hackathon is gemaakt, kan de basis vormen van een echte industriële oplossing, wat zeldzaam is.
belangrijkste conclusie:: Op basis van de gegevens die we hebben, is het mogelijk om voorspellende analyses op te zetten. We gingen hiervan uit, maar hadden niet de middelen om dit te controleren. De deelnemers aan de hackathon hebben onze hypothese getest en bevestigd, en we zullen met de trackwinnaars aan deze taak blijven werken.
Grafiek van een voorspellend model op het opensource neurale netwerk Facebook Prophet
Advies voor de toekomst: bij het opstellen van een taak moet je niet alleen kijken naar je productieroadmap, maar ook naar het belang van de deelnemers. Omdat onze hackathon geen geldprijzen kent, spelen we in op de natuurlijke nieuwsgierigheid van datawetenschappers en de wens om nieuwe, interessante problemen op te lossen waarin nog niemand iets heeft laten zien of waar ze zich beter kunnen laten zien dan bestaande resultaten. Als je meteen rekening houdt met de factor die van belang is, hoef je gaandeweg je focus niet te verleggen.
Управление
Taak: (applicatie) die een netwerk van Watts Battery-modules beheert, met een persoonlijk account, gegevensopslag in de cloud en statusmonitoring.
Specificiteit: in dit nummer waren we niet op zoek naar een nieuwe technische oplossing; we hebben uiteraard onze eigen consumenteninterface. We kozen hem voor de hackathon om de mogelijkheden van ons systeem te demonstreren, ons erin te verdiepen en te kijken of de gemeenschap geïnteresseerd is in het onderwerp ontwikkeling van slimme systemen en alternatieve energie. We hebben de mobiele applicatie als optie gepositioneerd; je kunt het naar eigen goeddunken wel of niet doen. Maar naar onze mening laat het goed zien hoe mensen erin slaagden dataopslag in de cloud te organiseren, met toegang vanuit verschillende bronnen tegelijk.
Wat heeft het bedrijf echt nodig?: een gemeenschap van ontwikkelaars die zakelijke ideeën bedenken, hypothesen testen en werkinstrumenten creëren voor de implementatie ervan.
Waarom is dit in dit stadium nog niet haalbaar?: Het marktvolume is nog steeds te klein voor de organische vorming van een dergelijke gemeenschap.
Hoe heb je besloten?: Als onderdeel van een hackathon hebben we een soort lichamelijkheidsonderzoek uitgevoerd om te zien of het mogelijk was om niet alleen functies te bedenken, maar volwaardige bedrijfsmodellen rond ons zeer specifieke product. Bovendien, om mensen die in staat zijn een prototype te implementeren dit te laten doen, hier - ik wil niemand beledigen - is dit niet het niveau van het programmeren van een knipperende LED op Arduino (hoewel dit wel mogelijk is met innovaties) , zijn hier vrij specifieke vaardigheden vereist: ontwikkeling van backend- en frontend-systemen, begrip van de principes van het bouwen van schaalbare Internet of Things-systemen.
Wat heb je als resultaat gekregen?: twee teams stelden volwaardige zakelijke ideeën voor hun werk voor: de ene richtte zich meer op het Russische segment, de andere op het buitenlandse. Dat wil zeggen dat ze in de finale niet alleen vertelden hoe ze met de applicatie kwamen, maar feitelijk zaken gingen doen rondom Watts. De jongens schetsten hoe zij het gebruik van Watts in verschillende bedrijfsmodellen zien, leverden statistieken, lieten zien welke regio's welke problemen hebben, welke wetten waar worden aangenomen, schetsten de mondiale trend: het is uit de mode om bitcoins te minen, het is in de mode om kilowatts te minen. Ze zijn bewust op alternatieve energie uitgekomen, wat wij erg leuk vonden. Het feit dat de deelnemers bovendien een werkende technische oplossing hebben kunnen creëren, suggereert dat ze zelfstandig een startup kunnen lanceren.
belangrijkste conclusie:: Er zijn teams klaar om Watts Battery als basis voor hun bedrijfsmodel te nemen, dit te ontwikkelen en partners/metgezellen van het bedrijf te worden. Sommigen van hen weten zelfs hoe ze de MVP van een bedrijfsidee moeten identificeren en daar eerst aan moeten werken, iets dat tegenwoordig overal in de branche ontbreekt. Mensen begrijpen niet wanneer ze moeten stoppen, wanneer ze een oplossing op de markt moeten brengen, zij het vroeg, maar werkend. In feite eindigt de fase van het polijsten van de oplossing vaak niet, technisch gezien overschrijdt de oplossing de grens van redelijke complexiteit, komt ze overbelast op de markt, is het niet langer duidelijk wat het oorspronkelijke idee was, wat klantgerichtheid is, wat bedrijfsmodellen zijn inbegrepen. Zoals in de grap over Akoenin, die nog een boek schreef terwijl hij het vorige voor iemand signeerde. Maar hier werd het in zijn puurste vorm gedaan: hier is een grafiek, hier is een teller, hier zijn indicatoren, hier is een voorspelling - dat is alles, er is niets anders nodig om het uit te voeren. Hiermee kunt u naar een investeerder gaan en geld ontvangen om een bedrijf te starten. Degenen die dit evenwicht vonden, kwamen als winnaars uit de baan.
Advies voor de toekomst: bij de volgende hackathon (die zijn we aan het plannen ), misschien is het zinvol om met hardware te experimenteren. We hebben onze eigen hardwareontwikkeling (een van de voordelen van Watts), we hebben volledige controle over de productie en het testen van alles wat we doen, maar we hebben niet genoeg middelen om sommige ‘hardware’-hypothesen te testen. Het kan heel goed zijn dat er in de gemeenschap van systeem- en low-level programmeurs en hardwareontwikkelaars mensen zijn die ons hierbij zullen helpen en in de toekomst onze partner op dit gebied zullen worden.
Mensen
Tijdens de hackathon verwachtten we degenen die zichzelf op een nieuw vakgebied willen uitproberen (bijvoorbeeld afgestudeerden van verschillende programmeerscholen) in plaats van degenen die gespecialiseerd zijn in dit soort ontwikkeling. Maar toch hadden we verwacht dat ze vóór de hackathon wat voorbereidend werk zouden doen, zouden lezen over hoe het energieverbruik in het algemeen wordt voorspeld en hoe Internet of Things-systemen werken. Zodat iedereen niet alleen voor de lol komt, op zoek naar interessante gegevens en taken, maar ook met een voorafgaande onderdompeling in het vakgebied. Van onze kant begrijpen wij dat het hiervoor noodzakelijk is om vooraf de beschikbare gegevens, hun beschrijving en nauwkeurigere vereisten voor het resultaat te publiceren, API-modules te publiceren, enz.
Iedereen had ongeveer hetzelfde technologische niveau, plus of min dezelfde capaciteiten. Tegen deze achtergrond was het niveau van harmonie niet de laatste factor. Een aantal ploegen heeft niet geschoten omdat zij zich niet duidelijk konden indelen in werkgebieden. Er waren er ook waarbij één persoon de hele ontwikkeling deed, de rest bezig was met het voorbereiden van de presentatie, in andere gevallen kreeg iemand taken die hij of zij deed, waarschijnlijk voor de eerste keer in hun leven.
De meeste deelnemers waren jong, dit betekent niet dat er geen sterke machine learning-ingenieurs en -ontwikkelaars onder hen waren. De meesten kwamen in teams; er waren vrijwel geen individuen. Iedereen droomde ervan om te winnen, iemand wilde in de toekomst een baan vinden, ongeveer 20% heeft er al een gevonden, ik denk dat dit cijfer zal groeien.
We hadden niet genoeg hardware-nerds, maar we hopen dit goed te maken tijdens de tweede hackathon.
Vooruitgang van de hackathon
Zoals ik hierboven schreef, waren we het grootste deel van de 48 uur van de hackathon bij de deelnemers en probeerden we, door hun successen bij controleposten te volgen, de taak en voorwaarden voor het accepteren van het eerste, analytische spoor aan te passen, zodat enerzijds de deelnemers konden het in de resterende tijd voltooien, en aan de andere kant was het voor ons interessant.
De laatste verduidelijking van de taak werd ergens rond het laatste controlepunt gegeven, op zaterdagmiddag (de finale stond gepland voor zondagavond). We hebben alles nog een beetje vereenvoudigd: we hebben de vereiste verwijderd om het model opnieuw te berekenen op basis van nieuwe gegevens, waardoor de gegevens overbleven waarmee de teams al werkten. Het vergelijken van de statistieken leverde ons niets meer op, ze hadden al kant-en-klare resultaten op basis van de beschikbare gegevens, en op de tweede dag waren de jongens al moe. Daarom hebben we besloten hen minder te martelen.
Drie van de vier deelnemers bereikten echter de finale niet. Het ene team besefte bij de start al dat ze meer geïnteresseerd waren in het spoor van onze collega's, het andere team realiseerde zich vlak voor de finale dat ze tijdens het verwerkingsproces vooraf de benodigde gegevens eruit hadden gefilterd en weigerden hun werk te presenteren.
Het team van “21 (Wet Hair Effect)” heeft tot het einde aan onze beide nummers deelgenomen. Ze wilden alles in één keer behandelen: machine learning, ontwikkeling, applicatie en website. Totdat we hen op het laatste moment met terugtrekking dreigden, geloofden ze dat ze alles op tijd deden, hoewel het al bij het tweede controlepunt duidelijk was dat ze met het belangrijkste - machinaal leren - geen noemenswaardige vooruitgang konden boeken: ze konden over het algemeen omgaan met het tweede blok, maar kon het elektriciteitsverbruik niet voorspellen, was nog niet klaar. Als gevolg hiervan kozen ze, toen we de minimale taak voor kwalificatie voor het eerste bepaalden, toch voor het tweede circuit.
Fit-predict had een uitgebalanceerde samenstelling op maat gemaakt voor data-analyse, zodat ze alles konden overwinnen. Het viel op dat de jongens geïnteresseerd waren in het 'aanraken' van echte industriële gegevens. Ze concentreerden zich meteen op het belangrijkste: analyseren, de gegevens opschonen, elke anomalie aanpakken. Dat ze tijdens de hackathon een werkend model hebben weten te bouwen, is een mooie prestatie. In de praktijk duurt dit doorgaans weken: terwijl de data worden opgeschoond, terwijl men zich erin verdiept. Daarom zullen we zeker met hen samenwerken.
In het tweede spoor (management) verwachtten we dat iedereen alles in een halve dag zou doen en zou komen vragen om de taak moeilijker te maken. In de praktijk hadden we nauwelijks tijd om de basistaak te voltooien. We hebben gewerkt aan JS en Python, wat de huidige stand van zaken in de branche weerspiegelt.
Ook hier werden de resultaten behaald door goed gecoördineerde teams waarin de taakverdeling werd opgebouwd, het was duidelijk wie wat deed.
Het derde team, FSociety, leek een oplossing te hebben, maar uiteindelijk besloten ze hun ontwikkeling niet te laten zien, ze zeiden dat ze het niet als werkend beschouwden. Wij respecteren dit en hebben geen ruzie gemaakt.
De winnaar was het team “Strippers uit Baku”, dat zichzelf kon tegenhouden, niet om “snuisterijen” na te jagen, maar een MVP te creëren die zich niet schaamt om te laten zien en die duidelijk is dat deze verder kan worden ontwikkeld en opgeschaald. We vertelden hen meteen dat we niet zo geïnteresseerd waren in extra mogelijkheden. Als ze registratie via QR-code en gezichtsherkenning willen, laat ze dan eerst grafieken maken in de applicatie en dan de optionele aangaan.
In dit nummer ging ‘Wet Hair’ vol vertrouwen de finale in en we bespraken de verdere samenwerking met hen en ‘Hustlers’. Die laatste hebben we in het nieuwe jaar al ontmoet.
Ik hoop dat alles goed komt en we kijken ernaar uit om iedereen te zien op de tweede hackathon in maart!
Bron: www.habr.com