Дизайн ML системы – Прогнозирование выручки в магазинах

Шаблон ML System Design Doc от телеграм-канала Reliable ML

• Рекомендации по процессу заполнения документа (workflow) - здесь.
• Детальный доклад о том, что такое ML System Design Doc и о том, как, когда и зачем его составлять - тут.

1 Цели и предпосылки

1.1 Обоснованность разработки продукта

Бизнес цель

Бизнес цель – замена ручной работы прогнозами модели, которые будут использоваться для:

• составления плана продаж в магазинах на следующие 6 месяцев
• сегментации магазинов на основе продаж для применения определенной стратегии взаимодействия

Побочная бизнес цель при получении прогнозов – uplift продаж в магазинах, получаемый при:

• точной сегментации магазина и применения определённой стратегии
• управления временем торговых представителей (увеличение посещаемости торговым, к примеру)

Описание текущего бизнес-процесса

Компания из отрасли FMSG отгружает свой товар в магазины для последующей продажи. Рассматриваемые в задаче магазины – точки частных предпринимателей (ларьки, киоски, все несетевые и малые магазины), называемые в компании традиционной торговлей.

Торговые представители компании на основе чек-листа и своего опыта оценивают средние продажи в магазине за полгода. Значения продаж для каждого из 6 месяцев – одинаковы, далее они нормируются на коэффициент сезонности.

Торговые представители посещают для оценки:

• заведённые в системе магазины раз в полгода
• новые при их открытии

Прогноз торговых представителей необходим для:

• определения плана продаж по точке
• выбора стратегии работы с магазином
• количество времени, уделяемое на обслуживание торговым представителем магазина. Чем больше времени уделяется – тем выше выручка

Задача торгового представителя компании – содействовать и контролировать реализацию товара. Типовые функции торгового:

• контроль наличия и правильности расстановки товара
• установка дополнительного оборудования для товара – подвесы, полки, холодильники

Польза от внедрения ML модели

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

Критерии успеха:

• модель выдаёт прогнозы с ≥ точностью, чем торговые представители но не ниже 80%

$$MAPE_{модель}≥MAPE_{торг.пред}$$

Некорректный прогноз по отдельному магазину означает неправильное составление плана по взаимодействию с ним, что несёт дополнительные затраты. Необходимо понимание не только картины в целом (как при использовании WAPE), но и по каждому магазину в частности. MAPE в расчётах:

$$MAPE=\frac{1}{N}\displaystyle\sum_{i=1}^{N}|{\frac{\hat{y_{i}}-y_{i}}{y_{i}}}|,$$

$N$ – общее количество заведённых в системе магазинов на момент прогноза

$\hat{y}_{i}$ – истинное значение среднемесячных продаж за 6 месяцев в магазине

$y_{i}$ – предсказанное значение среднемесячных продаж за 6 месяцев в магазине

• MAPE > 80% для магазинов с ежемесячными продажами категории товаров > 100 т.р. в месяц
• Экономия затрат, руб. – разработка и поддержка модели обходится дешевле потраченного торговыми представителями времени. Затраты на текущий бизнес-процесс (число предоставляет бизнес):

$$COST=(N+n){t}*{w}+S$$

${N}$ – общее количество заведённых в системе магазинов на момент прогноза;

${n}$ – количество новых магазинов, появляющихся за следующие 5 месяцев;

${t}$ – среднее время, затрачиваемое торговым на оценку магазина торговым;

${w}$ – совокупные затраты на торгового (ставка, затраты на транспорт);

${S}$ – стоимость поддержки аналитиков при составлении плана для торговых;

Затраты на внедрение проекта:

$$COST_{pr}=t_{sum}*{w}+P_{geo}+P_{ОФД}$$

$tsum$ – суммарное затраченное время на проект

$w$ – совокупная почасовая ставка команды

$P_{geo}$ – стоимость закупки геоданных

$P_{ОФД}$ – стоимость закупки чековых продаж ОФД

1.2 Бизнес требования и ограничения

Целевое видение

• Необходимо делать предсказания продаж на 6 следующих месяцев. Прогнозы получать 2 раза в год до последнего числа месяца:
  • Апрель
  • Ноябрь

Гранулярность расчёта – отдельный магазин, продажи категории товаров за месяц

• Предсказываются продажи отдельно для каждой категории товаров, всего 6 категорий.

• Истинные исторические значения продаж имеются во внутренней системе, данные загружаются спустя 2-3 месяца после факта продажи.

• Прогнозы для всех заведённых во внутренней системе магазинов (~120к) и для новых, заводящихся в течение 6 месяцев между прогнозами – для них прогноз делается отдельно.

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

  • Формата магазина (известен до посещения торговым) – минимаркет, алкомаркет, и т.д.
  • Площадь магазина (оценивается торговым)
  • Продажи категории товара. Торговый выбирает один из числовых диапазонов, который он считает наиболее близким к реальным продажам категории товара.

• Создание дэшборда для визуализации предсказаний модели. Требования к нему нет в данной операции, достаточно прогнозов в Excel.

• Интеграция результатов во внутренние системы компании. Результаты расчёта заносятся во внутреннюю систему и доступны всем.

Бизнес-требования и ограничения для пилота

• Необходимо cделать предсказания продаж на 6 следующих месяцев до конца мая.
• Гранулярность расчёта – отдельный магазин, продажи категории товаров за месяц
• Предсказываются продажи отдельно для 3-х категорий.
• Прогнозы делаются для всех магазинах в 3-х выбранных регионах. Регионы выбраны с максимальными различиями в:
  • Географическом положении
  • Характере изменения пешеходного трафика в течение года
  • Концентрации конкурентов-сетевых магазинов

Проведение пилота

• Тестирование модели и оценка пилота будут проводится на чековых данных, которые закупятся у операторов фискальных данных (ОФД). Предполагается, что эти данные будут иметь такой же вид, что и продажи категорий товаров по магазинам, имеющиеся во внутренней системе. Плюс использования чековых данных:
  • Быстрая оценка пилота – чековые данные доступны раньше ~ на 2 месяца, чем продажи во внутренней системе
  • Как следствие, увеличение времени для ролл-аута и доработок модели

Недостатки:

• Увеличение стоимости проекта
• Риск значимого отличия продаж в двух источниках

При невозможности оценки пилота на данных ОФД, будут использованы данные внутренней системы.

• Процесс тестирования модели

Обучение и валидация модели производится на имеющихся исторических данных продаж (из внутренней системы). Тестирование – на чеках ОФД за 1-2 месяца.

На тестовых данных вычисляется MAPE модели и торговых представителей. Вычисляются COSTpr для выбранных регионов, масштабируется на полный список регионов.

Критерии успешности пилота

• $MAPE > MAPE_{торговых} > 80$%
• $COST_{pr} < COST$

1.3 Что входит в скоуп итерации, а что нет

• Нет интеграции во внутренние системы
• Нет визуализации результатов в дэшборде

1.4 Предпосылки решения

Планируется создать 2 отличающиеся по архитектуре и входным признакам модели, т.е. будет 2 MVP, которые в последующем будут ансамблироваться.

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

Сейчас происходит переход на внутренние системы европейского подразделения. Пилот будет вестись на имеющихся платформах, с перспективой перехода при roll-out’е. Ниже описаны требования для пилота (текущей итерации).

• Проект ведётся в GitLab
• Документация – google docs на google disc. Должна содержать описание алгоритма, результаты промежуточных тестов
• Код. В JupyterLab, соответствует PEP8, разбит на модули
• Стек: PyTorch, Catboost + стандартный для DS
• БД: MongoDB

2 Методология

2.1 Постановка задачи

Создание прогнозной модели, задача регрессии.

2.2 Блок-схема (в приложении)

2.3 Этапы решения задачи

2.3.0 Этап 0 – Подготовка данных

Название данных	Есть ли данные в компании (если да, название источника/витрин)	Требуемый ресурс для получения данных (какие роли нужны)	Проверено ли качество данных (да, нет)
Геоданные	Нет	Аутсорс	Нет (проверены только схожие данные для другого проекта)
Обработка опросов	Нет	Отдел Sales operations	Нет (известен формат и возможные значения в данных, т.к. форма опроса составлялась заранее)
Данные по продажам	SAP-система	Data manager/DS	Да
Исторические прогнозы торговых	Excel файлы бизнеса	Product owner /DS	Нет
Чековые данные	ОФД	Product owner/DS	Нет (за качество данных ответствен поставщик)

2.3.1 Этап 1 – Проверка данных

Общие требования к данным:

• Данные есть для полной базы точек (110к), процент пропусков < 5% (кроме продаж)
• Отсутствие дубликатов в ID магазинов, которые могут иметь разный код, но быть одним и тем же местом

Название данных	Требования
Геоданные	- Координаты магазинов не отличаются от настоящих более чем на 30 метров - Имеется 20 трафиков для каждого магазина - Трафики не должны быть схожи и/или дублированы - Методология сбора трафиков не отличается от аналогичной для других проектов
Обработка опросов	Торговые заполнили данные по магазинам в соответствии с шаблоном, выбирая только имеющиеся варианты ответов
Данные по продажам	- Требуется проверка на экстремальные значения продаж - В продажах нет пропусков – учтены все каналы сбыта (напрямую по точке, через распределительный центр, через поставщиков)
Исторические прогнозы торговых	- Имеются числовые прогнозы по месяцам
Чековые данные	- Содержат помесячные продажи каждой категории отдельно - Нет серьёзных отличий от продаж в системе (не более 50% в отдельном магазине и месяце с поправкой на сезональность)

Риски:

• Значение продаж в магазине не полное – не учтён один из каналов сбыта продукции. Потребуется поиск внутри системы продаж, объединение с имеющимися или иной метод восстановления данных.
• Чековые данные не похожи на имеющиеся в системе (иной формат, попала продукция конкурентов, слишком большое расхождение в значениях и т.д.) за аналогичный период продаж. Риск поставщика или специфика сбора данных в маленьких магазинах. В этом случае чековые данные использовать не стоит.
• Дубликаты ID магазинов трудно поддаются отчистке. Пример – разные ИП магазина, название и немного отличающаяся геолокация, хотя это один и тот же магазин. Требуется более точный алгоритм удаления дубликатов.

2.3.2 Этап 2

Baseline

Бэйзлайн – прогнозы торговых представителей по каждому магазину. Это главный ориентир при сравнении всех моделей. Простое прогнозирование – скользящие окна по предыдущим продажам, кластеризация магазинов, логистическая регрессия если рассматривать задачу как классификационную (определять принадлежность к классу, минуя этап прогноза продаж), либо не дают минимально значимых результатов, либо требуют обработку и подбор признаков, что схоже по трудозатратам с построением MVP.

Основной таргет – продажи категории товара в магазине за месяц (одно значение на все следующие 6 месяцев).

Дополнительный таргет – определение диапазона продаж, которые используются для дальнейшей сегментации. Диапазон продаж:

• малый магазин, выручка < 20 т.р.
• средний, от 20 т.р. до 80 т.р.
• большой, > 80 т.р.

Метрики торговых вычисляются на данном этапе, после сбора данных. Риски этапа:

• Отсутствие данных по точным значениям продаж при наличии только диапазонов. Будет использоваться только метрика классификации для оценки бэйслайна, MVP сравниваться с самими собой.
• Некорректный выбор метрики из-за дисбаланса класса. Последует замена метрики на более корректную.

Основная метрика – MAPE. В прошлом равнялась 65%.

Дополнительная метрика – Accuracy, верное отнесение торговым представителем магазина к классу. Она не будет использоваться в расчётах, скорее для презентации бизнесу, насколько точно определялись сегменты исходя из прогнозов торговых. В прошлом у торговых она равнялась 87%.

MVP, Общие положения

Общий размер выборки – 120000 магазинов/строк.

Для валидации отбираются 25% точек, стратифицируя их по регионам и размеру городов. Для обучения используются средние продажи категории за период (год), усредняя месячные продажи.

Гранулярность: отдельно взятый магазин, таргет – как в бэйзлайне.

Частота пересчёта прогнозов: раз в 5 месяцев.

Метрика – MAPE, R2.

$$MAPE=\frac{1}{N}\displaystyle\sum_{i=1}^{N}|{\frac{\hat{y_{i}}-y_{i}}{y_{i}}}|$$

$$R^2 = 1- \frac{\displaystyle\sum_{i=1}^{N}(\hat{y_{i}} - y_{i})^2}{\displaystyle\sum_{i=1}^{N}(\overline{y_{i}} - y_{i})^2}$$

$\overline{y}_{i}$ – средние значение среднемесячных продаж за 6 месяцев в магазине

$\hat{y}_{i}$ – истинное значение среднемесячных продаж за 6 месяцев в магазине

${y}_{i}$ – предсказанное значение среднемесячных продаж за 6 месяцев в магазине

Использование R2 необходимо для:

• понимания, насколько хорошо модель связывает выбранные признаки с целевой переменной. Как одно из следствий – доказательство бизнесу преимущества использования модели перед бейзлайном
• экономии бюджета - определение необходимого набора признаков при их закупке/сборе

Необходимый результат этапа:

• Обучение модели с заданной точностью
• Получение набора признаков для отдельного MVP

Общие для MVP задачи этапа

• Отбор признаков для модели. Для catboost – оценка важности признаков встроенным методом feature_importance, для физической модели – L1 регуляризация
• Достижение MAPE > 80%

MVP 1, Построение модели оценки спроса

Алгоритм решения – математическая (физическая) модель спроса в магазине. Компоненты модели – взвешенные трафики потребителей в магазин в радиусе 20 метрах, вызванные определённой причиной. Данные парсятся с яндекс.карт и 2GIS, измеряются в человеках в час. Пример:

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

Риски:

• Слишком высокая региональная специфика, как следствие, обучение моделей для отдельного региона. Можно произвести кластеризацию регионов, получив кластеры-макрорегионы, чтобы снизить количество моделей. Или увеличить вклад региональности в общую модель
• Дороговизна набора признаков. Будет использовано слишком много закупаемых данных. Риск можно снизить путём увеличения отдачи от проекта (распространение его не только на магазины, но и на других клиентов – бары, рестораны и т.д.). Или отказ от закупки данных, переход к самостоятельному сбору трафиков.

MVP 2, Построение модели прогноза продаж

Алгоритм решения – градиентный бустинг над решающими деревьями, т.к. набор стандартен для подобного алгоритма.

Имеющиеся данные:

• описание магазина (площадь, формат, наличие эквайринга и т.д.)
• имеющийся ассортимент (характеристики продаваемой продукции)

Задача feature engineering – получить набор значимых признаков.

Риски этапа:

• переобучение модели. Потребуется дополнительный feature engineering.
• невозможность предсказывать продажи в локациях, где влияние окружающей среды гораздо сильнее характеристики магазинов, как следствие, высокое MAPE при низком WAPE. Ансамблирование с моделью трафиков снизит ошибку в этом случае.
• недостаточность собранных данных о магазинах. Этот риск в текущем проекте нивелировать невозможно
• недостаточное нивелирование сезонности в продажах

2.3.3 Этап 3 – Интерпретация моделей

Результат этапа:

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

Методы оценки:

• Для модели оценки спроса – оценка весов для каждого трафика в каждом регионе
• Модели прогноза продаж – изучение разбиения решающего дерева и весов факторов

При наличии дисбаланса в значимости факторов будет произведено переобучение моделей и/или дополнительный feature engineering.

Главные риски этапа: несогласуемость её с бизнес-логикой. В этом случае происходит возврат к этапу 2.3.2

2.3.4 Этап 4 – Ансамблирование

Результат этапа:

• Выбор ансамбля (предположительно, сумма от взвешенных ответов двух моделей)
• Получение ансамбля с точностью большей, чем у отдельно взятых моделей
• Возврат к этапу 2.3.1 или отказ от ансамблирования при плохих метриках, выбор наиболее точной модели

2.3.5 Этап 5 – Анализ ансамблиевой модели

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

Показ бизнес-заказчику предварительных результатов. Главный риск - неудовлетворённость заказчика точностью или наглядностью, понятностью результатов. Возврат к этапу 2.3.1

2.3.6 Этап 6 – Интеграция бизнес-правил

Интеграция бизнес-правил заключается в назначении класса магазина исходя из прогнозов продаж. Возможна выработка новых стратегий по взаимодействию с классами или получение новых классов на основе прогнозов – кластеризация магазинов.

2.3.7 Этап 7 – Подготовка к пилоту

Итоговый формат передачи данных в формате Excel:

Id магазина	Категория продаж	Продажи за месяц 1	…	Продажи за месяц 6
2003004	Напитки
2003004	Снэки
2003004	Соки
2003005	Напитки

3 Пилот

3.0 Описание методики пилота

Для 3-х пилотных регионов делаются прогнозы продаж. По магазинам в этих регионах делаются закупки чековых данных за полгода – тестовые значения, на основании которых считаются метрики точности.

На данном этапе развития проекта A/B тест не производится, т.к. отдача от проекта должна быть столь значительна, что статистически подтверждать гипотезы не должно иметь смысла.

3.1 Оценка успешности пилота

Общие с критериями успешности проекта.

4 Внедрение в production

На данной итерации не требуется, достаточно рассчитанных значений