Framework + Программист

Из названия все ясно. Лучшая утилита для оптимизации гиперпараметров вашей модели или нет? Многие перескакивает с метода подбора параметров GridSearch/Random из scikit-learn и постепенно переходят на библиотеку Optuna со своими решениями.

Почему?

Обычный GridSearch – примитивное перебирание по сетке, где мы смотрим только на качество решаемой задачи по accuracy, cross-entropy, mse. Экспоненциальный перебор всех узлов сетки параметров зависит напрямую от подаваемых координат.

Очевидно, простой "перебор" –  подход зачастую крайне ресурсоемкий. А вот Random'изированный показывает лучший результат, так как подбирает случайные комбинации и сэмплирует результаты… Но что если строить вероятностные модели выборки гиперпараметров?

Optuna и работает по этому принципу — байесовской оптимизации GP или Tree-structured Parzen Estimator (TPE). Чем лучше TPE в сравнении с всякими серчами переборов? Он предполагает вероятностные модели и исходит из прогнозируемой эффективности модели.

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

Какие ещё преимущества у этого фреймворка?

• У Optuna хорошая документация. Хотя и не слишком очевидно на старте, какие алгоритмы реализованы в библиотеке.

• Есть Define-by-run, при помощи которого можно динамически описывать пространство параметров во время работы оптимизировать.

• Можно явно задавать максимизацию или минимизацию функции качества.

Запутанный декларативный стиль или код, похожий на "нотации", головная боль от отладок...  А если ваша модель неожиданно выходит за рамки парадигмы работы фреймворка  — приходится прикладывать титанические усилия по переработке кода или разворачиванию парочки здоровенных костылей. И да, мы про TensorFlow.

Все из-за самого статического графа вычислений во фреймворке... Граф вычисление — это абстрактное представление алгоритма вычислений в виде, не поверите, математического графа. Где ребра — потоки данных, а узлы — операции. Узлами могут быть слоями нейронки, а ребра — потоками данных. В статическом варианте можно оптимизировать и ускорить работу вашего TPU или GPU, провести объединение или распараллеливание операций.

Удобно, конечно...

Только доступа у вас к обработке данных нет. Поэтому любые ошибки = час сеанса, пока TF не обнаружит проблемы. А крупные модели ML иногда требуют и больше времени... Это серьезный минус всех фреймворков, построенных на работе статического графа вычислений.

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

Вот тут и мы и говорим о PyTorch. Интуитивный и похожий на Питон синтаксис, неплохая интеграция с другими библиотеками и доступ к быстрой отладке – все это про него. И это мы не упоминаем кучу модульных элементов, которые легко комбинировать, упрощенное написание собственных типов слоев. Pytorch – про эксперименты, быстрое обучение и небольшие проекты.

Приятное дополнение — широкий выбор предварительно обученных моделей.

Но если вам все же нужна оптимизация ваших вычислений... тогда стоит обратиться к конкуренту от Google.