Как применить ML-технологии из большого энтерпрайза в маленьком пет-проекте. Опыт студента ИТМО

Привет! Меня зовут Андрей, я студент ИТМО. В рамках вузовской практики в NSS-лаборатории я участвовал в разработке решения для моделирования движения льда в Арктике. Те же технологии можно применить и в личном проекте. Для этого понадобятся свертки CNN-моделей и библиотека, которую я написал во время практики.

Используйте навигацию, если не хотите читать текст полностью:

→ Зачем нейросети в Арктике

→ Чем хороши свертки

→ Хорошие практики open-source проектов

→ Разработка ключевых функций

→ Шаблоны моделей

→ Тестирование

→ Итог

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

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

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

Решаемая задача — прогнозирование n-мерного временного ряда (в нашем случае изображения — это одноканальные тензоры). Для искушенных читателей приведу статьи, сотрудников NSS-лаборатории, которые рассматривают применение сверточных нейросетей для предиктивной аналитики, немного их модернизируют и наглядно демонстрируют жизнеспособность такого подхода:

Чтобы спрогнозировать изменения изображений, можно использовать сверточные нейронные сети. Они легче рекуррентных аналогов, формально более подходящих для данных вида временной последовательности. К тому же, мы работаем с изображениями карт, которые удобно обрабатывать именно свертками. Почти наверняка кто-то сможет предложить альтернативы для более легкого инференса, а также улучшения и дополнения полученного решения — с удовольствием изучу все в комментариях.

Для понимания работы сверточных нейросетей представим изображение как матрицу, где каждый пиксель — отдельное число. Нам хочется извлечь из нее полезные признаки, не забыв про вычислительные сложности и уменьшив при этом все изображение. Для этого мы проходимся некоторым ядром (другой матрицей) по нашей картинке и поэлементно сначала умножаем, а потом складываем все значения, получая на выходе меньшую по размерам матрицу.

Найти оптимальный вид сверточной нейронной сети — значит понять, какое количество слоев нужно, какие параметры и настройки должны у них быть, какие функции активации использовать, какие дополнительные слои нормализации подставить и т. д. Для этого нужно перепробовать много вариантов, а это не совсем приятная история:

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

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

Следующий вопрос — в каком формате должен быть проект? На мой взгляд, наиболее удобный и простой в использовании вариант почти для любой среды разработки — открытый фреймворк. Его можно применять почти везде и он позволит создать действительно универсальный инструмент.

В качестве стека я выбрал PyTorch и последующую выкатку библиотеки через pip, т. к. у проекта нет никаких других сторонних зависимостей. Это одно из ключевых его преимуществ. Если же у вас более комплексное решение с десятками строк в requirements, то есть смысл посмотреть в сторону poetry.

Структура проекта

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

Здесь внутри файла builder.py будут храниться функции, отвечающие за класс «строитель». Он вызывает свои методы и строит сверточные последовательности модели или просто стакает друг за другом слои torch.

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

В models.py лежат готовые шаблоны сверточных моделей, которые написаны с помощью автоматически строящихся последовательностей из Builder. Таким образом, получается следующая идея проекта:

В моем случае значительная часть функций уже реализована, поскольку код взят из уже упомянутой статьи Forecasting of Sea Ice Concentration using CNN, PDE discovery and Bayesian Networks. Но даже так требуется серьезный рефакторинг. Разработка общего пайплайна и дизайна всей системы по факту уже является его первым этапом.

Зачем нужен рефакторинг, если код и так работает?

Код для научной статьи и продакшен-решение — разные сущности, т. к. они преследуют разные идеи. Во втором случае меня интересует масштабируемость предложенных идей и практическая реализация решения в контексте нескольких сценариев использования. В идеале бы хотелось совместить лучшие практики из обеих областей: воспроизводимость, читабельность, масштабируемость, работоспособность, хорошую оптимизацию и т. д.

Следуя всем канонам удобных и приятно читаемых open source проектов, я выполнил три простых действия (помимо разработки и доработки ключевых функций):

Для будущей публикации библиотеки советую пройтись по следующим ссылкам:

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

Предобработка

Итак, основной архитектурой выбрана сверточная нейронная сеть. Теперь нужно понять, в каком виде подавать в нее данные.

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

В подобной постановке модель можно обучать по-разному: поделить весь датасет на «до» (X часть) и «после» (Y часть) или двигаться некоторым окном, где по конкретному фиксированному числу X сэмплов можно предсказывать фиксированное число Y сэмплов. Иногда первый случай удобнее, а иногда хочется свести задачу к виду «по 30 предыдущим дням хочу предсказывать 10 следующих». Для обоих случаев реализованы функции single_output_tensor и multi_output_tensor.

Кстати, один объект (one frame на картинке, в нашем случае — карта льда) гипотетически может иметь любую размерность и быть разным по своей природе: от n-мерного вектора до n-мерного тензора.

На самом деле, мы просто итерируемся в цикле по каждому тензору, агрегируя их в «группы». Закономерный вопрос — разве single_output_tensor не является частным случаем multi_output_tensor? Так и есть, но, признаюсь, я сделал две отдельные функции, т. к. в рамках одной попросту не смог удачно организовать и структурировать код, сохраняя дополнительные возможности:

Пример вызова функции со всеми параметрами выглядит следующим образом:

А таким кодом можно проверить, какие размерности внутри батчей мы получили:

Вывод кода:

Соответствующие примеры и подробную документацию с описанием всех параметров, классов и функций для preprocess можно найти в директории examples.

Сверточные последовательности

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

На данный момент в PyTorch есть поддержка одномерных, двумерных и трехмерных сверточных и транспонированных (в некотором смысле «обратных») сверточных операций. По итогу получим шесть функций. Также отмечу, что каждое измерение (условно «высота», «ширина» и т. д.) считается аналогично. Это значит, можно сделать всего одну функцию для подсчета одного измерения, а далее использовать ее во всех остальных случаях n раз для n измерений. Дальнейшие формулы взяты из документации nn.Conv2d и nn.TransposeConv2d и учитывают сразу несколько параметров:

Формула подсчета output измерения после сверточной операции:

Формула подсчета output измерения после транспонированной сверточной операции:

Теперь есть удобные функции, которыми можно подсчитать output измерения по любым заданным пользователем параметрам. Есть также параметр n_layers, который можно использовать, если хочется понять, каким будет выход свертки после нескольких одинаковых идущих друг за другом слоев (внутри обычный цикл):

Выход скрипта:

Сами сверточные последовательности построю в классе Builder. Идея следующая — инициализирую класс с input размерностями, а с помощью методов этого класса строю блок за блоком сверточные слои. Каждая сверточная последовательность — это nn.Sequential объект, который состоит из подблоков. Внутри блока выстраивается логика «слой свертки -> слой нормализации -> слой функции активации».

А зачем отдельно создавать блоки, которые все равно потом все находятся в одной большой последовательности? Дело в том, что в какой-то момент мне захотелось попробовать сделать слои из U-Net архитектуры, где есть несколько идущих подряд почти одинаковых сверток, которые на выходе не меняют изначальный размер тензора. К тому же такая гибкость позволяет потенциально отдельно настраивать каждый блок (хотя это пока в полной мере не реализовано в коде).

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

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

Параллельно проверяю допустимое количество каналов после каждого слоя. Обычно увеличение или уменьшение их числа происходит по экспоненте. Хотелось бы как-то ограничить диапазон изменения количества каналов. Для этого стоит добавить параметры max_channels и min_channels. Если они нарушаются, опять же выбрасываю кастомную ошибку.

Также я адаптировал и имплементировал другой метод расчета каналов, который рассчитывается пропорционально изменению размеров output тензора (его предложили коллеги постарше). В документации examples про это тоже можно почитать подробнее. На деле он просто дает последовательность, которая растет с гораздо меньшей скоростью:

На выходе из такого скрипта получаем:

Как видно, получился уже неплохой костяк сверточной сети. Если хочется более гибкий инструмент, блоки можно строить и по отдельности. В обоих случаях есть возможность указывать тип нормализации (пока это dropout и batchnorm) и его параметры, а также параметры самих сверток вместе со способом подсчета каналов:

Результат:

Отмечу, что размерность нормализации и сверточных операций автоматически подстраивается под размерность input тензора (dim может быть равно 1, 2 или 3). Зачастую в лаборатории мы пользуемся свертками на одну размерность меньше, чем наш input. Например, трехмерные RGB-изображения обрабатываем с помощью Conv2d, но формально можно это делать и с помощью Conv3d. Для таких случаев есть возможность регуляризации параметра conv_dim:

Результат:

Весь инструмент адаптирован также для транспонированных сверточных операций, нужно просто добавить transpose перед словом convolve. Единственное отличие в том, что у транспонированного блока можно убрать функцию активации, т. к. предполагается, что эти слои могут находиться в финальной decoder части, где не всегда нужна активация.

На самом деле, транспонированные и обычные сверточные операции не полностью взаимно обратные. Это проявляется в изменении размеров output тензоров в зависимости от четности/нечетности параметров свертки. По этим причинам в конце транспонированной последовательности стоит nn.AdaptiveAvgPool2d, который сглаживает эту разницу в «один пиксель».

Результат:

В последней части API models будут храниться шаблоны сверточных архитектур, которые сделаны с помощью автоматически собираемых последовательностей. Пока там только одна модель — Forecaster Model, которая состоит из сверток в encoder части и транспонированных сверток в decoder части. И именно ее и будем использовать для прогнозирования новых карт распространения льда.

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

Класс Builder хранит в себе историю размерностей и каналов последней сверточной последовательности, что было достаточно легко реализовать за счет аналитических формул проверки (просто в каждой итерации делаем append результата в общий список). А это значит, что и каждая модель, реализованная через класс Builder, тоже хранит в себе подобную историю.

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

Лучший результат я получил при другой конфигурации модели, нежели в примере выше. Пришлось отказаться от батчнормализации, поставить сигмоиду в качестве финальной функции активации и обучать вместе с кросс-энтропией. На деле я просто заставил модель запомнить видеоряд и идеально его воспроизводить с какого-то момента:

Для настоящих данных на арктических морях тоже было опробовано большое количество настроек модели (комбинации loss-ов, наличие или отсутствие нормализации, разные функции активации, количество слоев, размеры ядер сверток и т.д.). На момент выхода статьи Forecasting of Sea Ice Concentration using CNN, PDE discovery and Bayesian Networks одними из лучших вариантов были модели, обученные на L1 и SSIM лоссах. Но эксперименты с архитектурой и алгоритмом обучения до сих пор продолжаются.

Ниже представлено два ряда графиков из упомянутой статьи: карты распределения толщины льда в непрерывном диапазоне от 0 до 1 и карты кромки льда, полученные за счет бинаризации по заранее выбранному трешхолду. Результаты моделей сравнивались по двум критериям одновременно, т. к. важна не только толщина, но и граница распространения.

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

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

Надеюсь, мой опыт решения очень маленькой, но вполне прикладной и конкретной задачи поможет найти вдохновение в поиске темы для своего первого ML-проекта.

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

#selectel #ml #machinelearning #cnn #машинноеобучение #свертки #нейросети #арктика #python #петпроект