Комментарии 29
Я думаю, что анализ текущего рабочего места будет в следующей серии когда я перейду на следующую позицию, которая, по каким-то причинам мне понравится больше, чем то, что есть сейчас.
Этот текст я написал, когда смог сравнить различные подходы, а именно Bidgely vs TrueAccord. Будет больше данных для сравнения, а именно Bidgely vs TrueAccord vs XXX — будет новый текст.
Вопрос — а не легче ли в этом стартапе произвести разделение труда — один товарищь пишет быстро и, по возможности, правильно, правильно работающий код а другой -сразу же его только рефакторит пока он "горяч" и в промежутках рефакторит старьё — все равно там пара человек работает в сущности над одним и тем же? Тот же Алекс быстро говнокодит, а автор исходной статьи за ним идёт как фермер-перфекционист — в двойных рыбацких сапогах с лопатой.
Маркировку наверное можно было бы проводить автоматом при сборе данных, используя знания о том, откуда пришел тот или иной пакет по сети (список адресов с информацией об установленном на адресах оборудовании наверняка есть).
"Спрашиваю Алекса — а он опять говорит — ты говорит дебагером пробегись, да посмотри как и что эволюционирует. "
И господин функциональный язык программирования, с его "особыми отношениями с мадам Переменными" здесь был бы кстати — но сразу о том, в начале проекта, что чистая функциональщина прямо таки создана для скорой генерации срочно нужной тонны говнокода, дабы удобрить стартап-деревце — никто не подумал.
Но это сильно замедляет процесс разработки. Для небольших компаний это непозволительная роскошь. Это очень дорого и неэффективно и сейчас многие компании ищут тех, кто может провести алгоритм от прототипа до продакшена.
Проблема с маркировкой в том, что для ее получения надо в доме поставить по датчику между каждой разеткой и тем, что в нее вклюлчено, а это сложно и никто этим заниматься не будет.
Бизнес модель строится на том, что можно взять суммарное потребление, которое снимается со счетчика электроэнергии и разделить на компоненты не устанавливая что-то в каждую розетку.
Я не совсем это имел в виду — не нужно пихать датчики. Это делается на этапе заключения договора между поставщиком и потребителем энергии — тогда то и поставщик и получает список устройств потребителя с их установленной электрической мощностью, взятой из техпаспортов — дальше скачки мощности соответствуют мощности включаемых и выключаемых устройств из списка а продолжительность потребления данной мощности — подсказка о характере устройства — прерывистое равномерное потребление в течение многих, многих ночей и дней даст только холодильник, 5-минутные подъёмы в 1-1,5 кВт — скорее всего дрель или пылесос, утренние и вечерние подъёмы в 1-5 кВт — электроплита, более поздние 40 мин.- 2 ч. 1-1,5 кВт — стиралка.
Все это дело передаётся по сети, одним датчиком — тем, что на электросчетчике, и можно, зная адрес с которого датчик дал данные, маркировать их автоматом по имеющемуся на адресе списку устройств.
Кроме того, можно вспомнить про переходные процессы из электротехники и регистрировать их, если датчики счетчика это позволяют — они дадут конкретный "почерк" каждого устройства, подобный "почерку" радиста.
Вообще же этот стартап, просто ещё один представитель поколения компаний "интернета вещей". "Интернет вещей" сейчас буквально из каждой щели лезет, — что бы вы сказали, например, если бы попали в положение одного из героев романов Ф. К. Дика, который однажды с утра не смог выйти на улицу — потому что у него не было денег, которыми можно было бы открыть требующую платы за открывание дверь квартиры — бред, да?
Бред, бредом, но вот "охочие до денежек" вещи, пришедшие к нам из Завтра уже серийно производятся, и совсем скоро электроэнергию можно будет оплатить в своём электрощитке (кстати, не забудьте его закрыть на ключ — иначе туда установят банкоматный скиммер ...:)), — это электросчетчики марок СТК-1-10 и СТК-3-10, принимающие к оплате карты. Заодно поставщик энергии сможет предложить кучу тарифов, отключить, если потребитель превысил отведённый ему лимит электроэнергии или же закончилась предоплата за электроэнергию или же произошли не оговоренные договорами колебания мощности и/или напряжения.
А что касается схемы разработки — ну так это неизбежное зло, но, если уж хочется избавляться от говнокода, то придётся сделать это так — Data Scientist делает плохую программную модель и постепенно добивается её правильной работы, затем переписывает результаты не в виде кода, а в виде систем математических уравнений, (кодовый прототип Software Engineer не получает), которые Software Engineer набирает набело "с бумаги".
Кстати, в качестве рабочего языка конечной реализации, возможно, подойдёт Standard ML или Ada, — из-за их сверхмощной модульности, препятствующей расползанию говнокода, появляющегося из-за правок при эксплуатации, а прототипирование лучше вести на знакомом по аспирантуре лиспе, схеме или используя Agda, Cog, Isabelle (proof assistant), Maxima.
Разные языки прототипирования и реализации как раз и гарантируют, защищают от соблазна "чуть допилить" прототип.
Подход, который вы предложили, действительно сработает, но поставщикам электроэнергии это не надо.
Стартапы вроде Bidgely предлагают им готовое решение, в виде работающего алгоритма, а то что у Bidgely нет отмаркированных данных — это проблемы Bidgely.
Прототип в машинном обучении — это код, который поглощает сырые данный с одной стороны и выплевывает предсказание или что еще от него там требуется с другой — а это код, а не уравнения. И тут во многом играет роль даже не конкретный язык, а библиотеки, которые для этого языка доступны.
В Питоне с этим все нормально, в Matlab более-менее, в Standard ML и Ada, насколько я знаю — никак.
И задача вовсе не написать хороший код, деньги платят не за написание кода, а написать код который решает задачи, и сделать это быстро, и да, надо стараться писать как можно лучше, но не потому что это хорошо и благородно само по себе, а потому что это в большинстве случев экономит время в средне и долгосрочной перспективе.
На днях был пост на эту тему. => https://habrahabr.ru/post/310310/
Ну да, Вы писали в публикации про "клиентскую базу", которую набирают, чтобы жить за счёт долговременной работы с ними, при данном бизнес-поведении качество кода = низкие затраты на поддержку+долговечность программы.= выживаемость стартапа на последующих этапах. Я ориентировался на то, что буквально прочёл в статье.
Ну, если с библиотеками остаётся, главным образом, питон, то для нетривиальных задач (машобучение имеет отношение к математической вероятности), попробуйте применить "вероятностные языки программирования" — может, проще и быстрее прототипы разрабатывать можно будет (пользуясь ими для "набросков" модели):
https://habrahabr.ru/post/244625/
https://habrahabr.ru/post/242993/
Низкое качество кода это действительно очень плохо, но тут нужен баланс. Мое недовольство процессом разработки было вызвано как раз тем, что на мой взгляд, можно и код лучше писать, так чтобы не терять время при поиске багов/добавлении новых фич, и при этом можно было быстро итерировать, а быстрые итерации — это необходимое условие в разработке алгоритмов для машинного обучения.
Хочется всего — и точного алгоритма, и клиентской базы, и хорошего кода, но время/ресурсы ограничены — приходится маневрировать, но это должны быть здоровые маневры. И полностью жертвовать качеством кода, чтобы получить небольшую сиюминутную выгоду, не вариант, но и ставить во главе идельную аритектуру кода, жервуя точностью алгоритма — это тоже плохо.
И использование MatLab'а — это как раз нездоровый маневр, как минимум потому что нет IDE, которая поддерживает рефракторинг.
Машинное обучение действительно имеет наипрямейшее отношение к математической вероятности, в половине алгоритмов это Maximum likelihood estimation.
И вероятностные языки — это правильно и красиво, только на практике работает так себе. Хотя если вы знаете примеры, когда модели, разработанные, используя вероятностное программировние превосходили в точности более классические подходы я с удовольствием про это почитаю/попробую.
Алгоритмы ML — это кагл + статьи, книжки, видео лекции. Как правильно поставить задачу, выбрать метрику, которая отвечает интересам бизнеса и сделать так, чтобы алгоритм заработал в production, так как должен — это уже на работе.
Наверно, что-то по алгоритмам я и на работе выучился, но это пренебрежимо мало. Все таки у кагла по метрике знания в определенных областях ML в единицу времени конкурентов нет.
Есть одна задача в теоретической физике, о которой я думал еще во время обучения, куда ML хорошо войдет, но попробовать толком у меня пока руки не дошли.
Есть тут такой финт, если ты на F1, можно подать на Optional Practical Training, то есть в теории — это вы чему-то научились в университете, а после этого в учитесь в индустрии.
Но есть ограничение, работать можно на той позиции, которая связана полученние специальностью.
«Связана» — это очень нечеткое понятие, но, например в MacDonalds'e кричать «касса свободна» мне нельзя. А вот в Data Science — можно, потому что и неспециалист поймет, что Data Science и физика как-то связаны.
Еще одно ограничение — это сколько можно быть безработным. И, когда я принял индусский офер, я во многом дергался из-за этого. Время шло, работы не было.
OPT — 1 год, в течение него можно не работать 90 дней
OPT extension — еще два года сверху. OPT+OPT extension — в сумме можно не работать 120 дней.
По крайней мере читая статью, у меня такое впечатление сложилось, везде все одинаково. :)
Так вот когда Google и Uber, написали что хотели бы пригласить меня к ним в офис на это oniste интервью я вежливо отказался.
- Приглашение на onsite — это не предложение работы. Совсем не очевидно, что даже если бы мне сильно захотелось там работать — мне бы сделали офер.
- Вакансия в Google была Quantitative Analyst — а это практически чистая статистика, а не машинное обучение. Не интересно. Вакансия была в их штаб квартире, а это в Mountain View, что опять же не интересно.
Uber — удачное расположение (их штаб квартира через дорогу от квартиры, что я снимаю). И позиция скорее мидл, с потенциально быстрым ростом до Senior, но там тоже не чистое машинное обучение, а микс всего со всем. Но про них я много думал.
У больших компаний есть свои сильные стороны, и, скорее всего следующая позиция будет в большой компании, но хочется, чтобы она была связана с Deep Learning, а этим по работе и по учебе я не занимался, то тут надо тонко и правильно разыграть карты, которые у меня есть на руках плюс вытянуть правильные карты из колоды, и сделать это в нужный момент. И этот момент пока не настал.
Парень с моего факультета работает в компании LeapYear — у них там сплошной хаскель в Data Science, правда что именно они делают я не знаю. Может если бы я был экспертом в функциональном программировании — тоже бы его использовал под какие-то задачи, но программирование я качал занимаясь физикой, а там не смотря на пару попыток Haskell у меня не прижился.
Я бы с удовольствием вбухал время в Haskell, но под это нужна задача где он будет обладать серьезными преимуществами на фоне Питона.
Либо изучать в свободное время, что тоже можно, но времени мало и, скажем, работа над алгоритмом по предсказанию эпилептических припадков в данный момент будет обладать приоритетом, ибо знания, которые при этом почерпнуться они сейчас важны.
Я читал близкие вещи в книге «Analyzing the Analyzers», бесплатно доступна (после регистрации) на сайте O'Reily: http://www.oreilly.com/data/free/analyzing-the-analyzers.csp
Судя по всему, вопрос взаимодействия разработчиков и ученых — это еще не совсем решенная проблема в индустрии…
Из физиков в Data Science (Из двигателей науки в офисный планктон). Вторая часть