×Закрыть

Данные важнее, чем модели. Как выглядят эффективные процессы в Data Science

Всем привет! Меня зовут Вадим, я Machine Learning Researcher в Wix. Работаю в продуктовых компаниях в сфере Data Science уже более шести лет. Занимался построением Machine Learning моделей и закрывал весь цикл Data Science проектов. Мне доводилось строить проекты для разнообразных бизнес-задач, а также в разных доменах ML & Deep Learning.

Для многих работа дата саентиста выглядит, как черный ящик. Но несмотря на разные задачи, процессы в проектах похожи, равно как и причины возникающих проблем. В этой статье я хочу поделиться своим опытом, рассказать, в чем же именно состоит работа специалиста по Data Science: какие этапы проходит проект, что должен делать дата саентист и как он взаимодействует с другими членами команды.

Материал будет интересен всем, кто хочет узнать, как выглядит процесс работы дата саентиста. Особенно полезно будет начинающим специалистам и тем, кто хочет перейти в Data Science, так как статья поможет сформировать правильные ожидания от работы.

Этапы Data Science проекта

В Data Science, как в других IT-направлениях, уже давно есть эффективные процессы структурирования проектов. Удивительно, но далеко не все дата саентисты догадываются об их существовании. Первый фреймворк был придуман в 1996 году и называется CRISP-DM (Cross industry process in data mining). Модной фразы Data Science тогда еще не было, и говорили просто Data Mining. Интересно, что за 24 года своего существования система все ещё актуальна. Появились новые процессы, более подходящие под текущие реалии, но они так или иначе базируются на CRISP-DM. Примером для больших команд может быть процесс Microsoft, а на Медиуме есть хорошая инструкция для стартапов.

Чтобы лучше понять, как же устроена работа дата саентиста, давайте за основу возьмем CRISP-DM и пройдемся по основным этапам этой методологии (я немного изменил оригинальную схему для лучшего воcприятия):

  1. Определение бизнес-необходимости проекта и установление KPI. Обдумать KPI — задача нетривиальная, поэтому над ней зачастую не заморачиваются. Но это может привести к очень неприятным последствиям, вплоть до закрытия проекта.
  2. Работа с данными, которые необходимо где-то взять, убедиться в их качестве и подготовить для тренировки. На этом этапе нужно «засучить рукава», забыть о моральном вознаграждении и очень скрупулезно поработать. Интересный факт, что для достижения хороших результатов на этот этап тратится около 80% общего времени. Проверено на личном опыте :)
  3. Построение модели, — наверное, самый приятный этап. Мне кажется, именно из-за него программисты часто хотят перейти в Data Science. Но опытные специалисты знают, что это опасное место, на котором можно зациклиться и потратить много времени зря.
  4. Оценка качества модели — самый критичный этап. Во время построения модели мы делаем множество итераций и экспериментов, слабые места есть всегда. От того, как мы их проработаем, зависит скорость развития проекта и его финальное качество.
  5. Вывод в продакшн — во многом инженерная часть, но тесно связанная с алгоритмами Machine Learning.

Правильная коммуникация в команде особенно важна для успеха Data Science проекта. Обычно Data Scientist ведет общение на двух фронтах — с продакт-менеджером и инженером. В маленьких компаниях из-за недостатка людей дата саентисту приходится дополнительно закрывать либо продуктовую, либо инженерную часть. В некоторых компаниях пытаются искать «идеального» специалиста во всех трех сферах, но «быть профессионалом везде = быть профессионалом нигде».

Давайте подробнее рассмотрим каждый из этапов жизни Data Science проекта.

Business understanding

Обычно внедрение ML-модели инициирует продакт-менеджер. В идеале, ее стоит внедрять в уже готовый проект для улучшения его качества. Если же предлагают использовать Data Science с самого начала и это не является ключевой частью бизнеса, то сперва стоит задать вопрос: а нужен ли он здесь вообще?

Проект с Data Science требует значительных затрат: как денежных, так временных. Это затраты на получение и обработку данных, проверку гипотез, построение модели, оценку качества, а также решения вопросов интеграции и мониторинга. В самом начале будет гораздо легче и быстрее обойтись без этого. Можно проанализировать рынок, придумать несколько базовых правил и на их основе запустить проект. И только когда этих правил станет слишком много и ими будет тяжело управлять, стоит задуматься об ML-алгоритме.

В чем его польза? Machine Learning алгоритм — это алгоритм, который проанализировал большое количество данных и на основе статистической выборки принимает решение для будущих примеров. Иными словами, на основе статистики алгоритм выбирает наиболее выгодное решение. Это как раз похоже на то, что делают продакт-менеджеры, когда анализируют рынок и составляют правила. Например, «если человек три дня не покупает у нас премиум, то давайте сделаем ему скидку». Просто для этих решений продакт-менеджеры проводят ручной анализ, а машина сделает это автоматически.

Допустим, что все-таки Data Science проект стоит делать. Первый и важный этап — установить бизнес-метрики для оценки полезности модели. В чем заключается нетривиальность этой задачи? При обучении моделей дата саентисты руководствуются техническими метриками, которые обычно имеют мало общего с бизнес-требованиями. Основная трудность состоит как раз в конверсии технической метрики в бизнесовую и определении KPI, при котором модель можно выводить в продакшн.

Почему это важно? Для формирования адекватных ожиданий как продакт-менеджера, так и дата саентиста. Продакт-менеджер, для которого моделирование выглядит как black box, не разочаруется из-за своих завышенных ожиданий. Дата саентист, в свою очередь, правильнее расставит приоритеты при оптимизации технических метрик.

Классический пример: продакт-менеджер хочет знать, кто из пользователей продукта купит премиум-услугу. Техническая метрика для дата саентиста: точность, с которой модель предсказывает покупателей. Однако какая бизнес-цель этой модели? Дать скидку маловероятным покупателям либо оказать дополнительную техподдержку высоковероятным? Где цена ошибки будет выше: перепутать премиума с непремиумом или наоборот? Каждая бизнес-задача имеет свои особенности, и именно под нее стоит составлять бизнес-метрики, которые выражаются в деньгах или конечной полезности.

Получение данных

Для того чтобы натренировать модель определять взаимосвязи, необходимо иметь размеченные данные. Это набор примеров с характеристиками и «правильный ответ» по каждому из примеров. Например, у вас есть информация по 10к пользователям и о том, что они делали на сайте, а также «ответ»: купили ли они премиум в течение месяца. Другой пример: текст комментария в фейсбуке и оценка его агрессивности от 1 до 10.

Отмечу, что не для всех задач нужны размеченные данные. Исключение — задачи unsupervised learning (например кластеризация).

Ключевой фактор результативности модели — качество данных! Если что-то не так с данными, модель выявит неправильные взаимосвязи, и результаты не будут отображать реальность, а полезность будет нулевая. В Data Science кругах ходит популярная фраза: «Garbage in = garbage out». Никакая модель не сможет дать правильное предсказание, если данные на вход были неправильными. Именно поэтому хороший дата саентист проводит гораздо больше времени, разбираясь в данных, нежели тестируя разные модели.

Сложность получения и подготовки данных напрямую зависит от проекта. А сам процесс может занимать от нескольких дней до нескольких месяцев.

Ниже рассмотрим основные источники получения размеченных данных.

Базы данных (логов) продукта

Возможно, это самый простой источник данных, однако и с ним может возникать много трудностей. Допустим, есть проект, на котором необходимо предсказать, когда пользователь перестанет пользоваться продуктом. Для этого необходимы поведенческие данные из логов. Но просто взять и вытащить данные из БД недостаточно. Что может испортить данные? Например:

  • в какой-то период часть ивентов не сохранялась в БД из-за бага;
  • программисты добавили новую фичу и не покрыли ее логами;
  • была изменена воронка регистрации, и стало регистрироваться больше пользователей.

Каждый из таких сценариев влияет на данные и, как следствие, влияет на распределения зависимостей для принятия решений. Например, если в продукте ввели новую сокращенную воронку регистрации, то зарегистрируется больше пользователей. Но в результате, процент заинтересованных пользователей будет размываться, и большее количество покинет сайт. Этот факт очень важен для построения модели, потому что профиль среднего пользователя поменялся. Задача дата саентиста как раз сводится к тому, чтобы при моделировании все такие взаимосвязи были отображены в данных.

Скрэйпить из интернета

Думаю, тут сложность очевидна: вытащить данные из разных источников и унифицировать их. Вдобавок к инженерной сложности соскрейпить данные возникает другая проблема. Часть данных может не иметь никакого отношения к моделированию, и определить и исключить эти данные — достаточно кропотливая работа. Допустим, для задачи необходимо вытащить заголовки текстов с разных сайтов. Как это сделать? Вытаскивать заголовки по тегам <h1>, <h2> недостаточно, потому что пользователь может обойтись без них и просто сделать для обычного текста шрифт побольше. Вытаскивать все тексты со шрифтом больше 32pt тоже нелогично, ведь на сайте может быть весь текст с таким шрифтом. То есть чтобы получить качественные данные, нужно выбирать текст, учитывая особенности каждой отдельной страницы.

Ручная разметка

Процесс получения таких данных самый долгий и дорогой. Эти данные нужны для задач, с которыми легко справляется человек, но они сложны для алгоритма. К таким сценариям относятся reCAPTCHA, поиск опухолей на МРТ, обведение силуэта автомобиля, оценка эмоции по голосу. Почему такие задачи сложны для алгоритма? Они решаются на так называемых «неструктурированных данных». Например, две картинки с котиками разного цвета и в разном масштабе будут иметь абсолютно разные значения пикселей, хотя они и остаются котиками. Для человека это одна и та же сущность, а алгоритму необходимо будет выяснить, что эти два разных набора пикселей — один и тот же объект.

При этом автоматически получить размеченные данные для тренировки невозможно. Поэтому для таких задач человек вручную размечает N примеров, а потом эти данные используются для тренировки алгоритма. Задача ручной разметки данных с 2014 года превратилась в отдельную огромную индустрию и продолжает расти. Есть множество компаний, которые занимаются разметкой ваших данных. Например, вы платите компаниям, чтобы они разметили автомобили на ваших видеороликах. По оценкам аналитических компаний, в 2018 году рынок аутсорса Data Labelling достиг $318 миллионов, и предсказывают рост до $1,5 миллиарда к 2025. А некоторые эксперты ожидают вдвое больший рост.

Подводя итог, могу сказать, что получение данных и их унификация — зачастую трудоемкая задача, которая требует предельного внимания и скрупулезности, а также много времени.

Моделирование

В чем суть тренировки модели? Если говорить просто: алгоритм — это набор коэффициентов, которые перемножают и суммируют входящие данные. Результирующее число должно быть ответом, который мы ищем. Размеченные данные для тренировки как раз и содержат «желаемый ответ». У нас также есть функция, которая считает «силу ошибки», и по ней мы знаем (спасибо школьным производным), как надо подправить коэффициенты, чтобы в следующий раз ответ был ближе к правильному. Поэтому, подавая в цикле много примеров, модель корректирует свои веса («обучается»), и будет готова давать предсказания для новых похожих данных.

К счастью, дата саентисту не нужно придумывать алгоритмы. Уже есть множество различных алгоритмов, которые могут справиться с практически любой задачей. Нам нужно знать их принципы работы и уметь применить уместный, чтобы это не было как «забивать гвозди микроскопом».

Выбор алгоритма влияет на то, как и какие данные необходимо собирать. Допустим, есть задача отсортировать «объекты» по качеству. Вот два разных способа, как разметить данные, от которых будет кардинально зависеть выбор модели:

  • каждому объекту давать оценку от 1 до 10 и потом усреднить результаты;
  • показывать объекты попарно и спрашивать, какой лучше.

В целом, для дата саентиста задача моделирования сводится к следующему:

  • исправить неточности в данных;
  • добавить новые признаки, чтобы облегчить задачу алгоритму (например, к длине и ширине объекта, добавить «площадь»);
  • выбрать подходящий алгоритм и параметры тренировки;
  • натренировать модель;
  • разобраться, в каких ситуациях модель допускает ошибки;
  • повторять до готовности.

Анализ ошибок модели — критический этап для успеха ML-проекта. Качественный анализ и классификация ошибок дает возможность определить корень проблемы. Часто проблема находится в данных: баг при препроцессинге, недостаточно данных, взаимосвязи в данных слишком сложны для модели. Причин может быть много.

Лучшая стратегия при моделировании — двигаться итерациями. Сперва стоит построить полный pipeline: от получения данных до конечного результата для клиента. При этом важно закрыть этот pipeline в самую первую очередь, и желательно, чтобы он был максимально простым с самой простой моделью. Дальше итеративно улучшаем его, каждый раз принимая решения, анализируя ошибки. Условно процесс должен выглядеть так:

Почему важно начать с самой простой модели? Чем проще модель, тем обычно она лучше объясняет, где были допущены ошибки, и благодаря этому гораздо легче определять, на чем фокусироваться дальше. Такому принципу следуют все крупные компании уровня Google, Amazon и Facebook. У Гугла есть на эту тему очень хорошие гайдлайны.

Один из грехов дата саентистов — потратить мало времени на анализ ошибок и вместо этого долго играться с параметрами модели. Потом пытаться применить более сложный алгоритм или построить ансамбль из алгоритмов, чтобы «усреднить» их предсказания. В итоге итерации сводятся к такому виду, как на рисунке. Упускается важный факт, что чаще всего ошибка в данных, ведь модель просто проецирует распределение данных. Если ошибка в данных, то будет ошибка и в предсказаниях. Двигаясь по такому циклу, хороших результатов можно и не получить в принципе.

При достижении каких-либо интересных результатов либо наоборот, когда прогресса нет, стоит обсудить статус модели с продакт-менеджером.

Оценка результативности и принятие решения

Обсуждая результаты модели с продакт-менеджером, важно понимать, что ответственность за выведение ML-модели в продакшн лежит именно на нем, и он должен быть уверен в качестве и предсказуемости результатов. Поэтому правильно объяснить результаты и принципы работы модели крайне важно. К тому же ошибки предсказаний, которые допускает модель и которые допустил бы человек, значительно отличаются. И вот когда продакт-менеджер видит ошибки, допущенные моделью, они кажутся ему нелепыми. А если он не понимает, почему так произошло, возникает недоверие к модели. Однако, когда человеку удается осознать, почему так произошло, эффект «загадки» пропадает, и барьер недоверия уменьшается.

По своему опыту обратил внимание, что коммуникация результатов очень подвержена такому когнитивному искажению, как Halo effect. (Из Википедии: результат воздействия общего впечатления о чём-либо на восприятие частных особенностей. Примером может служить впечатление, что у людей с привлекательной внешностью большие умственные способности.) Он работает как в позитивную, так и в негативную сторону. В связи с этим обсуждение текущих результатов модели создает определенную эмоциональную окраску для будущих оценок. Это влияет на принятие конечного решения. И даже если все ваши решения data driven, из-за неправильного донесения особенностей выход модели в продакшн может изрядно замедлиться (например, в середине проекта решают ужесточить ранее установленный KPI).

Другой интересный аспект — не все ошибки модели можно уловить с помощью метрик. И рекомендации продакт-менеджера по улучшению могут быть ценным источником информации. Яркий пример: в рекомендательных системах алгоритм зацикливается на одной-двух отраслях и рекомендует только их, что ведет к недостаточному разнообразию. Продакт-менеджер, который хорошо знает особенности продукта, поможет определить похожие вещи, в то время как дата саентист может упустить важность этой метрики и не оценить по ней качество модели.

Бывает, что качества модели недостаточно, чтобы выводить ее в продакшн. При этом нет четкого понимания, какие действия наверняка улучшат качество. Такая ситуация вероятна, так как Data Science проекты не имеют четко определенного пути к цели. Задача сводится к пониманию проблемы, составлению гипотез и разнообразным экспериментам. Причины неуспеха могут быть связаны как со сложностью задачи, так и с качеством и количеством данных. Умение признать нерешаемость задачи и найти достойный pivot — очень ценный навык. Хороший пример pivot`a от сложной к более простой задаче: не делать полноценную систему рекомендаций, а внутри каждой категории рекомендовать самый популярный продукт.

Выведение в продакшн

Многие менеджеры ожидают, что дата саентист сможет самостоятельно задеплоить модель в продакшн. Для некоторых несложных проектов это может быть вполне разумной задачей. Однако, чем сложнее проект и чем выше цена ошибки — тем критичнее участие инженера. Вот несколько причин, почему инженер может быть ключевым звеном для успешности Data Science проекта.

Данные для тренировки модели и для продакшна различаются. Это обычная ситуация. Например, для тренировки дата саентист брал данные из аналитической базы, а для продакшна нужны реал-тайм. В аналитической базе данные часто собираются из разных источников и проходят какую-то трансформацию. Соответственно, для продакшн-данных будет другой процесс подготовки и агрегации разных источников. Другой пример: для тренировки и оценки качества данные собираются в batch. Однако в продакшне данные могут приходить по одному, поэтому задача оптимизации и распараллеливания вычислений будет выглядеть совсем по-другому.

Оптимизация кода. Во время рисерча дата саентист обычно пишет «грязный» и неэффективный код. И это абсолютно нормальная ситуация, потому что построение модели — это экспериментальный и итеративный процесс. Дата саентист тестирует много идей, многие из них не срабатывают, поэтому большое количество кода меняется и удаляется. Каждый раз писать качественный код — большая трата времени. И только к моменту, когда модель дошла до статуса готовности выхода в продакшн, есть смысл оптимизировать код. Ускорение вполне может достигать 10-100 раз. И это хорошее место для вовлечения инженера.

Например, в Python есть библиотека Pandas, которая позволяет очень удобно манипулировать данными, но она работает медленно. На критических проектах в продакшне мы эту библиотеку выпиливаем полностью, однако без этой библиотеки на проверку гипотез мы бы тратили в несколько раз больше времени.

Автоматизация. Обновление моделей — часто болезненный этап для проекта. Сценариев для обновления обычно два — устаревание модели и выход новой версии:

  • Устаревание модели. Для некоторых проектов это естественная ситуация, так как меняется продукт, поведение пользователей, данные. Если модель привязана к «текущему состоянию проекта» — то для того, чтобы она еще долго оставалась полезной, ее нужно обязательно обновлять. Перетренировку модели на актуальных данных, сравнение качества и выливание в продакшн можно и желательно автоматизировать. Это можно делать и вручную, но тратить на это время — не очень эффективная стратегия.
  • Выход новой версии. Когда дата саентист приходит с новой версией модели, обычно, кроме самой модели, меняется и процесс обработки данных. А это ведет к необходимости дополнительной оптимизации, а также проверки эффективности по качеству и скорости. У нас на проекте был интересный use case с нейронной сетью, где на одном из этапов мы уменьшаем разрешение картинки. Для продакшна мы заменили библиотеку для преподготовки изображения с PIL на OpenCV. И вот одна и та же функция с одним и тем же названием bicubic_interpolation давала разницу примерно в ~7%. Несложно догадаться, что это значительно повлияло на качество :) Так что тесты и мониторинг — это правильный уровень maturity Data Science проекта. (По ссылке хороший набор критериев для оценки уровня развитости вашего Data Science проекта.)

Идеальный вариант обновления модели — через А/Б тест, когда одновременно крутится две версии, чтобы удостовериться, что все корректно работает. Такой вариант не всегда возможен, поэтому чаще идут более простым путем. Собирают небольшой набор тестовых данных, которые ни одна из моделей не видела и которые не использовались для оптимизации. Эти данные служат только для финальной проверки: действительно ли новая модель работает лучше.

Итоги

В Data Science проектах так же, как и других Software проектах, сложились свои, проверенные временем процессы. Если им следовать, шансы на успех значительно повышаются.

Ключевые идеи:

  • Важно понимать целесообразность использования Machine Learning для решения задачи.
  • Установление правильных бизнес-требований — ключ к успешному проекту.
  • Главная сложность и залог успеха — в получении качественных данных.
  • Данные гораздо важнее, чем модель!
  • Процесс моделирования состоит из проверки гипотез, и вполне вероятно, что ни одна из них не сработает.
  • Деплоймент модели в продакшн — отдельный и значимый этап, который требует дополнительной автоматизации и другого подхода к данным.

Спасибо за ваше время!

Интересные ссылки

LinkedIn

43 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Днями вийшла цікава стаття towardsdatascience.com/...​lls-for-2020-a5a53226b168
Є думка, що дослідникам даних варто знати Agile. Можливо варто прийти до певного симбіозу CRISP-DM зі Scrum, наприклад, щоб можна було разом з тімою девелоропів нарізати таски на спрінти в 1-3 тижні, трекати разом з усіма прогрес, релізитись, коротше синхронізуватись і жити в тому ж темпі, в мирі і злагоді з усіма стейкхолдерами)
Може хтось поділитись досвідом взаємодіє аналітиків з девелоперами і на скільки сумісні CRISP-DM та Agile у вашій практиці?

Есть такая шутка There is no science in data science

Ребят, привет. Подскажите, пожалуйста, возможные курсы по дата аналитике. Сейчас прохожу Data Science IBM на Курсере. Но сравнивать не с чем. Возможно, у вас есть что порекомендовать. Спасиб

Все що я нижче напишу суб’єктивно, не претендую на оптимальність такої дорожньої мапи, разом з тим я саме таким чином мігрував з розробки ПЗ в аналітику даних. Будь які поради і зауваження вітаються :) Можливо в твоєму випадку ти вже маєш певні знання і більшість моїх порад будуть вже зайвими :)

Підготовку я би умовно поділив на три складові:
— вивчення необхідних аналітику інструментів;
— вивчення певних розділів математики і статистики;
— безпосередньо сам DS і ML.

Хронологічного порядку тут не має, вчити можна в будь якому. Та і сам поділ умовний бо часто курси та книги в тій чи іншій мірі одночасно охоплюють і теорію, і інструменти, і безпосередньо DS та/або ML. Отже джерела:

Що стосується інструментів у моєму випадку це python, numpy, pandas, matplotlib, jupyter, sklearn, keras тощо.

Python я вчив по книзі та Stack Overflow :) На жаль забув назву книги, але мова популярна і книг та курсів 100500.

У Jupyter Notebook інтуїтивно зрозумілий інтерфейс і все досить просто, якісь курси не потрібні) До речі jupyter notebook не обов’язково ставити локально, достатньо мати інтернет і для швидких експериментів можна ранити його online, наприклад, на Google colab colab.research.google.com. Там вже є більшість базових для DS/ML python модулів і можна доставити потрібні, можна підключити Google диск і тримати там дані, є якась інтеграція з GitHub, загалом зручна штука.
Якщо хочеться переглянути notebook на GitHub, інколи GitHub тупить і не відображає їх, тоді лінку на файл на GitHub можна підгрузити і переглянути тут) nbviewer.jupyter.org

З Numpy можна ознайомитись тут habr.com/ru/post/352678
З Pandas тут m.habr.com/...​/company/ods/blog/322626
Та курс від Мічіганського університета, як юзати pandas та інші python ліби саме для дослідження даних ru.coursera.org/...​earn/python-data-analysis

Matplotlib та інші інструменти для візуального аналізу даних:
habr.com/...​/company/ods/blog/323210
Курс по візуалізації від Мічіганського університета
ru.coursera.org/learn/python-plotting
Курс по візуалізації від Анатолія Бондаренко (засновник та керівник порталу Texty.org.ua). В цьому курсі не має програмування, але це цікавий курс про те як краще візуалізувати дані, щоб візуалізація була зрозуміла іншим людям.
courses.prometheus.org.ua/...​s/IRF/DV101/2016_T3/about

sklearn. Цю лібу часто використовують в підручниках/курсах з основ ML, тому що вона надає високорівневе API, яке дозволяє користуватись багатьма алгоритмами класичного ML, не замислюючись над деталями реалізації чи деталями алгоритма. Хоча, якщо ви розберетесь з алгоритмами — це дозволить вам свідомо краще підбирати гіперпараметри моделі і це чудово) Отже sklearn і основи ML можна вивчити на курсі від Мічіганського університету www.coursera.org/...​ine-learning/home/welcome
Ще є розкішна книга видавництва O’Reilly www.oreilly.com/...​to-machine/9781449369880
Схоже тут можна зареєструватись та завантажити без СМС та з реєстрацією) www.twirpx.com/file/2164153

Ще про деякі алгоритми ML є цикл цікавих статей habr.com/...​/company/ods/blog/322534

Якщо на старті ви плутаєтесь в усьому зоопарку ML моделей, є статті які простою мовою без технічних деталей класифікують всі ці алгоритми
vas3k.ru/blog/machine_learning

Після знайомства з класичним ML, можна ознайомитись з Deep Learning.
Є курс від Олеся Петріва (крутий фахівець з VideoGorillas). Загалом курс по основам ML, але на останньому тижні розглядаються і приклади CNN та LSTM, з цього можна почати своє знайомтсво з Deep Learning.
courses.prometheus.org.ua/...​s/IRF/ML101/2016_T3/about
Ще э розкішна книжка Deep Learning with Python
eng drive.google.com/...​4debJXwkzgYrjp84xn-h/view
rus drive.google.com/...​CBZh5fG0MXTyyDekiGzy/view

Після того, як ви ознайомились з основами і поширеними моделями, при бажанні можна глянути на екзотичніші речі типу Reinforcement Learning, Fuzzy Logic, Genetic algorithm тощо. Деякі з них типу Reinforcement Learning можна розглядати як цілу спеціалізацію, глибоко дослідити і можливо зробити кар’єру як спеціаліст саме в цьому напрямку. Деякі, наприклад, Genetic algorithm можуть стати в нагоді у звичайному ML чи навіть простих статистичних моделях без навчання. Наприклад, для підбору гіперпараметрів чи параметрів моделі, якщо з якихось причин ваша цільова функція є не типовою, а своєрідною комплексною метрикою з конкретної предметної області, важлива для бізнесу, але з математичної точки зору вона не диференціюється і тому ви не можете оптимізувати параметри популярним градієнтним спуском.
Але це все скоріше подальший розвиток в сторону алгоритмів. Знайти першу роботу в DS/ML можна і без цього.

В принципі на цьому етапі немає поділу на спеціалізації типу Computer Vision, NLP, аналіз часових рядів тощо. Це загальні штуки які потрібно розуміти любому початківцю для пошуку роботи.

Власне сама робота — чудовим спосіб навчання новому :) Навіть якщо вас поки не беруть на роботу вашої мрії в Boston Dynamics, чи куди ви там хочете, спробуйте влаштуватись в якийсь стартап чи що. Скоріш за все ви там здобудете корисний досвід!

Ще крім засвоєння алгоритмів варто навчитись збирати та опрацьовувати дані. Веб скрапінг, інтеграція з API, перевірка невалідних/відсутніх значень, трансформація категоріальних ознак в кількісні чи навпаки, масштабування та нормалізація значень, генерація нових значень, наприклад з допомого moving average тощо. Загалом збір і опрацювання даних займає 80% і не менш важливі ніж розуміння алгоритмів. До речі для трансформації даних вам можуть згодитись знання з математики і статистики.

Якщо треба підтягнути знання зі статистики, є курс з основ описової та вивідної статистики: навчить що таке вибірка, медіана, дисперсія, розподіл, кореляція, p-value тощо
courses.prometheus.org.ua/...​IRF/Stat101/2016_T3/about
Цей курс передбачає знання мови програмування R
По R є курс (лінка нижче). Я не проходив його повністю, навіть половини достатньо, щоб читати приклади коду з курсу про статистику вище. Свої рішення я реалізовував на Python.

Курс по R stepik.org/course/497/promo

Якщо треба підтягнути знання з теорії ймовірностей, є курс від МФТІ на курсері www.coursera.org/...​heory-basics/home/welcome
Від них же є курси з комбінаторики, графів, теорії ігор тощо. Але це саме математичні курси, вони розповідають не тільки те, що практично застосовується в DS та ML. Але потім, коли будете розглядати алгоритм, наприклад, Naive Bayes класифікатора — знатимете звідки ноги ростуть)

З приводу матричного множення та диференціювання важко щось порадити, бо я це вивчив ще в ВНЗ.
Якщо є бажання попрактикуватись з диференціюванням мені свого часу став у нагоді сайт mathprofi.ru
Але на мою думку для початкового рівня знайомства з DS та ML це занадто. Є прикольна книжка, де автор нагадує що таке матричне множення і диференціювання і в той же час демонструє для чого вони потрібні в ML, реалізуючі from scratch просту нейронну мережу www.yakaboo.ua/...​v_4Xm0WrXHARoCysUQAvD_BwE
Просте зрозуміле пояснення, але книжку не всі будут купувати, тож feel free гуглити статті на DOU, наприклад :)

До речі з приводу купівлі книжок, порада для тих хто з Дніпра і любить паперові книжки, є класний книжковий магазин «Скорпіон», де можна знайти гарні книжки про Machine Learning та Big Data.

Є ще купа ресурсів, які корисно відвідувати для тренування і навчання:
www.kaggle.com
arxiv.org
towardsdatascience.com
machinelearningmastery.com
тощо

Наостанок додам, що окрім самостійного навчання по книгам та окремим онлайн курсам, може бути корисно знайти ментора, гарний офлайн курс чи широкий послідовний онлайн курс, який проведе вас крок за кроком через всі потрібні знання для створення повного pipeline роботи з даними, від збору даних, до їх очистки, аналізу, підготовки фіч для тренування, до вибору самої моделі, тренування її, тюнінгу і оцінки результатів. Можливо ще зберігання даних і розгортання всього цього добра. Власне кожен степ того workflow, які розглядаються в цій статті на DOU. Такі об’ємні курси сформують цілісну картину.

З оффлайн курсів можу порадити Hillel ithillel.ua
У них можуть бути курси в різних містах України, залежно від того чи набереться в вашому місті група бажаючих. Ймовірно якість і програма курсу залежить від того, хто викладає. В мене був викладач Олександр Коробов (Київ) і мені дуже сподобалось.
І ще для тих хто з Дніпра, у вас є компанія ISD, яка спільно з SOLVVE іноді проводять безкоштовні курси з ML. Не впевнений що у них це якісь систематичні курси, можливо вони їх проводять коли є потреба когось навчити і взяти до себе на роботу найкращих з групи. Переглядайте об’яви на їх FB сторінці www.facebook.com/isditcompany

Власне у мене все. Буду радий почитати ваші зауваження. Особливо цікаво почитати досвід міграції в DS чи ML тих хто так само спершу працював розробником, бізнес аналітиком тощо. І тих хто цілеспрямовано навчався саме на аналітика даних, статистика, математика, можливо я упускаю якісь важливі знання/скіли, які дає академічна освіта. І тих хто вже давно працює в цій галузі, які ще скіли корисно розвивати для професійного росту?
Можливо, якщо буде час і натхнення, структурую свій лонгрід, врахую зауваження і зроблю повноцінну статтю)

Евгений, огромная благодарность за такой развернутый ответ! Это больше, чем я ожидал))

Записал и учел все рекомендации. До вашего ответа, еще пару недель назад, начал курс на Курсере «IBM Data Science», а также тот курс по статистике и анализу данных на Прометеусе. Курс IBM знакомит меня с Jupiter, Zeppelin, RStudio. Языки не знаю. Год назад смотрел курс по SQL с практическим онлайн софтом, но до конца не дошел (не было практической мотивации).

На днях буду нырять в ваши ссылки. Языки R, Python буду учить после курса статистики и, наверное, в середине курса IBM.

"

поки не беруть на роботу вашої мрії в Boston Dynamics

" так высоко не мечу :D Всего-лишь хочу перейти из стратегического маркетинга в аналитический маркетинг и поработать с big data в спотифай или твиттере, например.

Еще раз, большое спасибо за такой ответ. Точно нужно писать сатью!)

Дякую за статтю. Лаконічно, але разом з тим змістовно і гарно написано

Спасибо за статью. Мне была полезна книга Andrew Ng „Machine learning yearning” — на ее основе создан вот этот курс www.coursera.org/...​ing-projects/home/welcome

Не совсем понял что происходит с Pandas на проде. Выпиливается за ненадобностью или заменяется чем-то?

Выпиливается. Надобность pandas — его удобство для рисерча.
Но когда перформанс в продакшн важен, выпиливание pandas — первое место для оптимизации

Если можете, расскажите подробнее, пожалуйста. Что именно медленно работает в пандас и в каких условиях /нагрузках, и на что вы его заменяете. Спасибо!

Ольга, я частично ответил на ваш вопрос в соседнем комментарии.

Принятия решений оптимизации production performance, там где есть pandas — это уже вне моей компетенции, но теперь это будет актуальной тема для инженерного блог-поста :)

Спасибо! Было бы очень интересно почитать инженерный блог-пост на эту тему. Потому что, честно говоря, из комментария не совсем ясно, в чем проблема пандас, и как ее исправлять. Я один раз сталкивалась на практике с медленной работой пандас, но там скорее проблема была как раз в типах данных, а не в самом пандас (добавление строк в датафрейм было заменено на наполнение словаря, который потом одной операцией был преобразован в датафрейм)

Тоже не совсем ясно, что в пандас работает медленно. Может стоит не выпиливать пандас, а сначала попробовать оптимизировать код и типы данных?

Одна из проблем pandas, что его очень легко неправильно использовать, если не знать всех принципов работы. И этим регулярно злоупотребляют data scientist`ы. (Мое личное наблюдение). В таком случае performance резко падает. И да, один из вариантов — оптимизация кода и типов данных. На некоторых проектах — это чисто инженерное решение. К сожалению, детального сравнения оптимизированного кода c pandas и кода без него у меня нет.

А в случае, когда данных уже много и их надо параллелизировать — то тут точно надо искать альтернативы. (Spark/dask, etc)

ВСЕГДА МЛ проект надо начинать с источников данны и ETL! Моделями надо заниматься когда уже есть датафлоу со всеми данными, автоматическа оценка перфоманса разных версий модели (AB testing, ROC, FP, FN, TP, TN, F1 etc) и автоматический грин-блу деплоймент

У Google на Coursera есть курс по ML (я не могу сказать что хороший так как некоторые трюки, например embedding, они упоминают вскользь), в этом курсе целую неделю рассказывали о бест практис построения флоу для ML. Я сам работал на 2х проектах по МЛ где всем рулили датасайнтисты — поэтому в ральности никаких бестпрактис, а дикий трешак, так как максимум их инженерных скилов — обучить/разработать модель у себя на маке и завернуть ее в докер, то как эти данные получать и как обеспечить перфоманс по вычислительной ресурсам и как CI/CD сделать знаний не хватает, более того когда предлагается феншуйное решение, оно отвергается, так как они его не могут понять или не знают матчасти.
Мой вывод — если есть данные, которые хоть как то коррелируют с требуемым результатом, то можно практически ВСЕГДА построить модель с приемлемым перфомансом. Но если нет нормального ETL на Спарк/Кафка/Хадуп/Cloudwatch/ELK (нужное подчеркнуть) то все сайнтисткие модели ДО ЛАМПОЧКИ. Так как в процессе часто выясняется, что те данные которые используются в модели могут быть получены только после того момента на который нужно предсказание этой самой модели...

Не знаю даже на первой работе без опыта я занимался вопросами как будет работать модель на инференсе, какие данные буду получать, надо ли их фильтровать и тд. То есть я знал полностью структуру проекта и что с меня хотят.

У нас на проекте был интересный use case с нейронной сетью, где на одном из этапов мы уменьшаем разрешение картинки. Для продакшна мы заменили библиотеку для преподготовки изображения с PIL на OpenCV. И вот одна и та же функция с одним и тем же названием bicubic_interpolation давала разницу примерно в ~7%

Можно чуть подробней. Интересует вход и выход, а так же параметры преобразования.

Взять несколько картинок. Уменьшить их bicubic обеими библиотеками, сравнить результат по MSE

У bicubic алгоритма сжатия картинки очень много параметров, при этом часть из них не передаются в виде входных параметров в этих библиотеках, а просто зашиты внутри. А еще алгоритм уменьшения картинки по разному работает даже в разных версиях опенСВ ...

я как-то для интереса менял типы интерполяции в предпроцесинге ( би-линейная, по площади, по ближайшим пикселям), но в рамках таких изменений конфиденс детектов для мобайлНет (претрейн на МСКОКО) гулял всего на 1-2%, а общая точность детектов не упала ...
Думаю, что тут дело в том, что в самом МСКОКО очень много разных картинок, которые уже уменьшены каким-то алгоритмом, отсюда большая устойчивость нейронки к таким изменениям.

@Vadim Boikov, можете придумать новый тип аугментации данных: учить нейронку на одних и тех же картинках, но с разными алгоритмами сжатия, Вы ж ведь не знаете какую картинку пользователь загрузит в ваш продукт ( каким алгоритмом сжатия она была обработана перед этим)

Это то , к чему мы в итоге и пришли :)

На счёт 1-2% — тут же ещё зависит степень сжатия. Можно уменьшить картинку на 10%, а можно и в 2 раза. Тут будет ситуативно от оригинального размера

у меня было сжатие с 1024×768 на 224×224 :)

Вообще правильно перед доунсемплингом еще пройти фильтром и удалить нафиг все высокие частоты. Нужно просто вспомнить товарища Котельникова.
Но кто нынче его помнит, запустили интреполяцию и удовлетворились, потом обнаруживают, что чего-то не того получилось.

категорически СОГЛАСЕН :)

Более того, после правильного удаления высоких частот в случае даунсемплинга на собственно интерполяцию уже пофиг почти. Ошибка интерполяции легко считается.

Но я такого не видел при обработке картинок, вообще не видел. Когда говорил, что необходимо, то современные украинские, не знаю, как их назвать даже, смотрели на меня большими и круглыми глазами, типа зачем. В туториалах такого не показывают.
Считали меня старым пердуном из прошлого века с странностями.

А ЦОС они никогда не учили, но питон знают отлично.
Кстати в большинстве туториалов и учебников современных по извращениям с картинками о Котельникове и Найквесте тоже забыли.

А в звуке за ресемплинг без фильтрации всегда били и сильно таких молодых.

главное не переусердствовать, а то вдруг высокие частоты означают что-то важное в рамках этой конкретной задачи ( например, в рамках задачи super resolution )

А теперь мне у тебя спросить теорему Котельникова?
Или в визуальных образах ее уже отменили?

Знаю. Жыпег с большим коэффициентом сжатия и всеми его артефактами. А потом датасатанист еще ближайшим соседом даунсемплит до 224×224.
А часто еще раз 5 жыпегом пережато будет.

Самое смешное, что на полученной картинке часто даже человек не разберет, что там было.

У нас на проекте был интересный use case с нейронной сетью, где на одном из этапов мы уменьшаем разрешение картинки. Для продакшна мы заменили библиотеку для преподготовки изображения с PIL на OpenCV. И вот одна и та же функция с одним и тем же названием bicubic_interpolation давала разницу примерно в ~7%. Несложно догадаться, что это значительно повлияло на качество :)

Потому что алгоритмы обучения нейронной сети по определению неустойчивы и обучаются на локальный минимум целевой функции. В результате малое изменения входных данных приводит к большому изменению в результате работы нейронной сети. Ну вот так вот сейчас все забили на основные требования в выч мате к устойчивости алгоритмов.

А могу напомнить древнейший пример по моделированию хим реакций. Там простейшая система ОДУ. В решении нам всего-лишь нужно решить систему линейных уравнений. И вот тут появляется число обусловленности матрицы. С малым им все отлично и просто. А вот с большим все плохо и очень — а такие почти все хим реакции. При дохлых компах в советской время математики дохрена сил потратили, чтобы придумать устойчивые алгоритмы. Но сейчас их никто не юзает, а зачем.

Ну и по тому абзацу на который я отвечаю. Вы плохо обучили нейронку или плохо ее спроектировали.

Спасибо за статью, простыми словами о сложном. Как раз вчера прочел ‘Machine learning for dummies’)

Очень хорошая статья, спасибо!

Про feature engineering ни слова. А ведь на сырых (даже очищенных и нормализоыанных данных) далеко не уедешь. Этап порой поинтереснее, чем само моделирование!

А как же:

добавить новые признаки, чтобы облегчить задачу алгоритму (например, к длине и ширине объекта, добавить «площадь»);

?

Это очень скудно) да и добавляются они не с целью кому-то что-то облегчить

Как раз-таки облегчить. Например, пока все не перешли на нейронные сети, в computer vision только и занимались что придумывали kernel’ы. Что в каком-то роде и есть feature engineering.

Антон, спасибо, хороший поинт. Я неявно подразумевал, что этот пункт входит как раз 80% времени работы с данными.
Feature engineering достаточно уникален для каждого проекта, поэтому и не уделил ему достаточно внимания в статье. Но да, вы правы, без фичей далеко не уедешь :)

Так сейчас же мода на end-to-end решения, если вручную отбирать фичи в computer vision или STT, тогда Вам лет на 7 в прошлое. В более классических задачах типа скоринга заемщиков это в принципе еще нужно. А так вполне хватает фильтрация «плохих даных» типа битых файлов, слишком долгих файлов(для STT) и тд

В STT все еще достаточно популярен ручной отбор фичей, DL начинает его превосходить начиная только с очень больших размеров корпусов.

Подписаться на комментарии