Джерело:
Интересное на ДОУ
Дата публікації:
14/01/2020 13:00
Постійна адреса новини:
http://www.vsinovyny.com/6528500
14/01/2020 13:00 // Интересное на ДОУ
Всем привет! Меня зовут Вадим, я Machine Learning Researcher в Wix. Работаю в продуктовых компаниях в сфере Data Science уже более шести лет. Занимался построением Machine Learning моделей и закрывал весь цикл Data Science проектов. Мне доводилось строить проекты для разнообразных бизнес-задач, а также в разных доменах ML & Deep Learning.
Для многих работа дата саентиста выглядит, как черный ящик. Но несмотря на разные задачи, процессы в проектах похожи, равно как и причины возникающих проблем. В этой статье я хочу поделиться своим опытом, рассказать, в чем же именно состоит работа специалиста по 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приятия):

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

Допустим, что все-таки Data Science проект стоит делать. Первый и важный этап — установить бизнес-метрики для оценки полезности модели. В чем заключается нетривиальность этой задачи? При обучении моделей дата саентисты руководствуются техническими метриками, которые обычно имеют мало общего с бизнес-требованиями. Основная трудность состоит как раз в конверсии технической метрики в бизнесовую и определении KPI, при котором модель можно выводить в продакшн.
Почему это важно? Для формирования адекватных ожиданий как продакт-менеджера, так и дата саентиста. Продакт-менеджер, для которого моделирование выглядит как black box, не разочаруется из-за своих завышенных ожиданий. Дата саентист, в свою очередь, правильнее расставит приоритеты при оптимизации технических метрик.
Классический пример: продакт-менеджер хочет знать, кто из пользователей продукта купит премиум-услугу. Техническая метрика для дата саентиста: точность, с которой модель предсказывает покупателей. Однако какая бизнес-цель этой модели? Дать скидку маловероятным покупателям либо оказать дополнительную техподдержку высоковероятным? Где цена ошибки будет выше: перепутать премиума с непремиумом или наоборот? Каждая бизнес-задача имеет свои особенности, и именно под нее стоит составлять бизнес-метрики, которые выражаются в деньгах или конечной полезности.
Для того чтобы натренировать модель определять взаимосвязи, необходимо иметь размеченные данные. Это набор примеров с характеристиками и «правильный ответ» по каждому из примеров. Например, у вас есть информация по 10к пользователям и о том, что они делали на сайте, а также «ответ»: купили ли они премиум в течение месяца. Другой пример: текст комментария в фейсбуке и оценка его агрессивности от 1 до 10.
Отмечу, что не для всех задач нужны размеченные данные. Исключение — задачи unsupervised learning (например кластеризация).
Ключевой фактор результативности модели — качество данных! Если что-то не так с данными, модель выявит неправильные взаимосвязи, и результаты не будут отображать реальность, а полезность будет нулевая. В Data Science кругах ходит популярная фраза: «Garbage in = garbage out». Никакая модель не сможет дать правильное предсказание, если данные на вход были неправильными. Именно поэтому хороший дата саентист проводит гораздо больше времени, разбираясь в данных, нежели тестируя разные модели.
Сложность получения и подготовки данных напрямую зависит от проекта. А сам процесс может занимать от нескольких дней до нескольких месяцев.
Ниже рассмотрим основные источники получения размеченных данных.
Возможно, это самый простой источник данных, однако и с ним может возникать много трудностей. Допустим, есть проект, на котором необходимо предсказать, когда пользователь перестанет пользоваться продуктом. Для этого необходимы поведенческие данные из логов. Но просто взять и вытащить данные из БД недостаточно. Что может испортить данные? Например:
Каждый из таких сценариев влияет на данные и, как следствие, влияет на распределения зависимостей для принятия решений. Например, если в продукте ввели новую сокращенную воронку регистрации, то зарегистрируется больше пользователей. Но в результате, процент заинтересованных пользователей будет размываться, и большее количество покинет сайт. Этот факт очень важен для построения модели, потому что профиль среднего пользователя поменялся. Задача дата саентиста как раз сводится к тому, чтобы при моделировании все такие взаимосвязи были отображены в данных.
Думаю, тут сложность очевидна: вытащить данные из разных источников и унифицировать их. Вдобавок к инженерной сложности соскрейпить данные возникает другая проблема. Часть данных может не иметь никакого отношения к моделированию, и определить и исключить эти данные — достаточно кропотливая работа. Допустим, для задачи необходимо вытащить заголовки текстов с разных сайтов. Как это сделать? Вытаскивать заголовки по тегам
Процесс получения таких данных самый долгий и дорогой. Эти данные нужны для задач, с которыми легко справляется человек, но они сложны для алгоритма. К таким сценариям относятся reCAPTCHA, поиск опухолей на МРТ, обведение силуэта автомобиля, оценка эмоции по голосу. Почему такие задачи сложны для алгоритма? Они решаются на так называемых «неструктурированных данных». Например, две картинки с котиками разного цвета и в разном масштабе будут иметь абсолютно разные значения пикселей, хотя они и остаются котиками. Для человека это одна и та же сущность, а алгоритму необходимо будет выяснить, что эти два разных набора пикселей — один и тот же объект.
При этом автоматически получить размеченные данные для тренировки невозможно. Поэтому для таких задач человек вручную размечает N примеров, а потом эти данные используются для тренировки алгоритма. Задача ручной разметки данных с 2014 года превратилась в отдельную огромную индустрию и продолжает расти. Есть множество компаний, которые занимаются разметкой ваших данных. Например, вы платите компаниям, чтобы они разметили автомобили на ваших видеороликах. По оценкам аналитических компаний, в 2018 году рынок аутсорса Data Labelling достиг $318 миллионов, и предсказывают рост до $1,5 миллиарда к 2025. А некоторые эксперты ожидают вдвое больший рост.

Подводя итог, могу сказать, что получение данных и их унификация — зачастую трудоемкая задача, которая требует предельного внимания и скрупулезности, а также много времени.
В чем суть тренировки модели? Если говорить просто: алгоритм — это набор коэффициентов, которые перемножают и суммируют входящие данные. Результирующее число должно быть ответом, который мы ищем. Размеченные данные для тренировки как раз и содержат «желаемый ответ». У нас также есть функция, которая считает «силу ошибки», и по ней мы знаем (спасибо школьным производным), как надо подправить коэффициенты, чтобы в следующий раз ответ был ближе к правильному. Поэтому, подавая в цикле много примеров, модель корректирует свои веса («обучается»), и будет готова давать предсказания для новых похожих данных.
К счастью, дата саентисту не нужно придумывать алгоритмы. Уже есть множество различных алгоритмов, которые могут справиться с практически любой задачей. Нам нужно знать их принципы работы и уметь применить уместный, чтобы это не было как «забивать гвозди микроскопом».
Выбор алгоритма влияет на то, как и какие данные необходимо собирать. Допустим, есть задача отсортировать «объекты» по качеству. Вот два разных способа, как разметить данные, от которых будет кардинально зависеть выбор модели:
В целом, для дата саентиста задача моделирования сводится к следующему:
Анализ ошибок модели — критический этап для успеха
Лучшая стратегия при моделировании — двигаться итерациями. Сперва стоит построить полный pipeline: от получения данных до конечного результата для клиента. При этом важно закрыть этот pipeline в самую первую очередь, и желательно, чтобы он был максимально простым с самой простой моделью. Дальше итеративно улучшаем его, каждый раз принимая решения, анализируя ошибки. Условно процесс должен выглядеть так:
Почему важно начать с самой простой модели? Чем проще модель, тем обычно она лучше объясняет, где были допущены ошибки, и благодаря этому гораздо легче определять, на чем фокусироваться дальше. Такому принципу следуют все крупные компании уровня Google, Amazon и Facebook. У Гугла есть на эту тему очень хорошие гайдлайны.
Один из грехов дата саентистов — потратить мало времени на анализ ошибок и вместо этого долго играться с параметрами модели. Потом пытаться применить более сложный алгоритм или построить ансамбль из алгоритмов, чтобы «усреднить» их предсказания. В итоге итерации сводятся к такому виду, как на рисунке. Упускается важный факт, что чаще всего ошибка в данных, ведь модель просто проецирует распределение данных. Если ошибка в данных, то будет ошибка и в предсказаниях. Двигаясь по такому циклу, хороших результатов можно и не получить в принципе.
При достижении каких-либо интересных результатов либо наоборот, когда прогресса нет, стоит обсудить статус модели с продакт-менеджером.
Обсуждая результаты модели с продакт-менеджером, важно понимать, что ответственность за выведение
По своему опыту обратил внимание, что коммуникация результатов очень подвержена такому когнитивному искажению, как Halo effect. (Из Википедии: результат воздействия общего впечатления о чём-либо на восприятие частных особенностей. Примером может служить впечатление, что у людей с привлекательной внешностью большие умственные способности.) Он работает как в позитивную, так и в негативную сторону. В связи с этим обсуждение текущих результатов модели создает определенную эмоциональную окраску для будущих оценок. Это влияет на принятие конечного решения. И даже если все ваши решения data driven, из-за неправильного донесения особенностей выход модели в продакшн может изрядно замедлиться (например, в середине проекта решают ужесточить ранее установленный KPI).
Другой интересный аспект — не все ошибки модели можно уловить с помощью метрик. И рекомендации продакт-менеджера по улучшению могут быть ценным источником информации. Яркий пример: в рекомендательных системах алгоритм зацикливается на одной-двух отраслях и рекомендует только их, что ведет к недостаточному разнообразию. Продакт-менеджер, который хорошо знает особенности продукта, поможет определить похожие вещи, в то время как дата саентист может упустить важность этой метрики и не оценить по ней качество модели.
Бывает, что качества модели недостаточно, чтобы выводить ее в продакшн. При этом нет четкого понимания, какие действия наверняка улучшат качество. Такая ситуация вероятна, так как Data Science проекты не имеют четко определенного пути к цели. Задача сводится к пониманию проблемы, составлению гипотез и разнообразным экспериментам. Причины неуспеха могут быть связаны как со сложностью задачи, так и с качеством и количеством данных. Умение признать нерешаемость задачи и найти достойный pivot — очень ценный навык. Хороший пример pivot`a от сложной к более простой задаче: не делать полноценную систему рекомендаций, а внутри каждой категории рекомендовать самый популярный продукт.
Многие менеджеры ожидают, что дата саентист сможет самостоятельно задеплоить модель в продакшн. Для некоторых несложных проектов это может быть вполне разумной задачей. Однако, чем сложнее проект и чем выше цена ошибки — тем критичнее участие инженера. Вот несколько причин, почему инженер может быть ключевым звеном для успешности Data Science проекта.
Данные для тренировки модели и для продакшна различаются. Это обычная ситуация. Например, для тренировки дата саентист брал данные из аналитической базы, а для продакшна нужны реал-тайм. В аналитической базе данные часто собираются из разных источников и проходят какую-то трансформацию. Соответственно, для продакшн-данных будет другой процесс подготовки и агрегации разных источников. Другой пример: для тренировки и оценки качества данные собираются в batch. Однако в продакшне данные могут приходить по одному, поэтому задача оптимизации и распараллеливания вычислений будет выглядеть совсем по-другому.
Оптимизация кода. Во время рисерча дата саентист обычно пишет «грязный» и неэффективный код. И это абсолютно нормальная ситуация, потому что построение модели — это экспериментальный и итеративный процесс. Дата саентист тестирует много идей, многие из них не срабатывают, поэтому большое количество кода меняется и удаляется. Каждый раз писать качественный код — большая трата времени. И только к моменту, когда модель дошла до статуса готовности выхода в продакшн, есть смысл оптимизировать код. Ускорение вполне может достигать
Например, в Python есть библиотека Pandas, которая позволяет очень удобно манипулировать данными, но она работает медленно. На критических проектах в продакшне мы эту библиотеку выпиливаем полностью, однако без этой библиотеки на проверку гипотез мы бы тратили в несколько раз больше времени.
Автоматизация. Обновление моделей — часто болезненный этап для проекта. Сценариев для обновления обычно два — устаревание модели и выход новой версии:
Идеальный вариант обновления модели — через А/Б тест, когда одновременно крутится две версии, чтобы удостовериться, что все корректно работает. Такой вариант не всегда возможен, поэтому чаще идут более простым путем. Собирают небольшой набор тестовых данных, которые ни одна из моделей не видела и которые не использовались для оптимизации. Эти данные служат только для финальной проверки: действительно ли новая модель работает лучше.
В Data Science проектах так же, как и других Software проектах, сложились свои, проверенные временем процессы. Если им следовать, шансы на успех значительно повышаются.
Ключевые идеи:
Спасибо за ваше время!
| « |
Наступна новина з архіву На Житомирщине от гриппа умерли двое мужчин |
Попередня новина з архіву Russians hack energy company that played major role in Trump Ukraine scandal |
» | |
|
|
||||