ML Strategy 1(orthogonalization, evaluation metric, human-level performance)

해당 내용은 Coursera의 딥러닝 특화과정(Deep Learning Specialization)의 세 번째 강의 Structuring Machine Learning Projects를 듣고 정리한 내용입니다. (Week 1)

 

이번 강의의 목표는 다음과 같다.

• Explain why Machine Learning strategy is important
• Apply satisficing and optimizing metrics to set up your goal for ML projects
• Choose a correct train/dev/test split of your dataset
• Define human-level performance
• Use human-level performance to define key priorities in ML projects
• Take the correct ML Strategic decision based on observations of performances and dataset

 

이번 강의를 통해서 머신러닝 프로젝트를 진행할 때, 어떻게 구성하고, 어떤 방식으로 전략을 세우고, 어떻게 진행해야하는 지에 대해서 알아 볼 것이다.

 

- Introduction to ML Strategy

우선 고양이인지 판별하는 분류기를 가지고 진행해보자. 

고양이 판별기 학습을 어느정도 진행한 후에, 우리가 대략 90퍼센트의 정확도를 갖는다고 했을 때, 성능이 그렇게 좋은 편은 아니라고 할 수 있다. 그렇다면 이 시스템의 성능을 개선하는 방법에 대해서 고민해보면 여러가지 아이디어가 떠오를 텐데, 예를 들면 다음과 같은 방법들을 사용할 수 있을 것이다.

딥러닝 학습 시스템을 개선할 때에는 위와 같이 시도할 수 있는 방법들이 많은데, 문제는 개선 방법을 잘못 선택하는 경우에 성능은 개선되지 않고 많은 시간을 허비할 수 있다는 것이다. 실제로 현업에서 6개월이라는 시간동안 데이터를 수집했지만, 성능이 거의 향상되지 않는 경우도 있다. 

이렇게 우리가 6개월이라는 시간을 낭비할 여유가 없다면, 프로젝트를 개선하는 수 많은 방법들 중에서 어떤 것을 선택해야되고, 선택하지 않아야 된다는 것을 알면 좋을 것이다.

이번 강의에서는 가장 시도할만한 방법을 선택할 수 있도록 방향성을 제시하는 머신러닝 분석방법에 대해서 다룰 것이고, 이 과정을 통해서 딥러닝 시스템을 조금 더 효율적으로 접근해서 구현할 수 있을 것이다.

 

[Orthogonalization 직교화]

머신러닝 시스템을 구현하는데 가장 큰 도전 중의 하나는 시도할 수 있는 방법과 바꿀 수 있는 것들이 너무나 많다는 것이다. 예를 들어, 튜닝할 수 있는 HyperParameter가 엄청 많다. 특히, 머신러닝 업무를 효율적으로 수행하는 사람들을 살펴보면, 하나의 효과(성능)을 얻기 위해서 무엇을 튜닝해야되는지 뚜렷한 안목을 가지고 있다. 

여기서 Orthogonalization(직교화)라는 용어가 나오는데, 예시를 통해서 무엇을 의미하는지 살펴보도록 하자.

위 그림처럼 오래된 TV가 있으면, 화면을 조절할 수 있는 여러 개의 손잡이가 있다. 1개의 손잡이로는 화면의 높이를 조절하고, 다른 손잡이 하나는 너비를 조절하고, 또 다른 손잡이는 사다리꼴 모양의 정도를 조절하고, 다른 손잡이는 화면 좌우 위치를 조절하고, 다른 하나는 화면의 회전 정도를 조절할 수 있을 것이다. 이렇게 각각의 손잡이가 하나의 옵션만을 튜닝한다.

반대로 특정 손잡이가 높이와 너비, 사다리꼴 정도를 일정 비율로 모두 튜닝한다고 해보자. 이러한 손잡이가 있다면 높이, 너비, 사다리꼴의 정도 등의 여러 변수들이 한번에 적용되어 한번에 바뀌게 되어서, 원하는 화면(가운데 위치한 사각형)으로 튜닝하기가 거의 불가능할 것이다. 

Orthogonalization은 이렇게 각각의 손잡이가 한 개의 기능만을 갖도록 디자인하는 것을 의미한다. 이런 경우에 TV화면을 튜닝하기 훨씬 쉽다.

 

다른 예시로 자동차가 있는데, 자동차의 기능에는 크게 Steering, Acceleration, Braking이 있다. 이 3가지의 조정을 통해서 컨트롤을 하게 되는데, 조이스틱 버튼 식으로 설계를 해서 특정 명령에 0.3x스티어링 각도, -0.8x속도 이런 식으로 조절이 된다고 생각해보자. 그리고 다른 버튼은 2x스티어링 각도, 0.9x속도를 조절한다고 하면, 스티어링과 속도를 별개로 조절하는 것보다 차를 조정하는 것이 훨씬 더 어려울 것이다. 

따라서, 일차원적으로 3개의 기능이 각각 따로 스티어링, 속도, 브레이크를 담당하는 것이 좋고, 자동차를 원하는 방향으로 조절하기가 더 수월해진다. 

 

이 내용들이 어떻게 머신러닝에 적용되는지 살펴보자.

머신러닝 시스템이 잘 수행되려면, 시스템의 손잡이를 튜닝해서 위의 4가지가 잘 유지되도록 해야한다.

 

첫 번째로, 적어도 Training Set에서는 시스템이 잘 동작하도록 해야 한다. 즉, Training set에서의 성능 레벨이 수용가능할 정도로 성능 레벨을 만족해야 하는데, 어느 어플은 사람 수준의 성능일 수도 있다. 기준 성능 레벨을 어느 시스템이냐에 따라 다를 것이고, 사람 레벨의 성능과 비교하는 것은 뒤에서 더 자세히 다루도록 하겠다.

 

이렇게 Training Set에서 잘 구현된 경우에, dev set에서도 잘 동작하도록 해야 하며, 그 이후에 test set에서도 잘 동작하도록 해야 한다. 마지막으로 이전 3가지가 모두 잘 동작해서, 실제로도 잘 동작하는 시스템이 되도록 해야 한다.

여기서 TV의 예시처럼 각각 다른 역할을 하는 5개의 손잡이를 한번에 조정하는 것은 바람직하지 않고, 한 개의 손잡이만을 튜닝하는 것이 좋다.

 

알고리즘이 Training set에서 Cost Function에 잘 맞지 않는다면, 이 때 사용할 수 있는 손잡이는 더 큰 네트워크를 사용하거나 더 나은 최적화 알고리즘인 Adam Optimization 알고리즘을 사용하는 방법이 있을 수도 있다.

 

다음으로 알고리즘이 dev set과 잘 맞지 않는다고 생각되면, 또 다른 손잡이가 사용될 수 있다. 즉, Training Set에서는 잘 동작하고 dev set에서는 잘 동작하지 않을 경우에는 Regularization 손잡이가 있을 수 있고, 더 많은 training set을 사용하는 것도 한 가지 방법이 될 수 있다.

 

만약 세번째 기준인 test set에 잘 맞지 않는다면 어떻게 될까? 이런 경우에는 더 큰 dev set을 사용해야할 것이다. dev set에서는 잘 동작하지만, test set에서는 잘 동작하지 않는다면, dev set에 overfit되어있을 확률이 높기 때문에 다시 이전 단계로 돌아가서 더 큰 dev set을 사용해야할 것이다.

 

마지막으로 test set에서는 잘 동작하지만, 실제로(학습되지 않은 새로운 데이터)는 잘 동작이 되지 않는다고 한다면, 다시 이전 단계로 돌아가서 dev set을 바꾸거나, Cost Function을 변경해야한다는 것으로 해석할 수 있다.

이 경우에는 dev/test set의 분포가 잘 설정되어 있지 않거나, Cost Function이 올바르게 계산되고 있지 않은 것으로 볼 수 있다.

자세한 내용은 이후에 다루어보도록 하겠다.

 

지금까지 시스템에서 중요한 4가지의 문제점과 이에 따른 튜닝 방법을 간략하게 언급했다.

NN을 학습시키는 경우에는 (교수님 개인의견으로는) early stopping은 잘 사용하지 않는다. 왜냐하면 너무 일찍 학습을 멈추게 된다면 training set에서 잘 동작하지 않을 수 있는데, 동시에 early stopping은 dev set 성능을 향상시키는데 사용되기 때문이다. 즉, 하나의 손잡이가 Orthogonalization하지 않아서 동시에 2개의 요소가 영향을 받기 때문이다. 

항상 나쁘다고는 할 수는 없고, 항상 사용하지 말라고 이야기하는 것은 어렵지만, 직교화한 튜닝이 가능하다면 튜닝 절차를 더 간편하게 할 수 있는 것은 사실이다.

 

이번 강의로 Orthogonalization에 대해서 알아보았는데, 머신러닝에서 본인의 시스템을 확인해서 어느 특정한 부분이 이상하다라고 판단할 수 있으면 굉장이 좋고, 어디에서 문제가 있고 구현이 잘 안되었다는 것을 판단하는 능력이 생기면 

아주 좋다. 하지만, 정확히 어떤 부분에서 문제가 있고, 어떤 해결 방법을 사용해야 문제가 해결되는 것을 찾기 어렵기 때문에 이런 부분에서 머신러닝 시스템의 성능에 한계를 보이고 있다. 다음으로는 진단법에 대해서 알아보도록 하자.

 

- Set up your goal

[Single number evaluation metric]

우리가 하이퍼파라미터를 튜닝하거나, 머신러닝 시스템을 만드는데 있어서 문제 해결을 위한 다른 방법을 찾는 경우에 Single number evaluation metric(실수 평가 측정 지표)가 있으면, 진행속도가 훨씬 더 빨라지는 것을 보게 될 것이다. 이러한 지표는 시도한 방법들이 더 잘 동작하는지, 잘 동작하지 않는지 알려준다. 그래서 보통 머신러닝 프로젝트를 시작할 때, 실수 평가 측정 지표를 사용하는 것을 권장한다.

 

강의에서 계속 이야기하지만, 머신러닝은 empirical process, 즉, 경험을 토대로 하는 절차이다. 어떠한 아이디어가 떠오르면 그것을 코드화하고, 실험을 통해서 결과를 얻고, 결과를 사용해서 아이디어를 보완/개선한다. 이러한 절차를 계속 반복해서 알고리즘을 계속 개선해나가는 것이다.

우리에게 Classifier A와 Classifier B가 있다고 해보자.

여기서 Precision과 Recall 항목이 있는데, 용어의 의미는 다음과 같다.

Precision : 정확도, 정밀도를 의미하고, True라고 판별한 것 중에서 실제 True인 것의 비율이다.

Recall : 검출율, 재현율이라고 하는데, 검출된 결과가 얼마나 정확한지, 즉, 검출된 결과들 중 실제로 실제로 일치하는 것이다. 실제 True인 것들 중에서 True라고 판별한 것의 비율을 의미한다.

 

위에서 Classifier A의 precision이 95%라면 고양이가 맞다고 올바르게 판별하는 확률이 95%라는 것이고, Recall이 90%라고 한다면, 실제로 고양이인 이미지들 중에서 90%를 올바로게 판별했다는 뜻이다. 해당 수치에 너무 목메일 필요는 없으며, 둘 다 신경쓸 수 밖에 없는 수치이므로 Trade-Off가 필요하다. 하지만, Classifier가 이미지의 대부분을 올바르게 판별하는 것을 원하기 때문에 Precision과 Recall을 기준으로 평가하는 것이 합리적이라고 볼 수 있다. 

하지만 위 표에서는 Precision은 B가 더 뛰어나지만, Recall은 A가 더 뛰어나기 때문에 어떤 Classifier가 더 좋은지 확인하기 어렵다. 여러가지의 Classifier로 시도해본다면, 테스트해보고 가장 좋은 것을 선택하면 되는데, 이렇게 두 가지의 평가지표로는 가장 좋은 한 가지를 선택하는 것이 어려울 수 있다.

 

그래서 추천하는 방법은 Precision과 Recall을 결합시킨 새로운 평가지표를 사용하는 것이다. 

머신러닝에서는 Precision과 Recall을 결합할 때, F1 score를 사용하는 것이 정석이다. F1 score는 각각을 P와 R로 나타낼 때, 이 값들의 평균 수치라고 생각하면 된다.(정확히는 harmonic mean 이다)

\[F_1\text{ score } = \frac{2}{\frac{1}{P} + \frac{1}{R}}\]

각 Classifier의 F1 Score를 구하면 아래와 같다.

이번 예시를 다시 살펴보면, Classifier A가 B보다 더 좋은 F1 Score를 갖는 것을 볼 수 있고, 결과적으로 Classifier A가 더 좋다고 볼 수 있다.

 

다른 예시를 살펴보자.

이번에는 고양이를 좋아하는 사람들을 위해서 4개의 대륙(미국, 중국, 인도, 그리고 나머지)에 고양이 판별기를 만든다고 한다. 그리고 2가지 Classifier가 있고, 각각 대륙별로 다른 값의 에러를 갖게 된다고 해보자.

이렇게 4개의 지표를 가지고는 A가 나은지, B가 나은지 결정하기가 쉽지 않다. 그리고, 더 많은 Classifier로 테스트하게 된다면, 이런 결과를 가지고 한가지 알고리즘을 선택하는 것은 너무 어렵다. 그래서 이번 예시를 통해서 추천하는 방법은 대륙별 에러로 평균을 계산하는 것이다. 

위와 같이 평균값을 산출함으로써, 알고리즘 C가 가장 낮은 평균의 에러 값을 가지고 있다는 것을 빠르게 확인할 수 있고, 우리는 알고리즘 C를 선택할 수 있을 것이다. 

 

이처럼 Evaluation Metric은 어떤 알고리즘이 더 좋은지 빠르게 판단한 수 있고, 프로세스를 반복해서 알고리즘을 개선하는데 속도를 높일 수 있다.

(single number evaluation metric은 single row evaluation metric이라고도 한다)

 

[Satisficing and Optimizing metric]

머신러닝을 평가할 때, 우리가 중요하게 여기는 부분들을 모두 고려하여서 single row evaluation metric으로 결합해서 나타내는 것은 결코 쉬운 일이 아니다. 이런 경우에는 satisficing과 optimizing이 유용할 수도 있다.

 

아까 고양이 판별기 예제를 가지고 다시 살펴보자.

우리가 중요하게 여기는 요소에 정확도가 있고, 추가적으로 실행 시간도 고려한다고 가정해보자.

이미지를 올바르게 판별하는 데, A는 80ms, B는 95ms, C는 1500ms의 시간이 걸린다. 

여기서 한 가지 사용할 수 있는 방법은 정확도와 실행시간을 결합시켜서 종합 평가 수치를 만드는 것이 있다.

예를 들어서, 정확도 - 0.5x실행시간으로 Cost를 계산해서 비교할 수 있지만, 약간 인위적인 것처럼 보인다. (두 가지를 선형 조합을 사용해서 결합)

 

다른 방법으로는 고려하고 있는 실행시간의 최대치를 만족하면서 정확도를 최대한으로 끌어올릴 수 있는 Classifier를 선택하는 방법이 있다. 

예를 들어서, 정확도는 높으면 높을수록 좋지만, 실행시간은 어느 정도 만족할만한 수치가 된다면 실행시간에 대해서는 더 이상 신경쓰지 않는 것이다. 즉, 실행시간의 최대치는 100ms이내로 설정하고, 이 수치를 만족하는 분류기 중에서 가장 정확도가 높은 것을 선택하는 것이다. 여기서 정확도는 optimizing metric이라고 하고, 실행시간은 satisficing metric이라고 한다.

이 방법을 사용한다면, 위의 예시에서 우리는 Classifier B가 가장 좋은 Classifier이라고 할 수 있다.

이렇게 optimizing and satisficing matrix를 정의하면서, 가장 좋은 classifier를 선택하는 명확한 방법을 제시할 수 있다.

 

일반적으로 N개의 고려해야되는 matrix가 있으면, 1개를 optimizing metric으로 선택하고, 나머지 N-1개를 satisficing으로 선택하는 것이 합리적이다.

 

다른 예시로 wake words를 감지하는 시스템을 만든다고 가정해보자.

trigger word라고도 표현하는데, 애플의 경우에는 hey, siri라고 말해서 음성인식기기를 깨우고, 구글의 경우에는 okay, google이라고 말해서 기기를 깨운다.

어떤 사람이 이런 trigger word를 말하는 경우에 음성인식기기를 깨울 확률이 얼마나 될 지 신경쓸 수 있고, 또한, 잘못 깨는 비율도 신경쓸 수 있다(아무도 trigger word를 사용하지 않았는 경우에는 무작위로 갑자기 기기가 인식하는 경우가 얼마나 자주 발생하는가).

이런 경우에는 정확도를 최대치로 하고, 만약 특정 trigger word를 말할 경우에 음성인식기기가 깨어날 확률을 최대치로 끌어올리고, 이러한 결과를 토대로 24시간 이내에 1번 이내의 잘못된 인식만을 허용하도록 하는 방법이 있다.

 

요약하자면, 고려하는 요소가 여러가지 있다면, 가장 좋은 결과를 얻고 싶은 한가지 조건을 optimizing metric으로 설정하고, 나머지는 satisficing metric을 통해서 만족할만한 수치의 범위를 설정한다. 각각의 특정 한계치를 일일히 찾는 것보다 항상 잘 구현되고, 빠른 속도로 여러 개의 알고리즘 중 가장 좋은 것을 선택할 수 있을 것이다. 

 

[Train/dev/test distributions]

이번에는 training/dev/test set을 어떻게 설정하는지에 대해서 알아볼 것이다. 어떻게 data set을 설정하는 것은 중요하고, 어떻게 설정하는지에 따라서 머신러닝 프로젝트를 얼마나 빠르게 진행할 수 있는지에 큰 영향을 끼친다. 

먼저 dev/test set을 설정하는 방법에 대해서 알아보도록 하자. 여기서 dev set은 development set 또는 cross-validation set 이라고 불리기도 한다.

 

일반적으로 머신러닝 업무의 진행절차는 다양한 아이디어를 시도하고, 코드화해서 결과를 평가해보고 그 중에 가장 잘 구현이 된 것을 선택한다. 이런 과정을 반복해서 지속적으로 개선하고 dev set의 성능을 개선해나가면서 마지막으로 한가지를 선택하고, test set으로 평가해보는 것이다. 

이번에도 고양이 판별기 예시를 가지고 살펴보도록 하자. 

US, UK, Other Europe, South America, India, China, Other Asia, Australia에서 고양이 판별기를 운영하고 있다고 한다면, 우리는 dev set과 test set을 어떻게 설정해야 될까?

한가지 방법으로는 언급한 대륙 중에서 4가지를 고를 수 있다. 이 4가지 대륙은 무작위로 선별된 대륙일 수도 있다. 나머지 4개의 대륙은 test set이 될 것이다. 하지만, 이렇게 dev set과 test set을 설정하는 것은 dev set과 test set이 모두 다른 분포도를 갖고 있기 때문에 아주 좋지 않은 방법이다. 

그렇기 때문에, dev set과 test set을 설정할 때에는 같은 분포도를 가지는 데이터에서 설정하는 것을 권장한다.

만약 dev set과 test set이 다른 분포도를 갖는다면, dev set에서 얻은 데이터의 정보가 test set과 많이 다를 수 있다.

 

[Size of the dev and test sets]

이번에는 dev set과 test set의 크기를 어떻게 설정해야 하는지에 대해서 알아보도록 할 것이다.

dev set과 test set을 설정하는 가이드라인은 계속해서 변화되어가고 있는데, 머신러닝 초기에는 가지고 있는 데이터를 모두 사용해서 training set과 test set을 70:30의 비율도 나누는 방법을 사용하였다. 만약 dev/test set이 모두 필요하다면, training:dev:test set의 비율을 60:20:20으로 사용했다. 머신러닝 초기에는 이러한 방법이 합리적이었는데, data set의 크기가 그리 크지 않았기 때문이다. 100개, 1000개, 또는 10000개의 예제가 있을 때에는 경험에 의해서 이런 방법이 합리적이었을 것이다. 

하지만, 최근 머신러닝, 딥러닝에서는 훨씬 더 큰 data set을 사용하고 있다. 그러므로 만약 백만개의 data sample이 있다고 가정해보자. 이런 경우에는 training set을 98%로, dev와 test set을 각각 1%로 분배하는 것이 합리적일 수 있다. 백만개에서 1%는 10000개이므로, 이 정도의 크기는 dev/test set으로는 충분한 양이기 때문이다. 

 

Test set의 목적은 시스템의 개발이 완료된 후에, 마지막에 시스템이 얼마나 좋은 성능을 가지고 있는지 평가하는데 도움을 준다. 그렇기 때문에 마지막에 시스템이 얼마나 잘 동작하는지에 대해서 자세히 알아야하는 것이 아니거나, 전방적인 성능에 대해서 높은 신뢰수준이 필요하지 않다면, test set없이 training set과 dev set으로만 분배할 수도 있다. 

하지만, 시스템을 구축할 때, test set을 설정하지 않는 것은 절대 추천하지는 않는다.

 

이처럼 빅데이터 시대에 들어서면서, 경험에 의거해서 이전에 사용하던 70:30의 비율은 더 이상 적용되지 않는 것 같고, 트레이닝에 더 많은 데이터를 사용하고, dev/test에는 더 적은 데이터를 사용하는 트렌드가 있다. dev와 test set의 크기는 목적에 맞는 크기로 설정을 하면 되고, 이러한 가이드라인으로 dev set과 test set을 설정하면 될 것이다.

 

[When to change dev/test sets and metrics]

dev set을 설정하고, evaluation metric을 설정하는 것은 시스템을 구축하는데 목표를 이룰 수 있도록 방향성을 제시해주는 것과 같다. 하지만 프로젝트를 진행하는 도중에 이러한 설정이 잘못되어서 잘못된 방향으로 가고 있다는 것을 뒤늦게 깨닫는 경우도 있다. 이러한 경우에는 목표를 이동해야하고 결국 dev set이나, evaluation metric을 다시 설정해야 한다.

예시를 통해서 살펴보도록 하자.

고양이 분류기 프로그램을 만든다고 했을 때, metric은 classification error를 사용한다고 하자. 알고리즘 A와 B는 각각 3%, 5%의 error를 가지고 있고, 겉으로 보기에는 알고리즘 A가 더 성능이 좋다고 평가할 수 있다. 

하지만, 실제로 동작했을 때, 어떤 이유에서인지 알고리즘 A가 부적절한 이미지를 더 많이 허용하고 있는 것을 볼 수 있었다. 이런 상황에서 알고리즘 A를 사용하면 유저들은 더 많은 고양이 사진을 3%의 낮은 error로 볼 수 있지만, 동시에, 부적절한 이미지를 보게될 수도 있다. 반대로, 알고리즘 B는 5%의 error를 가지고 있기는 하지만, 부적절한 이미지를 허용하지는 않는다. 이렇게 되면 기업과 유저 입장에서는 알고리즘 B가 더 훌륭한 알고리즘이라고 볼 수 있다. 

 

위와 같은 예시에서는 dev set + evaluation metric으로는 알고리즘 A를 더 선호한다. 그 이유는 알고리즘 A가 error 수치가 더 낮기 때문이다. 그러나 유저나 기업은 부적절한 이미지를 허용하지 않는 알고리즘 B를 더 선호할 것이다. 

이런 경우가 발생한다면, evaluation metric이 더이상 올바르게 알고리즘을 평가할 수 없고, metric을 변경하거나 dev/test set을 바꾸어야 한다.

 

우선 기존 classification error는 아래와 같이 산출해낼 수 있다.

위 식에서 sum기호 다음 부분은 실제 y와 일치하지 않는 예측의 개수를 count한 것이다. 이런 식은 부적절한 이미지를 일반 이미지(고양이 이미지가 아닌 이미지)를 동일한 것으로 간주하기 때문에, 제대로 평가되지 않을 것이다.

위 식을 보완하기 위해서 우리는 아래와 같이 \(w_i\)를 추가할 수 있다.

즉, 가중치를 추가하는 것인데, 이미지가 부적절한 이미지라면 10이라는 가중치(weight)를 주는 것이다. weight는 부적절한 이미지를 dev/dest set을 거쳐서 레이블하여서 도입할 수 있다. 

그리고 여기서 normalization을 위해서 \(m_{dev}\)가 아닌 \(\sum_{i}w^{(i)}\)로 나누어 주었다.

 

이처럼 metric이 더이상 원하는 순서로 선호도를 평가하지 않는다면 새로운 evaluation metric 도입을 고려해야 한다.

이 경우에 Orthogonalization을 적용할 수 있는데, 

첫 번째로는 분류기를 평가하기 위한 metric을 정의하는 데에 집중을 하고, 이후에 어떻게 metric을 잘 구현하는 지에 대해서 고민하는 것이다. 즉, target을 plan하는 것과 tuning 단계를 분리해서 생각하는 것이다.

 

- Comparing to human-level performance

[Why human-level perfomance ?]

딥러닝이 발전되면서, 머신러닝 알고리즘이 더욱 좋은 성능을 가지게 되고, 인간레벨의 성능과 비교했을 때, 이것과 견줄만할 정도로 머신러닝의 알고리즘의 성능이 입증되고 있다. 또한, 인간이 할 수 있는 업무 영역에서 머신러닝 시스템을 디자인하고 수행하는 과정이 이전과 비교해서 많이 효율적으로 발전했다. 

 

시간이 지나면서 머신러닝 프로젝트의 진전은 다음과 같은 경향을 가지고 있다.

프로젝트의 성능은 인간레벨의 성능까지는 빠른 속도로 향상하는 경향이 있는데, 인간레벨의 성능을 뛰어넘으면서 진행속도나 정확도의 향상이 정체되기 시작한다. 물론 능숙도는 증가할 수도 있지만, 인간레벨의 성능을 능가하면서 지속적으로 성능이 더 좋아질 수는 있지만, 보통 속도는 더뎌진다.

알고리즘을 계속 학습시키면서 시간이 지나면, 더 큰 네트워크 모델이나, 더 많은 데이터를 수집해서 성능은 이론적 한계를 향해서 향상되지만, 절대로 한계에 도달을 하지는 못한다. 이 한계를 Bayes optimal error라고 하며, Bayes optimal error를 가장 좋은 성능의 error라고 생각하면 된다.

 

음식인식기기를 예시로 들면, 어떤 오디오는 너무 시끄러워서 어떤 내용인지 판단이 불가능할 수도 있다. 이런 경우에는 perfect accuracy가 100%가 아닐 수 있다. 고양이 판별기에서는 이미지가 너무 흐릿해서 이미지가 고양이 사진인지 자체를 전혀 인식할 수 없을 수도 있다. 마찬가지로 perfect accruracy level이 100%가 아닐 수 있고, 최소한의 error가 있을 수 있는데, 이 error를 Bayes optimal error 또는 Bayesian opimal error, 줄여서 Bayes error라고 한다. 이 값이 이론적으로 최소한의 error이며, 머신러닝 시스템은 이 값을 절대로 능가할 수는 없다.

그렇기 때문에, 위 그래프에서 보라색 선은 긴 시간이 지나도 Bayes error에 도달할 수 없는 것이다.

 

아까 언급했듯이, 인간레벨의 성능을 도달한 이후로 느려지기도 하는데, 첫 번째로 인간레벨 성능을 이미 능가한 시점에서는 더 발전할 수 있는 부분이 상당히 제한적이기도 하고, 두 번째로는 여러 가지 도구를 사용해서 성능을 향상시킬 수 있는데, 이런 도구들은 인간레벨 성능을 초과한 시점에서는 사용하기가 어렵다. 

 

ML이 인간레벨의 성능에 미치지 못한다면, 아래와 같은 방법을 사용할 수 있다.

 

[Avoidable bias]

우리가 알고리즘을 학습할 때, training set에서 잘 수행되기를 바라지만, 가끔은 너무 잘 수행되는 것이 별로 좋지 않을 수 있다. 이때, 인간레벨의 성능이 어느 정도인지 알면, 적당한 수준으로 알고리즘이 training set에서 성능을 발휘할 수 있도록 가능하게 한다. 

고양이 판별기 예시를 가지고 살펴보도록 하자.

위와 같이 8%의 training error, 10%의 dev error, 그리고 완벽에 가까운 정확도를 가지고 있는 Human error는 1%라고 해보자. 이런 경우에는 training set에서의 성능과 인간의 차이가 매우 크기 때문에, 해당 알고리즘이 training set에 잘 fitting되지 않고 있음을 보여주고 있다. 따라서, bais와 variance의 관점에서, bias를 줄이는데 중점을 둘 수 있을 것이다. 더 큰 NN 네트워크를 사용하거나, 더 긴 시간동안 학습하는 방법이 있을 수 있다. 

 

다음으로는 training/dev error는 그대로고, humans error가 7.5%인 경우(이미지가 너무 흐리거나, 화질이 좋지 않아서)를 살펴보자. 이 경우에는 training set에서 인간레벨의 성능보다 조금 못미치는 성능으로 좋은 성능을 발휘하고 있다고 볼 수 있다. 그래서 이런 경우에는 training error와 dev error의 차이, 즉, variance를 줄이는 방향으로 개선할 수 있으며, Regularization을 사용할 수 있을 것이다. 

 

여기서 humans error는 bayes error라고도 볼 수 있고, 컴퓨터의 vision 영역에서는 꽤 합리적인 수치일 수 있다. 사람은 computer vision 영역에서 굉장히 능숙하고, 사람이 할 수 있는 부분이 bayes error와 크게 다르지 않기 때문이다. human error를 정의만 가지고 살펴봤을 때는 bayes error를 절대로 능가할 수는 없지만, bayes error에서 크게 뒤떨어지지는 않을 수 있다.

 

위 두 예시에서 살펴보듯이, 인간레벨의 성능이 얼마인지에 따라(또는 bayes error에 따라), 같은 training/dev error에서 각각 다른 방법을 사용하고 있다.

첫 번째 예시에서는 8%의 training error를 1%까지 줄일 수 있다면, 이건 굉장한 성능의 개선이라고 볼 수 있고, 따라서 bias를 줄이는 방법에 중점을 둔다.

두 번째 예시는 bayes error가 7.5%이기 때문에 training error를 줄이기 힘들고, 7.5%보다 낮아지기를 원하지도 않는다. 따라서, bayes error와 가깝도록 개선하는 방법보다 training error와 dev error의 차이인 2%를 줄이는 방법에 중점을 두는 것이 더 유용할 것이다.

 

여기서 Bayes error(or Bayes error의 근사치)와 training error의 차이를 avoidable bias라고 부른다. 우리는 training error를 bayes error와 가까워지도록 개선하는 것이 목표이며, overfitting 하지 않는 이상 bayes error보다는 낮아질 수 없다.

이 용어는 최소한의 error가 있다는 것을 의미하고, bayes error가 7.5%인 경우에는 이 error 수치 이하로는 개선될 수 없다는 것을 내포하기도 한다. 특히, 두번째 예시에서 avoidable bias는 0.5%이고, training과 dev error의 차이는 2%이기 때문에, 2%를 더 줄이는 것이 더욱 큰 효과를 얻을 수 있다.

 

[Understanding human-level performance]

인간레벨 수준의 성능(human-level performance)은 논문이나 기사에서 자주 쓰이는 단어인데, human-level performance의 정의를 살펴보도록 하자. 

이전 내용에서 살펴봤듯이, human-level error는 bayes error를 추정하는 방법이 될 수 있다. 그렇다면 이 값은 어떻게 결정되는 걸까? 이점을 유의하면서, medical image classification 예시를 통해서 살펴보도록 하자.

위 사진의 오른쪽편에 있는 방사선 사진을 살펴보고 분류하는 일을 담당했다고 했을 때, 전형적인 보통 사람은 3%의 error를 가진다. 그리고 일반적인 의사는 1%의 error, 경험이 많은 의사는 0.7%의 error를 가지고, 경험이 많은 의사들로 구성된 팀은 0.5%의 error를 가진다고 한다. 이런 경우에 인간레벨의 error는 어떻게 정의할 수 있을까?

이 질문에 답하기 위해서 한 가지 접근 방법은 error의 추정치를 bayes error로 접근하는 것이다. Bayes error의 추정값을 원하는 경우에는 경험이 많은 의사들의 팀이 0.5%의 error를 가지고 있기 때문에, bayes error는 0.5%이거나 0.5% 이하일 것이다. 이런 팀들이 0.5%의 error를 일으킬 수 있기 때문에, 최적의 error는 0.5%이거나 낮다고 할 수 있는 것이다.

물론, 경험이 많은 의사 팀의 규모가 더 커서 0.5%보다 낮을 수도 있지만, optimal error는 0.5%보다 낮을 수 없고, 이런 상황에서 (교수님의 의견으로는) 0.5%를 bayes error의 추정치로 지정할 것이다. 이런 방법으로 0.5%를 human-level performance로 정의한다. 

 

논문이나 시스템 도입이 목적인 경우에는 사용할 수 있는 human-level performance가 다르게 정의될 수 있고, 아마 일반적인 의사의 능력 이상만 되어도 될 것이다. 성공한다면 굉장이 유용하고, 의사 개인의 역량을 뛰어넘은 시스템이라고 한다면, 실제로 도입이 가능할 수 있는 시스템이 되기 때문이다.

 

그래서 이번 강의에서 주목할 내용은 어떤 목적으로 human-level error를 정의할 것인지 정확하게 설정하는 것이다. 

 

다른 예시를 살펴보자.

여기 3가지의 예시가 있는데, 첫번째 예시부터 살펴보도록 하겠다.

training error가 5%이고, dev error가 6%이고, human level error가 누구냐에 따라서 1%, 0.7%, 0.5%의 값을 가진다고 하자. 이번 예시에서는 human-level performance를 어떻게 정의하는지는 크게 중요하지 않을 것이다. 어떤 값으로 지정해도 avoidable bias는 4% ~ 4.5%의 값을 가지고, training error와 dev error의 차이는 1%의 값을 가진다. 따라서 이 예시에서는 bais를 줄이는 방법에 중점을 두어야 한다.

 

두번째 예시는 인간레벨의 성능이 1%, 0.7%, 0.5%이고, training error가 1%, dev error가 5%이다. 이번에도 어떤 값을 human-level error로 설정하는 지 중요하지 않아보이고, avoidable bias가 0% ~ 0.5%의 값을 가지고, 반면에 training error와 dev error는 4%의 값을 가진다. 따라서 이 예시에서는 variance를 줄이는 방법을 권장할 것이다.

 

중요한 것은 마지막 예시인데, 이 예시에서는 training error가 0.7%이고 dev error가 0.8%인 경우이다. 이런 경우에는 bayes error(human-level error)가 0.5%가 되도록 지정하는 것이 중요하다. 이 경우에는 avoidable error가 0.2%이고, bias를 줄이는 것에 조금 더 중점을 둘 수 있다.

만약 0.7%를 bayes error의 추정치로 한다면, avoidable error는 0%가 되고 variance를 줄이는 방법에 중점을 둘 수 있다.

 

여기서 머신러닝에서 인간레벨의 성능에 도달해가는 시점에서 더 개선하기가 왜 어려운지를 알려준다. 마지막 예시에서 0.7%의 training error에 도달했을 때, bayes error를 정의하는 것에 굉장이 신경쓰지 않는다면, training error가 bayes error에서 얼마나 차이가 있는지 알기는 어려울 것이고, 따라서 우리가 avoidable bias를 얼마나 줄여야 할지도 모른다. 추가로, 머신러닝의 성능이 이미 꽤 괜찮은 상황에서 발생했기 때문에 training set를 fitting하기에 매우 까다롭다.

반면에, 첫번째와 두번째의 예시는 training error가 human-level performance와 차이가 많이나는 상황이기 때문에, bias와 variance에 집중하기에 쉽다. 

 

위의 예시들로부터 알 수 있듯이, 인간레벨의 성능과 가까이 있는 경우에는 bias와 variance 효과를 제거하기 더 어렵고, 결과적으로 인간레벨의 성능에 가까워질수록 개선하기가 더욱 어려워지는 것이다.

 

이전 강의에서는 training error를 계산하고, 0보다 얼마나 큰지 비교했었고, bayes error가 0에 가까운 경우를 살펴보았지만(고양이 판별기 같은 경우, 인간이 거의 완벽하게 분류하기 때문에 bayes error도 거의 완벽하다고 볼수 있음), 음성인식기기에서 오디오가 시끄러운 경우에는 음성은 인식하기 어려운 경우가 있고, 이런 문제에서는 bayes error가 0이 아니다. 이런 문제의 경우에는 bayes error의 추정치를 더 정확하게 알면, avoidable bias와 variance를 더 정확히 추정할 수 있게 되고, 어디에 중점을 둘 것인지 결정을 내릴 수 있을 것이다.

 

[Surpassing human-level performance]

이전 강의에서 이야기했듯이, 인간레벨의 성능을 능가한 시점에서는 머신러닝을 개선하기에 매우 어렵다. 구체적으로 왜 어려운지 살펴보도록 하자. 

위와 같은 경우에는 avoidable bias는 어떻게 될까? 이런 경우에는 0.5%가 bayes error의 추정치가 될 것이고, avoidable bias는 0.1%이고, variance는 0.2%정도로 추정하게 될 것이다. 이런 결과로 avoidable bias나 variance를 줄일 수 있는 방법을 선택할 수 있다. 

 

조금 더 어려운 예시를 살펴보도록 하자.

이번에는 training error가 0.3%이고, dev error가 0.4%라고 한다면 avoidable bias는 어떻게 될까? training error가 0.3%라는 것이 overfitting을 의미하는 것일까? 아니면 bayes error가 0.1 or 0.2 or 0.3%일 수도 있다. 

즉, 정확히 알 수가 없다. 정보가 충분하지 않기 때문에, 알고리즘에서 bias를 줄이는데 중점을 두어야할지, variance를 줄이는데 중점을 두어야할지 애매하다. 이렇게 된다면 효율적인 진행이 어려워진다.

 

이번 예시는 training error가 human-level performance를 능가했을 때, 머신러닝을 진행하고 개선하는 방법이 명확하지 않다. 그렇다고, 개선할 수 없는 것은 아니고, 정확한 방향성을 제시해줄 수 있는 도구들이 제한적일 수 있는 의미이다. 

이미 많은 분야에서 인간레벨의 성능을 능가하는 부분이 많다.

 

[Improving your model performance]

앞선 강의들을 종합해서, 학습 알고리즘의 성능을 향상시키는 방법에 대해서 정리해보도록 하자. 

우선, 학습 알고리즘의 성능이 효과가 있기 위해서는 2가지의 전제조건이 필요하다고 생각한다.

첫 번째로는 training set에 잘 fitting되어야 한다는 것이고, 이것은 낮은 avoidable bias를 갖는다는 것과 동일한 의미이다. 두 번째로는 dev/test set에서도 잘 fitting되어야 한다는 것이고, variance가 나쁘지 않다는 것을 의미한다. 

 

즉, 머신러닝의 성능을 향상시키고자 한다면, training error와 bayes error의 차이를 보고, avoidable bias문제를 살펴보고(training set가 얼마나 잘 fitting하는지), 그 이후에 dev error와 training error의 차이를 살펴보면 된다.

avoidable bias를 줄이는 방법으로는 더 큰 모델을 학습시키거나, 더 긴 시간을 가지고 학습하거나, 더욱 향상된 최적화 알고리즘(Momentum, RMSProp, Adam)을 사용하는 방법이 있다. 또 다른 방법으로는 더 좋은 구조를 사용하는 것인데, 더 좋은 hyperparameter를 사용하거나, activation function의 선택 및 layer의 개수, hidden unit의 개수를 바꾸는 방법이 있을 수 있다.

variance가 문제라면, 더 많은 data를 수집하거나, regularization을 시도해볼 수 있다. 그리고 avoidable bias와 동일하게 NN의 구조를 변경할 수 있고, hyperparameter를 변경해서 개선할 수도 있다.