<혼자 또는 같이하는 머신러닝 스터디 잼> Intermediate Machine Learning 코스 요약

아 슬슬 정리가 빡세진다ㅋㅋㅋㅋㅋㅋ 그래도 끝냈다. 두 번째 코스 Intermediate Machine Learning 코스 요약이다.

 

Lesson 2. Missing values

데이터가 비어있을 때 처리하는 방법을 알아본다. 세 가지 방법을 이야기 해볼 것이다.

 

1. 간단한 방법 : 값이 비어있는 컬럼을 버린다. 쿨하다.

drop column

Bed 부분에 NaN값으로 값이 없으니 그냥 Bed 컬럼을 버리자!

 

2. 조금 더 나은 방법 : Imputation

Imputation은 어떤 숫자로 비어있는 cell을 채운다. 예를 들어 해당 컬럼의 평균값으로 채운다.

Imputation

(1.0 + 2.0 + 3.0)/3 = 2.0

 

3. 확장된 Imputation 방법

Imputation은 스탠다드한 방법이고 보통은 잘 작동한다. 그러나 cell에 채워넣은 값이 진짜 값과는 차이가 있을 수 있다.

그래서 해당 값을 임의로 채운 것인지 아닌지 모델에게 가르쳐주는 것은 더 좋은 예측값을 얻을 수 있는 방법이 될 수 있다.

 

Extend Imputation

 

 

# 컬럼 기준으로 값이 하나라도 비어있는 컬럼의 이름을 모은다

cols_with_missing = [col for col in X_train.columns if X_train[col].isnull().any()]

# 모은 컬럼 버리기(drop)

reduced_X_train = X_train.drop(cols_with_missing, axis=1)

 

 

Lesson 3. Categorical Variables

Categorical variable는 몇 가지의 제한된 숫자로 값이 이루어져있다. 예를 들어, “당신은 어떤 종류의 자동차를 타십니까?” 라는 설문조사에 “혼다”. “토요타”, “포드”의 선택지가 있는 것과 같다. Categorical variable 타입의 데이터가 있을 때 어떻게 모델을 학습하는지 방법을 세 가지 알아본다.

 

1. Categorical variable로 이루어져 있는 컬럼을 버린다. 여전히 쿨..

 

2. Label Encoding

라벨 인코딩이란 각각의 유니크한 값들을 유니크한 숫자로 매칭 시켜주는 것이다. 즉, 각각의 숫자가 Categorical variable를 대신하는 것.

Label Encoding

위의 방법은 의미상 빈도순으로 설정했다 : "Never" (0) < "Rarely" (1) < "Most days" (2) < "Every day"

 

3. One-Hot Encoding

One-hot encoding은 각각의 라벨의 이름을 가진 컬럼을 만들고 해당 라벨을 가진 컬럼에만 1이라는 숫자를 준다. 나머지는 0.

그림이 이해가 편하다.

One-Hot Encoding

 

위 방법 중 어떤 방법이 제일 좋은가요?

보통은 one-hot encoding 방법을 가장 잘 되고, categorical variables이 있는 컬럼을 버리는 것이 가장 안좋지만 케바케다. categorical variables이 있는 컬럼을 무조건 버리는게 안좋아 보일 수 있지만 해당 컬럼이 전혀 의미없는 컬럼이라면 좋은 모델을 만드는데엔 도움이 될 것이다.

 

# 특정 데이터 타입을 가진 컬럼을 select

pandas.DataFrame.select_dtypes()

(Tip. String은 Object 타입이다.)

 

 

Lesson 4. Pipelines

Pipelines은 데이터 전처리와 모델링 코드를 간단하게 구성하는 역할을 해줌.

 

1. 더 깨끗한 코드 : 각 처리 단계를 거쳐서 데이터를 전처리하는 것은 복잡해질 수 있다. 파이프라인을 사용하면 수동으로 데이터의 흐름을 따라가지 않아도 됨.

2. 더 적은 버그 : 전처리에서 실수할 가능성을 줄여줌.

3. 생산성 : 모델을 프로토타입에서 배포 가능한 스케일로 전환하는 것은 상당히 어려울 수 있다. 이 문제에 대해 파이프라인이 도움이 될 수 있음.

4. 모델 검증을 위한 추가 옵션 : cross-validation을 다루는 예제에서 확인 가능.

 

 

Lesson 5. Cross-Validation

머신러닝은 반복작업이다.

사용할 예측 변수, 사용할 모델 유형, 해당 모델에 제공할 인수 등에 대한 선택 사항에 직면할 것이다. 지금까지 validation(또는 홀드아웃) 셋으로 모델 품질을 측정하여 데이터 중심 방식으로 이러한 선택을 수행했다.

그러나 이 접근법에는 몇 가지 단점이 있다. 이를 확인하려면 5000개의 행이 있는 데이터 세트를 사용한다고 가정해보자. 일반적으로 데이터의 약 20%를 validation 데이터 세트 또는 1000개의 행으로 유지한다. 그러나 이것은 모델 점수를 결정하기에 랜덤성이 있다. Validation 셋으로 사용해 모델 성능을 평가할 때 데이터 셋의 크기가 작은 경우 테스트 셋에 대한 성능 평가의 신뢰성이 떨어지기 때문이다. 즉, 다른 1000행에서 부정확하더라도 모델이 1000행의 한 집합에서 잘 수행될 수 있기 때문이다.

 

Cross-validation은 모델 품질 척도를 얻기 위해 데이터의 여러 하위 집합에 대해 모델을 평가해본다. 

 

예를 들어, 아래의 이미지같이 5개로 데이터를 쪼개는 것을 5 fold라고 한다.

Cross-validation

 

Cross-validation는 모델 퀄리티에 대해 더 정확히 측정할 수 있게 해주지만 학습 속도가 느려진다. 따라서 작은 데이터셋에는 약간의 계산이 큰 문제는 아니므로 시도해보는 것이 좋고, 큰 데이터셋은 이미 하나의 validation 셋으로 충분할 수 있다.

 

 

Lesson 6. XGBoost

Random forest는 “ensemble method(앙상블 기법)”이라고 한다. 앙상블 기법은 여러가지 모델의 예측을 합쳐서 결과를 낸다. Gradient boosting 역시 앙상블 기법 중 하나이고, 어떠한 사이클을 반복적으로 지속하면서 약한 모델을 결합해서 더 좋은, 강한 모델을 만들어낸다.

 

Gradient Boosting

사이클은 다음과 같다.

 

데이터셋에 대해 예측값을 얻고 loss를 구한다. 그리고 새로운 모델을 이전의 loss를 바탕으로 학습시켜서 더 나은 모델을 만들어 앙상블되도록 추가 한다(“gradient”나 “gradient boosting” 은 loss function이 새 모델의 파라미터를 결정할 때 gradient descent를 사용한다는 것을 말한다). 이것을 계속 반복한다.

 

Lesson  7. Data Leakage

Data leakage(혹은 leakage)는 학습 데이터가 타겟에 대한 정보를 가지고 있지만, 그 정보들을 실제 예측에 사용할 수 없는 경우 발생한다. 학습 데이터, 심지어 validation 데이터에 대해서도 학습이 잘 되었지만 모델 배포후에는 제대로 동작하지 않는다는 의미이다. 

 

두 가지 data leakage가 존재: Target leakage 와 train-test contamination

 

1. Target Leakage

leakage는 예측 할 때 사용할 수 없는 데이터가 학습 데이터 셋에 포함되어 있을 때 발생한다.

위 이미지 데이터로 당신은 폐렴(pneumonia) 환자를 예측할 것이다. got_pneumonia와 took_antibiotic_medicine는 긴밀한 연관성을 보인다. 그래서 모델은 쉽게 잘 학습될 것이다. 하지만 저 열의 의미를 생각해보면 조금 이상하다. 왜나하면 took_antibiotic_medicine은 항생제를 맞았는지? 인데 폐렴이 걸리기 전에 항생제를 맞지는 않는다.즉, 이 사람이 페렴에 걸렸냐 안걸렸냐를 예측할 때 took_antibiotic_medicine을 물어볼 타이밍은 아니다.  

따라서 해당 피쳐가 예측 시점에 사용이 될 수 있을지 생각해보고, 그렇지 않다면 데이터셋에서 제외시켜야 한다.

 

2. Train-Test Contamination

이 data leakage는 학습 데이터와 validation 데이터를 제대로 구분하지 않았을 때 생긴다.

 

Recall that validation는 모델이 이전에 고려되지 않았던 데이터에 대해 어떻게 작동하는지 측정하는 것을 말한다. Validation 데이터가 전처리에 영향을 준다면 이 과정에 손상이 올 수도 있다.

만약  train_test_split()을 전처리 과정(missing value를 처리하는 imputer 같은) 이전에 한다고 생각해보자. 결과는? Validation 스코어는 좋겠지만 배포 후의 성능은 별로일 것이다.

 

만약 validation 데이터가 train-test split을 기반으로 만들어졌을 때, validation 데이터를 모든 fitting에서 제외하고, 전처리 단계의 fitting에 포함시켜야 한다. Scikit-learn의 pipelines을 이용하면 더 쉽다. Cross-validation을 사용할 때는 파이프 라인 내에서 전처리를 수행하는 것이 훨씬 더 중요하다.

 

 

끝