в чем выражается надежность метрики
Семь раз отмерь, один раз отрежь: как не запутаться в метриках продукта, процесса и счастья команды
Сегодня моя цель – коротко рассказать о подходах data-informed продуктового менеджмента, который я исповедую и попытаться заинтересовать вас в использовании его базовых инструментов в ваших продуктах.
Короткий дисклеймер – я пришла в продуктовую разработку из проектного менеджмента в аутсорсе. Для меня стало неожиданностью, что в то время как продуктовым метрикам уделяется пристальное внимание, процессные и командные часто незаслуженно уходят на задний план.
Для себя я сформулировала, что измерения успешности продукта состоит из трех блоков:
— счастье пользователей;
— успешность (качественная и количественная) итераций и релизов;
— счастье команды.
Счастье пользователей
Часто его мы пытаемся измерить так подробно и со стольких сторон, что анализ полученной информации превращается в настоящую пытку.
Поэтому в проектах мы попробовали использовать легковесный фреймворк HEART и подход Цели-Сигналы-Метрики, который придумали ребята из Google, и который здорово помогает сфокусироваться на по настоящему важных для UX продукта вещах.
HEART разделяет все метрики на 5 категорий
Happiness (Счастье)
К метрикам счастья относятся, к примеру:
— пользовательское удовлетворение;
— ощущение, что продуктом легко пользоваться;
— net promoter score.
Engagement (Вовлечение)
К примеру:
— количество визитов пользователя в неделю;
— количество фото, загружаемых юзером в день;
— количество лайков и шэров.
Adoption (Принятие)
К принятию можно отнести:
— обновления до новой версии;
— созданные пользователем подписки;
— покупки сделанные новыми пользователями в приложении.
Retention (Возвращаемость)
Конкретными метриками здесь могут быть:
— количество пользователей, остающихся активными с течением времени
— churn
— повторные покупки
Task Success (Успех ключевых задач)
Ключевыми задачами могут, к примеру быть:
— успешные поиски;
— время загрузки фотографии;
— полностью заполненный пользователем профиль.
Необязательно пытаться придумать важные для вашего продукта метрики во всех этих категориях. HEART — о том, чтобы выбрать 1 или 2 по настоящему важных и на какой-то период сконцентрировать внимание именно на них.
К примеру, в энтерпрайз продукте, который пользователи так или иначе должны использовать каждый день, вовлечение может быть не так важно. Зато счастье и успех ключевых задач – это то, на чем стоит сконцентрироваться как минимум на стартовом этапе.
HEART позволяет легко «конвертировать» важные для вас категории в значимые метрики, которые можно непосредственно отслеживать.
Все, что вам нужно, это начать не с брейнсторминга интересных штук, которые вы бы хотели трекать в проекте или который позволяет отслеживать новая хитрая система продуктовой аналитики. Вам нужно начать с более высокоуровневых штук: определиться, какие цели преследует ваш проект.
Goals-Signals-Metrics
Как бы капитански это не звучало, иногда бывает не так просто сформулировать цели продукта, с которыми однозначно согласна вся команда, и в этом неплохо помогает HEART. Также здесь важно не допустить типичную ошибку – не формулировать цели в терминах уже существующих метрик.
К примеру, одна из наших целей в моем текущем продукте – заинтересовать пользователей рекомендациями и сделать так, чтобы они проводили в их изучении больше времени.
Часто одной цели могут потенциально подходить несколько сигналов, поэтому на этапе их определения полезно поанализировать и понять, какие из них легче или сложнее трекать, какие более чувствительны к изменениям в вашем продукте и определить оптимальный для вашей цели.
Сигнал в этом случае – количество времени, которое пользователи взаимодействуют с рекомендациями. Метрика – это количество минут на пользователя, потраченных на изучение рекомендаций.
Описанный процесс помогает естественным образом приоритезировать метрики и избавиться от лишнего шума в ваших измерениях. Это своеобразная бритва Оккама, которая со стороны выглядит очень тривиальной, но часто наталкивает на неожиданные выводы и действия.
А как же процесс?
Но измерения продукта, – это еще не все. И хотя HEART дает многое для того, чтобы понять, как сделать продукт лучше для наших пользователей, для долгосрочной успешной работы нам не хватает понимания того, все ли у нас хорошо с процессом и командой.
Часто в продуктах я сталкиваюсь с тем, что эти вопросы замалчиваются, потому что вроде бы все и так неплохо, у людей горят глаза, мы тут делаем классную штуку, да и вообще это все какое-то старперство.
Очередная жуткая тривиальность, о которой все знают, но которую очень легко игнорировать: time-to-market, скорость реакции на рынок и действия конкурентов критично важны для успеха продуктов.
Отсутствие внимания к тому, как развивается ваш технический долг, насколько успешны ваши итерации, какие стратегические проблемы копятся в вашем процессе, приводят к тому, что ваши проекты превращаются в попытку запрыгнуть в уходящий трамвай.
Мой маленький бутстрап процессных метрик состоит из трех частей. Их легко мерить, и если вы еще не делаете этого, я призываю вас попробовать подумать над собственным набором метрик, которые отражают прозрачность и здоровье вашего процесса. Конкретные примеры метрик могут не соответствовать тому, что важно измерять в вашем проекте, поэтому будьте осторожны с буквальным применением этого блока.
Количественные метрики релиза
Тут все просто. Чтобы понять, как у вас дела, достаточно мерить скорость vs качество вашей работы.
Метрикой скорости может служить непосредственно скорость команды или составная метрика: пользовательские истории, сделанные в течение этой итерации/не завершенные, но запланированные/перенесенные в следующую итерацию.
Метриками, отражающими не ущемляете ли вы качество в ущерб скорости могут быть:
— количество дефектов, найденных за итерацию/vs пробравшихся в итоге на продакшн
— распределение дефектов по типам/компонентам и источникам
К тому же такая штука здорово помогает на раннем этапе вылавливать технологические риски проекта.
Мне довелось работать в проекте, где основным источником дефектом стал внешний компонент, использовавшийся командой. В тот момент, когда это обнаружили, – он был просто досадной неприятностью, и от него решили избавиться, чтобы не портить статистику.
Где-то через полгода было довольно печально наблюдать за соседними командами, которые начали в спешке отказываться от этого компонента, который к тому времени превратился для многих в настоящий блокер к дальнейшему развитию продуктов.
Качественные метрики релиза
— отношение количества сделанных пользовательский историй к общему числу историй в проекте;
— отклонение от запланированной даты релиза;
— технический долг.
Наверняка многие из вас сталкивались с проектами, о которых говорят, что «да это легче с нуля написать, чем поддерживать». Виной этому часто технический долг, разроссшийся до невероятных размеров. Если вы не знаете о нем и не менеджите его сегодня, вполне возможно, что завтра он сделает вам больно. Это кажется потрясающе очевидным в engineering-centered компаниях, но я видела столько случаев, когда бизнес и продукт настолько доминируют над здоровыми инженерными практиками, что нельзя было не упомянуть этот пункт.
И, наконец, качественные метрики.
В первую очередь – это простой список того, что было хорошо, что стоит улучшить. Тут важно сказать, что это не просто метрика, которую надо отслеживать. Это процесс непрерывных улучшений, который нужно постараться внедрить на своем проекте. Если мы постоянно не стараемся стать лучше, то постепенно мы становимся чуть хуже, чем были раньше. Как минимум потому что окружающий мир не стоит на месте.
Список того, что стоит улучшить может включать в себя абсолютно любые вещи, – от добавления в ваш код стайл новых гайдов до покупки удобных стульев для команды. И это не просто – собрались, поговорили и разошлись, – а план конкретных действий, которые нужно сделать для улучшения.
Team is the King
И о последней, самой важной, как на мой взгляд, части отличного продукта.
Простой тест – знаете ли вы, что заставляет каждого человека из вашей команды каждое утро приходить на работу? А знаете ли, что заставляет сцеплять зубы и думать «как же они меня достали, еще раз и пойду писать заявление»?
Если вы, как и я, считаете, что без мотивированной и удовлетворенной команды продукт в долгосрочной перспективе не может стать полностью успешным, то самое время разобраться с этими вопросами.
Каждый раз, когда я говорю подобные штуки, люди начинают спрашивать, – «Ну и как узнать такие интимные вещи? А вдруг мой коллега хочет уйти из нашей большой компании в тех стартап или скопить денег и переехать в Таиланд? Как же он мне об этом расскажет?»
Но ведь вы, правда, не хотите узнать об этом в тот момент, когда он положит заявление на стол? Поэтому я предлагаю начать с анкеты, которую разработал Макс Ландсберг и которая позволяет получить кучу важной информации, о том, что драйвит и расстраивает вашу команду, и дальше понять, что с этим делать. И обязательно прочитайте «Motivate Me Right» Стаса Давыдова, если по какой-то причине вы этого еще не сделали.
Обратная связь
В любом продукте на разных этапах развития мы стремимся получить максимум фидбека от пользователей. Он служит своеобразной путеводной звездой и часто помогат понять, на правильном ли мы пути.
Личный профессиональный фидбек внутри команды – это такая же путеводная звезда. Если вы регулярно не получаете фидбек о вашей работе от вашей команды и не даете его тем людям, с которыми вы вместе создаете продукт, в вашем продукте могут копиться проблемы, которые вы даже не осознаете.
На одном из проектов мне довелось наблюдать за уходом талантливейшего разработчика.
Забавно, но о нем никто из менеджмента за 2 года работы не узнал, что этот парень по настоящему нуждался в профессиональном признании, очень трепетно относился к выступлениям на конференциях, наставничеству новичков, участии в оупенсорсных проектах. Участие в конференциях все время откладывалось, то дедлайны в проектах, то денег маловато, чтобы поехать на Java Day где-то в штатах, и через 2 года он не выдержал и ушел работать в крупную компанию tech евангелистом.
Я уверена, этому разработчику было что сказать своим менеджерам в качестве фидбека. И таких примеров море. Фидбек помогает получить и дать важную для развития и сохранения команды информацию, и ею не стоит пренебрегать. Вы можете пойти еще дальше и попробовать собирать фидбек на уровне нескольких команд или большого проекта. Почитайте, как это делает Valve, это вовсе не так сложно, как может показаться.
9 метрик, которые могут иметь значение для современных команд по разработке ПО
Перевод статьи подготовлен в преддверии старта курса «Team Lead 2.0».
Как я отмечал в статье «Why metrics don’t matter in software development unless you pair them with business goals», выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как «Сколько у нас сейчас тысяч строк кода в проекте?»
В этой статье продолжается тема, начатая в предыдущей. Сначала мы поговорим о конкретных метриках, которые должна использовать каждая команда, или по крайней мере планирует использовать для того, чтобы заметно улучшить производительность. Обратите внимание, что название этой статьи начинается как «9 метрик, которые МОГУТ иметь значение…», потому что важно именно то, как эти метрики повышают ценность бизнеса. Как вы их будете использовать зависит только от вас. Завершим мы статью рассказом о том, как осмысленно сочетать эти метрики между собой, а также сформулируем и проверим гипотезу о ценности бизнеса.
Начните с измерения правильных вещей
Здесь представлены 9 объективных показателей (или метрик), которые необходимо постоянно отслеживать, чтобы инкрементально улучшать процессы и производственную среду. Улучшение этих показателей не гарантирует, что уровень удовлетворенности ваших клиентов будет расти не по дням, а по часам. Однако, это те показатели, которые действительно нужно мониторить. В одном из последующих разделов «Собираем все вместе», вы узнаете почему.
Метрики Agile-процесса
Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.
Вы не можете точно знать или хотя бы предполагать откуда берутся те или иные цифры, но эти метрики дадут вам понимание того, где и на какие процессы стоит обратить внимание. Например, высокий показатель open и низкий close в течение нескольких итераций может означать, что issue продакшена сейчас имеют более низкий приоритет, чем новые функции, или, возможно команда сосредоточена на сокращении технического долга и исправления целых классов проблем, или же, что единственный человек, который знал, как их исправить уволился или с ним что-то случилось. Из чисел вы первопричину точно не узнаете.
Аналитика продакшена
Частота сбоев приложения – количество раз, которое приложение «падает», деленное на количество использований. Этот показатель напрямую связан с MTBF и MTTR.
Обратите внимание, что ни одна из этих трех метрик не даст вам представление об отдельных функциях или задействованных пользователях. И все же, чем меньше значения показателей, тем лучше. Современные системы мониторинга приложений позволяют с легкостью собирать эти метрики по программам и транзакциям, но чтобы настроить правильные диапазоны для отправки предупреждений или триггеры для масштабирования (применительно к облачным системам), нужно время и тщательное осмысление.
Конечно, хотелось бы, чтобы наше ПО никогда не отказывало, но статистически это маловероятно. Хотелось бы, чтобы никакие важные данные не терялись и приложение восстанавливалось мгновенно, когда оно падает, но достичь этого бывает чрезвычайно сложно. Однако, если ваше программное обеспечение – это ваш источник дохода, то усилия того стоят.
Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1-2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.
Метрики безопасности
Безопасность – важный аспект качества программного обеспечения, который на поздних этапах разработки (или последующих этапах жизненного цикла) часто упускается. Инструменты анализа безопасности могут использоваться в процессе сборки вместе с более специализированными методами оценки и стресс-тестами. Требования к безопасности согласуются со здравым смыслом, но команда разработчиков должна всегда о них помнить, ровно как и о метриках от них происходящих.
Полный спектр методов обеспечения безопасности и связанных с ними метрик выходит за рамки этой статьи, но, как и в случае с метриками agile-процессов и метриками продакшена, существует несколько вполне конкретных показателей, которые будут иметь большое значение для удовлетворения потребностей ваших клиентов.
Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.
Заметка о метриках исходного кода
На сегодняшний день подключить сканнер исходников к пайплайну сборки и получить ворох объективных метрик достаточно легко. Существуют эмпирические средние значения, предлагаемые диапазоны и логические аргументы в пользу относительной важности этих показателей. Однако на практике эти инструменты более полезны для обеспечения соблюдения определенного стиля написания кода, выделения определённых антипаттернов и выявления аномалий и закономерностей.
Не стоит зацикливаться на цифрах. Приведу пример, чтобы вы поняли, к чему я клоню.
Допустим, вы обнаружили в классе метод с нелепым значением показателя сложности NPATH в 52 миллиона. То есть потребуется 52 миллиона тест-кейсов, чтобы протестировать каждый вариант выполнения метода. Вы можете отрефакторить код и получить более простую структуру, но прежде, чем это сделать, подумайте о том, как это отразится на бизнес-логике. Скорее всего этот старый страшный код работает достаточно хорошо (несмотря на то, что он может быть не полностью покрыт тестами). Ценным будет показать этот антипаттерн своей команде, чтобы они так больше не делали, поскольку фикс этого метода в целом не изменит ни одну стоящую бизнес-метрику.
Лучше всего, если команда согласится с уровнем требований и правилами, которым отвечает их код, но имейте в виду, что изучение аномалий и беспокойство на тему появления каких-либо закономерностей может отнимать время.
Соберем все вместе: Успех – универсальная метрика
Главный плюс использования автоматизированных инструментов для отслеживания и измерения показателей качества и анализа поведения пользователей кроется в том, что они освобождают время для работы над действительно важными показателями – показателями успеха.
Как использовать метрики для достижения успеха
У бизнеса есть цели. В целях кроются вопросы, например: «Как выглядит успех?» или «Как продукт повлияет на поведение клиентов?». Правильно сформулированные вопросы таят в себе метрики.
Другими словами, метрики должны использоваться только для ответов на поставленные вопросы, для проверки гипотез, сформулированных относительно конкретной бизнес-цели. Отвечать на эти вопросы следует до тех пор, пока ответы приводят к положительным изменениям.
Разве не все у всех проектов есть некоторый набор инвариантных целей, вопросов и гипотез, а следовательно, и метрик?
Да, но только с точки зрения бизнеса. Метрики уровня бизнеса, такие как вовлеченность пользователей, коэффициент закрытия сделок, генерирование доходов и т.д., дают фидбэк о том, как влияет бизнес на реальный мир. Изменения в ПО, которые повлияют на бизнес, также повлияют и на эти метрики.
На более тонком уровне разрешения каждая функция и User Story могут иметь свой собственный показатель успеха – предпочтительнее, чтобы он был единственным и был связан непосредственно с ценностью, которая доставляется клиенту. Закрытие 9 из 10 историй за спринт для функций, которые остаются недоставленными – это не успех, а поражение. Доставка историй, которые клиентам не нужны, и они их не используют – не успех, а пустая трата времени и сил. Создание историй, которые делают пользователя немного счастливее – вот это успех. Создание истории, которая не улучшила взаимодействие с пользователями, тоже своего рода успех, поскольку теперь вы знаете, что эта бизнес-гипотеза не работает, и можете освободить ресурсы для поиска других идей.
Как сформулировать ценностную гипотезу
Ценностная гипотеза – это утверждение о том, что, по вашему мнению, произойдет в результате добавления определенной функции. Взаимосвязь между программным обеспечением, желаемым результатом и метриками формирует ценностную гипотезу для функции (или системы, истории, обновления и т.д.). Гипотеза должна выражать ожидаемое изменение целевой метрики в течение определённого промежутка времени, а также понятие о ее эффективности. Вам нужно будет поговорить с командой и с Product Owner-ом, чтобы как минимум выяснить, что именно это функция или история может создать или улучшить применительно к бизнесу, чтобы сформулировать относительно нее ценностную гипотезу. Возможно, задать вопрос «почему» вам придется несколько раз (как ребенку), чтобы избавиться от невысказанных предположений, поэтому будьте терпеливы. Когда вы поймете, какой должна быть ценность для бизнеса, вы можете начать задавать вопросы, которые приведут вас к метрикам, дающим на них ответы.
Например, «техническая» история о повышении скорости оформления заказа в интернет-магазине может иметь под собой идею о том, что ускорение продаж приведет к росту их количества. Но почему мы так думаем? Много ли людей оставляют корзины с товарами во время процесса оформления заказа? Если вы пришли к консенсусу (подкрепили свои предположения данными), то ценностная гипотеза может быть звучать так: «Мы считаем, что ускорение процесса оформления заказа приведет к снижению коэффициента «отказа от корзины». В свою очередь это приведет к увеличению продаж и улучшению пользовательского опыта.»
Вероятно, вы предполагаете, что пользователям понравится ускорение оформления заказа, но не будет лишним спросить, заметили ли они это вообще. Коэффициент отказа от корзины и продажи можно замерить в течение определенного времени до внедрения нового процесса и после. Если коэффициент отказа от корзины падает, а продажи увеличиваются (с учетом статистических колебаний), то доказательства подтверждают гипотезу, и вы можете задаться вопросом, оправдано ли дальнейшее увеличение скорости оформления покупки. Если нет, то пускай эта метрика отойдет на задний план (или вообще исключите ее, чтобы не отвлекала), и переключите свое внимание на следующую гипотезу. Если коэффициент отказа от корзины уменьшается, а продажи остаются неизменными, проводите измерения дольше или попробуйте переосмыслить предполагаемую связь между отказом от корзины и продажами. Другими словами, используйте метрики, которые приносят значимые улучшения для того, чтобы учиться.
В некоторых случаях, гипотеза оказывается ошибочной, и мы отбрасываем метрики (и откатываемся к старой версии программного обеспечения) спустя несколько дней. В других случаях гипотеза может быть верной, поэтому мы продолжаем улучшать показатели в этой области в течение долгих лет.
Шесть эвристик для эффективного использования метрик
Мы увидели, как субъективные метрики делали больший вклад в успех бизнеса, чем старые добрые объективные показатели качества. Полученные знания и возможности для обучения преобладают над усилиями, необходимыми для поиска и измерения соответствующих бизнес-показателей функций. Условия бизнеса и возможности меняются постоянно, поэтому вместо того, чтобы выводить хрупкую формулу, которой можно было бы следовать, я дам шесть эмпирических правил, или эвристик, которые помогут сохранить сосредоточенность и гибкость. Пусть они помогут вам на вашем пути к качественному программному обеспечению и успеху!
В чём мерить будем? Как выбрать правильные ML-метрики под задачи бизнеса
Сегодня одним из главных препятствий на пути внедрения машинного обучения в бизнес является несовместимость метрик ML и показателей, которыми оперирует топ-менеджмент. Аналитик прогнозирует увеличение прибыли? Но ведь нужно понять, в каких случаях причиной увеличения станет именно машинное обучение, а в каких — прочие факторы. Увы, но довольно часто улучшение метрик ML не приводит к росту прибыли. К тому же иногда сложность данных такова, что даже опытные разработчики могут выбрать некорректные метрики, на которые нельзя ориентироваться.
Давайте рассмотрим, какие бывают метрики ML и когда их целесообразно использовать. Разберём типичные ошибки, а также расскажем о том, какие варианты постановки задачи могут подойти для машинного обучения и бизнеса.
ML-метрики: зачем их так много?
Метрики машинного обучения весьма специфичны и часто вводят в заблуждение, показывая хорошую мину при плохой игре хороший результат для плохих моделей. Для проверки моделей и их совершенствования нужно выбрать метрику, которая адекватно отражает качество модели, и способы её измерения. Обычно для оценки качества модели используют отдельный тестовый набор данных. И как вы понимаете, выбор правильной метрики — задача сложная.
Какие задачи чаще всего решаются с помощью машинного обучения? В первую очередь это регрессия, классификация и кластеризация. Первые две — так называемое обучение с учителем: есть набор размеченных данных, на основе какого-то опыта нужно предсказать заданное значение. Регрессия — это предсказание какого-то значения: например, на какую сумму купит клиент, какова износостойкость материала, сколько километров проедет автомобиль до первой поломки.
Кластеризация — это определение структуры данных с помощью выделения кластеров (например, категорий клиентов), причём у нас нет предположений об этих кластерах. Этот тип задач мы рассматривать не будем.
Алгоритмы машинного обучения оптимизируют (вычисляя функцию потерь) математическую метрику — разность между предсказанием модели и истинным значением. Но если метрика представляет собой сумму отклонений, то при одинаковом количестве отклонений в обе стороны эта сумма будет равна нулю, и мы просто не узнаем о наличии ошибки. Поэтому обычно используют среднюю абсолютную (сумма абсолютных значений отклонений) или среднюю квадратичную ошибку (сумма квадратов отклонений от истинного значения). Иногда формулу усложняют: берут логарифм или извлекают квадратный корень из этих сумм. Благодаря этим метрикам можно оценить динамику качества вычислений модели, но для этого полученный результат нужно с чем-то сравнить.
C этим не возникнет сложностей, если уже есть построенная модель, с которой можно сравнить полученные результаты. А что если вы в первый раз создали модель? В этом случае часто используют коэффициент детерминации, или R2. Коэффициент детерминации выражается как:
Где:
R^2 — коэффициент детерминации,
et^2 — средняя квадратичная ошибка,
yt — верное значение,
yt с крышкой — среднее значение.
Единица минус отношение средней квадратичной ошибки модели к средней квадратичной ошибке среднего значения тестовой выборки.
То есть коэффициент детерминации позволяет оценить улучшение предсказания моделью.
Иногда бывает, что ошибка в одну сторону неравнозначна ошибке в другую. Например, если модель предсказывает заказ товара на склад магазина, то вполне можно ошибиться и заказать чуть больше, товар дождётся своего часа на складе. А если модель ошибётся в другую сторону и закажет меньше, то можно и потерять покупателей. В подобных случаях используют квантильную ошибку: положительные и отрицательные отклонения от истинного значения учитываются с разными весами.
В задаче классификации модель машинного обучения распределяет объекты по двум классам: уйдет пользователь с сайта или не уйдет, будет деталь бракованной или нет, и т.д. Точность предсказания часто оценивают как отношение количества верно определенных классов к общему количеству предсказаний. Однако эту характеристику редко можно считать адекватным параметром.
Рис. 1. Матрица ошибок для задачи предсказания возвращения клиента
Пример: если из 100 застрахованных за возмещением обращаются 7 человек, то модель, предсказывающая отсутствие страхового случая, будет иметь точность 93%, не имея никакой предсказательной силы.
Рис. 2. Пример зависимости фактической прибыли компании от точности модели в случае разбалансированных классов
Для каких-то задач можно применить метрики полноты (количество правильно определенных объектов класса среди всех объектов этого класса) и точности (количество правильных определенных объектов класса среди всех объектов, которые модель отнесла к этому классу). Если необходимо учитывать одновременно полноту и точность, то применяют среднее гармоническое между этими величинами (F1-мера).
С помощью этих метрик можно оценить выполненное разбиение по классам. При этом многие модели предсказывают вероятность отношения модели к определенному классу. С этой точки зрения можно изменять порог вероятности, относительно которого элементы будут присваиваться к одному или другому классу (например, если клиент уйдёт с вероятностью 60 %, то его можно считать остающимися). Если конкретный порог не задан, то для оценки эффективности модели можно построить график зависимости метрик от разных пороговых значений (ROC-кривая или PR-кривая), взяв в качестве метрики площадь под выбранной кривой.
Рис. 3. PR-кривая
Бизнес-метрики
Выражаясь аллегорически, бизнес-метрики — это слоны: их невозможно не заметить, и в одном таком «слоне» может уместиться большое количество «попугаев» машинного обучения. Ответ на вопрос, какие метрики ML позволят увеличить прибыль, зависит от улучшения. По сути, бизнес-метрики так или иначе привязаны к увеличению прибыли, однако нам почти никогда не удаётся напрямую связать с ними прибыль. Обычно применяются промежуточные метрики, например:
Первая сложнее, её результаты использует вторая. Ошибки в модели предсказания вынуждают закладывать больший запас в модели оптимизации, поэтому оптимизируемая сумма уменьшается.
Пример: чем ниже точность предсказания поведения клиентов или вероятности промышленного брака, тем меньше клиентов удаётся удержать и тем меньше объём сэкономленных материалов.
Общепринятые метрики успешности бизнеса (EBITDA и др.) редко получается использовать при постановках задач ML. Обычно приходится глубоко изучать специфику и применять метрики, принятые в той сфере, в который мы внедряем машинное обучение (средний чек, посещаемость и т.д.).
Трудности перевода
По иронии судьбы удобнее всего оптимизировать модели с помощью метрик, которые трудно понять представителям бизнеса. Как площадь под ROC-кривой в модели определения тональности комментария соотносится с конкретным размером выручки? С этой точки зрения перед бизнесом встают две задачи: как измерить и как максимизировать эффект от внедрения машинного обучения?
Первая задача проще в решении, если у вас есть ретроспективные данные и при этом остальные факторы можно нивелировать или измерить. Тогда ничто не мешает сравнить полученные значения с аналогичными ретроспективными данными. Но есть одна сложность: выборка должна быть репрезентативна и при этом максимально похожа на ту, с помощью которой мы апробируем модель.
Пример: нужно найти самых похожих клиентов, чтобы выяснить, увеличился ли у них средний чек. Но при этом выборка клиентов должна быть достаточно большой, чтобы избежать всплесков из-за нестандартного поведения. Эту задачу можно решить с помощью предварительного создания достаточно большой выборки похожих клиентов и на ней проверять результат своих усилий.
Однако вы спросите: как перевести выбранную метрику в функцию потерь (минимизацией которой и занимается модель) для машинного обучения. С наскока эту задачу не решить: разработчикам модели придётся глубоко вникнуть в бизнес-процессы. Но если при обучении модели использовать метрику, которая зависит от бизнеса, качество моделей сразу вырастает. Скажем, если модель предсказывает, какие клиенты уйдут, то в роли бизнес-метрики можно использовать график, где по одной оси отложено количество уходящих, по мнению модели, клиентов, а по другой оси — общий объём средств у этих клиентов. С помощью такого графика бизнес-заказчик может выбрать удобную для себя точку и работать с ней. Если с помощью линейных преобразований свести график к PR-кривой (по одной оси точность, по второй полнота), то можно оптимизировать площадь под этой кривой одновременно с бизнес-метрикой.
Рис. 4. Кривая денежного эффекта
Заключение
Прежде чем ставить задачу для машинного обучения и создавать модель, нужно выбрать разумную метрику. Если вы собираетесь оптимизировать модель, то в качестве функции ошибок можно использовать одну из стандартных метрик. Обязательно согласуйте с заказчиком выбранную метрику, её веса и прочие параметры, преобразовав бизнес-метрики в модели ML. По длительности это может быть сравнимо с разработкой самой модели, но без этого не имеет смысла приступать к работе. Если привлечь математиков к изучению бизнес-процессов, то можно сильно уменьшить вероятность ошибок в метриках. Эффективная оптимизация модели невозможна без понимания предметной области и совместной постановки задачи на уровне бизнеса и статистики. И уже после проведения всех расчётов вы сможете оценить полученную прибыль (или экономию) в зависимости от каждого улучшения модели.
Николай Князев (iRumata), руководитель группы машинного обучения «Инфосистемы Джет»