How to win a data science competition Week2 - EDA

Coursera 강의인 How to Win a Data Science Competition: Learn from Top Kaggler Week2 EDA를 듣고 정리한 내용입니다
EDA : 탐색적 자료 분석, Exploratory data analysis

EDA

EDA가 주는 것
- 데이터를 더 잘 이해할 수 있음
- 인사이트를 형성 가능
- 가설 생성할 수 있음
- 직관력을 가질 수 있음
- magic feature를 찾을 수 있음
Visualiations
- Visualization -> Idea : Find pattern
- Idea -> Visualization : Hypothesis testing
모델링에 바로 들어가기보다 반드시 EDA를 먼저 해라!

Exploratory data analysis

Get domain knowledge
- 대회 관련 도메인 지식 쌓기
- 위키피디아에 검색, 구글에서 기사 검색 등
Check if the data is intuitive
- 직감에 기반해 데이터 체크
- 나이에 336이 있으면 이건 오타인가?
- 33인가? 36인가?
Understand how the data was generated
- Train과 Test data의 분포 비교
- 데이터를 잘 섞었는지?
- 적절한 validation이 셋팅되야 함

Exploring anonymized data

Anonymized data
- 보안상의 문제로 encode
- type of feature를 알 수 없게 만듬
- 우리는 의미를 알 수 없음
- decode 할 수 있지만, 거의 불가능
- 각각의 feature를 explore
  - column의 의미지 추측
  - column의 타입 추측
- Feature의 관계를 explore
  - Feature간 관계 찾기
  - Feature groups 찾기
- histogram을 그려보거나 value_counts()로 빈도 보기
- Decoding 실습
  - feature_importance 보고 중요도 파악
  - mean, std 파악
  - 같은 값이 반복되는 것이 보임
  - 아마도 StandardScaler! Decode해보자
  - unique value를 뽑고 sort -> 0.04332159가 반복
  - 모든 값에 0.04332159를 나눈 후, 소수점을 정리

Visualizations

Explore individual features
- Histograms : plt.hist()
- Plot (index vs value) : plt.plot(x, '.'), plt.scatter(range(len(x)), x, c=y), 데이터가 적절히 섞였는지 확인
- Statistics : df.describe(), x.mean(), x.var()
- Other tools : x.value_counts(),x.isnull()
Explore feature relations
- Pairs
  - Scatter plots : plt.scatter(x1, x2), pd.scatter_matrix(df)
  - Corrplot : df.corr(), plt.matshow(...)
- Groups
  - Corrplot + clustering
  - Plot (index vs feature statistics) : df.mean().plot(style='.'), df.srot_values().plot(style='.')

Dataset cleaning and other things to check

Duplicated columns
- 중복되는 column이라면 제거하는 것이 좋음(메모리 관점)
- traintest.T.drop_duplicates()
Duplicated rows
- 같은 label을 가지는지 체크
- 왜 이 값이 중복인지 이해하기
Check if dataset is shuffled
- 만약 셔플되지 않았으면 data leakages를 찾을 수도 있음!
- rolling_mean과 mean 비교

Validation

Validation and overfitting

private 리더보드가 나오면 성적이 떨어지는 경우가 있습니다
2가지 원인
- 1) 경쟁자가 validation을 무시하고 public 리더보드에서 가장 좋은 제출물을 선택
- 2) 경쟁자가 public, private 데이터가 일치하지 않거나 private 리더보드에 데이터가 적은 경우
private 데이터에 맞게 제출하는 것이 목표!
Validation
- Unseen data에도 잘 맞췄으면 좋겠음
- 잘 맞추지 못한다면 모델의 실수를 측정하고 싶음
- 이 성능은 Train(past) 데이터와 Test(future) 데이터에 따라 다름
- 학습한 후, 모델의 성능을 평가하기 위해 validation을 사용
- Train(past), Validation(past), Test(future)
- Validation에서 성능이 잘 나온 것을 Best 모델로 하고 계속 튜닝을 하면 오버피팅이 될 수 있음(Test엔 잘 안맞는 모델)
underfitting and overfitting
- 머신러닝의 오버피팅과 대회의 오버피팅은 살짝 다름
- Overfitting in general != overfitting in competition
- General
  - capturing noize
  - capturing patterns which do not getneralize to test data
- Competition
  - low models’ quality on test data, which was unexpected due to validation socres
  - 모델의 복잡도가 높을 경우, 낮추면 당연히 더 좋을 것이라 예상하지만 아닐 경우

Validation strategies

How many splits should we make
What are the most foten methods to perform such splits
Validation 유형
- Holdout
  - ngroups=1
  - sklearn.model_selection.ShuffleSplit
  - Data를 Part A, B로 나눔
  - A로 Train, B로 Predict
  - B의 예측을 토대로 model quality 측정하고 하이퍼파라미터 진행. B의 quality를 최대화
  - Use Case
    - 충분한 데이터를 가지고 있을 때 유용
    - 같은 모델을 다르게 split해서 성능을 보고싶을 경우
  - Split 방식이 성능 추정에 민감한 영향을 미침
- K-fold
  - ngroups=k
  - sklearn.model_selection.kfold
  - Train data를 K folds로 나눔
  - 각 fold마다 iterate: 현재 fold를 제외한 모든 fold에 retrain한 후, 현재 fold로 predict
  - prediction값을 사용해 각 fold별 quality를 계산, 하이퍼 파라미터를 찾고, 각 fold의 quality 최대화
  - loss의 mean과 variance를 측정해 개선을 파악할 수 있음
  - 서로 다른 holdout을 k번 반복
    - 모든 데이터를 training과 test에 쓸 수 있음
  - Score를 평균
  - 일반화 성능을 만족시키는 최적의 하이퍼 파라미터를 구하기 위한 모델 튜닝에 사용
  - Strtified 방법을 사용해 샘플링하면 알고리즘이 더 개선되곤 함
- Leave-one-out
  - ngroups=len(train)
  - sklearn.model_selection.LeaveOneOut
  - 작은 데이터를 가지고 있을 때 유용
  - 현재 샘플을 제외한 모든 샘플로 retrain, 현재 샘플로 predict
  - 다른 알고리즘에 비해 실행 시간이 오래 걸림
Stratification
- 충분한 sample이 있을 경우 shuffling data로 random split
- 그러나 sample이 충분하지 않으면 random split은 실패할 수 있음
  - Train시 클래스 비율은 38%, 28%, 34%인데 Valid시 데이터셋은 24%, 44%, 32%라면 불균형 발생
- 각 클래스가 train set과 test set에 정확하게 분포되도록 데이터셋을 랜덤하게 나눔
- 유용한 상황
  - 작은 데이터셋
  - 불균형한 데이터셋
  - Multiclass classification

Data splitting strategies

1) Random rows in validation
2) Time based split
3) Differend approached to validation
- 모델의 목적에 따라 적절한 split이 필요
- - 파란색 선이 mean value
  - 좌측의 경우 test보다 validation 때 더 나은 score 얻음
  - 우측의 경우 test와 validation와 유사한 score 얻음
Summary
- 다음과 같은 상황에 전략이 다를 수 있음
  - 생성된 feature 사용시
  - 모델이 해당 feature에 의존할 경우
  - target leak일 경우
- Splitting data into train and validation
  - Random, rowwise
    - Row들이 독립적일 때 유용
    - Row가 사람일 경우 독립적인 Case
    - 가족이거나 같은 회사 동료일 경우, 가족이 하나의 카드를 사용할 경우는 의존적인 Case
  - Timewise
    - Time based
    - 특정 일 이전의 데이터는 train, 이후의 데이터는 test
    - Moving window validation
  - By id
  - Combined
    - Date + Id, geographic

Problems occurring during validation

1) Validation stage
- inconsistency for data
- example : 1월이 2월보다 명절이 더 있어 판매량이 증가되는 데이터가 있음. 이 경우 1월 데이터로 2월을 예측하면?
- score와 최적의 파라미터가 다른 이유
  - 너무 적은 데이터 (Too little data)
  - 너무 다양하고 불일치한 데이터 (Too diverse and inconsistent data)
- Extensive validation
  - 다른 KFold에서 얻은 score를 평균
  - 1 split으로 모델을 만든 후, 나머지로 score 평가
2) Submission stage
- 우리가 종종 보는 현상
  - LB score가 validation score보다 일관되게 상승/하락
  - LB score가 valdation score와 관련이 없음
- Organizer가 split한 것을 분류하는 것은 매우 어려움
  - 계속 제출해보며 기록
  - leader board 점수를 또다른 validation fold로 보기!
- Other reasons
  - too little data in public leaderboard
  - 부정확한 train/test split
  - train and test data가 다른 분포
LB shuffle
- 리더보드에서 랭킹이 급상승 또는 급하락할 경우
- Randomness
- Little amount of data
- Different public/private distributions
  - Time-series 데이터에서 종종 발생
Conclusion
- validation stage가 크게 다를 경우
  - Average scores form different KFold splits
  - Tune model on one split, evaluate score on the other
- Submission score가 local validation score와 일치하지 않을 경우
  - Public LB가 너무 작은지 check
  - 오버피팅인지 check
  - 올바른 split 전략을 선택했는지 check
  - train/test의 분포가 다른지 check
- LB shuffle의 원인
  - Randomeness
  - 적은 데이터
  - public/private 분포가 다름
Advices on validation in a competition

Data leakages

Basic data leaks

Data leakage : 데이터 유출, 비현실적으로 좋은 결과를 내는 예상하지 못한 정보가 있는 경우
현실에선 사용하는 것이 말도 안되지만, 경진 대회에선 높은 점수가 목적이라 사용하기도 함
마감 전에 공개하면 대회가 흔들릴 수 있음
종류
- Leaks in time series
  - Future picking
  - 현실에선 우린 미래의 정보를 알 수 없음
  - 대회에선 train/public/private으로 나뉨
  - CTR tasks에서 유저 로그, 날씨 같은 경우 미래의 정보를 포함할 수 있음
- Unexpected information
  - Meta data
    - 파일 생성일, 이미지 해상도 등
    - 특정 카메라에서 찍은 것이 모두 고양이일 수 있음
  - Information in IDs
    - 모델에 ID를 넣는 것은 이치에 맞지 않음(이미 target값과 연결되어 있으니)
    - 그러나 언제나 그런 것은 아님 id는 hash의 결과일 수 있음
    - id에 대해 신중히 다루기
  - Row order

Leaderboard probing and examples of rare data leaks

ID와 밀접하게 연결된 카테고리는 LB probing에 취약함
- id가 같은 것의 라벨을 넣고 제출해보고 나온 결과로 역추적 가능
- Redhat and west nile competition
Peculiar(이상한) examples
- Truly Native
  - Data collection, Date proxies가 저장되어 있음. 추가적인 데이터를 수집해 feature 생성
- Expedia Hotel recommendations
  - 유저가 예약할 호텔 그룹 예측
  - distance feature에 data leak
  - Reverse engineering으로 좌표를 추정
- Falvours of physics
  - signal이 인위적으로 시뮬레이션됨
  - Reverse engineering
- Pairwise tasks
  - Data leakge in item frequencies
  - Similarities from connectivity matrix

Expedia challenge

강의 자료
강사님이 참여한 대회 중 가장 흥미로운 대회
Data leakage 썰 풀어줌
호텔 그룹으로 라벨링 되었다는 것은 실제 호텔의 특성임을 기억!
유저와 호텔의 거리를 통해 추측할 수 있는 것들이 있음! Train과 test에서 많이 매칭됨
- user city와 destination distance pair
- 더 많은 match를 찾는 것
- 유저 도시, 호텔 국가, 호텔 도시 3개의 방정식으로 어느 그룹의 호텔이 몇 개나 있는지를 알 수 있음
- 리버스 엔지니어링을 하며 모든 도시의 좌표를 반복적으로 찾음
- 일부 도시는 바다 위에 있는것으로 보였는데, 알고리즘이 정확하지 않다는 것을 의미
- 3개의 방정식이 아닌 수백 수천개의 방정식과 수만개의 변수를 사용해 정확한 좌표를 얻음
- 모든 도시에 대해 그리드 셀을 남겨서 개수 count
- Out-of-fold로 feature generation. 2013<->2014
- Xgboost로 16시간 학습
- (그냥 진짜 리버스 엔지니어링으로 철저하게 데이터를 얻음.. 변태처럼 해야 3등하는구나)

Reference

카일스쿨 유튜브 채널을 만들었습니다. 데이터 사이언스, 성장, 리더십, BigQuery 등을 이야기할 예정이니, 관심 있으시면 구독 부탁드립니다 :)

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 다양한 의견이 있다면 댓글 부탁드립니다 :)

Buy me a coffee