En decembro pasado, celebramos o noso propio hackathon de inicio con outras seis empresas de Skolkovo. Sen patrocinadores corporativos nin ningún apoio externo, reunimos douscentos participantes de 20 cidades de Rusia grazas aos esforzos da comunidade de programación. A continuación vouvos contar como o logramos, con que trampas atopamos no camiño e por que de inmediato comezamos a colaborar cun dos equipos gañadores.
Interface da aplicación que controla os módulos Watts Battery dos finalistas do tema, "Wet Hair"
Compañía
A nosa empresa Watts Battery crea centrais eléctricas portátiles modulares. O produto é unha central eléctrica portátil de 46x36x11 cm, capaz de entregar de 1,5 a 15 quilovatios por hora. Catro destes módulos poden proporcionar o consumo de enerxía dunha pequena casa de campo durante dous días.
Aínda que comezamos a enviar mostras de produción o ano pasado, Watts Battery é unha startup. A empresa foi fundada en 2016 e desde o mesmo ano é residente do Clúster de Tecnoloxías de Eficiencia Enerxética de Skolkovo. Hoxe temos 15 empregados e un enorme atraso de cousas que nos gustaría facer nalgún momento, pero agora mesmo non hai tempo para iso.
Isto tamén inclúe tarefas puramente de software. Por que?
A principal tarefa do módulo é proporcionar un abastecemento enerxético ininterrompido e equilibrado a un custo óptimo. Se experimentas un corte de enerxía por motivos alleos ao teu control, sempre debes ter unha reserva para poder alimentar completamente a carga de rede necesaria durante o tempo que dure a interrupción. E cando a fonte de enerxía é boa, podes usar a enerxía solar para aforrar cartos.
A opción máis sinxela é que podes cargar a batería do sol durante o día e usala pola noite, pero exactamente ao nivel necesario para que, en caso de apagón, non te quedes sen electricidade. Entón, nunca te atoparás nunha situación na que encendeches a iluminación cunha batería durante toda a noite (porque é máis barato), pero pola noite a electricidade apagouse e o teu frigorífico desconxelouse.
Está claro que unha persoa raramente é capaz de predecir con gran precisión a cantidade de electricidade que necesita, pero un sistema armado cun modelo preditivo si. Polo tanto, a aprendizaxe automática como tal é unha das nosas áreas prioritarias. É só que actualmente estamos centrados no desenvolvemento de hardware e non podemos destinar recursos suficientes a estas tarefas, que é o que nos levou ao Startup Hackathon.
Preparación, datos, infraestrutura
Como resultado, tomamos dúas vías: a análise de datos e o sistema de xestión. Ademais dos nosos, había sete temas máis dos compañeiros.
Aínda que non se determinou o formato do hackathon, estabamos pensando en crear “a nosa propia atmosfera”, cun sistema de puntos: os participantes fan algunhas cousas que nos parecen difíciles e interesantes, recibindo puntos por iso. Tivemos moitas tarefas. Pero a medida que construímos a estrutura do hackathon, outros organizadores pediron levar todo a unha forma común, o que fixemos.
Despois chegamos ao seguinte esquema: os rapaces elaboran un modelo a partir dos seus datos, despois reciben os nosos datos, que o modelo non vira antes, aprende e comeza a predicir. Supoñíase que todo isto podería facerse en 48 horas, pero para nós este foi o primeiro hackathon sobre os nosos datos, e é posible que sobreestimamos os recursos de tempo ou o grao de preparación dos datos. Nos hackathons especializados de aprendizaxe automática, esa liña de tempo sería a norma, pero o noso non era así.
Descargamos o software e hardware do módulo na medida do posible, e fixemos unha versión do noso dispositivo especificamente para o hackathon, cunha interface interna moi sinxela e comprensible que podería soportar calquera desenvolvedor.
Para a pista baseada no sistema de control, existía a opción de facer unha aplicación móbil. Para evitar que os participantes se aburran sobre como debería ser e perdan tempo extra, démoslles un deseño da aplicación, súper lixeiro, para que quen queira simplemente "estira" as funcións que necesita. . Para ser honesto, non esperabamos ningún dilema moral aquí, pero un dos equipos tomouno de tal xeito que estabamos limitando o seu voo de fantasía, queriamos conseguir unha solución preparada de balde e non probalas. na práctica. E despegaron.
Outro equipo optou por facer unha aplicación completamente diferente desde cero e todo funcionou. Non insistimos en que a aplicación fose exactamente así, só precisabamos que conteña algúns elementos que demostrasen o nivel técnico da solución: gráficos, analíticas, etc. O deseño acabado tamén foi unha pista.
Dado que analizar un módulo Watts Battery en directo nun hackathon levaría demasiado tempo, ofrecémoslles aos participantes unha porción de datos preparada durante un mes tomada dos módulos reais dos nosos clientes (que previamente anonimizamos coidadosamente). Dende que era xuño non había nada que incorporara á análise os cambios estacionais. Pero no futuro engadirémoslles datos externos, como características estacionais e climáticas (hoxe é o estándar da industria).
Non queriamos crear expectativas pouco realistas entre os participantes, polo que no anuncio do hackathon dixemos directamente: o traballo será o máis próximo posible ao traballo de campo: datos ruidosos, sucios, que ninguén preparou especialmente. Pero isto tamén tivo un lado positivo: con espírito áxil, estivemos constantemente en contacto cos participantes, e realizamos de inmediato cambios na tarefa e nas condicións de admisión (máis información a continuación).
Ademais, demos aos participantes acceso a Amazon AWS (tan activamente que Amazon bloqueou unha rexión para nós, imos descubrir que facer ao respecto). Alí podes implementar infraestrutura para a Internet das cousas e, incluso en modelos simples de Amazon, crear unha solución completa nun día. Pero ao final, absolutamente cada un foi o seu camiño, facendo todo pola súa conta ao máximo. Ao mesmo tempo, algúns lograron cumprir o límite de tempo, outros non. Un equipo, Nubble, utilizou Yandex.cloud, alguén o plantexou no seu hosting. Incluso estabamos preparados para dar dominios (temos rexistrados), pero non foron útiles.
Para determinar os gañadores na pista analítica, planeamos comparar os resultados, para o que preparamos métricas numéricas. Pero ao final non foi necesario facelo, xa que por diversos motivos tres dos catro participantes non chegaron ás finais.
En canto á infraestrutura doméstica, o Skolkovo Technopark axudou aquí proporcionándonos (de balde) unha das súas acolledoras salas modulares con videowall para presentacións e un par de salas máis pequenas para unha área recreativa e para organizar un catering.
Analítica
Tarefa: un sistema de autoaprendizaxe que identifica anomalías no consumo e no funcionamento do módulo a partir de datos de control. Mantivemos deliberadamente a redacción o máis xeral posible para que os participantes puidesen traballar connosco para pensar o que se podería facer en función dos datos dispoñibles.
Especificidade: A máis complexa das dúas pistas. Os datos industriais teñen algunhas diferenzas cos datos en sistemas pechados (por exemplo, marketing dixital). Aquí cómpre comprender a natureza física dos parámetros que estás a analizar; mirar todo como unha serie de números abstractos non funcionará. Por exemplo, a distribución do consumo eléctrico ao longo do día. É como rituais: a navalla eléctrica acéndese pola mañá os días laborables e a batidora as fins de semana. A continuación, a esencia das propias anomalías. E non esquezas que a batería Watts está pensada para uso persoal, polo que cada cliente terá os seus propios rituais e un modelo universal non funcionará. Buscar anomalías coñecidas nos datos nin sequera é unha tarefa; crear un sistema que busque de forma autónoma anomalías sen etiquetar é outra cuestión. Despois de todo, calquera cousa pode ser unha anomalía, incluído o insidioso factor humano. Por exemplo, nos nosos datos de proba houbo un caso no que o sistema foi forzado polo usuario ao modo de batería. Sen ningún motivo, os usuarios fan isto ás veces (reservarei que este usuario está a probar o módulo por nós e é por iso que ten acceso ao control manual dos modos; para outros usuarios o control é completamente automático). Como é fácil de prever, en tal situación a batería descárgase bastante activamente e, se a carga é grande, a carga rematará antes de que saia o sol ou apareza outra fonte de enerxía. Nestes casos, esperamos ver algún tipo de notificación de que o comportamento do sistema se desviou do normal. Ou a persoa marchou e esqueceuse de apagar o forno. O sistema ve que normalmente a esta hora do día o consumo é de 500 watts, pero hoxe - 3,5 mil - unha anomalía! Como Denis Matsuev no avión: "Non entendo nada dos motores dos avións, pero no camiño o motor soaba diferente".
Gráfico dun modelo preditivo na rede neuronal de código aberto Yandex CatBoost
Que necesita realmente a empresa?: sistema de autodiagnóstico dentro do dispositivo, análise preditiva, incluso sen infraestrutura de rede (como mostra a práctica, non todos os nosos clientes teñen présa por conectar as baterías a Internet; para a maioría, é suficiente para que todo funcione de forma fiable), identificación de anomalías, cuxa natureza aínda non coñecemos, un sistema de autoaprendizaxe sen profesor, agrupación, redes neuronais e todo o arsenal de métodos analíticos modernos. Necesitamos entender que o sistema comezou a comportarse doutro xeito, aínda que non saibamos exactamente o que cambiou. No propio hackathon, foi moi importante para nós ver que hai rapaces que están preparados para entrar na analítica industrial ou xa están nela, e buscan novas áreas para aplicar as súas habilidades. Ao principio sorprendeume que houbese tantos aspirantes: á fin e ao cabo, trátase dunha cociña moi específica, pero aos poucos todos os catro participantes, menos un, foron abandonando, polo que ata certo punto todo quedou no seu lugar.
Por que non é viable nesta fase?: O principal problema coas tarefas de minería de datos non son datos suficientes. Actualmente hai varias ducias de dispositivos Watts Battery en funcionamento en todo o mundo, pero moitos deles non están conectados á rede, polo que os nosos datos aínda non son moi diversos. Apenas reunimos dúas anomalías, e as ocorreron en prototipos; a batería industrial Watts funciona de forma bastante estable. Se tivésemos un enxeñeiro interno de aprendizaxe automática e soubésemos -si, isto pode ser eliminado destes datos, pero queremos obter unha mellor calidade de predición- sería unha historia. Pero ata este momento non fixemos nada con estes datos. Ademais, isto requiriría unha profunda inmersión dos participantes nas especificidades do funcionamento do noso produto, un día e medio non é suficiente para iso.
Como decidiches?: Non estableceron inmediatamente a tarefa final exacta. Pola contra, ao longo das 48 horas, estivemos dialogando cos participantes, descubrindo pronto o que podían conseguir e o que non. En base a isto, con espírito de compromiso, finalizouse a tarefa.
Que obtivo como resultado?: os gañadores da pista puideron limpar os datos (ao mesmo tempo atoparon as “características” de calcular uns parámetros que nós mesmos non nos decataramos antes, xa que non utilizamos algúns dos datos para resolver os nosos problemas) , resaltar as desviacións do comportamento esperado dos módulos de Watts Battery e configurar un modelo preditivo capaz de predecir o consumo de enerxía cun alto grao de precisión. Si, esta é só unha fase de viabilidade para desenvolver unha solución industrial; entón serán necesarias semanas de traballo técnico minucioso, pero mesmo este prototipo, creado directamente durante o hackathon, pode formar a base dunha solución industrial real, o que é raro.
conclusión principal: En base aos datos que temos, é posible configurar análises preditivas, asumimos isto, pero non tiñamos recursos para comprobar. Os participantes no hackathon probaron e confirmaron a nosa hipótese, e seguiremos traballando cos gañadores da pista nesta tarefa.
Gráfico dun modelo preditivo na rede neuronal de código aberto Facebook Prophet
Consellos para o futuro: ao elaborar unha tarefa, cómpre mirar non só a súa folla de ruta de produción, senón tamén o interese dos participantes. Dado que o noso hackathon non ten premios en metálico, xogamos coa curiosidade natural dos científicos de datos e o desexo de resolver problemas novos e interesantes nos que ninguén aínda mostrou nada nin onde se pode mostrar mellor que os resultados existentes. Se tes en conta inmediatamente o factor de interese, non terás que cambiar o teu foco no camiño.
Управление
Tarefa: (aplicación) que xestiona unha rede de módulos Watts Battery, cunha conta persoal, almacenamento de datos na nube e seguimento do estado.
Especificidade: nesta pista non buscabamos algunha solución técnica nova; por suposto, temos a nosa propia interface de consumidor. Escollemosno para o hackathon para demostrar as capacidades do noso sistema, mergullarnos nel e comprobar se a comunidade está interesada no tema do desenvolvemento de sistemas intelixentes e enerxías alternativas. Posicionamos a aplicación móbil como unha opción, podes facelo ou non ao teu criterio. Pero na nosa opinión, amosa ben como a xente conseguía organizar o almacenamento de datos na nube, con acceso desde varias fontes diferentes á vez.
Que necesita realmente a empresa?: unha comunidade de desenvolvedores que elaborarán ideas de negocio, probarán hipóteses e crearán ferramentas de traballo para a súa implementación.
Por que non é viable nesta fase?: O volume do mercado aínda é demasiado pequeno para a formación orgánica de tal comunidade.
Como decidiches?: Como parte dun hackathon, realizamos unha especie de estudo físico para ver se era posible crear non só características, senón modelos de negocio completos arredor do noso produto moi específico. Ademais, para que as persoas capaces de implementar un prototipo fagan isto, despois de todo, aquí -non quero ofender a ninguén- este non é o nivel de programación dun LED parpadeante en Arduino (aínda que isto pódese facer con innovacións) , aquí son necesarias habilidades máis ben específicas: desenvolvemento de sistemas backend e frontend, comprensión dos principios de construción de sistemas escalables de Internet das Cousas.
Que obtivo como resultado?: dous equipos propuxeron ideas de negocio de pleno dereito para o seu traballo: un enfocado máis no segmento ruso, o outro no estranxeiro. É dicir, no final non só contaron como se lles ocorreu a aplicación, senón que, esencialmente, chegaron a facer negocios arredor de Watts. Os mozos explicaron como ven o uso de Watts en varios modelos de negocio, proporcionaron estatísticas, mostraron que rexións teñen que problemas, que leis se adoptan onde, delinearon a tendencia global: non está de moda minar bitcoins, está de moda minar quilovatios. Chegaron deliberadamente ás enerxías alternativas, que nos gustou moito. O feito de que os participantes, ademais disto, puidesen crear unha solución técnica funcional suxire que poden lanzar unha startup de forma independente.
conclusión principal: Hai equipos preparados para tomar Watts Battery como base do seu modelo de negocio, desenvolvelo e converterse en socios/compañeiros da empresa. Algúns deles mesmo saben identificar o MVP dunha idea de negocio e traballar nel primeiro, algo que falta en todas as partes do sector hoxe en día. A xente non entende cando parar, cando lanzar unha solución ao mercado, aínda que sexa cedo, pero funcionando. De feito, a etapa de pulido da solución moitas veces non remata, tecnicamente a solución cruza a liña de complexidade razoable, entra no mercado sobrecargada, xa non está claro cal era a idea orixinal, cal é a orientación ao cliente, cales son os modelos de negocio. incluído. Como na broma sobre Akunin, que escribiu outro libro mentres asinaba o anterior para alguén. Pero aquí fíxose na súa forma máis pura: aquí hai un gráfico, aquí hai un contador, aquí hai indicadores, aquí hai unha predición - iso é todo, non se necesita nada máis para executalo. Con isto, podes acudir a un investidor e recibir diñeiro para iniciar un negocio. Os que atoparon este equilibrio saíron da pista como vencedores.
Consellos para o futuro: no próximo hackathon (estamos planeando ), quizais teña sentido experimentar co hardware. Temos o noso propio desenvolvemento de hardware (unha das vantaxes de Watts), controlamos totalmente a produción e as probas de todo o que facemos, pero non temos recursos suficientes para probar algunhas hipóteses do "hardware". Pode ser moi ben que na comunidade de programadores de sistemas e de baixo nivel e desenvolvedores de hardware haxa quen nos axude con isto e que no futuro se converta no noso socio neste ámbito.
Persoas
No hackathon, esperábamos aqueles que queiran probarse nun campo novo (por exemplo, titulados de varias escolas de programación) en lugar dos que se especializan neste tipo de desenvolvemento. Pero aínda así, esperabamos que antes do hackathon fagan un pequeno traballo preparatorio, ler sobre como se prevé o consumo de enerxía en xeral e como funcionan os sistemas de Internet das Cousas. Para que todos veñan non só por diversión, buscando datos e tarefas interesantes, senón tamén cunha inmersión previa na materia. Pola nosa banda, entendemos que para iso é necesario publicar previamente os datos dispoñibles, a súa descrición e requisitos máis precisos para o resultado, publicar módulos API, etc.
Todos tiñan aproximadamente o mesmo nivel tecnolóxico, máis ou menos as mesmas capacidades. Neste contexto, o nivel de harmonía non foi o último factor. Varios equipos non tiraron porque non podían dividirse claramente en áreas de traballo. Tamén houbo aquelas nas que unha persoa facía todo o desenvolvemento, o resto estaba ocupado preparando a presentación, noutros, a alguén se lle encomendaban tarefas que estaba a realizar, probablemente por primeira vez na súa vida.
A maioría dos participantes eran novos, isto non significa que non houbese enxeñeiros e desenvolvedores fortes de aprendizaxe automática entre eles. A maioría viñeron por equipos, practicamente non había individuos. Todo o mundo soñaba con gañar, alguén quería atopar un traballo no futuro, preto do 20% xa atopou un, creo que esta cifra crecerá.
Non tiñamos suficientes fanáticos do hardware, pero esperamos compensalo no segundo hackathon.
Progreso do hackathon
Como escribín anteriormente, estivemos cos participantes a maior parte das 48 horas do hackathon e, controlando os seus éxitos nos postos de control, tentamos adaptar a tarefa e as condicións para aceptar a primeira pista analítica para que, por unha banda, os participantes puideron completalo no tempo restante e, por outra banda, resultounos do seu interese.
A última aclaración da tarefa fíxose nalgún lugar arredor do último control, o sábado pola tarde (a final estaba prevista para o domingo á noite). Simplificamos todo un pouco máis: eliminamos a esixencia de recalcular o modelo en novos datos, deixando os datos cos que xa estaban traballando os equipos. Comparar métricas xa non nos daba nada, xa tiñan resultados preparados en función dos datos dispoñibles, e ao segundo día os rapaces xa estaban cansos. Por iso, decidimos torturalos menos.
Non obstante, tres de cada catro participantes non chegaron ás finais. Un equipo xa se deu conta ao comezo de que lles interesaba máis a pista dos nosos compañeiros, o outro, xusto antes da final, deuse conta de que durante o proceso de tramitación filtraran os datos necesarios con antelación e negáronse a presentar o seu traballo.
O equipo "21 (Wet Hair Effect)" participou nos dous temas ata o final. Querían cubrir todo á vez: aprendizaxe automática, desenvolvemento, aplicación e sitio web. Ata que os ameazamos con retirada no último momento, crían que o estaban facendo todo a tempo, aínda que xa no segundo punto de control era obvio que co principal -a aprendizaxe automática- non podían avanzar significativamente: en xeral afrontaban o segundo bloque, pero non podía prever o consumo de electricidade non estaban listos. En consecuencia, cando determinamos a tarefa mínima para a clasificación para a primeira, aínda elixiron a segunda pista.
Fit-predict tiña unha composición equilibrada adaptada para a análise de datos, polo que puideron superalo todo. Notou que os mozos estaban interesados en "tocar" datos industriais reais. Inmediatamente concentráronse no principal: analizar, limpar os datos, tratar con cada anomalía. O feito de que fosen capaces de construír un modelo de traballo durante o hackathon é un gran logro. Na práctica laboral, isto adoita levar semanas: mentres se limpan os datos, mentres se afondan nel. Polo tanto, definitivamente traballaremos con eles.
Na segunda pista (xestión), agardabamos que todos o fixeran todo en media xornada e viñesen pedir para dificultar a tarefa. Na práctica, apenas tivemos tempo para completar a tarefa básica. Traballamos en JS e Python, o que reflicte o estado actual da industria.
Tamén aquí os resultados conseguíronos equipos ben coordinados nos que se construía a división do traballo, estaba claro quen facía que.
O terceiro equipo, o FSociety, parecía ter unha solución, pero ao final decidiron non mostrar o seu desenvolvemento, dixeron que non consideraban que funcionaba. Respectamos isto e non discutimos.
O gañador foi o equipo "Strippers from Baku", que foi capaz de deterse, non para perseguir "trinkets", senón para crear un MVP que non se avergoña de mostrar e que ten claro que se pode desenvolver e escalar aínda máis. Inmediatamente dixémoslles que non estabamos moi interesados en oportunidades adicionais. Se queren rexistrarse mediante código QR, recoñecemento facial, que primeiro fagan gráficas na aplicación, e despois asuman as opcionais.
Neste tema, "Wet Hair" entrou con confianza na final, e falamos de máis cooperación con eles e "Hustlers". Este último xa o coñecemos no novo ano.
Espero que todo funcione, e estamos ansiosos por ver a todos no segundo hackathon de marzo!
Fonte: www.habr.com