Вступление

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

Инновации также играют решающую роль в успехе команды Data Science в Telegraph. Группа отвечает за определение областей бизнеса, в которых может быть полезно прогнозное моделирование, а также расширенные аналитические данные и рекомендации на основе данных.

В соответствии с этими ожиданиями, одной из областей бизнеса, которая с 2019 года получает выгоду от такого прогнозного моделирования в больших масштабах, является тираж Telegraph. Как объяснялось в нашей предыдущей статье, работа по оптимизации тиража печатных изданий в Telegraph началась до 2019 года. С тех пор были разработаны и протестированы различные решения, позволяющие максимизировать продажи газет при минимальном количестве непроданных копий, отправляемых розничным торговцам каждый день по всему миру. Объединенное Королевство.

Оставление непроданных экземпляров газеты в магазинах в конце дня связано с расходами, которые зависят от продукта и дня недели. Следовательно, два вышеуказанных бизнес-КПЭ, то есть максимизация продаж газет при минимальном количестве непроданных копий, могут быть объединены в единую цель оптимизации для нашей системы машинного обучения, то есть максимизацию прибыли от тиража. По сути, наша система пытается найти правильный баланс между спросом и предложением (затраты на потерю продаж против затрат на то, чтобы в итоге у каждого продавца остались непроданные копии), чтобы максимизировать прибыль, отойдя от моделей максимальных продаж при любых затратах.

Наша устаревшая система

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

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

Системная сложность

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

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

Этот подход, также известный как «Рекурсивное многоэтапное прогнозирование», представлен ниже для задачи создания прогноза на 3 шага вперед.

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

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

Таким образом, при модернизации системы была выявлена ​​необходимость снижения ее сложности без снижения производительности.

Ручное управление супервизором

Наша унаследованная система изначально была разработана с учетом полностью автоматизированной доставки прогнозов оптовикам Telegraph. Однако из-за характера бизнеса были случаи, когда требовалось ручное пополнение (повышение / изменение регионального или оптового уровня). Кроме того, иногда требуется переопределение предложения на уровне продавца, поскольку розничные торговцы могут запросить определенный уровень фиксированного предложения в определенные дни недели.

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

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

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

Наша модернизированная система

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

Прямое прогнозирование на несколько шагов вперед

Одним из основных изменений в модернизированной системе оптимизации циркуляции является переключение стратегии прогнозирования с «рекурсивной» на «прямую». Это означает, что наша современная система способна делать прогнозы сразу на несколько дней вперед. Мы смогли обеспечить выполнение требований к предварительному планированию печати при любых условиях, установив достаточно длинное окно с шагом вперед (достаточная длина выходной последовательности). Ниже приведен пример прогноза на 3 шага вперед, выполняемого этой стратегией прогнозирования.

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

Нейронная сеть от последовательности к последовательности

Самое большое изменение произошло в ядре системы - архитектуре нейронной сети. Мы разработали новую архитектуру, чтобы принимать исторические последовательности продаж вместе с их изменяющимися во времени и не зависящими от времени метаданными (типы розничных продавцов, местоположения, праздники и т. Д.) И выводить последовательность оптимальных (прибыльных) поставок на несколько дней в будущем. Это также можно было бы описать как многомерную сеть прогнозирования с несколькими шагами вперед.

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

Это не только устраняет необходимость поддерживать отдельную логику для управления несколькими нейронными сетями и прогнозирования на несколько дней вперед, но также упрощает развертывание ее как единого API с легко обновляемой базовой сетью.

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

Наша задача оптимизации очень невыпуклая; то есть максимизация прибыли от продаж среди всех розничных продавцов Telegraph по всей Великобритании с различными характеристиками, объемами продаж, сезонностью и тенденциями. Следовательно, разработка архитектуры нейронной сети была одной из основных задач этой новой последовательности для последовательной сети.

В последние годы Transformer Networks оказались чрезвычайно успешными в последовательном моделировании, особенно в случаях использования обработки естественного языка (NLP). Мы решили разработать архитектуру на основе трансформатора для прогнозирования многомерных временных рядов вместо последовательностей слов и букв.

Хотя мы не будем вдаваться в подробности архитектуры сети и блоков в этой статье, окончательная сеть основана на сети, представленной в исходной статье трансформаторов Внимание - это все, что вам нужно (Vaswani, et al., 2017 ). Однако в исходную сеть были внесены различные изменения, чтобы адаптировать ее для прогнозирования временных рядов. Эти изменения включают, но не ограничиваются этим, удаление встраивания слов, замену исходного позиционного кодирования нашим настраиваемым слоем последовательного кодирования и преобразование выходных данных декодера из вероятностей в линейные.

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

Распределенное обучение

Перед обучением наши модули сбора и предварительной обработки данных подготавливают и сохраняют наши данные обучения и проверки в сериализованном формате TFRecord (с использованием protobuf) в Google Cloud Storage. Мы разработали предварительную обработку таким образом, чтобы тот же модуль можно было использовать позже для подготовки данных в реальном времени для ежедневного прогнозирования, что упростило общий подход и позволило избежать ошибок в будущем.

Файлы TFRecord обеспечивают параллельный приток данных во время обучения с использованием API tf.data от TensorFlow. Это позволяет нам оптимизировать использование CPU, GPU и минимизировать время их простоя, что значительно ускоряет процесс обучения. Кроме того, это позволяет нам пакетами считывать данные непосредственно из облачного хранилища и передавать их в нейронную сеть во время обучения. Следовательно, не будет необходимости загружать полные обучающие данные в ОЗУ, что фактически предоставит нам бесконечные накладные расходы на размер обучающих данных. Это особенно полезно для этого проекта, поскольку нам доступны терабайты исторических данных обучения.

Процесс обучения в нашей сети проходит на Google AI Platform. Снимки наших обучающих сценариев и файлы архитектуры модели изначально загружаются в Google Cloud Storage. Затем платформа Google AI инициирует процесс обучения с помощью нашего учебного скрипта.

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

«Зеркальная стратегия» просто создает реплику для каждого графического процессора на устройстве, на котором выполняется обучение. Затем каждая сетевая переменная зеркально отражается во всех этих репликах, образуя единую концептуальную переменную, которая называется «Зеркальная переменная». Применяя идентичные обновления, эти переменные всегда синхронизируются друг с другом. Чтобы передать эти обновления переменных на все устройства, используются алгоритмы полного сокращения, которые значительно сокращают накладные расходы на синхронизацию чрезвычайно эффективным способом.

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

Обученная сеть может затем использоваться в качестве API в разделе «модели» платформы Google AI. Это позволит нам просто отслеживать запросы, время ответа и общую производительность нашего API прогнозирования без ручного кодирования API.

Контрольный лист

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

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

Это потребовало от нас написать нашу собственную логику для эффективного взаимодействия с Google Sheets API и иметь возможность быстро и параллельно загружать большие объемы данных на несколько вкладок. Наличие собственных функций управления листами обеспечивает бесперебойную работу нашего ежедневного прогноза и процесса связи с оптовиками, и на него не могут повлиять задержки в адаптации сторонних пакетов к новым обновлениям API Google Таблиц.

Наш контрольный лист содержит четыре основные категории вкладок, которые кратко описаны ниже:

  • Вкладки изменения: для ввода периодических пополнений в процентах или по объему для каждой области или оптового продавца и для импорта объемов, запрошенных розничным продавцом.
  • Вкладка «Сводка»: для отображения сводной информации о прогнозируемых объемах до и после изменений для каждого оптовика и за день вперед, а также прогнозируемого влияния изменений на прибыль в этом конкретном регионе или за день.
  • Вкладки прогнозов: для отображения прогнозируемых запасов на уровне продавца на все доступные дни в будущем (до максимальной длины последовательности в сети, т. е. на 14 дней вперед).
  • Вкладка «Процесс»: запуск функции для применения запрошенных изменений и создания новых прогнозов, вкладок прогнозов и вкладок сводки. Также для запуска прогнозов пакетов и функции электронной почты.

Функции применить изменения или упаковать и отправить электронное письмо в контрольной таблице на самом деле являются функциями Google Apps Script, которые запускают запуск соответствующего модуля в Google Kubernetes Engine (GKE). Каждая функция также сохраняет снимок примененных изменений для будущего анализа и анализа влияния на прибыль.

Облачная Архитектура

Каждый компонент и модуль нашей модернизированной системы либо развернут, либо работает на Google Cloud Platform. Сюда входят необработанные данные, сценарии предварительной обработки, генераторы данных обучения и проверки, API обученной сети, сценарии для получения ежедневных прогнозов от API и их последующей обработки, сами прогнозы после обработки и, в конечном итоге, контрольный лист и его соответствующие функции. .

Основными компонентами Google Cloud Platform, которые широко используются в проекте, являются следующие:

  • Облачное хранилище Google
  • Google Cloud BigQuery
  • Платформа Google AI
  • Google Cloud Composer
  • Google Kubernetes Engine

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

Выводы

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

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

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

Давуд Ардали - ведущий специалист по анализу данных в The Telegraph. Следуйте за ним в LinkedIn и Twitter.