Шаблон ML System Design Doc от телеграм-канала Reliable ML
- Рекомендации по процессу заполнения документа (workflow) - здесь.
- Детальный доклад о том, что такое ML System Design Doc и о том, как, когда и зачем его составлять - тут.
Бизнес цель – замена ручной работы прогнозами модели, которые будут использоваться для:
- составления плана продаж в магазинах на следующие 6 месяцев
- сегментации магазинов на основе продаж для применения определенной стратегии взаимодействия
Побочная бизнес цель при получении прогнозов – uplift продаж в магазинах, получаемый при:
- точной сегментации магазина и применения определённой стратегии
- управления временем торговых представителей (увеличение посещаемости торговым, к примеру)
Компания из отрасли FMSG отгружает свой товар в магазины для последующей продажи. Рассматриваемые в задаче магазины – точки частных предпринимателей (ларьки, киоски, все несетевые и малые магазины), называемые в компании традиционной торговлей.
Торговые представители компании на основе чек-листа и своего опыта оценивают средние продажи в магазине за полгода. Значения продаж для каждого из 6 месяцев – одинаковы, далее они нормируются на коэффициент сезонности.
Торговые представители посещают для оценки:
- заведённые в системе магазины раз в полгода
- новые при их открытии
Прогноз торговых представителей необходим для:
- определения плана продаж по точке
- выбора стратегии работы с магазином
- количество времени, уделяемое на обслуживание торговым представителем магазина. Чем больше времени уделяется – тем выше выручка
Задача торгового представителя компании – содействовать и контролировать реализацию товара. Типовые функции торгового:
- контроль наличия и правильности расстановки товара
- установка дополнительного оборудования для товара – подвесы, полки, холодильники
Внедрение ML модели сократит расходы на оценку выручки, исключат человеческий фактор торговых представителей, увеличит точность определения значимых магазинов, с которыми необходимо взаимодействовать в первую очередь
- модель выдаёт прогнозы с ≥ точностью, чем торговые представители но не ниже 80%
Некорректный прогноз по отдельному магазину означает неправильное составление плана по взаимодействию с ним, что несёт дополнительные затраты. Необходимо понимание не только картины в целом (как при использовании WAPE), но и по каждому магазину в частности. MAPE в расчётах:
- MAPE > 80% для магазинов с ежемесячными продажами категории товаров > 100 т.р. в месяц
- Экономия затрат, руб. – разработка и поддержка модели обходится дешевле потраченного торговыми представителями времени. Затраты на текущий бизнес-процесс (число предоставляет бизнес):
Затраты на внедрение проекта:
Целевое видение
- Необходимо делать предсказания продаж на 6 следующих месяцев. Прогнозы получать 2 раза в год до последнего числа месяца:
- Апрель
- Ноябрь
Гранулярность расчёта – отдельный магазин, продажи категории товаров за месяц
-
Предсказываются продажи отдельно для каждой категории товаров, всего 6 категорий.
-
Истинные исторические значения продаж имеются во внутренней системе, данные загружаются спустя 2-3 месяца после факта продажи.
-
Прогнозы для всех заведённых во внутренней системе магазинов (~120к) и для новых, заводящихся в течение 6 месяцев между прогнозами – для них прогноз делается отдельно.
-
На основе предсказания необходимо отнести точки к разным сегментам, для каждого из которого выработана стратегия взаимодействия с магазином. Сегменты получаются комбинациями:
- Формата магазина (известен до посещения торговым) – минимаркет, алкомаркет, и т.д.
- Площадь магазина (оценивается торговым)
- Продажи категории товара. Торговый выбирает один из числовых диапазонов, который он считает наиболее близким к реальным продажам категории товара.
-
Создание дэшборда для визуализации предсказаний модели. Требования к нему нет в данной операции, достаточно прогнозов в Excel.
-
Интеграция результатов во внутренние системы компании. Результаты расчёта заносятся во внутреннюю систему и доступны всем.
Бизнес-требования и ограничения для пилота
- Необходимо cделать предсказания продаж на 6 следующих месяцев до конца мая.
- Гранулярность расчёта – отдельный магазин, продажи категории товаров за месяц
- Предсказываются продажи отдельно для 3-х категорий.
- Прогнозы делаются для всех магазинах в 3-х выбранных регионах. Регионы выбраны с максимальными различиями в:
- Географическом положении
- Характере изменения пешеходного трафика в течение года
- Концентрации конкурентов-сетевых магазинов
Проведение пилота
- Тестирование модели и оценка пилота будут проводится на чековых данных, которые закупятся у операторов фискальных данных (ОФД). Предполагается, что эти данные будут иметь такой же вид, что и продажи категорий товаров по магазинам, имеющиеся во внутренней системе.
Плюс использования чековых данных:
- Быстрая оценка пилота – чековые данные доступны раньше ~ на 2 месяца, чем продажи во внутренней системе
- Как следствие, увеличение времени для ролл-аута и доработок модели
Недостатки:
- Увеличение стоимости проекта
- Риск значимого отличия продаж в двух источниках
При невозможности оценки пилота на данных ОФД, будут использованы данные внутренней системы.
- Процесс тестирования модели
Обучение и валидация модели производится на имеющихся исторических данных продаж (из внутренней системы). Тестирование – на чеках ОФД за 1-2 месяца.
На тестовых данных вычисляется MAPE модели и торговых представителей. Вычисляются COSTpr для выбранных регионов, масштабируется на полный список регионов.
Критерии успешности пилота
-
$MAPE > MAPE_{торговых} > 80$ % $COST_{pr} < COST$
- Нет интеграции во внутренние системы
- Нет визуализации результатов в дэшборде
Планируется создать 2 отличающиеся по архитектуре и входным признакам модели, т.е. будет 2 MVP, которые в последующем будут ансамблироваться.
Младшие разработчики не только должны участвовать в процессе, но и понимать всю методологию. Все члены команды должны иметь схожие знания и способность развивать/поддерживать продукт самостоятельно.
Сейчас происходит переход на внутренние системы европейского подразделения. Пилот будет вестись на имеющихся платформах, с перспективой перехода при roll-out’е. Ниже описаны требования для пилота (текущей итерации).
- Проект ведётся в GitLab
- Документация – google docs на google disc. Должна содержать описание алгоритма, результаты промежуточных тестов
- Код. В JupyterLab, соответствует PEP8, разбит на модули
- Стек: PyTorch, Catboost + стандартный для DS
- БД: MongoDB
Создание прогнозной модели, задача регрессии.
| Название данных | Есть ли данные в компании (если да, название источника/витрин) | Требуемый ресурс для получения данных (какие роли нужны) | Проверено ли качество данных (да, нет) |
|---|---|---|---|
| Геоданные | Нет | Аутсорс | Нет (проверены только схожие данные для другого проекта) |
| Обработка опросов | Нет | Отдел Sales operations | Нет (известен формат и возможные значения в данных, т.к. форма опроса составлялась заранее) |
| Данные по продажам | SAP-система | Data manager/DS | Да |
| Исторические прогнозы торговых | Excel файлы бизнеса | Product owner /DS | Нет |
| Чековые данные | ОФД | Product owner/DS | Нет (за качество данных ответствен поставщик) |
2.3.1 Этап 1 – Проверка данных
Общие требования к данным:
- Данные есть для полной базы точек (110к), процент пропусков < 5% (кроме продаж)
- Отсутствие дубликатов в ID магазинов, которые могут иметь разный код, но быть одним и тем же местом
| Название данных | Требования |
|---|---|
| Геоданные | - Координаты магазинов не отличаются от настоящих более чем на 30 метров - Имеется 20 трафиков для каждого магазина - Трафики не должны быть схожи и/или дублированы - Методология сбора трафиков не отличается от аналогичной для других проектов |
| Обработка опросов | Торговые заполнили данные по магазинам в соответствии с шаблоном, выбирая только имеющиеся варианты ответов |
| Данные по продажам | - Требуется проверка на экстремальные значения продаж - В продажах нет пропусков – учтены все каналы сбыта (напрямую по точке, через распределительный центр, через поставщиков) |
| Исторические прогнозы торговых | - Имеются числовые прогнозы по месяцам |
| Чековые данные | - Содержат помесячные продажи каждой категории отдельно - Нет серьёзных отличий от продаж в системе (не более 50% в отдельном магазине и месяце с поправкой на сезональность) |
Риски:
- Значение продаж в магазине не полное – не учтён один из каналов сбыта продукции. Потребуется поиск внутри системы продаж, объединение с имеющимися или иной метод восстановления данных.
- Чековые данные не похожи на имеющиеся в системе (иной формат, попала продукция конкурентов, слишком большое расхождение в значениях и т.д.) за аналогичный период продаж. Риск поставщика или специфика сбора данных в маленьких магазинах. В этом случае чековые данные использовать не стоит.
- Дубликаты ID магазинов трудно поддаются отчистке. Пример – разные ИП магазина, название и немного отличающаяся геолокация, хотя это один и тот же магазин. Требуется более точный алгоритм удаления дубликатов.
Baseline
Бэйзлайн – прогнозы торговых представителей по каждому магазину. Это главный ориентир при сравнении всех моделей. Простое прогнозирование – скользящие окна по предыдущим продажам, кластеризация магазинов, логистическая регрессия если рассматривать задачу как классификационную (определять принадлежность к классу, минуя этап прогноза продаж), либо не дают минимально значимых результатов, либо требуют обработку и подбор признаков, что схоже по трудозатратам с построением MVP.
Основной таргет – продажи категории товара в магазине за месяц (одно значение на все следующие 6 месяцев).
Дополнительный таргет – определение диапазона продаж, которые используются для дальнейшей сегментации. Диапазон продаж:
- малый магазин, выручка < 20 т.р.
- средний, от 20 т.р. до 80 т.р.
- большой, > 80 т.р.
Метрики торговых вычисляются на данном этапе, после сбора данных. Риски этапа:
- Отсутствие данных по точным значениям продаж при наличии только диапазонов. Будет использоваться только метрика классификации для оценки бэйслайна, MVP сравниваться с самими собой.
- Некорректный выбор метрики из-за дисбаланса класса. Последует замена метрики на более корректную.
Основная метрика – MAPE. В прошлом равнялась 65%.
Дополнительная метрика – Accuracy, верное отнесение торговым представителем магазина к классу. Она не будет использоваться в расчётах, скорее для презентации бизнесу, насколько точно определялись сегменты исходя из прогнозов торговых. В прошлом у торговых она равнялась 87%.
Общий размер выборки – 120000 магазинов/строк.
Для валидации отбираются 25% точек, стратифицируя их по регионам и размеру городов. Для обучения используются средние продажи категории за период (год), усредняя месячные продажи.
Гранулярность: отдельно взятый магазин, таргет – как в бэйзлайне.
Частота пересчёта прогнозов: раз в 5 месяцев.
Метрика – MAPE, R2.
Использование R2 необходимо для:
- понимания, насколько хорошо модель связывает выбранные признаки с целевой переменной. Как одно из следствий – доказательство бизнесу преимущества использования модели перед бейзлайном
- экономии бюджета - определение необходимого набора признаков при их закупке/сборе
Необходимый результат этапа:
- Обучение модели с заданной точностью
- Получение набора признаков для отдельного MVP
Общие для MVP задачи этапа
- Отбор признаков для модели. Для catboost – оценка важности признаков встроенным методом feature_importance, для физической модели – L1 регуляризация
- Достижение MAPE > 80%
Алгоритм решения – математическая (физическая) модель спроса в магазине. Компоненты модели – взвешенные трафики потребителей в магазин в радиусе 20 метрах, вызванные определённой причиной. Данные парсятся с яндекс.карт и 2GIS, измеряются в человеках в час. Пример:
- пешеходный трафик рядом с магазином
- автомобильный трафик
- трафик от новостроек
- трафик в бизнес-центры
- университеты и т. д.
Риски:
- Слишком высокая региональная специфика, как следствие, обучение моделей для отдельного региона. Можно произвести кластеризацию регионов, получив кластеры-макрорегионы, чтобы снизить количество моделей. Или увеличить вклад региональности в общую модель
- Дороговизна набора признаков. Будет использовано слишком много закупаемых данных. Риск можно снизить путём увеличения отдачи от проекта (распространение его не только на магазины, но и на других клиентов – бары, рестораны и т.д.). Или отказ от закупки данных, переход к самостоятельному сбору трафиков.
Алгоритм решения – градиентный бустинг над решающими деревьями, т.к. набор стандартен для подобного алгоритма.
Имеющиеся данные:
- описание магазина (площадь, формат, наличие эквайринга и т.д.)
- имеющийся ассортимент (характеристики продаваемой продукции)
Задача feature engineering – получить набор значимых признаков.
Риски этапа:
- переобучение модели. Потребуется дополнительный feature engineering.
- невозможность предсказывать продажи в локациях, где влияние окружающей среды гораздо сильнее характеристики магазинов, как следствие, высокое MAPE при низком WAPE. Ансамблирование с моделью трафиков снизит ошибку в этом случае.
- недостаточность собранных данных о магазинах. Этот риск в текущем проекте нивелировать невозможно
- недостаточное нивелирование сезонности в продажах
Результат этапа:
- Оценка влияния различных факторов, сравнение их с бизнес-логикой
- Проверка отсутствия переобучения моделей
Методы оценки:
- Для модели оценки спроса – оценка весов для каждого трафика в каждом регионе
- Модели прогноза продаж – изучение разбиения решающего дерева и весов факторов
При наличии дисбаланса в значимости факторов будет произведено переобучение моделей и/или дополнительный feature engineering.
Главные риски этапа: несогласуемость её с бизнес-логикой. В этом случае происходит возврат к этапу 2.3.2
Результат этапа:
- Выбор ансамбля (предположительно, сумма от взвешенных ответов двух моделей)
- Получение ансамбля с точностью большей, чем у отдельно взятых моделей
- Возврат к этапу 2.3.1 или отказ от ансамблирования при плохих метриках, выбор наиболее точной модели
Интерпретация результатов ансамблиевой модели. Поиск взаимосвязей между признаками для двух отдельных моделей.
Показ бизнес-заказчику предварительных результатов. Главный риск - неудовлетворённость заказчика точностью или наглядностью, понятностью результатов. Возврат к этапу 2.3.1
Интеграция бизнес-правил заключается в назначении класса магазина исходя из прогнозов продаж. Возможна выработка новых стратегий по взаимодействию с классами или получение новых классов на основе прогнозов – кластеризация магазинов.
Итоговый формат передачи данных в формате Excel:
| Id магазина | Категория продаж | Продажи за месяц 1 | … | Продажи за месяц 6 |
|---|---|---|---|---|
| 2003004 | Напитки | |||
| 2003004 | Снэки | |||
| 2003004 | Соки | |||
| 2003005 | Напитки |
Для 3-х пилотных регионов делаются прогнозы продаж. По магазинам в этих регионах делаются закупки чековых данных за полгода – тестовые значения, на основании которых считаются метрики точности.
На данном этапе развития проекта A/B тест не производится, т.к. отдача от проекта должна быть столь значительна, что статистически подтверждать гипотезы не должно иметь смысла.
Общие с критериями успешности проекта.
На данной итерации не требуется, достаточно рассчитанных значений