ОБЛАЧНЫЕ СРЕДСТВА ДЛЯ ОБУЧЕНИЯ АВТОМАТИЧЕСКИМ МАШИНАМ (ЧАСТЬ 1)

Уроки, извлеченные с помощью Google Cloud BigQuery ML

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

Мотивация

Я часто слышу новое модное слово «демократизировать ИИ для масс». Обычно далее следует предлагаемый инструмент облачного машинного обучения. Общий термин для этих инструментов, кажется, AML или автоматическое машинное обучение. Мне, как специалисту по анализу данных, было любопытно изучить эти инструменты. У меня возникают вопросы: что на самом деле может AML? Могу ли я использовать эти инструменты в моем обычном рабочем процессе моделирования? Если да, то как и для чего? Исчезнет ли скоро моя полезность как человека с навыками машинного обучения?

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

В моей работе недавно мне нужно было создать и развернуть модели обнаружения финансового мошенничества. Я не могу использовать частные данные в общедоступном блоге, поэтому я собираюсь использовать хорошо известный общедоступный набор данных German Credit Data. Обратите внимание, что матрица стоимости составляет 5 DM за ложный отрицательный результат и 1 DM за ложный положительный результат. Несмотря на то, что данных мало, я буду использовать те же методы, что и для реальных данных. Код для всех демок будет у меня на гитхабе.

Мой план состоит в том, чтобы охватить эти популярные инструменты AML:

Надеюсь, скоро (!) Выйдут части 2, 3, 4:

BigQuery ML - Шаг 1) создайте данные

Давайте начнем. BigQuery от Google предлагает ряд бесплатных общедоступных наборов данных. Вы можете искать их здесь. Я не видел никаких кредитных данных, поэтому я использовал песочницу Google BigQuery, чтобы загрузить свою. Песочница BigQuery - это облачная SQL-база данных бесплатного уровня GCP от Google. Это бесплатно, но ваши данные хранятся не более 60 дней.

Для всех инструментов Google Cloud сначала необходимо создать учетную запись Google Cloud и проект. Затем назначьте проекту ресурс Sandbox следуйте этим инструкциям. Теперь перейдите на https://console.cloud.google.com/bigquery, это веб-интерфейс. Затем закрепите свой проект с песочницей (см. Снимок экрана ниже слева). Затем загрузите данные с помощью веб-интерфейса. Я назвал свою таблицу allData.

Немецкие кредитные данные - это очень маленький набор данных, всего 998 строк. Обычно лучшая практика - разделить ваши данные на тренировку / валидность / тест, но, поскольку это настолько мало, я собираюсь разделить на тренировку / тест 80/20 и использовать технику перекрестной проверки, чтобы растянуть поезд на поезд / действителен. Примечание: я создал поддельный столбец uniqueID (см. Снимок экрана внизу справа), чтобы помочь со случайным разделением.

Вот SQL, который я использовал для создания «trainData» и «testData» в виде произвольно выбранных строк из «allData».

CREATE TABLE cbergman.germanCreditData.testData AS
SELECT *
FROM `cbergman.germanCreditData.allData`
WHERE MOD(ABS(FARM_FINGERPRINT(CAST(uniqueID AS STRING))), 5) = 0;

CREATE OR REPLACE TABLE cbergman.germanCreditData.trainData AS
SELECT *
FROM `cbergman.germanCreditData.allData`
WHERE NOT uniqueID IN (
  SELECT DISTINCT uniqueID FROM `cbergman.germanCreditData.testData`
);

Теперь мои таблицы загружены в BigQuery с 199 и 798 строками соответственно. Убедитесь, что случайная выборка поступила правильно:

SELECT count (distinct uniqueID)
FROM `cbergman.germanCreditData.allData`
where response = 2;

# repeat for train, test data...

См. Нижнюю строку ниже, я получаю отношения отрицательного (ответ = 1) к положительному (ответ = 2) как 30%, 29%, 32% для наборов данных All / Train / Test, что выглядит хорошей выборкой:

BigQuery ML - Шаг 2) обучение модели машинного обучения

На момент написания этого API предоставляет вам на выбор 3 алгоритма: регрессия, логистическая регрессия или K-ближайших соседей.

Обновление в декабре 2019 года: с момента написания этой статьи Google добавил в BigQuery ML 2 новых алгоритма: многоклассовая логистическая регрессия и Tensorflow!

Перед созданием модели обычно необходимо: 1) убедиться, что бизнес-цели ясны: «Постарайтесь автоматически поймать как можно больше мошеннических денег». В моей работе деньги от мошенничества подразделяются на типы мошенничества, например: Третья сторона. 2) Затем вам обычно нужно преобразовать это в алгоритм математической модели: в этом случае классификация, поэтому выберите метод API Логистическая регрессия. 3) Затем вы определяете функцию потерь, что в реальной компании сложно, поскольку один отдел может сказать, что новые пользователи более важны; в то время как отдел рисков говорит, что мошенничество важнее. Например, в одной компании, в которой я работал, они не могли согласовать единую метрику потерь. Однако здесь эта проблема решена, создатели этих общедоступных данных дали матрицу стоимости 5 немецких марок за ложноотрицательный результат и 1 марку за ложноположительный результат.

После того, как бизнес-определения сделаны, см. Снимок экрана ниже, где показано, как можно обучить базовую модель, выполнив запрос SQL из редактора запросов. В разделе «Сведения об обучении» потери на итерацию уменьшаются, чего мы и ожидали; и поскольку это логистическая регрессия, потеря - это потеря журнала.

Ниже приведен SQL-код для создания модели и проверки соответствия модели на данных поездов и испытаний.

# Create the base model
CREATE OR REPLACE MODEL cbergman.germanCreditData.baseModel OPTIONS(input_label_cols=['response'], model_type='logistic_reg') AS 
SELECT * EXCEPT (uniqueID) 
FROM `cbergman.germanCreditData.trainData`;
# Model fit on train data
SELECT *
FROM ML.EVALUATE(MODEL `cbergman.germanCreditData.baseModel`, 
(
  SELECT * EXCEPT (uniqueID)
  FROM `cbergman.germanCreditData.trainData`);
# Model fit on test data
SELECT *
FROM ML.EVALUATE(MODEL `cbergman.germanCreditData.baseModel`, 
(
  SELECT * EXCEPT (uniqueID)
  FROM `cbergman.germanCreditData.testData`);
# To view your linear beta-values
SELECT * from ML.WEIGHTS(MODEL cbergman.germanCreditData.baseModel);
# To get test data confusion matrix
SELECT *
FROM ML.CONFUSION_MATRIX(MODEL `cbergman.germanCreditData.baseModel`,
(
  SELECT* EXCEPT (uniqueID)
  FROM `cbergman.germanCreditData.testData`);

Моя базовая логистическая регрессия тренировалась за 1 минуту 36 секунд, выполнялась на тесте за 0,7 секунды, с ROC_AUC для поезда = 0,84, тестом ROC_AUC = 0,75, отзывом = 0,41 и стоимостью 38 * 5 + 12 = 202 DM.

Я заметил, что AUC поезда была 0,84, поэтому произошло небольшое переоснащение. Я не удивлен, поскольку были использованы все переменные (SELECT *), а логистическая регрессия - это линейная модель, которая требует, чтобы все входные данные были независимыми. Часть создания базовой линейной модели - это очистка коллинеарных входных данных. Я знаю, как это сделать в Python, так что к этому я обращусь позже.

Между тем, мы можем проверять и сохранять бета-значения для коэффициентов модели логистической регрессии и матрицу неточностей для показателей удержания и производительности в данных проверки удержания. Примечание: если вы не укажете иное, порог по умолчанию будет 0,5. Я вычислил нормализованную и ненормализованную матрицу путаницы по умолчанию и сохранил их в таблице сравнения моделей (я сделал резервную копию таблиц коэффициентов и статистики производительности в Google Таблицах, очень простую навигацию по меню в WebUI, так как я осознаю, что мои бесплатные данные исчезнут в 60 дней).

Шаг 3) Разработка функций

Далее следует секретный соус от опытного практикующего специалиста, как получить лучшую модель. Сейчас я перехожу на Блокнот Jupyter, так как я знаю, как очистить коллинеарные входные данные в Python. Сначала я проверяю корреляции для числовых столбцов. Ниже в выделенном красном поле справа мы видим, что количество и продолжительность коррелированы на 63%. В этом есть смысл, сумма и продолжительность займа, вероятно, увеличиваются вместе, мы можем подтвердить это на парных графиках (меньшие участки, обведенные красным контуром слева). Ниже в нижнем ряду показаны все числовые переменные, построенные по парам в сравнении с ответом 1 или 2, явно ничего не связанного. Я оставлю поле "Продолжительность".

Довольно много переменных относятся к строковым категориям. Я хотел бы провести VIF-анализ строковых переменных, для этого я реализовал в Python Информационный пакет R, который иногда называют Весом доказательств с использованием информационной ценности. Идея информационного или WOE-биннинга состоит в том, чтобы выйти за рамки добавления новых переменных с помощью One-Hot-Encoding, а фактически объединить и пронумеровать категории в возрастающем линейном порядке с помощью переменной ответа. Например. если у вас есть переменная Транспортные средства с категориями автомобиль, лодка, грузовик, тогда будет выбрано преобразование в числа 1, 2, 3, представляющие автомобиль, лодку, грузовик, чтобы представить информационную выгоду, которую они дают. относительно переменной ответа. Итак, у вас будет не 1, 2, 3, а нумерация, выровненная по информационному принципу.

Я добавил пару ссылок в раздел «Ресурсы» внизу этой статьи, посвященный «информационному объединению».

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

Коэффициенты VIF указаны вверху слева. Интересно, что работа и телефон выглядят тесно связанными с точки зрения объяснения отклонений. Может быть, у безработных / нерезидентов реже есть телефоны? Другая пара дисперсия-покрытие выглядит так, будто пол связан с other_debtor. Хм, это говорит о том, что замужние / разведенные женщины с большей вероятностью будут иметь второго заявителя. Работа и телефон находятся на вершине избыточных объяснений отклонений, поэтому на основе VIF, я собираюсь опустить поле "Телефон".

Корреляции, вверху справа, теперь выглядят намного чище. Единственная проблема может заключаться в том, что n_credits на 40% коррелирует с credit_his, а недвижимость на 36% коррелирует с жильем . На основе корреляций я отброшу n_credits и property.

Таким образом, я отбросил поля duration, n_credits, property и phone и добавил преобразования журнала в вычисление числовых функций. Мои первоначальные 21 поле теперь превратились в 64 полностью числовых поля. В основном из-за добавления числовых преобразований: среднего, медианного, максимального, минимального и логарифмических преобразований. Количество полей моей категории осталось прежним из-за использования информационного биннинга вместо One Hot Encoding.

Затем я пропущу все мои преобразованные переменные через Выбор переменных Elastic Net Lasso. (Примечание: если бы меня спросили, кто мой герой ML, я бы первым ответил Тревор Хэсти!). Обычно при k-кратной перекрестной проверке наилучшей практикой является k = 10 крат. Компромисс большего количества складок состоит в том, что вы получаете больше прогонов для усреднения (k = 10) по сравнению с выборками на кратность N / k. Так как мои данные очень малы, я выбрал k = 4-кратную перекрестную проверку, чтобы у меня было 199 выборок в каждой. В итоге я получаю модель ниже.

Вверху посередине слева кривые ROC выглядят достаточно выровненными. Вверху внизу обе кривые обучения и действительные кривые Precision-Recall пересекаются около порога = 0,9, что свидетельствует об обнадеживающей согласованности. Вверху справа самый большой коэффициент был у «Текущий счет». Я могу заглянуть в подборку информации, чтобы увидеть упорядочивание A11 (отрицательный баланс), A12 (‹200DM), A13 (› = 200DM), A14 (без проверки счета) в порядке возрастания для прогнозирования получения ссуды. Мы также замечаем, что сумма и продолжительность отрицательно связаны с получением кредита. Любопытно, что «уровень профессиональных навыков», похоже, не имел большого значения для прогнозирования «хороших» или «плохих» результатов ссуды, для «неквалифицированный - нерезидент» против «неквалифицированный - резидент» против «руководства / должностного лица». Может быть, все это имеет смысл, я бы, наверное, хотел уточнить это у специалиста по предметной области.

На данный момент я придерживаюсь этой модели логистической регрессии, которая тренировалась за 3,6 секунды, выполнялась на тестовых данных за 0,5 секунды с обучением ROC_AUC = 0,81 и тестом ROC_AUC = 0,83 со стоимостью 11 * 5 + 34 = 89 DM. Мы сэкономили 50% стоимости базовой модели !! И использовало меньше переменных, с меньшим разбросом между обучением и проверкой. Очевидно, что эта модель является улучшением, и если бы мы конкурировали, мы бы попали в таблицу лидеров Kaggle, поскольку наивысший балл имеет тестовую AUC около 78%. Отлично.

После разработки функции обычно следуют следующие шаги:
1) сравнение алгоритмов
2) настройка гиперпараметров
3) настройка пороговых значений.

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

Шаг 4) Создайте конвейеры машинного обучения, использующие модели BigQuery

Возвращаясь к тому, как я мог бы использовать BigQuery в реальной жизни конвейерной обработки машинного обучения. В моей нынешней компании пользователь не ожидает немедленного ответа на свою заявку на получение кредита. Итак, мы можем использовать пакетную обработку для оценки «в реальном времени». Вот как может выглядеть мой пакетный конвейер с BigQuery:

  1. Возьмите сценарий Python для разработки функций, приведенный выше, запустите его один раз для allData.
    Конечный результат: еще одна таблица bigQuery под названием «transformedData».
  2. Разделить преобразованные данные на поезд / тест, как раньше
  3. Обучите другую модель GLM, используя перекрестную проверку, тот же процесс, что и раньше, но ограничьте ее только таблицей «trainTransformedData» (вместо «trainData») и выберите только последние функции в моей окончательной модели (вместо выберите *).
    Конечный результат: glmModel вместо baseModel.
  4. Сохраните показатели glmModelCoefficients, modelComparison как Google Sheet (более постоянный, вспомните, что уровень бесплатного пользования GCP Big Query исчезает каждые 60 дней).
    Конечный результат: еще 2 таблицы: glmModelCoeffiecients, modelComparisons (с резервными копиями в Google Sheets) .
  5. Возьмите тот же сценарий Python для разработки функций, что и на шаге 1), превратите его в пакетное задание, которое запускается каждые пару часов только с новыми данными, которые еще не были преобразованы.
    Конечный результат: другая таблица BigQuery под названием «testTransformedData» с флагом model_run = false.
  6. Делайте прогнозы в реальном времени - добавьте еще одно пакетное задание в оркестратор пакетных заданий, которое запускается каждые 1,5 часа после шага 1) выше.
    Конечный результат: все входящие новые данные получают классификацию логического вывода в пакетном режиме реального времени, который выполняется каждые 2 часов.

Шаг 6) Чтобы запустить BigQueryML, просто добавьте инструкцию SQL в сценарий Java или Python:

# SQL to run inference on new data
SELECT
  *
FROM
  ML.EVALUATE(MODEL `cbergman.germanCreditData.glmModel`, (
SELECT   'chk_acct_woe', 'credit_his_woe', 'purpose_woe', 'saving_acct_woe', 'present_emp_woe', 'sex_woe', 'other_debtor_woe', 'other_install_woe', 'housing_woe', 'job_woe', 'foreign_woe','amount_logmean', 'installment_rate_logmedian', 'present_resid_logmedian', 'age_logmedian',  'n_people_max'
FROM `cbergman.germanCreditData.testTransformedData`
WHERE model_run = false);

# Tag inferenced data so it won't be re-inferenced
UPDATE `cbergman.germanCreditData.testTransformedData`
SET model_run = true;

Резюме

Мы выполнили моделирование машинного обучения от начала до конца с помощью инструмента Google Cloud Platform BigQuery ML. Мы использовали необработанный Python, Scikit-learn, pandas, matlab, seaborn для разработки функций. Превратил это в скрипт для выполнения Feature Engineering в качестве дополнительного шага Data Engineering для создания преобразованных таблиц BigQuery. Достигнута модель логистической регрессии с ROC_AUC = 0,83 при стоимости 11 * 5 + 34 = 89 DM (что поставило бы нас в топ-10 таблицы лидеров Kaggle).

У меня сложилось впечатление, что, поскольку BigQuery ML находится прямо сейчас, вы не можете получить достойную Kaggle отличную модель без дополнительной работы по разработке функций, но вы можете получить быструю базовую модель. Google явно вкладывает ресурсы в свой продукт BigQuery ML, два новых алгоритма за последний месяц. Уже одно это говорит о том, что это продукт, на который стоит обратить внимание. Я бы сказал, что даже в том виде, в каком он есть сейчас, это инструмент AML, который стоит изучить и добавить в свой набор инструментов для практикующих специалистов по ИИ / машинному обучению.

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

Ресурсы

  1. Страницы документов BigQuery: https://cloud.google.com/bigquery/docs/
  2. Блог автора книги Google BigQuery О'рейли: https://towardsdatascience.com/how-to-do-hyperparameter-tuning-of-a-bigquery-ml-model-29ba273a6563
  3. Общий AML: https://www.automl.org/book/
  4. Мой гитхаб: https://github.com/christy/MachineLearningTools
  5. Набор данных открытого кредита: https://archive.ics.uci.edu/ml/datasets/statlog+%28german+credit+data%29
  6. Пакет R для информационного биннинга, о котором говорилось в этой статье: https://cran.r-project.org/web/packages/Information/index.html
  7. Хорошее, дополнительное объяснение информационного объединения: https://ucanalytics.com/blogs/information-value-and-weight-of-evidencebanking-case/

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

Если у вас есть какие-либо отзывы, комментарии или интересные идеи о моей статье, искусственном интеллекте или машинном обучении, не стесняйтесь обращаться ко мне через мой LinkedIn.