ML Strategy(1)
우리가 모델을 개발하고 있고, 더 좋은 성능을 위해 고민할 수 있는 것은 뭘까?
데이터를 더 수집하거나, 여러 종류의 Gradient descent algorithm을 시도하거나, 신경망의 구조를 바꾸는 등 정말 수많은 경우의 수가 존재한다.
하지만 Machine Learning(혹은 Deep Learning)은 그 특성상 학습을 하는데에 시간이 오래 걸리기 때문에 어떠한 행동이 어떠한 결과를 나을지 모르는 채로 하나 하나 다 시도해 보기에는 시간이 매우 부족할 것이다.
따라서 우리가 모델을 설계할 때에는 어떤 것에 중점을 두어야하고, 어떤 문제는 어떻게 해결해야 하는 지 등의 전략을 갖고 있는것이 매우 중요하다.
이번 시리즈 ML Strategy에서는 머신러닝 혹은 딥러닝 시스템을 구현하는데에 있어 효율적인 접근법을 소개한다.
Orthogonalization
모델을 설계할 때, 능력있는 엔지니어라면 한가지 목표를 달성하기 위해 어떠한 것을 튜닝해야 하는지 정확한 안목을 가지고 있다.
'어떠한 문제가 있으면 어디를 바꾸면 된다' 라고 말할 수 있게 설계하는 것이 Orthogonalization이다.
쉽게 말하면, 자동차를 운전할 때 핸들은 방향만 조정하고 악셀은 속도를 조절하는 것 처럼 한가지의 행동이 하나의 결과로 이어지는 것이다.
반대로 핸들을 조절했는데 방향과 속도가 같이 변한다면 자신이 원하는대로 조절하기 더 힘들것이다.
우리가 모델을 성공적으로 설계됬는지 평가할 수 있는 순서는 대략 아래와 같다.
- Fit training set well on cost function
- Fit dev set well on cost function
- Fit test set well on cost function
- Performs well in real world
만약 우리의 모델이 Training set와 잘 안맞는다면 , 신경망의 크기를 바꾸거나 optimizer를 바꿔보는 등의 시도를 할 수 잇다.
Dev set에서 좋은 결과를 내지 못한다면 데이터를 Regularization하거나 더 큰 training set를 학습시켜 볼 수 있다.
Test set에서 좋은 결과를 내지 못한다면 더 큰 Dev set을 설정해보는 등의 시도를 해볼 수 있다.
현실에서 좋은 성과를 내지 못한다면 cost function을 바꾸는 등의 시도를 해볼 수 있다.
중요한점은, 한가지의 action이 한가지의 결과로 이어진다는 점이다.
이러한 관점에서, early stopping은 Training set을 조금 더 덜맞추게 됨과 동시에 Dev set에 대한 최적화가 이루어 지므로 두가지에 영향을 미치기 때문에 Less Orthogonalize 한 방법이다.
(그렇다고 Early stopping 나쁘다는건 아니며, 쓰지 말아야할 이유도 없다.)
Setting Goal
- Single Number evaluation metric
모델의 성능을 평가하는 기준을 정할때는 하나의 숫자로 평가지표를 설정하는 것이 좋다.
예를 들어 어떤 classifier의 성능이 다음과 같이 측정되었다고 하자.
Precision 과 Recall 의 tradeoff가 있는 한 뭐가 더 좋은 지표인지 파악하기가 어려울 것이다.
따라서 대략 두개의 평균값을 같는 F1 score (92.4%, 91.0%) 를 비교하면 될것이다.
마찬가지로, 지역에 따른 error rate를 다음과 같는 모델이 있다고 했을때 역시 무슨 지표로 파악하기 어려울 것이다.
이 때도 마찬가지로 Average를 구하면 명확한 판단의 근거로 사용할 수 있다.
- Satisficing and Optimizing Metric
하지만 모든것을 하나로 묶어 Single number metric을 만드는것은 항상 가능한 일이 아니다. 이러한 경우를 위해 Satisficing and Optimizing metric를 설정하는 것은 도움을 준다.
만약 Accuracy가 90%, Running time이 80ms 인 모델A와 Accuracy가 95%, Running time이 1500ms인 모델B가 있다고 가정해보자.
Accuracy는 B가 더 높지만, Runnig time이 1500ms이나 걸리므로 뭐가 더 좋은지 판별하기 애매하다.
이 경우에 적용이 가능한것이 바로 Satisficing and Optimizing Metric이다.
예를들어 Accuracy를 최대화 하고 Running time은 100ms 이내를 만족하는 모델 이라는 목표를 가질 경우
최대화하는 대상인 Accuracy가 Optimizing, 조건을 만족시켜야하는 Running time이 Satisficing metric이 된다.
이처럼, 보통 N개의 평가지표(metric)이 있으면 1개의 항목을 최대화(Optimizing)으로 설정하고 나머지 N-1개를 최소조건(Satisficing) 으로 설정하면 된다.
- Train/Dev/Test Distribution
Train/Dev/Test를 어떻게 설정하느냐에 따라서 프로젝트를 얼마나 신속하게 진행하고 앞으로 나아갈 수 있는지에 대해 큰 영향을 미친다. 즉 팀의 생산성과 직결된다.
프로젝트를 시작하고 나서 dev/test set와 그를 평가할 single number metric을 설정하는 것은 그 프로젝트의 최종 목표를 정하는 것과 같다.
따라서 dev/test set에서의 높은 single number metric 달성을 위해 idea를 내고, dev set에 대한 실험을 하고 제일 나은 여러개의 모델중 제일 좋은 모델을 test set로 최종 평가한다.
여기서 중요한 점은 dev set과 test set은 같은 distribution에서 와야 한다는 것이다.
만약 그렇지 않다면, 애초에 목표와는 다른 과녁을 조준하며 활을 쏘는 연습을 하는것과 같다. 어떠한 위치의 과녁을 잘 맞추기 위해 열심히 노력했는데, test를 할 때에는 그 과녁의 위치를 옮기는 것이다.
그렇다면 많은 시간의 노력이 물거품으로 돌아가고, 처음으로 다시 돌아가 모든것을 만들어야 할 것이다. 따라서 dev set과 train set은 같은 분포에서 설정해야한다.
-Size of Dev/Test sets
Deep Learning은 대게 매우 큰 Big data를 기반으로 작동하기 때문에 기존 Machine Learning에서의 Train/Dev/Test set의 size를 결정하는 척도와는 다르고, 계속 바뀌고 있다.
Dev/Test
데이터가 비교적 적었던 옛날에는 Train/Dev/Test의 비율을 6:2:2 정도로 했던것이 합리적이었을지도 모른다.
하지만 요즘과 같은 Big data시대에는 그 규모가 백만,천만 혹은 그 이상이기 때문에 6:2:2의 비율로 설정했을 경우 너무나 과도하게 Dev/Test에 할당하게 된다.
그정도의 양은 Dev/Test를 평가하는데 있어 너무 과도할 뿐 만 아니라, 더 많은 Train data를 학습할 수록 더 높은 성능을 내는 Deep Learning model의 특징을 잘 활용하지 못하게 된다.
따라서, 충분한 data를 가지고 있다면 Dev/Test의 비율은 1%만 설정해도 평가를 하기에 충분할 것이다.
Test
Test set는 시스템 개발을 마치고 최종적으로 그 모델이 얼마나 좋은지 평가를 하는데에 쓰인다. 따라서 1만개 혹은 데이터의 규모에 따라 10만개의 Test set만 있어도 평가를 하는데에 충분하다.
그리고 최종 모델에 대한 신뢰도 높은 성능이 필요하지 않을 경우, Test set이 아예 없어도 무관할 수 있다. (사실 dev set이 Test set의 역할을 대신 한다고 생각하면 된다.)
-Chage Dev/Test sets and Metrics
앞에서 Dev/Test set과 Metric을 정하는 것은 팀에게 프로젝트의 방향성을 제시하는 것과 같다고 말했다. 물론 처음부터 올바른 목표를 정하면 좋겠지만, 프로젝트 도중에 목표가 잘못된것을 알게될 수도 있다.
이 경우 목표를 이동시키는 것이 당연하다. 예를 들어 아래와 같이 유저에게 이미지를 찾아 보여주는 모델 A,B가 있다고 생각해보자.
- A: Classify에 있어서 3%의 에러를 내지만 선정적 이미지를 포함.
- B: Classify에 있어서 5%의 에러를 내지만 선정적 이미지를 포함시키지 않음.
위와 같은 모델 A,B가 있다면 우리가 설정한 Dev/Test set과 Metric에 대해서는 A가 더 훌륭한 모델인건 틀림없다.
하지만 유저들은 예상에 없던 선정적 이미지를 보면 큰 불쾌감을 느낄 것이고, 다소 정확도가 떨어지더라도 B의 모델을 당연히 더 선호할 것이다.
이 경우 Dev/Test set을 다시 설정하고, Error를 산출하는 cost function또한 바꿔야할 수 있다.(종류에 따라 Weight를 주는 등등.)
또 다른 예로는 High quality Image들로 Train되었고, 인터넷에서 다운받은 고화질의 사진들로 구성된 Test set에 대해서는 B 보다A가 더 좋은 성능을 보인다고 해보자.
하지만 실제 application에서는 유저들이 덜 professional하고 고화질 보다는 저화질의 사진을 올리는 등의 이유로 B가 더 좋은 성능을 보일 수 있다.
이럴 경우에도 변칙적인 데이터들을 더 추가하여 Dev/Train set를 다시 구성해야 할것이다.
중요한 점은, 이 과정에 있어서도 Orthogonalization을 잘 적용시키는 것이다. 우선 어떠한 것을 목표로 해야하는지부터 명확하게 설정을 하고, 그 다음에 그 목표를 달성하기 위해 어떻게 해야할지를 고민 하는것이 좋다.
어떠한 Metric이나 dev/test set을 가지고 너무 오랜시간 매달리면 속도가 느려지고 팀의 생산성에 치명적인 문제가 생길 것이다.
Improving Model Performance
앞서 소개한 Orthogonalization, Dev/Train set설정, Human-level performance를 참고한 Bayes error활용 등의 모든 요소들을 종합해 Model의 성능을 향상시킬 수 있다.
Supervised Learning이 잘 작동하기 위해서는 다음의 두가지 전제조건을 들 수 있다.
- Training set를 잘 맞추기(avoidable bias 최소화)
- Training set의 결과를 Dev/Test set까지 잘 끌고갈 수 있는가(Variance의 최소화)
이를 위해선 우선 Human-level performance를 참고해 Training error와의 Avoidable bias를 파악하고, 그 후에는 Training set와 Dev set 의 Error 차이를 파악하면 된다. 결국 Bias/Variance의 문제다.
Bias를 줄이기 위해 노력할 수 있는 방법은 다음과 같을 것이다.
- Train Bigger Model
- Train longer/better optimization algorithms (Momentum, RMSprop, Adam 등..)
- NN architecture, hyperparameter tuning
Variance를 줄이기 위해 노력할 수 있는 방법은 다음과 같을 것이다.
- More data 수집
- Regularization (L2 norm, Drop out, Data augmentation 등..)
- NN architecture, hyperparameter tuning
막연하게 Model을 평가하고 개선하려고 노력하기 보다는, 이러한 지식을 바탕으로 더욱 체계적이고 효율적으로 성능을 향상시킬 수 있을 것이다.