Прогнозирование временных рядов с помощью LSTM и Prophet
Прогнозируйте нагрузку на электронную почту
Прогнозирование временных рядов предлагает фантастическую площадку для тестирования алгоритмов анализа данных. В конце концов, как было бы здорово, если бы можно было предсказывать будущее? Типичными наборами данных, которые используются для демонстрации алгоритмов прогнозирования, являются биржевые диаграммы, данные о продажах и метеорологические данные. Здесь мы попробуем кое-что, что более актуально для каждого онлайн-пользователя, а именно количество электронных писем, которые вы получите. Согласно статистическому отчету по электронной почте, в 2014 средний офисный работник получал 85 писем в день. Давайте попробуем сделать точный прогноз на основе ваших исторических данных о входящих сообщениях. Для этого мы рассмотрим использование LSTM и Пророка Facebook. Здесь цель состоит в том, как подготовить данные для различных алгоритмов и предоставить качественный обзор, а не точную настройку. Возможно, результаты будут существенно различаться в зависимости от количества обычных писем, которые вы обычно получаете, и, следовательно, данных, которые у вас есть для обучения.
Сбор данных
Мы начинаем с создания набора данных с нашим собственным почтовым ящиком с помощью пакета imapclient
. Отличное введение можно найти в разделе Автоматизация скучных вещей, глава 16. Мы загрузим все электронные письма за последние три года (начиная с 01 января 2016 г.) и получим тему и дату. Мы используем pandas
, чтобы преобразовать это в фрейм данных.
A total of 12738 e-mails loaded.
В моем случае теперь у нас есть 12738 электронных писем для обучения. Обратите внимание, что приведенный выше код предназначен для ящика входящих сообщений электронной почты. Если вы отсортировали электронную почту в другой папке, измените код соответствующим образом. Некоторые люди, в том числе и я, немедленно удаляют неважные электронные письма. Результатом вашей модели будет количество важных сообщений, а не фактических электронных писем. Также обратите внимание, что некоторые поставщики услуг электронной почты (например, Google) будут препятствовать подключению, заявив, что они не разрешают подключение к своей службе из «менее безопасных» приложений. Это можно включить в их настройках. В принципе, вы также можете проверить локальный почтовый ящик. Проверка пакета mailbox
может стать хорошим началом.
Исследование данных
Теперь давайте сначала проведем небольшое визуальное исследование данных и построим график количества электронных писем в час и в день. Для этого мы будем использовать pandas
и его функции resample и groubpy
. Используя аргументы sum()
и count()
, мы можем нормализовать для каждого временного интервала. Дополнительно мы используем seaborn
для визуализации.
Из данных мы можем увидеть четкую закономерность, а именно то, что распределение следует типичному графику с понедельника по пятницу с 9:00 до 5:00, при этом большинство электронных писем поступает в 10:00. Поскольку пиковое количество электронных писем в час лишь немногим превышает одно электронное письмо, не имеет смысла пытаться составить почасовой прогноз для этого набора данных. Поэтому мы постараемся спрогнозировать ежедневную нагрузку на электронную почту.
Предварительные соображения: прогнозирование непредсказуемого
Прежде чем мы углубимся в наши модели, стоит подумать о некоторых принципиальных ограничениях нашей проблемы. Возможно, моменты времени получения электронных писем в некоторой степени случайны и поэтому не могут быть предсказаны. В большинстве случаев отправители не знают друг друга; следовательно, мы можем предположить, что они статистически независимы. В качестве оценки мы можем аппроксимировать наш процесс пуассоновским, со стандартным отклонением, равным квадратному корню из его среднего значения. Приблизительно для 12 электронных писем мы ожидаем, что RMSE будет не менее 3,5 исключительно из-за случайности нашего распределения (sqrt(11.95) ~ 3.461
).
Для дальнейшего чтения я рекомендую прочитать о распределении Erlang, которое было разработано для проверить количество телефонных звонков, сделанных за определенный период.
Расчет базовой линии
Чтобы создать базовую модель, мы можем использовать справочную таблицу из исторических данных. Сколько писем я получил за определенный день в прошлом? Чтобы протестировать модель, я использую движущееся окно, чтобы создать свою таблицу поиска и вычислить разницу прогнозов на следующий день.
RMSE for BASELINE 7.39
Для базовой модели мы получаем среднеквадратичное значение 7,39, которое я считаю хорошим значением по отношению к ожидаемому среднеквадратическому значению не менее 3,5.
Прогнозирование электронной почты с LSTM
В качестве более продвинутой модели мы будем использовать нейронную сеть с долговременной краткосрочной памятью (LSTM). Отличное введение в LSTM можно найти здесь. Для нашей модели мы будем использовать размер окна 6 дней, и модель будет предсказывать седьмой день.
RMSE for LSTM 7.90
Наблюдая за потерей, мы видим, что сеть LSTM учится и становится лучше в предсказании будущих значений. Мы также можем видеть, что RMSE немного хуже, чем у базовой модели. Хотя номинальная разница невелика, действительно удивительно, насколько она близка к базовой модели. Это показывает, что сеть способна изучить структуру рабочей недели с выходными, когда вы получаете меньше электронных писем.
Еще одна вещь, о которой стоит упомянуть, заключается в том, что мы не можем напрямую сравнивать RMSE базовой линии с LSTM. Это связано с тем, что мы переместили обучающие данные для скользящего прогноза на базовый уровень, тогда как LSTM всегда видит только 80% обучающих данных. Можно также сделать это для обучения LSTM; однако это было бы намного дороже в вычислительном отношении.
Предсказание по электронной почте с Пророком
Далее мы создадим модель, используя библиотеку Prophet Facebook. Это аддитивная модель, в которой мы можем сопоставить нелинейные тренды с годовой, недельной и дневной сезонностью. Опять же, чтобы протестировать модель, мы разделим наши данные на набор для обучения и тестирования и вычислим RMSE. Подобно базовой модели, мы увеличим количество данных для подбора и рассчитаем RMSE.
RMSE for PROPHET 6.96
Согласно тесту RMSE, модель Prophet наиболее эффективна для набора данных. Давайте теперь попробуем понять, почему это так. Для этого мы строим компоненты модели, чтобы лучше понять, что делает модель. Это можно сделать, просто используя функцию performance_metrics
в нашей модели.
from fbprophet.diagnostics import performance_metrics prophet_model.plot_components(prophet_forecast)
Изучая компоненты модели Prophet, мы видим, что она может определять ключевые тенденции в данных. Общая тенденция отражает общее увеличение количества электронных писем. Еженедельная сезонность точно отображает график рабочего дня / выходных. Годовая сезонность показывает большие праздники, то есть мало писем по электронной почте в течение нового года, но увеличивается перед Рождеством. Также минимум в сентябре, который является важным праздником для страны набора данных. Поэтому понятно, почему производительность достаточно хорошая.
Собираем все вместе: прогноз по электронной почте
Наконец, мы развернем модель Prophet в качестве инструмента прогнозирования. Для этого мы снова авторизуемся на сервере IMAP и используем все исторические данные с 1 января 2016 года для обучения нашей модели прогнозирования. После обучения модели мы строим исторические данные за предыдущую неделю и прогноз на следующую неделю.
Обсуждение
LSTM и пророк Facebook предлагают простой способ прогнозирования данных электронной почты с достаточно хорошей точностью. Я думаю, что это понятно, если рассмотреть механизмы, лежащие в основе моделей. Прогноз LSTM основан на наборе последних значений, поэтому мы менее склонны к отклонениям из-за сезонности и уже учитываем текущую тенденцию.
В отличие от этого, модель пророка хорошо справляется с моделированием в качестве дополнения система и обнаружение и отображение сезонностей. Когда дело доходит до планирования будущих рабочих нагрузок или укомплектования персоналом, я считаю, что это информация, которую вы ищете. Теперь можно провести точную настройку модели.
Ключевой проблемой такого рода проблем является то, что если у вас есть только спорадические события, внутренняя случайность не будет предсказуемой.
В конечном счете, давайте не будем забывать, что у нас уже есть хорошая базовая модель, которая подчеркивает, что вам не всегда нужны сложные алгоритмы машинного обучения для моделей прогнозирования.