33.9 C
Colombia
lunes, julio 7, 2025

Un primer intento de predicción de varios pasos


Recogemos donde el primera publicación de esta serie nos dejó: afrontar la tarea de la previsión de collection temporales de varios pasos.

Nuestro primer intento fue una especie de solución alternativa. El modelo había sido entrenado para ofrecer una única predicción, correspondiente al siguiente momento. Por lo tanto, si necesitáramos un pronóstico más largo, todo lo que podríamos hacer es usar esa predicción y retroalimentarla al modelo, moviendo la secuencia de entrada en un valor (de ([x_{t-n}, …, x_t]) a ([x_{t-n-1}, …, x_{t+1}])decir).

Por el contrario, el nuevo modelo estará diseñado (y entrenado) para pronosticar un número configurable de observaciones a la vez. La arquitectura seguirá siendo básica (lo más básica posible, dada la tarea) y, por lo tanto, puede servir como base para intentos posteriores.

Trabajamos con los mismos datos que antes, vic_elec de tsibbledata.

Sin embargo, en comparación con la última vez, el dataset La clase tiene que cambiar. Mientras que, anteriormente, para cada artículo del lote el objetivo (y) period un valor único, ahora es un vector, al igual que la entrada, x. Y al igual que n_timesteps se usaba (y todavía se usa) para especificar la longitud de la secuencia de entrada, ahora hay un segundo parámetro, n_forecastpara configurar el tamaño objetivo.

En nuestro ejemplo, n_timesteps y n_forecast se establecen en el mismo valor, pero no es necesario que este sea el caso. También podrías entrenar en secuencias de una semana y luego pronosticar los acontecimientos durante un solo día o un mes.

Aparte del hecho de que .getitem() ahora devuelve un vector para y así como xno hay mucho que decir sobre la creación de conjuntos de datos. Aquí está el código completo para configurar la canalización de entrada de datos:

n_timesteps <- 7 * 24 * 2
n_forecast <- 7 * 24 * 2 
batch_size <- 32

vic_elec_get_year <- operate(12 months, month = NULL) {
  vic_elec %>%
    filter(12 months(Date) == 12 months, month(Date) == if (is.null(month)) month(Date) else month) %>%
    as_tibble() %>%
    choose(Demand)
}

elec_train <- vic_elec_get_year(2012) %>% as.matrix()
elec_valid <- vic_elec_get_year(2013) %>% as.matrix()
elec_test <- vic_elec_get_year(2014, 1) %>% as.matrix()

train_mean <- imply(elec_train)
train_sd <- sd(elec_train)

elec_dataset <- dataset(
  identify = "elec_dataset",
  
  initialize = operate(x, n_timesteps, n_forecast, sample_frac = 1) {
    
    self$n_timesteps <- n_timesteps
    self$n_forecast <- n_forecast
    self$x <- torch_tensor((x - train_mean) / train_sd)
    
    n <- size(self$x) - self$n_timesteps - self$n_forecast + 1
    
    self$begins <- kind(pattern.int(
      n = n,
      dimension = n * sample_frac
    ))
    
  },
  
  .getitem = operate(i) {
    
    begin <- self$begins[i]
    finish <- begin + self$n_timesteps - 1
    pred_length <- self$n_forecast
    
    record(
      x = self$x[start:end],
      y = self$x[(end + 1):(end + pred_length)]$squeeze(2)
    )
    
  },
  
  .size = operate() {
    size(self$begins) 
  }
)

train_ds <- elec_dataset(elec_train, n_timesteps, n_forecast, sample_frac = 0.5)
train_dl <- train_ds %>% dataloader(batch_size = batch_size, shuffle = TRUE)

valid_ds <- elec_dataset(elec_valid, n_timesteps, n_forecast, sample_frac = 0.5)
valid_dl <- valid_ds %>% dataloader(batch_size = batch_size)

test_ds <- elec_dataset(elec_test, n_timesteps, n_forecast)
test_dl <- test_ds %>% dataloader(batch_size = 1)

El modelo reemplaza la capa lineal única que, en la publicación anterior, tenía la tarea de generar la predicción ultimate, con una pequeña purple, completa con dos capas lineales y, opcionalmente, abandono.

En ahead()primero aplicamos el RNN y, al igual que en la publicación anterior, hacemos uso del outputs solo; o más específicamente, el output correspondiente al paso de tiempo ultimate. (Ver esa publicación anterior para una discusión detallada de que torch RNN regresa.)

mannequin <- nn_module(
  
  initialize = operate(sort, input_size, hidden_size, linear_size, output_size,
                        num_layers = 1, dropout = 0, linear_dropout = 0) {
    
    self$sort <- sort
    self$num_layers <- num_layers
    self$linear_dropout <- linear_dropout
    
    self$rnn <- if (self$sort == "gru") {
      nn_gru(
        input_size = input_size,
        hidden_size = hidden_size,
        num_layers = num_layers,
        dropout = dropout,
        batch_first = TRUE
      )
    } else {
      nn_lstm(
        input_size = input_size,
        hidden_size = hidden_size,
        num_layers = num_layers,
        dropout = dropout,
        batch_first = TRUE
      )
    }
    
    self$mlp <- nn_sequential(
      nn_linear(hidden_size, linear_size),
      nn_relu(),
      nn_dropout(linear_dropout),
      nn_linear(linear_size, output_size)
    )
    
  },
  
  ahead = operate(x) {
    
    x <- self$rnn(x)
    x[[1]][ ,-1, ..] %>% 
      self$mlp()
    
  }
  
)

Para la creación de instancias del modelo, ahora tenemos un parámetro de configuración adicional, relacionado con la cantidad de abandono entre las dos capas lineales.

web <- mannequin(
  "gru", input_size = 1, hidden_size = 32, linear_size = 512, output_size = n_forecast, linear_dropout = 0
  )

# coaching RNNs on the GPU presently prints a warning that will litter 
# the console
# see https://github.com/mlverse/torch/points/461
# alternatively, use 
# gadget <- "cpu"
gadget <- torch_device(if (cuda_is_available()) "cuda" else "cpu")

web <- web$to(gadget = gadget)

El procedimiento de formación no ha cambiado en absoluto.

optimizer <- optim_adam(web$parameters, lr = 0.001)

num_epochs <- 30

train_batch <- operate(b) {
  
  optimizer$zero_grad()
  output <- web(b$x$to(gadget = gadget))
  goal <- b$y$to(gadget = gadget)
  
  loss <- nnf_mse_loss(output, goal)
  loss$backward()
  optimizer$step()
  
  loss$merchandise()
}

valid_batch <- operate(b) {
  
  output <- web(b$x$to(gadget = gadget))
  goal <- b$y$to(gadget = gadget)
  
  loss <- nnf_mse_loss(output, goal)
  loss$merchandise()
  
}

for (epoch in 1:num_epochs) {
  
  web$practice()
  train_loss <- c()
  
  coro::loop(for (b in train_dl) {
    loss <-train_batch(b)
    train_loss <- c(train_loss, loss)
  })
  
  cat(sprintf("nEpoch %d, coaching: loss: %3.5f n", epoch, imply(train_loss)))
  
  web$eval()
  valid_loss <- c()
  
  coro::loop(for (b in valid_dl) {
    loss <- valid_batch(b)
    valid_loss <- c(valid_loss, loss)
  })
  
  cat(sprintf("nEpoch %d, validation: loss: %3.5f n", epoch, imply(valid_loss)))
}
# Epoch 1, coaching: loss: 0.65737 
# 
# Epoch 1, validation: loss: 0.54586 
# 
# Epoch 2, coaching: loss: 0.43991 
# 
# Epoch 2, validation: loss: 0.50588 
# 
# Epoch 3, coaching: loss: 0.42161 
# 
# Epoch 3, validation: loss: 0.50031 
# 
# Epoch 4, coaching: loss: 0.41718 
# 
# Epoch 4, validation: loss: 0.48703 
# 
# Epoch 5, coaching: loss: 0.39498 
# 
# Epoch 5, validation: loss: 0.49572 
# 
# Epoch 6, coaching: loss: 0.38073 
# 
# Epoch 6, validation: loss: 0.46813 
# 
# Epoch 7, coaching: loss: 0.36472 
# 
# Epoch 7, validation: loss: 0.44957 
# 
# Epoch 8, coaching: loss: 0.35058 
# 
# Epoch 8, validation: loss: 0.44440 
# 
# Epoch 9, coaching: loss: 0.33880 
# 
# Epoch 9, validation: loss: 0.41995 
# 
# Epoch 10, coaching: loss: 0.32545 
# 
# Epoch 10, validation: loss: 0.42021 
# 
# Epoch 11, coaching: loss: 0.31347 
# 
# Epoch 11, validation: loss: 0.39514 
# 
# Epoch 12, coaching: loss: 0.29622 
# 
# Epoch 12, validation: loss: 0.38146 
# 
# Epoch 13, coaching: loss: 0.28006 
# 
# Epoch 13, validation: loss: 0.37754 
# 
# Epoch 14, coaching: loss: 0.27001 
# 
# Epoch 14, validation: loss: 0.36636 
# 
# Epoch 15, coaching: loss: 0.26191 
# 
# Epoch 15, validation: loss: 0.35338 
# 
# Epoch 16, coaching: loss: 0.25533 
# 
# Epoch 16, validation: loss: 0.35453 
# 
# Epoch 17, coaching: loss: 0.25085 
# 
# Epoch 17, validation: loss: 0.34521 
# 
# Epoch 18, coaching: loss: 0.24686 
# 
# Epoch 18, validation: loss: 0.35094 
# 
# Epoch 19, coaching: loss: 0.24159 
# 
# Epoch 19, validation: loss: 0.33776 
# 
# Epoch 20, coaching: loss: 0.23680 
# 
# Epoch 20, validation: loss: 0.33974 
# 
# Epoch 21, coaching: loss: 0.23070 
# 
# Epoch 21, validation: loss: 0.34069 
# 
# Epoch 22, coaching: loss: 0.22761 
# 
# Epoch 22, validation: loss: 0.33724 
# 
# Epoch 23, coaching: loss: 0.22390 
# 
# Epoch 23, validation: loss: 0.34013 
# 
# Epoch 24, coaching: loss: 0.22155 
# 
# Epoch 24, validation: loss: 0.33460 
# 
# Epoch 25, coaching: loss: 0.21820 
# 
# Epoch 25, validation: loss: 0.33755 
# 
# Epoch 26, coaching: loss: 0.22134 
# 
# Epoch 26, validation: loss: 0.33678 
# 
# Epoch 27, coaching: loss: 0.21061 
# 
# Epoch 27, validation: loss: 0.33108 
# 
# Epoch 28, coaching: loss: 0.20496 
# 
# Epoch 28, validation: loss: 0.32769 
# 
# Epoch 29, coaching: loss: 0.20223 
# 
# Epoch 29, validation: loss: 0.32969 
# 
# Epoch 30, coaching: loss: 0.20022 
# 
# Epoch 30, validation: loss: 0.33331 

Por la forma en que la pérdida disminuye en el conjunto de entrenamiento, concluimos que sí, el modelo está aprendiendo algo. Probablemente seguirá mejorando durante bastantes épocas todavía. Sin embargo, vemos menos mejoras en el conjunto de validación.

Naturalmente, ahora sentimos curiosidad por las predicciones de los conjuntos de pruebas. (Recuerde, para las pruebas elegimos el mes “particularmente difícil” de enero de 2014, particularmente difícil debido a una ola de calor que resultó en una demanda excepcionalmente alta).

Sin ningún bucle que codificar, la evaluación ahora se vuelve bastante sencilla:

web$eval()

test_preds <- vector(mode = "record", size = size(test_dl))

i <- 1

coro::loop(for (b in test_dl) {
  
  enter <- b$x
  output <- web(enter$to(gadget = gadget))
  preds <- as.numeric(output)
  
  test_preds[[i]] <- preds
  i <<- i + 1
  
})

vic_elec_jan_2014 <- vic_elec %>%
  filter(12 months(Date) == 2014, month(Date) == 1)

test_pred1 <- test_preds[[1]]
test_pred1 <- c(rep(NA, n_timesteps), test_pred1, rep(NA, nrow(vic_elec_jan_2014) - n_timesteps - n_forecast))

test_pred2 <- test_preds[[408]]
test_pred2 <- c(rep(NA, n_timesteps + 407), test_pred2, rep(NA, nrow(vic_elec_jan_2014) - 407 - n_timesteps - n_forecast))

test_pred3 <- test_preds[[817]]
test_pred3 <- c(rep(NA, nrow(vic_elec_jan_2014) - n_forecast), test_pred3)


preds_ts <- vic_elec_jan_2014 %>%
  choose(Demand) %>%
  add_column(
    mlp_ex_1 = test_pred1 * train_sd + train_mean,
    mlp_ex_2 = test_pred2 * train_sd + train_mean,
    mlp_ex_3 = test_pred3 * train_sd + train_mean) %>%
  pivot_longer(-Time) %>%
  update_tsibble(key = identify)


preds_ts %>%
  autoplot() +
  scale_colour_manual(values = c("#08c5d1", "#00353f", "#ffbf66", "#d46f4d")) +
  theme_minimal()

Predicciones con una semana de antelación para enero de 2014.

Figura 1: Predicciones a una semana de enero de 2014.

Evaluate esto con el pronóstico obtenido al retroalimentar las predicciones. Los perfiles de demanda a lo largo del día parecen mucho más realistas ahora. ¿Qué tal las fases de extrema demanda? Evidentemente, estos no se reflejan en el pronóstico, al igual que en la “técnica del bucle”. De hecho, el pronóstico permite obtener información interesante sobre la personalidad de este modelo: aparentemente, le gusta mucho fluctuar alrededor de la media; “prepárelo” con entradas que oscilen alrededor de un nivel significativamente más alto, y rápidamente regresará a su zona de confort.

Al ver cómo, anteriormente, brindamos una opción para usar la deserción dentro del MLP, es posible que se pregunte si esto ayudaría con los pronósticos en el conjunto de prueba. Resulta que no fue así en mis experimentos. Quizás esto tampoco sea tan extraño: ¿cómo, en ausencia de señales externas (temperatura), debería saber la purple que se avecina una gran demanda?

En nuestro análisis, podemos hacer una distinción adicional. Con la primera semana de predicciones, lo que vemos es una falta de previsión de algo que no pudo razonablemente se habían anticipado (dos o dos días y medio, digamos, de demanda excepcionalmente alta). En el segundo, todo lo que la purple habría tenido que hacer period permanecer en el nivel elevado precise. Será interesante ver cómo las arquitecturas que analizamos a continuación manejan esto.

Finalmente, una thought adicional que quizás haya tenido es: ¿qué pasaría si usáramos la temperatura como segunda variable de entrada? De hecho, el rendimiento del entrenamiento mejoró, pero no se observó ningún impacto en el rendimiento en los conjuntos de validación y prueba. Aun así, el código puede resultarle útil: se puede ampliar fácilmente a conjuntos de datos con más predictores. Por ello lo reproducimos en el apéndice.

¡Gracias por leer!

# Knowledge enter code modified to accommodate two predictors

n_timesteps <- 7 * 24 * 2
n_forecast <- 7 * 24 * 2

vic_elec_get_year <- operate(12 months, month = NULL) {
  vic_elec %>%
    filter(12 months(Date) == 12 months, month(Date) == if (is.null(month)) month(Date) else month) %>%
    as_tibble() %>%
    choose(Demand, Temperature)
}

elec_train <- vic_elec_get_year(2012) %>% as.matrix()
elec_valid <- vic_elec_get_year(2013) %>% as.matrix()
elec_test <- vic_elec_get_year(2014, 1) %>% as.matrix()

train_mean_demand <- imply(elec_train[ , 1])
train_sd_demand <- sd(elec_train[ , 1])

train_mean_temp <- imply(elec_train[ , 2])
train_sd_temp <- sd(elec_train[ , 2])

elec_dataset <- dataset(
  identify = "elec_dataset",
  
  initialize = operate(information, n_timesteps, n_forecast, sample_frac = 1) {
    
    demand <- (information[ , 1] - train_mean_demand) / train_sd_demand
    temp <- (information[ , 2] - train_mean_temp) / train_sd_temp
    self$x <- cbind(demand, temp) %>% torch_tensor()
    
    self$n_timesteps <- n_timesteps
    self$n_forecast <- n_forecast
    
    n <- nrow(self$x) - self$n_timesteps - self$n_forecast + 1
    self$begins <- kind(pattern.int(
      n = n,
      dimension = n * sample_frac
    ))
    
  },
  
  .getitem = operate(i) {
    
    begin <- self$begins[i]
    finish <- begin + self$n_timesteps - 1
    pred_length <- self$n_forecast
    
    record(
      x = self$x[start:end, ],
      y = self$x[(end + 1):(end + pred_length), 1]
    )
    
  },
  
  .size = operate() {
    size(self$begins)
  }
  
)

### relaxation equivalent to single-predictor code above

Foto por Mónica Bourgeau en desempaquetar

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles