Привет! Меня зовут Илья Туксов, я проджект-менеджер проектов, связанных с машинным обучением и искусственным интеллектом. Работаю в команде персонализации и параллельно учусь сам разрабатывать модели. Сегодня я расскажу об устройстве ML-проектов с точки зрения менеджмента. Мы разберем ключевые этапы проекта, поговорим об их специфике, поищем подводные камни и способы их избежать.
Это будет интересно в первую очередь техлидам команд, где есть машинное обучение, а также менеджерам продуктов и проектов. Еще текст будет полезен разработчикам моделей, желающим перейти на следующий уровень, и бизнес-заказчикам, которые хотят внедрить машинное обучение в процессы, но пока не знают, как это сделать.
Что мы знаем об ML-проектах
Многие пользователи продуктов не знают, что та или иная любимая фича — результат работы алгоритма искусственного интеллекта. Например, банкам алгоритмы помогают рекомендовать продукты своей экосистемы, а медикам — получать второе мнение при диагностике заболеваний. По прогнозам, озвученным на ВЭФ в 2020 году, к 2030 году вклад продуктов с искусственным интеллектом в экономику составит около 15,7 трлн долларов.
Но мы не знаем, сколько денег на ML-проектах было потрачено впустую. Вероятно, очень много. Поэтому критически важно понимать, нужно ли вообще внедрять машинное обучение в бизнес-процессы или продукты. Спойлер: иногда это не только не нужно, а даже вредно. Также необходимо понимать, как должен развиваться проект на каждом этапе.
ML-проекты — это чаще всего высокие затраты на вычислительные ресурсы и зарплату специалистов и долгая реализация. И все это может закончиться тем, что результата не будет. Или он будет не таким, как ожидали, и работать с ним никто не захочет. Наша цель — свести риски к минимуму и получить желаемый результат. И главное, полезный. О том, как это сделать, мы и поговорим.
Как устроен пайплайн ML-проекта
Как и в классической автоматизации, в ML-проектах есть пайплайн, которого мы пытаемся придерживаться. Разберем его особенности. Вопросы, которые мы задаем на разных этапах, плюс-минус одинаковые. Но ответы на них будут существенно менять всю картину в дальнейшем.
Представим, что к нам приходит заказчик и говорит: «Я хочу, чтобы мы могли доставать из документов название компании, которая нам эти документы отправила, и дату, когда они пришли». Мы обсуждаем, что нужно сделать. И понимаем, что документы хранятся в Excel, а нужные данные разбросаны по строчкам. Чтобы выполнить просьбу заказчика, достаточно достать дату из нужной строки и понять, кто отправитель. Алгоритм машинного обучения здесь не нужен: это неоправданно сложное решение для такой задачи.
Но если в процессе мы понимаем, что документы распечатаны на бумаге и их нужно отсканировать, распознать текст, а также спрогнозировать, сколько денег это сэкономит, — поздравляю, начинается приключение под названием ML-разработка с технологиями компьютерного зрения, CV, и обработки естественного языка — NLP.
Пайплайн ML-проекта выглядит не так, как обычный. На любом этапе может произойти что-то, что заблокирует работу. При этом на каждом этапе, который помечен красным, есть риск вернуться к началу: заново ставить гипотезу, пересматривать таргет и в целом задачу. Важно понимать, что это может произойти, но бояться этого не нужно.
Попробуем представить собирательный образ типичного заказчика. Разумеется, далеко не все такие — сейчас многие заказчики погружены в тему. Мы специально рассмотрим крайний случай, чтобы разобрать возможные проблемы. Итак, типичный заказчик:
не сталкивался с ML, но слышал о нем;
считает, что большинство ML-решений уже существует и остается выбрать нужное под потребность бизнеса;
не знает, что нужно для создания ML-проекта;
удивляется, что решение может закрыть потребности не на 100%.
Как вы понимаете, в таких условиях работа может быть непростой. Но каким бы ни был заказчик, нужно четко понимать, как устроен каждый из этапов и какие подводные камни могут нас ожидать.
На что стоит обращать внимание на каждом этапе
Бизнес-анализ и системный анализ. Без этого этапа проект не сможет начать существовать. Перед стартом нужно ответить на множество вопросов, и ловушка в том, что ответы на некоторые из них найти не получится. Но это не страшно: некоторые вопросы стоит задать заранее, чтобы отвечать на них в ходе работы.
Вот на что стоит обращать внимание на этапе бизнес-анализа:
Цель и проблематика. Важно четко понимать, какую проблему мы решаем своим продуктом. Чем больше конкретики, тем лучше. Нужен максимум обоснований.
Профит. Считаем, сколько мы заработаем, сэкономим или правильно перераспределим. Тут очень важны цифры и подсчеты. Помимо экономических показателей есть показатели лояльности, снижения рисков, предотвращения убытков и другие метрики не про монетизацию — об этом тоже не стоит забывать. Здесь каждый сам решает, какие у него приоритеты.
Данные. Без них проект не поедет. Важно понимать, есть ли данные в принципе, что представляют собой источники информации, как с ними можно работать, где они хранятся, легко ли получить доступ, есть ли там конфиденциальные данные. Возможно, через данные придется объяснять заказчику, в чем связь между метриками модели и метриками бизнеса. Это еще одна причина отнестись к ним серьезно. Здесь действует простое правило: чем больше данных, тем лучше. Пусть лучше мы потом что-то уберем, чем выясним, что чего-то не хватает.
Ресурсы. Это не ключевой пункт, но если есть возможность попросить кого-то со стороны бизнеса помогать вам, лучше это сделать. Он сможет объяснить, как ведут себя данные, из каких систем они берутся, когда появляются, какие сущности есть на объекте и так далее. С таким человеком разобраться в проекте будет проще.
Чтобы успешно пройти этот этап, лучше заранее определиться со спецификой теста. Зафиксировать особенности, сроки и метрики. А также понять, как мы будем внедрять модель в продакшен в случае успеха: какие понадобятся интеграции, новые сервисы и структуры данных. Без понимания этих моментов есть риск решить задачу в стол.
Разработка. К этому этапу имеют отношение прежде всего ребята, которые занимаются созданием моделей. Советую не отдавать на откуп всю разработку, которая есть на стороне коллеги. Потому что многие любят экспериментировать, улучшать модели и создавать фичи. Это может занимать очень много времени, а эффект есть не всегда. Основная задача сейчас — двигаться в выбранном направлении и подсвечивать важные для проекта моменты, вести разработку в тесном тандеме с бизнес-требованиями.
Какие проблемы могут возникнуть на этом этапе? Их может быть много, но мы разберем основные:
Смещение распределения таргета. Если это произошло, попробуйте определить другой таргет или накопить дополнительные кейсы, если есть возможность и ресурсы.
Недостаток размеченных данных — или данных вовсе. Здесь та же история: попробуйте собрать больше данных общими силами и с помощью бизнеса. Возможно, данные уже где-то есть и нужно просто найти источник.
Сомнительные и ограниченные источники данных. Не всегда все лежит в централизованном хранилище: что-то может быть на задворках системы на бэке. Такие данные либо вообще нельзя получить, либо можно, но в очень ограниченном виде. Например, в csv-файле. Поэтому я советую по возможности уже на старте начать организовывать централизованное хранилище, чтобы обращаться к данным было проще.
Низкие метрики бейзлайн-решения. Этот пункт связан с фичами. Возможно, дело не столько в их количестве, сколько в качестве. Иногда достаточно найти парочку фичей, которые продвинут разработку.
Высокая корреляция признаков — мультиколлинеарность — между собой. В таком случае советую избавляться от менее значимых признаков и оставлять самые весомые для бизнеса. Выбирать лучше вместе с заказчиком.
Если все получилось решить или вы не столкнулись с проблемами из списка — отлично, можно переходить на следующий этап проекта. Если что-то решить не удалось, стоит задуматься, как предотвратить проблемы в будущем, или вернуться на первый этап проекта.
Тестирование V.1. На этом этапе есть вероятность столкнуться с сопротивлением со стороны заказчика. Казалось бы, о каком сопротивлении может идти речь, если нам поставили задачу и ждут результата? Но в классической автоматизации у нас есть четкое ТЗ и понятный ожидаемый результат, а в ML-проектах все сложнее.
Разберем на примере. Допустим, нам нужно добавить кнопку «Купить», чтобы пользователь мог купить ценную бумагу и видеть ее у себя на главной странице. Если при нажатии на кнопку все отображается и переливается в нужные базы данных, работа считается выполненной.
Допустим, мы хотим добавить возможность просматривать динамику роста акций за определенный период. Если при нажатии на кнопку отображается корректный график, то все в порядке.
Но если нужно отранжировать ценные бумаги по релевантности для инвестора через ML-алгоритм, возникают вопросы. Какова конверсия на ретро, какова точность модели, каково качество выдаваемой рекомендации — их может быть множество. И нам нужно заново обосновать то, что заказчик и так хотел внедрить. Если не сможем обосновать и договориться, нас ждет возврат на этап бизнес-анализа и обсуждений.
Тестирование V.2. Если все в порядке, переходим на этап, где мы пытаемся проверить качество модели с помощью обычного — когда у нас нет альтернативного варианта процесса — или A/B-тестирования. Сколько тут может обнаружиться подводных камней, сказать сложно. Поговорим о самых распространенных.
Важнее всего сформировать гипотезу, которую мы собираемся проверить. Это поможет сформировать тест. Важно помнить, что мы оцениваем не только готовое бизнес-решение, но и саму модель. Ее качество не должно падать во время тестирования.
Вот о чем стоит подумать на этом этапе:
Дизайн теста. Какую гипотезу проверяем, чего ожидаем, на какую метрику смотрим и так далее.
Параметры теста. Уровень значимости, мощности, ожидаемый лифт, объем выборки, сроки проведения и так далее. Зная это, мы сможем понять границы теста и критерии его успешности.
Мониторинг и отчетность. Иногда можно обойтись без выстраивания полноценной системы мониторинга и отчетности. Но построение простых дашбордов может помочь увидеть картину происходящего.
Подведение итогов. Определяем критерии, по которым будем судить о результатах теста. Тут нужно обратить внимание не только на ключевую метрику, но и на саму работу модели. Возможно, есть шероховатости, которые стоит поправить.
Тестирование V.3. На этот этап мы попадаем, когда сталкиваемся с вечным тестированием. Так бывает, когда приходится менять модель во время теста или когда она нестабильна. Улучшать и стабилизировать модель — это хорошо, но не нужно заниматься этим постоянно. Важно определить границы, за которыми вы не будете вносить изменения. И пересмотреть цель, если остаться внутри границ не получилось.
Продакшен. Здесь стоит обратить внимание на два момента. Первый — мониторинг. Важно построить контроль за ключевыми метриками моделей, чтобы своевременно реагировать на изменения. Второй — переобучение (дообучение). Это необязательно, но, если мы видим какие-то аномалии с данными, лучше настроить целый пайплайн, чтобы переобучать модель бесшовно и без последствий для бизнеса.
Выводы и рекомендации
ML-проекты требуют повышенного внимания. Нужно держать в голове множество деталей, чтобы в конце проекта работа не ушла в стол. При этом мы можем не дойти до прода. Это грустно, но такое случается. В наших интересах свести риски к минимуму заранее, чтобы проект состоялся.
Эксперименты и мониторинг нужны, но увлекаться ими не стоит. Мы должны постоянно что-то проверять, тестировать и изучать, если хотим получить лучший результат. Но подходить к этому лучше итерационно. И конечно, будьте любопытными. Постоянно ставьте вопросы к заказчику, продукту, разработке и тестам: чем меньше серых зон, тем ниже риск ошибиться.
А теперь несколько конкретных рекомендаций:
Постарайтесь привести постановку вашего проекта к шаблону, который будут заполнять заказчики. Укажите там ключевые пункты, которые важны для вас.
Знания. Как менеджер, вы не должны глубоко погружаться в разработку моделей, но лучше постоянно прокачиваться в этой области. Вам придется много общаться с заказчиками и отвечать на их вопросы о происходящем. Знания в этом помогут.
Доверие. Доверяйте и своей команде, и команде на стороне бизнеса. Впитывайте информацию с обеих сторон, но не забывайте задавать вопросы.
Идеи. Пробуйте искать новые способы использования вашей работы. Возможно, результаты можно применять где-то еще — в других процессах и продуктах.
Погружение. Если заказчик поймет специфику ML-разработки, работать будет проще. Расскажите заранее, какие есть риски, какие ресурсы вам нужны, какие метрики можно отслеживать и как все это будет связано с бизнес-показателями. Скорее всего, вам придется говорить одно и то же много раз, и это совершенно нормально.
Спокойствие. Не бойтесь провалов: это нормально, потому что вы экспериментаторы. Сохраняйте настрой, и все обязательно получится.
Желаю всем успешных проектов с интересными задачами. Если у вас есть вопросы, пишите в комментариях.