Ноут s3_stacked_dae_07.ipynb.

Сущностные моменты: 1) чисто визуально stacked dae работает. На первом уровне выделяются фильтры, на втором и третьем что-то даже происходит по восстановлению испорченных данных 2) пытался прикрутить SVM поверх фичей не третьем слое. Сам-то SVM прикрутился, но только результаты (accuracy) классификации получились максимум 98.17%. Тогда в статье идёт речь вообще о >99%. 3) SVM прикручивал как LinearSVC, так и SVC c kernel=’rbf’ 4) показатель 98.17% через GridSearchSV получил. Хотя возможно можно ещё поиграться с параметром регулиризации C. Я его достаточно консервативно крутил в пределах от 0.01 до 10, м.б. лучше будут значения более агресивные. 5) cuml - хорошая штука. Жаль только, что не работает с мультиклассовой классификацией через SVC =( 6) cuml конфликтует по депендам с torch. И тот и другой почему-то любят приколачивать гвоздями конвретные версии cuda-пакетов. В итоге пришлось сделать отдельный env в конде, где стоит cuml и CPU-шный торч. А чтобы можно было cuml-ом пользоваться используется хак с ipykernel install - регистрируем kernel в основном env и запускаем ядро с cuml по кнопке из Jupyter. 7) после долго чтения статьи понял, что зря сразу ломанулся прикручивать SVM. У авторов это было как факультативное занятие. Правильнее сделать классификационную нейронку, у которой внизу SDAE. И после того, как уже получены хорошые результаты, использовать SDAE для SVC. Собственно авторы так и делали 8) важно уметь конструировать МАШИНЫ СИСТЕМНОГО ПОИСКА оптимального сочетания параметров. Этим и надо заняться. А то с SVM как-то тяжко получется - слишком много переключений. 9) усматривается прямая связь между [OlshausenEmergeCellRecF, OlshausenNatImgStats, OlshausenSparseWithOvercompl] и [VincentStackedDenoisingAE]. В первой группе работ явно артикулируется генеративная модель картинки. Типа есть избыточный набор паттернов (фильтров) и любая картинка собирается из линейной комбинации этих паттернов. При этом требуется, чтобы в сборе участвовало небольшое кол-во фильтров (условие sparseness). Условия sparseness при обучении достигается путем внедрения штрафной функции (используется $log(1+x^2)$, хотя авторы писали и про другие типа $|x|$ или $-e^{-x^2}$). В [VincentStackedDenoisingAE] по факту опять же имеем дело с фильтрами, которые облачены в форму автоэкондера. При этом авторы используют tied weights, что почти один в один соответствует модели Olshausen. Единственное значимое различие - это то, что штраф на sparseness не используется, а вместо этого используется тренинг на noised данных. Хотя, есть подозрение, что штраф не помешает. В работе Olshaues по факту loss функция есть MSELoss + штраф на sparseness, в работе Pascal loss функция есть BCELoss. 10) Dropout как замена ручному noising? По факту делает тоже самое. Надо проверить

Инфраструктурные моменты: 1) tensorboard умеет показывать в динамике картинки - можно слайдером смотреть эволюцию сквозь эпохи 2) на tensoboard удобно выгружать всякие метаданные в виде текста. Удобно туда выгружать гиперпараметры, с которыми тренилась модель, т.к. когда вариантов больше 5 становится, то без учёта уже вообще ничего непонять (всё забывается) 3) артефакты модельные (веса, параметры оптимизатора и прочие бинарные и не обязательно данные) удобно в nexus выгружать. 4) nexus также выступает единой точкой выдачи идентификаторов моделей 5) единые идентификатора модели нужны для централизованного сбора метрик с разных машин: с баки, с ноута 6) единые идентификаторы модели нужны для учёта артефактов (см. пункт 3) 7) сейчас немного неудобно то, что для выгрузки метрик на баки, требуется монтировать по sshfs папку tensorboard в ноута. Неудобство в том, что при включении/выключении баки точка монтирования теряется, а при повторном монтировании нужно вводить пароль. Конечно, можно через automount изловчиться и ещё ssh ключами обменяться, но как-то всё это бее. 8) Думаю, что идеально было бы организовать сбор tfevents по рэббиту. Но тогда придётся написать кастомный код, т.к. SummaryWriter из торча умеет только в файл писать 9) концептуально полезно разделять ноут на два режима работы: мастер и слейв. В мастер режиме собственно набивка кода, отладка и проч. А вот уже запуск тренинга модели в слейв режиме. В слейв режиме уже идёт выгрузка на tensorboard, учётные операции и прочее. Такое разделение как-то упорядочивает разработку. 10) для 9) разработан механизм launchit, который с помощью специальных комментов в ячейках позволяет создавать слейв ноуты из мастера