Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третий уровень – передаем задачу условному центральному отделу аналитиков данных, если:

• задача требует изменения ядра системы;

• задача технически сложна для аналитика какого-то отдела;

• требуется большая коллаборация между отделами для ее решения.

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

До Физтеха я вообще не знал английского – в школе у меня был немецкий, о чем я очень жалел. На Физтехе принято учить английский язык, поэтому сразу на первом курсе была сформирована группа начинающих, в которую попали всего 4 человека. На протяжении трех курсов у нас проходило 2 занятия в неделю. Это был один из самых моих любимых предметов, и он здорово мне пригодился. На четвертом курсе я устроился подрабатывать переводчиком книги с английского языка на русский. Это была книга о программе анализа данных STATISTICA компании StatSoft. Я устроился туда стажером, переводил книгу, помню норматив – 15 000 знаков в день, от которого к вечеру пухла голова. Постепенно я втянулся и стал заниматься более интересными вещами: преподавал клиентам компании, проводил презентации для продаж, ездил в командировки и т. д. Тогда я постоянно консультировал клиентов и понял одну важную вещь: многие клиенты хотят получить кнопку и желательно на стуле – садишься на нее, а она делает всю твою работу.

Кроме того, заказчику чаще всего лень вдаваться в детали, и он готов платить огромные деньги просто за яркую обертку. Этот феномен очень хорошо эксплуатируется продавцами IT-решений, консультантами всех мастей. Я наблюдал его, когда Ozon.ru выбирал решение для веб-аналитики между Omniture SiteCatalyst и Webtrends. Обе команды продавцов активно рассказывали о «светлом» будущем. Так как никто из принимающих решения не был особенно в теме (я, кстати, тоже), то выбрали тех, кто «поет» лучше. Презентация Omniture выглядела эффектней, они нам подарили радиоуправляемые машинки и всякие подарки. Поэтому выбор был сделан в их пользу, хотя я нахожу системы равнозначными, и стоили они почти одинаково. В продолжение истории – когда я пришел в Wikimart.ru, мне уже было понятно, что нужно пользователям от веб-аналитики. Я быстро накатал техническое задание, его реализовали разработчики, и через два месяца после моего прихода в компании была своя система веб-аналитики, ничуть не хуже Omniture. И экономия составляла порядка 100 тысяч долларов в год.