Интерпретируемость ML моделей для конечного пользователя: где нужна на практике и что делать
Где нужна на практике
Мы недавно рассмотрели ключевых пользователей интерпретации ML-моделей и различия в их потребностях в интерпретации.
На практике - и в рамках концепции Reliable ML - ключевой целью работы над моделью является ее итоговое применение в бизнес-процессах и финансовая польза от этого применения. Следовательно, ключевыми целями интерпретации являются цели бизнес-заказчика (финансовая польза) и пользователя ML-решения (корректное применение в бизнес-процессе).
При этом чаще всего и бизнес-заказчик и пользователь ML-решения формулируют требования и участвуют в приемке решения совместно, поэтому для простоты в некоторой литературе их называют конечными пользователями модели.
В каких блоках цикла управления продуктом продвинутой аналитики интерпретируемость моделей машинного обучения для конечного пользователя вашей модели становится важной? Поделимся своим видением.
В отдельных случаях критично думать об интерпретируемости уже на этапе разработки MVP. Особенно, когда нужно «продать» ваше решение конечному пользователю, или при очень высокой цене ошибки, когда без интерпретируемости моделей бизнес не готов идти даже на проведение пилота.
Но наиболее важное значение интерпретируемость имеет на этапах внедрения решения и мониторинга модельного риска. То есть, понятность модели конечным пользователям приобретает критическое значение именно тогда, когда модель доказала свою эффективность по итогам пилотного эксперимента и было принято решение о ролл-ауте (масштабировании модели на все целевые объекты).
Что именно становится важным?
- Доверие к результату. Принятие решений моделью должно быть понятно бизнесу как в целом (global interpretation), так и на отдельных примерах (local interpretation).
В случае низкого доверия к работе модели и к её логике принятия решений (модель позиционируется или воспринимается как черный ящик) сильно возрастают трудности с интеграцией модели в бизнес-процесс и обучением конечных пользователей ее использованию. Попросту говоря, моделью не хотят пользоваться, нарушают рекомендации, а если что-то идет не так, то виновата всегда модель. Особенно, если решение о ее ролл-ауте в итоге было принято сверху.
И наоборот, высокое доверие к модели способствует ее корректному применению и эффективной и быстрой интеграции в бизнес-процессы.
- Применимость модели в реальных условиях. Реальные условия, в которых работает модель, всегда так или иначе отличаются от тех, на которых она строилась. Кажется, что это уже ни для кого не секрет на фоне большого числа форс-мажорных событий последних лет.
Понятность модели конечному пользователю в продуктиве – как модель пришла к конкретному результату (данные, факторы, логика работы, итоговый прогноз/рекомендация) – снижает риск некорректного применения модели на новых данных, при сложных кейсах, в меняющейся среде. В случае аномального поведения модели человек, которому понятна модель, с большей вероятностью исправит или предотвратит неправильное решение. Митигации риска аномального поведения модели с технической стороны также очень помогают системы мониторинга модельного риска. О них мы поговорим в отдельных постах.
- Информативность для бизнес-процесса. Конечному пользователю должно быть понятно, что делать при виде результата работы модели. Именно это называют информативностью. То есть, для работы в боевых условиях чаще всего критически важно, чтобы результат работы был не просто красивыми сведениями, а содержал конкретную рекомендацию к действию (push to action).
#interpretable_ml #business
Где нужна на практике
Мы недавно рассмотрели ключевых пользователей интерпретации ML-моделей и различия в их потребностях в интерпретации.
На практике - и в рамках концепции Reliable ML - ключевой целью работы над моделью является ее итоговое применение в бизнес-процессах и финансовая польза от этого применения. Следовательно, ключевыми целями интерпретации являются цели бизнес-заказчика (финансовая польза) и пользователя ML-решения (корректное применение в бизнес-процессе).
При этом чаще всего и бизнес-заказчик и пользователь ML-решения формулируют требования и участвуют в приемке решения совместно, поэтому для простоты в некоторой литературе их называют конечными пользователями модели.
В каких блоках цикла управления продуктом продвинутой аналитики интерпретируемость моделей машинного обучения для конечного пользователя вашей модели становится важной? Поделимся своим видением.
В отдельных случаях критично думать об интерпретируемости уже на этапе разработки MVP. Особенно, когда нужно «продать» ваше решение конечному пользователю, или при очень высокой цене ошибки, когда без интерпретируемости моделей бизнес не готов идти даже на проведение пилота.
Но наиболее важное значение интерпретируемость имеет на этапах внедрения решения и мониторинга модельного риска. То есть, понятность модели конечным пользователям приобретает критическое значение именно тогда, когда модель доказала свою эффективность по итогам пилотного эксперимента и было принято решение о ролл-ауте (масштабировании модели на все целевые объекты).
Что именно становится важным?
- Доверие к результату. Принятие решений моделью должно быть понятно бизнесу как в целом (global interpretation), так и на отдельных примерах (local interpretation).
В случае низкого доверия к работе модели и к её логике принятия решений (модель позиционируется или воспринимается как черный ящик) сильно возрастают трудности с интеграцией модели в бизнес-процесс и обучением конечных пользователей ее использованию. Попросту говоря, моделью не хотят пользоваться, нарушают рекомендации, а если что-то идет не так, то виновата всегда модель. Особенно, если решение о ее ролл-ауте в итоге было принято сверху.
И наоборот, высокое доверие к модели способствует ее корректному применению и эффективной и быстрой интеграции в бизнес-процессы.
- Применимость модели в реальных условиях. Реальные условия, в которых работает модель, всегда так или иначе отличаются от тех, на которых она строилась. Кажется, что это уже ни для кого не секрет на фоне большого числа форс-мажорных событий последних лет.
Понятность модели конечному пользователю в продуктиве – как модель пришла к конкретному результату (данные, факторы, логика работы, итоговый прогноз/рекомендация) – снижает риск некорректного применения модели на новых данных, при сложных кейсах, в меняющейся среде. В случае аномального поведения модели человек, которому понятна модель, с большей вероятностью исправит или предотвратит неправильное решение. Митигации риска аномального поведения модели с технической стороны также очень помогают системы мониторинга модельного риска. О них мы поговорим в отдельных постах.
- Информативность для бизнес-процесса. Конечному пользователю должно быть понятно, что делать при виде результата работы модели. Именно это называют информативностью. То есть, для работы в боевых условиях чаще всего критически важно, чтобы результат работы был не просто красивыми сведениями, а содержал конкретную рекомендацию к действию (push to action).
#interpretable_ml #business
👍3👏3🔥1
Картинка к посту.
Наиболее важное значение интерпретируемость имеет на этапах внедрения решения и мониторинга модельного риска. В отдельных случаях критично думать об интерпретируемости уже на этапе разработки MVP.
#interpretable_ml #business
Наиболее важное значение интерпретируемость имеет на этапах внедрения решения и мониторинга модельного риска. В отдельных случаях критично думать об интерпретируемости уже на этапе разработки MVP.
#interpretable_ml #business
👍6🔥1
Интерпретируемость ML моделей для конечного пользователя: где нужна на практике и что делать
Что делать. Часть 1
В предыдущем посте мы разобрали, где на практике бывает нужна интерпретируемость моделей для конечного пользователя.
А теперь на каком-то примере из жизни подумаем, что можно сделать со всеми этими потребностями.
Давайте представим, что вы строите систему оптимизации ассортимента для магазинов крупной торговой сети. Результат работы вашей модели в первом приближении – это оптимальная матрица товаров для каждого магазина, или ассортиментная матрица. Конечный пользователь модели – категорийные менеджеры, управляющие жизненным циклом отдельных категорий товаров (КМ, пользователи ML-решения), и их руководство (бизнес-заказчик ML-решения).
Чаще всего, в первом приближении ваша модель машинного обучения для них – это черный ящик.
Как повысить доверие к результату?
Объяснить КМ логику работы моделей прогноза спроса, которые стоят в основе вашего решения. Наиболее популярные на практике методы global и local интерпретации моделей – это SHAP для алгоритмов на табличных данных и Grad-CAM для глубокого обучения.
Повышению доверия к модели на практике также сильно помогает возможность для конечного пользователя самому создавать локальные прогнозы спроса для отдельных товаров и видеть результат и его объяснение (возможность «потрогать инструмент руками»).
Все это хорошо, скажете вы. Но это про спрос на отдельные товары, а как объяснить КМ, почему модель в итоге предлагает именно такую комбинацию товаров для каждого магазина, а не другую? Как объяснить саму оптимизацию?
Каких-либо инструментов interpretable ml, объясняющих как модель пришла к оптимальному результату в пространстве возможных решений, пока нет. Но не все потеряно. На практике вам может помочь та же самая возможность «потрогать руками». Если дать возможность конечному пользователю вручную менять комбинации товаров для магазина на свое усмотрение и смотреть на прогноз совокупного спроса (или выигрыша относительно текущей ситуации), это значительно повышает его доверие ко всей системе в целом. Если у вас реализована и первая часть – возможность «провалиться» в прогноз и интерпретацию прогноза отдельных товаров, то это почти победа.
Как усилить применимость модели в реальных условиях?
Реализация пункта «доверие к результату» уже положительно влияет на применимость модели в реальных условиях. КМ, неуверенный в итоговых результатах работы модели сможет посмотреть отдельные прогнозы, попробовать другие варианты и принять финальное решение. Поскольку – особенно в случае моделей с длинным горизонтом принятия решения – у человека чаще всего больше контекста о бизнес-процессах, чем в данных, используемых моделью (события, связанные с политикой компании, форс-мажорными обстоятельствами, планируемые изменения инфраструктуры рядом с объектами сети и др.).
Усилить применимость модели в реальных условиях в случае модели оптимизации ассортимента может также помочь добавление доверительных интервалов прогноза для каждого товара. В таком случае у КМ будет возможность видеть уверенность модели в своем финальном решении. По сути, сетка рекомендаций будет подсвечена с точки зрения качества прогноза отдельных сегментов товаров. Тогда внимание конечного пользователя в среднем будет сконцентрировано именно на сложных кейсах.
#interpretable_ml #business
Что делать. Часть 1
В предыдущем посте мы разобрали, где на практике бывает нужна интерпретируемость моделей для конечного пользователя.
А теперь на каком-то примере из жизни подумаем, что можно сделать со всеми этими потребностями.
Давайте представим, что вы строите систему оптимизации ассортимента для магазинов крупной торговой сети. Результат работы вашей модели в первом приближении – это оптимальная матрица товаров для каждого магазина, или ассортиментная матрица. Конечный пользователь модели – категорийные менеджеры, управляющие жизненным циклом отдельных категорий товаров (КМ, пользователи ML-решения), и их руководство (бизнес-заказчик ML-решения).
Чаще всего, в первом приближении ваша модель машинного обучения для них – это черный ящик.
Как повысить доверие к результату?
Объяснить КМ логику работы моделей прогноза спроса, которые стоят в основе вашего решения. Наиболее популярные на практике методы global и local интерпретации моделей – это SHAP для алгоритмов на табличных данных и Grad-CAM для глубокого обучения.
Повышению доверия к модели на практике также сильно помогает возможность для конечного пользователя самому создавать локальные прогнозы спроса для отдельных товаров и видеть результат и его объяснение (возможность «потрогать инструмент руками»).
Все это хорошо, скажете вы. Но это про спрос на отдельные товары, а как объяснить КМ, почему модель в итоге предлагает именно такую комбинацию товаров для каждого магазина, а не другую? Как объяснить саму оптимизацию?
Каких-либо инструментов interpretable ml, объясняющих как модель пришла к оптимальному результату в пространстве возможных решений, пока нет. Но не все потеряно. На практике вам может помочь та же самая возможность «потрогать руками». Если дать возможность конечному пользователю вручную менять комбинации товаров для магазина на свое усмотрение и смотреть на прогноз совокупного спроса (или выигрыша относительно текущей ситуации), это значительно повышает его доверие ко всей системе в целом. Если у вас реализована и первая часть – возможность «провалиться» в прогноз и интерпретацию прогноза отдельных товаров, то это почти победа.
Как усилить применимость модели в реальных условиях?
Реализация пункта «доверие к результату» уже положительно влияет на применимость модели в реальных условиях. КМ, неуверенный в итоговых результатах работы модели сможет посмотреть отдельные прогнозы, попробовать другие варианты и принять финальное решение. Поскольку – особенно в случае моделей с длинным горизонтом принятия решения – у человека чаще всего больше контекста о бизнес-процессах, чем в данных, используемых моделью (события, связанные с политикой компании, форс-мажорными обстоятельствами, планируемые изменения инфраструктуры рядом с объектами сети и др.).
Усилить применимость модели в реальных условиях в случае модели оптимизации ассортимента может также помочь добавление доверительных интервалов прогноза для каждого товара. В таком случае у КМ будет возможность видеть уверенность модели в своем финальном решении. По сути, сетка рекомендаций будет подсвечена с точки зрения качества прогноза отдельных сегментов товаров. Тогда внимание конечного пользователя в среднем будет сконцентрировано именно на сложных кейсах.
#interpretable_ml #business
👍3🔥1
Интерпретируемость ML моделей для конечного пользователя: где нужна на практике и что делать
Что делать. Часть 2 (Часть 1 тут)
Как сделать результат информативным?
Если результат работы системы оптимизации ассортимента – это финальная рекомендуемая товарная матрица магазина, такой результат вряд ли можно будет назвать информативным для категорийных менеджеров сети. В таком результате нет push to action.
Рекомендацию к действию создать достаточно просто. Что нужно будет делать КМ для внедрения оптимальной ассортиментной матрицы в жизнь? Менять предшествующую матрицу. Часть товаров вывезти, часть привезти вместо них, часть ввести новых, часть оставить, как есть. Если итоговый результат работы модели рассказывает, что нужно сделать, чтобы превратить текущую товарную матрицу в оптимальную и зачем (какой будет денежный выигрыш от этого изменения), то в таком выводе ML-модели уже содержится вполне явный push to action. И ее интеграция в бизнес-процесс будет намного более быстрой.
Об основных аспектах интерпретируемости с примерами из научных статей и своей практики мы рассказывали на Data Fest 2019 г. Вот тут можно посмотреть доклад.
#interpretable_ml #business
Что делать. Часть 2 (Часть 1 тут)
Как сделать результат информативным?
Если результат работы системы оптимизации ассортимента – это финальная рекомендуемая товарная матрица магазина, такой результат вряд ли можно будет назвать информативным для категорийных менеджеров сети. В таком результате нет push to action.
Рекомендацию к действию создать достаточно просто. Что нужно будет делать КМ для внедрения оптимальной ассортиментной матрицы в жизнь? Менять предшествующую матрицу. Часть товаров вывезти, часть привезти вместо них, часть ввести новых, часть оставить, как есть. Если итоговый результат работы модели рассказывает, что нужно сделать, чтобы превратить текущую товарную матрицу в оптимальную и зачем (какой будет денежный выигрыш от этого изменения), то в таком выводе ML-модели уже содержится вполне явный push to action. И ее интеграция в бизнес-процесс будет намного более быстрой.
Об основных аспектах интерпретируемости с примерами из научных статей и своей практики мы рассказывали на Data Fest 2019 г. Вот тут можно посмотреть доклад.
#interpretable_ml #business
👍4🔥1
Выпуск подкаста "Данные Люди"
Недавно был опубликован новый выпуск подкаста "Данные люди".
Поговорили с ведущими Ваней Горбань и Артемом Глазуновым о том, что изменилось в data science с 2009 г., про роль Head of DS, взаимодействие ML Engineers и DS, и, конечно же, о causal inference и Reliable ML.
🔹Apple
🔹Castbox
🔹Google
🔹Яндекс
🔹Simplecast
#business
Недавно был опубликован новый выпуск подкаста "Данные люди".
Поговорили с ведущими Ваней Горбань и Артемом Глазуновым о том, что изменилось в data science с 2009 г., про роль Head of DS, взаимодействие ML Engineers и DS, и, конечно же, о causal inference и Reliable ML.
🔹Apple
🔹Castbox
🔹Яндекс
🔹Simplecast
#business
🔥4❤1👍1
Подборка полезных материалов по ML System Design
- Круглый стол про ML System Design секции Reliable ML 2022 г. Подойдет для знакомства с темой. Обсуждение о том, что такое ML System Design, как его структурировать и применять. Для знакомства с темой также хорошо подойдет вот эта статья и вот эта.
- Конспекты лекций Стенфорда – курс CS 329S: Machine Learning Systems Design. Самые лучшие материалы для основательного изучения дисциплины. Структурированный разбор материалов: от паттернов ресерча до деплоя моделей. Для каждой темы есть текстовые записи лекций, слайды, ссылки на полезные материалы.
- Небольшая, хорошо структурированная и, что важно, краткая электронная книга в открытом доступе от одного из преподавателей Стенфордского курса Chip Huyen - ML Systems Design (собрана из статей автора в блоге). Если хочется для начала получить представление о книге и вообще о месте ML System Design в мире DS/ML можно сначала посмотреть это видео от Chip Huyen. Кроме того, в 2022 г. Chip Huyen опубликовала книгу Designing Machine Learning Systems как расширенную и дополненную версию статей своего блога.
Chip Huyen - один из авторов, внесших наибольший вклад в развитие ML System Design как дисциплины, как можно увидеть по подборке материалов. Кроме того, она является одним из самых популярных въетнамских художественных писаталей в жанре creative non-fiction. Списки книг можно увидеть на ее персональном сайте.
- Книга Machine Learning Design Patterns. Отличные обзоры книги есть у: тг-канала Варим МЛ и на towards data science. Книга хорошо подойдет для начинающих дата саентистов и МЛ-инженеров, кто хочет структурировать информацию о паттернах дизайна систем машинного обучения.
- Grokking the Machine Learning Interview. Уроки по ML System Design на стандартных примерах: Search Ranking, Feed Based System, Recommendation System, Self-Driving Car, Entity Linking System, Ad Prediction System. Платно. Есть акцент на system design вопросах (про system design дальше сделаем отдельную подборку).
- Серия видео от Валеры Бабушкина по ML System Design собеседованиям. В них подробно разбираются дизайны МЛ-систем для: ранжирования рекламы в новостной ленте соцсети, ценообразования и матчинга в маркетплейсе.
- Miro-доска от Богдана Печёнкина (X5, AliExpress, KazanExpress) с примерами ML дизайна различных систем: динамическое ценообразование, матчинг, антифрод, рекомендашки, ранжирование рекламы. Доска постоянно дорабатывается и пополняется. Рекомендуем также видео, где Богдан рассказывает про дизайн ML ценообразования на маркетплейсе.
Материалы, которых все очень ждут:
- Материалы курса Дмитрия Колодезева по ML System Design (2022)
- Книга от Валерия Бабушкина и Арсения Кравченко Principles of ML Design (2023)
Как выйдут – обязательно опубликуем ссылки!
#tech #ml_system_design
- Круглый стол про ML System Design секции Reliable ML 2022 г. Подойдет для знакомства с темой. Обсуждение о том, что такое ML System Design, как его структурировать и применять. Для знакомства с темой также хорошо подойдет вот эта статья и вот эта.
- Конспекты лекций Стенфорда – курс CS 329S: Machine Learning Systems Design. Самые лучшие материалы для основательного изучения дисциплины. Структурированный разбор материалов: от паттернов ресерча до деплоя моделей. Для каждой темы есть текстовые записи лекций, слайды, ссылки на полезные материалы.
- Небольшая, хорошо структурированная и, что важно, краткая электронная книга в открытом доступе от одного из преподавателей Стенфордского курса Chip Huyen - ML Systems Design (собрана из статей автора в блоге). Если хочется для начала получить представление о книге и вообще о месте ML System Design в мире DS/ML можно сначала посмотреть это видео от Chip Huyen. Кроме того, в 2022 г. Chip Huyen опубликовала книгу Designing Machine Learning Systems как расширенную и дополненную версию статей своего блога.
Chip Huyen - один из авторов, внесших наибольший вклад в развитие ML System Design как дисциплины, как можно увидеть по подборке материалов. Кроме того, она является одним из самых популярных въетнамских художественных писаталей в жанре creative non-fiction. Списки книг можно увидеть на ее персональном сайте.
- Книга Machine Learning Design Patterns. Отличные обзоры книги есть у: тг-канала Варим МЛ и на towards data science. Книга хорошо подойдет для начинающих дата саентистов и МЛ-инженеров, кто хочет структурировать информацию о паттернах дизайна систем машинного обучения.
- Grokking the Machine Learning Interview. Уроки по ML System Design на стандартных примерах: Search Ranking, Feed Based System, Recommendation System, Self-Driving Car, Entity Linking System, Ad Prediction System. Платно. Есть акцент на system design вопросах (про system design дальше сделаем отдельную подборку).
- Серия видео от Валеры Бабушкина по ML System Design собеседованиям. В них подробно разбираются дизайны МЛ-систем для: ранжирования рекламы в новостной ленте соцсети, ценообразования и матчинга в маркетплейсе.
- Miro-доска от Богдана Печёнкина (X5, AliExpress, KazanExpress) с примерами ML дизайна различных систем: динамическое ценообразование, матчинг, антифрод, рекомендашки, ранжирование рекламы. Доска постоянно дорабатывается и пополняется. Рекомендуем также видео, где Богдан рассказывает про дизайн ML ценообразования на маркетплейсе.
Материалы, которых все очень ждут:
- Материалы курса Дмитрия Колодезева по ML System Design (2022)
- Книга от Валерия Бабушкина и Арсения Кравченко Principles of ML Design (2023)
Как выйдут – обязательно опубликуем ссылки!
#tech #ml_system_design
🔥33👍8❤1
Подборка полезных материалов по ML Engineering & ML Ops
- Обзорная статья про то, что вообще такое ML Ops “Machine Learning Operations (MLOps): Overview, Definition, and Architecture”. Статья хорошо структурирована, содержит много красивых схем про разные роли, их ответственность и взаимодействие в рамках работы над ML проектом: Business, DS, DE, IT Solution Architect, SWE, DevOps, ML Engineer. Но, как правильно заметил Арсений Кравченко в своем тг-канале, такая строгая бюрократизация ролей и процесса может подойти не каждой компании. Многое зависит от уровня зрелости компании, масштаба и количества решаемых задач.
- Обзорные статьи от bigdataschool про основные шаги внедрения ML Ops и оценку уровня зрелости ML Engineering & ML Ops в вашей компании: разбор методики от Google и от GigaOm. Вообще, на ресурсе много кратких обзорных статей по ML Ops и Data Engineering: как по отдельным инструментам, так и в целом. Если хочется получить общее представление по отдельным темам, рекомендуем. Подробное описание уровней зрелости от Google можно почитать вот тут.
- Открытый курс ODS “MLOps и production подход к ML исследованиям”. Курс был высоко оценен в сообществе Open Data Science. По итогам его прохождения Юрий Кашницкий опубликовал статью на Хабр с подробным рассказом про опыт создания своего проекта в рамках курса.
- Открытый курс от DataTalks.Club: MLOps ZoomCamp. На курсе детально рассказывается про весь цикл работы MLOps: есть записи лекций, домашние задания и открытый лидерборд.
- Курс от Weights & Biases (wandb.ai): “Effective MLOps: Model Development”. Хороший бесплатный обзорный курс, где рассказывают про основные инструменты и, конечно, не забывают порекламировать проприетарные продукты Weights & Biases.
- Серия видео-семинаров Стенфорда по System Design в ML. Нам показалось, что в материалах акцент больше дается на ML Engineering & ML Ops, поэтому классифицировали ссылку в эту подборку.
- Наикрутейший инструмент - конструктор ML Ops стека на базе open-source инструментов. Позволяет посмотреть плюсы и минусы и итеративно выбрать любой из имеющихся в open-source инструментов для всех ключевых шагов MLOps (Experiment Tracking, Experimentation, Data Versioning, Code versioning, Pipeline orchestration, Runtime Engine, Artifact Tracking, Model Registry, Model Serving, Model Monitoring). Далее, получаем красивую схему архитектуры вашего MLOps стека и рекомендации по его установке.
Если считаете, что подборку стоит чем-то дополнить, welcome в комментарии!
#tech #ml_engineering #ml_ops
- Обзорная статья про то, что вообще такое ML Ops “Machine Learning Operations (MLOps): Overview, Definition, and Architecture”. Статья хорошо структурирована, содержит много красивых схем про разные роли, их ответственность и взаимодействие в рамках работы над ML проектом: Business, DS, DE, IT Solution Architect, SWE, DevOps, ML Engineer. Но, как правильно заметил Арсений Кравченко в своем тг-канале, такая строгая бюрократизация ролей и процесса может подойти не каждой компании. Многое зависит от уровня зрелости компании, масштаба и количества решаемых задач.
- Обзорные статьи от bigdataschool про основные шаги внедрения ML Ops и оценку уровня зрелости ML Engineering & ML Ops в вашей компании: разбор методики от Google и от GigaOm. Вообще, на ресурсе много кратких обзорных статей по ML Ops и Data Engineering: как по отдельным инструментам, так и в целом. Если хочется получить общее представление по отдельным темам, рекомендуем. Подробное описание уровней зрелости от Google можно почитать вот тут.
- Открытый курс ODS “MLOps и production подход к ML исследованиям”. Курс был высоко оценен в сообществе Open Data Science. По итогам его прохождения Юрий Кашницкий опубликовал статью на Хабр с подробным рассказом про опыт создания своего проекта в рамках курса.
- Открытый курс от DataTalks.Club: MLOps ZoomCamp. На курсе детально рассказывается про весь цикл работы MLOps: есть записи лекций, домашние задания и открытый лидерборд.
- Курс от Weights & Biases (wandb.ai): “Effective MLOps: Model Development”. Хороший бесплатный обзорный курс, где рассказывают про основные инструменты и, конечно, не забывают порекламировать проприетарные продукты Weights & Biases.
- Серия видео-семинаров Стенфорда по System Design в ML. Нам показалось, что в материалах акцент больше дается на ML Engineering & ML Ops, поэтому классифицировали ссылку в эту подборку.
- Наикрутейший инструмент - конструктор ML Ops стека на базе open-source инструментов. Позволяет посмотреть плюсы и минусы и итеративно выбрать любой из имеющихся в open-source инструментов для всех ключевых шагов MLOps (Experiment Tracking, Experimentation, Data Versioning, Code versioning, Pipeline orchestration, Runtime Engine, Artifact Tracking, Model Registry, Model Serving, Model Monitoring). Далее, получаем красивую схему архитектуры вашего MLOps стека и рекомендации по его установке.
Если считаете, что подборку стоит чем-то дополнить, welcome в комментарии!
#tech #ml_engineering #ml_ops
🔥27👍11❤5
Анонс AI Quality Workshop
Открытый бесплатный курс по оценке качества и надежности моделей
Компания Truera запустила серию бесплатных открытых курсов AI Quality Workshop. Ближайшая сессия стартует 25 августа, зарегистрироваться можно тут.
Курс предполагает 4 live-сессии. Одна из целей курса, конечно же, реклама проприетарных продуктов Truera. Но, кажется, что при этом состав преподавателей вполне неплох (MIT, Carnegie Mellon University, Georgia Institute of Technology, University of Maryland) и темы, которые планируются к рассказу, тоже очень достойны для расширения кругозора: ML Explainability, Accuracy and Performance Debugging, Model Drift Fairness, NLP Model Quality.
#tech
Открытый бесплатный курс по оценке качества и надежности моделей
Компания Truera запустила серию бесплатных открытых курсов AI Quality Workshop. Ближайшая сессия стартует 25 августа, зарегистрироваться можно тут.
Курс предполагает 4 live-сессии. Одна из целей курса, конечно же, реклама проприетарных продуктов Truera. Но, кажется, что при этом состав преподавателей вполне неплох (MIT, Carnegie Mellon University, Georgia Institute of Technology, University of Maryland) и темы, которые планируются к рассказу, тоже очень достойны для расширения кругозора: ML Explainability, Accuracy and Performance Debugging, Model Drift Fairness, NLP Model Quality.
#tech
👍6🔥4🤩1
АБ-тесты - это не только ценный мех… Но еще и процессы.
Цикл постов про АБ-тестирование. Пост 1.
О математических нюансах АБ-тестирования есть много замечательной литературы, подборку которой мы дадим в конце этой серии постов.
Но почти нигде нет информации о том, каким образом в компаниях выстраивать сам процесс применения АБ-тестирования. За исключением отдельных отраслей (игры, интернет-коммерция), где уже сформировались зрелые практики.
При этом для офлайн-бизнеса внедрение АБ-тестирования во многом организационная, а не математическая проблема.
На первый взгляд, кажется, что достаточно отработать методику АБ-тестирования на уровне объектов тестирования (например, точек продаж для офлайн ритейла). Но на практике правильно выстроить бизнес-процесс применения АБ и позиционирования его внутри компании едва ли не сложнее, чем создать правильную статистическую методологию.
С точки зрения бизнес-процессов компании АБ-тестирование - часть инвестиционного цикла проектов и продуктов, за который отвечает финансовое подразделение. Внутри инвестиционного цикла АБ-тестирование – это один из способов дизайна и оценки пилотных экспериментов компании для того, чтобы принять решение о дальнейших инвестициях в проект.
Обобщенно инвестиционный цикл можно разбить на этапы:
- Заявка на проект. Процедура отбора проектов, в которые компания готова инвестировать. Здесь АБ-тестирование может участвовать, дополняя критерии отбора проектов возможностью проведения статистически корректного АБ-теста.
На практике это, к сожалению, происходит редко, что приводит к значительным денежным потерям. Проект запустили, а вывод о том, эффективен ли он, сделать невозможно.
- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.
- Разработка MVP. Разрабатывается прототип решения.
- Пилот. После разработки MVP нужно как можно дешевле (на минимальном числе объектов) оценить финансовый эффект проекта, чтобы принять решение о продолжении или прекращении инвестиций в проект.
Чтобы понять, окупятся ли дальнейшие инвестиции в проект, нам нужно быть уверенными, что мы получили достоверную оценку финансового эффекта.
Как тут помогает АБ тестирование: математически корректная методика дизайна и оценки результатов экспериментов дает возможность сделать правильные выводы о ценности разработанного MVP.
- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.
- Ролл-аут. Осуществляется внедрение проекта на все целевые объекты в масштабе компании.
- Пост-инвест анализ. Чтобы отслеживать эффективность инвестиционной деятельности, компании нужно оценить итоговый финансовый эффект ролл-аута. Какие статистические инструменты доступны?
Прежде всего - контрфактические методы причинно-следственного анализа. Мы писали о них в начале года (тут, тут и тут).
Важно помнить, что АБ-тестирование – лишь часть (пусть и очень важная) методов причинно-следственного анализа. АБ-тесты - только один из способов дизайна и оценки пилотных экспериментов. Они хорошо работают в типовых случаях, а для сложных случаев помогут контрфактические методы. При использовании контрфактических методов критически важно обеспечить робастность применения моделей.
Эту структуру полезно иметь в виду при интеграции АБ-тестирования в бизнес-процессы компании.
В следующих постах цикла речь пойдет о детальном бизнес-процессе дизайна и оценки пилота, а также о том, какие этапы в нем закрывает математическая методика АБ-тестирования, а какие этапы нужно дополнительно продумать и упорядочить при ее внедрении.
#business #ab_testing
Цикл постов про АБ-тестирование. Пост 1.
О математических нюансах АБ-тестирования есть много замечательной литературы, подборку которой мы дадим в конце этой серии постов.
Но почти нигде нет информации о том, каким образом в компаниях выстраивать сам процесс применения АБ-тестирования. За исключением отдельных отраслей (игры, интернет-коммерция), где уже сформировались зрелые практики.
При этом для офлайн-бизнеса внедрение АБ-тестирования во многом организационная, а не математическая проблема.
На первый взгляд, кажется, что достаточно отработать методику АБ-тестирования на уровне объектов тестирования (например, точек продаж для офлайн ритейла). Но на практике правильно выстроить бизнес-процесс применения АБ и позиционирования его внутри компании едва ли не сложнее, чем создать правильную статистическую методологию.
С точки зрения бизнес-процессов компании АБ-тестирование - часть инвестиционного цикла проектов и продуктов, за который отвечает финансовое подразделение. Внутри инвестиционного цикла АБ-тестирование – это один из способов дизайна и оценки пилотных экспериментов компании для того, чтобы принять решение о дальнейших инвестициях в проект.
Обобщенно инвестиционный цикл можно разбить на этапы:
- Заявка на проект. Процедура отбора проектов, в которые компания готова инвестировать. Здесь АБ-тестирование может участвовать, дополняя критерии отбора проектов возможностью проведения статистически корректного АБ-теста.
На практике это, к сожалению, происходит редко, что приводит к значительным денежным потерям. Проект запустили, а вывод о том, эффективен ли он, сделать невозможно.
- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.
- Разработка MVP. Разрабатывается прототип решения.
- Пилот. После разработки MVP нужно как можно дешевле (на минимальном числе объектов) оценить финансовый эффект проекта, чтобы принять решение о продолжении или прекращении инвестиций в проект.
Чтобы понять, окупятся ли дальнейшие инвестиции в проект, нам нужно быть уверенными, что мы получили достоверную оценку финансового эффекта.
Как тут помогает АБ тестирование: математически корректная методика дизайна и оценки результатов экспериментов дает возможность сделать правильные выводы о ценности разработанного MVP.
- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.
- Ролл-аут. Осуществляется внедрение проекта на все целевые объекты в масштабе компании.
- Пост-инвест анализ. Чтобы отслеживать эффективность инвестиционной деятельности, компании нужно оценить итоговый финансовый эффект ролл-аута. Какие статистические инструменты доступны?
Прежде всего - контрфактические методы причинно-следственного анализа. Мы писали о них в начале года (тут, тут и тут).
Важно помнить, что АБ-тестирование – лишь часть (пусть и очень важная) методов причинно-следственного анализа. АБ-тесты - только один из способов дизайна и оценки пилотных экспериментов. Они хорошо работают в типовых случаях, а для сложных случаев помогут контрфактические методы. При использовании контрфактических методов критически важно обеспечить робастность применения моделей.
Эту структуру полезно иметь в виду при интеграции АБ-тестирования в бизнес-процессы компании.
В следующих постах цикла речь пойдет о детальном бизнес-процессе дизайна и оценки пилота, а также о том, какие этапы в нем закрывает математическая методика АБ-тестирования, а какие этапы нужно дополнительно продумать и упорядочить при ее внедрении.
#business #ab_testing
🔥20❤3👍3
О Hard ML и karpov.courses
Наши подборки материалов по ML System Design и ML Engineering & ML Ops были бы неполными без курсов от Анатолия Карпова.
Многие из вас, вероятно, начинали свой путь с его бесплатных курсов на Stepik по статистике и введению в data science. А если не начинали, то мы очень их рекомендуем.
Кроме того, уважаем и рекомендуем также и платные курсы от karpov.courses, в особенности, Hard ML и System Design.
По Hard ML скоро стартует новый поток. До 5 сентября по промокоду RELIABLEML можно получить скидку 10%. Есть бесплатное демо.
По ML Engineering & ML Ops: в рамках курса есть отдельный модуль про деплой ML-сервисов. В сам курс включена тема создания feature stores.
По ML System Design: разбираются дизайны систем для задач матчинга и ранжирования, ценообразования, аплифт-моделирования. Отдельно объясняются темы АБ-тестирования и выбора корректных метрик при построении ML-систем.
Одним из авторов курса является Валера Бабушкин. А Валера, как мы знаем, плохого не делает.
#tech
Наши подборки материалов по ML System Design и ML Engineering & ML Ops были бы неполными без курсов от Анатолия Карпова.
Многие из вас, вероятно, начинали свой путь с его бесплатных курсов на Stepik по статистике и введению в data science. А если не начинали, то мы очень их рекомендуем.
Кроме того, уважаем и рекомендуем также и платные курсы от karpov.courses, в особенности, Hard ML и System Design.
По Hard ML скоро стартует новый поток. До 5 сентября по промокоду RELIABLEML можно получить скидку 10%. Есть бесплатное демо.
По ML Engineering & ML Ops: в рамках курса есть отдельный модуль про деплой ML-сервисов. В сам курс включена тема создания feature stores.
По ML System Design: разбираются дизайны систем для задач матчинга и ранжирования, ценообразования, аплифт-моделирования. Отдельно объясняются темы АБ-тестирования и выбора корректных метрик при построении ML-систем.
Одним из авторов курса является Валера Бабушкин. А Валера, как мы знаем, плохого не делает.
#tech
👍30🔥1🤯1
Митап NoML по Causal Inference
На следующей неделе - 7 сентября - сообщество NoML ждет всех на очный митап по Causal Inference.
Программа кажется довольно огненной!
И меня тоже пригласили поучаствовать.
А места при этом ограничены. Так что, если интересно, не откладывайте с регистрацией! Трансляции не будет, только запись.
Темы и спикеры:
📌 Введение в методы Causal Inference
😎 Полина Окунева, 😎 Наталья Тоганова, Эксперты команды Advanced Analytics в GlowByte
📌 Кейс применения Synthetic Control для оценки инициатив
😎 Артем Александрин, Дата аналитик мобильного приложения “Моя Москва”
📌 Дискуссия: “за”, “против”, а также сложности и причины сомнений в Causal Inference
Упомянутые выше докладчики, а также:
😎 Ирина Голощапова, Head of Data Science, Лента
😎 Александр Толмачев, Head of Analytics Ozon.Fintech
😎 Антон Григорьев, Руководитель службы аналитических инструментов Яндекс Доставки
Сбор гостей в 17:30.
В конце будет фуршет. 🥂
Вроде мелочь, а когда-то в студенческие годы для меня это было чуть ли не основным критерием выбора конференций 🙂
На следующей неделе - 7 сентября - сообщество NoML ждет всех на очный митап по Causal Inference.
Программа кажется довольно огненной!
И меня тоже пригласили поучаствовать.
А места при этом ограничены. Так что, если интересно, не откладывайте с регистрацией! Трансляции не будет, только запись.
Темы и спикеры:
📌 Введение в методы Causal Inference
😎 Полина Окунева, 😎 Наталья Тоганова, Эксперты команды Advanced Analytics в GlowByte
📌 Кейс применения Synthetic Control для оценки инициатив
😎 Артем Александрин, Дата аналитик мобильного приложения “Моя Москва”
📌 Дискуссия: “за”, “против”, а также сложности и причины сомнений в Causal Inference
Упомянутые выше докладчики, а также:
😎 Ирина Голощапова, Head of Data Science, Лента
😎 Александр Толмачев, Head of Analytics Ozon.Fintech
😎 Антон Григорьев, Руководитель службы аналитических инструментов Яндекс Доставки
Сбор гостей в 17:30.
В конце будет фуршет. 🥂
Вроде мелочь, а когда-то в студенческие годы для меня это было чуть ли не основным критерием выбора конференций 🙂
👍13😁2❤1
АБ-тесты. Интеграция в процесс пилотирования. Как выглядит типовой бизнес-процесс без АБ.
Цикл постов про АБ-тестирование. Пост 2.
В предыдущем посте цикла мы верхнеуровнево разобрали инвестиционный цикл проектов в офлайн-бизнесе и кратко поговорили о том, в какие его этапы и каким образом встраивается математическая методика АБ-тестирования.
В частности, мы определились, что наиболее важный этап инвестиционного цикла для АБ-тестирования - это этап пилотирования для понимания финансового эффекта от MVP какого-либо проекта.
Теперь предлагаем сделать zoom в этот этап и разобрать его детально, поняв, как именно в него может быть встроена методика АБ-тестирования, и что нужно предусмотреть в рамках интеграции.
Итак, бизнес-процесс пилота - еще до всяких АБ-тестирований - как правило, выглядит так:
- Определение целей, задач, KPI пилота. Бизнес-подразделение, ответственное за проект, формирует свои ожидания к проведению пилота и его ключевым параметрам. Если в компании нет единой методики оценки пилотов, то эти ожидания формируются несистемно, часто больше из соображений наименьших затрат на проведение пилота.
- Согласование ожиданий бизнеса по пилоту с финансовой службой. Все ожидания должны пройти контроль подразделения, отвечающего за инвестиционный цикл подобных проектов в финансовой службе.
- Определение географии пилота и выбор объектов для тестирования (пилотная группа, внедряем MVP) и сравнения (контрольная группа, ничего не внедряем). Как правило, выбирается экспертно, из соображений удобного и наименее затратного проведения пилота. Для небольших проектов может использоваться 1 выделенный для пилотов объект.
- Согласование запуска пилота с операционной службой. Изменения в пилотной группе объектов должны быть согласованы с операционным подразделением. Коллегам непосредственно на местах необходимо будет обеспечить исполнение пилота.
- Проведение пилота. Реализация MVP на местах в пилотной группе при отсутствии изменений в контрольной группе. Если эти понятия, конечно, выделяются при отсутствии АБ-тестирования. Надо сказать, что чаще всего, выделяются.
- Оценка результатов пилота. При отсутствии АБ, чаще всего применяется простая разность результатов пилотной группы с контрольной по целевой метрике (продажи, количество клиентов, маржа, и т.п.). Используются как темпы роста, так и абсолютные значения. Почему подобное ручное сравнение это плохо и что должно улучшить АБ (и как объяснить это бизнесу!), мы поговорим в дальнейших постах цикла. Сейчас для нас важно то, что без применения статистики (aka внедрения АБ) компания берет на себя огромный риск финансовых потерь за счет некорректных оценок пилотных экспериментов. Фактически, идет по инвестиционному циклу вслепую.
- Решение о дальнейшем развитии проекта. Здесь, что очень важно, происходит экстраполяция результатов пилота на всю сеть - расчет потенциального финансового эффекта для того, чтобы понять, стоит ли проект дальнейших инвестиций в его внедрение для всех объектов компании (ролл-аут).
В следующем посте рассмотрим риски, с которыми связан этот бизнес-процесс. И почему они формируются.
#business #ab_testing
Цикл постов про АБ-тестирование. Пост 2.
В предыдущем посте цикла мы верхнеуровнево разобрали инвестиционный цикл проектов в офлайн-бизнесе и кратко поговорили о том, в какие его этапы и каким образом встраивается математическая методика АБ-тестирования.
В частности, мы определились, что наиболее важный этап инвестиционного цикла для АБ-тестирования - это этап пилотирования для понимания финансового эффекта от MVP какого-либо проекта.
Теперь предлагаем сделать zoom в этот этап и разобрать его детально, поняв, как именно в него может быть встроена методика АБ-тестирования, и что нужно предусмотреть в рамках интеграции.
Итак, бизнес-процесс пилота - еще до всяких АБ-тестирований - как правило, выглядит так:
- Определение целей, задач, KPI пилота. Бизнес-подразделение, ответственное за проект, формирует свои ожидания к проведению пилота и его ключевым параметрам. Если в компании нет единой методики оценки пилотов, то эти ожидания формируются несистемно, часто больше из соображений наименьших затрат на проведение пилота.
- Согласование ожиданий бизнеса по пилоту с финансовой службой. Все ожидания должны пройти контроль подразделения, отвечающего за инвестиционный цикл подобных проектов в финансовой службе.
- Определение географии пилота и выбор объектов для тестирования (пилотная группа, внедряем MVP) и сравнения (контрольная группа, ничего не внедряем). Как правило, выбирается экспертно, из соображений удобного и наименее затратного проведения пилота. Для небольших проектов может использоваться 1 выделенный для пилотов объект.
- Согласование запуска пилота с операционной службой. Изменения в пилотной группе объектов должны быть согласованы с операционным подразделением. Коллегам непосредственно на местах необходимо будет обеспечить исполнение пилота.
- Проведение пилота. Реализация MVP на местах в пилотной группе при отсутствии изменений в контрольной группе. Если эти понятия, конечно, выделяются при отсутствии АБ-тестирования. Надо сказать, что чаще всего, выделяются.
- Оценка результатов пилота. При отсутствии АБ, чаще всего применяется простая разность результатов пилотной группы с контрольной по целевой метрике (продажи, количество клиентов, маржа, и т.п.). Используются как темпы роста, так и абсолютные значения. Почему подобное ручное сравнение это плохо и что должно улучшить АБ (и как объяснить это бизнесу!), мы поговорим в дальнейших постах цикла. Сейчас для нас важно то, что без применения статистики (aka внедрения АБ) компания берет на себя огромный риск финансовых потерь за счет некорректных оценок пилотных экспериментов. Фактически, идет по инвестиционному циклу вслепую.
- Решение о дальнейшем развитии проекта. Здесь, что очень важно, происходит экстраполяция результатов пилота на всю сеть - расчет потенциального финансового эффекта для того, чтобы понять, стоит ли проект дальнейших инвестиций в его внедрение для всех объектов компании (ролл-аут).
В следующем посте рассмотрим риски, с которыми связан этот бизнес-процесс. И почему они формируются.
#business #ab_testing
❤7👍4
АБ-тесты. Интеграция в процесс пилотирования. Риски типового бизнес-процесса без АБ
Цикл постов про АБ-тестирование. Пост 3
Бизнес-процесс, описанный в предшествующем посте цикла, связан со значительными рисками для компании:
- Риск некорректного финального решения о дальнейшем развитии проекта. Наиболее значимый риск среди всех. Как мы написали выше, компания идет по инвестиционному циклу вслепую. И очень важно понимать, что это связано не только с отсутствием АБ-тестирования в шаге оценки результатов пилотов. Даже если у вас стройная и правильная математика при оценке результата пилота, риски остаются и в других шагах:
- Нет фиксации ограниченного круга целевых метрик и KPI пилота. Это может приводить к тому, что при отсутствии эффекта на основные метрики, заинтересованная сторона будет искать эффект в других метриках, пока не найдет и постфактум сможет объявить о том, что пилот успешен, но на других метриках. Научно это называется проблемой множественного тестирования и отлично иллюстрируется известной историей про мертвого лосося.
- Нет единой базы пилотов. При проведении пилотов далеко не всегда контролируется отсутствие изменений в контрольной группе объектов. А если эксперименты проводятся в 1м объекте, выделенном для тестов, нередка ситуация, когда в одно время может проходить и два, и три, и пять пилотов. Результаты проведения каждого из них по отдельности, как нетрудно догадаться, в такой ситуации, оценить будет невозможно.
- Нет единой методики/правил экстраполяции результатов пилота для расчета финансового эффекта на все объекты. Даже при суперкорректной статистической оценке результатов пилота на основе АБ, финальное решение об инвестициях в проект может оказаться некорректным, если нет правил его масштабирования на всю сеть. Получили +1% к выручке на 5 объектах. Можем ли сказать, что при ролл-ауте проекта, для всей сети будет +1% к выручке? Была ли выборка репрезентативна для всей сети? Можем ли назвать результаты пилота робастными? Например, 5 объектов пилота могли быть расположены в Сибири, а основные объекты компании расположены в Центральных регионах.
- Риск задержек в проведении пилотов. Как мы увидели в предшествующем посте, в бизнес-процессе проведения пилота много шагов, в него вовлечено много сторон/согласующих. Это может приводить к значительному замедлению в продвижении компании по инвестиционному циклу, а значит, в перспективе - к отставанию от конкурентов во внедрении новых решений.
В следующем посте цикла мы поговорим о том “А что делать-то?”. Как подумать о рассмотренных рисках при интеграции АБ-тестирования, а также учесть особенности бизнес-процесса.
#business #ab_testing
Цикл постов про АБ-тестирование. Пост 3
Бизнес-процесс, описанный в предшествующем посте цикла, связан со значительными рисками для компании:
- Риск некорректного финального решения о дальнейшем развитии проекта. Наиболее значимый риск среди всех. Как мы написали выше, компания идет по инвестиционному циклу вслепую. И очень важно понимать, что это связано не только с отсутствием АБ-тестирования в шаге оценки результатов пилотов. Даже если у вас стройная и правильная математика при оценке результата пилота, риски остаются и в других шагах:
- Нет фиксации ограниченного круга целевых метрик и KPI пилота. Это может приводить к тому, что при отсутствии эффекта на основные метрики, заинтересованная сторона будет искать эффект в других метриках, пока не найдет и постфактум сможет объявить о том, что пилот успешен, но на других метриках. Научно это называется проблемой множественного тестирования и отлично иллюстрируется известной историей про мертвого лосося.
- Нет единой базы пилотов. При проведении пилотов далеко не всегда контролируется отсутствие изменений в контрольной группе объектов. А если эксперименты проводятся в 1м объекте, выделенном для тестов, нередка ситуация, когда в одно время может проходить и два, и три, и пять пилотов. Результаты проведения каждого из них по отдельности, как нетрудно догадаться, в такой ситуации, оценить будет невозможно.
- Нет единой методики/правил экстраполяции результатов пилота для расчета финансового эффекта на все объекты. Даже при суперкорректной статистической оценке результатов пилота на основе АБ, финальное решение об инвестициях в проект может оказаться некорректным, если нет правил его масштабирования на всю сеть. Получили +1% к выручке на 5 объектах. Можем ли сказать, что при ролл-ауте проекта, для всей сети будет +1% к выручке? Была ли выборка репрезентативна для всей сети? Можем ли назвать результаты пилота робастными? Например, 5 объектов пилота могли быть расположены в Сибири, а основные объекты компании расположены в Центральных регионах.
- Риск задержек в проведении пилотов. Как мы увидели в предшествующем посте, в бизнес-процессе проведения пилота много шагов, в него вовлечено много сторон/согласующих. Это может приводить к значительному замедлению в продвижении компании по инвестиционному циклу, а значит, в перспективе - к отставанию от конкурентов во внедрении новых решений.
В следующем посте цикла мы поговорим о том “А что делать-то?”. Как подумать о рассмотренных рисках при интеграции АБ-тестирования, а также учесть особенности бизнес-процесса.
#business #ab_testing
👍5🥰2❤1
image_2022-09-15_14-13-20.png
208 KB
Подытожим в одной картинке выводы последних двух постов цикла про АБ-тестирование: о бизнес-процессе пилотирования и его рисках.
P.S. Хочется выразить большую благодарность моим замечательным коллегам Анастасии Комович и Эдуарду Григоряну, которые вместе со мной в разное время долгие часы формировали концепцию внедрения АБ-тестирования в бизнес-процессы компаний. Без них понимания бизнес-процессов и того, что со всем этим делать, не состоялось бы.
#business #ab_testing
P.S. Хочется выразить большую благодарность моим замечательным коллегам Анастасии Комович и Эдуарду Григоряну, которые вместе со мной в разное время долгие часы формировали концепцию внедрения АБ-тестирования в бизнес-процессы компаний. Без них понимания бизнес-процессов и того, что со всем этим делать, не состоялось бы.
#business #ab_testing
👍7❤1
ML System Design ODS Course
Уже сегодня - 19 сентября - открывается курс по ML System Design для начинающих. Автор курса - Дмитрий Колодезев, директор Promsoft.
Первая лекция скоро будет доступна на странице курса! Группа для участников в тг тут.
Что входит в курс:
- ML-системы в реальной жизни с точки зрения софта, железа и бизнеса.
- Итеративный процесс построения ML-систем
Что не рассматривается:
- Алгоритмы машинного обучения
- Дата-инженерия
- Дизайн пользовательского интерфейса
- Как работать с докером и k8s
Курс состоит из видео, статей, докладов студентов, работы над проектом.
Уже сегодня - 19 сентября - открывается курс по ML System Design для начинающих. Автор курса - Дмитрий Колодезев, директор Promsoft.
Первая лекция скоро будет доступна на странице курса! Группа для участников в тг тут.
Что входит в курс:
- ML-системы в реальной жизни с точки зрения софта, железа и бизнеса.
- Итеративный процесс построения ML-систем
Что не рассматривается:
- Алгоритмы машинного обучения
- Дата-инженерия
- Дизайн пользовательского интерфейса
- Как работать с докером и k8s
Курс состоит из видео, статей, докладов студентов, работы над проектом.
🔥20👍5⚡2
День Открытых Дверей Mathshub - 4 октября 2022 г.
С наступлением осени снова появляются хорошие DS мероприятия. Хотим рассказать вам об одном из них.
Уже в ближайший вторник, 4 октября, состоится День Открытых Дверей Mathshub. Будет полезно всем интересующимся темой ML System Design.
В программе:
- Рассказ о том, как создать ML-проект с нуля (от выбора идеи до релиза), как найти большой рынок для своей идеи и не умереть в конкуренции с крупными компаниями. Спикер - замечательная Айра Монгуш [ex-Mail.Ru, ex-aitarget.com], основательница Mathshub, которая многим может быть уже хорошо знакома как преподаватель в МФТИ/ВШЭ.
- Краткая презентация осенней программы по созданию ML-проектов. 👩🎓 Среди преподавателей — Давид Дале из AI Research, Игорь Слинько, ex-Samsung AI Research и другие ребята с обширной практикой в диплернинге и обучении.
Регистрация на мероприятие тут.
#tech
С наступлением осени снова появляются хорошие DS мероприятия. Хотим рассказать вам об одном из них.
Уже в ближайший вторник, 4 октября, состоится День Открытых Дверей Mathshub. Будет полезно всем интересующимся темой ML System Design.
В программе:
- Рассказ о том, как создать ML-проект с нуля (от выбора идеи до релиза), как найти большой рынок для своей идеи и не умереть в конкуренции с крупными компаниями. Спикер - замечательная Айра Монгуш [ex-Mail.Ru, ex-aitarget.com], основательница Mathshub, которая многим может быть уже хорошо знакома как преподаватель в МФТИ/ВШЭ.
- Краткая презентация осенней программы по созданию ML-проектов. 👩🎓 Среди преподавателей — Давид Дале из AI Research, Игорь Слинько, ex-Samsung AI Research и другие ребята с обширной практикой в диплернинге и обучении.
Регистрация на мероприятие тут.
#tech
👍8
АБ-тесты. Интеграция в процесс пилотирования. Что делать.
Цикл постов про АБ-тестирование. Пост 4.
Теперь, когда мы разобрали бизнес-процессы и ключевые риски инвестиционного цикла и отдельно пилотирования, можно поговорить о том, как предусмотреть митигацию этих рисков при интеграции АБ-тестов в деятельность компании.
Первое, что мы рассмотрим, это создание процесса взаимодействия бизнеса с командой АБ-тестирования. Наличие у вас классной методики АБ - это круто, но этого недостаточно для того, чтобы нивелировать риски некорректных оценок финального эффекта и задержек в проведении пилота.
Создание такого бизнес-процесса (далее - БП):
- значительно уменьшает время на планирование и получение оценки пилота. Если БП создан командой АБ совместно с финансовой службой, то этот эффект еще заметнее. Финансовая служба - владелец процесса инвестиционного цикла проектов и являются ключевым согласующим по его этапам.
- позволяет получить максимально полную информацию для корректного планирования пилота и его последующей оценки, а значит, снижает риск неправильных выводов о финансовом эффекте.
Необходимые атрибуты процесса взаимодействия бизнеса с командой АБ-тестирования: единое окно для подачи всех заявок на АБ, механизм приоритезации, чек-листы для подачи заявки на дизайн пилота и на оценку эффекта после пилота, SLA ответа на корректно поданную заявку.
Ключевой атрибут - это чек-листы. Рассмотрим их подробнее.
A. Чек-лист для подачи заявки на дизайн пилота в команду АБ, включающий как технику, так и бизнес-постановку.
Бизнес-часть:
- сведения о заказчике пилота (бизнес-подразделение, контакты);
- содержание пилота (что внедряем, почему это принесет эффект);
- категория приоритетности расчета. Пока у вас нет библиотеки или платформы АБ-тестирования и дизайны экспериментов требуют вовлечения DS-ов, необходимо выстроить процесс приоритезации заявок: какие проекты оцениваются в 1/2/3 очередь, какие - не оцениваются вообще. Основа критериев: бюджет проведения пилота (считается ли проект крупным с точки зрения инвестиционного цикла компании) и материальность ожидаемого эффекта для PnL компании (ждем ли реально большой пользы от проекта).
Техническая часть. Стоит обозначить все пункты, необходимые для математического дизайна пилота по вашей методе:
- что является объектом тестирования;
- целевые метрики пилота и ожидаемый количественный эффект пилота на них;
- есть ли период привыкания с точки зрения бизнес-постановки. Например, распространено мнение, что изменение ассортимента в магазине может не сразу повлиять на спрос, покупателю требуется время привыкнуть к изменениям
возможные границы периода пилота, ожидаемая дата начала;
- максимальное количество объектов, которое бизнес готов выделить в пилот;
- ограничения на эти объекты по бизнес-постановке. Например, в пилот требуется включать только магазины определенных регионов присутствия и с финансовыми показателями выше заданных порогов.
Б. Чек-лист для подачи заявки в команду АБ на оценку пилота. Здесь возможны 2 варианта:
- Дизайн пилота делала команда АБ по единой методике. Чек-лист не требуется, вся информация есть у команды. Нужно только уведомление о завершении пилота и просьба рассчитать эффект.
- Пилот проводился без участия команды АБ. Для заявки на оценку пилота нужен максимально детальный чек-лист дизайна. Так команда АБ сможет понять, может ли сделать математически корректную оценку эффекта.
#business #ab_testing
Цикл постов про АБ-тестирование. Пост 4.
Теперь, когда мы разобрали бизнес-процессы и ключевые риски инвестиционного цикла и отдельно пилотирования, можно поговорить о том, как предусмотреть митигацию этих рисков при интеграции АБ-тестов в деятельность компании.
Первое, что мы рассмотрим, это создание процесса взаимодействия бизнеса с командой АБ-тестирования. Наличие у вас классной методики АБ - это круто, но этого недостаточно для того, чтобы нивелировать риски некорректных оценок финального эффекта и задержек в проведении пилота.
Создание такого бизнес-процесса (далее - БП):
- значительно уменьшает время на планирование и получение оценки пилота. Если БП создан командой АБ совместно с финансовой службой, то этот эффект еще заметнее. Финансовая служба - владелец процесса инвестиционного цикла проектов и являются ключевым согласующим по его этапам.
- позволяет получить максимально полную информацию для корректного планирования пилота и его последующей оценки, а значит, снижает риск неправильных выводов о финансовом эффекте.
Необходимые атрибуты процесса взаимодействия бизнеса с командой АБ-тестирования: единое окно для подачи всех заявок на АБ, механизм приоритезации, чек-листы для подачи заявки на дизайн пилота и на оценку эффекта после пилота, SLA ответа на корректно поданную заявку.
Ключевой атрибут - это чек-листы. Рассмотрим их подробнее.
A. Чек-лист для подачи заявки на дизайн пилота в команду АБ, включающий как технику, так и бизнес-постановку.
Бизнес-часть:
- сведения о заказчике пилота (бизнес-подразделение, контакты);
- содержание пилота (что внедряем, почему это принесет эффект);
- категория приоритетности расчета. Пока у вас нет библиотеки или платформы АБ-тестирования и дизайны экспериментов требуют вовлечения DS-ов, необходимо выстроить процесс приоритезации заявок: какие проекты оцениваются в 1/2/3 очередь, какие - не оцениваются вообще. Основа критериев: бюджет проведения пилота (считается ли проект крупным с точки зрения инвестиционного цикла компании) и материальность ожидаемого эффекта для PnL компании (ждем ли реально большой пользы от проекта).
Техническая часть. Стоит обозначить все пункты, необходимые для математического дизайна пилота по вашей методе:
- что является объектом тестирования;
- целевые метрики пилота и ожидаемый количественный эффект пилота на них;
- есть ли период привыкания с точки зрения бизнес-постановки. Например, распространено мнение, что изменение ассортимента в магазине может не сразу повлиять на спрос, покупателю требуется время привыкнуть к изменениям
возможные границы периода пилота, ожидаемая дата начала;
- максимальное количество объектов, которое бизнес готов выделить в пилот;
- ограничения на эти объекты по бизнес-постановке. Например, в пилот требуется включать только магазины определенных регионов присутствия и с финансовыми показателями выше заданных порогов.
Б. Чек-лист для подачи заявки в команду АБ на оценку пилота. Здесь возможны 2 варианта:
- Дизайн пилота делала команда АБ по единой методике. Чек-лист не требуется, вся информация есть у команды. Нужно только уведомление о завершении пилота и просьба рассчитать эффект.
- Пилот проводился без участия команды АБ. Для заявки на оценку пилота нужен максимально детальный чек-лист дизайна. Так команда АБ сможет понять, может ли сделать математически корректную оценку эффекта.
#business #ab_testing
👍3❤1👏1
АБ-тесты. Интеграция в процесс пилотирования. Что делать.
Пост 4. Взаимодействие АБ-команды, финансовой службы и бизнеса.
Краткое резюме - о чем был предыдущий пост.
Весь цикл постов про процессы в АБ-тестировании (на текущий момент):
- Пост 1. АБ-тесты - это не только ценный мех… Но еще и процессы. Об инвестиционном цикле и месте АБ в нем.
- Пост 2. АБ-тесты. Интеграция в процесс пилотирования. Как выглядит типовой бизнес-процесс без АБ.
- Пост 3. АБ-тесты. Интеграция в процесс пилотирования. Риски типового бизнес-процесса без АБ.
- Пост 4. АБ-тесты. Интеграция в процесс пилотирования. Что делать. Взаимодействие АБ-команды, финансовой службы и бизнеса.
- Продолжение - на канале Reliable ML!
#business #ab_testing
Пост 4. Взаимодействие АБ-команды, финансовой службы и бизнеса.
Краткое резюме - о чем был предыдущий пост.
Весь цикл постов про процессы в АБ-тестировании (на текущий момент):
- Пост 1. АБ-тесты - это не только ценный мех… Но еще и процессы. Об инвестиционном цикле и месте АБ в нем.
- Пост 2. АБ-тесты. Интеграция в процесс пилотирования. Как выглядит типовой бизнес-процесс без АБ.
- Пост 3. АБ-тесты. Интеграция в процесс пилотирования. Риски типового бизнес-процесса без АБ.
- Пост 4. АБ-тесты. Интеграция в процесс пилотирования. Что делать. Взаимодействие АБ-команды, финансовой службы и бизнеса.
- Продолжение - на канале Reliable ML!
#business #ab_testing
🔥8👍2❤1
Reliable ML как framework для работы с продвинутой аналитикой
В апреле мы рассказывали вам, какое содержание мы вкладываем в термин Reliable ML. Так называется наш канал, если вдруг кто еще не обратил внимания 😄
В сентябре я выступила на форуме Управление данными 2022 с более структурированным рассказом о том, что же такое Reliable ML как framework. Время выступления всего 20 минут, поэтому раскрыть детально удалось только темы про выбор проектов для реализации, бизнес-аспекты ML System Design и внедрение моделей.
Организаторы конференции разрешили выложить выступление.
https://www.youtube.com/watch?v=pTQYR0f5NQs
Welcome, кому интересно!
#reliable_ml
В апреле мы рассказывали вам, какое содержание мы вкладываем в термин Reliable ML. Так называется наш канал, если вдруг кто еще не обратил внимания 😄
В сентябре я выступила на форуме Управление данными 2022 с более структурированным рассказом о том, что же такое Reliable ML как framework. Время выступления всего 20 минут, поэтому раскрыть детально удалось только темы про выбор проектов для реализации, бизнес-аспекты ML System Design и внедрение моделей.
Организаторы конференции разрешили выложить выступление.
https://www.youtube.com/watch?v=pTQYR0f5NQs
Welcome, кому интересно!
#reliable_ml
👍8🔥5❤1