데이터분석/Code & Tools & Script Snippet

데이터 분석대회 참가 정리 (1)

늘근이 2018. 4. 21. 11:09

처음부터 대충의 가정과 모델을 세우긴 세우는데, 

모델을 세우는건 사실은 데이터가 있으면 컴퓨터가 알아서 하는것이고,


마찬가지로 알고리즘을 고를만한 선택폭도 

빠르고 확실한 부스팅 앙상블 계열을 택할수밖에 없는것으로 보이는데


그렇다면 제일 중요한것이라고 느껴진건



1) Input 데이터의 품질과 양

인풋데이터에 어떠한 feature들이 준비되어서 설명력을 높여갈수있을지. 그리고 그 변수들간 어느정도 상관성이 있어도 일단 깔끔한 모델을 만드는게 목적이 아니라 예측력을 높인다는 측면에서는 최대한 많이 필요로 하는것이 보인다.


2) Predict 대상 데이터의 형태

예측대상이 바로 옆에 있고 그대로 끝나면 상관이 없는데, 현실에서는 제대로된 모델을 세우려면 미래에도 동일한 형태로 학습데이터와 마찬가지인 데이터가 주어져야 한다. 미래 데이터구간의 데이터 형식이 바뀐다면, train모델의 예측력은 아무리 test를 잘 해본다해도 동떨어질수밖에 없다.


3) Predict 데이터에 대한 지속적인 팔로업

Predict데이터는 시간에 따른 예측을 해야할경우, 지속적으로 대회에서 내뱉는 값과, 나의 Test값을 Predict데이터들로 바꿔가면서 모델을 계속해서 발전시켜야 한다. 어떤 경진대회는 테스트기간이 있고, 테스트기간의 데이터 점수를 통해 계속해서 모델을 발전시키도록 한다.


4) 별로인 모델이라도, 데이터라도 일단 빠르게 내는게 중요하다!

Biendata의 같은 경우에는 2일뒤에 결과가 뜨기 때문에, 별로인 모델이라도 일단 아무거나 만들어서 제출하는것이 오히려 경험에 도움이 된다. 시험도 보면 볼수록 는다는 뭐 그러한 개념인데, 아무리 자기가 테스트 데이터가 있어도 그건 자기만의 테스트 데이터이므로 실제의 시험용 데이터에 빨리 대입해보는게 중요하다. 어떤것이든 깨닫는 게 생긴다.


5) FINAL모델의 SUBMIT시 올바른 모델인지 살펴보기

R의 XGBOOST의 구현체의 경우, 데이터프레임이 아닌 원핫인코딩이 되어있는 matrix를 넣게 되어있다. 그말인 즉슨, 나중에predict 될때 컬럼이 하나 적거나 순서가 바뀌어있어도 컴퓨터는 에러를 뱉지 않는다는것이다. 그래서 눈으로 하나하나 살펴보면서 이게 타당했는지 살펴볼 필요성이 있다.


개인적으로 첫경험이였던 데이터 경진대회의 경우 테스트 기간시 predict데이터에 대해 날씨정보에 대한 level변환시 컬럼이 바뀌어있어 예측력이 드라마틱하게 개선되었다. 다만아쉬웠던건 테스트를 빨리 못해봤다는점이 회사다니는 직장인으로써 좀 안타까운점이다. 이번 대회는 5월부터 시작하는 대회므로, 5월이 지난후에 후기를 남길 예정~ 약 200명이 참가하는 대회에서 30등안에 드는게 목표!

(SMAPE기준, 0~2까지 나오고 작은값일수록 에러가 적음)


6) 여러번 제출이 가능하다면 모델을 해당 횟수만큼 만들기

만약 제출횟수가 여러번이면 최대한 빠르게 제출횟수만큼의 모델을 구축하는게 급선무이다. 위의 대회에서는 3번의 제출기회가 하루마다 주어지는데, 3개의 완성도있는 모델을 만든다음에 여러번 제출하는게 좋다. 하나는 보수적인 모델, 하나는 급진적인 모델, 하나는 안정적인 모델 정도로..


분석대회에서는 데이터를 외부데이터를 쓰고자 한다면, 공개를 해야하거나 공정한 경쟁을 위해 통제를 하는데 이부분도 유의해서 봐야함.


7) Predict 테스트 데이터에 대한 재현

어떤 경진대회는 Predict를 미리 해볼수있도록 해놓았는데, 이에대한 재현만 가능하면 모든 파라미터를 다 테스트해볼수있다. 


8) 기존의 모델은 꼭 유지하면서 A/B 테스트 필요.

모델을 고쳤을때 무조건 기존 모델과 비교를 해야한다. 아무리 테스트 데이터에서 성능이 좋아졌더라도 오히려 특정한 상황에서만 좋아지고 나머지들은 죄다 나빠졌을 가능성이 있기 때문이다.


시간을 많이 쏟지는 못해서 아쉬웠다. 기상관측데이터를 많이 더 많이 찾아봤어야한다. 게다가 마지막에 이르러 모델이 좀 어그러진것같다. 고친 모델의 예측력이 오히려 심하게 떨어졌다.


대회기록

연습기간 (참가인원 약 1500팀, 제출팀 약 300팀)

04-24 117위

04-25 100위

04-26 76위

04-27 70위

04-28 64위

04-29 60위

04-30 59위


실제구간 (참가인원 3128팀, 리더보드 제출팀 313팀)

05-01 114위

05-10 98위

05-13 86위

05-14 89위


최종구간 (참가인원 4170팀, 리더보드 제출팀 660팀)

06-01 평가기준에 따라 98~135위


생각보다 순위는 낮지만, 참가했다는데 의의를 둔다

캐글에서 참가했으면 뭐 받았을까?


사용한 모델

잘정리해놓을 필요가 있지만, 일단 귀찮아서 대충 적는다.


Train Data / Predict용 기상예보 데이터

openweathermap.org 기상예보 (<- 데이터가 제대로 없어서 패착)


XGBOOST nRound = 1500, (1부터 2000까지 100단위로 학습 해봄),  L2 regualrization.


PM2.5 모델 중국 각 도시 35개 * 시간별로 48시간 = 1680개

PM2.5 모델 영국 각 도시 13개 * 시간별로 48시간 = 624개

PM10 모델 LAG없는 모델로 각 도시 35개 = 35개 (과소예측)

PM10 모델 LAG없는 모델로 각 도시 13개 = 13개 (과소예측)

O3 모델 = 1680개



POLLUTION 별로 LAG를 측정해서, 시간별 모델을 만들고, 각 도시마다 다시 만들었다. 다만 기상예측 데이터를 시간상 각 GRID마다 생성한게 아니라, 베이징 / 런던 기상예측 딱 두개를 가지고 훈련을 했기 때문에 과소예측이다.

PM10의 경우 NA가 많아서 LAG가 없고, 도시별로도 하지 않아서 일반모델로 돌려서 과소예측이다.

문제는 Predict데이터의 결과를 재현하는게 중요한데 잘 되지 않았다. 분명 가지고 있는 Test셋에는 1등보다 더 예측력이 좋았으나, 직접 제출을 하기 시작하자 상당히 예측력이 낮아진다.


GRID기상예측 데이터로 했어야하고, Predict 재현이 가능하게 했어야하는데, 시간이 없으니 일단 해본거에 만족한다.

다음에는 알고리즘에 대한 깊은 이해와 데이터셋에 대한 이해가 선결되어있어야 할듯하다. 다음은, XGBOOST뿐만 아니라 여러 알고리즘을 다시 stacking하는 모델을 10,000개정도 만들어서 뒤섞어봐야겠다.



제출 및 분석용 언어 R 라이브러리

- dplyr tidyverse(리눅스에서 설치할때 여러 난관이 있다. xml2를 설치하는데 애를 먹음.) 

- xgboost (메인 알고리즘) , randomForest(비교용)

- httr (request용), 

- xts 및 zoo (년도월등 separate하는데 씀) 


파싱용 언어 Python3

- urllib.request / json / csv / time / pandas / datetime / traceback / random / time


1) Python3 기상예보, 오염 데이터 전날 오전 12시에 파싱

2) R General 모델로 첫번째 submit 7분

3) Python3 최신 오염데이터로 전날 자정직전 업데이트

4) R General 모델로 한번 submit (예측력 제일 좋음) 7분

5) R Lag 모델로 다시한번 submit (예측력떨어짐) 7분


crontab을 이용한 자동화

한달동안 꾸준히 제출하는 방식이라 리눅스 crontab을 이용해서 알아서 파싱하고 알아서 올리게 만들었다.

crontab에 >>로 로그를 심을수 있는데, 경로가 제대로 안박혀있을경우 에러메시시에서 이를 제대로 확인하기 어려움.


느낀점

다음에는 파이썬을 쓰는게 나을것같다. 리눅스에서 Rscript가 상당히 애를 먹음.


주요 실험결과


RF

PM2.5 ~ temperature + pressure + humidity + wind_direction + wind_speed + weather + m + h + day, data = na.omit(raw_w)

SMAPE : 25.22 on train data

PM2.5 ~ temperature + pressure + humidity + wind_direction + wind_speed + weather + h + day, data = na.omit(train_w)

SMAPE 59.35 on test data


XGBOOST

PM2.5 ~ temperature + pressure + humidity + wind_direction + wind_speed + h + day

nround 100 SMAPE : 28.87 on train data

nround 1000 SMAPE : 1.55 on train data


PM2.5 ~ temperature + pressure + humidity + wind_direction + wind_speed + weather + h + day, data = na.omit(train_w)


XGBOOST

10 / 65.08

50 / 60.80

500 / 50.52

1000 / 49.80

1500 / 49 .79 <- final model without time lag (+month 45.16)

2000 / 49.80


XGBOOST (3hour lag)

recursive to 1000

nround = 1500 smape 57.04

nround = 1000 smape 55.75

nround = 500 smape 57.26

 

XGBoost (lag added)

Finally, lag added and SMAPE dropped to 37.37


실제 예측력 50~100 

낮아야 좋음.



다 끝나고 글을 써서 정리하려니 재미가 한뛔기(?)도 없다. 다음에는 생생하게 잘 정리를 해보아야 겠다는 생각으로~


대회가 끝나고 정리 -

- 최상위 탑티어 grid데이터 + lightGBM.

- Predict데이터가 없어도 순수 시계열 (Prophet)으로 예측가능. (상위 10~30위권) ㅡ.ㅡ

- 논문을 다 읽고나니 2018년 이후 부스팅계열은 xgboost -> lightGBM의 전환기이지만 결과적으로는 lightGBM(이름은 구리지만) 무조건적인 우세판단






'데이터분석 > Code & Tools & Script Snippet' 카테고리의 다른 글

Swift 4 - Read CGImage File  (0) 2018.05.17
모델평가 smape 파일창고  (0) 2018.04.22
R단점  (0) 2018.04.19
Long - Wide 데이터  (0) 2018.04.15
need at least two non-NA values to interpolate  (0) 2018.04.14