Шаблон ML System Design Doc от телеграм-канала Reliable ML
- Рекомендации по процессу заполнения документа (workflow) - здесь.
- Шаблон дизайн-дока.
- Товар - помещение, которое сдаётся в аренду
- Клиент - компания или предприниматель, который ищет или искал помещение в аренду и уже обращался в компанию в его поисках, но не обязательно заключил сделку
- Сделка - подписанный и оплаченный договор аренды
- Лид - Клиент, который еще не был проверен Менеджером и не получил первичную подборку коммерческих предложений
- ИММО - Итерация по моделированию машинного обучения (ИММО). Состоит из шагов поиска данных, их обработки, подготовки к машинному обучению, само машинное обучение и анализ полученных результатов
- Бизнес-цель: увеличить среднюю конверсию из лида в успешную сделку для арендаторов до 3-4% с текущих 1-2%. Промежуточные цели: поднять % перехода из лида в сделку. Тут сложно определить целевую величину, так как сейчас сделки создаются не предсказуемо без правил. В разработке стоит задача сделать автоматизацию создания сделок каждый раз, когда клиенту отправляется КП. С её внедрением показатель автоматически вырастет. На стадии деплоя этой разработки придется наблюдать за этой метрикой снова и отталкиваться уже от неё. Сейчас в сделку переходят 15% лидов.
- Почему станет лучше, чем сейчас, от использования: система сможет прогнозировать сделку лучше, чем это делает человек. Клиенту делается предложение 2-4 помещений из 100+. В этом случае человек точно упускает варианты и даже не предлагает их. Машина способна поднять это качество и помогать менеджеру делать подборку ничего не пропуская и с большей вероятностью в успехе.
- Логика работы ML: Машинное обучение работает по принципу запрос-ответ. Из CRM системы поступает запрос с данными о Клиенте и Менеджере (признаками для предикта). В ответ система выдаёт ответ с номерами айди товаров которые на её взгляд приведут к сделке у данного менеджера с данным клиентом.
- Бизнес-требования: Запрос-ответ должен происходить не более 10 секунд. В идеале 2-3.
- Успешная модель: успешной будет модель, которая предлагает на уровне опытного менеджера такие товары, которые будут выгодны менеджеру и интересны клиенту для заключения Сделки.
- Возможные пути развития проекта: Шаг 1 (Остап v1.0). Убрать всё не подходящее. Модель классификации товаров. Товары классифицируются на подходящий и неподходящий. Версии модели (0.1, 0.2, 0.3...) отличаются уровнем качества. Подверсии (0.1.1, 0.1.2, 0.1.3...) удобством и устойчивостью. Шаг 2 (Остап v2.0). Ранжировать подходящее. Рекомендательная система. Товары расставляются в порядке вероятности заключения сделки. Версии модели отличаются по уровню качества. Подверсии - интерпретируемостью модели, устойчивостью. Шаг 3(Остап v3.0). Рекомендательная система подбора арендатора. Товарам рекомендуются клиенты. Модель оценивает сумму и вероятность сделки. Версии отличаются точностью. Подверсии - удобством и устойчивостью.
- Среда: разработка на мощностях компании в её удалённом сервере. Отдельная виртуальная машина, находящаяся в локальной среде в кластере.
- Стэк-технологии: Flask
- Данные: Используется база данных CRM компании. Карточки Компаний(Лид/Компания), Товары, Менеджер. Данные о текущих сделках: арендатор+место+условия из 1с обогощенные полями из црм. Данные собраны за 8 лет работы и старые сделки могут путать систему. Полнота и достоверность данных лучше с 2020 года и хуже до этого периода. Актуализировать данные в порядке от заполнения Товаров к заполнению карточек компании: Арендаторы в успешных сделках, аренадторы из списка мозгового штурма, новые лиды месяца и далее.
- Исполнители: Проект выполняется мной, поэтому могут быть ограничения связанные с нехваткой опыта/знаний
- Что мы ожидаем от конкретной итерации: проверка на верную интерпретацию моделью признаков. Корреляция на попадание в диапазон квадратных метров и в бюджет арендатора. Определение целевых метрик и способов мониторинга качества модели. Верный предпроцессинг категориальных признаков.
- На закрытие каких БТ подписываемся в данной итерации: в strealit машина должна предлагать подходящие помещения в топ-10 списке для идеального арендатора.
- Что не будет закрыто: в этой итерации не будет закрыто требование успеха проекта - повышение конверсии, поскольку мы это пока не измеряем. Пока не выкатываем в рабочий кластер. Не собираем на REST API. Не занимаемся настройкой фронта на строне б24.
- Результат с точки зрения качества кода и воспроизводимости решения: в данный момент рабочая тетрадь юпитера, в котором подняты первичные данные и сделана МЛ, способная делать предикты для новых клиентов. Внутри комментарии касаемо сделанных шагов, как нужно обработать данные в базе и того, что нужно сделать для безотказной работы.
- Описание планируемого технического долга (что оставляем для дальнейшей продуктивизации): кастомизация пайплайна под специфику входных данных, версирование моделей и данных. Описать ограничения и требования. Определить стэк.
- Описание всех общих предпосылок решения, используемых в системе: Используем данные о сделках с гранулярностью: клиент-товар-статус сделки. Признаками выступают заполненные в сделках данные. Горизонтом прогноза выступает сделка.
- Что делаем с технической точки зрения: в V1.0 MVP - это задача классификации. В V2.0 и V3.0 - рекомендательные системы.
- Блок-схема для MVP и пилота с ключевыми этапами решения задачи.
- Этап 1 - подготовка бейзлайна.
Шаг 1. Сбор данных, отбор признаков, анализ. Скачиваем данные о сделках из CRM системы. Загружаем их в тетрадь юпитера. При отборе проверяем заполненность данных. Убираем крайне малозаполненные данные или малодостоверные. По итогу количественные признаки должны быть количественными, качественные качественными.
Целевая переменная
| Название данных | Есть ли данные в компании (если да, название источника/витрин) | Требуемый ресурс для получения данных (какие роли нужны) | Проверено ли качество данных (да, нет) |
|---|---|---|---|
| Статус сделки (успешная или проваленная) | CRM.Сделки | DE | + |
Признаки:
| Название данных | Есть ли данные в компании (если да, название источника/витрин) | Требуемый ресурс для получения данных (какие роли нужны) | Проверено ли качество данных (да, нет) |
|---|---|---|---|
| Менеджер | CRM. Айди менеджера | DE | + |
| Размах компании со слов клиента или по мнению менеджера | Лид.Размах компании | DE | - |
| Чем занимается арендатор | Компания/лид.Чем занимается | DE | - |
| Минимальная площадь аренды со слов клиента | Компания/лид.Площади от | DE | - |
| Максимальная площадь аренды со слов клиента | Компания/лид.Площади до | DE | - |
| Площадь вакантного помещения | Товар свободный.Площадь | DE | + |
| Прайс цена вакантного помещения за аренду в месяц | Товар свободный.Цена за всё помещение | DE | + |
| Сколько клиент в принципе может платить аренды | Лид.Цена за всю площадь-максимум, руб. | DE | - |
| Приоритетный берег для аренды со слов клиента | Лид. Какой берег интересует? | DE | - |
| Какой район интересует интересует клиента с его слов | Лид. Какой район интересует? | DE | - |
MVP: тетрать юпитера с загруженными признаками.
Шаг 2. Обработка данных, подготовка к обучению.
- Количественные признаки: Чистим данные от выбросов, заполняем пропуски, шкалируем.
- Качественные признаки: заполняем пропуски как фиксированный вариант. Приводим в вид OHE. Учитываем то, что клиенты занимаются несколькими бизнесами, ищут помещения в нескольких районах и нескольких берегах.
- Группируем уволенных менеджеров как один менеджер
- Описание формирования выборки для обучения, тестирования и валидации: за основу берутся сделки, с подкреплённым товаром и заполненными признаками. Так как данные накопленные за разный промежуток времени, часть сделок уже не актуальна, то для пилота данные перемешаем и запустим трейн на 75% с кросс-валидацией на 5 батчах. Оставшиеся 25% будем использовать для тестирования. Идея заключается в том, что решение модели будет использоваться не для прогнозирования сделок, а для прогнозирования провалов. В этом ключе проверку модели в бою можно будет провести довольно быстро. Использовать лиды сегодняшнего дня и экспертно проверить, насколько хорошо или прекрасно модель определила злокачественные варианты. Если качество будет слабым, то проверяем данные уже тщательно и повторяем процедуру.
MVP: модель способная на введённых в streamlit данных дать ответ, в котором минимум половина предложенных вариантов может быть использована для отправки клиенту.
Шаг 3. Поиск и обучение модели с необходимым для бейзлайна уровнем метрик.
- определяем метрики качества модели: например, высокий recall, потому что нам важно не потерять качественные варианты.
- проверяем несколько моделей. Желательно штук 5-7.
- находим через гиперпараметры лучшую модель.
В случае, если в результате обучения качество модели не удаётся поднять до уровня бейзлайна необходимо провести дополнительное изучение базы данных на предмет потенциальных признаков, играющих важную роль в подборе.
MVP: тетрадь юпитера с определённой лучшей моделью и её параметрами, отвечающая заявленными критериям качества
Шаг 4. Анализ результатов. Проверка значимости признаков.
- Интерпретации результата: Проверка на адекватность. Если клиент снял помещение 40 м2, хотя искал 100-200 - это должно игнорироваться моделью. Если большинство пекарен снимают помещение с ценой до 40000 рублей, то помещение с ценой 80000 будет помечаться скорей отрицательно.
MVP: обученная модель соблюдает бизнес-логику
Шаг 5. - Развертывание ИММО согласно бизнес требованиям заказчика. Готовим стэк согласно требованиям заказчика, переносим туда наш бейзлайн и добиваемся того, чтобы модель могла исполняться согласно заявленной логике. Настраиваем интеграцию с тестовой базой, разворачиваем интерфейс, настраиваем пайплайны, редактируем базу данных.
- Описание техники достижения поставленных бизнес-требований: Для улучшения скорости в систему МЛ периодически (надо решить как часто) фоново попадают обновления базы данных Товаров и Менеджеров и все остальные необходимые данные. Таким образом пакет данных из боевой базы уменьшается кратно и отправляются только данные о Клиенте и ID менеджера. Пересчёт эмбедингов делать чаще раза в месяц не эффективно, так как бизнес-цикл происходит на этом промежутке. В ответ МЛ должна давать батчи с парой Товар-Класс, который на стороне боевой базы используется как фильтр предложений.
Проверяем выбранные прокси-метрики:
- % созданных сделок, которые наша модель разметила как негативные. Бейзлайн = 50%.
- % успешных сделок, которые наша модель разметила как негативные. Бейзлайн = 50%.
- % неверно убранных предложений на 10 рандомных лидах в неделю проверенные экспертом. Бейзлайн = 50%. Если подходит 15 из 100, то модель должна ошибочно негативно разметить не больше 8 из них. 8/15 = 53%.
MVP: модель работает с тестовой средой с заявленным качеством согласно бизнес-требованиям.
Шаг 6. - Считаем системные требования к модели. Проводим расчёт вычислительной мощности необходимой для работы системы. Заполняем 4-й раздел дизайн-дока.
MVP: составлены системные требования для модели
Этап 2. Создание пилота.
Шаг 7. - Утверждение метрик пилота. Определяем финальные метрики, прокси-метрики и технические метрики, при достижении которых модель будет запущена в деплой. Цели подтверждает заказчик, дата-саентист и дата-инженер.
MVP: определены целевые метрики на основании имеющихся данных и согласованные с бизнесом
Шаг 8. - Подготовка модели к деплою. Проводим обогощение модели данными, улучшаем предобработку и подбор параметров модели до тех пор, пока не удастся достичь заявленные цели.
MVP: модель, удовлетворяющая заявленным метрикам
Шаг 9. - Деплой. Выкатываем модель в рабочую среду и проводим тестирование на достижение метрик и отказоустойчивости согласно требованиям.
Неверная интерпретируемость данных: проверка данных Низкое качество модели: добавление признаков Недостающие ресурсы: купим
- Краткое описание предполагаемого дизайна и способа оценки пилота: проверяем модель на 10 клиентах. Проводим оценку % потерянных предложений. Считаем какое количество предложений на мнение эксперта подходили клиенту и смотрим, какое количество из них система отметила как неподходящие.
Формализованные в пилоте метрики оценки успешности: При потере не более 3 из 15 (FN = 20%) вариантов модель считаем успешной.
- Блок схема и пояснения: сервисы, назначения, методы API
Data Scientist: попробуем на Docker сделать. ML как сервис. Через API запросы идут. Но на данном этапе делаем тетрадку юпитера с импортом данных из csv.
- Какая инфраструктура выбрана и почему
Data Scientist: надо изучить варианты. Пока никакая - Плюсы и минусы выбора
Data Scientist: - - Почему финальный выбор лучше других альтернатив
Data Scientist: -
- SLA, пропускная способность и задержка
Data Scientist: -
- Потенциальная уязвимость системы
Data Scientist: тут могу сказать, что всё может не заработать из-за того, что данные очень растянуты по времени и в идеале обучение делать не на старых данных, а на срезе данных. Какие были помещения в момент заключения сделки кроме сданного помещения. С точки зрения используемого программного обеспечения или устарения данных, то риски пока оценить сложно, да и возможно не нужно.
- Нет ли нарушений GDPR и других законов
Data Scientist: нет
- Расчетные издержки на работу системы в месяц
Data Scientist: минимальные. Если используем только открытый код, то кластер у нас есть, его ресурсов должно хватать для пилота
- Описание взаимодействия между сервисами (методы API и др.)
Data Scientist: пока не известно
- Описание рисков и неопределенностей, которые стоит предусмотреть
Data Scientist: пока не известно
- Шаблон ML System Design Doc [EN] от AWS и статья с объяснением каждого раздела
- Верхнеуровневый шаблон ML System Design Doc от Google и описание общих принципов его заполнения.
- ML Design Template от ML Engineering Interviews
- Статья Design Documents for ML Models на Medium. Верхнеуровневые рекомендации по содержанию дизайн-документа и объяснение, зачем он вообще нужен
- Краткий Canvas для ML-проекта от Made with ML. Подходит для верхнеуровневого описания идеи, чтобы понять, имеет ли смысл идти дальше.