ML Strategy (1주차) 정리

Orthogonalization (직교화)

 

Orthogonalization이란? : 보통 직교한다는 것은 두 각이 직각을 이루는 것을 의미한다. 운전을 할 때의 예시에 적용해보면, 하나의 차원은 각도만 움직이고 하나의 차원은 속도를 조절한다고 하면,  두 각이 직각을 이루도록 설계를 하는 것이다. 즉 하나의 버튼 (동작)이 하나의 기능만 하도록 설계하는 것을 의미한다. 이렇게 직교화를 고려해서 설계를 하는 것은, 다양한 하이퍼파라미터를 고려해야하는 ML에서 중요한 요소라고 할 수 있다. 

 

 

 

직교화가 잘 되어 있으면 training set -> dev set -> test set -> real word 로 가는 ML 파이프라인에서 각 상황에 맞게 조절할 수 있다. 그런데 예를 들어 early stopping과 같은 경우에는 (1) training set에서의 성능 개선 (2) dev set에서의 성능 개선 두 가지 기능을 하기 때문에 직교화가 덜 이루어졌다고 할 수 있다. 이것이 효과있는 방법이긴 하지만 파라미터를 조정하기 어렵게 만들 수 있다.  

 

Single Number Evaluation Metric

 

강의 제목은 실수(real number)로 된 평가 기준을 의미한다. 머신러닝 프로젝트를 할 때 단일 실수로 성능의 척도를 판단할 수 있는 평가 메트릭을 사용하면 좋다. 그 예시로는 정밀도 (Precision)와 재현율(Recall)이 있다. 머신러닝에서는 정밀도와 재현율을 결합해서(조화평균) f1 score로 종종 평가한다.   

 

정밀도 : 모델이 분류한 정답 중 진짜 정답이 얼마나 되는지

재현율 : 실제 정답 중 모델이 분류한 정답이 얼마나 되는지

- 정밀도와 재현율은 trade off 관계에 있다고 함 

Satisficing and Optimizing Metric 

 

여러 모델 중에 고를 때 평가 메트릭을 Optimizing과 Satisficing으로 나눌 수 있다.

Optimizing(최적화) 메트릭은 해당 모델의 목표인, 성능이 높으면 높을 수록 좋은 메트릭을 말한다. 보통 정확도를 말한다.

반면 Satisficing(만족) 메트릭은 어떠한 조건을 만족하기만 하면 그 성능은 상관이 없는 메트릭을 말한다. 위 이미지에서는 Running time(실행 시간)을 말하는데, 만약 100ms 이하를 원한다면 그 이하로는 얼마나 빠른지는 중요하지 않다. 해당 조건만 만족하면 되는 메트릭이다.  요약하자면 많은 것들을 고려해야 할 때, 성능을 최대로 높이고 싶은 한 가지를 Opotimizing metric으로 두고, 어떠한 기준만 넘기면 되도록 하나 이상을 Satisficing metric으로 정함으로써 빠르게 모델을 선별할 수 있다. 

 

Train/Dev/Test Distributions

 

8개 지역에 있는 고양이 사진 분류기를 만든다고 했을 때, 어떻게 dev set과 test set을 구분하면 좋을까? (dev set에서 보통 하이퍼파라미터를 조정한다.) 지역별로 dev set과 test set을 나누는 것은 최악의 선택이다. 왜냐하면 두 set의 데이터 분포가 다르기 때문이다. 이렇게 되면 몇달동안 dev set에 대해 성능이 좋게 튜닝을 해도 test set에서의 성능이 안좋을 확률이 높다. 더 좋은 방법은, 8개의 지역을 모두 섞어서 랜덤 샘플링 하는 것이다. 그러면 두 set의 데이터 분포 또한 크게 차이가 없을 것이다.

 

Size of the Dev and Test sets

 현대 딥러닝 시대에서 data set이 커질 수록 train set의 비율을 높이고 (98%), test set과 dev set의 비율을 낮추고 있다. 예를 들어 백만 데이터가 있다면 모델을 테스트하는 용도는 만개의 데이터로도 충분하기 때문이다. 

 

When to Change Dev/Test Set and Metrics?

머신러닝 프로젝트 도중에 dev/test set이나 평가 척도를 바꾸고 싶을 때는 어떻게 해야할까? 

만약 기존 평가 척도에서는 A의 에러율이 더 낮지만, 알고보니 A가 부적절한 사진 또한 함께 분류한다는 사실을 알게 되었다고 가정해보자. 그럴 경우 기존 평가 척도를 수정할 수 있다. (만약 이상한 사진이 나오면 weight를 더 많이 부여해서 에러율을 높이는 방향으로) 이렇게 중간에 모델의 오류를 발견했을 때 평가 메트릭을 수정할 수 있다. 

 

 

평가 척도를 정의하는 것과, 그 평가 척도가 잘 작동하는지 보는 것을 구분할 필요가 있다. 일단 정의한 다음 (1) 이것이 잘 작동하지 않는다는걸 확인하면 (2) 과정에서 비용함수나 평가 지표가 수정될 수 있다. (2)을 위해서 (1) 정의를 못하는 것보다는, 완벽하지 못하더라도 우선 정의를 하고 반복 과정을 늘리는 것을 추천한다. 

 

dev/test set에서는 고화질의 고양이 사진으로 좋은 성능을 얻었는데, 실 사용에서 그 성능이 제대로 발휘되지 않을 수 있다. (예를 들어 유저가 흐린 사진이나 저화질의 사진을 올리는 경우가 그렇다.) 이렇게 만든 모델이 실 생활에서 제대로 작동하지 않을 경우 data set이나 평가 기준을 다시 세울 필요가 있다. 

 

Why Human-level Performance? 

 

보통 human level performance (사람이 구분할 수 있는 정도) 까지 모델의 성능을 올리는 것은 쉬운데, 그 이후부터는 성능이 올라가는 기울기가 점차 낮아진다. 그리고 베이지안 최적 오차 (정확한 정의는 모르지만, 가능한한 가장 에러가 낮은 정도를 말하는 것 같다.)를 넘는 것은 정말 어렵다고 한다. 왜 사람이 할 수 있을 정도의 성능까지 끌어올리는 것은 쉬울까?

 

 

만약 모델 성능이 사람보다 떨어진다면 사람이 개입하여 위에 있는 것들을 시도해볼 수 있다.

(1) 사람에게 라벨링 부탁 (2) 사람이 직접 에러 케이스 분석 (3) 편향/분산 분석 

하지만, 모델의 성능이 사람보다 좋아지면 위에 것들을 적용하기 어려워진다. 

 

Avoidable Bias

사람이 어느정도로 잘 해내는지를 안다면, 이를 통해 training set에 대한 모델의 적절한 성능이 어느정도일지 가늠할 수 있을 것이다. 

 

같은 training error / dev error에 대해서도 human level performance가 어떻게 되는지에 따라서 이후 진행 방향이 달라질 수 있다. 예를 들어 training error가 8%, dev error가 10%이고 human error가 1%인 상황에서는, bias가 크기 때문에 우선 training error에 대한 성능을 더 늘려야 한다. 반면 오른쪽의 상황에서는 human error와 training error가 큰 차이가 나지 않으므로 variance (training error와 dev error의 차이)를 줄여나가는 방향으로 진행되어야 한다. 그러기 위해 정규화와 같은 방법을 쓸 수 있을 것이다. 여기서 human error와 training error의 차이를 avoidable bias라고 한다. 

 

우리가 지금까지 살펴봤던 bias는 0%인 에러율과 학습 에러율의 차이를 의미했다. avoidable bias는 우리가 임의로 정의한 human level과의 차이를 의미한다. 높은 성능을 원할 경우 human level error을 bayes error의 추정치라고 볼 수 있다. bayes error는 0%가 아닐 수 있지만, bayes error보다 더 적은 에러율을 내는 것이 거의 불가능할 때를 의미한다. 

 

Understanding Human-level Performance

Human level performance라는 말은 paper에서 큰 의미 없이 쓰일 때도 많다. 이번 강의에서는 그 용어를 더 정확하게 정의하고 이 정의를 활용해서 머신러닝 프로젝트를 발전시키도록 해보겠다. 

 

위와 같은 가정이 있을 때, human level error을 어떻게 정의할 것인가? human level error을 우리는 bayes error (최적의 에러값)의 추정치로 본다고 했었다. 이러한 가정으로 생각해봤을 때, human level error는 위 가정 중 가장 낮은 에러율을 가지는 (d) 0.5%로 정의할 수 있을 것이다. 

 

human level error을 정의함에 있어서 목적이 무엇인지를 명확히 하는 것이 중요하다. 일반적인 의사만큼, 혹은 그 이상의 성능을 목표의 목표로 둔다면 (b)를 human level error로 두는 것이 좋을 것이다.

 

3번째 예시처럼 bias도 작고, variance도 작은 경우, human level error을 어떤 것으로 정의하느냐에 따라 이후 의사결정이 달라질 수 있다. 이것이 모델의 성능이 human level에 근접할 수록 모델을 훈련시키기 어려워지는 이유이기도 하다. 세번째 case에 비해 첫번째나 두번째 경우는 앞으로 해야할 일이 명확하다. 

 

Surpassing Human-level Performance

 

만약 오른쪽 경우처럼 training error가 human level error보다 더 적을 경우, overfitting되어서인지 아니면 bayes error가 알고보니 더 낮아서인지 판단하기 어렵다. 따라서 더 모델의 성능을 발전시키기 어렵기도 하다. 이렇게 ML의 성능이 사람보다 좋은 경우가 그렇게 많지는 않다. 

주로 사람보다 모델이 더 뛰어난 성능을 낼 때는 Structured data 에 대해서였다. 하지만 요즘은 딥러닝이 발전하면서 unstructured data에 대해서도 좋은 성능을 내고 있다.  

 

Improving your Model Performance