최근 Andrew Ng 교수님의 Deep Learning Specialization(DLS) 과정을 들었습니다. Machine Learning이라는 완전히 다른 패러다임에 적응하지 어렵고 오랫만에 보는 수식들에 정신이 없지만, 그래도 나름 재미있게 공부하고 있어요.

DLS 강의 중 “ML Strategy” 강의가 특히 흥미로웠습니다. 이 강의를 통해 “ML engineering"을 어떻게 하는지 엿볼 수 있었기 때문입니다. 처음에는 ML System의 general 성능(실행속도 아닌 정확도를 의미)을 측정하는 게 불가능해 보였지만, 이 강의를 통해 ML System을 체계적으로, 전략적으로 분석, 개선하는 방법을 (조금이나마) 배울 수 있었습니다. 개인적으로 기억에 남는 강의여서 이 부분만 따로 정리해 올려봅니다. 총 2편으로 나눠집니다.

 

Introduction to ML Strategy

: how to structure your ML project quickly and efficiently

ML의 성능이 원하는 만큼 나오지 않았을 때(e.g., 분류 시스템의 분류정확도가 떨어질 때) 시스템 개선을 위해 할 수 있는 일은 굉장히 많습니다. 더 많은 학습 데이터를 구해볼 수도 있고, ML model을 바꿔볼 수도 있고, hyperparameter들을 tuning해 볼 수도 있습니다. 하지만 아무 방법이나 마구잡이로 시도해 볼 순 없을 겁니다. 요즘의 ML 시스템의 규모와 모델 학습에 소요되는 어마어마한 시간을 고려해 본다면, 다양한 선택지를 전략적으로 접근하는 게 더욱 중요합니다.

이렇게 많은 선택지 중 전략적인 접근을 하기 위해서는 “what to tune in order to try to achieve one effect” 를 아는 것이 굉장히 중요합니다. 이 특징을 “orthogonalization” 이라 하고, 하나의 “knob"을 돌려 한 가지의 효과를 얻을 수 있는 것을 의미합니다.

ML System의 성능 목표는 다음과 같은 순서로 타겟팅 되어야 합니다. 그리고 이 목표는 각각 다른 “knob"을 사용해서 조절해야 합니다. 각 성능 목표들을 달성시키는 과정이 다른 목표에 영향을 끼치지 않습니다. (=모두 orthogonal 합니다)

  • Chain of assumptions in ML
    • Fit training set well on cost function
      • knob: bigger network, better optimization algorithms,,,
    • Fit dev set well on cost function
      • knob: regularization, bigger training set, …
    • Fit test set well on cost function
      • knob: bigger dev set, …
    • Performs well in real world
      • knob: Change dev set or cost function

 

그런 의미에서, “early stopping"을 추천하지 않는다고 합니다. Training set, dev set 성능 둘 다에 영향을 미치기 때문입니다.

 

Setting Up your Goal

Single Number Evaluation Metric

성능을 평가할 때 가장 중요한 것은 “평가 기준“을 세우는 것 일겁니다. 평가 기준을 세울 때는 현재 시스템의 문제를 “single number evaluation metric“으로 표현할 수 있어야 합니다. 적절한 single number metric을 가지고 있다면 변경의 효과를 빠르게 파악할 수 있어 효율적인 실험이 가능합니다.

사용할 수 있는 metric의 예는 다음과 같습니다.

  • Precision: of examples recognized as cat, what % actually are cats?
    • cat으로 recognized된 것 중 몇 %가 진짜 cat인가
  • Recall: what % of actual cats are correctly recognized?
    • actual cat 중 몇 %가 올바르게 recognized 되었는가?

이 때, Precision-Recall 두 개의 기준을 사용한다면 “single number"가 아닙니다. Best 옵션이 무엇인지 알기 어렵습니다. 그럴 땐, 두 지표를 합친 새로운 하나의 지표를 만들고, 이를 기준으로 판단하는 것이 좋습니다.

Precision, Recall의 경우 F1 score 를 많이 사용합니다. (harmonic mean of P and R)

$$ F1score = { 2 \over {{ 1 \over P} + {1 \over R }}} $$

 

중요한 건

  • well-defined dev set = how your’e measuring precision and recall
  • single real number evaluation metric = quickly tell which is better

이고 이를 통해 학습 및 실험의 iterating process를 speed-up 할 수 있습니다.

 

Satisficing and Optimizing Metric

하지만 단 하나의 지표를 만들어 내기 모호한 경우가 있습니다. 예를 들면, “accuracy"와 “running time"의 평가 조건이 있을 때, 두 값을 평균을 낸다거나 “cost = accuracy - 0.5 * running_time"이라는 수식을 사용하면 원하는 목표를 적절하게 표현하지 못할 수 있습니다.

이 경우엔 accuracy는 높으면 높을 수록 좋고 running time은 최소 조건만 만족하면 됩니다. accuracy는 optimizing metric으로, running time은 satisficing metric으로 정의하고, satisficing metric을 만족하는 것 중 optimizing metric을 최대화하는 모델을 고르면 됩니다. 이 때, N 개의 metric 중, 1개는 optimizing metrics, (N-1)개는 satisficing metric이 되어야 합니다.

예를 들어, “trigger word” 인식 시스템의 평가 기준을 세워 봅시다. “trigger word"는 인공지능 스피커에서 사용자 입력 시작을 말합니다. 아이폰의 “Hi siri"나 구글의 “Okay google” 같은 단어입니다. 이 경우, accuracy, 즉 “Hi siri"를 인식하는 정확도는 높으면 높을수록 좋은 optimizing metric으로, false positivitiy(e.g., ≤1 false positive every 24 hours)는 satisficing metric으로 잡을 수 있습니다.

 

Size of the Dev and Test Sets

ML System 구축 시 사용되는 data는 보통 3가지의 data set로 나눠서 사용하게 됩니다.

  • Training set: machine training 용 data set
  • Dev set: used to evaluate different ideas and pick one
  • Test set: 최종 성능을 보는 data set. 이게 만족스러울 때 까지 dev set으로 최적을 찾는다

 

예전에는 다음과 같은 구성을 많이 사용했다고 하는데요, 이 구성은 data set이 작을 때, 예를 들면 100, 1K, 10K 정도의 데이터가 있을 때는 좋은 구성이라고 합니다.

  • 70 % training set, 30% test set
  • 60% training set, 20% dev set, 20% test set

Modern ML에서는 사용하는 데이터 양이 굉장히 많습니다. 1000K 정도의 데이터를 사용하는 요즘에는, 1%만 사용해도 test set이 10K example을 갖게 됩니다. 그래서 이 경우엔 training set에 최대한 많은 데이터를 사용하는 것이 더 좋다고 합니다. 엄청나게 큰 training set을 쓰는 것이 트렌드라고 하네요.

  • 98% training set, 1% dev set, 1% test set

 

여기서 test set의 크기에 대해 좀 더 얘기하자면,

  • Test set은 시스템의 성능을 평가할 수 있을 만큼 big enough 해야 합니다.
  • 아주 아주 accurate measure가 필요한 경우가 아니라면 millions 이상의 sample이 필요하지 않을 것, 즉 10K, 100K 면 충분하다고 합니다.
  • 때로 high confidence가 필요하지 않은 경우엔, test set을 사용하지 않거나 dev set을 test set으로 사용할 수도 있습니다 - 추천하는 좋은 방향은 아니지만, 데이터가 절실할 땐 이런 시도도 해볼 수 있는 것 같습니다.

 

Train/Dev/Test Distributions

갖고 있는 data들을 3개의 data set으로 나눌 때 주의해야 할 점들이 있습니다. 바로 “data distrubution” 입니다.

Dev data set과 test data set의 data distribution은 최대한 유사해야 합니다. 예를 들어, 여러 region에서 얻은 data가 있다면 이걸 어떻게 사용해야 할까요?

  1. 특정 지역에서 나온 데이터를 dev set으로 / 또 다른 지역에서 나온 것 test set으로 사용

좋지 않은 선택입니다. dev/test set의 distribution이 달라져, 타겟 분포가 아닌 분포를 갖고 학습시키기 때문입니다. 학습과 테스트의 타겟 자체가 달라지는 것 입니다.

  1. randomly shuffle into dev / test set

이렇게 하면 dev/test set의 distribution이 같아지므로, 좋은 선택입니다.

 

수업에서 제시 된 Guideline은 다음과 같습니다.

  • Choose a dev set and test set to reflect data you expect to get in the future and consider important to do well on
  • same distribution! 타겟하는 형태로 트레이닝/테스트 해야 한다!

 

참고로, 이후 다른책에서 “훈련/테스트 데이터 분포에 차이가 있을 때” 할 수 있는 전략을 알 수 있었는데요. 보통의 ML 과제에서는 data distribution 조절이 그리 어렵지 않으나, 캐글 대회에서는 정해진 training, test set 이 있어서 이런 상황에 대응해야 할 때가 있습니다. 이럴 때 취할 수 있는 전략은 아래와 같습니다.

  • 억제: dev/test set 분포가 같아질 때가지, 결과에 가장 큰 영향을 미치는 변수를 제거해 본다.
  • test set과 가장 유사한 세트로 훈련: test set과 유사한 분포를 가진 dev set을 sampling 하여 사용한다.
  • test set를 모방한 검증: 모든 데이터를 학습에 사용하되, test set과 유사한 분포의 데이터만 평가에 사용한다.

 

When to Change Dev/Test Sets and Metrics?

ML System을 개발하다 보면, 어떤 이유에서든 원하지 않는 혹은 잘못된 결과가 나온다면, 더 나은 알고리즘을 판별하는 기준을 바꿔야 할 수 있습니다. Evaluation metric 혹은 dev/test set을 바꿔야 합니다.

  • Evaluation metric을 새로 만드는 예시: Untitled

    • 기존의 cost function에 새로운 weight를 추가할 수 있습니다.

  • dev/test set을 바꾸는 예시:

    • Dev/test set에서는 고화질의 사진을 사용했는데, user images는 low quality,./. 일 경우 데이터셋의 변화가 필요합니다.
    • If doing well on your metric + dev / test set does not correspond to doing well on your application, change your metric and/or dev/test set

중요한 건, 완벽하지 않은 evaluation metric을 갖고 있더라도 일단 이를 타겟으로 빠르게 시작하는 것 입니다.

 

Comparing to Human-level Performance

최근의 ML의 급격한 발전으로, 그 성능이 human-level 성능과 비교할 만 해졌습니다. 그래서 이제는 성능 목표를 human-level performance, 혹은 그 이상을 잡는 경우가 많은 것 같습니다.

 

완벽한 성능은 불가능 할 수도 있습니다. 이미지 분류 시스템에서 사진 혹은 그림이 애매하여 사람조차도, 그 누구도 그게 무엇인지 말할 수 없는 경우가 그 예입니다. 반면 Bayes-optimal performance는 특정 task에 도달할 수 있는 이론 상 최대 성능입니다. Human-level performance보다 높은 정확도로, 우리가 타겟하는 성능이 될 수 있습니다.

human_level_performance

위의 그래프에서 보는 것과 같이, ML System의 성능이 human-level performance에 도달하기 까지는 금방이지만, 그 이후에는 성능 개선이 어려워 집니다. 하지만 사실 human-level performance가 꽤 높습니다(bayes-optimal에 꽤 가깝습니다). Human-level performance보다 낮을 땐 사용할 수 있는 tool이 꽤 많이 있으나, 그 이후 개선에 사용할 수 있는 툴은 많지 않습니다.

많은 task들에 대해, Human-level performance는 꽤 좋습니다. 그래서, ML System이 human-level performance 이하라면, 다음과 같은 것들을 해 볼 수 있습니다.

  • Get labeled data from humans
  • Gain insight from manual error analysis: Why did a person get this right?
  • Better analysis of bias/variance (아래 이어질 내용)

 

Avoidable Bias

Bayes-optimal performance의 값을 정확히 알 수 없으니, 우리는 Human level performance를 bayes optimal performance의 proxy로 사용할 수 있습니다. Human level performance에 도달하는 것을 목표로 잡는 것만으로도 충분할 수 있는 거죠.

 

풀고자 하는 문제의 최대 성능, human level performance를 dev/training set의 성능과 비교할 때, human level performance와 training set performance 간 차이를 avoidable bias라고 하고 training set 과 dev set 사이의 performance 차이는 variance라고 합니다.

다음 그림과 같이, 여러 ML 모델의 성능이 다음과 같다고 예를 들면,

avoidable_bias

  • 왼쪽: training set error는 8%, Dev set error는 10%인데, human level error는 1%인 경우입니다. 이 경우 training-dev error 차이를 좁히는 것도 의미가 있지만, training set의 성능 자체를 human level 까지 올리는 데 집중하는 것이 좀 더 의미 있습니다. (avoidable bias에 집중하는 것이 좋다)

  • 오른쪽: training/dev set error는 왼쪽과 동일하나 human level error가 7.5%, 즉 dev set error와 크게 차이가 나지 않는 경우 입니다. 이 경우는 human level performance에 도달하는 것 보다, training-dev set 간 성능 차이를 개선하는 것이 더 의미있습니다. (variance에 집중하는 것이 좋다)

 

Understanding Human-level Performance

그렇다면, Human level performance은 어떻게 측정할 수 있을까요. 사실 이 성능은 애매할 수 있습니다. “어떤 사람"이냐에 따라 그 성능은 천차만별일 수 있기 때문입니다.

 

what_is_human_level

X-ray 이미지 분류 예시에서는, 보통의 사람들은 3%의 에러율로 이미지를 분류하지만, 숙련된 전문가들은 0.7%의 에러율을, 숙련된 전문가들이 토론을 통해 낸 결론에서는 고작 0.5%의 에러율로 이미지를 분류했다고 합니다.

이 때 human-level performance는 어떤 사람으로 잡아야 할까요? 이 경우 Bayes-optimal performance의 proxy로 사용할 성능은 가장 좋은 성능입니다. 즉, bayes-optimal 성능은 0.5%보다 낮을 것 이기 때문에, 0.5를 목표 성능, human-level performance로 잡아야 하는 것 입니다.

하지만 용도에 따라 조금씩 선택이 달라질 수 있다곤 합니다. Human level performance를 최대치로 잡으면 집중해야 하는 부분을 잘못 선택할 수도 있습니다. Variance 문제를 풀어야 하는데, bias 에 집중하게 만드는 경우이죠. Human-level 성능과 training-dev set 성능이 충분히 높아 그 차이가 매우 크지 않을 때 이 문제가 두드러진다고 해요. 항상 마지막 행주를 쥐어짜는 성능 개선은 미묘하고 어려운가 봅니다.

 

Surpassing Human-level Performance

다음과 같은 분야들에선 ML System이 human-level 성능을 “surpass” 하곤 합니다.

  • Online advertising
  • Product recommendations
  • Logistics (predicting transit time)
  • Loan approvals
  • Speech recognition
  • Some image recognition
  • Medical tasks

대부분 structured data로부터 학습하는 것, 많은 데이터를 분석하는 것, 그리고 natural perception이 아닌 것들입니다. Natural perception 과 관련된 task는 인간을 이기기가 어렵습니다.

 

Improving your Model Performance

지금까지의 내용을 요약하면 다음과 같습니다.

summary

 

Supervised learning에서 원하는 성능을 만족시키기 위해선 다음 두가지를 고려해야 합니다. 그리고 두 task는 서로 orthogonal 합니다.

  1. You can fit the training set pretty well (low avoidable bias)
  2. The training set performance generalizes pretty well to the dev/test set (low variance)