Ноуты 14_embedding/full_capacity_emb_02.ipynb, 14_embedding/over_capacity_emb_01.ipynb. В них наткнулся на знакомый мотив автоэнкодеров “туда и обратно”. Стало интересно, является ли декоррелятор фичей из этих ноутов реализацией автоэнкодера. Ну или наоборот - является ли автоэнкодер реализацией декоррелятора фичей.

С т.з. вычисления/синтаксиса MlpModel из 14_embedding/over_capacity_emb_01.ipynb полностью повторяет декоррелятор фичей.

На радостях, решил проверить на старом добром 10_denoise/s3_stacked_dae_09.ipynb, будут ли декоррелироваться фичи. Ведь Pascal Vincent нам обещал, что линейный автоэнкодера без нелинейностей делает PCA. А в PCA как раз некоррелированные фичи. Мучался долго и так и этак, но декорреляцию фичей не обнаружил. Причем проверял и колонки, и строки слоя nn.Linear в автоэнкодере.

Решил упростить задачу и вернулся в рамках 14_embedding/full_capacity_emb_02.ipynb к простому примеру: картинка 3х3, линейный автоэнкодер, хотим получить PC компоненты. Как оказалось, это не так просто, хотя и не так сложно. Ключевые ингредиенты: 1) регуляризация на ортонормальность 2) лосс функция, которая бы вела к иерархическому variance ordering

Без этих приседаний фичи вполне себе будут коррелированы, а лосс около нулей. Было очень много приседаний и интенстивные диалоги с Gemini: linear_autoencoder_and_pca.ipynb, projection_vs_linear_combo.ipynb

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

Также выжимки из 14_embedding/full_capacity_emb_02.ipynb:

Изначальный вердикт был таким: “In Model features (axes, directions) are in rows, in MlpModel features (axes, directions) are in columns”. Так и взаправду можно смотреть, если придерживаться точки зрения, что вычисляется линейная комбинация входного вектора с колонками MlpModel (там ведь транспонирование выполняется и мы получаем 4-ую мнемонику).

Но тут надо быть осторожным! nn.Linear это больше про ПРОЕКЦИЮ, нежели про ЛИНЕЙНУЮ КОМБИНАЦИЮ. Это всё из-за двойственности матричного умножения. Особенно легко запутаться, когда embedding_size == features_bank_size. См. эпопею с full_capacity_emb_02.ipynb, а также диалоги linear_autoencoder_and_pca.ipynb, projection_vs_linear_combo.ipynb.

Также ПРОЕКЦИОННЫЙ режим становится понятным, если представить или нарисовать визуальную модель автоэнкодера, где слева идёт входной вектор, а далее полносвязный слой энкодера. Так вот, связи от входа к нейронам энкодера, они направленные (directed) и как бы намекают на то, что каждый нейрон через свои веса “впитывает” данные из ВСЕГО входного вектора. А это и есть проекция. Конечно, можно смотреть и по-другому, как будто каждый входной нейрон “распыляет” своё значение по нейронам энкодера, но это интуиция более слабая и, кажется, не ведёт к полезным конструкциям.

Учитывая всё это, более правильный вывод такой, что в nn.Linear фича векторы тоже в строках, просто внутри nn.Linear.forward() делается транспонирование, и таким образом мы получаем проецирование входных данных на эти векторы. И из этого можно собрать PCA анализатор. А когда features_bank_size > embedding_size, то мы получаем bottleneck, т.е. пытаемся описать данные меньшим кол-во фича векторов (principal components). Если features_bank_size < embedding_size, то получаем overcomplete и тут уже другая история, например, можно делать sparse coding.

Ещё более правильный вывод - it depends. На самом делё все зависит от того, как мы интерпретируем колонки/строки в MlpModel в окружающем коде. Какие регуляризации, на что? Нормализация, чего? И т.д. Т.е. если смотреть изолированно, что и проекционная и комбинационная точки зрения - обе равноправны. Но если начать принимать во внимание окружающий код, то скорее всего останется только одна т.з.

Поэтому, да. Вполне можно использовать MlpModel вместо MainModel. Просто в этом случае надо дополнительно настраивать мозги, что это будет не совсем типичное применение, т.е. не проекционное, а комбинациоое.