Пять способов тонкой настройки модели Chronos-2, модели, лежащей в основе анализа временных рядов.

Часть 2: Практический обзор адаптации LoRA.

Делиться

В первой части этой серии мы представили Chronos-2, базовую модель для анализа временных рядов. Мы попрактиковались на реальном примере и увидели, на что способен Chronos-2 сразу после установки, без предварительного обучения.

Но, как мы отметили в конце первой части, нулевого выстрела не всегда достаточно .

В случаях, когда:

• Ваши данные могут отличаться от всего, что было в исходном наборе данных для предварительного обучения.
• Модель постоянно допускает систематические ошибки.
• У вас есть обширные исторические данные, которые можно использовать.
• Ваша конечная цель может не совпадать с целью, для которой оптимизируется обучение Chronos-2.

Следующий естественный шаг — это тонкая настройка.

В этой статье мы продолжим анализ потребления электроэнергии в здании, начатый в Части 1, и рассмотрим пять сценариев тонкой настройки Chronos-2:

1. Адаптация отдельного здания : как точно настроить работу с одним единственным активом.
2. Тонкая настройка портфеля : как объединить историю по всему парку устройств для общего адаптера.
3. Тонкая настройка с учетом ковариат : как выполнить тонкую настройку с использованием известных будущих сигналов.
4. Портфель + ковариаты : как использовать информацию как о ковариатах, так и о флоте.
5. Перенос с задержкой : как адаптировать модель один раз, а затем развернуть ее на ресурсах, которые модель никогда не видела во время тонкой настройки.

В итоге у вас будет рабочий шаблон для тонкой настройки TSFM, готовый к адаптации к вашим собственным данным.

В первой части этой серии статей рассказывается о том, как использовать Chronos-2 для прогнозирования в одномерном, многомерном, ковариационном и кросс-обучении сценариях. Если вы хотите использовать Chronos-2 без дополнительных настроек, ознакомьтесь с публикацией здесь.

1. Краткий обзор тематического исследования.

Давайте быстро вернемся к настройке из части 1.

У нас есть синтетический набор данных по восьми коммерческим зданиям, в котором регистрируется почасовая потребность в электроэнергии. Задача, которую мы ставим перед собой, — спрогнозировать общую нагрузку на электроэнергию на неделю вперед, то есть на 168 часов. Для генерации набора данных мы используем физический симулятор, в котором общая нагрузка разложена на базовую нагрузку, нагрузку от розеток, освещение и системы отопления, вентиляции и кондиционирования воздуха (ОВК). Физически, нагрузка от розеток и освещения определяется графиком использования помещений в будние дни, а нагрузка от ОВК — температурой наружного воздуха.

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

• Период подготовки (12 недель): с 1 марта по 22 мая 2025 года — это единственный период для тонкой настройки.
• Период проверки (1 неделя): с 23.05.2025 по 29.05.2025, использовался для выбора контрольных точек и досрочного прекращения.
• Контекст для вывода (45 дней): с 30.05.2025 по 13.07.2025 — период, используемый в качестве контекста при построении прогнозов. Конвейер нулевого обучения в Части 1 также использовал 45 дней контекста.
• Тестирование (1 неделя): с 14.07.2025 по 20.07.2025, прогнозный горизонт для тестирования доработанной модели.

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

2. Краткая информация о тонкой настройке и LoRA.

Прежде чем перейти к подробному описанию, давайте кратко обсудим концепцию тонкой настройки и одну из её специфических технологий, а именно LoRA.

2.1 Что такое тонкая настройка?

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

В частности, для Chronos-2 это трансформер с 120 миллионами параметров, который уже изучил множество типовых структур временных рядов. Тонкая настройка позволит нам еще больше скорректировать его поведение в соответствии с нашими данными.

Но стоит ли обновлять все 120 миллионов параметров?

Скорее всего, нет.

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

Нам нужен более эффективный способ тонкой настройки. Одним из таких решений является LoRA .

2.2 Что такое LoRA?

LoRA расшифровывается как Low-Rank Adaptation (адаптация низкого ранга) [1]. Ее основная идея проста: вместо обновления всех весовых матриц мы замораживаем исходную предварительно обученную модель и обучаем лишь небольшой набор дополнительных параметров, которые незначительно изменяют ее поведение.

В качестве примера предположим, что один слой в предварительно обученной модели содержит матрицу весов W размером d_out x d_in, где d_out = d_in = 1024.

Обновление матрицы весов будет означать следующее:

Тогда размер ΔW также должен составлять 1024 x 1024. Если мы хотим выполнить полное обновление, это будет означать обновление более миллиона обучаемых параметров.

Секрет LoRA заключается в том, что ΔW обучается не как полная матрица. Вместо этого LoRA представляет его как произведение двух гораздо меньших матриц:

где A имеет форму rx d_in, а B имеет форму d_out x r. И r — ранг адаптера. Этот метод называется методом низкого ранга, потому что r обычно довольно мало, например, 4, 8, 16 или 32.

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

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

На практике это дает нам несколько преимуществ. Поскольку у нас гораздо меньше обучаемых параметров, использование памяти GPU, которая расходуется на градиенты и состояния оптимизатора, может быть значительно снижено. У нас также меньше контрольных точек, поскольку нам не нужно сохранять полную копию модели с 120 миллионами параметров для каждого эксперимента; мы сохраняем только адаптер. И это снижает риск переобучения, особенно когда исходный набор данных невелик.

3. Как выполнить расчет LoRA для Chronos-2?

Для реализации LoRA для модели Chronos-2 первое, что нам нужно решить, это какие слои Chronos-2 мы хотим адаптировать.

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

В первой части мы объяснили, что Chronos-2 — это кодировщик на основе трансформатора, построенный на трех основных блоках:

1. Встраивание входного фрагмента кода.
2. Стопка слоев внимания, чередующихся между вниманием ко времени и групповым вниманием.
3. Встраивание выходного патча.

Наша конфигурация LoRA адаптирует два из этих трех блоков:

• Проекции Q, K, V и O в каждом слое внимания . Здесь мы можем точно настроить, как модель реагирует на события как во временном отношении внутри каждой серии, так и между сериями внутри группы.

В Chronos-2 каждый слой внимания включает четыре линейные проекции для отображения входных данных слоя на выходные. Запрос (Q), ключ (K) и значение (V) создают три различных представления входных данных, затем механизм внимания вычисляет показатель сходства между каждым запросом и каждым ключом и использует эти показатели для вычисления взвешенной агрегации значений. Затем результат проходит через выходную проекцию (O), которая объединяет информацию между слоями внимания и преобразует ее обратно в соответствии со стандартными размерами выходных данных слоя.

• Встраивание выходного фрагмента . Это позволяет нам точно настроить способ, которым модель проецирует свои внутренние состояния в окончательные прогнозы.

В коде мы имеем:

 LORA_CONFIG = { "r": 8, "lora_alpha": 16, "target_modules": [ "self_attention.q", "self_attention.v", "self_attention.k", "self_attention.o", "output_patch_embedding.output_layer", ], }

где lora_alpha — масштабный коэффициент. Он определяет, насколько интенсивно применяется обновление LoRA, при этом большее значение α означает более агрессивную адаптацию.

В нашем текущем исследовании мы используем библиотеку Hugging Face peft для тонкой настройки Chronos-2.

Теперь мы готовы приступить к практической работе.

4. Пять сценариев тонкой настройки

Для последующих экспериментов мы также начинаем с той же базовой модели, а именно с контрольной точки amazon/chronos-2 , с той же конфигурацией LoRA. Изменяется лишь объем данных, которые мы используем для тонкой настройки.

Основной метрикой, которую мы будем использовать, является взвешенная абсолютная процентная ошибка:

Итак, давайте рассмотрим пять сценариев по очереди.

Если вы еще не настроили соответствующую среду Chronos, обратитесь к части 1: 4.1 Настройка модели Chronos-2 .

4.1 Адаптация отдельных зданий

Можно ли выполнить тонкую настройку по одному активу?

Предположим, нас интересует только одно здание, скажем, здание 03. У нас есть исторические данные о нагрузке этого здания, и мы хотим адаптировать Chronos-2 к особенностям работы именно этого здания.

Это будет простейшая схема тонкой настройки. Никаких ковариат, никакой информации о портфеле, только один целевой ряд.

Как уже упоминалось ранее, мы начинаем с контрольной точки amazon/chronos-2 , оставляем базовую модель замороженной и изучаем только небольшой адаптер LoRA поверх неё.

API тонкой настройки Chronos-2 ожидает, что обучающие данные будут представлены в виде списка словарей задач. Для нашей текущей одномерной задачи, содержащей только целевые значения, каждому словарю нужен только один ключ: target .

Для здания 03 мы можем подготовить входные данные для тонкой настройки следующим образом:

 story_building = "Building 03" train_df = full_df[full_df["timestamp"] < "2025-05-23"] single_building_train = train_df[ train_df["building"].eq(story_building) ].sort_values("timestamp") train_inputs = [ { "target": single_building_train[["total_load_kw"]] .to_numpy(dtype="float32") .T } ]

Причина, по которой нам необходима операция «транспонирования», заключается в том, что Chronos-2 ожидает, что целевой массив будет иметь следующую форму:

 (num_target_series, time_steps)

Поскольку у нас есть только одна одномерная целевая переменная, мы имеем:

 (1, T)

Помимо обучающих данных, следует подготовить и валидационные данные в том же формате:

 validation_df = full_df[full_df["timestamp"] < "2025-05-30"] single_building_validation = validation_df[ validation_df["building"].eq(story_building) ].sort_values("timestamp") validation_inputs = [ { "target": single_building_validation[["total_load_kw"]] .to_numpy(dtype="float32") .T } ]

Здесь стоит упомянуть две вещи:

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

Затем вы можете заметить, что validation_df включает не только период с 23 по 29 мая, но и все, что было до этого. Это необходимо, потому что для построения прогнозов Chronos-2 нужен контекст. На основе заданного prediction_length Chronos внутренне рассматривает последние часы prediction_length из validation_df как истинную целевую дату прогноза для проверки. Предшествующие значения и есть контекст.

В данном случае мы настроили только одну задачу валидации в validation_inputs . Это означает, что у нас фактически только одно окно прогнозирования для валидации, поскольку внутри Chronos-2 всегда использует последние шаги prediction_length из датафрейма в качестве целевого окна и предыдущие шаги context_length в качестве контекста, НЕЗАВИСИМО от того , сколько еще шагов вы подадите в этот датафрейм. Другими словами, простое добавление более длинного датафрейма для валидации автоматически не создает больше окон валидации.

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

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

Теперь мы можем внести более точные изменения:

 fine_tuned_model = base_model.fit( train_inputs, prediction_length=168, validation_inputs=validation_inputs, finetune_mode="lora", lora_config=LORA_CONFIG, context_length=1080, # 45-day context window learning_rate=2e-5, num_steps=1000, batch_size=32, output_dir="finetuned_models/fine_tuning_modes/single_target", finetuned_ckpt_name="checkpoint", callbacks=[EarlyStoppingCallback(early_stopping_patience=6)], save_steps=25, eval_steps=25, )

Здесь мы устанавливаем prediction_length=168 , чтобы модель обучалась для той же задачи, которая нас интересует во время тестирования, а именно, для почасового прогнозирования на неделю вперед. Также мы устанавливаем context_length=45 * 24 , что представляет собой контекстное окно на 45 дней. Это та же длина контекста, которую мы использовали в Части 1. Наконец, поскольку мы использовали validation_inputs , активируется выбор контрольных точек. Каждые 25 шагов обучения Chronos-2 оценивает потери валидации, и если потери валидации перестают улучшаться в течение 6 проверок валидации подряд ( early_stopping_patience=6 ), срабатывает ранняя остановка, и тонкая настройка прекращается.

Я запустил процесс тонкой настройки на ноутбуке с видеокартой NVIDIA RTX 2000 Ada и 8 ГБ видеопамяти. Запуск занял около 42 секунд.

После обучения адаптера вывод результатов выглядит практически так же, как и при прогнозировании без предварительного обучения:

 single_context = test_context_df[ test_context_df["building"].eq(story_building) ][["building", "timestamp", "total_load_kw"]] pred_single_finetuned = fine_tuned_model.predict_df( single_context, prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="building", timestamp_column="timestamp", target="total_load_kw", )

Для здания 03 базовый показатель WAPE при стрельбе только по мишени без выстрелов составил 8,3%. После тонкой настройки только для здания 03 показатель WAPE снизился до 7,6%. Мы видим, что тонкая настройка привела к некоторым улучшениям.

4.2 Тонкая настройка портфеля

Можно ли объединить историю событий по всему парку автомобилей для использования с общим адаптером?

На практике в портфеле часто присутствует несколько взаимосвязанных активов.

В нашем случае это означает восемь зданий. Они не идентичны, но демонстрируют схожие ежедневные и еженедельные тенденции спроса.

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

Здесь мы по-прежнему прогнозируем только total_load_kw , а это значит, что настройка практически такая же, как и раньше:

 target_column = "total_load_kw" train_inputs = [ { "target": building_df[[target_column]].to_numpy(dtype="float32").T, } for _, building_df in train_df.groupby("building", sort=True) ] validation_inputs = [ { "target": building_df[[target_column]].to_numpy(dtype="float32").T, } for _, building_df in validation_df.groupby("building", sort=True) ]

По сути, каждое здание становится отдельной задачей для обучения. Затем мы дорабатываем Chronos-2 с той же конфигурацией LoRA, что и раньше:

 fine_tuned_model = base_model.fit( inputs=train_inputs, validation_inputs=validation_inputs, prediction_length=168, context_length=1080, lora_config=LORA_CONFIG, learning_rate=2e-5, max_steps=1000, )

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

Причины тонкой настройки показаны ниже, где мы сравниваем качество прогнозирования между моделью Chronos-2 без предварительного обучения и с тонкой настройкой:

 Building Zero-shot WAPE Fine-tuned WAPE Building 01 8.0% 7.4% Building 02 12.2% 11.3% Building 03 8.3% 7.5% Building 04 8.0% 7.6% Building 05 7.2% 6.8% Building 06 10.9% 9.9% Building 07 7.7% 7.2% Building 08 6.6% 6.3%

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

4.3 Тонкая настройка с учетом ковариат

Можно ли задать Chronos-2 известные ковариаты во время тонкой настройки?

На данный момент Chronos-2 видит только саму целевую серию данных, то есть исторические total_load_kw .

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

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

Здесь необходимо изменить входные данные для тонкой настройки. Вместо передачи только целевого значения, каждое обучающее задание теперь должно также содержать past_covariates и future_covariates :

 known_future_columns = [ "outdoor_temp_c", "occupancy", "solar_irradiance", "is_weekend", ] single_building_train = train_df[ train_df["building"].eq(story_building) ].sort_values("timestamp") train_inputs = [ { "target": single_building_train[["total_load_kw"]] .to_numpy(dtype="float32") .T, "past_covariates": { column: single_building_train[column].to_numpy(dtype="float32") for column in known_future_columns }, "future_covariates": { column: None for column in known_future_columns }, } ]

В разделе past_covariates содержатся исторические значения ряда ковариат. В процессе тонкой настройки Chronos-2 может отслеживать, как такие ковариаты, как температура, занятость, солнечная радиация и выходные дни, влияют на нагрузку.

Часть future_covariates сообщает Chronos-2, что эти ковариаты также доступны на горизонте прогнозирования. Здесь мы устанавливаем для них значение None, поскольку Chronos-2 формирует будущие окна внутри себя на основе той же исторической серии. Позже, во время вывода, мы предоставим фактические будущие значения ковариат через future_df , как и в части 1.

Сам вызов для тонкой настройки остаётся практически неизменным:

 fine_tuned_model = base_model.fit( train_inputs, prediction_length=168, validation_inputs=validation_inputs, finetune_mode="lora", lora_config=LORA_CONFIG, context_length=1080, learning_rate=2e-5, num_steps=1000, batch_size=32, output_dir="finetuned_models/fine_tuning_modes/single_covariate", finetuned_ckpt_name="checkpoint", callbacks=[EarlyStoppingCallback(early_stopping_patience=6)], save_steps=25, eval_steps=25, )

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

 context_with_covariates = test_context_df[ ["building", "timestamp", "total_load_kw"] + known_future_columns ] future_covariates_df = test_truth_df[ ["building", "timestamp"] + known_future_columns ] pred_single_covariate = fine_tuned_model.predict_df( context_with_covariates, future_df=future_covariates_df, prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="building", timestamp_column="timestamp", target="total_load_kw", )

Для здания 03 средневзвешенная вероятность ошибки первого рода (WAPE) с учетом ковариат составляет 4,0%. После тонкой настройки адаптера с учетом ковариат для здания 03, WAPE снижается до 2,8%, что приводит к относительному снижению на 30,7%.

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

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

4.4 Портфель + ковариаты

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

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

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

В частности, в нашем текущем случае мы проводим тонкую настройку для всех восьми зданий, и для каждого здания мы задаем total_load_kw в качестве целевого значения, а outdoor_temp_c , occupancy , solar_irradiance и is_weekend в качестве известных будущих ковариат:

 train_inputs = [] for building, building_df in train_df.groupby("building", sort=True): building_df = building_df.sort_values("timestamp") train_inputs.append( { "target": building_df[["total_load_kw"]] .to_numpy(dtype="float32") .T, "past_covariates": { column: building_df[column].to_numpy(dtype="float32") for column in known_future_columns }, "future_covariates": { column: None for column in known_future_columns }, } )

В приведенном выше фрагменте кода мы создаем одну задачу для каждого здания. Тот же принцип применим и к данным для валидации. Каждое здание связано с одной задачей валидации, и Chronos-2 использует последние 168 часов каждой задачи в качестве окна прогнозирования для валидации.

Сам вызов для тонкой настройки остается прежним:

 fine_tuned_model = base_model.fit( train_inputs, prediction_length=168, validation_inputs=validation_inputs, finetune_mode="lora", lora_config=LORA_CONFIG, context_length=1080, learning_rate=2e-5, num_steps=1000, batch_size=32, output_dir="finetuned_models/fine_tuning_modes/portfolio_covariate", finetuned_ckpt_name="checkpoint", callbacks=[EarlyStoppingCallback(early_stopping_patience=6)], save_steps=25, eval_steps=25, )

Для вывода заключений мы используем 45-дневный исторический контекст, а также известные будущие ковариаты для прогнозируемой недели:

 context_with_covariates = test_context_df[ ["building", "timestamp", "total_load_kw"] + known_future_columns ] future_covariates_df = test_truth_df[ ["building", "timestamp"] + known_future_columns ] pred_portfolio_covariate = fine_tuned_model.predict_df( context_with_covariates, future_df=future_covariates_df, prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="building", timestamp_column="timestamp", target="total_load_kw", )

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

В восьми зданиях базовый показатель WAPE для стратегии без предварительного тестирования составил 8,4%. После тонкой настройки портфеля и ковариат показатель WAPE снизился до 2,8%, что составляет относительное снижение на 66,8%.

4.5 Отложенный перевод

Можно ли адаптировать модель один раз, а затем развернуть её на ресурсах, которые она никогда не видела во время тонкой настройки?

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

Но есть еще один важный вопрос: что, если новое здание введено в эксплуатацию совсем недавно?

Таким образом, в этом заключительном сценарии мы исключаем здание 06 из процесса тонкой настройки, чтобы Chronos-2 никогда не видел его данных во время обучения адаптера LoRA. Мы проводим тонкую настройку на остальных семи зданиях, используя как целевые истории, так и известные будущие ковариаты. Затем, во время вывода, мы применяем адаптер к зданию 06.

Изменение в коде незначительное:

 held_out_building = "Building 06" train_buildings = [ building for building in sorted(train_df["building"].unique()) if building != held_out_building ] train_inputs = [] for building in train_buildings: building_df = train_df[ train_df["building"].eq(building) ].sort_values("timestamp") train_inputs.append( { "target": building_df[["total_load_kw"]] .to_numpy(dtype="float32") .T, "past_covariates": { column: building_df[column].to_numpy(dtype="float32") for column in known_future_columns }, "future_covariates": { column: None for column in known_future_columns }, } )

Затем, на этапе вывода результатов, мы выбираем для прогнозирования здание № 06:

 building_06_context = test_context_df[ test_context_df["building"].eq(held_out_building) ][["building", "timestamp", "total_load_kw"] + known_future_columns] building_06_future_covariates = test_truth_df[ test_truth_df["building"].eq(held_out_building) ][["building", "timestamp"] + known_future_columns] pred_heldout = fine_tuned_model.predict_df( building_06_context, future_df=building_06_future_covariates, prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="building", timestamp_column="timestamp", target="total_load_kw", )

Для здания 06 базовый вариант с нулевым уровнем значимости, учитывающий ковариаты, имеет средневзвешенную ошибку прогнозирования (WAPE) 4,2%. После применения адаптера, доработанного для остальных семи зданий, WAPE снижается до 3,1%. Это относительное снижение на 26,8%.

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

5. Чему мы научились?

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

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

Закономерность довольно очевидна. Тонкая настройка только целевой переменной помогает в некоторой степени, но лишь незначительно. Более существенный прирост наблюдается, когда мы предоставляем Chronos-2 известные будущие ковариаты, а затем выполняем тонкую настройку адаптера на их основе. Результат переноса, проведенного с использованием отложенного обучения, также обнадеживает: даже для здания, исключенного из тонкой настройки, адаптер может обучаться на примере связанных зданий и все равно превосходить базовый вариант с нулевым количеством примеров, основанный на ковариатах.

Полный код блокнота можно найти здесь: https://github.com/ShuaiGuo16/chronos-2-forecasting/blob/main/02_chronos2_fine_tuning_building_demand.ipynb

Ссылка

[1] LoRA: Низкоранговая адаптация больших языковых моделей. arXiv, 2021.

Шуай Го Посмотреть все в Шуай Го

Источник: towardsdatascience.com