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

Совет №1: знай своего пророка

Prophet - отличная библиотека для определенных проблем, но она может легко уступать другим инструментам в определенных задачах. Для чего это? Пророк очень хорош для создания прогнозов для ряда, используя сами данные ряда. Это не так хорошо, когда вы хотите добавить больше функций или извлечь уроки из аналогичных серий (например, когда у вас есть несколько учетных записей с одинаковым поведением).

Способ работы с Prophet отличается от того, как вы обычно работаете с сервисами на основе нейронных сетей. Вместо того, чтобы поддерживать сериализованную обученную модель и вызывать прогнозы в реальном времени, вы фактически обучаете и прогнозируете модель за каждый вызов. По этой причине для обработки одного запроса требуется несколько ядер ЦП (достаточно около 8 ядер).

Дополнительной особенностью библиотеки является ее дизайн, который соответствует тенденциям, связанным с бизнесом (например, ежедневным и ежемесячным сезонным изменениям), в стандартной комплектации Prophet может работать не так хорошо с другими типами временных рядов (например, с радиосигналами). Если вы столкнулись с проблемой, что Prophet не оптимизирован для вас, я хочу рассмотреть NeuralProphet, DeepAR, ARIMA или другие алгоритмы, библиотеки и облачные инструменты, специализирующиеся на прогнозировании временных рядов.

Совет № 2: Создайте подклассы Пророка

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

Возможно, вместо этого вы захотите поддерживать только небольшой и конечный набор частот, таких как Ежедневно, Еженедельно и Ежемесячно. В этом случае вам может быть полезно создать подкласс Prophet-per-frequency и установить его по-разному для каждого класса:

  1. Набор гиперпараметров
  2. Пользовательские регрессоры
  3. Таможенные сезонности

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

В нашем случае ежедневные данные содержат повторяющиеся ежемесячные счета (например, ваш счет за поддержку), которые появляются в первый день каждого месяца. Кроме того, мы заметили, что данные имеют тенденцию коррелировать месяц с месяцем из-за некоторых основных режимов скидок, которые применяют Google Cloud и AWS. Мы повысили точность наших прогнозов, создав специальный объект Daily-Prophet, добавив настраиваемый регрессор для начала 1 числа каждого месяца и настроив его с настраиваемой сезонностью 30,5 дней. Мы также инициализировали метод super () этого объекта с настраиваемыми гиперпараметрами, которые мы оптимизировали для ежедневных прогнозов.

Совет № 3: Дайте Пророку достаточно ЦП и ОЗУ

Сервис Prophet можно легко поместить в контейнеры и использовать с такими инструментами, как Cloud Run Google Cloud. Однако эта библиотека, основанная на pystan, может быть очень ресурсоемкой. Мы обнаружили, что оптимальным решением с точки зрения простоты управления и производительности было развертывание службы в Cloud Run over Anthos (GKE).

Таким образом, мы смогли предоставить сервису надежные, оптимизированные для вычислений машины, которые сократили время прогнозирования на 60% по сравнению с собственным Cloud Run. Поскольку сервис использовал все ядра и оперативную память, которые мы ему предоставили, мы также ограничили каждый экземпляр Cloud Run обрабатывать лишь небольшое количество запросов параллельно, используя возможности Cloud Run и GKE для быстрого масштабирования вверх и вниз!

Совет №4: не забывайте строить сюжеты, вкладывайте больше бизнес-знаний

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

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

Совет №5. Не уверены? Выразите свою неуверенность!

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

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

В результате вы можете принять во внимание следующее:

  1. Выразите прогноз в виде серой пунктирной линии.
  2. Добавьте доверительный интервал.
  3. По возможности подумайте о замене «yhat» (предсказания) на «y» (исторические наблюдения).

Вы можете контролировать ширину интервалов, предоставляя ее в качестве параметра конструктору.

Совет № 6: используйте предварительную обработку и постобработку

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

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

Другие варианты улучшения обработки могут включать использование функции прокрутки Pandas для применения фильтров скользящего окна к результатам.

Совет № 7: ускорите вывод, игнорируя неопределенность

Prophet подбирает вероятностную модель к данным, а затем итеративно производит выборку распределения, чтобы оценить шум (и связанные с ним интервалы прогнозирования).

После выполнения некоторого профилирования выполнения в моем сервисе я обнаружил, что этот процесс выборки отвечает за довольно большую часть общего времени выполнения программы. Эта итерация выполняется много раз, пока не будет сгенерировано достаточно выборок для оценки шума. Если вас не интересуют интервалы прогнозирования, вы можете уменьшить значение параметра неопределенности_выборки до меньшего числа (даже 0) и значительно сократить время выполнения программы!

Конечно, этот совет идет вразрез с советом № 5, который говорит вам, насколько важно представить неопределенность. Я предполагаю, что разработка программного обеспечения всегда связана с компромиссами, не так ли? :)

Вот и все, ребята! Если у вас есть какие-либо комментарии, не стесняйтесь оставлять их ниже!

Гад Бенрам - старший инженер-исследователь в офисе технического директора DoiT International. Хотите работать с Гадом? Посетите нашу страницу Карьера.