Следующий постулат: данные, на которых обучена модель, – это часть кода. Это еще одно серьезное отличие от классического программирования. Чтобы сделать «тиражирование» программного кода, его текст можно опубликовать в Сети. Эта программа будет работать везде одинаково. Если вы захотите «поделиться» своей обученный моделью, то вам придется отправить не только код, но и весь получившийся черный ящик. Именно так исследователи и делятся своими обученными моделями. Например, модель нейронной сети 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 тысяч долларов в год.
