Роман Зыков - Роман с Data Science. Как монетизировать большие данные [litres]

• Функция обучения (train), в которую можно отправить данные для обучения признаки (они же фичи, независимые предикторы, независимые переменные) и правильный ответ (output). Сам результат обучения сохраняется внутри модели.

• Функция предсказания (predict), которая предсказывает результат для новых примеров.

Поясню на примере одной задачи. У нас есть много фотографий собак и кошек, и нам нужно их разделить: в одну папку сложить файлы с фотографиями кошек, в другую – фото собак. Фотографий очень много – миллионы, вручную не сделать. У вас есть размеченный набор данных для обучения – тысяча фотографий, для каждой указано, кошка там или собака. Вы берете нужную модель, «скармливаете» ей в функцию train набор с размеченными данными, и она учится на них. Сама модель выглядит для нас как черный ящик. Конечно, в него можно заглянуть, что мы и сделаем в главе про машинное обучение. Как только модель обучится, мы уже начинаем одна за другой скармливать ей фотографии, которые нужно разделить. Для каждой фотографии модель вернет нам вероятность того, кошка там или собака. Используя эти цифры, уже несложно разделить фотографии.

Этот пример я видел вживую, когда глубокое обучение нейронных сетей (Deep Learning) только набирало оборот. На одном из конкурсов Kaggle.com была точно такая же задача [14]. Чтобы поиграть с этой задачей, я нашел код в интернете, который не использовал нейронные сети. Естественно, ничего не получилось, мой алгоритм был настолько плох, что проще было бросить монетку и получить такой же результат. Первые места заняли исследователи, у которых результат был близок в 99 % (точность угадывания). Их модель была основана на сверточных нейронных сетях. Меня тогда поразил результат. Глубокое обучение нейронных сетей еще не было популярным, а ведь это было всего лишь в 2013 году. Вот так быстро меняются технологии!

Следующий постулат: данные, на которых обучена модель, – это часть кода. Это еще одно серьезное отличие от классического программирования. Чтобы сделать «тиражирование» программного кода, его текст можно опубликовать в Сети. Эта программа будет работать везде одинаково. Если вы захотите «поделиться» своей обученный моделью, то вам придется отправить не только код, но и весь получившийся черный ящик. Именно так исследователи и делятся своими обученными моделями. Например, модель нейронной сети Resnet 50 [15] была обучена на миллионах изображений. Она уже полностью готова к работе; просто показывая ей разные фотографии, вы получите названия предметов, которые там изображены.

Ничего нельзя сделать без инженерии аналитической системы. Даже для самых простых вещей «на коленке» нужно продумывать следующие вопросы:

• Откуда и с какой периодичностью брать данные и как туда получить доступ?

• Какова нагрузочная способность источников данных, чтобы и бизнес работал без сбоев, и данные как можно быстрее были доступны для анализа?

• Какую архитектуру хранилища сделать? Или, может, не делать его вовсе?

• Какую аналитическую систему выбрать?

• Как использовать в процессах обученную модель машинного обучения (далее ML-модель)?

Таких вопросов может быть очень много. Эти вопросы должны решаться и автоматизироваться. Артефактами инженерии будут:

• Архитектура аналитической системы.

• Программный код, который обеспечивает работу системы.

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

Архитектура аналитической системы состоит из нескольких уровней:

• Физический – серверы и каналы связи между ними.

• Данные – хранилища данных.

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

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

За уровень данных отвечают инженеры данных (Data Engineers или ETL Engineers): их основная задача – сделать так, чтобы данные доставлялись от источников данных и сохранялись в хранилищах данных. Часто они же отвечают за предобработку данных и развертывание BI-систем (OLAP-кубы и отчетные системы).

За уровень приложений отвечают инженеры машинного обучения (ML engineers) и аналитики данных (data scientists). ML-инженеры занимаются созданием ML-моделей и иногда – их развертыванием, чтобы они работали на благо вашего бизнеса (хотя в больших компаниях развертыванием моделей «в бою» часто занимаются другие инженеры). Аналитики данных занимаются тестированием моделей и их оценкой. В небольших компаниях эти две роли часто совмещаются. Однажды я проходил собеседование в офисе компании Quora.com (социальная сеть) в Пало-Альто (Калифорния, США) и там выяснил, что местные ML-инженеры как раз и занимаются разработкой ML-моделей, а аналитики данных занимаются метриками, анализом данных и прочим, но не ML-моделями.

Чем ближе анализ данных к точке принятия решений – тем лучше. Если вопрос возник у руководителя и у него есть полное понимание бизнес-контекста (какие события были и т. д.), а аналитическая система обладает хорошей интерактивностью, то большинство вопросов решаются на раз-два-три. До 80 % вопросов (вспомните правило Парето), если быть точным. В чем плюсы такого решения? Нет посредников – выше скорость! Пользователь даже может не иметь четко сформулированного вопроса, который точно понадобится, если ставить задачу аналитикам. Для этого очень важно внутри компании «продавать» аналитический подход и регулярно обучать пользователей.

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