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

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

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



Есть ли способ быстро найти «модель по умолчанию», на которую мы могли бы ссылаться? Абсолютно!

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

Есть ли какие-либо лучшие варианты моделирования, которые не были рассмотрены?

«Всегда найдется рыба покрупнее» [Квай-Гон Джинн], или, как в нашем случае, модель, которая могла бы просто работать лучше, чем наша реализация. С учетом сказанного, даже если мы не сможем найти лучшую модель, это полезно знать, не так ли? Здесь я хотел бы представить AutoML. Несмотря на то, что во вселенной науки о данных существует множество различных реализаций «AutoML», я рассмотрю простой метод «оплата по мере использования», который не подвергает нас бесконечным циклам настройки.

Я рассмотрю следующий рабочий процесс, чтобы (1) построить модель локально и (2) посмотреть на эталонный тест модели, полученный с помощью реализации AutoML в Google:

Local Setup:
1. Defining a dummy dataset
2. Train a model and tune hyperparameters (cross validation)
Cloud Setup:
3. Upload a dataset Google's Vertex AI (bucket)
4. Set up Vertex AI and build a model through AutoML
5. Compare performance

Пример набора данных в этой статье относится к задаче регрессии. Если основная проблема аналитики — это задача классификации, вы можете найти вдохновение здесь:



Создание простого фиктивного набора данных

Для этого эксперимента я использовал возрастающие значения X1 и X2 (оба в интервале [0, 1]), которые объединяются вместе в переменную отклика Y — , где Y определяется как:

Y = 100 * [ max(e^y1, e^y2, ..) / sum((e^y1, e^y2, ..)) ]

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

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

Построение модели на локальной машине

Я решил использовать две разные модели: множественную линейную регрессию, а также gbm (машина повышения градиента).

Пример для (подправленной) модели gbm:

Как уже упоминалось, подгонка модели проста, но также требует выполнения настройки гиперпараметров, подобной «сетевому поиску», для получения наиболее разумных результатов. Это не касается модели линейной регрессии, однако gbm имеет множество гиперпараметров, которые можно изменить (например, n.trees, параметр сжатия, minobsinnode).

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

Учитывая описанную выше настройку модели, gbm смог спрогнозировать при RMSE 1,11568, что кажется низким значением, учитывая среднее значение приблизительно 50 для всех ответов Yi. Линейная регрессия привела к RMSE 3,1846, что значительно больше, но, как и ожидалось, учитывая нелинейную форму данных ответа.

Теперь возникает интересный вопрос: "Как модель gbm сравнивается с эталонной моделью, подобранной с помощью AutoML?"

Эталонная модель

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

Для начала нам необходимо загрузить или «создать» набор данных прямо в облачной консоли, сохранив данные в корзине. Тип данных находится в «табличном» формате (который представляет собой файл csv), а задача, которую мы хотим выполнить, — это задача регрессии.

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

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

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

После того, как модель остановилась (из-за бюджетных ограничений или из-за сходимости модели), метрики конечного результата можно наблюдать следующим образом:

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

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

Сравнение и заключение

В этом примере мы видим, что результаты локальной модели (gbm) и модели AutoML очень близки, хотя AutoML работает немного лучше. Означает ли это, что мы должны отказаться от нашей подогнанной модели? Скорее всего нет.

  1. AutoML потребовалось более 1,5 часов, чтобы получить разумный результат, в то время как локально подобранная модель gmb заняла всего около 20 минут (включая процедуру поиска по сетке для настройки гиперпараметров).
  2. Разница в RMSE составляет около 0,02, что является отличным результатом для нашей модели, а также указывает на то, что мы находимся на правильном пути и можем даже улучшить его, введя большее количество возможных гиперпараметров (например, увеличив глубину взаимодействия повышающей модели).
  3. Затраты и выгоды: победитель не может быть более очевидным. Если вас интересует стоимость модели, не стесняйтесь загуглить ее, но одно можно сказать наверняка: облако совсем не дешевое.
  4. Создание прогнозов требует усилий по развертыванию и интеграции облачной модели, в то время как локальная модель готова к прогнозированию, как только она будет установлена. Однако, если вы используете модель для крупномасштабной производственной среды, вы все равно можете предпочесть облачное решение AutoML.

Мои 2 цента относительно роли специалиста по данным во всем этом:

Уничтожает ли AutoML профессию Data Science? — Скорее всего нет.

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

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

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

{Позаботьтесь о себе, и, если можете, о ком-то еще}

— позаимствовано у Стивена Дабнера