[Structuring ML Project] Orthogonalization

1. Orthogonalization (직교화)

 

머신러닝 시스템을 구축할 때 어려운 점 중 하나는  시도해 볼 수 있는 것도, 바꿀 수 있는 것도 아주 많다는 것이다.

무엇을 튜닝할 것인지에 대한 뚜렷한 안목을 가지고 하나의 효과를 얻어내기 위한 절차를 Orthogonalization (직교화)라고 한다. 

 

1) Chain of Assumptions in ML

 

Procedure	Failure
1. Fit training set well in cost functinon	=> bigger network, better optimization algorithm
2. Fit dev set well on cost function	=> Regularzation, Bigger training set
3. Fit tset set well on cost function	=> Bigger dev set
4. Performs well in real world	=> Change dev set or cost function

Failure는 각 절차에서 원하던 목표치의 결과가 나오지 않았을 때 할 수 있는 방법들이다. 아래에서 더 자세히 살펴보자.

 

2. Single Number Evaluation Metric

 

 

 

 

Classifier A를 만들고 Hyper parameter 의 변화 등을 주어 새로운 Clasifier B를 만들었다고 하자. 이때 이 두가지 분류기 중 합리적인 성능 평가 방법을 볼 수 있는 것은 정밀도와 재현율을 보는 것이다. 

 

 

 

이때 예시로 고양이를 판별하는 Classifier에 대해 

Classifier A : 95% (Precision) | 90% (Recall) | 92.4 % (F1 Score)

Classifier B : 98% (Precision) | 85% (Recall) | 91.0 % (F1 Score)       인 경우 

 

A가 95%의 확률로 고양이를 올바르게 판별하며 (정확도), 모든 개발 세트의 이미지에서 실제 고양이인 이미지를 90%의 정확도로 인식했다는 것이다(재현율). B와 비교했을 때 이 두가지 평가지표로는 둘 중 하나를 빨리 선택하거나, 더 여러개의 분류기 모델이 있을 경우 그 중 하나를 선택하는 것이 어려울 것이다. 따라서 우리는 두개를 결합한 F1 Score를 주로 사용한다. 이를 사용하면 분류기 A가 B 보다 더 나은 성능을 가지고 있다고 판단할 수 있다. 

 

F1 Score

: 정밀도 (Precision)와 재현율 (Recall)의 조화평균으로 계산되는 성능 측정 지표이다. 주로 Classification (이진 분류) 문제에서 사용한다.

$$ F1 Score = 2 * \frac{Precision * Recall}{Prcision + Recall} $$

 

Precision은 앞서 언급한 것 처럼 모델이 분류한 양성 예측 중에서 실제로 양성인 비율을 나타내며 Recall은 실제 양성 중에서 모델이 양성으로 예측한 비율을 의미한다. 

 

3. Train / Dev / Test  Distributions

 

🌟 Choose a dev set and test set to reflect data you expect to get in the future and consider important to do well on. 

=> Dev set과 Test set은 동일한 Distribution에서 나와야한다. 

e.g 여러개의 나라를 기준으로 cat의 이미지를 분류하는 모델을 만든다고 할 때, 특정 A ~ C 나라의 데이터를 가지고 모델을 학습, develop시키고 D ~ F 나라의 데이터로 test한다고 하면 이 두 set의 데이터는 다른 분포에서 나온 것이므로 원하는 목표치의 값이 나오지 않을 것이다!

 

1 ) Old way of splitting data

     (1) train 70% | test 30 % 혹은  train 60% | dev 20 % | tset 20 % 가 기존 방식이였음

     (2) 그러나 최근 데이터 세트의 양이 크게 늘어난 딥러닝 시대에서는 이보다 더 적은 퍼센트로 dev, test를 구성하는 게 맞음 

 

2) Dev / Test set & Metrics를 바꿔야하는 때 ?

     dev / test set + metric이 좋은 성능을 보였을지라도, 실제 적용시 상응하여 좋은 결과를 나타내지 못한다면 ! 이때 test / dev set & metrics를 바꿔야할 때이다. 예를들어 dev, test set은 고품질 이미질을 다뤘지만 실제 사용자의 이미지를 적용하는 때에는 저품질의 이미지가 주를 이루어 실제 평가 결과가 성능을 제대로 예측하지 못한다면말이다. 

 

4. Human - level Performance

 

     1) Bayes (optimal) error : 성능의 이론적인 한계점. x에서 y로의 매핑을 이론적으로 가장 정확하게 나타내는 함수 

     

     따라서 인간 수준의 성능을 능가하기 전까지의 발전 속도는 보통 꽤나 빠르지만, 그 이후로는 간혹 느려지기도 한다. 그 이유는 크게 두가지 이다 첫째, 많은 프로젝트에서 human level performance가 bayes error와 그렇게 많이 떨어져 있지 않기 때문이다. 따라서 인간 수준 성능을 이미 능가한 시점에서는 더 발전할 수 있는 부분이 제한적이라는 것이다. 둘째, 성능이 인간 수준에 미치지 못할 경우 여러가지 도구를 이용해 성능을 개발할 수 있다. 이런 도구는 human level performance를 넘은 뒤에는 사용하기 어렵다. 

 

     즉, 알고리즘이 human level 보다 나쁜 경우 크게 3가지 방법을 시도해 볼 수 있는데 human으로 부터 labeled data를 더 얻어오거나 에러에 대해 왜 알고리즘이 틀린 부분과 사람이 맞은 부분이 다른 지 등을 비교해 볼 수 있다. 또한 더 나은 bias / variance에 대한 분석을 실시하는 방법도 있다. 

 

 

동일하게 cat classification을 하는 예시를 생각해보자.

 

그리고 두가지 case가 있다.

• Human level error  1 %    |   Training error 8%   |   Dev error 10 %
• Human level error  7.5 % |   Training error 8%   |   Dev error 10 %

첫번째 경우에는 1%까지 에러를 줄일 수 있다고 생각하면 8%의 training error는 상당히 큰 값이다. 이 경우세는 bias reduction 전략 (편향 감소 전략)이 도움이 될 것이다. 반대로 두번째 경우에는 7.5%와 8%를 비교하면 더 training error를 줄일 수 있는 여력이 많지 않다. 또한 human level이 7.5% 이기에 이것보다 더 나은 값을 원하지는 않을 것인데 대신 training과 dev의 2 % 차이를 줄이는 편이 훨씬 쉬울 것이다. 이 경우에는 정규화나 훈련 데이터를 더 수집해 variance reduction 전략을 사용할 것이다.

 

• Avoidable bias ; Human-level과 Training error 사이의 간격 좁히기 
  
  • Train bigger model
  • Train longer / better optimization algorithms (RMSProp, Adam,.. etc)
  • NN architecture / hyperparameters search
• Variance ; Training error 와 Dev error 사이의 간격 좁히기
  • More data
  • Regularization
  • NN architecture / hyperparameters search