За то лето, которое только что прошло, со мной произошло многое: подача заявления в отпуск из моей кандидатской диссертации. программа по медицинским показаниям, почти месячный карантин, посещение семьи и близких друзей после двухлетнего отсутствия, путешествие по северо-западной части Китая и завершение моего Google Summer of Code 2021 (GSoC 2021) проект: разработка Оптуна-Dashboard.
В какой-то степени Optuna-Dashboard — это TensorBoard Optuna, библиотеки оптимизации гиперпараметров для машинного обучения, написанной на чистом Python. Во время процессов настройки гиперпараметров многие переменные, например методы инициализации веса, глубина сети в DNN, скорость обучения и т. д., влияют на окончательную производительность модели. Из-за многомерности и разнообразия (гиперпараметры могут быть целыми числами, числами с плавающей запятой и категориальными значениями) природы этих переменных трудно интуитивно понять, как каждая переменная влияет на показатель производительности, и играть с другими переменными. Optuna-Dashboard предлагает комплексное решение этой проблемы, представляя различные результаты визуализации в веб-браузере. Он интерактивен и обновляется в режиме реального времени, поэтому с его помощью удобно исследовать и отслеживать процесс оптимизации гиперпараметров локально или удаленно.
Моя задача в этом году в проекте GSoC — работать с коммиттерами Optuna-dashboard для разработки и улучшения Optuna-dashboard. Моя работа в основном была сосредоточена на следующих темах:
- Портирование дополнительных функций визуализации в Optuna-Dashboard
- Добавить поддержку многоцелевых исследований
- Добавить панель настроек
- Добавьте модульные тесты
- Исследование замены бэкенда некоторых методов анализа модулями WebAssembly
Работа Optuna-dashboard заключается в запуске внутреннего сервера на хост-компьютере, который сначала подключается к механизму хранения Optuna, а затем обслуживает как статические файлы для веб-приложения (написанные на React), так и набор API (написанные с помощью Бутылка), которые вызывают методы анализа от Оптуна. После загрузки веб-приложения и указания исследования клиентская часть периодически отправляет запросы к серверной части, чтобы запросить данные испытаний для визуализации. На самом деле, сама Optuna предоставляет множество функций визуализации из коробки с бэкэндами Matplotlib и Plotly. Однако их нельзя использовать напрямую, так как они предназначены для локального использования со сценариями и блокнотами iPython. Этим летом мы перенесли почти все функции визуализации из Optuna в Typescript в веб-приложении.
Добавлена поддержка многоцелевых исследований.
Мы также привносим еще одно преимущество Optuna в инструментальную панель Optuna: поддержку многоцелевых исследований. В отличие от исследований с одной целью, многоцелевое исследование требует большего количества взаимодействий для представления результатов визуализации, поскольку пользователи не должны переключать цели с помощью фрагментов кода Python (внедрение кода может быть опасным) в интерфейсе панели инструментов.
Добавить панель настроек
Кроме того, мы добавили панель настроек на панель инструментов. Процесс повторного анализа-графика может быть медленным, если в исследовании слишком много испытаний, и некоторые графики визуализации могут быть ненужными, если пользователю нужно только несколько из них. Добавление панели, которая хранит параметры выбора графика в локальном хранилище браузера, позволяет пользователям самостоятельно настраивать панель мониторинга.
Добавьте модульные тесты
Что касается модульного тестирования, моя работа в этой части в основном связана с добавлением тестов для внешнего интерфейса. Это оказывается сложнее, чем я думал. Сначала мы думали, что для тестов будет достаточно простой тестовой библиотеки, но оказалось, что мы ошибались. Хотя тесты для графов писать легко, с табличной частью все усложнилось. На выбор есть два основных фреймворка: JEST и Библиотека тестирования React. Первый предоставляет API для управления элементами внутри таблицы, но работает не с отрендеренным HTML-выводом, а с деревом узлов, кроме того, он не поддерживает React 17. Последний вместо этого фокусируется на отрендеренном выводе, но имеет плохие методы для идентификации и извлекать элементы, что может иметь решающее значение, если нужно проверить определенные столбцы с условиями в таблице.
Следуя духу тестирования, мы все согласились с тем, что тестовая библиотека должна напрямую измерять и взаимодействовать с окончательным интерфейсом (рендерингом HTML), поэтому мы выбрали библиотеку тестирования React. Но его плохой API делает потенциальные тесты таблиц очень громоздкими, если не полностью невозможными.
Исследование замены бэкенда некоторых методов анализа модулями WebAssembly
Закончив эти части, наш проект постепенно улегся, и я вернулся в Китай. Мы попробовали другую идею — заменить API важности параметра модулем WASM. Мы потерпели неудачу в этой идее, так как в Golang, который я использовал для реализации алгоритма случайного дерева, не хватает готовых библиотек для соответствующих сложных операций, и у меня нет времени реализовать их с нуля. Текущее существующее решение несколько нестандартное: хотя для большинства визуализаций у нас есть реализации JS, которые функционально эквивалентны тем API с теми же именами и используются Optuna, и требуют только данных испытаний для вычисления, в то время как для визуализации важности параметра мы запрашиваем серверной части для вычисления значений важности. Это вносит несогласованность и избыточность в систему. Кроме того, так как Optuna-dashboard обычно используется для мониторинга хода оптимизации, он отправляет запросы периодически с относительно коротким интервалом, что будет потреблять гораздо больше ресурсов, так как каждый вызов оценки важности параметра может быть тяжелым и его нужно начинать с самого начала. в то время как значение важности может не сильно измениться в интервале.
Переосмысление архитектуры Optuna-dashboard
Это неудачное исследование и некоторые проблемы, возникшие в предыдущих частях, заставили меня переосмыслить архитектуру Optuna-dashboard: для API визуализации, с одной стороны, текущее решение в большинстве случаев делает запросы API простыми, поскольку требует только пробные данные для построения графиков и вычислительная нагрузка находятся на стороне клиента, что освобождает серверную часть от тяжелых вычислений. С другой стороны, однако, это создает избыточность в библиотеке и принципе DRY, у нас есть два набора функций для одного набора целей. Если в будущем «Оптуна» изменит один API визуализации, нам придется одновременно изменить и панель управления. Конечно, это не будет большой проблемой, если Optuna войдет в фазу «спокойствия».
Но альтернативное решение может быть следующим: вместо того, чтобы запрашивать необработанные данные списка испытаний, которые могут быть очень тяжелыми, если у вас есть давнее исследование оптимизации, клиент напрямую просит серверную сторону вычислить и отобразить все результаты визуализации. Это 1) не требует больше отдельных реализаций для одной и той же функции визуализации и 2) уменьшает как объем передаваемых данных, так и потребление ресурсов в браузере. В настоящее время и Matplotlib, и Plotly поддерживают возврат объектов fig в формате содержимого PNG или HTML, поэтому технически это правдоподобно.
Это может быть проблематично, если у нас есть несколько клиентов, подключенных к одному и тому же бэкэнду, но, к счастью, Optuna-dashboard предназначен для использования не так. И даже в этом случае вычислительная нагрузка может быть уменьшена с помощью механизма кэширования: только при обновлении испытаний серверная часть пересчитывает все визуализации. Но какова цена этого? Я думаю, что это затруднит создание интерактивных графиков, так как все пересчеты происходят в бэкэнде и могут быть медленными.
Краткое содержание
Optuna-dashboard — отличный инструмент для мониторинга и анализа оптимизаций в Optuna. Этим летом мы помогли улучшить его через GUI/Unit тесты, API и т.д. В целом мы выполнили все запланированные необходимые предложения. Но, к сожалению, мы не закончили некоторые необязательные: у нас не было времени изучить все идеи в приведенном выше обсуждении и некоторые другие предложения (например, расширение JupyterLab) в этом году по многим причинам. Но мне повезло, потому что я многому научился в этом проекте, от тестирования до совместной работы через Github. Итак, я хотел бы поблагодарить своих руководителей в проекте GSoC, Masashi Shibata и Crissman Loomis. Опыт работы с вами, ребята, потрясающий и очень приятный.
