Как внедрить Machine Learning и не упереться в тупик
Меня зовут Хамбар Дусалиев, я руковожу ML & Operations в Kolesa Group. Технологии Machine Learning используются в нашей компании уже несколько лет. В своё время мы столкнулись с нехваткой практической информации по проблемам внедрения ML. Хочу помочь тем, кто сейчас в начале этого пути. Для этого расскажу, на какие грабли мы наступили и как можно их обойти.
Этот материал поможет:
- подготовить вашу компанию к внедрению ML-решений;
- правильно запустить ML;
- избежать типичных ошибок менеджмента на этом пути.
Machine Learning в Kolesa Group
Первые ML-модели мы начали внедрять в 2017 году. Довольно быстро возникла потребность перестраивать внутренние процессы. Я уже рассказывал, как мы подружили ML и бэкенд. Но технические сложности — это ещё не всё. Изменилась и организационная структура компании. Теперь она включает в себя отдел ML & Operations, а в нём — 3 ML-инженера и 2 MLOps-инженера, силами которых в наших продуктах крутится больше 60 моделей.
На этом пути мы не раз заходили в тупик. Конечно, это происходит со многими командами. Однажды мне попалось исследование консалтинговой компании McKinsey под названием State of Machine Learning in 2020. Из приведённой статистики мы узнали:
- При внедрении ML только 36% опрошенных смогли выйти за пределы MVP;
- У 50% опрошенных запуск модели на сервере занимает от трёх недель до трёх месяцев;
- А 18% пожаловались, что сроки ещё дольше — от трёх месяцев до года.
Очевидно, что внедрение ML даётся бизнесу нелегко, особенно на этапе деплоя в продакшен. На мой взгляд, главная причина этого — неправильное видение в самом начале.
«Наймём ML-инженеров, и будем надеяться, что они сами всё сделают» — не самый подходящий фундамент для построения ML в организации. На самом деле в основе должны быть ответы на вопросы, которые неизбежно встанут перед менеджментом.
- Откуда ML-инженеры возьмут данные?
- Кто займётся разметкой?
- Сколько времени нужно на разработку модели?
- Кто ответственен за доведение до production этих моделей?
- Кто отвечает за поддержку сервисов на основе моделей?
- Кто отрабатывает кейсы, когда модель не справилась?
- Кто ответственен за покупку и эксплуатацию оборудования?
- Как мы отличим успех от неудачи?
- Что будем делать, если результаты неудовлетворительны?
На первый взгляд, на плечи руководителя ложится ворох сложных решений. Хорошая новость в том, что не нужно будет принимать их все одновременно. Дальше я покажу, что подготовка и внедрение ML происходит в три этапа. Речь пойдёт о компаниях, в которых ML не лежит в основе бизнеса, а используется для оптимизации процессов, как у нас.
Первый этап. Принятие решений на основе данных
Компания будет готова к внедрению ML только тогда, когда решения в ней принимаются на основе данных. Сейчас набрала обороты концепция Data-driven decision-making (DDDM). Качество решений зависит от того, откуда компания берёт данные и как «глубоко копает», чтобы их добыть.
Я предлагаю небольшой тест, чтобы оценить DDDM в вашей организации.
- Вы опираетесь на данные при найме и увольнении людей?
- Проекты стартуют и сворачиваются на основе данных?
- Новые фичи пилят, потому что их необходимость доказана данными?
Допустим, на все три вопроса вы ответили скорее отрицательно. В этом случае у топ-менеджмента есть соблазн нанять бизнес-аналитика и делегировать ему всю работу. Это не приведёт к результату, если ваша цель — по-настоящему изменить процесс decision-making в компании.
Если на вопросы вы ответили «скорее да», в вашей компании умеют собирать и хранить данные. Вы даже можете проводить исследования по требованию, чтобы прояснить какую-то информацию. Например, компетентный сотрудник задаётся вопросом: «Почему произошло событие X?» и знает, как найти ответ.
Кроме того, важно нащупать метрики, которые отражают здоровье бизнеса. Например, Kolesa Group — это четыре продукта формата «доска объявлений», то есть четыре классифайда. И мы отслеживаем целый ряд метрик, которые показывают, как себя чувствует этот бизнес. Любой эффект от наших действий, в том числе для ML-сервисов, стараемся видеть через эти метрики.
Если вы тоже отслеживаете метрики, скорее всего, вы уже работаете с предиктивной аналитикой: можете предсказать снижение или повышение бизнес-показателей, оцениваете влияние своих действий на будущее.
Для меня предиктивная аналитика — это маркер того, что компания уже прошла первый этап и готова к внедрению ML:
- Здесь собирают и хранят данные;
- Есть процессы оценки сроков/стоимости для решений;
- Сотрудники уже работают с «классическим» ML.
Убедившись в этом, можно переходить к следующему этапу.
Второй этап. Сначала простые решения, потом модели
Например, мы в Kolesa Group используем модели для оптимизации вспомогательных процессов и для помощи пользователям.
- Есть ли на этой фотографии что-то, чего не должно быть видно?
- Есть ли в этом сообщении запрещённые слова или приватная информация?
Подобные задачи потом научится решать модель, а сначала лучше поручить их людям. В большинстве случаев это проще и дешевле, но дело не только в экономической выгоде.
Давайте посмотрим, как устроен процесс модерации:
Контент попадает к модератору. Тот ищет нарушения, опираясь на правила. При этом, если нарушения обнаружены, модератор может принять решение, как их исправить. Обеспечив этот процесс, мы строим систему работы с данными, которая ляжет в основу будущей модели:
а) Есть админка, в которую в нужный момент поступает контент.
б) Данные перетекают дальше, это поддерживает инфраструктура продукта.
в) Нанимая модераторов, мы учимся оценивать их работу, ставить KPI.
г) Накапливается опыт работы с ошибками и жалобами пользователей.
Благодаря этому мы не строим с нуля процесс автомодерации, он идёт параллельно. И здесь уже можно обучать модель — кстати, для разметки данных мы часто задействуем тех же модераторов.
Суть моей рекомендации: оттягивайте внедрение ML настолько, насколько это возможно. Запускаем модели только тогда, когда процессы хорошо работают без них.
В этом случае вы оцените, во сколько обходится компании этот процесс, и установите baseline для расчёта костов внедрения ML.
Итог второго этапа: у вас выработан продуктовый флоу, построен процесс контроля качества и налажена обработка ошибок/жалоб. И самое главное — вы знаете стоимость процессов и понимаете, стоит ли овчинка выделки. Если ML существенно сэкономит человеко-часы, можно двигаться дальше.
Третий этап. Интегрируем ML-инженеров в процессы разработки
Итак, вы наладили процессы работы с данными и построили продуктовую аналитику в компании. Часть задач, которые выполняют люди, было бы быстрее и дешевле закрывать с помощью технологий ML.
Теперь нужно найти ML-инженеров, которые этим займутся. Есть два варианта, где их искать. Во-первых, в этом направлении могут расти те сотрудники компании, которые уже занимаются аналитикой. Во-вторых, можно нанять «готовых» специалистов с рынка.
Так или иначе, многим руководителям кажется очевидной идея создать изолированную команду ML «на пробу». Мы тоже совершали эту ошибку. Казалось, это так продуманно: сейчас инженеры наладят процессы, докажут свою пользу компании, и только тогда мы изменим процессы под нужды ML.
Почему обособленная ML-команда — не лучшая идея
Напомню, что по аналогии с известным понятием «технический долг» есть «организационный долг». Он накапливается, когда мы вовремя не устраняем проблемы, не исправляем несовершенства в процессах. Компания становится неповоротливой, нерешённые организационные вопросы мешают жить.
Создание изолированной команды — верный способ накопить организационный долг. Представьте: все процессы раздваиваются, каждая команда варится сама по себе, действия специалистов не согласованы.
«Организации проектируют системы, которые копируют структуру коммуникаций в этой организации» — так звучит Закон Конвея.
Это значит, что техническая структура IT-продуктов всегда похожа на организационную структуру IT-компании. Усложните коммуникации, удвойте количество команд — получите сложный, громоздкий продукт. Например, одну и ту же проблему админы будут решать по-своему, а разработчики — по своему. Со временем использование разных инструментов приведёт к ещё большей обособленности команд и сложности поддержки.
Как избежать организационных проблем
Теперь расскажу, как я сразу строил бы процессы, если бы мог вернуться во времени.
Лучше заранее нарисовать схему организации и утвердить со всеми своё видение. Когда вы откроете несколько новых позиций ML-инженеров, кто будет отвечать за то, что всё работает? Кто будет заниматься разметкой? Где будут обрабатываться жалобы? Скорее всего, в компании уже есть такие сотрудники. Можно перераспределить обязанности между ними.
Пример 1. Мы пришли к тому, что в Kolesa Group нет отдела разметки. Вместо этого задействовали уже существующий отдел модерации. Когда мы тренируем модель, обычно его сотрудники размечают данные, ведь именно они лучше всего знают правила наших продуктов.
Пример 2. Нет чёткой грани, какие вопросы относятся к внедрению ML, а какие нет. Так, мы работаем с видеокартами. Кто должен отвечать за их эксплуатацию? Это точка пересечения зон ответственности админов и разработчиков. Пришлось организовать их работу так, чтобы они говорили на одном языке и решали вопросы с оборудованием без посторонней помощи.
По этим примерам можно получить представление о том, как мы решали целый ряд похожих проблем.
В начале наша команда ML была частью отдела RND и процесс разработки шёл изолированно — а значит, в некоторых моментах ML и backend взаимно блокировали процессы. Это затрудняло коммуникации, рос технический долг. Мы решили, что унифицировать процессы получится, если «подружить» ML и backend. Нашли на первый взгляд нелогичное решение — команда перешла в ведение руководителя backend-разработки. В нашем случае это сработало.
Выше я приводил печальную статистику компаний, которые годами ведут ML до продакшена. В какой-то момент мы испытали на себе все эти проблемы.
Чтобы выбраться, нам пришлось действовать быстро и решительно. Мои коллеги провернули несколько масштабных проектов, которые изменили процессы. Это был стресс для системы, но в результате:
- Автоматизировали генерацию сервисов вокруг моделей;
- Вывод модели в продакшн занимает около 20 минут;
- В отдельных случаях — — сократили TTM больше, чем в два раза;
4. Автоматизируем сбор данных;
5. Оптимизируем косты на GPU.
6. Общий цикл тренировки модели сократился, но это сильно зависит от конкретного случая.
Четыре совета для первых релизов
После долгой подготовки вы построите процессы и найдёте нужных людей. Магия сработает, и первые модели начнут крутиться на проде.
На что нужно обратить внимание:
- Избегайте вложений в дорогое оборудование, где возможно. Скорее всего, для работы вам понадобится не то оборудование, которое хочется закупить в самом начале.
- Эффективность ваших ML-сервисов должна быть завязана на продуктовые метрики. Это более показательно, чем специфические ML-метрики.
- Сдерживайте организационный долг, в новых командах он копится с ускорением.
- Не изолируйте команду ML от DevOps-практик. Технический долг будет накапливаться быстрее, чем в «классической» разработке.
Как мы победили растущий backlog задач с помощью MLOps, можно прочитать в статье моего коллеги Миржана Иркегулова.
Roadmap для менеджера
В начале статьи мы рассуждали, почему многим компаниям так сложно даётся внедрение ML. Помните ворох вопросов, на которые нужно ответить на подготовительной стадии?
Теперь это сделать легче, потому что так или иначе каждый вопрос относится к одному из этапов, про которые я рассказал:
Принятие решений на основе данных:
- Откуда ML-инженеры возьмут данные?
- Как мы отличим успех от неудачи?
- Что будем делать, если результаты неудовлетворительны?
Сначала простые решения, потом модели:
- Кто займется разметкой?
- Кто отрабатывает кейсы, когда модель не справилась?
Процессы разработки:
- Сколько времени нужно на разработку модели?
- Кто ответственен за доведение этих моделей до продакшна?
- Кто отвечает за поддержку сервисов на основе моделей?
- Кто ответственен за покупку и эксплуатацию оборудования?
Так в нашем случае выглядит дорожная карта внедрения ML. По аналогии можно составить свою — для любого бизнеса, в котором технологии Machine Learning помогают оптимизировать процессы.
Каждый этап продлится столько, сколько нужно вашей компании. Если какой-то шаг растянется на длительное время — это нормально, главное двигаться в общем направлении.
