Я встретился с командой Latent Space, чтобы обсудить лучшие практики совместной работы и управления итерацией модели. В машинном обучении ошибки могут влиять на распределение возможных моделей больше, чем какой-либо конкретный экземпляр, что делает традиционные детерминированные тесты ошибочными. По этой причине среда разработки на основе тестирования для больших моделей машинного обучения должна учитывать статистический характер обучения. Это особенно важно, когда несколько исследователей и инженеров вносят свой вклад в одну и ту же модель, поскольку легко незаметно ввести регрессии в кодовую базу. Здесь команда делится некоторыми мыслями о том, как эта новая форма разработки через тестирование стала ключом к быстрому продвижению крупномасштабного совместного проекта.
Latent Space демократизирует творчество с помощью ИИ. Они делают первый полностью 3D-движок с искусственным интеллектом, в котором пользователи создают сам мир и объекты в нем. Создание так же просто, как загрузка изображения в Instagram. Но когда вы загружаете в скрытое пространство, вы видите, как оно оживает в 3D. Принесите свой семейный автомобиль или «Тысячелетний сокол» в общий мир, который может выглядеть как что угодно, от Тадж-Махала до Винтерфелла. Этот новый уровень самовыражения обеспечивает большее разнообразие 3D-контента, решая одну из самых больших проблем в игровой индустрии.
Коротко о процессе
Чтобы быстро и уверенно работать с передовыми генеративными моделями вместе с командой, Latent Space нашла две важные стратегии:
- Полностью модульные модели.
- Тестирование со всей строгостью.
Полностью модульные модели
Latent Space построила то, что они называют системой блоков, в сочетании с инфраструктурой конфигурации gin, чтобы позволить им создавать новые генераторы, дискриминаторы, кодировщики, произвольные пропускные соединения или параметры настройки в файле конфигурации высокого уровня. Название было вдохновлено старой системой блоков Theano Theano от MILA. Дэррил Барнхарт, архитектор блочной системы, описывает ее преимущества:
- Ясность абстракции. Отделяя гиперпараметры от бизнес-логики прямых проходов и построения модели, конфигурации становятся способом проектирования модели более высокого уровня.
- Легкость абляции. Сравнить два варианта модели так же просто, как изменить несколько параметров в конфигурации, что значительно снижает барьер для экспериментов.
- Простота поиска гиперпараметров. Они используют функцию развертки W&B для запуска тысяч вариантов модели, чтобы найти наилучшую настройку. (Еще более экстремальным расширением этого является Поиск нейронной архитектуры, где модель машинного обучения управляет выбором архитектуры с еще большей степенью детализации.)
Структура их конфигурации иерархична. У них есть одна модель HEAD, которая представляет собой последние и наиболее эффективные изменения. Все остальное — «детская» конфигурация. Это делает абляции (A/B-тесты изменений) понятными: наследуйте от модели HEAD, изменяйте настройки, которые отличаются/новыми, и запускайте эту новую конфигурацию. Каждая конфигурация по сути является определением модели, и в W&B каждая конфигурация получает свой собственный тег.
Вот пример конфигурации джина:
Chase Basich в конфиге системы:
Одна вещь в нашей системе конфигурации, которая оказалась очень полезной, — это то, что система похожа на контрольную точку. Для любой функции мы можем легко найти конфигурацию, которая впервые представила эту функцию, чтобы увидеть канонический пример того, как она была настроена, а затем запустить эту конфигурацию. Затем мы можем использовать эту конфигурацию для поиска соответствующих прогонов и отчетов W&B. Например, недавно я исследовал регрессию, и это дало быстрый способ повторно запустить аблацию и сравнить новые и старые данные W&B.
Тестирование со строгостью
В поисках новой SOTA
Одна из вещей, которая изначально привлекла их в W&B, заключалась в том, что отчетами W&B можно делиться. Им понравилась идея связывать отчеты с запросами на вытягивание. Запросы на извлечение происходят, когда код объединяется с их веткой разработки и когда они меняют свои конфигурации модели HEAD. Иметь статистику, доказывающую, что набор изменений является улучшением их модели, было очень заманчиво.
Сначала они сравнили среднее и минимальное/максимальное значение нескольких запусков из ветки с HEAD.
Если вы запускаете одну и ту же конфигурацию много раз, вы получите разные результаты в зависимости от инициализации модели, случайного чтения загрузчика данных в случайном порядке или параллельного характера операций графического процессора. Более того, они поняли, что заботятся не только об улучшении среднего или даже минимального/максимального значений. Если бы изменение не повлияло на среднее/минимальное/максимальное, но значительно уменьшило дисперсию, это был бы выигрыш. Такие изменения делают сигнал более четким и сокращают количество необходимых прогонов.
Даже во время разработки команда запускает тренировочный прогон более 10 раз для каждого своего изменения. Используя внутреннюю облачную настройку, они могут запускать их все параллельно, а затем анализировать их изменения в W&B.
Чтобы сообщить, как изменения улучшают их модели, все их запросы на включение кода используют следующий шаблон:
Они используют один или несколько тегов W&B для каждой конфигурации, а затем используют разные наборы запусков (с соответствующими им тегами) в одном и том же разделе отчета, чтобы свести воедино разные ветви эксперимента.
Советы от Джеффа Линга:
В W&B каждая из наших конфигураций сопоставляется с одним или несколькими тегами. Вот как мы находим релевантные прогоны. Мы используем теги с отчетами, чтобы показать A/B-сравнение изменения конфигурации. Например, если я проверяю влияние новой функции, я нахожу модель головного облака и конфигурацию с этой функцией и добавляю один и тот же тег в обе. Когда я запускаю оба, они появляются в моем отчете.
Предотвращение регрессии
Согласно Саре Джейн Хонг,
Модели машинного обучения трудно отлаживать из-за их адаптивного характера. если у вас есть ошибка (или много!), модель все еще может работать адекватно. Самые коварные формы ошибок — это те, которые выходят из строя незаметно. Это может варьироваться от чего-то непреднамеренного, такого как передача выходных данных softmax, до потери, которая ожидает необработанные логиты, или настолько незаметной, как случайная передача тензора где-то в вашей модели.
У них есть ежечасные, ночные и еженедельные интеграционные тесты, а также модульные тесты для каждого PR. Тесты используются для того, чтобы убедиться, что их модели не будут работать хуже по мере внесения новых изменений. Чем чаще проводится интеграционный тест, тем короче его продолжительность. У прогонов есть несколько ключевых показателей (для них это включает Начальное расстояние Фреше), и любой из них можно сравнить с распределением базовых прогонов.
Получение быстрых и достоверных отзывов о новых функциях играет центральную роль в автоматизированном тестировании Latent Space. Они используют смесь частотных и байесовских методов для сравнения старых и новых распределений, но все чаще полагаются на байесовские подходы для более быстрого обновления своих убеждений на основе новых данных (каждый запуск и субметрики в рамках цикла представляют новые данные). Большинство тестов включают сравнение двух дистрибутивов: предыдущего дистрибутива из более ранней конфигурации/фиксации и нового дистрибутива для выполняемого интеграционного теста, PR или абляции/зачистки. По мере того, как компания Latent Space масштабировала свои генеративные модели, более совершенный автоматизированный статистический анализ становился все более полезным по мере того, как расширялся их режим обучения. Это создает быструю петлю обратной связи для добавления новых функций и понимания их эффекта в масштабе при минимальных затратах.
Они также рассматривают чрезвычайно необычные «хорошие» результаты как провал. Если бы их ждали, они должны были прийти с PR и установить новые базовые прогоны. Если это неожиданно, вероятно, есть новая ошибка в том, как рассчитывается метрика, и на самом деле она не улучшена.
Наконец, у них есть модульные тесты, которые запускаются через CircleCI на каждом PR, чтобы гарантировать, что модель все еще может механически обучаться, а ключевые функции всегда работают должным образом.
Вывод
Тщательный подход Latent Space к координации улучшений моделей показался мне примером продуманной и воспроизводимой структуры для выхода за рамки передового опыта в отрасли.
Одной из самых интересных частей системы Latent Space является использование составных блоков. Они более подробно расскажут об этом в следующем посте. Приготовьтесь узнать, как этот вариант дизайна позволяет команде просматривать различные архитектуры, а не просто настраивать гиперпараметры!
Если вы нашли этот пост в блоге интересным или ценным, не стесняйтесь поделиться им с другом! Их команда всегда рада обратной связи — свяжитесь со мной по адресу [email protected] по любым вопросам или [email protected], чтобы узнать, как использовать W&B в вашей компании.
