Совершенно правильное направление предлагаете. Но портирование numpy в PHP выглядит как костыль.
Более верным было бы сделать нативное расширение. Например, используя Eigen + php-cpp
Все кто занимаются анализом данных рано или поздно приходят к пониманию, что золото в правильном извлечении признаков.
Я не так давно писал похожую статью. Общий смысл тот же самый.
Подготовка данных это не просто важная часть построения модели. Она важнейшая.
Про эту часть не расскажут на курсах и не напишут в книгах. Что бы понять как это работает нужен реальный опыт. Конкурсные задачи его не дадут, т.к. использование готовых датасетов не способствует прокачке этого навыка.
К вашей статье добавил бы, что даже при качественной проработке признаков использование сильных алгоритмов предпочтительнее слабых.
Ну то есть даже если вы идеально проработали признаки, логистическая регрессия всё равно может быть хуже просто потому что ей не хватает нелинейности.
Но посыл вашей статьи — уделить больше внимания признакам чем выбору модели совершенно правильный.
RocksDB использую уже давно. Я как-то писал о своей серверной обёртке над RocksDB, позволяющей использовать её на бэкенде как NoSQL решение. С тех пор у меня появились рабочие проекты на ней.
Работает очень стабильно. Ни разу не было проблем. Даёт потрясающую производительность.
Давно наблюдаю за развитием MyRocks. К сожалению, в последнее время не использую MySQL. Так что, MyRocks попробовать не довелось. Но, зная качество фэйсбучных продуктов, не сомневаюсь что проблем с ней не будет.
Собственно, статья об этом.
Логарифм хорошо использовать, когда значения переменной отличаются на порядки. В этом случае, логарифм будет характеристикой порядка.
Если есть периодичность, тригонометрические функции. Можно использовать преобразование Фурье, вейвлеты, дискретное косинусное преобразование и т.п.
Иногда данные можно представить в виде дерева. Обработка деревьев — это вообще отдельная тема. На деревьях много фич появляется. Про них можно отдельную статью писать.
Если есть какой-то текст, то тоже можно много дополнительной информации вытащить. По частотам, по группам слов и т.п.
Вот один из моих примеров понижения размерности автокодировщиком: 3039 -> 213 -> 56 -> 15
Если в конец добавить ещё 15 -> 3 то можно визуализировать результат и посмотреть распределение.
Можно пожалуйста подробнее о том как работать имея небольшое количество размеченных данных и большое количество неразмеченных данных?
Смысл в том что бы использовать понижение размерности.
Можно использовать классический PCA, но лучше использовать автокодировщики. Автоэнкодеры умеют улавливать нелинейность в данных, а не просто удалять компоненты с минимальной дисперсией.
Как это работает.
Берём большой набор неразмеченных данных. Строим автоенкодер. Автоенкодер принимает на вход вектор всех ваших фич и даёт вектор небольшой размерности 10-30. Результат работы автокодировщика добавляется к фичам.
Автокодировщик можно строить разными способами. Тут сложно дать какие то универсальные рекомендации.
Я обычно использую автокодировщики с 4-мя скрытыми слоями. Что-то вроде такого:
Функции активации могут быть другими. Всегда есть relu, а его расположение может меняться.
Вторую половину выкидываю и выход после H2 -> tanh беру как выход автокодировщика.
Можно понижать размерность в несколько этапов.
Допустим так 3000 -> 2100 -> 1000 -> 15
Причина поэтапного понижения размерности в том, что из-за затухания градиентов, вы не можете сделать автокодировщик сразу слишком глубоким.
Какие-то универсальных рекомендаций дать не могу. Нужно экспериментировать.
При использовании автоэнкодера нужно учитывать следующие нюансы:
1) Автокодировщик находит внутренние закономерности. Его выход невозможно объяснить. Это просто какой-то вектор. Как его интерпретировать не понятно.
2) Автокодировщик теряет информацию. Поэтому строить прогноз только на его выводе нельзя. Чем сильнее понижается размерность, тем больше информации он теряет.
3) Если понижать размерность поэтапно, то каждый следующий автокодировщик будет иметь намного меньшую ёмкость по сравнению с предыдущим.
Рассчитывать этапы понижения нужно с учётом ёмкости каждого автокодировщика и объёма имеющихся неразмеченных данных.
Сложно проверить хорошо сработал у вас автокодировщик или плохо. Можно косвенно оценивать по качеству аппроксимации исходного набора. Но качество полученных в результате фич оценить сложно.
Но он точно работает, потому что результаты автоенкодера часто выходят у нас в топ FI.
И второй вопрос который пришел сегодня в голову. Как быть и можно ли что-то придумать если данные размечены некачественно. Положим требования к параметрам для попадания в какую-либо категорию менялись из года в год с ростом бизнеса и изменением внешних факторов.
Вот это сложный для меня вопрос. Реальные данные часто грязные. Как быть не знаю. Пытаться исправить качество разметки, разве что. Самому интересно, есть ли какие то рецепты на этот счёт.
Ребят, сделайте нормальную документацию к C++ API и люди к вам потянутся.
Отрасль уже готова выйти за рамки Питона и Луа.
Вы сравниваете CNTK с TensorFlow. Но все кто хоть немного поработал в отрасли уже знают о больячках TensorFlow. И это сравнение не выглядит убедительным.
Сейчас CNTK — просто ещё один фреймворк на Питоне и, внезапно, BrainScript.
Киллер-фич по сравнению с Torch, Caffe или тем же Teano не видно.
И опять, нет ясной и удобной документации C++, а это как раз то, чего не хватает остальным мейнстримовым фреймворкам.
Немного запоздало, но всё же внесу свои 5 копеек.
Тоже, как и коментаторы выше остановился на tiny-dnn.
Простой и логичный интерфейс. Если какие-то вещи не документированы, то действительно легко (а не как в Caffe) найти их в исходниках.
Например, автор поста упоминает отсутствие возможности остановки обучения. Тоже сталкивался с этой проблемой. Пять минут обзора исходников и вуаля:
Ещё tiny-dnn легко расширяется. Можно создавать свои функции ошибки, свои слои и т.п.
Из недостатков можно отметить жутко большое время компиляции; отсутствие GPU.
Некоторые архитектурные решения показались мне спорными. Но в сравнении с тем, что есть в других фреймворках, они всё равно на голову выше.
Очень удобная возможность загружать свои модели в json.
Особенно, когда приходится работать с ансамблями моделей и отбором моделей.
Для многих задач машинного обучения все недостатки с лихвой компенсируются простотой и удобством.
Пользуясь случаем, хочу спросить. Планируется ли появление полноценной документации?
Вроде бы интересный и перспективный фреймворк, но без документации что-то на нём делать не представляется возможным.
То что есть на текущий момент выглядит весьма уныло.
Ну тут ответ очень стандартный. Никаких предметно-специфических вещей не добавляется.
Главная причина — код пишут для людей, а не для компьютеров.
Рано или поздно ваш код прочитает ваш коллега. И если вы писали для людей, то получите меньше проклятий в свой адрес. Вы сами через пол года можете забыть что означала эта ksi.
Вам или вашему коллеге может быть просто нужно внести небольшие изменения в код — добавить новые фичи. И тут выясняется что для этого вам нужно прочитать статью в 20 страниц, на которую у вас прямо сейчас просто нет времени. И все это только для того что бы понять что же на самом деле скрывается за именем пременной ksi.
Если вы хардкодите константы в коде, то у того, кто будет читать код не может быть уверенности в том что таже самая константа не захардкожена в другом месте. И как её менять? Просматривать весь код на наличие константы 64? А вдруг в другом месте другая 64? А что это вообще за 64? Ах, да! нужно прочитать статью, которая прилагается в pdf файле к коду.
На хабре тема write-only кода поднималась тысячу раз. Мне даже как-то неловко поднимать её в 1001-й раз.
В заголовке затронута важная тема. Но решение, на самом деле не предоставлено.
Поэтому пользуясь случаем, обращаюсь к сообществу. Просто мой крик души. Пожалуйста, если вы занимаетесь машинным обучением и пишите код, который будут читать другие люди, следуйте простым и общеизвестным правилам. Особенно, если используете скриптовые языки без строгой типизации, такие как Python и Lua.
В частности,
1) не используйте магические константы (64 в статье).
2) используйте самоназывающие имена переменных (имя переменной 'ksi' и ссылка на статью, где эта переменная расшифровывается — не вариант).
3) не экономьте место, разделяйте блоки на логические части.
4) комментируйте код.
5) (самое важное) аннотируйте сигнатуры функций и методов — параметры и возврощаемые значения
Большая и очень полезная работа была проделана.
Огромное вам спасибо!
В каком месте вы увидели проверку на равенство double переменных?
у меня вот такая команда повешена на хоткей
Заменяет "раскладку" текста в буфере обмена. в обе стороны
Годнота!
Вот такие статьи по ML хочу видеть на Хабре.
Для этого Leonardo нужна
А какие задачи решит ваша библиотека? С какой целью она создавалась?
Совершенно правильное направление предлагаете. Но портирование numpy в PHP выглядит как костыль.
Более верным было бы сделать нативное расширение. Например, используя Eigen + php-cpp
Все кто занимаются анализом данных рано или поздно приходят к пониманию, что золото в правильном извлечении признаков.
Я не так давно писал похожую статью. Общий смысл тот же самый.
Подготовка данных это не просто важная часть построения модели. Она важнейшая.
Про эту часть не расскажут на курсах и не напишут в книгах. Что бы понять как это работает нужен реальный опыт. Конкурсные задачи его не дадут, т.к. использование готовых датасетов не способствует прокачке этого навыка.
К вашей статье добавил бы, что даже при качественной проработке признаков использование сильных алгоритмов предпочтительнее слабых.
Ну то есть даже если вы идеально проработали признаки, логистическая регрессия всё равно может быть хуже просто потому что ей не хватает нелинейности.
Но посыл вашей статьи — уделить больше внимания признакам чем выбору модели совершенно правильный.
Как раз сейчас читаю вашу книгу. Статья — прекрасное дополнение к ней.
RocksDB использую уже давно. Я как-то писал о своей серверной обёртке над RocksDB, позволяющей использовать её на бэкенде как NoSQL решение. С тех пор у меня появились рабочие проекты на ней.
Работает очень стабильно. Ни разу не было проблем. Даёт потрясающую производительность.
Давно наблюдаю за развитием MyRocks. К сожалению, в последнее время не использую MySQL. Так что, MyRocks попробовать не довелось. Но, зная качество фэйсбучных продуктов, не сомневаюсь что проблем с ней не будет.
Собственно, статья об этом.
Логарифм хорошо использовать, когда значения переменной отличаются на порядки. В этом случае, логарифм будет характеристикой порядка.
Если есть периодичность, тригонометрические функции. Можно использовать преобразование Фурье, вейвлеты, дискретное косинусное преобразование и т.п.
Иногда данные можно представить в виде дерева. Обработка деревьев — это вообще отдельная тема. На деревьях много фич появляется. Про них можно отдельную статью писать.
Если есть какой-то текст, то тоже можно много дополнительной информации вытащить. По частотам, по группам слов и т.п.
Вот один из моих примеров понижения размерности автокодировщиком:
3039 -> 213 -> 56 -> 15Если в конец добавить ещё
15 -> 3то можно визуализировать результат и посмотреть распределение.Смысл в том что бы использовать понижение размерности.
Можно использовать классический PCA, но лучше использовать автокодировщики. Автоэнкодеры умеют улавливать нелинейность в данных, а не просто удалять компоненты с минимальной дисперсией.
Как это работает.
Берём большой набор неразмеченных данных. Строим автоенкодер. Автоенкодер принимает на вход вектор всех ваших фич и даёт вектор небольшой размерности 10-30. Результат работы автокодировщика добавляется к фичам.
Автокодировщик можно строить разными способами. Тут сложно дать какие то универсальные рекомендации.
Я обычно использую автокодировщики с 4-мя скрытыми слоями. Что-то вроде такого:
Функции активации могут быть другими. Всегда есть
relu, а его расположение может меняться.Вторую половину выкидываю и выход после
H2 -> tanhберу как выход автокодировщика.Можно понижать размерность в несколько этапов.
Допустим так
3000 -> 2100 -> 1000 -> 15Причина поэтапного понижения размерности в том, что из-за затухания градиентов, вы не можете сделать автокодировщик сразу слишком глубоким.
Какие-то универсальных рекомендаций дать не могу. Нужно экспериментировать.
При использовании автоэнкодера нужно учитывать следующие нюансы:
1) Автокодировщик находит внутренние закономерности. Его выход невозможно объяснить. Это просто какой-то вектор. Как его интерпретировать не понятно.
2) Автокодировщик теряет информацию. Поэтому строить прогноз только на его выводе нельзя. Чем сильнее понижается размерность, тем больше информации он теряет.
3) Если понижать размерность поэтапно, то каждый следующий автокодировщик будет иметь намного меньшую ёмкость по сравнению с предыдущим.
Рассчитывать этапы понижения нужно с учётом ёмкости каждого автокодировщика и объёма имеющихся неразмеченных данных.
Сложно проверить хорошо сработал у вас автокодировщик или плохо. Можно косвенно оценивать по качеству аппроксимации исходного набора. Но качество полученных в результате фич оценить сложно.
Но он точно работает, потому что результаты автоенкодера часто выходят у нас в топ FI.
Вот это сложный для меня вопрос. Реальные данные часто грязные. Как быть не знаю. Пытаться исправить качество разметки, разве что. Самому интересно, есть ли какие то рецепты на этот счёт.
Ребят, сделайте нормальную документацию к C++ API и люди к вам потянутся.
Отрасль уже готова выйти за рамки Питона и Луа.
Вы сравниваете CNTK с TensorFlow. Но все кто хоть немного поработал в отрасли уже знают о больячках TensorFlow. И это сравнение не выглядит убедительным.
Сейчас CNTK — просто ещё один фреймворк на Питоне и, внезапно, BrainScript.
Киллер-фич по сравнению с Torch, Caffe или тем же Teano не видно.
И опять, нет ясной и удобной документации C++, а это как раз то, чего не хватает остальным мейнстримовым фреймворкам.
Немного запоздало, но всё же внесу свои 5 копеек.
Тоже, как и коментаторы выше остановился на tiny-dnn.
Простой и логичный интерфейс. Если какие-то вещи не документированы, то действительно легко (а не как в Caffe) найти их в исходниках.
Например, автор поста упоминает отсутствие возможности остановки обучения. Тоже сталкивался с этой проблемой. Пять минут обзора исходников и вуаля:
Использовать его можно как то так:
Ещё tiny-dnn легко расширяется. Можно создавать свои функции ошибки, свои слои и т.п.
Из недостатков можно отметить жутко большое время компиляции; отсутствие GPU.
Некоторые архитектурные решения показались мне спорными. Но в сравнении с тем, что есть в других фреймворках, они всё равно на голову выше.
Очень удобная возможность загружать свои модели в json.
Особенно, когда приходится работать с ансамблями моделей и отбором моделей.
Для многих задач машинного обучения все недостатки с лихвой компенсируются простотой и удобством.
Да там вcё не очевидно сделано. Мне в итоге прямо на почту ссылка пришла.
Пользуясь случаем, хочу спросить. Планируется ли появление полноценной документации?
Вроде бы интересный и перспективный фреймворк, но без документации что-то на нём делать не представляется возможным.
То что есть на текущий момент выглядит весьма уныло.
Вы взяли https://github.com/jcjohnson/torch-rnn
Сравнивали вот с этой библиотечкой https://github.com/Element-Research/rnn?
Если да, можете пару слов сказать о ваших впечатлениях. Какая удобнее, качественнее вам показалась и почему.
Ну тут ответ очень стандартный. Никаких предметно-специфических вещей не добавляется.
Главная причина — код пишут для людей, а не для компьютеров.
Рано или поздно ваш код прочитает ваш коллега. И если вы писали для людей, то получите меньше проклятий в свой адрес. Вы сами через пол года можете забыть что означала эта
ksi.Вам или вашему коллеге может быть просто нужно внести небольшие изменения в код — добавить новые фичи. И тут выясняется что для этого вам нужно прочитать статью в 20 страниц, на которую у вас прямо сейчас просто нет времени. И все это только для того что бы понять что же на самом деле скрывается за именем пременной
ksi.Если вы хардкодите константы в коде, то у того, кто будет читать код не может быть уверенности в том что таже самая константа не захардкожена в другом месте. И как её менять? Просматривать весь код на наличие константы
64? А вдруг в другом месте другая64? А что это вообще за 64? Ах, да! нужно прочитать статью, которая прилагается в pdf файле к коду.На хабре тема write-only кода поднималась тысячу раз. Мне даже как-то неловко поднимать её в 1001-й раз.
В заголовке затронута важная тема. Но решение, на самом деле не предоставлено.
Поэтому пользуясь случаем, обращаюсь к сообществу. Просто мой крик души.
Пожалуйста, если вы занимаетесь машинным обучением и пишите код, который будут читать другие люди, следуйте простым и общеизвестным правилам. Особенно, если используете скриптовые языки без строгой типизации, такие как Python и Lua.
В частности,
1) не используйте магические константы (64 в статье).
2) используйте самоназывающие имена переменных (имя переменной 'ksi' и ссылка на статью, где эта переменная расшифровывается — не вариант).
3) не экономьте место, разделяйте блоки на логические части.
4) комментируйте код.
5) (самое важное) аннотируйте сигнатуры функций и методов — параметры и возврощаемые значения