0:00
[БЕЗ СЛОВ] В
этом видео мы продолжим разбирать задачи прогнозирования оттока пользователей.
В прошлый раз мы остановились на том, что мы сформулировали постановку задачи,
теперь давайте перейдем непосредственно к построению модели.
И первое, с чего мы начнем, это построение набора данных, или датасета,
для обучения и оценки качества модели.
Первое, о чем хочется упомянуть, это то,
что мы можем работать с данными разного типа.
Это могут быть как числовые данные, например, данные, связанные с
количеством визитов пользователей на сервис в месяц или в неделю,
со средним чеком или другими показателями, которые можно измерить в цифрах.
С другой стороны, нам могут быть доступны номинальные данные,
например, пол пользователя, тарифный план, который он использует, или пакет услуг.
С другой стороны, мы можем работать с порядковыми данными.
Это также нечисловые данные, то есть номинальные данные,
однако на них мы можем установить некоторое отношение порядка.
Например, это могут быть данные про категорию пользователя, скажем,
это может быть абонент стандартный или корпоративный или бизнес-абонент.
С одной стороны, это номинальные признаки, с другой стороны,
мы можем некоторое отношение порядка на них установить.
Также мы часто будем сталкиваться с временными рядами,
потому что когда мы говорим о поведении пользователей, мы говорим о том,
как пользователи взаимодействуют с нашим сервисом в течение некоторого времени.
Поэтому временные ряды здесь будут практически всегда: это история
использования услуг, история заходов на сервис, история смены тарифных планов,
история покупок и различных платежей.
С этими данными также важно работать аккуратно, важно понимать, как их
обрабатывать, и очень многое об этом вы наверняка узнали из предыдущего урока.
Теперь важно понимать следующее: когда мы работаем с данными разного типа,
нам нужно убедиться в том, что те инструменты, которые мы используем,
мы используем правильно.
То есть мы не используем категориальные данные в качестве числовых.
Если мы все-таки используем номинальные или порядковые данные,
мы их обрабатываем соответствующим образом.
Если мы используем временные ряды, то мы понимаем, как мы их обрабатываем: либо мы
используем ряд целиком, либо мы рассчитываем характеристики,
специфичные для этого ряда, например, такие показатели, как лаг автокорреляции.
Это важно.
Далее давайте немножечко поговорим про выборку.
Часто целевой класс может составлять единицы или даже десятые доли процентов
от всей выборки.
Такая несбалансированность классов может негативно сказаться на модели
классификации.
Во-первых, может не хватить данных для обучения,
данных для настройки на целевой класс.
Это может привести к тому, что объекты не будут классифицироваться к этому классу,
потому что, скажем, с точки зрения модели это может быть очень рискованно.
Часто подобные проблемы возникают на практике.
Нам с вами очень важно заметить это в процессе обучения модели,
важно заметить это на метриках, то есть важно выбирать такие метрики,
которые к этому чувствительны, и решать эту проблему в процессе построения модели.
Давайте обсудим, как ее можно решать.
Вообще подходов достаточно много,
мы с вами рассмотрим три наиболее часто используемых подхода.
И первый подход называется reweighting, или перевзвешивание.
Идея этого подхода заключается в следующем: давайте зададим веса объектам
целевого класса таким образом, чтобы скомпенсировать их количество.
Как это можно делать?
Первое предположение следующее: давайте скомпенсируем количество объектов
меньшего класса их важностью.
Скажем, если мы изначально имеем соотношение 1 к 100,
давайте зададим веса таким образом, чтобы это соотношение изменилось, скажем,
1 к 10, 1 к 2 или даже 1 к 1.
Под соотношением мы понимаем следующее: мы с вами суммируем количество объектов с
весами одного класса,
количество объектов с весами другого класса и далее считаем соотношение.
То есть если изначально у нас веса всех объектов равняются единичке,
то есть мы веса фактически не задаем, то соотношение объектов разных классов —
это доля объектов одного класса по отношению к доле объектов другого класса.
Вот если теперь целевому классу мы добавим большие веса, больше единицы,
мы это соотношение можем склонить в сторону объектов целевого класса,
то есть как-то немножечко это скомпенсировать.
С другой стороны, мы можем задавать веса объектам,
исходя из стоимости ошибок классификации разного рода.
Мы понимаем, что в рамках задачи оттока нам важнее найти клиентов,
которые собираются от нас уйти, чем найти клиентов,
которые от нас уходить не собираются.
Поэтому если мы ошибочно отнесем клиента, который уходить не собирается, к оттоку,
это не так страшно, как если мы пропустим клиента, который от нас уходить
собирается, потому что в этом случае мы, конечно же, не сможем его удержать.
Соответственно, исходя из этих соображений, если мы понимаем, скажем,
в цифрах, в деньгах, насколько стоимость этой ошибки больше,
исходя из этого мы можем задать соответствующие веса объектам.
Следующая стратегия, которую мы рассматриваем, называется oversampling.
Идея этой стратегии следующая: если у нас ощущается нехватка объектов
целевого класса, если представителей класса «отток» слишком мало,
давайте сгенерируем больше объектов этого класса.
Весь вопрос в том, на основании чего эти объекты генерировать.
Ну, самое простое, что мы можем сделать, это задублировать объекты этих классов.
На самом деле, этот метод часто сводится к тому,
чтобы просто увеличить вес этих объектов.
С другой стороны,
мы с вами можем сгенерировать новые объекты на основании существующих.
Скажем, взять существующие объекты класса «отток» и несколько изменить значения
некоторых факторов, то есть с помощью таких небольших случайных изменений
породить больше объектов, похожих на настоящие объекты класса «отток».
С другой стороны, мы можем генерировать новые объекты на основании нескольких
объектов из класса «отток».
То есть, скажем, взять группу некоторых объектов и каким-то образом их усреднить,
построить объекты, похожие на несколько объектов целевого класса.
Другая стратегия — в некотором роде противоположная этой стратегии.
Это стратегия undersampling.
В рамках этой стратегии мы исходим из предположения,
что у нас слишком много объектов из нецелевого класса,
и давайте мы от какой-то части этих объектов просто избавимся.
Ну, что нам нужно сделать?
Нам нужно выбрать какие-то объекты, которые мы из выборки удалим.
Мы уже понимаем, что это объекты нецелевого класса,
осталось только понять какие.
Но самое простое — давайте уберем случайные объекты нецелевого класса.
Кажется, их достаточно много,
чтобы такая процедура не испортила качество нашей выборки.
С другой стороны, мы можем убирать их не совсем случайно.
Давайте каким-то образом выберем из них группу схожих объектов, допустим,
решим задачу кластеризации, и далее оставим только по нескольку представителей
из каждой группы схожих объектов, а всех остальных уберем.
Вот это тоже способ сбалансировать нашу выборку.
Итак, мы с вами обсудили три подхода для балансировки выборки: перевзвешивание,
oversampling и undersampling.
Теперь давайте перейдем непосредственно к обучению модели.
Мы зафиксировали набор данных, подумали о том, как мы будем решать проблему
балансировки классов, поэтому теперь можем смело переходить к обучению.
Предположим, что мы уже выбрали модель, выбрали инструмент, с помощью которого мы
будем строить модель, поэтому теперь нужно проконтролировать несколько вопросов.
Первый вопрос — это обучение на данных,
доступных не только за исторический период.
Нам важно убедиться, что в процессе обучения модели мы используем тот же самый
набор данных, который нам будет доступен при применении модели в prediction.
То есть в тот момент, когда мы захотим взять готовую модель и применить ее к
пользователям, которые сейчас в режиме real time пользуются нашим сервисом,
у нас не возникнет конфликта по данным, то есть у нас не возникнет таких данных,
которые доступны в оффлайне, которые доступны о клиентах из прошлого,
но недоступны о клиентах из будущего.
Допустим, у нас была некоторая услуга, которой клиенты пользовались,
мы использовали данные об этой услуге в процессе обучения, но сейчас этой услуги
уже нет, поэтому когда мы будем пытаться применить нашу модель,
обученную на данных с этой услугой к пользователям,
которые пользуются сервисом сейчас, у нас возникнет некоторый конфликт по данным.
Вот этого нужно избегать.
Следующая проблема — это обучение на данных из будущего.
Нам нужно очень внимательно контролировать временные промежутки,
на которых мы строим модель.
Важно, чтобы в обучающей выборке не было тех событий или тех данных,
которые нам на момент обучения не должны быть известны, скажем, тех событий,
которые еще не произошли.
И последняя классическая проблема построения модели — это контроль
переобучения.
Нам важно не переобучиться под конкретную группу пользователей,
не допустить подбора параметров, которые будут хорошо подходить к маленькой группе,
однако будут плохо работать на новых пользователях.
Теперь давайте поговорим про кросс-валидацию.
Это понятие вам уже знакомо, в частности оно используется для борьбы с
переобучением в процессе оптимизации модели.
В рамках нашей задачи мы можем рассмотреть два подхода к проведению кросс-валидации.
Это кросс-валидация по объектам и кросс-валидация по времени.
В рамках кросс-валидации по объектам мы делим объекты на выборки
по непересекающимся группам пользователей, то есть те пользователи,
которые участвуют в обучении, не участвуют в тестировании модели.
Это хороший подход.
С другой стороны, мы можем делать кросс-валидацию по времени,
то есть мы можем взять пользователей за более ранний период времени, обучить на
них модель и применить ее к пользователях за более поздний период времени.
При этом мы не запрещаем этим объектам пересекаться по пользователям, то есть мы
не запрещаем одному и тому же пользователю быть как в обучении, так и в тесте,
однако мы будем рассматривать разные данные касательно этого пользователя.
Кстати, эти подходы можно комбинировать, то есть можно строить выборки таким
образом, чтобы они не пересекались ни по пользователям, ни по времени.
В рамках каждой конкретной задачи вы можете выбирать тот подход,
который кажется вам более правильным.
Что касается задачи оттока, здесь я советую использовать кросс-валидацию по
времени, исходя из того, что данный вид кросс-валидации ближе к тому,
как мы будем использовать модель в реальности.
То есть когда мы будем обучать модель на всех данных и применять их к
пользователям, которые сейчас активно используют наш сервис, эта ситуация ближе
к кросс-валидации по времени, то есть на более ранних данных мы модель построили,
к более поздним данным мы ее применяем.
Соответственно, можно использовать кросс-валидацию по времени либо
комбинированный вариант.
Теперь давайте поговорим про подбор параметров.
Помимо того, что подбор параметров нужно делать на основании кросс-валидации, важно
всегда оставлять некоторую Независимую выборку, которая никак не используется в
процессе подбора параметров и других измерений в процессе оптимизации модели.
Это важно для того, чтобы мы имели такой неприкосновенный инструмент,
для того чтобы протестировать финальное решение.
В тот момент, когда мы обучили модель практически на всех данных,
нам важно понять, не допустили ли мы нигде никаких ошибок.
Вот в этом случае всегда можно использовать ту выборку,
которая в предыдущем анализе не участвовала никак.
Такая выборка называется hold-out dataset.
Таких датасетов может быть несколько, они могут быть построены по разным принципам,
но единственное, что их всегда объединяет — они абсолютно никак не
участвуют в процессе оптимизации настройки параметров модели.
Следующая важная вещь — это оценка качества.
Во-первых, нам нужно с самого начала определиться с целевой метрикой.
Такая метрика должна быть одна,
и именно это метрику мы с вами будем оптимизировать.
На основании этой метрики мы будем принимать решение о том, что
модель достаточно хороша, для того чтобы использовать ее на реальных пользователях,
для того чтобы проводить онлайн-эксперимент, например, A/B testing.
При этом метрика, которую мы оптимизируем, должна удовлетворять ряду требований.
Ну самое большое требование — желательно, чтобы это была та же
самая целевая метрика, которую мы будем считать в рамках онлайн-эксперимента,
та бизнес-метрика, на которую мы будем смотреть.
Но если это невозможно, то мы можем выбрать метрику таким образом,
чтобы она с ней коррелировала и соответствовала целевой метрике.
Очень важно оптимизировать в офлайне такую метрику,
которая будет соответствовать той метрике, которую мы оцениваем онлайн.
Также важно оценивать модель «скользящим окном» по времени.
Важно понимать, меняется ли качество модели в зависимости от того,
в какой день мы ее обучаем, в какой день мы ее применяем,
влияют ли на нее недельные тренды, месячные тренды и так далее.
Нам нужно понимать, насколько модель устойчива к сезонным изменениям.
Теперь давайте поговорим про улучшение модели.
Мы всегда сталкиваемся с такой ситуацией, что мы получили некоторую модель,
начинаем ее применять, она достаточно хорошо работает, и возникает вопрос, нужно
ли нам инвестировать еще время и средства в то, чтобы улучшать качество этой модели,
или же нам нужно здесь остановиться и использовать модель в таком виде,
в котором она есть.
Ну для того чтобы ответить на этот вопрос, для того чтобы оценить
перспективность улучшения модели, нужно провести некоторое исследование.
Во-первых, важно понять, на каких группах объектов модель ошибается,
перспективные ли это группы объектов,
важно ли нам на этих группах объектов получать хорошее качество классификации.
Также нам важно посмотреть на распределение ошибок, понять,
вообще говоря, от чего оно зависит.
Важно оценить экономическую перспективность, то есть понять,
как много денег мы теряем на ошибках модели, сколько нам стоят эти ошибки, а
также являются ли инвестиции в дальнейшее улучшение модели экономически выгодными.
То есть если у нас ошибок уже достаточно мало, кажется, что потери небольшие,
а инвестиции в улучшение модели планируются существенные,
то это может быть просто экономически необоснованно.
Важным этапом оценки любой модели, построенной на данных пользователей,
является этап интерпретации результатов.
Нам часто бывает интересно понять, какие же факторы внесли наибольший вклад в
обучение модели, какие факторы оказались наиболее сильными.
Также интересно проанализировать, как изменение факторов, скажем,
рост или падение конкретного фактора — особенно фактора, который находится в
топе, который является сильным фактором, —сказывается на результате классификации.
Приводит ли рост фактора к увеличению вероятности того,
что пользователь будет классифицирован как отток, или же к уменьшению.
Такой анализ позволит нам сформулировать новые гипотезы о том,
по каким причинам пользователи уходят,
с какими проблемами они сталкиваются и каким образом на это можно повлиять.
Также нам важно проанализировать объекты.
Нам важно понять, на каких объектах модель работает наиболее уверенно, где у
нас получается мало ошибок, где получается много, на каких объектах модель ошибается,
как эти объекты группируются и какие сегменты из них можно выделить.
Это также позволит нам понять, имеет ли смысл инвестировать в улучшение модели,
а может быть,
эти классы нужно рассматривать отдельно и строить на них отдельную модель.
Теперь давайте поговорим про работу модели в production.
После того как мы обучили первую модель и начали ее использовать,
нам важно понять, насколько хорошо эта модель работает,
насколько сильно меняется ее качество во времени.
С одной стороны, это важно для того, чтобы вовремя задетектировать то,
что модель начинает «протухать», то, что она уже не актуальна современным данным и
успеть ее переобучить, перестроить, начать использовать новую модель.
Как это понять?
Ну, во-первых, важно в процессе использования модели регулярно измерять
метрики качества и следить, смотреть на них в динамике, смотреть,
как они изменяются.
Также нам важно заранее оценить, насколько быстро модель обучается,
сколько времени нам требуется на то, чтобы построить новую модель,
оценить и принять решение о том, что можно модели заменять.
Соответственно, эти оценки нужны для того, чтобы мы могли заблаговременно
задетектировать момент, когда нужно будет переключиться на новую модель,
момент того, что старая модель начинает «протухать»,
и успеть за это время подготовить новую модель и произвести переход,
произвести переключение с одной модели на другую.
Как же такой мониторинг качества должен быть устроен?
Ну в данном случае нам нужно следить за двумя вещами — за изменениями данных и за
изменениями модели.
С точки зрения изменения данных нам важно понимать, не изменились ли наши данные,
не появились ли новые события или новые факторы, которые в модели еще не учтены,
но при этом существенно влияют на поведение пользователей.
Актуальны ли всё еще те допущения и эвристики,
которые мы строили в процессе построения текущей модели,
не пора ли нам их заменить и использовать какие-то новые допущения.
С другой стороны, нам важно мониторить качество модели и
оценивать не только ключевую метрику, которую мы оптимизировали,
но также смотреть на модель с разных точек зрения, смотреть на разные метрики.
А теперь давайте подведем итог.
Мы с вами рассмотрели задачу прогнозирования оттока пользователей.
Мы поняли, что это очень сложная задача, состоящая из целого ряда этапов.
Очень важно оценивать качество решения задачи на всех этих этапах, начиная от
постановки формальной задачи, заканчивая эксплуатацией и доработкой модели.
Также важно заранее составить список потенциальных узких мест и продумать
способы их детектирования.
Мы с вами обсудили возможность несогласованности метрик,
несбалансированности выборки, переобучения или обучения на данных из будущего.
Все эти проблемы актуальны не только для задачи прогнозирования оттока,
но также для других задач из области анализа пользовательского поведения,
например, работа с пользователями или привлечение пользователей.