[Kaggle Study] 7. About Structuring ML Projects (1)

This post is a summary of Coursera Andrew Ng's lecture:

머신 러닝 프로젝트 구조화

Introduction

• 위의 예를 보면 알 수 있듯이 머신러닝 모델이 원하는 성능보다 저조한 성능을 보였을 때 취할 수 있는 조치는 수없이 많습니다. 
• 머신러닝 프로젝트를 진행할 때 수없이 많은 방법들 사이에서 어떤 부분을 집중적으로 개선할지 판단할 수 있는 기준점을 세워야 기한이 정해진 프로젝트에서 원하는 성과를 낼 수 있습니다. 

Orthogonalization

• 머신러닝 프로젝트를 진행하면서 위 4가지가 최대한 모두 만족하는 모델을 찾는 것이 목표입니다. 
• 각 단계에서 문제가 발생했을 때의 해결방법이 다릅니다: 문제간의 상관관계를 생각하기보단 각 문제를 구별하여 하나의 문제로 정의하고 풀어가는 것이 이상적입니다. 
  • 같은 맥락에서 Early stopping 기법은 사용하기 까다롭기 때문에 배제하는 것이 나을 수 있습니다.
  • Early stopping 기법은 training set과 dev set에서 일어나는 문제를 각각의 문제로 정의하지 않고 두가지 모두에 영향을 주기 때문에 사용하기 까다롭습니다.
    • 1. loss function의 값을 최대한 감소시키는 것과 2. overfitting을 방지하는 것 으로 구분시켜서 모델을 향상시키는 것이 좋습니다.
• Orthogonalization은 위와 같이 각 문제를 구별하여 하나의 문제로 정의하여 풀어가는 방식을 뜻합니다.

Single Number Evaluation Metric

• idea -> experiment -> code 의 주기를 더 빠르게 돌려서 모델의 성능을 더 빠르고 효율적으로 향상시키려면 Single Number Evaluation Metric을 지정하는 것이 좋습니다.
• 위의 사진의 예와 같이 Precision과 Recall의 정확도만 두고 봤을 때는 A classifier는 Recall에서 더 좋은 성능을 보이고, B classifier는 Precision에서 더 좋은 성능을 보이기 때문에 둘 중 어느 모델이 더 낫다고 확실하게 말할 수 없습니다.
• 하지만, F1 Score이라는 간단하게 말해 Precision과 Recall의 성능을 평균내서 하나의 숫자로 나타내는 Single Number Evaluation Metric을 지정하게 되면 그 판단이 훨씬 빨라집니다.
• 좋은 Dev set과 Single (real) Number Evaluation Metric을 갖추게 되면 iteration(주기)를 더 빠르게 돌릴 수 있다고 말할 수 있습니다.

Satisficing Metric & Optimizing Metric

Single Number Evaluation Metric을 정의하여 사용할 수 없는 경우도 있습니다.

• 위와 같은 경우에는 accuracy와 running time의 단위가 맞지 않기 때문에 단순하게 평균을 내거나 Single Number Evaluation Metric으로 만들기 까다롭습니다.
• 이런 경우에는 Optimizing metric과 Satisficing metric을 지정해서 사용하면 편리합니다.
• Optimizing metric은 최대 성능을 내는 metric을 의미하고 Satisficing metric은 기준점을 지정하여 해당 기준점에 만족하기만 하면 상관이 없는 metric을 의미합니다.
• 위의 예시에서는 running time을 100ms 이하로 설정하고(satisficing metric), accuracy를 최대치로 갖는(optimizing metric) 모델을 최고 성능 모델로 정의하였습니다.
• 보통 n개의 metric이 있을 때 1개의 optimizing metric을 설정하고 나머지 n-1개의 metric은 satisficing metric으로 지정하는게 일반적입니다.
• false positive의 개수와 같은 기준점을 따로 정의하여 satisficing metric으로 정의하는 것도 효과적입니다.

Train/Dev/Test Distribution

• Development set(hold out cross validation set)과 Test set은 같은 distribution에서 추출해야합니다. 
• Dev set 에서의 performance로 test set 에서의 performance를 예측할 수 있어야 하기 때문입니다.

Choosing Size of the Dev & Test dataset

• 70:30 으로 train datset과 test dataset을 나누거나 60:20:20 으로 train, dev, test dataset을 나누는 방식은 큰 규모의 데이터를 다루는 현대의 머신러닝 모델과는 잘 맞지 않습니다.
• 현대의 딥러닝 알고리즘들은 큰 training dataset을 요구한다는 점도 크게 작용합니다.

• 완성된 머신러닝 모델의 성능을 아주 세밀하게 검사해야될 필요가 없다면 test dataset을 아주 크게 가져갈 필요는 없습니다.
  • 큰 데이터셋을 다룬다면 10,000개 에서 100,000개 정도의 성능을 검사할 수 있을 정도의 양이면 충분합니다.
• 따라서, test dataset을 배제하고 train과 dev set으로만 머신러닝 모델을 구축하는 것도 합리적인 경우도 있습니다.
  • 하지만 이런 경우는 예외적인 상황이며 일반적으로 머신러닝 모델의 unbiased estimation을 위해서는 test set을 구축하는 편이 좋습니다.

When to change dev/test sets and metrics

• 위의 예시에서는 고양이 이미지를 분류하는 classifier 모델을 비교합니다.
  • A 알고리즘은 3%의 오차를 내기 때문에 성능 측면에서는 B 알고리즘보다 우세하지만, 선정적 이미지도 고양이 이미지로 분류하기 때문에 문제가 있습니다.
  • B 알고리즘은 5%의 오차를 내므로 A 알고리즘보다 성능 측면에서는 살짝 떨어지지만, 선정적 이미지에 대한 분류를 잘 하기 때문에 오히려 A 알고리즘보다 적합하다고 판단됩니다. 
• 이런 경우에는 오차를 계산하는 수식을 위와 같이 수정할 수 있습니다.
  
  • 예측값(고양이가 맞는지 아닌지를 나타내는 0/1 값: y hat)과 실제 값(y)이 같은지 아닌지를 표시하는 identifier 앞에 w 값을 곱합니다.
  • w는 i번째 데이터가 선정적 이미지가 아니라면 1, 맞다면 10의 값을 갖기 때문에 선정적 이미지에 대한 오차 값을 대폭 상승시킵니다.
    • 위와 같이 선정적 이미지에 대한 오차 값을 상승시킴에 따라서 선정적 이미지가 고양이 이미지가 아닌 축으로 분류되도록 합니다.
  • 최종 오차값이 0 ~ 1의 범위를 갖을 수 있도록 1/m의 값 대신 1/(w 값을 모두 더한 값)으로 나눠줍니다.

Comparing to Human-level Performance

• 인간의 능력과 비교되는 이유
  1. 딥러닝 기술의 발전으로 인해 머신러닝 알고리즘 성능이 인간과 겨룰 정도로 향상되었기 때문
  2. 인간도 수행할 수 있는 작업들에 대한 흐름(flow)이 머신러닝 알고리즘이 인간보다 효율적이기 때문에 비교가 불가피함

• Bayes optimal error은 theoretical limit을 의미함
  • 즉, best possible error, x에서 y로 매핑되는 함수가 넘을 수 없는 수준의 정확도를 의미함
  • 이런 한계는 흐릿한 이미지, 음성 데이터에 포함되는 노이즈 등의 이유로 인해 형성됨
• 머신러닝 알고리즘들이 human level performance를 달성하기 까지는 굉장히 가파르게 향상되다가 Bayes optimal error에 도달하기 까지는 느린 속도로 향상되는 이유:
  1. 일단 대부분의 문제에서 human level performance와 Bayes optimal error의 차이는 크지 않음
  2. 아래 이미지 참고

Avoidable Bias

• 위에서 언급한 것과 같이 인간의 능력으로 해당 문제를 얼마나 잘 해결할 수 있는지 측정하는 것(bias, variance, ...)은 해당 문제를 해결하는 머신러닝 모델을 향상시키는데에 도움을 줌

• 위의 예시를 보면 human level performance를 기준으로 판단하면 됨
  • 왼쪽 예시에서는 human level performance가 1%의 오차를 내기 때문에 이를 training error와 비교하면(8%) 과소적합이라는 결론을 낼 수 있음(training set에서도 오차가 큼)
    • 따라서 bias를 줄여서 과소적합을 해결하자는 프로젝트 방향성을 구축할 수 있음
  • 오른쪽 예시에서는 human level performance를 봤을 때도 7.5%의 오차를 내기 때문에 training error와 큰 차이가 없음
    • 따라서 과소적합은 아니라고 판단하고 dev error를 줄이기 위해 variance를 줄이는 방향으로 프로젝트를 진행할 수 있음
• 결론적으로 human level performance는 bayes error의 proxy(대리)로서 사용할 수 있음
  • 특히 computer vision과 같이 인간의 능력으로 충분히 잘 수행할 수 있는 작업에 한해서는 더욱 그러함
• Bayes Error 혹은 Approximation of Bayes error(human level performance)와 training error의 차이를 "Avoidable Bias"라고 부름
• 위의 예시에서는 Avoidable Bias는 0.5%이고 Measure of Variance(training error와 dev error의 차이)는 2%이므로 variance를 줄이는 것이 합리적인 판단임

Understanding Human-level performance

• Bayes error의 정의에 따라 해당 값은 0.5% 보다 낮을 것임은 분명함
• 따라서, human-level performance를 Bayes error의 estimation으로 사용할 경우에는 0.5%로 잡는 것이 합리적인 방법들 중 하나라고 생각됨
• 하지만, 모델의 목적성에 따라서 이는 달라질 수 있음: 만약 Typical doctor 보다 나은 모델이면 deploy 할거라는 계획을 가졌다면 Bayes error를 1%라고 잡을 수도 있음(0.5%가 가장 최선의 Bayes error라는 사실은 변함없음)

• 첫 번째 경우에는 Human level performance를 1%, 0.7%, 0.5% 중 어느 것으로 잡아도 Avoidable bias가 Measure of variance 보다 크기 때문에 Bias를 줄여서 과소적합을 해결하는 방향이 합리적임
• 두 번째 경우에는 Human level performance와 상관없이 Measure of variance가 더 크기 때문에 variance를 줄이는 방향이 합리적임
• 하지만 마지막 경우에는 Bayes error를 무엇으로 잡는지가 상관이 있어짐
• 이 예시를 통해서 알 수 있는 점은 모델의 향상에 있어서 Human level performance의 극한이 어디인지를 파악하는 것은 굉장히 중요함
  • 만약 Human level performance가 0.5%까지 도달할 수 있다는 사실을 모르고 0.7%가 최선이라고 알고 있었다면, 과소적합이기 때문에 training에 더 치중해야 된다는 결론을 도출하지 못함
  • 0.7%로 알았다면 Avoidable bias는 0%이므로 variance를 줄이려는 방향으로 프로젝트가 진행될 가능성이 큼

Surpassing Human-level performance

• 오른쪽 예시를 보면 파악 가능한 Human level performance 보다 training set 성능이 더 좋기 때문에 Bayes error 파악이 불가능함
• 따라서, Bias를 줄이는 쪽으로 프로젝트를 진행해야 될지 Variance를 줄이는 것에 집중해야 할지 모름

• Natural perception task가 아니고 structured data를 사용하며 인간이 감당할 수 없는만큼의 데이터가 필요한 작업들은 머신러닝 모델들이 월등히 잘할 수 있음

Improving your model performance

---

I love pressure; pressure makes diamonds.
- Conor Mcgregor -