Автору респект за интересный пост!
Интересно, а как вы отнесетесь к идее того, чтобы использовать нейронную сеть для извлечения фич, а не как классификатор.
Я имею ввиду следующие, делаем на нейронной сети классификатор, берем выход препоследнего слоя и работаем с ним как с обычными фичами. Здесь уже появляется большое поля для манерва, можно использовать другие методы, например, SVM.
Что думаете?
на самом деле почти все применимо, но есть одно но. Внедрение требует очень много инженерной работы. Как правило реализация алгоритма требует 10-20% временных ресурсов, а инженерная обвеска остальные 80-90%
Я уже писал, что команда разработки и тестирования алгоритмов (data scientists) использует свой парк серверов на Spark и пишет только на Scala, а вся остальная разработка ведется на .Net
Коллаборативная фильтрация на Scala/Spark пишется в 100 строчек кода без всякого УГ как Mahout (вы пробовали с его документацией разбираться?), даже без MLLib.
Я вижу очень большой минус, что курс будет на готовой библиотеке sci-kit. Курс от Andrew лучше тем, что ученик сам пишет алгоритм и видит изнутри, как он работает. Посмотрите первый ответ на quora на вопрос «How do I learn machine learning?»
Xavier (который был директором по аналитике Netflix) пишет:
Get a good ML book (my list below), read the first intro chapters, and then jump to whatever chapter includes an algorithm you are interested. Once you have found that algo, dive into it, understand all the details, and, especially, implement it. In the previous online course you would already have implemented some algorithms in Octave. But, here I am talking about implementing an algorithm from scratch in a «real» programming language. You can still start with an easy one such as L2-regularized Logistic Regression, or k-means, but you should also push yourself to implement more interesting ones such as LDA (Latent Dirichlet Allocation) or SVMs. You can use a reference implementation in one of the many existing libraries to make sure you are getting comparable results, but ideally you don't want to look at the code but actually force yourself to implement it directly from the mathematical formulation in the book.
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следующие:
очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следуюшие:
очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
Мне очень не хватало графиков в ipython интерфейсах. DF особо не пользуюсь, все-таки case классы и функциональный подход тоже дают похожий эффект, но конечно не такой как Pandas
У нас есть свой GitHub, там есть один проект для Spark. В Spark коммиты пока не делаем, т.к. это время разработчиков. Мы стартап, который уже самоокупился, поэтому не можем разбрасываться рабочим временем.
Для нас нет никакой необходимости познавать внутренности Scala, внутренности Spark для нас более актуальны, т.к. бывает нужно оптимизировать саму реализацию алгорима. А это больше не сама Scala, а Spark!
У нас очень специфический ML, пишем сами, хотя некоторые методы MLlib используем. Из внешних библиотек я планировал протестировать распределенный R. Python или Vowpal Wabbit использовать не хочется по причине возвращению к зоопарку технологий, как было раньше, это очень хорошо для экспериментов, но плохо для production
Нам очень помогли курсы по Scala на coursera + книги по Spark, которые опубликованы на O'Reilly.
Тестовый переход занял 2 месяца, на production переходили дольше, т.к. до версии Spark 1.1.1 все было плохо.
Сейчас переписано 90% функционала. Написано около 15 000 строк кода на Scala. Команда три человека.
Я больше занимаюсь Pig and Hive — возможно там лучше ситуация. ODBC драйвер тоже искал для MS SQL. Как вам производительность ODBC для Oracle? Быстро работает?
Интересно, а как вы отнесетесь к идее того, чтобы использовать нейронную сеть для извлечения фич, а не как классификатор.
Я имею ввиду следующие, делаем на нейронной сети классификатор, берем выход препоследнего слоя и работаем с ним как с обычными фичами. Здесь уже появляется большое поля для манерва, можно использовать другие методы, например, SVM.
Что думаете?
Сами начинали с Pig и Hive, потом резко перешли на Scala/Spark
Xavier (который был директором по аналитике Netflix) пишет:
Недостатки следующие:
Недостатки следуюшие:
Тестовый переход занял 2 месяца, на production переходили дольше, т.к. до версии Spark 1.1.1 все было плохо.
Сейчас переписано 90% функционала. Написано около 15 000 строк кода на Scala. Команда три человека.