Предиктивная аналитика на пальцах

Я занимаюсь Data Science и Machine Learning в компании Redmadrobot. Нас знают в основном как разработчика мобильных приложений, но практика DS и ML в роботах тоже развита.

Например, мы делаем предиктивную аналитику: это такой класс методов Data Science, с помощью которого можно предсказать какие-то важные для клиента показатели в будущем. В этой статье я на пальцах объясню, как работает предиктивная аналитика и как именно она помогает, например, просчитать выручку и сэкономить деньги.

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

Сначала мы смотрим, какие данные уже есть у заказчика. Их еще называют внутренними данными.

У магазина обычно уже есть какие-то данные по существующим точкам: ассортимент, товарооборот, площадь торгового зала и так далее. Используя только эти данные, мы можем обучить модель и попытаться предсказать, например, выручку для каждой точки: для этого мы делим существующие данные в пропорции 70/30, обучаем модель на 70% данных, а на оставшихся 30% проверяем, насколько точно наша модель научилась предсказывать выручку для точки.

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

Что делать в этом случае? Обогащать данные, то есть дополнять то, что уже есть у клиента, внешними данными.

Внешних данных бывает огромное множество.

Погода, курсы валют, график запуска ракет SpaceX — все это внешние данные по отношению к нашему клиенту.

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

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

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

Некоторые сервисы-агрегаторы данных отдают их свободно, иногда даже в удобном формате xml или json — как, например, сервис OpenStreetMap, где можно получить географические данные об объекте. Бывают публичные базы данных, например от Google — это уже собранные большие наборы данных по различным тематикам, которые можно найти в открытом доступе и свободно использовать для обучения своей модели.

Некоторые данные находятся в открытом доступе, но их неудобно использовать. Тогда приходится парсить сайты, то есть вытаскивать данные в автоматическом режиме (до тех пор, пока это законно, конечно — но в большинстве случаев это законно).

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

В каждом случае мы решаем, насколько нам нужны эти данные, насколько они повысят точность модели и насколько это важно для заказчика. Предположим, какой-то набор данных позволит нам сделать модель на 10% точнее. Насколько это хорошо для заказчика? Сколько денег он сэкономит или получит, если предсказания нашей модели будут на 10% точнее? Стоит ли это того, чтобы покупать этот набор данных? Чтобы понимать это, нам нужно действительно много знать про клиента — поэтому на этапе понимания задачи мы задаем много вопросов про его бизнес, источники прибыли и особенности работы.

Как проверить (и доказать клиенту), что наша модель действительно имеет смысл? Что она предсказывает результат с нужной нам вероятностью?

Делим все данные, которые у нас есть, случайным образом в пропорции 80/20. С 80% мы будем работать и обучать на них модель, это наша тренировочная выборка. 20% пока отложим — они нам понадобятся позже, чтобы проверить на них модель и убедиться, что все работает. Это валидационная выборка.

Тренировочную выборку делим на обучающую и тестовую выборки (70/30). На 70% обучаем модель. На 30% проверяем. Когда точность нас устраивает — проверяем модель теперь уже окончательно, на валидационной выборке, то есть на тех данных, которые модель никогда не видела. Это позволяет нам убедиться, что модель действительно предсказывает с заданной точностью.

Как правило, точность модели на тестовой и валидационной выборке почти совпадает. Если они сильно отличаются — скорее всего, дело в данных: возможно, они были поделены на обучающую и валидационную выборки не случайным образом, либо данные неоднородны.

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

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

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

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

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

1. Веб-сервис или мобильное приложение с удобным интерфейсом, которое наглядно показывает клиенту ответ на его вопрос (например, где открывать магазин и сколько у него будет выручки).

2. Под капотом — модель, которая с заданной (и оговоренной) точностью выдает предсказания на основе имеющихся данных — внутренних данных клиента и внешних данных, которые мы приняли решение собирать и использовать в этой модели.

3. Поддержку модели, реализованную либо как постоянные доработки модели со стороны живой DS-команды, либо как встроенная функция периодического переобучения внутри самой программы. Модель поддержки выбирается в зависимости от характера данных и бизнес-задач, которую решает модель.

4. Наглядное подтверждение тому, что Data Science и Machine Learning — не просто модные технологии, а инструменты, которые помогают быстро и точно решать реальные задачи бизнеса.

#datascience #machinelearning #искусственный_интеллект #redmadrobot