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

Как я прокомментировал предыдущий пост, я работаю в разведывательной логистической компании под названием www.simpliroute.com, где одной из областей, на которых я сосредоточен, является машинное обучение в конце-2-конце конвейера (сбор данных, очистка , обучение, развертывание и переобучение).

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

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

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

Первые решения для машинного обучения и большие данные в реальных условиях

Для достижения цели обучения модели машинного обучения с исторической базой, превышающей 7000 миллионов GPS (с ежедневным потреблением, превышающим 15 миллионов пингов) и объемом, превышающим 1 ТБ, непростая задача для получения статистики, анализа данных и чтобы очистить их, все это в непрерывном потоке GPS (через pubsub-dataflow-bigquery), хранящемся в bigquery.

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

По имеющимся данным были построены следующие модели:

  • Тензорный поток
  • RandomForest
  • XgBoost
  • Линейная регрессия (базовая линия)

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

Вскоре будет опубликована статья, которая инициировала это решение.

Оценка и прогнозирование времени в пути с использованием данных GPS, разработанных Хавьерой Моралес Бенца, Кристианом Кортесом, Виктором Гонсалесом и Альваро Эчеверрией.

А большие данные?

Задача непростая. Работа с 3 ТБ ОЗУ в распределенных системах с контролируемым бюджетом — задача, требующая опыта и внимательности (рассчитывается на основе dataproc с помощью mllib), особенно когда ваши модели обрабатывают только выборки, а набор данных не знает временных рядов, сгенерированных приём GPS.

Были приняты решения для следующего этапа, и все они были достигнуты путем создания аналитики, конвейеров очистки данных и большого количества анализа больших запросов (метод проб и ошибок играет ключевую роль в стоимости здесь). Было обработано около 2,5 петабайт, пока не было найдено решение, которое позволило нам создать конвейер (5 этапов, организованных с помощью bigquery и Google Composer), включая создание географических полигонов на основе широты и долготы GPS и частичный анализ выбросов в нашем наборе данных.

После организации создания нашего окончательного набора данных начинается наша работа по обучению набора данных с примерно 4000 миллионами регистров (около 1 ТБ).

Мы выбрали несколько способов, которые я прокомментирую,

  • машинное обучение Bigquery
  • Вершина
  • Кубефлоу
  • Искра + Коалы + Mllib + PySpark
  • Тензорный поток
  • XgBoost

Что мы узнали,

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

Большой запрос

Было выбрано в качестве хорошей практики выбор пути automl bigquery ml, потому что было легко создать базовый уровень для метрик, после чего немного гиперпараметризации и попытки развертывания в продуктивных средах (это процесс, в котором мы сейчас живем). После того, как пройденный путь освежает, чтобы получить прогнозы на основе нашего набора данных. Менее чем за 30 минут мы создаем 2 модели с разными параметрами и прогнозируем почти чудесным образом.

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

Вершина

Наши тесты с Vertex не были действительно удовлетворительными. Выполнение этого типа automl, несмотря на наличие полностью разработанного набора данных, на самом деле не помогло. Мы много раз тренировались более 10 часов, было создано несколько наборов данных размером менее 100GP (значительно меньше нашего реального набора данных).

Кубефлоу

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

Экосистема искры

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

Теперь, благодаря управлению и поддержке со стороны технического директора option, мне удалось немного больше внедрить экосистему Databricks, которая включает в себя решения на основе Spark, такие же, как dataproc, но с огромной экосистемой для решений для хранилищ данных, машинного обучения и Mlops. Хотя это предполагает большие затраты на инфраструктуру и тем более на обучение.

Ноутбуки — Kubernetes — Кластеры

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

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

Kubernetes с HPA или Managed Instances оставил у нас похожие ощущения. Слишком много ресурсов и частичных решений и слишком много экспериментов с mlflow (цена этого инструмента). Я не хочу слишком много анализировать, но нам не удалось обучить полный набор данных.

Выводы

Обучение машинному обучению в области больших данных использует много ресурсов от анализа данных до продуктивной модели. В этом посте не рассматривались Mlops (в идеале с Kubeflow, Mlflow или Kedro), равно как и процессы генерации артефактов, жизненный цикл данных, мониторинг и т. д. Я хочу сказать, что нет фиксированного рецепта того, как направлять или управлять ML. проекты. Многие компании отказываются от использования Data Driven / AI Ready / Predictors. То, что мы узнали, оставило нам 3 вещи, которые я хотел бы обобщить.

  • Все роли важны. Data Scientist, Data Engineers, AI/ML Engineers, MLops и Software Engineers. У каждого есть своя роль, и часто мы забываем, что это дисциплина, которая включает в себя так много знаний, что трудно найти кого-то, кто обладает знаниями и понимает каждую экосистему, инструмент и язык программирования. (Если вы это сделаете, будьте осторожны)
  • Чтобы решить проблемы ML, мы должны начать с простого: грязный набор данных в BigQuery ML (или любом инструменте automl), чтобы сгенерировать базовый уровень, запустить его в производство, отслеживать и через несколько недель проверить, решает ли модель проблему или нет (и если его можно улучшить или нет). Или сложные эвристики — решение проблемы (возможно, вам стоило сделать это перед уходом из машинного обучения)
  • Чтобы выбрать путь или философию. К сожалению, существует множество способов решения проблем с большими данными и машинным обучением, будь то автор, облачный провайдер, провайдер машинного обучения, исследования, самообучение, обучающее видео или предыдущий опыт. Не существует идеального и повторяемого рецепта. Мы все еще на начальных этапах и учимся по ходу дела. Выберите путь, повторите и запустите эту модель в производство, а затем оцените, можно ли ее улучшить.