№1. Никакого машинного обучения. КПЭ в первую очередь.
Это рассказ (на самом деле это первый) из серии Летные проверки любого (большого) проекта машинного обучения.
Нет ничего более заманчивого при запуске проекта машинного обучения, чем… ну… заниматься машинным обучением! В конце концов, для этого мы здесь, верно? Тогда давайте не будем больше ждать и запустим наши DNN, настроим искровой кластер и… отключимся, чтобы создать ценность.
Придержи лошадей! В реальном мире так не работает.
Самая распространенная и дорогостоящая ошибка, которую я видел, - это запуск проекта машинного обучения без четких ключевых показателей эффективности.
Честно говоря, это может относиться к любому программному проекту. Но это особенно важно в случае проектов машинного обучения, где по определению мы ищем оптимизацию «чего-то».
Метрики, которые мы определяем в начале проекта, будут направлять значительную часть последующих усилий. Отсутствие четких KPI заставит нас раскрутиться в воздухе, пока у нас не закончится топливо.
Загвоздка в том, что эта задача может показаться тривиальной. Нет.
Что еще хуже, бизнес-KPI сами по себе обычно выражают измерение, которое часто является слишком общим для потребностей измерения проекта.
Например, в случае предотвращения мошенничества бизнес-цель может быть такой: «Мы хотим создать лучший UX, поэтому нам нужно увеличить одобрение платежей, не увеличивая риски мошенничества».
Неискушенному глазу может показаться, что у нас уже определено 90% KPI:
Ничего более далекого от истины:
- Хотим ли мы улучшить опыт всех пользователей в равной степени или определенных пользовательских сегментов (например, новых пользователей), поскольку мы готовы идти на больший риск, чтобы способствовать их росту?
- Мы заинтересованы в измерении количества платежей или общей обработанной суммы? Стоит ли покупка на 5 долларов так же, как покупка на 1500 долларов?
- То же самое, если при покупке комиссия выше, чем при отсутствии комиссии?
- Когда мы говорим, что хотим сохранить текущий уровень мошенничества, это абсолютная или относительная величина? Если мы одобрим больше транзакций, сможем ли мы увеличить масштабы мошенничества в той же или меньшей степени и при этом достичь поставленной цели?
- Существуют ли в настоящее время какие-либо другие инициативы, влияющие на этот же показатель? Какие из них и на кого вы ссылаетесь? Например, есть ли на кассе проект изменения, чтобы упростить покупки в один клик?
- Какие факторы могут привести к тому, что платеж не будет одобрен? Собираемся ли мы контролировать все эти факторы? Например, если номер карты указан неверно, имеет ли смысл фильтровать эту переменную по метрике? Каков реальный процент изменений, которые мы можем внести в конечное состояние? Как мы можем приписать результат себе?
- Насколько сложно определить этот ключевой показатель эффективности? Есть ли база данных, к которой можно обращаться? Насколько сложен этот запрос? Кто будет его выполнять? Будет ли это доступно на панели управления?
- Как часто я смогу получать обновленную метрику: один раз в час, один раз в день, один раз в месяц? Будут ли данные достаточно свежими, чтобы измерять, что происходит в производственной среде, и принимать решения, или они будут только информативными относительно того, что уже произошло? И если да, то на какие данные я буду смотреть, чтобы принимать решения в режиме реального времени?
- Как этот ключевой показатель эффективности будет связан с метрикой, которую мы стремимся оптимизировать на основе моделей?
- Как мы собираемся произвести перевод между показателями развития (например, AUC) и ожидаемыми бизнес-ключевыми показателями эффективности? Насколько мы можем доверять этому переводу? Какие решения будут основаны на этом переводе?
- Все ли участники проекта согласны с предложенными KPI? Есть ли у нас подтверждение всех заинтересованных сторон?
При разработке ключевых показателей эффективности необходимо учитывать так много факторов, что, несомненно, задача является сложной и междисциплинарной. Тем не менее, это очень важно.
Несколько советов.
Выделите достаточно времени для разработки показателей в самом начале проекта:
- Инкрементная итеративная разработка - это нормально, но первая итерация должна иметь гораздо более высокую проектную нагрузку на KPI, чем остальные.
- Помните, что показатели разработки решения будут «привязаны» к бизнес-KPI.
Постройте показатели проекта вместе со спонсором и бизнес-специалистами:
- Совместная работа помогает согласовать ожидания.
- Помните, что определенные метрики, скорее всего, будут частью того, как работа каждой команды оценивается при каждой поставке.
- Важно, чтобы при разработке KPI участвовали самые старшие специалисты по данным - это может даже стать целью карьеры для младших специалистов по данным.
- Обычно нет определенного руководства по разработке каких-либо KPI, но полезно провести некоторое исследование, чтобы найти хорошие идеи.
Узнайте, какие другие факторы могут влиять на этот показатель:
- Будет ли он перемещен к лучшему или к худшему.
- Попробуйте отделить их от результатов измерения.
Убедитесь, что частота и точность обновления метрики соответствует требованиям проекта машинного обучения:
- Обязательно наличие хорошей инфраструктуры для измерения воздействия. Метрики модели - это обычно значения, которые мы хотим иметь в реальном времени и день за днем.
- Учтите, что мы обязательно хотим провести A / B-тестирование различных моделей… Готова ли инфраструктура к этому ? Нужно ли мне готовиться Это?
Поделитесь важностью разработки хорошего KPI:
- Хотя, возможно, это не та задача, которая вызывает больше всего шума, на мой взгляд, это одна из ключевых задач.
- Как участник проекта помните, что определенные здесь KPI - это те, которые будут измерять ваш прогресс в работе. Никто не сомневается, что KPI, которые вы стремитесь улучшить, будут улучшены, поэтому если KPI четко определены, ваш спонсор будет доволен вашей работой, и ваш вклад будет правильно оценен!
- Как руководитель инициативы, создайте стимулы для выполнения этой задачи с учетом ее важности, а также измерьте и спланируйте время, которое на это потребуется.
Я не могу достаточно выделить это. Это применимо независимо от того, создаете ли вы систему рекомендаций, оптимизатор времени доставки, детектор спама в комментариях, классификатор товаров или беспилотный автомобиль. Крайне важно определить ключевые показатели эффективности инициативы с самого начала.
Метрики разработки и измерения моделей будут основаны на бизнес-ключевых показателях эффективности. В то же время эти показатели разработки подтверждают решения об используемых алгоритмах, собранных данных и остальной работе. Неспособность разработать Правильные KPI не приведут к соответствию ожиданиям спонсора. Это может привести к размыванию команды и, таким образом, к возникновению разрыва между их усилиями, результатами и восприятием их прогресса.
Возможно, не удастся решить все на первой итерации ключевых показателей эффективности - некоторые проекты более сложны, чем другие, - но важно, чтобы это было ясно и ясно. Принятие решения на основе консенсуса между спонсором и командой помогает его повторять. Раньше чем позже.
Теперь за вас: как вы оцениваете разработку KPI вашего проекта?
Читая это, чувствовали ли вы, что какой-то опыт вам знаком?
Дайте нам знать!
