[논문리뷰] Optuna: A Next-generation Hyperparameter Optimization Framework

[Paper] [GitHub]

💡 해당 포스터에 정리한 내용은 제가 논문을 읽고 이해한 흐름대로 내용을 재구성하여 작성했습니다. 따라서 글의 소제목 및 수식 번호는 실제 논문의 구성과 다를 수 있습니다!

1. Introduction

1-1. Motivation

1-2. Limitations of Existing Methods

1-3. Contributions

2. Methods

2-1. Define-by-run API

Define-by-run이라는 말은 원래 딥러닝 개발자들 사이에서 처음 나온 용어다.

Tensorflow와 같은 초창기 딥러닝 프레임워크는 Define-and-run 방식을 채택했다.
이는 신경망의 전체 구조를 사전에 미리 정의해놓은 뒤, 그 고정된 구조 위로 데이터를 흘려보내 연산을 수행하는 방식이었다.
하지만 이러한 방식 때문에 한 번 구조를 정의하고 나면, 중간에 변수를 조작하거나 네트워크 구조를 바꾸는 것이 불가능했다.

이러한 문제를 해결하기 위해 등장한 것이 PyTorch로 대표되는 Define-by-run 프레임워크이다.
사전에 네트워크 구조를 미리 설계할 필요 없이, 직관적으로 코드를 작성하기만 하면 그 코드가 실행되는 흐름에 따라 네트워크가 동적으로 구성되는 방식이다.

저자들은 기존의 하이퍼파라미터 최적화 (HPO) 프레임워크들이 과거의 Define-and-run 방식처럼 정적으로 동작한다는 점을 지적하였고, 이 문제를 해결하기 위해 HPO 시스템에 Define-by-run 개념을 새롭게 도입했다.

즉, 사용자가 Hyperparmeter search space를 사전에 억지로 전부 정의할 필요 없이, 실행 시점에 동적으로 만들어지도록 한 것이다.

Figure 2를 보면 기존의 대표적인 프레임워크인 Hyperopt는 사전에 모든 파라미터 경우의 수를 준비해 두어야 했다.
이로 인해 최적화 문제가 복잡해질수록, 코드가 훨씬 길고 한눈에 이해하기 어려워진다.

반면 Figure 1을 보면 Optuna의 목적 함수는 상호작용이 가능한 Trial 객체를 전달받으며, 코드가 실행되는 런타임 도중에 trial.suggest_int와 같은 API를 호출하면, 과거 기록을 바탕으로 통계적으로 파라미터를 즉시 출력한다.
덕분에 파이썬의 for 루프나 if 조건문을 그대로 쓸 수 있어서, 복잡한 파라미터 공간을 직관적이고 쉽게 코드로 표현할 수 있다.

Modular Programming

Optuna의 동적 설계 덕분에, 복잡한 하이퍼파라미터 최적화 코드를 목적에 따라 여러 개의 독립적인 모듈로 깔끔하게 나누어 작성할 수 있다.

예를 들어 Figure 3을 보면, 신경망의 뼈대 (layer 개수, 각 layer의 unit 수 등)를 결정하는 create_model 함수와, 학습률이나 weight-decay 같은 옵티마이저 설정을 담당하는 create_optimizer 함수를 별개로 만들어서 동시에 최적화할 수 있다.

Deployment

이러한 Define-by-run 방식은 함수 중간중간에 trial.suggest처럼 값을 무작위로 뽑아주는 코드가 존재하기 때문에, 최적의 값을 다 찾고 나서 진짜 서비스에 올릴 때는 해당 코드를 싹 다 지우고 새로 작성해야 할지 의문이 들 수 있다.

Optuna에서는 이러한 문제를 FixedTrial이라는 별도의 객체를 만들어 해결했다.

FixedTrial은 기존의 Trial 객체와 동일한 기능을 가지고 있다.
단지 새로운 파라미터를 탐색해서 추천하는 대신, 실험 기록을 보고 성능이 가장 좋았던 하이퍼파라미터만 고정적으로 반환하도록 작동한다.

결과적으로 사용자는 최적의 하이퍼파라미터 조합을 찾은 뒤 그 값들을 담은 FixedTrial 객체를 생성하여, 원래의 목적 함수에 그대로 넘겨주기만 하면 배포 준비가 끝난다.

2-2. Efficient Sampling and Pruning Mechanism

저자들은 하이퍼파라미터 최적화 프레임워크가 얼마나 효율적인지는 다음 두 가지 요소에 달려 있다고 설명한다.

• 탐색 전략 (Sampling): 수많은 경우의 수 중에서 다음에 어떤 파라미터 조합을 테스트해 볼 것인가를 결정하는 방법
• 성능 예측 전략 (Pruning): 학습이 진행되는 초중반의 곡선을 보고, 이 파라미터 조합은 끝까지 가봤자 가망이 없다고 미리 예측하여 시도를 조기에 종료하는 방법 (Automated early stopping)

Pruning은 모델이 학습 데이터에 오버피팅되는 것을 막기 위해 사용하는 머신러닝의 Early stopping 기법과는 다르다는 것을 인지해야 한다.

Sampling Methods

샘플링 방법에는 일반적으로 파라미터들 사이의 상관관계를 고려해서 뽑는 relational sampling과 각 파라미터를 개별적으로 뽑는 independent sampling이 존재한다.

기존의 Define-and-run 방식은 시작하기 전에 전체 파라미터 구조를 다 그려놓기 때문에, 시스템이 처음부터 파라미터 간의 관계를 파악하고 있다.
하지만 Define-by-run 방식은 코드가 실행되면서 그때그때 파라미터가 등장하기 때문에, 초반에 시스템이 파라미터들끼리 서로 어떤 관계를 가지고 있는지 미리 알 수 없다.

이 딜레마를 극복하기 위해 Optuna는 초반에 TPE와 같은 independent sampling을 몇 번 돌리면서 데이터를 쌓는다.
이후 데이터가 모여서 유의미한 결과 기록이 쌓이면, 시스템이 그 기록들을 분석해서 파라미터 간의 숨겨진 상관관계를 스스로 추론한다.
이렇게 관계를 파악하고 나면, 그때부터 CMA-ES나 GP-BO 같은 relational sampling 알고리즘을 사용할 수 있게 된다.

Pruning Algorithm

Pruning은 기본적으로 학습 중간중간의 성능 (목적 함수 값)을 주기적으로 모니터링하고, 정해진 기준에 미치지 못하는 trial을 강제로 종료하는 두 단계로 작동한다.
Figure 5에서 볼 수 있듯이, 두 가지 역할은 report API와 should_prune API가 담당하도록 설계했다.

Optuna는 각 worker가 비동기적으로 pruning을 할 수 있도록, 기존의 Successive Halving의 확장 형태인 Asynchronous Successive Halving (ASHA) 사용했다고 한다.

비동기 방식은 각 worker가 pruning을 할 때, 다른 worker의 결과가 나올 때까지 기다릴 필요 없이 각자 자기 페이스대로 조기 종료를 실행할 수 있다.
따라서 분산 환경에 특히 더 잘 맞는다고 한다.

추가적으로 논문에서는 메모리 낭비를 방지하기 위해, ASHA를 살짝 변형하여 한 번 탈락한 시도를 나중에 다시 살려내는 패자부활전은 허용하지 않는다고 하였다.

Algorithm 1은 실제 Optuna에서 구현된 pruning 알고리즘이다.

먼저 각 tiral이 pruning에서 몇 번 살아남았는지를 뜻하는 rung을 계산한다.
그리고 해당 trial의 순위가 상위 $1/\eta$ 안에 들어야만 다음 라운드로 진출할 수 있게 한다.
만약 rung이 같은 trial의 총 개수가 $\eta$보다 작다면, 그중에서 가장 성적이 좋은 trial을 무조건 다음 라운드로 진출시킨다.

2-3. Scalable and Versatile System

Figure 6은 시스템 설계도를 보여주는 그림이다.

분산 환경에서는 여러 worker가 동시에 투입되는데, 각 worker는 하나의 최적화 과정 (Study) 안에서 각자 독립적으로 목적 함수를 실행하여 trial을 진행한다.
목적 함수가 실행되는 동안에는 파라미터 추천 알고리즘 suggest(), 가지치기 판별 알고리즘should_prune(), 중간 결과 보고 report()와 같은 Optuna의 핵심 API들을 호출한다.

이 API들이 호출될 때마다 목적 함수는 공유 스토리지 (Shared storage)에 접근한다.
이를 통해 과거의 실험 기록들을 가져와서 참고하기도 하고, 각자 독립적으로 진행한 현재의 진행 상황을 스토리지에 저장하여 전체 작업 내역을 서로 공유하게 된다.

3. Experiments