Обсуждение

по-моему, в области machine learning не использовать cloud имеет ещё меньше смысла, чем в области традиционных сервисов.

А как же Java и dl4j? Слабее Torch и Theano?

В вопросе "что такое слабее" в мире софта вопрос становится религиозным в один клик. Насколько я знаю, все новинки в области сеток (в том числе новинки массово-параллельных архитектур сеток) приходят от проектов без использования dl4j. Ну, и таких "самых быстрых" и "самых коммерческих" фреймворков много, тот же помянутый Neon. Если вам нравится Java и у вас весь прикладной уровень на Java, то юзайте dl4j, я про связь хост-языков и DNN фреймворков довольно отчётливо, вроде написал, и даже пример привёл с Julia и Torch.

Об том и пост, нет?

Вопрос не религиозный, а для меня вполне практический. Да, бизнес-логика на Java. Но deep learning пока лучше на Python получается. Соответственно, не понятно, что делать - прототип на Python и потом переносить на dl4j или развивать прототип и потом мостик какой придумывать или еще что-то... Спасибо. Ответ я получил.

Если вам нужно делать новые типы (архитектуры) сеток, то вам нужен Torch. Если вы учитесь или занимаетесь наукой, то берите Python варианты. Если ищете приключений и думаете о будущем -- Julia. Если вам нужно быстро-быстро что-то сделать для коммерческого применения на уже известных идеях и при этом на Java, берите dl4j. Увы, однозначного ответа тут нет, весь дьявол в деталях.

Большое спасибо за совет!

я как-то не вижу, что в этом посте про cloud. вроде всё про то, как самому построить. особенно про затраты вхождения смешно - в клауд затраты вхождения нулевые, а scalability - практически бесконечна. учитывая, что много вычислительных ресурсов нужно только во время тренинга (недолго), а не во время использования (долго), не использовать клауд имеет смысл только в каких-нибудь сильно необычных случаях, а весь мэйнстрим вписывается в клауд просто чудесно.

Сводить все настройки нейросети к изменению количества элементов в слоях -- это как сводить все арифметические операции к умножению. Куда у вас делась функция потерь, краеугольный камень нейросетей? Вы принципиально не хотите признавать элементы научного мышления в нейросетях, поэтому не можете осилить мысль, что подбор гиперпараметров -- это тривиальная задача, дело одного дня такое запрограммировать, и дело-то не в этом (и ваше "конечно, когда-нибудь ему в этом помогут средства автоматизации и оптимизации, но пока они не слишком развиты" -- ересь полнейшая). Объясняю: Так же, как и с FPGA, высокая скорость работы означает фиксацию на определённой архитектуре. А по задаче редко когда понятно, какой метод и насколько хорошо сработает. Это не инженерия, это научный метод в чистом виде: мы проверяем гипотезы, анализируем результаты, строим новые гипотезы, и снова их проверяем. Именно поэтому процесс не такой, как вы описываете, все проекты одноразовые, и поэтому вместо SaaS в большинстве случаев на самом деле продаётся консалтинг, и поэтому используется метод "full stack" -- когда вместо специалистов на стороне мы используем своих специалистов. Так же, как с Битриксом: продаётся не коробка, а коробку продаёт дизайнерская контора вместе с проектом. Ну и почитайте http://neon.nervanasys.com/docs/latest/hyperparameter_tuning.html , например, про подбор гиперпараметров -- давно уже всё придумано, но не всё так просто. Да, облако удобно, но только потому что требуется однократно сделать много вычислений -- для того же подбора гиперпараметров. Ну даст вам оно 2% точности дополнительных, затратив 10-кратное количество ваших денег. Но даже если у вас есть столько денег, облако не панацея -- потому что облако не осуществляет консалтинг.

Вы меня неправильно тут читаете. Я обычно или род и пару видов задаю, или в рамках теории прототипов пару-тройку прототипов для задания концепта. Так что количество элементов в слоях это только пример. И даже кроме функции потерь там много чего есть. Про соотношение науки и инженерии -- так инженерия ровно так и устроена: как говорил мне один из опытных инженеров, компрессор на пару мегават очень легко сделать, нужно просто сделать их штуки четыре (представляете размеры и цикл их проектирования?), после чего будет абсолютно ясно, как их делать -- и пятый уже будет вполне ничего. По вашему разумению, это и есть наука в чистом виде: сделать гипотезу, проверить её, если не работает, что-то поменять. А по моему мнению, так это как раз инженерия. Software engineering тоже такая же, инженерия. Учёные не сетки делают на выходе работающие, учёные теории новые разрабатывают. А вы тут описываете Эдисона с его лабораториями и тысячей попробованных лампочек. Эдисон не учёный, он изобретатель. И ваши настраиватели сеток не учёные, а изобретатели. А если они иногда и определяют какие-то гиперпараметры вычислением или какими иными эвристиками, так и инженеры регулярно что-то вычисляют-моделируют, а не просто используют метод проб и ошибок. Но испытания даже в случае использования каких-то теорий и расчётов таки проводят: расчёты расчётами, а реальность реальностью. Про облако я пишу, потому как вычислительные мощности всё больше и больше как водопровод: бутылки дорогие все покупают, но кран в квартире и в офисе всё одно есть. Так что я недаром привёл тут обе архитектуры -- и бесстековую и полного стека. А консалтинг или аутсорсинг возможен в сочетаении с любой из этих архитектур. На хакатоне использовалось и облако, и местные компьютеры.

Ага, расскажите людям, которые серьёзно нейросетями занимаются, пре-принты на arxiv выкладывают и потом публикуются, что они, оказывается, инженерией занимаются (или изобретательством). https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%83%D1%87%D0%BD%D1%8B%D0%B9_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4 Эдисон изобретатель, а не учёный, только если он наобум эти тысячу материалов для лампочек тестирует. Но и даже тогда грань настолько тонка, что физики-ядерщики, которые в коллайдере протоны сталкивают, по-вашему, не учёные, а изобретатели -- потому что они наобум их сталкивают, а потом описывают результат. Вся экспериментальная физика тоже изобретательство, по-вашему. Для меня разделение следующее: если товарищ моделирует предметную область и изготавливает по ней систему, он инженер, а если он занимается исследованиями: изучает способ построения лучшей модели, описывающей данные, то он учёный. Цель инженера -- проект: построить систему, решающую задачу на достаточном уровне за ограниченное время. Цель учёного -- изучить новые методы, попытаться с их помощью решить задачу с лучшим качеством, чем до него, и описать свои результаты. Критерии оптимизации разные. На хакатоне цель была на 90% построить систему, и только на 10% -- по остаточному принципу -- решить с лучшим качеством, потому что времени на эксперименты практически не было. Поэтому можно говорить о том, что это было состязание инженеров. Ну и бог с ним, поигрались и забыли. Но вы теперь, говоря об инженерии нейросетей, упускаете, что для достижения хороших результатов в практических задачах сегодняшнего дня, инженеров мало, нужен ещё и учёный, который исследует задачу и выберет подходящие методы для её решения. В советское время это называлось НИОКР -- научно-исследовательские и опытно-конструкторские работы. Так вот, у вас остались только последние две компоненты, и необходимость НИОКРа практически в каждой задаче для вас не видна, и мир у вас предсказуемый донельзя. Нету и близко такого -- отличным результатом считается качество 90%, и даже его бывает весьма сложно достигнуть. Нет ничего печальней, чем смотреть на инженеров, наобум втыкающих случайно выбранную нейросеть в каждую задачу.

Пошли тут по второму кругу. Для меня моделирование предметной области (метамоделирование!) -- наука, построение лучшей модели -- наука, построение лучшей системы (не путать систему и её модель!) -- инженерия, а нахождение лучшего метода -- методология (и у методологов есть довольно много про то, как они себя отличают от инженеров, учёных и даже философов). Мне тоже печально смотреть на инженеров, втыкающих случайно выбранную сетку в какую-то задачу. Инженерия давно использует не только метод проб и ошибок. Что касается публикаций в arxiv, то не всякая публикация научна, если её выложить в arxive. И, конечно, если у инженера есть дефицит знаний о том, как что-то делать, он обращается к методологии (или сам занимается этим, или идёт в библиотеку за методом, или методологов-консультантов приглашает), а если есть дефицит знаний о том, как описывать его предметную область, чтобы сначала создать модель и оптимизировать её, а только потом изготавливать систему, то он обращается к науке (или сам исследует, или идёт в библиотеку, или просит учёных). С точностью до того, что чисто в библиотеке ни метод ни наука не живут хорошо, обычно сохранение, накопление и передача соответствующих знаний требует участия живых людей.

И всё-таки нейросети втыкаются по большей части наобум. Только-только начинают появляться методы, которые снижают количество ошибок в выборе гиперпараметров (переводят гиперпараметры в параметры). Вот, например, ------------- Auto-Sizing Neural Networks: With Applications to n-gram Language Models Kenton Murray, David Chiang Neural networks have been shown to improve performance across a range of natural-language tasks. However, designing and training them can be complicated. Frequently, researchers resort to repeated experimentation to pick optimal settings. In this paper, we address the issue of choosing the correct number of units in hidden layers. We introduce a method for automatically adjusting network size by pruning out hidden units through ℓ∞,1 and ℓ2,1 regularization. We apply this method to language modeling and demonstrate its ability to correctly choose the number of hidden units while maintaining perplexity. We also include these models in a machine translation decoder and show that these smaller neural models maintain the significant improvements of their unpruned versions. http://arxiv.org/abs/1508.05051 ------------

Я понимаю ваше горячее желание уйти от науки, экспериментирования и подбора к чисто инженерии, но, мне кажется, это ещё долго не будет доступно массам (за исключением гугла и некоторых других, кто может себе позволить параллельно работающие кластеры из видюшек). Поэтому, поскольку полное пространство за достаточное время не перебрать, гиперпараметры обычно оптимизируются не автоматическим перебором, а комбинированными методами (скажем, подглядыванием за коллегами-единомышленниками).