1. Introduction to ML Strategy
: NN의 성능을 올리기 위해서 시도해 볼 아이디어는 무척이나 많다. 더 많은 데이터 모으기, 더 다양한 학습셋 모으기, 더 오래 학습하기, 더 좋은 optimizer 사용하기, 더 큰/작은 네트워크 설계하기, dropout 사용하기, regularization, network architecture 바꾸기 등등등..
우리는 이러한 많은 시도들을 해볼 수 있는데 이때 중요한 개념이 orthogonalization이다.
(1) Orthogonalization
: 각각의 Idea가 하나의 문제만 해결하도록 설계하는 것.
예를 들어, 자동차 핸들에는 방향 조절 기능만 넣어놓는 것이 우리가 다루기가 편하다. 하지만 핸들에 '0.5 * 방향조절 + 0.3 * 속도 증가 + 0.2 * 속도 감속'과 같이 여러 기능이 섞여있다면, 우리는 핸들 조작에 직관성도 떨어지고, 다루기 매우 어려울 것이다.
NN를 조정할 때도 이와 유사하게 동작하는 것이 좋다는 의미이다.
- Cost function에 대해 training set을 fitting 한다. (이때 기준은 human-level performance와 유사할 때까지)
*human-level performance는 뒤에서 다룬다.
잘 안 됐을 때: Bigger network 사용, Adam 사용 등등의 해결책이 있을 수 있다. - Cost function에 대해 dev set을 fitting 한다.
잘 안된다면: Regularization 사용, Bigger train set 사용 등의 해결책 사용 - Cost function에 대해 test set을 fitting 한다.
잘 안된다면: Bigger dev set 사용 - Real world에서 잘 수행하는지 확인
잘 안된다면: dev set이나 cost function을 바꾼다. (dev set distribution이나 cost function이 우리가 원하는 방향과 다르게 설계되었을 가능성 높음)
1과 2를 동시에 해결할 수 있는 방법으로 early stopping이 있으나, (물론 효과적이다) othogonalization 하기 어려움으로 Ng 교수님은 선호하지 않는다고 하신다.
2. Setting Up your Goal
: Evaluation metric에 대해서 다룬다.
(1) Single Number Evaluation Metric
: dev set을 평가하기 위한 하나의 evaluation metric을 선정하면, 우리의 개발 속도를 speed up 할 수 있다.
예를 들어, Precision과 Recall에 대한 점수만 있을 때 A와 B 중에 어떤 것이 더 나은 classifier인지 알기 어렵다.
| Classifier | Precision | Recall | F1 score |
| A | 95% | 90% | 92.4% |
| B | 98% | 85% | 91.0% |
이때, F1 score를 evaluation metric으로 선정하면 A가 B보다 더 나은 것을 알 수 있다.
(2) Satisficing and optimizing metrics
- Optimizing metrics: 가장 좋은 결과가 났으면 하는 것
- Satisficing metrics: 어느 정도 이상의 성능이면 충분한 것 (특정 기준을 충족하는 이상 그 범위 안에 속하면, 신경 쓰지 않음)
(3) Dataset을 잘 구성하는 방법
- 미래에 얻을 것으로 예상되는 데이터를 반영하기 위해, dev set와 test set를 선택하고, 이를 잘 수행하기 위해 중요하게 고려합니다.
- Dev set과 test set은 same distribution으로부터 나오는 것이 제일 좋다.
- Train/dev/test set의 크기: ML 초기에는 70/30 혹은 60/20/20으로 나누는 것이 보편적이었다. 하지만, 빅데이터 시대에는 data가 워낙 많기 때문에 dev set은 개발자가 수행하는 algorithm이나 model의 차이를 detect 할 수 있을 정도로 크면 된다. 그리고 test set은 개발자의 system의 전반적인 performance에서 high confidence를 줄 만큼 크면 된다.
(4) 언제 dev/test set과 evaluation metrics를 바꿔야 할까?
- metric + dev/test set에서는 잘 동작했는데, real application에서 잘 동작하지 않을 때, metric이나 dev/test set을 바꿔야 한다.
3. Comparing to Human-level Performance
: 인간은 이미 많은 task들 (고양이 분류 등)에서 잘하고 있다. 따라서 human-level performance와 알고리즘의 성능을 비교하는 것은 어찌 보면 당연하다.
- Bayes Optimal Error: 이론적으로 model이 가질 수 있는 가장 최상의 오류 (x->y mapping을 이론적으로 가장 정확하게 나타내는 function)을 의미한다. 하지만 NN는 결코 이 값을 넘을 수 없다.
- NN는 human-level performance에 도달하기까지는 상대적으로 빠르게 성능이 증가하다가, human-level을 넘는 지점부터는 성능 향상 속도가 매우 더뎌진다. 그 이유는 다음과 같다:
- 많은 task에서 human-level performance는 bayes optimal error와 멀리 떨어져 있지 않기 때문이다.
- human-level에 미치지 못한 경우, 여러 가지 tool을 이용해 성능을 개선할 수 있지만, huma-level을 넘긴 뒤에는 이러한 tool을 이용할 수 없기 때문이다.
Human-level performance까지 미치지 못했을 때 사용할 수 있는 tool은 다음과 같다.
- Human으로부터 labeled data를 얻는다.
- Manual error analysis를 통해, 인간은 맞고 알고리즘은 왜 틀렸는지에 대한 insight를 얻는다.
- bias/variance에 대해 분석한다. (인간이 어떤 작업을 얼마나 잘할 수 있는지 알면, bias와 variance를 얼마나 줄여야 하는지 더 쉽게 이해할 수 있다.)
이러한 과정을 통해 ML 알고리즘이 인간이 잘하는 업무를 능숙히 복제할 수 있고, 그 과정에서 human-level performance를 따라잡을 수 있다.
(1) Avoidable bias
: Human-level performance를 알면, 이에 따라 algorithm의 train error가 얼마나 되어야하는지에 대해 알 수 있다.
인간은 대부분의 task에 대해서 뛰어난 performance를 보여주기 때문에, 우리는 human-level performance를 proxy for bayse error, 즉 bayes optimal error의 추정치로써 사용할 수 있다.
| task | task1 | task2 |
| Human (~proxy for bayes error) | 1% | 7.5% |
| Training error | 8% | 8% |
| Dev error | 10% | 10% |
| 전략 | Focous on bias | Focus on variance |
task 1과 2 모두 같은 train/dev error를 갖고 있지만, human-level performance에 따라 어느 부분에 집중할지 전략이 달라진다.
Avoidable bias: human error와 training error 사이의 차이
task1의 경우, 알고리즘이 training set에 잘 fitting되고 있지 않으므로 avoidable bias를 줄이는 데 집중해야한다.
task2의 경우, dev set에 대해 generalization이 잘 안되고 있으므로 variance를 줄이는데 집중해야한다.
(2) Human-level performance 설정 방법
: 그렇다면, 이제 기준으로 삼을 human-level performance를 어떻게 설정하는지가 중요해진다. 예시를 들면 다음과 같다.
- 어떤 분야에서 특정 인간의 역량을 능가해, 시스템을 도입하는 경우라면 one human (전문가) 의 성능을 기준으로 하는 것이 좋다.
- 하지만, bayse error에 대한 proxy 만큼 성능 향상을 원하는 것이라면, 여러 전문가가 논의해서 결정을 내렸을 때의 성능을 기준으로 하는 것이 좋다.
결론: human-level performance를 정확히 알면, avoidable bias와 variance를 좀 더 정확하게 추정 가능하고, 어디에 집중해야할 지 보다 적절한 결정을 내릴 수 있다.
*따라서 human-level performance를 이미 띄어넘은 ML task의 경우, 모델의 성능을 향상시키기 어렵다. (proxy for bayse error를 구하기 어렵기때문에, 명확한 의사결정을 내리는데 어려움 --> 어떻게 model을 발전시킬지 선택지 (bias 개선할지/variance 개선할지) 가 명확하지 않다.)
(3) Improving your model performance
: 지금까지 배운 결론을 종합해서 모델 성능을 향상시켜보자
- Supervised learning의 2가지 fundamental assumption
- You can fit the training set pretty well (means low avoidable bias)
- The training set performance generalizes pretty well to the dev/test set (means low variance)
이 두 가지를 orthogonalization해서 각각 잘 해결할 수 있어야한다.
| Avoidable bias | 1. Train bigger model 2. Train longer 3. Better optimization algorithms (e.g., momentum, RMS prop, Adam) 4. NN architecture / hyperparameters search |
| Variance | 1. More data 2. Regularization (L2, dropout, data augmentation) 3. |
bias/variance를 줄이기 위한 자세한 설명은 여기 참조!