Сегодня на конференции Data&Science в Яндексе выступал Саша Белугин - преподаватель в НИУ ВШЭ и до недавнего времени главный project manager в Yandex Data Factory. Он поделился своим взглядом на особенности проектного управления в задачах, связанных c анализом данных (в первую очередь - в промышленности, ибо последний год YDF занималась именно этим). А я записал его лекцию, и сейчас пересказываю своими словами, иногда вставляя что-то от себя. Таких постов будет несколько, ибо и спикер сегодня был не один. Начнём же!
Существуют различные методологии проектного управления в машинном обучении: CRISP-DM, SAS SEMMA, MS TDSP. Они все в принципе друг на друга похожи: от бизнес-задачи идём к сбору данных, построению прототипа и внедрению модели, снимаем и интерпретируем метрики, и начинаем процесс с начала. Во многих областях, от медицины до металлургии, первые успехи в ML стимулируют проводить новые эксперименты: собирать больше данных, инвестировать больше времени в проработку гипотез, ставить всё новые задачи. Поэтому цикличность кажется неотъемлемым свойством таких проектов.
Планирование
Первая и главная задача при планировании ML-проекта - оценка экономического эффекта. Часто заранее непонятно, каким может быть эффект. Но можно использовать "правило большого пальца": если 1% от величины, которую мы надеемся оптимизировать - это серьёзные деньги, то у нас вообще есть шансы принести финансовую пользу. Улучшения сильно меньше одного процента обычно сложно измерить. Улучшения сильно больше одного процента не всегда достижимы средствами машинного обучения: это всё-таки не магия.
Важно, чтобы мы могли оценить результат внедрения:
- KPI бизнеса должны совпадать с тем, что мы оптимизируем - например, если мы сокращаем издержки, бизнесу должно быть важно сокращение издержек (а не только рост доли рынка, например)
- При оценки эффекта учитывать все факторы (в т.ч. побочные эффекты, например, от излишней коммуникации с клиентами)
- Улучшения должны быть статистически значимы. На маленьких данных это не всегда быстро. И часто вообще приходится выбирать: или переходить на более быстрые и шумные метрики, или долго ждать созревания честного результат.
- Эффект должен быть устойчивым - при изменении базы он должен сохраниться. Например, если мы внедрили модель в марте, и показали улучшение по сравнению с февралём, то в апреле нам нужно будет доказывать, что это улучшение сохраняется. Если не продумать этого, мы рискуем вступить в гонку сами с собой - и рано или поздно проиграть.
Желаемый эффект будет достигнут, только если новый процесс, основанный на машинном обучении, вообще можно внедрить:
- Построенная модель достаточно интерпретируема, чтобы ей начали пользоваться.
- Производство должно быть достаточно автоматизировано, чтобы можно было в реальном времени отправлять данные и получать рекомендации.
- Должны быть доступны технические ресурсы. Это нетривиально - например, компьютеры на заводе могут быть на порядок дороже, чем в офисе, т.к. работают они иногда в экстремальных условиях.
Для успеха проекта, разумеется, должны быть доступны данные. Но это не всегда так:
- Иногда сохраняемые данные слишком сильно агрегируются, чтобы на их основе можно было давать нетривиальные рекомендации.
- Бумажные документы и ручной ввод - сильный стоп-фактор, ибо в ходе построения модели это надо расшифровывать и исправлять, а в ходе использования - заменять чем-то цифровым.
- Часто нужны справочники значений, встречающихся в данных, и на их создание и поддержку требуются ресурсы экспертов.
- Узким местом может быть скорость канала связи - например, если вам нужно в реальном времени распознавать изображения, которые снимаются где-то на крайнем севере.
Ставя задачу алгоритмизации какого-то процесса, стоит проверять новизну: есть ли по этой тематике открытые кейсы, научные публикации, патенты? Если нет, то почему? Абсолютно пустая ниша - это может быть и хорошо, и плохо. Но в любом случае, если в этой области что-то уже делали, об этом стоит знать.
Реализация проекта
Реализация проекта - дело рук в первую очередь data scientist'ов (а также разработчиков, ML-инжен.еров, и так далее). Чем они занимаются?
Часто это не типичная разработка (когда заранее есть feature list), а эксперименты (успехом завершаются далеко не все). Экспериментировать можно с созданием и отбором признаков, выбором формы моделей и её тюнингом, применением "спортивных" приёмов в стиле kaggle, и так далее. Список эксперименов можно и нужно составлять заранее, и управлять им по мере развития проекта. И стоит заранее задумываться о схемах тестирования и метриках успеха. Наиболее успешный эксперимент и станет тем прототипом, который вам предстоит внедрить. Сам процесс внедрения - это по сути тоже эксперименты, но теперь они подчиняются гораздо более жёстким ограничениям по срокам, техническим решениям, и цене ошибки.
Как жить после внедрения
Успешным внедрением модели проект не заканчивается
- Нужно измерять скорость деградации модели. Её качество, скорее всего, в какой-то момент начнёт снижаться, и важно его не пропустить.
- Есть риски изменений со стороны заказчика: новые процессы в старой модели могут не поддерживаться. Например, выход компании на новые рынки, изменения производимого сортамента, или замена оборудования могут всё сломать.
- Дообучение модели на новых данных. Иногда это можно делать автоматически на площадке заказчика, иногда для каждой итерации дообучения требуется эсперт, чтобы проверять входные данные и/или валидировать полученный результат.
- Оценка качества модели: хочется делать это автоматизированно и потоком, но так не всегда получается. Иногда надо специально готовить тестовые выборки, иногда - вручную оценивать результат (в том числе с помощью краудсорсинга).
Что можно мониторить:
- Что IT-сервис вообще жив и отрабатывает быстро и без ошибок.
- Качество принимаемых решений: сравниваем с ситуацией до внедрения модели (что эффект вообще есть) и с недавними периодами (что он не деградирует).
- Распределение всего: признаков во входных данных (их изменение - это баг, или это изменился мир?), частоты запросов по времени, значений ответов модели. Изменения нужно интерпретировать и решать, стоит ли как-то реагировать на них.
На этом месте презентация Саши закончилась (он уложился минут в 15), и пошли вопросы:
Q: На каких этапах ML-проекта нужно сильнее всего напрягаться?
А: Больше всего усилий стоит прикладывать с начала, чтобы точно поставить правильную задачу. Не менее важно напрячься и при внедрении модели, чтобы оперативно фиксить все вылезающие баги и помогать пользователю научиться применять модель.
Q: Какие есть основные риски таких проектов?
А: Наверное, опаснее всего два внешних риска:
- конечный потребитель не примет модель - не будет запрашивать рекомендации или пользоваться ими
- имеющиеся данные некорректные или неполные, но исполнитель не имеет возможности это проверить
И один внутренний риск - неправильная постановка задачи. Подробнее про эти риски можно почитать на Хабре.
Q: Какие основные роли выделяются в таких проектах?
А: На наших проектах обычно встречаются следующие:
- Менеджер проектов (это я)
- Аналитик по данным, aka data scientist - тот, кто строит модель
- Бизнес-аналитик. Про него часто забывают, ведь какой-то аналитик в проекте уже есть :)
- Разработчик. Часть разработки может брать на себя DS, но в инфраструктурных задачах ему обычно нужна помощь
- Дата-инженер. Но если данные простые, пусть таким инжинирингом лучше занимается DS, чтобы не распылять задачи
Q: Сколько нужно людей на проект? От чего это зависит?
A: В типичном маленьком пилотном проекте участвует один project, один DS (и ещё один, который иногда делает ревью), он же аналитик, и один разработчик. Если задача достаточно сложная или срочная, команда увеличивается. Количество человеческих ресурсов определяется во многом сложностью того процесса, который мы пытаемся оптимизировать: например, предсказание одной величины проще, чем многофакторная оптимизация.
Q: Какими методологиями вы пользуетесь?
A: Какой-то конкретной методологии (например, гибкая разработка), которая всегда бы выстреливала, нет: всё-таки это эксперименты. На разных проектах и в разных командах могут работать совершенно разные форматы.
Другие доклады с того же мероприятия раскрыли несколько тем, поднятых Сашей:
- Как выбрать схему ценообразования ML-проекта? Стоит ли привязывать его стоимость к затратам или результату, или оставить фиксированной?
Их конспекты мы тоже скоро выложим, поэтому подписывайтесь!
