Вдохновленный недавним выступлением на подкасте O’reilly Data Show «Что нужно знать инженерам по машинному обучению», я решил пролить свет на эту набирающую популярность тему. Хотя я не такой уж и большой эксперт, я думаю, что моего полуторагодичного опыта на этой конкретной должности может быть достаточно, чтобы написать краткое изложение того, о чем идет речь.

Машинное обучение, искусственный интеллект и подобные модные словечки в настоящее время находятся в центре внимания венчурных инвесторов. Стартапы появляются слева и справа, обещая миру поразительное умное будущее. Лучшие из них приобретаются «большой пятеркой» для дальнейшего увеличения своих доходов. С ростом этой ИТ-отрасли также растет рыночный спрос на разработчиков, которые действительно могут предоставлять обещанные приложения с искусственным интеллектом.

Итак, естественный выбор - нанять команду специалистов по обработке данных для разработки вашей идеи, не так ли?

Не совсем так.

Специалисты по анализу данных обычно имеют другое образование, чем инженеры-программисты. Из них не обязательно быть хорошими программистами. Фактически, они никогда не намеревались быть ими - для специалиста по обработке данных кодирование - это просто средство решения текущей головоломки. И ничего более. В отличие от разработчиков программного обеспечения, они не относятся к коду как к искусству. Конечно, их мудрость неоценима, но диапазон навыков, необходимых для того, чтобы стать успешным специалистом по обработке данных, уже широк (особенно, когда эта область часто развивается с новыми открытиями, делая значительную часть с трудом заработанных знаний устаревшими на повседневной основе). Слишком широкий. Нельзя ожидать, что человек, специализирующийся на компьютерном зрении или предписывающем анализе, также станет простым программистом, создавая модели и помещая их в масштабируемую облачную среду. А также поддержание высокого качества, многоразового кода. Использование функционального программирования. Или реактивный. Или оба.

С другой стороны, когда дело касается машинного обучения, инженеры-программисты весьма сдержанны. Вся концепция выглядит довольно странно с их точки зрения, особенно когда большинство так называемых моделей, которые создает их команда по анализу данных, представляют собой короткие хакерские сценарии со странными вызовами методов и нечитаемым кодом на незнакомом языке. Где все шаблоны проектирования? Где чистый код? Где ведение журнала или мониторинг? Почему код нельзя использовать повторно? Разве код, решающий такую ​​сложную задачу, не должен содержать больше двухсот строк? Это очень уродливый сценарий, который может понять только один человек! Это вообще вообще программирование?

Слияние

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

Эта потребность была удовлетворена с появлением роли инженера по машинному обучению.

Чего всегда не хватает во всех статьях, учебных пособиях и книгах, касающихся машинного обучения, так это производственной среды. Его буквально не существует. Данные загружаются из CSV, модели создаются в Jupyter, рисуются кривые ROC и готово - ваш продукт машинного обучения запущен и работает. Пришло время еще одного раунда посевного финансирования!

Подожди.

На самом деле большая часть вашего кода не привязана к машинному обучению. Фактически, соответствующий код обычно занимает всего несколько процентов от всей вашей кодовой базы! Ваш предварительно обученный черный ящик дает только крошечный ответ в формате JSON - для выполнения этого прогноза требуются тысячи строк кода. Или, может быть, все, что вы получите, - это сгенерированная таблица базы данных с аналитическими данными. Опять же, чтобы сделать ее полезной, необходимо построить на ней целую систему! Вы должны получить данные, преобразовать и изменить их, автоматизировать свою работу, где-то представить свои идеи конечному пользователю. Независимо от того, насколько мала проблема, объем работы, которую необходимо проделать вокруг самого машинного обучения, огромен, даже если вы начнете свой проект с помощью таких технологий, как Apache Airflow или NiFi.

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

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

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

Это просто еще один API

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

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

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

Вы также можете нести ответственность за выбор других инструментов и экосистем, всегда принимая во внимание весь жизненный цикл проекта (а не только безрассудную исследовательскую часть) - например, Azure ML Workbench или IBM Watson могут быть отличными инструментами для начальной загрузки проекта и проведения исследований, но не обязательно отвечать всем требованиям вашей окончательной версии продукта, когда дело доходит до настраиваемого планирования и мониторинга.

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

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

Невыразимые минусы

Вы можете свободно общаться со всеми новейшими технологиями в этой области. Keras, pyTorch, TensorFlow, H2O, scikit-learn, Apache Spark - выберите имя, вы, вероятно, будете его использовать. Apache Kafka! Пульсар! AWS! Каждая конференция, которую вы посещаете, громко говорит о вашем стеке технологий, как если бы это был Избранный. Люди смотрят на вас с завистью, зная, что вы тот парень, который использует все самое крутое.

Что всегда удобно, так это тот факт, что эти крутые вещи также оказываются не широко используемыми. И когда технология является новой, все вы остались с плохой документацией и кучей сообщений в блогах. То, что вы видите на конференциях и технических переговорах, - это просто счастливые зеленые пути (похожие на те ноутбуки Jupyter, которые вы получаете от своей команды DS). Вы знаете, что программное обеспечение работает не так. Много раз, после нескольких часов отладки внутреннего устройства Apache Spark, я сомневался в своем желании продолжить карьеру программиста в области машинного обучения. Разве я не был бы счастливее без всего этого? Неужели веб-разработка действительно настолько утомительна?

Ожидается, что вы будете знать множество концепций как в области разработки программного обеспечения, так и в области науки о данных. Самое главное, люди хотят, чтобы вы очень быстро получали новые знания. Я многому учусь, беря чужие фрагменты, изменяя и взламывая их, и наблюдая, что происходит. Ну а что делать, если сниппетов нет? Что, если полученная вами трассировка стека бессмысленна, а поиск в Google имени исключения приводит только к тому, что код на GitHub выбрасывает его?

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

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

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

Разработчик полного цикла в области науки о данных.

Подводя итоги

Человек по имени инженер по машинному обучению:

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

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

Наконец, я пообещал своему другу, что мы оба начнем вести блог примерно в 2018 году.

Ну вот, Джоанна! Теперь твоя очередь.