실제 머신 러닝을 구현해야 할 때는 현실적인 고민들에 빠지게 된다. 결론적으로, 모델에 대한 가정과 hyperparameter 이해 없이 적용하는 것은 의미가 없다. 다시 말하면, 디폴트 상태로 동작시킨다면 안 하는 것만큼 못하다는 이야기다.
• 실무자들이 알아야 할 사항들... - 특정 애플리케이션에 대한 알고리즘은 어떻게 선택할까? - 시스템을 개선하기 위해 실험에서 얻은 피드백 (monitor and respond) 방법은 무엇일까? • 아래에 대한 사항들... 데이터를 더 수집해야 할지 아닌지? 모델의 캐퍼시티를 늘려야 할지 줄여야 할지? 정규화 특성을 추가해야 할지 삭제해야 할지? 모델 최적화 개선을 해야 할지? 모델의 근삿값 추론을 개선해야 할지? 또는 디버그 과정은 어떻게 할지? 등
• 가정을 이해하지 않고 맹목적으로 알고리즘을 데이터 셋에 적용하는 것은, 정확한 모델에 도달하기 어렵다. • 모호한 알고리즘을 엉성하게 적용하는 것보다, 일반적으로 잘 알려진 알고리즘이 훨씬 더 잘 작동한다.
Practical Methodology : 실용적인 방법론
현실에서는 시스템 구축 후에도 여러 가지 문제에 직면하게 된다. 이론상 잘 작동하더라도, 현실 데이터는 지속적으로 변하기 때문에 업데이트되지 못한 부분들이 생길 것이고, 그때 발생될 금전적 손실도 무시할 수 없다. 따라서, 시스템 설계 시 성능을 간접적으로 검증할 수 있는 지표들을 선정하고 확인해나가야 한다.
Practical Process 1. Determine your goals : 목표 결정 2. Build an end-to-end system : 종단 간 시스템 구현 3. Refine the system : 시스템 개선
- 머신 러닝 시스템 설계
단계적으로 머신 러닝 시스템을 설계하도록 한다.
Step 1: 목표 결정하기 : Performance Metrics 1) 최종 목표를 유지: 어디에 적용될 것인가 -. 과업(Task), 데이터(Data), 요구사항(Requirements), 성능평가지표(Performance Metrics)를 명확하게 나눈다. -. 대부분의 현실 문제(Business metric) 목표는 머신 러닝 목표와 1:1 Mapping 이 힘들다. -. 최대한 비즈니스 지표를 표현할 수 있는 방식으로 성능 평가가 이루어져야 한다. 2) 간접적인 평가지표 선정: 충분한 검증 및 성능 평가 -. (binary) classification: 분류 문제일 경우, 단순 Accuracy 값이나 Error Rate 값이 성능의 전부가 아니다. Class Imbalance (클래스 불균형) : 치우침을 해석하기 위해 Precision, Recall, F₁ Score, Sensitivity, Sepcificity 값도 비교해 보아야 한다. Threshold (경곗값) : 가령, 0~1 사이의 확률이라고 한다면 분류 기준을 default 0.5 값이 아닌, 상황에 따라 조정이 필요하다. Receiver Operating Characteristic (ROC Curve) : 모든 상황을 고려해서 AUC 넓이가 넓게 나오도록 민감도, 특이도를 모두 따져본다. -. regression: 회귀 문제는 오류 함수를 선택할 때 예측 대상의 스케일을 보고 적절한 것을 선택한다. Interval Scale (간격) : 온도와 같이 크기는 있지만 비율은 아닌 경우, MAPE 가 적합하지 않다. Ratio Scale (비율) : 무게나 길이와 같이 절대 0 값이 존재하는 경우, RMSE 및 MAE 는 적합하지 않다. RMSE vs. MAE : MAE 보단, RMSE 사용이 큰 오류에 대해 좀 더 패널티가 있다. (극단/평균적인 오류 선호)
Step 2: 종단 간 시스템 구현 1) 가능한 한 빨리(ASAP) 베이스 라인으로 사용할 합리적 시스템을 구축 -. 정상적으로 작동만 되면 된다. -. 또는, 잘 작동되는 다른 파이프 라인을 가져와 기준으로 삼아도 된다. 2) 어떤 학습 알고리즘을 사용할 것인가? -. 딥 러닝이 정말로 필요한가? (large-scale data? complex task? previous success of deep learning?) -. 깊은가? (Listle noise, complex structure? or Lots of noise, little structure) -. 일반적으로, 간단하고 강력한 알고리즘으로 시작하는 것이 좋다. (linear regression, decision tree ensemble)
Step 3: 반복적 시스템 개선 Source: GTC 2015 Keynote with Dr. Andrew Ng 1) 데이터(Data) 관점에서 확인 -. 학습 성능부터 오류가 너무 높다: 데이터나 코드가 잘못되었거나, hyperparameture tuning 으로 해결 ⇒ 그래도 안되면 데이터 문제 -. 학습 성능은 좋은데, 실제 성능이 좋지 않다: Regularization 문제, 그래도 안되면 데이터를 더 수집한다. -. 실제 성능이 좋으면? 그냥 사용해도 좋다. 2) 하이퍼 파라미터(Hyperparameters) 관점에서 확인 -. Manual Hyperparameter Tuning: 수기로 초기 설정 ⇒ 딥 러닝인 경우, ⓛ Number of hidden layers/unints ② Learning rate ③ Weight decay coefficient ④ Droup rate 등 존재
-. Autometic Hyperparameter Tuning: hyperparameter 개수가 많을 경우, 계산 자원을 모두 넣고 최적 탐색 ⓛ Grid Search ② Random Search ③ Meta-heuristics ④ Model-based Optimization 등 존재
Machine Learning Practice
머신 러닝을 할 때는 항상 자신이 만든 결과물에 대해 다시 한번 생각해보아야 한다. 이 모델이 이상하게도 잘 작동될 때가 있고, 예상대로 잘 작동되지 않을 때가 많다. 따라서, 순차적으로 점검 포인트를 확인하고 시스템을 개선할 수 있도록 살펴보아야 한다.
Debugging
- 시스템 점검 포인트
일반적으로 머신 러닝이 잘 작동하지 않는 이유를 찾는 것은 어렵다.
데이터 / 소프트웨어 / 하드웨어...
작은 데이터부터 맞추어보고...
모델이 작동하는 과정을 전부 시각화 출력해보고...
- 전형적인 머신 러닝 모델링 전략과 현실에서의 머신 러닝 시스템
Source from http://martink.me/articles/machine-learning-is-for-muggles-too
