Заменит ли AutoML специалистов по данным?

AutoML уже скоро!

В 2018 технологические гиганты Google и Microsoft представили миру свои сервисы AutoML: Google Cloud AutoML и машинное обучение Azure. С тех пор популярность и интерес к этим услугам резко возросли. В этом сообщении блога мы рассмотрим, что такое AutoML, какие платформы доступны в настоящее время, и обсудим самый важный вопрос для специалистов по данным: заменит ли нас AutoML?

Введение в AutoML

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

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

Какие платформы AutoML доступны?

1. Google Cloud AutoML

Запущенный в 2018 году сервис Google Cloud AutoML быстро завоевал популярность благодаря удобному интерфейсу и высокой производительности. На приведенной ниже диаграмме демонстрируется производительность Google (синие столбцы) по сравнению с другими платформами AutoML.

2. Microsoft Azure AutoML

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

3. H2o.ai

H2O была движущей силой для создания масштабных моделей. Речь идет о миллиардах исков. Вы не можете сделать это с помощью стандартных готовых методов с открытым исходным кодом . - H2o.ai

Компания H2o была основана в 2012 году и предлагает как пакет с открытым исходным кодом, так и коммерческую службу AutoML под названием Driverless AI. С момента своего создания H2o получил широкое распространение в таких отраслях, как финансовые услуги и розничная торговля.

4. TPOT

TPOT (Tree-based Pipeline Optimization Tool) был разработан Университетом Пенсильвании и представляет собой бесплатный пакет Python. Несмотря на то, что этот пакет бесплатный, он чрезвычайно мощный и обеспечивает выдающуюся производительность в различных наборах данных: точность около 97% для набора данных Iris, 98% для распознавания цифр MNIST и 10 MSE для прогнозирования цен на жилье в Бостоне. (Источник: документация TPOT)

AutoML против специалистов по данным

Теперь, когда мы знаем, что такое AutoML и какие варианты доступны, мы обратимся к слону в комнате: собираются ли эти платформы заменить ученых, работающих с данными? Мы рассмотрим эту проблему с точки зрения затрат и проведем хакатон, чтобы оценить эффективность AutoML по сравнению с человеческими.

Сравнение затрат

Согласно Indeed.com, средняя годовая зарплата специалистов по обработке данных в США составляет 121585 долларов. Между тем, если компания нанимает AutoML для работы на полную ставку (40 часов в неделю, 52 недели в году), стоимость будет варьироваться от 4160 до 41 600 долларов в год, в зависимости от платформы, которую она выберет.

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

Сравнение производительности: хакатон

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

Набор данных 1: набор данных скоростных знакомств

Обзор набора данных

Этот набор данных был получен от участников экспериментальных мероприятий по быстрому знакомству. Во время этих мероприятий участники заполняли анкету, в которую входила информация о них самих и о том, что они ищут в своем партнере. Например, насколько амбициозными они оценивают себя по шкале от 1 до 10, какими видами деятельности они занимаются, насколько амбициозными вы хотите, чтобы ваш партнер был. Цель этого набора данных состояла в том, чтобы предсказать, сможет ли человек найти совпадение на основе своих предпочтений в качестве функций. Это была проблема классификации с переменной «совпадение» в качестве нашей зависимой переменной.

Предварительная обработка данных и разработка функций специалистами по данным

Чтобы получить лучшие результаты, чем платформы AutoML, нам нужно было спроектировать наш набор данных, решить проблему дисбаланса классов, разобраться с отсутствующими значениями и выполнить одноразовое кодирование для категориальных переменных. Поскольку данные были собраны в ходе опроса, мы столкнулись с проблемой отсутствия значений во всем наборе данных. Если человек не участвовал или чувствовал себя комфортно, отвечая на вопрос, они просто оставляли его пустым. Эти пропущенные значения были учтены путем вменения среднего, медианы или режима, который казался подходящим. Данные имели коллинеарность среди некоторых независимых переменных, поэтому некоторые переменные были исключены. Только 29% зависимой метки имели двоичное значение 1, в то время как другие были равны 0. Для решения этой проблемы мы использовали SMOTE (Synthetic Minority Oversampling Technique). SMOTE создает синтетические образцы из класса меньшинства вместо простого копирования данных. В частности, переменные с горячим кодированием имеют проблемы на платформе Google, потому что платформа не может сгруппировать их таким образом, чтобы извлечь значимую информацию.

Теперь мы будем использовать необработанные данные и данные, созданные с помощью функций, для анализа общей эффективности платформ Azure и Google AutoML.

Специалисты по обработке данных против платформ AutoML

Специалисты по данным: мы попробовали несколько разных моделей и пришли к выводу, что модели XGBoost и Neural Network работают лучше всего. Здесь мы смотрим на показатели AUC ROC, чтобы сравнить результаты нашей модели с моделями, созданными этими платформами AutoML. Мы получили оценку AUC ROC 0,77 с нашей моделью XGBoost и 0,74 с нашей моделью нейронной сети.

Платформы AutoML на необработанных данных. Google показал себя немного лучше, чем модель XGBoost в Azure. Google получил оценку AUC ROC 0,881, в то время как Azure получил оценку AUC ROC 0,865. Платформа Google не сообщает нам, какая модель была выбрана в качестве лучшей, поскольку эта информация считается частной. С другой стороны, Azure сообщает вам точно, сколько моделей было запущено, каковы были баллы по каждой модели и сколько времени потребовалось для обучения каждой модели.

Платформы AutoML для обрабатываемых данных. Теперь мы хотим измерить производительность нашего набора данных, созданного с помощью функций. Мы замечаем несколько вещей: производительность Google снизилась, а производительность Azure увеличилась. Как упоминалось ранее, быстрое кодирование является проблемой для AutoML Google, и платформа создана для выполнения собственной разработки функций. Следовательно, предоставление данных, спроектированных функцией, с переменными, закодированными в горячем режиме, снизило общую производительность. Производительность Azure увеличилась с 0,865 до 0,885.

Вот изображение моделей, которые Azure использовала для этого набора данных:

Вы также можете просматривать графики Precision-Recall, ROC, матрицы путаницы и графики важности функций на платформах Google и Azure:

Выводы из набора данных Speed ​​Dating:

  • Специалисты по работе с данными могут повысить ценность, предоставляя хорошо спроектированные наборы данных для платформ AutoML.
  • Azure более прозрачно сообщает, какая модель использовалась в прогнозе; Информация о создании и выборе моделей Google является собственностью компании.
  • Google плохо обрабатывает горячие закодированные переменные.

Набор данных 2: ASHRAE

Обзор набора данных

Этот набор данных был получен в результате конкурса ASHRAE Energy Prediction Kaggle, в ходе которого участникам предлагалось разработать прогнозные модели для показаний счетчиков горячей воды, охлажденной воды, пара и электросчетчиков для 1449 зданий. Данные состояли из метаданных о зданиях, включая квадратные метры, год постройки и количество этажей; тип счетчика и показания по метке времени; и данные о погоде, включая температуру воздуха, облачность, глубину осадков, скорость ветра, направление ветра в градусах и давление на уровне моря с отметками времени. Данные о погоде собирались на уровне участка ближайшей метеорологической станцией.

Предварительная обработка данных и разработка функций специалистами по данным

Отсутствующие значения в наборе данных о погоде представляли собой серьезную проблему, которую необходимо было решить, поскольку характеристики облачности и глубины осадков не содержали 50% и 35% значений, соответственно. На некоторых метеорологических участках отсутствовали все данные об облачности и глубине осадков. Чтобы преодолеть это препятствие, мы попытались интерполировать недостающие значения в характеристиках температуры воздуха, температуры росы, скорости ветра и давления на уровне моря, которые содержали очень мало нулевых значений, и использовали интерполированные данные для разработки модели прогнозирования облачности и осадков. глубина.

Мы выбрали методы интерполяции для каждой функции с использованием 10-кратной перекрестной проверки и применили их к нашим обучающим и тестовым данным. Мы запустили серию моделей для прогнозирования облачности и глубины осадков, но нам не удалось найти модель, достаточно точную для получения недостающих значений. Направление ветра было реконструировано как набор категориальных переменных по интервалам, и мы преобразовали скорость ветра в логарифмической шкале из-за его сильного отклонения вправо. Кроме того, мы создали для наших функций такие функции, как праздники, выходные и сроки задержки. В общей сложности мы создали 19 функций поверх наших 13 оригинальных, в общей сложности 32 переменных.

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

Специалисты по обработке данных против платформ AutoML

Специалисты по данным: вместо создания общей модели для всех зданий мы построили модель Light Gradient Boost для каждого здания в нашем наборе данных, поскольку обучающий и тестовый наборы содержали одни и те же здания. С этим подходом мы достигли RMSLE 0,773.

Платформы AutoML на необработанных данных. За час обучения Google Cloud достиг RMSLE 1,017; дополнительные 3 часа тренировки улучшили RMSLE на 0,011. Google легко превзошел Azure, получивший RMSLE 2,22. Это не совсем честное сравнение, поскольку мы ограничили Azure только случайными лесами, поскольку только этот метод вернет RMSLE.

Платформы AutoML для обработанных данных. Мы обрабатывали обработанные данные через Google Cloud и были удивлены, когда после 4 часов обучения Google Cloud достиг RMSLE 1,7. В ходе дальнейшего исследования мы обнаружили, что наш метод выбора функций снижает производительность AutoML, поскольку платформы AutoML будут выполнять свой собственный выбор функций. Мы снова прогнали обработанные данные через обе платформы, со всеми 32 переменными вместо 13. На этот раз производительность обеих платформ улучшилась. Google Cloud получил RMSLE 0,755 после часа обучения и RMSLE 0,656 после четырех часов, что является значительным улучшением работы специалистов по данным! Azure получила RMSLE 3,826 за один час обучения и 3,653 после четырех.

Выводы из набора данных ASHRAE:

  • Хотя AutoML - мощный инструмент для прогнозирования, он не может обрабатывать данные достаточно хорошо, чтобы постоянно превосходить человека.
  • Несколько дополнительных часов обучения могут значительно повысить производительность платформы AutoML.
  • Разрешить платформам AutoML выбирать функции за вас; в противном случае вы рискуете сильно ограничить производительность платформы.
  • Сочетание опыта специалиста по обработке данных в решении бизнес-проблем с возможностями AutoMLs по выбору функций, предварительной обработке функций, выбору модели и настройке гиперпараметров является эффективным решением для получения ценной информации и надежных результатов прогнозирования.

Заключение и основные выводы

Наконец, мы хотели бы завершить наш проект, ответив на три вопроса.

Заменит ли AutoML специалистов по обработке данных?

Ответ: НЕТ.

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

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

Когда специалисты по обработке данных могут лучше всего использовать платформы AutoML?

Здесь мы хотели бы привести несколько примеров, которые стоит рассмотреть.

  • Эффективность важнее интерпретируемости:

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

  • Скорость производства:

И Google, и Azure предоставляют удобные способы развертывания ваших моделей в производстве. Например, Google Cloud позволяет выполнять пакетное и онлайн-прогнозирование всего за несколько кликов. Это также позволяет вам развернуть вашу модель на вашем веб-сайте, используя их API. Эти функции могут позволить специалистам по обработке данных ускорить производственный процесс и сократить усилия.

  • Лучше использовать свое время:

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

Какой AutoML лучше? (Google Cloud AutoML против машинного обучения Azure)

В приведенной выше таблице обобщен наш опыт использования AutoML в Google Cloud и Azure. Здесь хотелось бы отметить некоторые детали.

  • Пользовательский опыт:

Мы столкнулись с несколькими ошибками при использовании Azure. Когда мы обучали модели на наборе данных ASHRAE (около 20 миллионов строк, 30 столбцов), одна треть наших экспериментов потерпела неудачу. Мы установили ограничение по времени обучения, чтобы обе платформы были сопоставимы, но кажется, что с обширным набором данных, таким как ASHRAE, ограничение в один час может привести к некоторым ошибкам. Однако при запуске меньшего набора данных, такого как наш набор данных Speed ​​Dating, процесс был довольно эффективным. С другой стороны, мы не столкнулись с какими-либо проблемами на платформе Google.

  • Интерпретируемость:

AutoML от Google использует собственный алгоритм глубокого обучения. Таким образом, с точки зрения интерпретируемости, лучшее, что может сделать Google AutoML, - это распечатать важность функции. С другой стороны, в Azure интерпретируемость существенно зависит от того, какую модель вы используете. Хотя не все модели в Azure более интерпретируемы, чем модель Google, она все же более гибкая. Например, если вы используете модель XGB, настроенную в Azure, вы можете загрузить модель и запустить на ней SHAP, чтобы понять, как функции влияют на выходные данные модели.

Несколько напоминаний перед тем, как вы попробуете AutoML:

  • При использовании Google AutoML позвольте платформе позаботиться о выборе функций. Как показали наши эксперименты, выбор / удаление функций перед запуском AutoML от Google для набора данных снижал производительность. Лучше всего добавить любые функции, которые, по вашему мнению, подходят к исходному набору данных, и позволить AutoML Google выбрать лучшие функции.
  • Если вы имеете дело с большим набором данных, AutoML от Google может быть лучшим выбором. Если вам необходимо использовать платформу Azure, убедитесь, что вы установили более высокий временной лимит (или не установили никакого ограничения вообще), чтобы предотвратить возможные ошибки. С другой стороны, если ваш набор данных относительно невелик (менее миллиона строк), Azure может работать лучше.
  • Назовите столбцы без пробелов. Имена столбцов с пробелами могут вызвать ошибки при загрузке набора данных на обеих платформах, поэтому убедитесь, что вы правильно называете свои столбцы! В Python рекомендуемой альтернативой пробелу является подчеркивание (_).
  • Ознакомьтесь с оценочными метриками. Ниже мы перечислили оценочные показатели, доступные на обеих платформах. Иногда вы не можете найти метрику, на которой хотите обучить модель, поэтому вам понадобится прокси-метрика. Таким образом, понимание свойств каждой метрики может быть полезным для выбора метрики оценки, а также для выбора подходящей платформы AutoML.

использованная литература

Авторы

Джозеф Чин, UT Austin MSBA ’20: [email protected]

Айфаз Говани, UT Austin MSBA ’20: [email protected]

Габриэль Джеймс, UT Austin MSBA ’20: [email protected]

Мэтью Пенг, UT Austin MSBA ’20: [email protected]