For cirka halvandet år siden begyndte jeg at deltage i hackathons. I løbet af denne tid har jeg deltaget i mere end 20 arrangementer af varierende størrelse og temaer i Moskva, Helsinki, Berlin, München, Amsterdam, Zürich og Paris. I alle arrangementer har jeg arbejdet med dataanalyse i en eller anden form. Jeg nyder at besøge nye byer, opbygge nye kontakter, finde friske ideer, realisere gamle tanker på kort tid og føle adrenalin under præsentationen og resultatoffentliggørelsen.
Dette indlæg er den første af tre indlæg om hackathons, hvor jeg vil fortælle, hvad hackathons er, og hvorfor du bør begynde at deltage i dem. Det andet indlæg vil handle om den mørke side af disse arrangementer — om hvordan arrangørerne lavede fejl under afholdelsen, og hvad det førte til. Det tredje indlæg vil være dedikeret til at besvare spørgsmål om emner relateret til hackathons.
Hvad er et hackathon?
Et hackathon er et arrangement, der afholdes over flere dage, hvis mål er at løse et bestemt problem. Der er typisk flere problemer på et hackathon, hver præsenteret som et særskilt spor. Sponsorerende virksomheder giver en beskrivelse af opgaven, succesmålinger (målingerne kan være subjektive som "nyhedsværdi og kreativitet", men kan også være objektive — nøjagtigheden af klassificeringen på et hold-out datasæt) og ressourcer til at opnå succes (virksomhedens API, datasæt, "hardware"). Deltagerne skal i den tildelte tid formulere problemet, foreslå en løsning og vise en prototype af deres produkt. De bedste løsninger modtager præmier fra virksomheden og mulighed for videre samarbejde.
Faserne i hackathon
Efter oplysning af opgaverne samles deltagerne i hackathonen i teams: hver "ensom ulv" får en mikrofon og taler om den valgte opgave, sin erfaring, idé og hvilken type specialister han har brug for til realiseringen. Nogle gange kan teamet bestå af én person, som er i stand til at udføre hele arbejdet på projektet selvstændigt på et tilstrækkeligt højt niveau. Dette er relevant for hackathons om dataanalyse, men ofte forbudt eller uønsket for produktarrangementer — arrangørerne har til hensigt at fortsætte arbejdet med projektet, men allerede i virksomheden; det dannede team har en række fordele i forhold til deltagere, der ønsker at skabe produktet alene. Et optimalt team består typisk af 4 personer og inkluderer: frontend, backend, data scientist og en forretningsperson. For at bemærke, er opdelingen mellem data science/produkt-hackathons ret simpel — hvis der er et datasæt med en klar måling og leaderboard, eller man kan vinde med kode i en jupyter notebook — er det en data science hackathon; alt andet — hvor der er behov for at lave en applikation, hjemmeside eller noget fangende — er produkt.
Normalt starter arbejdet med projektet kl. 21 fredag aften, og deadline er kl. 10 søndag morgen. En del af denne tid skal afsattes til søvn (at ikke sove og kode — det er en sikker vej til fiasko, det har jeg prøvet), og det betyder, at deltagerne ikke har så meget tid til at lave noget kvalitetsmæssigt. For at hjælpe deltagerne er der repræsentanter fra virksomheden og mentorer til stede.
Arbejdet med projektet starter med kommunikation med repræsentanterne fra virksomheden, da de bedre forstår opgavens specifik, målinger, og de vil sandsynligvis dømme jeres arbejde til sidst. Målet med denne kommunikation er at forstå, hvilke retninger der er mest relevante, og hvor man skal fokusere sin opmærksomhed og tid.
På en hackathon blev der stillet en regressionopgave med et datasæt af tabeldata og billeder samt en klar metrik - RMSE. Efter at jeg havde talt med datascientisten fra virksomheden, indså jeg, at de havde brug for klassifikation, ikke regression, men nogen i ledelsen havde besluttet, at opgaven bedst kunne løses på denne måde. Klassifikationen var ikke for at opnå et økonomisk forbedringsmål, men for at forstå hvilke parametre der er mest væsentlige ved beslutningstagning, og derefter bearbejde dem manuelt. Det betyder, at den oprindelige opgave (regression med RMSE) ændres til klassifikation; prioriteten for vurderingen ændres fra den opnåede nøjagtighed til muligheden for at forklare resultatet. Dette udelukker muligheden for at bruge stacking og black box algoritmer. En sådan dialog har sparet mig en masse tid og øget mine chancer for at vinde.
Når du har forstået, hvad du skal gøre, begynder det faktiske arbejde med projektet. Du skal etablere checkpoints - tidspunkter, hvor de opstillede opgaver skal være udført; samtidig er det en god idé at fortsætte kommunikationen med mentorerne - repræsentanter fra virksomheden og tekniske specialister - det er nyttigt til justering af din projektplan. Et friskt perspektiv på problemet kan give interessante løsninger.
Da hackathons tiltrækker mange nybegyndere, er det god skik fra arrangørernes side at afholde foredrag og workshops. Normalt er der tre foredrag - om hvordan man præsenterer sin idé som et produkt, et teknisk foredrag (for eksempel om brugen af åbne API'er i maskinlæring, så du ikke skal skrive dit eget speech2text på to dage, men kan bruge det, der allerede findes), og et foredrag om pitching (hvordan man præsenterer sit produkt, hvordan man korrekt gestikulerer på scenen, så lytterne ikke keder sig). Der er forskellige aktiviteter for at opmuntre deltagerne - yoga, bordfodbold og bordtennis eller videospil.
På søndag morgen skal du præsentere dine resultater for dommerne. På gode hackathons starter alting med teknisk ekspertise — fungerer det, du påstår, virkelig? Formålet med denne kontrol er at skille hold med flotte præsentationer og buzzwords fra dem, der faktisk har skabt noget. Desværre er teknisk ekspertise ikke til stede på alle hackathons, og der er tilfælde, hvor et team med 12 slides og mentaliteten '... blockchain, kvantecomputing, så her kan AI klare det...' vinder førstepladsen. Sådanne præcedenser er ikke så hyppige, men fordi de huskes bedst, tror mange, at en god præsentation er 99% af sejr i hackathons. Præsentationen er faktisk vigtig, men dens bidrag er højst 30%.
Efter deltagernes præsentation træffer dommerne beslutning om præmiering af vindere. Den officielle del af hackathonen er nu afsluttet.
Motivation for at deltage i hackathons
Erfaring
Set fra et erfaringsperspektiv er hackathon et unikt arrangement. Der findes ikke mange steder, hvor man kan realisere en idé fra ingenting på 2 dage og få øjeblikkelig feedback på sit arbejde. Under hackathonen udvikler man kritisk tænkning, evnen til at arbejde i team, tidsstyring, evnen til at arbejde i stressede situationer, evnen til at præsentere resultaterne af sit arbejde på en forståelig måde, præsentationsteknikker og mange andre færdigheder. Det er netop derfor, hackathons er et fantastisk sted for personer med teoretisk viden, der ønsker at få virkelig erfaring.
Præmier
Den typiske præmiesum for et hackathon ligger normalt mellem 1.500 og 10.000 euro for førstepladsen (i Rusland mellem 100.000 og 300.000 rubler). Den forventede værdi (expected value, EV) ved deltagelse kan beregnes med en simpel formel:
EV = Prize * WinRate + Future_Value - Costs hvor Præmie — størrelsen på præmien (for enkelheds skyld antager vi, at der er én præmie);
WinRate — vinderate (for et nybegyndervirksomhed vil denne værdi være begrænset til 10%, for mere erfarne 50% og derover; jeg har mødt folk, der kom hjem fra hvert hackathon med en præmie, men det er snarere undtagelsen end reglen, og på længere sigt vil deres vinderate være lavere end 100%);
Future_Value — et mål på den fremtidige profit fra deltagelse i hackathonet: dette kan være profit fra den erfaring, man får, de kontakter, man knytter, de informationer, man opnår, osv. Det er praktisk talt umuligt at bestemme dette præcist, men det er noget, man skal huske;
Omkostninger — udgifter til transport, ophold, mv.
Beslutningen om deltagelse træffes på baggrund af en sammenligning af EV fra hackathonet med EV fra den aktivitet, man ville have engageret sig i, hvis hackathonet ikke havde fundet sted: hvis du ville ligge på sofaen i weekenden og pille næse, så måske er det værd at deltage i hackathonet; hvis du vil tilbringe tid med dine forældre eller kæreste — så tag dem med i teamet til hackathonet (bare sjov — beslut selv), hvis du vil freelance — sammenlign dollar-pris pr. time.
Ifølge mine beregninger kan jeg sige, at det i Rusland for en gennemsnitlig data scientist på junior- til mellem-niveau at deltage i hackathons er sammenligneligt med den monetære profit fra en almindelig arbejdsdag, men der er også nuancer (teamstørrelse, type hackathon, præmiepulje mv.). Generelt er hackathons lige nu ikke en guldgrube, men de kan give en pæn tilføjelse til det personlige budget.
Ansættelse i virksomheden og netværk
For virksomheden er hackathonet en måde at ansætte nye medarbejdere. Det er meget lettere for dig at vise, at du er en rationel person og kan arbejde under hackathonet, end under en jobsamtale, hvor du skal tegne et binært træ på en tavle (hvilket for øvrigt ikke altid stemmer overens med det, du vil lave i det virkelige arbejde som data scientist, men traditioner skal respekteres). Denne test i 'kamp' kan erstatte en prøvedag.
Mit første job fik jeg takket være et hackathon. Under hackathonet viste jeg, at man kunne få flere penge ud af dataene, og jeg fortalte, hvordan jeg planlagde at gøre det. Jeg startede et projekt under hackathonet, vandt det, og fortsatte derefter projektet i sponsorselskabet. Det var mit fjerde hackathon i mit liv.
Muligheden for at få et unikt datasæt
Dette er et meget relevant punkt for datavidenskab hackathons, hvis betydning ikke er forstået af alle. Normalt leverer sponsorvirksomhederne reelle datasæt under arrangementet. Disse data er private, de er omfattet af en NDA, men det forhindrer ikke i at vise dig et proof of concept på et rigtigt datasæt og ikke på et legetøjs-titanic. I fremtiden vil sådanne resultater være en stor hjælp ved ansøgning om job i den pågældende virksomhed eller en konkurrentvirksomhed, eller når man skal begrunde lignende projekter. Enig i at, alt andet lige, have gennemførte projekter, som er blevet bedømt positivt, er bedre end ikke at have nogle. Generelt spiller sådanne realiserede projekter en lignende rolle som medaljer og status på Kaggle, men deres værdi i industrien er mere åbenlys.
Tips
Generelt er arbejdet på et hackathon en temmelig varieret oplevelse, og det er svært at formulere en liste over regler. Men her vil jeg gerne give en liste over observationer, der kan hjælpe nybegyndere:
- Vær ikke bange for at deltage i hackathons, selvom du ikke har erfaring eller et team. Tænk på, hvad du kunne være nyttig for. For eksempel har du måske en interessant idé, eller er du dygtig inden for et bestemt område? Du kan bruge din domain knowledge til at formulere problemet og finde ud af, hvordan det kan løses på utraditionelle måder. Eller måske er du den bedste til at google? Din evne kan spare dig for en masse tid, hvis du kan finde færdige implementationer på GitHub. Eller er du virkelig god til at tune parametre i lightgbm? I så fald skal du ikke gå til hackathon, men bevise det i Kaggle konkurrencer.
- Taktik er vigtigere end manøvrer. Din opgave på hackathonet er at løse problemet. Nogle gange, for at løse et problem, skal det identificeres. Tjek, om dit identificerede problem er relevant for virksomheden. Tjek din løsning i forhold til problemet, og spørg dig selv om optimaliteten af din løsning. Ved vurdering af din løsning vil man først se på relevansen af problemet og hensigtsmæssigheden af den foreslåede løsning. Arkitekturen af dit neurale netværk eller hvor mange hænder du har fået, interesserer knap nogen.
- Deltag i så mange hackathons som muligt, men vær ikke bange for at forlade dårligt organiserede arrangementer.
- Tilføj resultaterne af dit arbejde på hackathonet til dit CV, og vær ikke bange for at skrive offentligt om det.
Essensen af hackathons. Kort sagt
Kilde: habr.com
