Мы рады сообщить о выпуске третьей основной версии нашего фреймворка оптимизации гиперпараметров Оптуна. Обязательно ознакомьтесь с примечаниями к выпуску!

Мы выпустили первую основную версию Optuna в январе 2020 года и вторую основную версию в июле 2020 года, и с тех пор значительно выросли как пользователи, так и сообщества разработчиков. Что касается пользовательского сообщества, Optuna загружается 1,43 миллиона раз в месяц и имеет более 6800 звезд на GitHub. Начиная с версии 2.0, сообщество разработчиков выросло до 177 участников и 1225 PR.

Мы разработали v3.0 со следующими целями:

  • Откройте направление разработки для сообщества
    — обсуждайте вопросы разработки с помощью общедоступной дорожной карты и вопросов GitHub.
  • Повышение стабильности
     – Значительное уменьшение неоднозначности в спецификации
     – Определение необходимости одобрения экспериментальных функций для нормального использования.
  • Предоставьте всем пользователям полезные функции и алгоритмы
    – Улучшите производительность с помощью аргументов по умолчанию
    – Повысьте доступность существующих функций/алгоритмов для простых пользователей. (Целевые функции/алгоритмы, о которых пользователи могут не знать, например, многомерный TPE, постоянный лжец и т. д.)

В этом блоге мы расскажем, как Optuna развивалась на протяжении всего процесса.

TL;DR

  • Мы обнародовали дорожную карту разработки и разработали версию 3.0 в сотрудничестве со многими участниками.
  • Упрощение API, стабилизация и рефакторинг функций, с которыми часто сталкиваются пользователи, были сделаны для повышения стабильности фреймворка.
  • Впервые был проведен обширный бенчмаркинг алгоритмов для проверки полезности функций, представленных до версии 3.0.
  • Многие новые функции, которые изначально не были частью дорожной карты, были представлены с помощью различных участников.

Сотрудничество с контрибьюторами

Мы поняли, что для успеха версии 3.0 потребуется больше, чем просто коммиттеры (мейнтейнеры Optuna); для этого потребуются объединенные усилия многих участников. Чтобы некоммиттерам было проще понять, как будет происходить разработка версии 3.0, мы сохранили выпуск GitHub и составили дорожную карту, доступную на GitHub wiki. Мы также организовали спринты разработчиков, чтобы ускорить разработку версии 3.0 и облегчить общение между коммиттерами и участниками. Всего спринты разработки проводились 6 раз, в них участвовало много участников и набралось много PR. Мы начали в Японии, чтобы выяснить, разумно ли это, и теперь планируем продолжить спринты разработки. Всемирная версия также находится на рассмотрении. Следите за обновлениями.

Улучшенная стабильность

Optuna имеет ряд основных API. Одним из них является API предложений и класс optuna.Study. Модуль визуализации также часто используется для анализа результатов. Многие из них были упрощены, стабилизированы и реорганизованы в версии 3.0. Вот краткое описание того, как изменились эти функции.

Упрощенный API предложений

Предлагаемый API используется для выборки параметров из области поиска. В версии 3.0 API предложений был объединен в 3 метода: suggest_float для параметров с плавающей запятой, suggest_int для целочисленных параметров и suggest_catagorical для категориальных параметров. Вариации теперь могут быть указаны аргументами этих методов. Используя этот более простой API предложений, вы сможете писать более читаемый и удобный для сопровождения код.

Например, давайте посмотрим, как изменилось предложение параметра с плавающей запятой из серии v2 в v3.0. Если вы хотите попробовать параметр с плавающей запятой x между low и high, сделайте следующее.

Если вы хотите сосредоточить поиск рядом с low в диапазоне, вы можете сделать следующее.

Если вы хотите сделать выборку из дискретного набора, такого как low + k, low + 2 * k, low + 3 * k, …,, вы можете сделать это следующим образом.

Как видите, в версии 3.0 метод предложения для выборки параметров с плавающей запятой был упрощен до suggest_float.

Упрощение предлагаемого API стало возможным благодаря помощи следующих участников. Спасибо! @himkt, @nyanhi, @nzw0301 и @xadrianzetx.

Введение политики тестирования

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

Разработка политики тестирования и модификация модульных тестов на ее основе стала возможной благодаря многим участникам. @HideakiImamura, @c-bata, @g-votte, @not522, @toshihikoyanase, @contramundum53, @nzw0301, @keisuke-umezawa и @knhnb.

Рефакторинг визуализации

Оптуна может использоваться не только для оптимизации, но и для анализа результатов оптимизации. В настоящее время модуль визуализации в Optuna предоставляет два модуля: один для визуализации с использованием Plotly в качестве серверной части (функции визуализации в optuna.visualization), а другой для визуализации с использованием Matplotlib (функции визуализации в optuna.visualization.matplotlib). Исторически первое было реализовано первым, а второе было введено экспериментально через некоторое время. До сих пор они разрабатывались отдельно, что приводило к таким проблемам, как отсутствие возможностей одного в другом, несогласованность стилей и нежелательные различия во внутренней реализации.

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

@HideakiImamura, @IEP, @MasahitoKumada, @TakuyaInoue-github, @akawashiro, @belldandyxtq, @c-bata, @contramundum53, @divyanshugit, @divyanshugit, @dubey-anshuman, @fukatani, @harupy, @himkt, @kasparthommen , @keisukefukuda, @knshnb, @makinzm, @nzw0301, @semiexp, @shu65, @sidshrivastav, @takoika и @xadrianzetx.

Стабилизированные функции

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

Стабилизация этих функций стала возможной благодаря многим участникам. Спасибо! @contramundum53, @knshnb, @HideakiImamura и @himkt.

Проверка производительности

Optuna реализует ряд алгоритмов оптимизации для решения задач оптимизации черного ящика. Текущим значением по умолчанию является байесовский алгоритм оптимизации, называемый древовидной оценкой Парзена (TPE). Во-первых, в версии 3.0 мы опубликовали следующую таблицу, обобщающую эмпирически известное поведение алгоритмов и особенности их реализации в Оптуне. Таблица призвана помочь выбрать правильный алгоритм оптимизации для конкретной задачи.

Однако этого недостаточно для количественной оценки производительности алгоритма. Мы разработали тестовую среду для оценки производительности алгоритмов Оптуны в версии 3.0 и провели эксперименты по оценке производительности с целью изменения алгоритма по умолчанию или аргументов алгоритмов по умолчанию. Ниже приведены краткие описания тестовой среды и экспериментов по оценке производительности.

Эталонная среда

При разработке эталонной среды мы считали важным, чтобы любой мог легко воспроизвести эксперимент. Среда бенчмаркинга состоит из скриптов для решения конкретных проблем путем указания семплеров и секаторов, а также механизма их запуска в GitHub Actions. В настоящее время в Optuna доступно более 170 задач, включая оптимизацию гиперпараметров машинного обучения и известные тестовые функции. Пользователи и участники могут запускать сценарии в своей локальной среде или легко запускать рабочий процесс в своей собственной ветке Optuna с помощью GitHub Actions. Чтобы узнать больше о тестовой среде, пожалуйста, проверьте здесь.

Многие участники участвовали в реализации тестовых сценариев и рабочего процесса на GitHub Actions. Спасибо @HideakiImamura, @drumehiron, @xadrianzetx, @kei-mo, @contramundum53 и @shu65.

Контрольный эксперимент

Используя разработанную среду бенчмаркинга, мы провели эксперимент по оценке производительности. Это делается для того, чтобы честно сравнить алгоритмы, реализованные в Optuna, в различных условиях задачи, чтобы учесть изменения в аргументах по умолчанию, включая сэмплер и секаторы.

Поскольку было бы нецелесообразно проводить эксперимент на всех комбинациях пробоотборника и секатора, мы ограничили наш бенчмаркинг наиболее важными из них. Мы провели 100 исследований из 1000 испытаний более чем 30 различных комбинаций пробоотборников и секаторов и более 170 различных комбинаций задач, в общей сложности более 500 миллионов испытаний. Поскольку для этого эксперимента требовалось большое количество вычислительных ресурсов, мы провели эксперимент с использованием вычислительного кластера Preferred Networks, Inc. Мы запускали примерно 7000 процессоров параллельно в течение примерно 3 дней. Ниже приведены краткие сводки результатов тестов.

  • Бенчмарки сэмплера
    . TPESampler – текущий алгоритм сэмплирования по умолчанию в Optuna. Текущие аргументы по умолчанию TPESampler хорошо работают во многих настройках. Однако мы также обнаружили, что разные пробоотборники подходят для разных типов задач и количества испытаний.
    - Параметр multivariate для TPESampler позволяет включить многомерную выборку. Значение параметра multivariate по умолчанию в настоящее время равно False. Мы обнаружили, что установка для параметра multivariate значения True во многих случаях повышала производительность, но иногда приводила к ухудшению производительности в многомерных задачах. Поскольку изменение аргумента по умолчанию оказывает значительное влияние на пользователей, мы решили проявить осторожность и не менять на данном этапе значение параметра multivariate по умолчанию на True.
     – Мы также провели тест скорости с использованием существующей среды на основе asv. Мы заметили, что изменение аргумента multivariate ускорит выборку. Обратите внимание, что разница в скорости является результатом реализации и может измениться в будущем.
  • Тесты сэмплера в распределенной оптимизации
    — Мы провели тест с распределенной оптимизацией. Параметр constant_liar параметра TPESampler позволяет включить стратегию постоянного лжеца. Мы обнаружили, что установка параметра constant_liar для TPESampler на True не обязательно повышает производительность. Было обнаружено, что для некоторых типов задач BoTorchSampler, который представляет собой алгоритм, основанный на гауссовских процессах, работает лучше. Значение по умолчанию параметра constant_liar для TPESampler в настоящее время равно False, и мы решили не менять его на True.
  • Тесты обрезки
    . MedianPruner – текущий алгоритм обрезки по умолчанию в Optuna. HyperbandPruner — это секатор с большими ожиданиями от коммиттеров. Результаты показали, что в некоторых случаях MedianPruner работал лучше, в то время как в других случаях HyperbandPruner работал лучше, используя свои аргументы по умолчанию. Поэтому изменение секатора по умолчанию было отложено. Стоит отметить, что разные конфигурации секатора могут давать разные результаты.

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

Вы можете воспроизвести частичные тестовые эксперименты на GitHub Actions. Если вы хотите более подробно изучить поведение определенного алгоритма, мы рекомендуем вам попробовать его самостоятельно. Если вас интересуют подробные результаты наших тестовых экспериментов, проверьте #2964 и #2906.

Что дальше

Спасибо, что дочитали до этого места. В следующей половине этого блога мы обсудим различные новые функции, добавленные в Optuna v3.0, а также элементы разработки, которые были в дорожной карте, но так и не были реализованы из-за перипетий. Наслаждаться!

https://medium.com/optuna/optuna-3-part-2-3d64bca63573