В прошлой статье мы говорили о подходе к рекомендации сервисов на основании автоматизации расчета склонностей клиентов и единого репозитория предложений. В ней мы углубились в создание репозитория, описание логики категоризации и набора в кампании для коммуникации с клиентами. Сегодня мы подробнее расскажем про наш подход к автоматизации построения и вывода в прод набора моделей.

Как мы выбирали модель

Одной из задач, которые мы решали — сохранение продаж при уменьшении числа коммуникации. Решили общаться только с теми абонентами, для которых продукт релевантен.

Первая идея, которая приходит в голову для решения задач такого типа — рекомендательные алгоритмы: например, матричная факторизация, als или более сложные подходы, основанные на нейронных сетях.

В нашем случае мы отказались от использования рекомендательных алгоритмов по следующим причинам:

• Количество продуктов измеряется несколькими десятками — несопоставимо мало для использования нормальной рекомендашки.

• Матрица откликов разрежена, сложно сравнивать продукты между собой. Например, продукты имеют разную частоту списания и срок подписки: оплата парковки подключается по запросу абонента, а книги — это разовая подписка.

Таким образом, в качестве решения выбран набор моделей бинарной классификации для каждого продукта.

Теперь нужно решить задачку: сколько требуется специалистов в области data science для построения и поддержки 50 моделей?

Кажется, что если каждая модель будет прорабатываться отдельно, то это может привести к увеличению метрик качества модели: можно детально изучить модель, проконсультироваться с менеджером продукта для поиска значимых фич. Вместе с тем, у нас стоит задача уменьшения time2market, то есть вывода модели в прод.

Кроме этого, в арсенале мы имеем очень мощную систему хранения фичей для ML-моделей — FeatureStore (FS). Мы провели ряд экспериментов, которые показали, что потери на качестве не сравнимы с затратами на дополнительный поиск фичей.

Далее коснемся двух вопросов:

• Подход к автоматизации построения и вывода в прод набора однотипных моделей.

• Подход к оценке качества полученных моделей и выбора порогов релевантности для выбора абонентов для коммуникации

Часть 1. Подход к автоматизации построения и вывода в прод набора однотипных моделей

Feature Store

Для централизованного хранения, поддержки и управления признаками (фичами) абонента в ML-проектах мы используем платформу FeatureStore. В ней хранится огромное количество витрин, которые могут обновляться с разной частотой: от минутных метрик до ежемесячных агрегатов. А также у них есть временной сдвиг: например, метрики могут поступать с задержкой, а бизнес-отчеты агрегироваться в конце дня. Все это усложняет объединение данных в единый датасет для обучения моделей. Чтобы решить эту проблему, мы реализовали в нашей библиотеке специальный модуль "Features Collection", который:

• корректно синхронизирует данные с разной частотой обновления;

• учитывает сдвиг данных для обеспечения временной целостности;

• преобразует данные для оптимального хранения и использования в ML-моделях.

Каждая витрина имеет фиксированную структуру и свойства, что дает нам возможность зафиксировать всю необходимую информацию о витрине в yaml-файле.

Пример описания таблицы с данными:

name: AGG_FEATURES_EXAMPLE
bd_name: bd_name_example
primary_key:
- ctn
- ban
partition_col_name: time_key
partition_col_format: "%Y-%m-%d"
start_date: 2024-01-09
day_delay: 2
week_delay:
month_delay: 1
schedule: "0 0 11 * *"
description: "social demographic data"
features:
- market
- age_bkt
- lt_bkt
drop_duplicates: true

Для объединения данных мы используем следующий подход:

• На первом этапе мы определяем частоту обновления каждой таблицы и временной сдвиг:

  • Чтобы определить частоту обновления данных мы смотрим на метаданные таблицы. Частота обновления данных может быть weekly, daily или monthly.

  • Временной сдвиг определяется на основе зафиксированной при разработке витрины задержки.

• На втором этапе извлекаем данные из базы на основе частоты обновления, временного сдвига и объединения их в универсальный датасет.

Разбиение данных

Для разделения универсального датасета на данные для обучения (train), тестирования (test) и отложенную выборку (oot) мы реализовали метод spliter — в нем уделяется особое внимание формированию oot-выборки. Этот подход позволяет создать стабильное и воспроизводимое разбиение данных, которое не зависит от их порядка и обеспечивает равномерное распределение записей, что минимизирует риск случайных выбросов или смещений.

Для формирования oot-выборки используем следующий метод:

1. Задается список уникальных дат (oot_dates), строки с которыми будут претендовать на попадание в oot-выборку. Такой подход позволяет нам выделять данные за определенные периоды времени.

2. Для каждой строки рассчитывается хэш от идентификатора абонента, который затем нормализуется в диапазон от 0 до 1. Это обеспечивает равномерное распределение значений по всей выборке и позволят корректно выделять доли абоентов для отложенной выборки и теста.

3. Устанавливается параметр oot_size, определяющий долю абонентов, которые попадут в oot-выборку. Например, при oot_size = 0.2 в OOT будет отнесено 20% абонентов.

4. В oot-выборку попадают строки, которые одновременно:

• соответствуют заранее определённым датам;

• имеют нормализованный хэш, меньший или равный oot_size.

Далее происходит стандартное разбиение оставшихся абонентов на две выборки с учетом заранее фиксированной доли абонентов (test_size): train и test. Таким образом обученная модель тестируется на данных того же промежутка и на отложенной выборке. Такое разбиение позволяет добавить дополнительную проверку качества обучения модели на следующем этапе, так как исходные данные могут быть разнородными из-за методики подбора абонентов в кампании.

Выборка данных для подбора гиперпараметров (valid_df) может быть выделена отдельно в процессе обучения модели, так как зависит от выбранного метода (например, cross-validation или time-series).

Заключительный этап — проверка заполненности фичей и их распределений на разных выборках (критерий Колмогорова-Смирнова, тест Манна-Уитни). Конечный результат — репортинг и очищенные данные: удаление фичей по фиксированному набору условий.

Обучение моделей

Как было сказано выше, задача оценки отклика на продукт в терминах ML сводится к задаче бинарной классификации. Каждый продукт может продвигаться в нескольких каналах, например, sms, push, email. Мы строим модели на уровне продукта, канал продвижения включается в качестве фичи и используется для калибровки значений предсказаний. Разработка моделей на уровне продукт-канал кажется избыточной: уменьшается количество данных для обучения, что может помешать найти важные фичи в данных.

Для нашей задачи мы используем трехуровневую модель:

1. Обучение в режиме fast

На первом этапе происходит обучение легковесной модели на сэмпле данных. Основная цель — сокращение объема данных. Для отбора фичей мы обучаем модель catboost и используем permutation importance для отбора признаков (оставляем фичи, значение важности которых превышает 0). Кроме этого, есть возможность оставить только топ-N фичей для модели. Это позволит исключить фичи, которые оказывают незначительный вклад в увеличение метрик точности модели.

2. Обучение в режиме full

На втором этапе происходит обучение полной модели с помощью библиотеки LightAutoML от Сбера. Мы использовали однослойную модель (LightGBM и CatBoost) и блендинг на результатах скоринга этих моделей.

3. Калибровка модели на тестовой выборке данных

Есть много разных алгоритмов калибровки, которые преобразуют предсказанные значения как можно ближе к реальным. В нашем решении можно использовать один из встроенных калибраторов или добавить свой. Для оценки качества мы взяли кривую калибровки и метрику Expected Calibration Error (ECE). Таким образом, для каждого абонента мы можем получить набор склонностей к продукту в разных каналах продвижения.

Метрики и аналитика моделей

Результаты обучения модели оцениваются на стандартных метриках вроде roc auc, precision, recall, f1 и продвинутых, например, recall@k и lift curve. Ниже будет подробное описание использованных метрик и подходов к аналитике модели.

Особенность нашей работы — это тесное взаимодействие с продуктом. Конечно, все продукты разные и универсальное решение придумать сложно. Менеджерам важно объяснять, что модельный подход действительно имеет право на существование, поэтому мы пытаемся чуть глубже заглянуть в черный ящик наши модели.

На первом этапе строятся стандартные графики Feature Importance, Permutation Importance и Shap values. Далее мы смотрим более глубокую аналитику по фичам. Здесь нам может помочь визуализация чисел Шепли, а также Partial dependences plot. Кроме этого, можно просто разбить значения фичи по бинам и в каждом из них сравнить реальный отклик и средний скор модели.

Внедрение моделей

Для сохранения результатов используем MLFlow. Он позволяет залогировать саму модель и множество связанных артефактов: параметры, метрики, графики исследования важности фичей. Создание единого подхода к логированию моделей и структуры артефактов позволяет удобно сравнивать результаты экспериментов между собой.

На этапе деплоя происходит автоматическая генерация двух yaml-файлов для постановки модели на расписание в Argo Workflow, а также задания всех этапов для скоринга в проде:

• проверка данных (партиций в базовой таблице и в таблицах с фичами),

• генерация датасета для инференса модели (выбор и join нужных партиций в данных из разных таблиц использованием описанного выше модуля "Features Collection"),

• этап скоринга данных.

Код для последних двух этапов включен в библиотеку в качестве дополнительного модуля "Job".

Наличие специальных методов работы с FS позволяет в проде собирать только данные фичей, используемых в модели. Например, если в модели используется только 40 фичей из десяти источников данных, то в датасет для скоринга будет включать в себя только 10 столбцов с фичами. Все остальные столбцы данных подгружаться не будут.

Часть 2. Подход к оценке качества полученных моделей и выбора порогов релевантности для выбора абонентов для коммуникации

Напомним, что данные несбалансированные, а основная задача — выбор абонентов наиболее склонных к каждому продукту. Поэтому основной упор мы сделали на метрику recall@k и lift curve.

Метрика recall@k показывает долю правильно определенных единичек в топ-K клиентов, отсортированных в порядке убывания скора. Здесь стоит вспомнить, что у нас несбалансированные данные и отклик на продукт имеет низкие значения, поэтому для отсечения абонентов мы не можем использовать стандартное значение порога равное 0.5, средние значение отклика тоже может не отражать действительное распределение скоров.

Появляется вопрос: как отбирать порог отсечения модели? Для этого сортируем в порядке убывания скоры, полученные на тестовых данных, далее последовательно выбираем топ-k клиентов, рассчитываем recall и минимальный скор для этой группы абонентов — это значение будут соответствовать порогу отсечения (threshold@k).

Например, на левом рисунке ниже, при значении метрики recall@k на уровне 0.5 порогом будет значение 0.002, а при значении метрики recall@k на уровне 0.9 порогом будет значение 0.001.

Метрика lift curve позволяет оценить ранжирование абонентов. Грубо говоря, мы сравниваем, во сколько раз количество единичек в топ-k больше, чем в среднем по выборке, то есть при рандомизированном отборе абонентов.

Например, мы можем взять топ 20% и получить увеличение отклика в 4.2 раза (точка А). Взять 50% и получить увеличение отклика в 2 раза (точка В). Здесь можно поиграться с отображением и показать на кривой разные значение метрики recall@k, чтобы оценить увеличение потенциального отклика на продукт. Например, выше мы определили порог при recall@k=0.9 для сохранения 90% продаж, при данном пороге в среднем отклик на коммуникации увеличится в 1.5 раза. То есть мы сократим базу для коммуникации, при этом сохраним продажи на заданном уровне.

Результаты

1. Нам удалось автоматизировать весь pipline обучения модели от сбора фичей до постановки моделей на регулярный расчет. С учетом потенциальной загруженности кластера время на раскатку моделей для новых продуктов или переобучения сократилось до 1-2 дней.

2. Мы разработали подход к определению порогов для выбора абонентов для коммуникации. Задавая разные целевые метрики, мы можем сохранять долю откликов на заданном уровне с использованием метрики recall@k или увеличивать средний отклик при использовании подхода с lift кривыми.

Планы на будущее

Мы планируем развивать наш подход и выделили следующие направления работ:

• Разработка фичей на основании взаимодействия с менеджерами продуктов, дополнительный feature engeneering и их внедрение в FS.

• Мониторинг качества моделей и автоматическое переобучение модели.

• Добавление рандомных выборок абонентов в кампании, чтобы избежать истощения абонентской базы и переобучения модели на своих же результатах. Это, кстати, дополнительно может быть оценкой качества модели относительно рандомной выборки абонентов.

Над DS-частью проекта работали:

Евгений Наговицын, Наталия Култыгина, Богдан Севернов, Оксана Северюхина @oseveryukhina