Личное исследование: предсказатель великой энергии Ашраэ III

Самостоятельный пример: предсказатель великой энергии Ашрае III

Определение проблемы-

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

Определение проблемы для проблемы машинного обучения

Обзор предоставленных данных-

Данные предоставлены Kaggle.

Ссылка- https://www.kaggle.com/competitions/ashrae-energy-prediction/data

Нам предоставили 5 файлов CSV. Они описаны ниже.

1. файл train.csv со столбцами: building_id, счетчик, метка времени и показания счетчика.

2. Файл building_meta.csv со столбцами site_id, building_id, primary_use, Square_feet, year_built и Floor_count.

3. Файл weather_[train/test].csv со столбцами site_id, timestamp, air_temperature, cloud_coverage, dew_temperature, precip_depth_1_hr, sea_level_pressure, wind_direction и wind_speed.

4. Файл test.csv со столбцами row_id, building_id, счетчиком и отметкой времени.

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

Подход к проблеме машинного обучения:

Мы попытаемся подойти к этой проблеме как к проблеме регрессии.

Это так, потому что, поскольку нам предоставлены данные о потреблении энергии в момент времени t, мы попытаемся предсказать потребление энергии в момент времени t+1, прогноз потребления энергии в будущем.

Запрашиваемая метрика

Метрика, выбранная для этой задачи регрессии, представляет собой среднеквадратичную ошибку логарифмической ошибки. Он определяется как-

Где:

· «эпсилон» — значение RMSLE (оценка).

· «n» — общее количество наблюдений в (общедоступном/частном) наборе данных.

· ‘p_i’ – это наш прогноз цели, и

· ‘a_i’ – фактическая цель для ‘i’.

· ‘log(x)’ – натуральный логарифм x.

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

1.1 Загрузка данных

Сначала мы импортируем все необходимые библиотеки python/Scikit-learn в нашу систему, как показано ниже:

Затем мы загружаем все пять файлов данных в нашу записную книжку Jupyter, используя команду библиотеки Pandas «pandas.read_csv(‘file_name’)».

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

Ссылка- https://www.kaggle.com/code/arjanso/reduction-dataframe-memory-size-by-65/notebook

Этот код уменьшает потребление файловой памяти/ОЗУ и предоставляет простой способ выполнения операций с файлами и выполнения результатов.

1.2 Объединение файлов

Мы объединяем train.csv, Weather_train.csv и building_metadata.csv вместе. Также мы объединяем test.csv, Weather_test.csv и building_metadata.csv. Затем этот метод дает нам целостный подход к решению нашей определенной проблемы.

Например, мы используем команду «pandas»:

train_data.merge(weather_train,on=['timestamp','site_id'],how='left')

Мы используем эту команду для объединения файлов train_data и Weather_train в один файл на основе функций «timestamp» и «site_id», которые являются общими для обоих.

Таким же образом объединив файлы, мы получили два файла — train_data и test_data. На рисунке ниже показано, как выглядит файл данных поезда после слияния.

Теперь мы можем перейти к исследовательскому анализу данных, используя файл train_data.

2. Исследовательский анализ данных

2.1 Отдельные участки

а. метр_показания

Сначала мы строим график плотности дляmeter_reading. Это следующим образом-

Как видно, значение train_data[‘meter_reading’] огромно. Его можно рассматривать как точку выброса. Кроме того, график выглядит так, как будто все значения даны только при нулевом показании счетчика. Поэтому мы строим график путем преобразования в логарифмическую шкалу для лучшей визуализации данных.

Мы используем log1p для преобразования целевой переменной -meter_reading. Сюжет тогда выглядит следующим образом-

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

б. метр

Теперь мы строим график подсчета функции «метр» в train_data. Это следующим образом-

Здесь значения счетчика- 0: «электричество», 1: «охлажденная вода», 2: «пар», 3: «горячая вода». Мы видим, что максимальные баллы присуждаются за «электричество» в сочетании с «охлажденной водой» и «паром». Минимальные точки данных относятся к «горячей воде». Таким образом, мы преобразуем эту категориальную переменную из числовой в соответствующие переменные.

в. Изображение графика подсчета первичного_использования электроэнергии

Теперь мы изображаем график подсчета мощности категории primary_use из train_data.

Мы видим, что максимальное значение «primary_use» приходится на разделы «Образование», «Офис», «Развлечение/общественное собрание» и «Госуслуги».

д. распределение температуры воздуха

Приведенное выше распределение отображает количество распределения air_temperature train_data. Мы видим, что характеристика температуры воздуха соответствует нормальному/гауссовскому распределению с максимальным количеством значений, лежащих в диапазоне от 0 до 30 градусов. Цельсия.

e. распределение температуры росы

На приведенном выше графике показано распределение счетчика температуры росы. Мы видим, что распределение несколько смещено вправо с максимальными значениями, лежащими между -5 град. Цельсия до 20 град. Цельсия.

ж. распределение cloud_coverage

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

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

г. precip_depth_1_hr распределение

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

ч. Распределение давления на уровне моря

На приведенном выше графике показан скрипичный график sea_level_pressure. Мы видим, что большинство значений лежат в диапазоне от 1010 до 1020.

я. Распределение floor_count

Вышеприведенное распределение показывает график подсчета floor_count. Мы видим, что есть много зданий с этажностью меньше или равной 5. Лишь несколько зданий имеют этажность больше 5.

Дж. Распределение year_built

На приведенном выше графике показан график подсчета функции year_built. Мы видим, что многие здания были построены в 1975 году из участка-122. В целом, между 1960 и 1980 годами было построено большое количество зданий. Кроме того, многие здания появились за этот 120-летний период, с 1900 по 2020 год.

к. Распределение квадратных футов

На приведенном выше графике показано распределение подсчета функции square_feet. Мы видим, что график смещен вправо со многими значениями, лежащими в диапазоне от 0 до 200 000.

Чтобы лучше понять, применим к этой функции логарифмическое преобразование.

После применения преобразования log1p мы видим, что средние значения теперь составляют 1,103946e+01.

Теперь мы снова строим график подсчета квадратных_футов. Это можно увидеть ниже.

Мы видим, что распределение функции square_feet напоминает нормальное/гауссово распределение. Кроме того, он несколько смещен вправо.

2.2 Сравнительные графики функций

а. Сравнение показаний счетчика и функций счетчика

На приведенном выше графике показано сравнение функций counter иmeter_reading в train_data. Мы наблюдаем, что показания счетчика самые высокие для пара и самые низкие для категории горячей воды функции «счетчик».

б. Сравнение функцийmeter_reading и air_temperature

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

в. Сравнение функций air_temperature и site_id

На приведенном выше графике показано сравнение функций air_temperature и site_id. Из этого графика мы можем сделать вывод о том, что температура воздуха сильно различается, и что есть участки с высокими температурами воздуха, например, участок 2 и участок 8 имеют высокие температуры воздуха. Также участки 13, 14 имеют значительно более низкие температуры.

д. Сравнение функцийmeter_reading и floor_count

На приведенном выше графике показано сравнение между функциями counter_reading и floor_count для train_data. Мы видим, что здания с этажностью от 1 до 10 используют большую мощность. Кроме того, пробел на графике сразу после количества этажей = 20 предполагает, что, возможно, не все этажи потребляют электроэнергию одновременно, или нам может понадобиться дополнительная информация по этому вопросу. Мы также видим, что здания с этажностью от 15 до 20 потребляют большую мощность.

e. Сравнение функцийmeter_reading и year_built

Приведенная выше гистограмма отображает сравнение между функциямиmeter_reading и year_built. Мы видим, что большое количество энергии было потреблено в 1922, 1938, 1952 и 2009 годах.

ж. Сравнение функцийmeter_reading и Square_feet

Приведенный выше график рассеяния показывает сравнение между функциямиmeter_reading и Square_feet. Мы видим, что по мере увеличения площади зданий, area-square_feet, вместе с ней увеличивается и энергопотребление. Связь хорошо видна из приведенного выше графика.

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

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

г. Сравнение функцийmeter_reading и site_id

Приведенная выше диаграмма показывает сравнение между функциямиmeter_reading и site_id. Мы видим, что сайты 7, 14 и 13 потребляют очень большую мощность по сравнению с остальными. Кроме того, сайт 5 потребляет наименьшую мощность. Как видно из приведенного выше графика, почти все объекты потребляют электроэнергию со значениемmeter_reading ‹= 4,5.

ч. Сравнение функцийmeter_reading и site_id

На приведенном выше графике рассеяния показано сравнение функцийmeter_reading и building_id. Существует разница в потреблении энергии во всех зданиях. Мы видим, что есть 1 точка с очень высоким значениемmeter_reading. Его можно рассматривать как точку выброса. Сначала проверим.

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

я. Матрица корреляции

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

· температура росы и температура воздуха — 0,75

· Square_feet и floor_count — 0,56

· site_id и building_id — 0,98

Остальные признаки имеют корреляцию менее 0,50. Размер здания определяет энергопотребление, что мы видим на приведенном выше графике, где корреляция между Square_Feet и Floor_Count составляет 0,56. Мы можем заметить, что температуры также влияют на энергопотребление.

3. Разработка функций

Из приведенных выше графиков мы видим, что у нас есть выброс в building_id 1099. Мы удаляем этот выброс.

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

3.1 Добавление функции – час, день, неделя, месяц, год

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

3.2 График зависимости показаний счетчика от часов

На приведенном выше графике показано сравнение показателейmeter_reading и часов для заданных данных. Мы видим, что энергопотребление снижается в ночное время. Кроме того, потребление энергии является высоким с 7 утра до почти 8 вечера дня, т. е. потребление энергии увеличивается в дневное время суток. Потребление достигает пика около 15:00 часов (15:00). Это может быть связано с тем, что большинство/все отрасли промышленности, учебные заведения и рабочие/корпоративные здания работают в дневное время суток.

3.3 График зависимости показаний счетчика от дней недели

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

3.4 График зависимости показаний счетчика от месяцев года

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

Мы также рисуем-

График энергопотребления в час по сравнению с показаниями счетчика для каждого варианта использования primary_use.
График энергопотребления — Day_of_week против показаний счетчика для каждого варианта использования primary_use.
График энергопотребления — количество месяцев в зависимости от показаний счетчика для каждого варианта использования primary_use.
График почасового энергопотребления — месяцы и показания счетчика для каждого случая site_id

Кроме того, мы проверяем наличие отсутствующих значений в кадрах данных train_data и test_data и удаляем эти значения. Мы видим, что функции year_built и floor_count имеют более 50% отсутствующих значений. Итак, мы удаляем эти функции из наших наборов данных train_data и test_data.

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

3.5 Добавление функции относительной влажности в train_data и test_data

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

Здесь «Td» означает температуру росы в градусах Цельсия. «T» означает температуру воздуха в градусах Цельсия. «RH» означает относительную влажность и выражается в процентах. Значения «а» и «b» являются константами, где а = 17,625 и b = 243,04.

Ссылка- https://www.omnicalculator.com/physics/relative-humidity

3.6 Добавление функции "По ощущениям" в train_data и test_data

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

Для добавления функции ощущения мы используем библиотеку python — Meteocalc (ссылка — https://pypi.org/project/meteocalc/)

3.7 Добавление функций города и страны в train_data и test_data

Мы добавляем функции City и Country в наши train_data и добавляем наборы данных test_data. Это поможет нам добавить в наборы данных важную функцию — Праздник.

В приведенном ниже фрагменте кода показано, как добавляются функции «Город» и «Страна».

Мы создаем «области» фрейма данных, в которых есть названия городов и стран.

Поскольку участков 16, мы используем эту особенность наборов данных для объединения с ними областей. Фрагмент кода ниже показывает, как области объединяются с train_data. Точно так же мы можем объединить области с test_data.

3.8 Добавление функции «Праздник» в train_data и test_data

Мы добавляем функцию «Праздник» в наши наборы данных. Это так, потому что данные, которые у нас есть, являются годовыми, а в году много праздников. Итак, мы используем библиотеку Python Holiday.

Модуль Python Holidays — это полезный инструмент для быстрого и гибкого определения того, является ли данная дата праздником. С помощью этой библиотеки можно определить, является ли данный день праздником в любой данной стране. С помощью этой библиотеки можно легко определить определенные дни (государственные праздники), такие как Рождество и Новый год.

Приведенный выше фрагмент описывает страны и годы, затраченные на определение праздников в наших наборах данных. Можно заметить, что, поскольку в наших данных есть страны — Соединенные Штаты Америки, Великобритания, Ирландия и Канада, мы отдыхали только в этих странах.

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

Точно так же мы можем добавить функцию Holiday в наш тестовый набор данных.

3.9 Добавление сезонных и дневных функций в train_data и test_data

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

Функцию «сезон» можно добавить с помощью приведенного ниже фрагмента кода.

Приведенный выше код показывает добавление функции «сезон» в train_data. Точно так же мы можем добавить функцию «сезон» в test_data.

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

3.10 Добавление функций Latitude, Solar_Hour, Solar_Dec и Horiz_Solar в train_data и test_data

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

Ссылка- https://www.kaggle.com/c/ashrae-energy-prediction/discussion/124984

3.11 Ярлык, кодирующий категориальные признаки в train_data и test_data

С помощью библиотеки кодировщика меток Scikit Learn мы кодируем категориальные функции в наших наборах данных обучения и тестирования. Функции, которые мы помечаем как кодирование, — «метр», «основное_использование» и «сезон».

Ниже фрагмент кода показывает, как мы пометили закодированную функцию — «primary_use».

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

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

3.12 Добавление функции Air_Temp_Diff в train_data и test_data

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

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

Окончательные кадры данных train_data и test_data содержат 29 и 28 столбцов, а train_data имеет дополнительный столбец counter_reading, который является нашей целевой переменной.

4. Моделирование данных

4.1 Базовая модель

Во-первых, мы делаем наш фрейм данных y_predict, используя train_data, как видно из приведенного ниже фрагмента кода.

Затем мы разделяем наши train_data на x_train и x_cv в качестве нашего набора для обучения и перекрестной проверки, используя библиотеку Scikit-Learn train_test_split. Затем мы создаем y_train и y_cv.

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

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

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

Он определяется как среднеквадратичное значение разницы между прогнозируемым и фактическим значением целевой переменной, здесь -meter_reading.

Кроме того, в формате кода мы определяем RMSE следующим образом:

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

4.2 Регрессионная модель дерева решений

Теперь мы применим регрессионную модель дерева решений к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

Мы наблюдаем, что наименьшая ошибка перекрестной проверки приходится на глубину дерева -15 со среднеквадратичной ошибкой 0,847.

Эта ошибка может быть дополнительно уменьшена в других будущих моделях.

При этой самой низкой перекрестной проверке мы снова запускаем нашу модель и сохраняем ее. Мы получаем ту же самую низкую ошибку перекрестной проверки 0,847. Мы сохраняем эту модель в файле .sav.

4.3 Модель регрессионного дерева принятия решений с использованием машины повышения градиента света (LGBM)

Теперь мы применим регрессионную модель дерева решений Light GBM к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

Мы наблюдаем, что наименьшая ошибка перекрестной проверки составляет 0,635 при количестве оценок 2000.

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

4.4 Модель регрессии случайного леса

Теперь мы применим модель регрессии случайного леса к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

Мы наблюдаем, что самая низкая ошибка перекрестной проверки составляет 0,816 при глубине дерева 15. Эта ошибка больше, чем в модели регрессии дерева решений LGBM, но меньше по сравнению с моделью регрессии простого дерева решений.

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

4.5 Light Gradient Boost Machine (LGBM) Модель случайной регрессии леса

Теперь мы применим модель регрессии случайного леса Light GBM к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

Мы наблюдаем, что наименьшая ошибка перекрестной проверки составляет 1,177 при количестве оценок 75. Эта ошибка больше, чем у любой регрессионной модели, но она намного меньше по сравнению с другим количеством оценок этой самой модели.

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

4.6 Регрессионная модель CatBoost

Теперь мы применяем модель категориального повышения или регрессионной модели CatBoost к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

Мы наблюдаем, что наименьшая ошибка перекрестной проверки составляет 0,684 при количестве оценок 1000. Эта ошибка больше, чем у первых трех моделей регрессии, но она намного меньше по сравнению с моделью регрессии случайного леса LGBM.

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

4.7 Регрессионная модель Extreme Gradient Boost (XGBoost)

Теперь мы применяем модель Extreme Gradient Boost или регрессионную модель XGBoost к наборам x_train, x_test, y_train и y_test.

Ошибки перекрестной проверки для этой модели представлены ниже.

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

При этом наименьшем значении перекрестной проверки мы снова запускаем нашу модель и сохраняем ее. Мы получаем ту же самую низкую ошибку перекрестной проверки 0,665. Мы сохраняем эту модель в файле .sav.

5. Результаты

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

6. Прогнозирование моделей

Мы запускаем все наши модели и делаем прогнозы на test_data. Кроме того, мы сохраняем эти прогнозы в файле CSV (переменная, разделенная запятыми). Наконец, мы отправляем эти предсказанные CSV-файлы на веб-сайт Kaggle и генерируем оценки.

Сгенерированные оценки Kaggle следующие:

Мы видим, что модель регрессии LGBM GBDT имеет самые низкие оценки. Это наша лучшая модель. Публичные и частные оценки лучшей модели: 1,292 и 1,584. Это довольно приличный показатель.

Мы также развернули лучшую модель, используя NGROK и STREAMLIT. Посмотрите видео о развертывании здесь — https://youtu.be/0vFqEVFd7g0

Проверьте мою ссылку GitHub на это тематическое исследование - https://github.com/nakul1402/Self-Case-Study--Ashrae-Great-Energy-Predictor-3.-

Ссылка на мой профиль LinkedIn — https://www.linkedin.com/in/nakulgirinitr/

7. Будущая область

Мы можем применить алгоритмы глубокого обучения, такие как LSTM, GRU, к этой проблеме и получить еще лучшие результаты.

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

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

8. Ссылки

· www.appliedaicourse.com

· https://www.kaggle.com/code/gemartin/load-data-reduce-memory-usage/notebook

· https://www.kaggle.com/code/ts1789/ashrae-part-2-feature-engineering-and-selectionot

· https://www.kaggle.com/code/varunjain113/ashrae-starting-dataset-tabularpandas-object