Додавання функцій до моделі часових рядів LSTM

читав трохи про LSTM та їх використання для часових рядів, і це було цікаво, але важко водночас. Одне, що у мене виникли труднощі з розумінням, - це підхід до додавання додаткових функцій до того, що вже є переліком функцій часових рядів. Припустимо, що у вас є такий набір даних так:

t-3, t-2, t-1, вихід

Тепер давайте скажемо, що ви знаєте, що у вас є функція, яка впливає на вихід, але це не обов'язково функція часового ряду, давайте скажемо, що її погода зовні. Це щось, що ви можете просто додати, і LSTM зможе розрізнити, що таке аспект часового ряду, а що ні?

Для RNN (наприклад, LSTM та GRU) введення шару - це список часових кроків , а кожен часовий крок - тензор функції. Це означає, що у вас може бути такий вхідний тензор (у пітонічній нотації):

# Input tensor to RNN
[
    # Timestep 1
    [ temperature_in_paris, value_of_nasdaq, unemployment_rate ],
    # Timestep 2
    [ temperature_in_paris, value_of_nasdaq, unemployment_rate ],
    # Timestep 3
    [ temperature_in_paris, value_of_nasdaq, unemployment_rate ],
    ...
]

Таким чином, ви можете мати кілька функцій на кожному кроці. На мій погляд, погода - особливість часових рядів: там, де я живу, це, можливо, є функцією часу. Тож було б цілком розумно кодувати інформацію про погоду як одну з ваших особливостей у кожному часовому кроці (з відповідним кодуванням, наприклад, хмарно = 0, сонячно = 1 тощо).

Якщо у вас є дані, що не є часовими рядами, передати їх через LSTM не має сенсу. Можливо, LSTM все-таки спрацює, але навіть якщо це станеться, це, ймовірно, вийде ціною більшої втрати / меншої точності за час навчання.

Крім того, ви можете ввести подібну "зайву" інформацію у вашу модель поза LSTM за допомогою додаткових шарів. У вас може бути потік даних таким:

TIME_SERIES_INPUT ------> LSTM -------\
                                       *---> MERGE ---> [more processing]
AUXILIARY_INPUTS --> [do something] --/

Таким чином, ви об'єднали б ваші допоміжні входи до виходів LSTM і продовжували свою мережу звідти. Тепер ваша модель просто багатокористувацька.

Наприклад, скажімо, що у вашій конкретній програмі ви зберігаєте лише останній висновок вихідної послідовності LSTM. Скажімо, що це вектор довжиною 10. Ви допоміжним входом можуть бути кодованою погодою (таким чином, скалярною). Ваш шар злиття може просто додати допоміжну інформацію про погоду на кінець вихідного вектора LSTM, щоб отримати єдиний вектор довжиною 11. Але вам не потрібно просто зберігати останній часовий крок виходу LSTM: якщо LSTM виводить 100 часових кроків, кожен з 10-векторними функціями ви все ще можете скористатись вашою допоміжною інформацією про погоду, в результаті чого з'явиться 100 кроків часу, кожен з яких складається з вектора з 11 точок даних.

Документація Keras у своєму функціональному API має хороший огляд цього.

В інших випадках, як вказує @horaceT, можливо, вам потрібно встановити LSTM на не тимчасових даних. Наприклад, прогнозуйте погоду завтра за вказаним місцем розташування. У цьому випадку наведено три пропозиції, кожна з позитивних / негативних:

1. Запропонуйте перший крок часу містити ваші умови кондиціонування, оскільки він ефективно "встановить" внутрішній / прихований стан вашого RNN. Чесно кажучи, я б цього не робив з низки причин: ваші дані кондиціонування повинні мати таку ж форму, як і решта ваших функцій, ускладнює створення справжніх RNN (з точки зору того, щоб бути дуже уважними для відстеження, як ви подаєте дані в мережу), мережа може «забути» дані кондиціонування за достатньо часу (наприклад, тривалі послідовності тренувань або довгі послідовності передбачення) тощо.

2. Включіть дані як частину самих тимчасових даних. Отже, кожен функціональний вектор у конкретному часовому кроці включає дані "переважно" часових рядів, але потім дані кондиціонування додаються до кінця кожного вектора ознак. Чи навчиться мережа впізнавати це? Напевно, але вже тоді ви створюєте більш важке навчальне завдання, забруднюючи дані послідовності непослідовною інформацією. Тож я б також перешкодив цьому.

3. Напевно, найкращим підходом було б безпосередньо впливати на прихований стан RNN в нульовий час. Такий підхід застосовують Карпатія та Фей-Фей та Vinyals та ін . Ось як це працює:

   1. Для кожного зразка тренінгу візьміть змінні стану .$\vec{x}$
   2. Перетворіть / змініть свої змінні стану афінним перетворенням, щоб отримати його у правильній формі як внутрішній стан RNN: (ці і це треновані ваги). Ви можете отримати його з щільним шаром у керах. W → $\vec{v} = \mathbf{W} \vec{x} + \vec{b}$$\mathbf{W}$$\vec{b}$
   3. Для першого кроку часу додайте до прихованого стану RNN при обчисленні його значення.$\vec{v}$

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

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

https://github.com/philipperemy/cond_rnn/ (tensorflow)

Сподіваюся, це допомагає!

Є функція в керах LSTM reset_states(states).

Однак стан параметрів - це контиматизація двох станів, прихованого стану h та стану комірки.

States = [h, c]

було б цікаво дізнатися, чи варто ініціалізувати hчи cвідповідно до підходів у вищезгаданих документах.

Це, мабуть, не найефективніший спосіб, але статичні змінні можуть бути повторені на довжину тимчасових серій, використовуючи tf.tile().