7 분 소요

image



Optimization Algorithms

Hyperparameter Tuning

Using an Appropriate Scale to pick Hyperparameters

지난번에는 여러 범위의 하이퍼파라미터에서 임의의 샘플링을 통해 더 효율적으로 하이퍼파라미터의 공간을 검색하는 방법을 배웠습니다. 하지만 임의로 샘플링을 하는 것은 균일화된 임의의 작업을 뜻하는 것이 아닌데요. 특정 범위의 유효한 값에서 말이죠. 대신에 적절한 척도를 선택하여 하이퍼파라미터를 탐색해야 합니다. 이번에는 그 방법을 살펴보겠습니다.


image

은닉 단위의 수인 $n^{[l]}$을 찾으려고 한다고 가정하면, 1개의 레이어에서 말이죠. 그리고 좋은 범위는 50에서 100사이라고 해보겠습니다. 이런 경우 50에서 100사이 숫자 라인을 보면 이 숫자 라인 내에서 임의의 숫자 값을 선택할 수 있습니다. 이 특정 하이퍼파라미터를 검색하는 꽤 눈에 띄는 방법이 있습니다. 또는 신경망 네트워크 레이어의 개수를 결정하려고 한다면요.

이것을 대문자 L이라고 하겠습니다. 총 레이어의 개수가 2에서 4개 사이여야한다고 생각할 수도 있습니다. 그러면 2, 3, 4에 따라 랜덤으로 균일하게 예제를 추출하는 것이 합리적일 수 있습니다. 또는 심지어 격자판 검색 같은 경우 명백히 2, 3 그리고 4의 값을 평가하는 것이 합리적일 수 있습니다. 이러한 몇 개의 예제들과 같이 균일화된 임의의 방법으로 샘플링을 하는 경우 생각하고 있는 범위가 합리적인 방법일 수도 있습니다. 하지만 이런 방법이 모든 하이퍼파라미터에서 적용되는 것은 아니죠.


image

다른 예제를 보시죠. 학습률인 알파 값을 검색한다고 해보겠습니다. 그리고 이 경우에 0.0001이 낮은 경계선이고 또는 높은 경계선이 1일 수 있겠죠. 자 만약 0.0001에서 1까지인 숫자라인을 그리고 임의로 균일화되게 샘플링을 진행하면 대략적으로 샘플값의 90퍼센트 정도가 0.1과 1사이에 있을 것입니다. 따라서 90% 자원을 사용하여 0.1과 1사이를 검색하고 그리고 자원의 10%만 0.0001과 0.1사이를 검색합니다. 옳은 방법처럼 보이지 않죠.

대신에 로그 스케일에서 하이퍼파라미터를 검색하는 것이 더 합리적으로 보입니다. 선형 척도를 이용하는 대신에 0.0001과 0.001, 0.01, 0.1 그리고 1가 척도에 있습니다. 그리고 이러한 유형의 로그 스케일에서 무작위로 균일하게 샘플링합니다. 그렇게하면 0.0001과 0.001사이와, 0.001과 0.01 사이등 검색에 더 많은 자원을 사용할 수 있습니다.

그러므로 파이썬에서는 이렇게 도입하는게 좋습니다.

r = -4 * np.random.rand()

이런식으로 말이죠. 그리고 임의로 선택된 알파값은 $10^r$이 됩니다. 이 첫번째 라인 이후로는 임의 숫자가 -4와 0사이의 값일 것입니다. 그래서 여기 알파값은 $10^{-4}$과 $10^0$사이의 값을 가질 것입니다.

더 일반적인 경우 $10^a, 10^b$을 로그 척도에서 샘플링하려고 하는 경우 말이죠. 그리고 r을 임의로 a와 b사이에서 균일하게 샘플링합니다. 이 경우에는 r의 값은 -4와 0사이입니다. 그리고 알파의 값을 임의로 샘플링된 하이퍼 파라미터의 값인 $10^r$로 지정할 수 있습니다.

요약하자면 로그 척도로 샘플링하려면 낮은 값을 취하고 로그를 취하여 a의 값을 알아냅니다. 높은 값을 취하고 로그를 취하여 b가 무엇인지 알아냅니다. 이제 여러분은 $10^a$에서 $10^b$을 로그 척도에서 샘플링하려 합니다. 그러면 r의 값을 균일화되게 임의로 설정해요. $a$와 $b$사이로 말이죠. 그리고 하이퍼파라미터를 $10^r$로 설정합니다. 그래서 이것은 로그 척도로 샘플링을 구현하는 방법입니다.


image

마지막으로 조금 헷갈리는 부분은 하이퍼파라미터 베타 샘플링인데요. 지수 가중 평균을 계산하는 데 사용됩니다. 베타가 0.9에서 0.999사이 어딘가라고 가정하겠습니다. 따라서 기억할 것은 지수 가중 평균을 계산할 때 0.9의 값을 사용하는 것은 마치 10개의 값에서 평균을 구하는 것과 같습니다. 마치 10일 동안의 평균 기온을 구하는 것처럼 말인데요.

반면에 0.999의 값을 사용하는 것은 1000개의 값에서 평균치를 구하는 것과 같습니다. 그래서 이전에 본 것과 비슷하게 0.9와 0.999의 값에서 검색을 하고 싶은 경우에 선형 척도에서 검색을 하는 것이 말이 안되죠. 0.9와 0.999사이에서 말이죠.

이에 대해 생각하기 쉬운 방법으로는 $1 - beta$에서 그 값의 범위를 찾는 것인데요. 그러면 이제 범위는 0.1에서 0.001이 되겠죠. 그래서 베타 사이에서 샘플링을 할 텐데요. 0.1에서 0.01사이의 값 그리고 0.01과 0.001사이에서 말입니다. 알파와 같은 방법을 통해서 자원을 더 효율적으로 사용할 수 있습니다.

그렇다면 왜 선형 척도로 샘플링하는게 나쁜 생각일까요? 즉 베타가 1에 가까울 때 그 민감도 결과값에 대한 민감도가 변합니다. 아주 조금의 베타값 변화에도 말이죠. 그러므로 베타가 만약 0.9에서 0.9005로 바뀌면 이것은 그리 큰 의미를 갖진 않습니다. 결과값을 거의 바꾸지 않기 때문이죠. 하지만 만약 베타가 0.999에서 0.9995로 간다면 알고리즘이 어떻게 하고 있는지에 대해서 아주 큰 영향을 끼칩니다.

이 두 경우에 대략 10개 이상의 값을 평균화합니다. 그러나 여기서는 지난 1000개 정도의 예제에 대한 지수 가중 평균에서 이제 2000개 예제로 바뀌었습니다. 그리고 그것은 공식 $\dfrac{1}{1-\beta}$ 때문에 베타가 1에 가까울 때 베타의 작은 변화에 매우 민감합니다. 그러면 여기 전체 샘플링 절차가 하는 것은 베타가 1이 근접한 범위에서 샘플링을 밀도있게 진행하게 합니다. 또는 대안적으로 1-베타가 0에 가까울 때 그럴 수 있죠. 샘플을 배포하는 방법 측면에서 더 효율적일 수 있도록 가능한 결과값에 대해 더 효율적으로 탐색할 수 있게 말이죠.


Hyperparameters Tuning in Practice: Pandas vs. Caviar

좋은 하이퍼파라미터를 찾는 방법에 대해 많이 들으셨을텐데요. 하이퍼파라미터 검색에 대한 토론 내용을 정리하기 전에 앞서 마지막으로 몇 가지 팁과 기술을 공유하겠습니다. 하이퍼파라미터 검색 과정을 조직화하는 방법에 대해서 말이죠.


image

딥러닝은 오늘날 많은 다양한 어플 분양에서 적용되고 있는데요. 그리고 한 어플리케이션 영역에서 하이퍼파라미터 설정에 대한 직관이 다른 영역으로 이전될 수도 있고 그렇지 않을 수도 있습니다. 서로 다른 어플 도메인에서는 교차 수정이 많이 있는데요. Vision의 아이디어가 Speeach에 또 Speech에서 개발된 아이디어 NLP에 성공적으로 적용되는 경우가 있었습니다. 따라서 딥 러닝의 한 가지 좋은 발전은 다양한 응용 분야의 사람들이 교차 수정에 대한 영감을 찾기 위해 다른 응용 분야의 연구 논문을 점점 더 많이 읽는다는 것입니다.

하이만 하이퍼파라미터의 설정에 있어서는 이런 직관이 잘 이루어지지 않는 것을 보게됩니다. 한개의 문제를 다루게 되더라도, 예를 들어 로지스틱, 하이퍼파라미터를 위한 좋은 값을 찾을 수 있으며 그리고 계속 알고리즘을 개발했겠죠. 또는 몇 개월에 걸쳐 데이터가 점진적으로 변경되는 것을 볼 수 있고 또는 데이터 센터에 있는 서버를 막 업그레이드 했을 수도 있죠.

그리고 이러한 변화 때문에 하이퍼파라미터 최적 설정이 오래될 수 있습니다. 그렇기 때문에 다시 테스트하거나 하이퍼파라미터를 재평가하는 것을 추천합니다. 최소한 몇 개월에 한번씩은 말이죠.


image

마지막으로 사람들이 하이퍼파라미터를 검색하는 것에 대해 이야기해볼텐데요. 아마도 2개의 주요 사고 방식을 보거나 또는 어쩌면 사람들이 하는 2개의 방법이죠.

한 가지 방법은 한 모델을 돌보는 것입니다. 그리고 일반적으로 데이터 세트는 엄청나지만 산출 자원도 많지 않고 CPU와 GPU가 많지 않기 때문에 기본적으로 한 번에 하나의 모델만 훈련하거나 아주 적은 수의 모델을 훈련할 수 있습니다. 이런 경우 훈련 중에도 해당 모델을 점차적으로 돌봐줄 수 있습니다.

예를 들어 첫째날일때 파라미터를 임의로 초기화시키고 바로 트레이닝을 할 수 있겠죠. 그리고 점차 학습 곡선 아마도 비용 함수 J 또는 데이터 세트 오류 또는 다른 것이 첫날에 점차적으로 감소하는 것을 관찰합니다. 그리고 첫째날의 마지막 부분에 이르러서 아주 잘 학습하고 있다고 생각하실 수 있는데요. 이런 경우 학습률을 약곤 높혀서 어떤 결과가 나오는지 보겠습니다. 그러면 아마 더 잘할 수도 있겠죠.

그리고 둘째날 그리고 이틀후에 아직 잘하고 있다고 판단할 수 있습니다. 모멘텀 항을 조금 채우거나 학습 분사을 조금 줄일 수 있는데요. 그리고 그렇게되면 셋째날로 접어드는 것이죠. 이렇게 매일 보면서 파라미터를 위아애로 조금씩 움직여보세요. 그러면 아마 어느날에는 학습률이 매우 컸다는 것을 꺠달을 수 있습니다. 그러면 이전 날들의 모델로 다시 돌아갈 것입니다.

하지만 한 번에 하루씩 모델을 돌보고 있는데요. 심지어 훈련이 몇일간 또는 몇 주간 이루어지는 경우에도 말이죠 이것이 하나의 접근 방식이고 한 모델을 돌보는 사람들이며 성능을 관찰하고 인내심 있게 학습률을 높이거나 낮추는 것입니다. 그러나 이 경우는 일반적으로 많은 모델을 동시에 훈련할 충분한 산출 여력이 없는 경우에 발생합니다

다른 방법으로는 병렬 방식으로 여러 모델을 훈련 시키는 방법인데요. 따라서 하이퍼파라미터를 일부 설정할 수 있는데 그래서 혼자 작동하게 놔둘 수 있는데요. 하루 또는 며칠 간 이렇게 놔둘 수 있습니다. 그러면 이렇게 생긴 학습 곡선을 얻게 될텐데요. 그리고 이것은 J 비용함수의 그래프 이거나 훈련 오류의 비용이거나, 또는 데이터 세트 에러의 비용일 수 있을 텐데요. 하지만 추적에 몇 가지 측정 항목이 있습니다. 그리고 동시에 다른 설정값의 하이퍼 파라미터를 가진 다른 모델을 시작할 수 있습니다.

그래서 두번째 모델은 다른 학습 커브를 줄 것인데요. 동시에 세번째 모델도 훈련 시킬 수 있습니다. 그리고 또 하나를 만들수도 있고요. 어쩌면 이것은 이렇게 나뉘어질 수 있는데요. 이렇게 생길것이며 계속 이어집니다. 또는 여러분은 여러개의 모델을 병렬하게 훈련 시킬 수 있습니다. 그러면 여기 오렌지색 선이 다른 모델들인데요. 그리고 이런 방식으로 다른 하이퍼 파라미터 설정값을 시도하고 어쩌면 빠르게 마지막에 가장 잘 작동하는 것을 찾을 수 있습니다.

그럼 비유를 하자면 여기 왼쪽 방식을 판다 접근이라고 할 것입니다. 판다가 아이를 갖는 경우 그들은 아이를 굉장히 조금 갖는데요. 한번에 1명씩 낳으며 그리고 그렇게 1명을 낳아 그 아기 판다가 잘 생존해서 자랄 수 있도록 많은 노력을 기울입니다. 이것은 실제로 아이를 돌보는 것과도 같죠 한개의 모델 또는 한개의 아기 판다입니다.

오른쪽 방법은 물고기가 하는 방식과 비슷합니다. 이것을 캐비아 전략이라고 할 것입니다. 한 짝짓기 시즌에 1억개가 넘는 생선알을 낳는 물고기가 있습니다. 물고기가 번식하는 방법은 그러나 많은 알을 낳고 그리고 그 중 어느 것에도 너무 많은 관심을 기울이지 않는다는 것입니다. 하지만 그들 중 하나 또는 아마도 많은 사람들이 잘 할 수 있기를 바랍니다.

그래서 이것이 포유류가 번식하는 방식과 물고기와 많은 파충류가 번식하는 방식의 차이입니다. 저는 이것을 판다 접근 대 케비어 접근이라고 할 것인데요. 이것이 더 흥미롭고 쉽게 외울 수 있는 방법이기 때문입니다. 이 2개의 접근 방식 중 고르는 방법은 여러분이 얼마나 산출 자원을 가지고 있느냐에 따라 달라집니다. 여러분이 충분히 많은 컴퓨터를 가지고 있어 여러개의 모델을 병렬 방식으로 훈련 시킬 수 있으면 그런 다음 반드시 케비어 접근 방식을 취하고 그리고 여러개의 하이퍼 파라미터를 시도하여 어떤 것이 잘 작동하는 것인지 확인하는 것입니다.

하지만 어떤 어플 도메인에서는 저는 이것을 몇개의 온라인 광고 설정에서 보기도 하고 컴퓨터 비전 어플에서도 보는데요. 거기에는 단지 데이터가 무수히 많아 훈련 시키려고 하는 모델이 너무 방대해서 모델들을 한번에 훈련 시키기가 매우 어렵습니다. 물론 어플에 따라 다를 수 있겠죠.

하지만 이런 커뮤니티와 같은 경우 판다 접근을 더 많이 쓰는 경우를 봤고 이 경우 한개의 모델을 베이비 시팅하고 위 아래로 움직이며 이 하나의 모델이 작동하도록 하려고 합니다. 판다 접근도 한 모델을 훈련시킨 다음 그리고 작동 여부를 확인하고 아마도 두 번째 주나 세 번째 주에 다른 모델을 초기화한 다음 팬더와 마찬가지로 한 모델이 평생 여러 자녀를 가질 수 있도록 초기화해야 하는데요. 비록 한 번에 한 명의 자녀 또는 아주 적은 수의 아이가 있더라도 말이죠.

댓글남기기