[DACON] LG-시스템품질 변화로 인한 사용자불편 예지 AI 경진대회

https://github.com/Hyunj5ng/dacon-LG

Hyunj5ng/dacon-LG

 

블로그에는 코드를 다 정리하기 힘들어서 주피터노트북파일을 업로드한 깃허브 링크를 올리기로 했다. 링크를 타고 들어가서 README.md 파일에 적힌 내용을 먼저 그대로 복붙했다.

 

dacon-LG

처음으로 공모전에 도전한 결과물이다. 공모전 당시에는 알지못했던 점들을 복습을 하면서 많이 배웠다. pandas DataFrame의 기본적인 조작법을 익히는데에 많은 도움이 되었다. 그리고 데이터분석에 있어서 처음에 가장 많은 시간이 들고 가장 중요한 부분이 EDA(Exploral Data Analysis)라는 것을 알았다. 기초 통계를 이용하여 데이터의 특성을 이해하고 데이터에서 나타내는 각 숫자의 의미를 파악하는 것이 먼저였다. 데이터분석은 누가 많이 해봤는가에 대한 싸움인것같다. 많이 시도해보고 시행착오를 많이 겪을수록 그 격차는 너무나도 크게 벌어진다. 이번 repo에서는 데이터의 EDA, 파생변수를 생성하는 첫 시도, 그 시도를 함수로 바꿔주는 작업, 그리고 간단하게 모델링을하여 테스트 결과까지 내는 것으로 마무리하였다. 부족한 점이 많고 개선할 수 있는 부분이 많기때문에 공부할 길이 멀다.

1. LG-EDA

주어진 train_err 데이터에서 각 컬럼별로 특징과 규칙을 도출해내었다. 예를들면 모델명과 fwver의 관계나, errtype과 errcode의 관계에 대해서 파악을 하였다. time column이 까다로웠지만 더 많은 시간을 투자하면 분명히 유의미한 insight를 도출할 수 있다. (output이 많아서 잘 열리지않는다..)

2. LG-derived-variables

EDA를 한 결과를 토대로 파생변수가 가능한 후보군을 추려내었다. 여기서 가장 큰 고민은 내가 생각하는 이상적인 파생변수의 논리와 현실적인 나의 코딩실력이 크게 상충되었다. 2차원 데이터를 다루는데에 있어서 엑셀로 간편하게 될 것 같은 부분들이 코딩으로 하기에 역부족인 상황들을 많이 마주쳤다. 사실 결과적으로 보면 어느정도 코딩으로 구현한 부분이 많지만 이 코드가 과연 효율적인 코드인지에 대한 의문은 없어지지 않았다. 대표적인 부분이, 각 id에서 errtype이 발생한 시간이나 요일의 평균을 구할때 약 6분정도 소요되었는데, 이게 과연 그렇게 오래걸릴만한 코드인지 확실하지 않았다. 하지만 계속 파생변수를 만드는 작업만을 할 수는 없기에, 이쯤에선 다음 스텝으로 넘어가야한다는 감이 생겼다.

3. LG-make-cols

가능한 파생변수들을 추려내고 마지막으로 이들을 하나의 함수로 묶어서 test 데이터에도 쉽게 적용할 수 있도록 만들었다. 사실 이 부분은 변수명을 고치는 작업이라서 논리적인 부분에 대한 고민은 적었지만 미세하게 test set에서 발생하는 문제를 해결하는데 많은 시간을 투자했다. 예를들면, train set에서는 user_id가 순서대로 처음부터 끝까지 모두 존재했지만 test set에서는 중간에 빠진 user_id 때문에 이를 어느 단계에서 처리해야하는지에 대한 문제에 마주쳤다. 이러한 문제를 사전에 방지하기위해서는 처음 EDA 단계에서 train과 test set의 공통점, 차이점을 확실하게 파악을 해야하고 test set또한 train set만큼 EDA를 철저하게 해야한다. 미리 알고있었다면 코드를 짤때부터 고려할 수 있었을 것이다.

4. lg-preprocess-to-modeling

앞서서 파생변수를 생성하여 (15000,252) 형태의 틀을 만들어, DACON에서 제공한 baseline의 모델링 코드를 그대로 사용했다. 결과적으로 말하면 성능은 그리좋지 못했다. baseline의 결과보다 0.02정도 높은 수준이었다. 따라서 파생변수의 수에 비례하여 결과가 좋아지는 것은 결코아니며 파생변수를 어떻게 생성해야하는지에 대한 논리적인 아이디어가 중요했다. 그 아이디어를 도출해내기 위해서는 EDA에 굉장히 많은 시간을 투자해야 한다. 개인적인 생각으로는 최대 2주정도 EDA만 지속적으로 하여 시각화를 통해 데이터에 대한 이해를 하는 게 최우선이다. 다른 사람들이 진행한 코드를 참고하는 것도 좋은 방법이지만 그보다 먼저 내가 직접 EDA를 해보고 다른사람들의 코드와 비교하여 부족한 부분이나, 조금 엇나간 방향을 바로잡는것이 가장 중요했다. 팀으로 진행한다면 시작전에 어떻게 EDA를 진행할 것인지 충분한 논의가 필요하다.

 

 

-----------------------------------------------------------------------------------------------------------------------------

 

이번 공모전에서 내가 접하지 못했던 많은 부분들을 배웠다. 위 글에서 제한사항이나 반성을 위주로 적었다면, 이번 프로젝트에서 개선사항을 정리해보고자 한다.

 

1. 생성한 모델에서 큰 영향을 미치는 column들을 탐색

사실 검색하면 바로 나오는 개념이다. 하지만 데이터 분석 프로세스가 완벽하게 익히지 못했기때문에 어느 단계에서 이 부분을 적용해야하는지 아직 감이 잡히지 않는다. 이와 관련하여 다중공선성 탐색또한 필요하다. 더 나아가 다중공선성의 개념에 대해 다시한번 블로그에 포스팅을 하는 것도 좋은 방법이다.

 

2. Quality data 적용

이번 공모전에서는 데이터 set가 2개가 주어졌다. train_error_data와 train_quality_data 였다. 하지만 나는 충분한 실력을 갖추지 못하기도 하고 한 set라도 제대로 해보자 라는 결심을 했기때문에 후자는 거의 건들지도 못했다. 만약 팀으로 진행한다면 투자시간이 확연히 줄어들 것이다.

 

3. 내가 설정한 가설(파생변수를 생성한 근거)가 맞는지 확인

이는 1번 항목과 겹치는 부분이긴 한데, 모델이 큰 영향을 미치는 column만을 찾는다고 해서 그 column이 내가 설정한 가설이 들어맞는다고 말할 수는 없을 것이다. 이를 논리적으로 설명할 수 있는 근거를 마련해야한다.

 

4. time data 처리를 올바르게 했는가

이번 프로젝트에서 가장 고민이 많았던 부분이다. 솔직하게 말하자면, 그냥 평균으로 퉁치자 라는 막연한 생각으로 접근했다. 특정 errtype이 이 날짜, 이 시간에 평균적으로 발생하더라 라고 가설을 세우긴 했지만, 이는 EDA가 충분히 진행되지 못한 결과이다. time data는 EDA를 할때 더 자세하게 다뤄야할 부분이다. 다른 사람들의 코드를 참고했을때는, fwver이 변화한 time을 토대로 새로운 column을 만들었고 결과가 상당히 좋게 나왔었다. 내가 이를 간과한 이유는 애초에 스스로 EDA를 해보지도 못했기때문이었다. 

 

5. 파생변수 생성 소요시간을 줄일 수는 없는가

가장 아까운 시간이 아마 이 소요시간이 아니었나 싶다. 지금 나의 상식으로는 전혀 오래걸릴 이유가 없는 코드인데 예상보다 너무 오래걸렸다. 구글링을 충분히 해보고 내가 찾고싶은 정보를 찾아 올바르게 적용하는 능력을 더 길러야 한다. 그리고 내가 직접 for문을 만들어 돌리는 시도는 좋지만, 분명히 그보다 더 좋은 함수가 있을게 분명하고 더 간결하게 코드를 작성하는 방법이 무수히 많을 것이다. 새로운 코드, 함수에 대한 거부감을 줄여야한다.

 

6. test data에 결측값을 어떻게 처리하는 것이 가장 smart한가?

이번 프로젝트에서, 대부분의 결측값은 mode값으로 대치했다. 하지만 아예 누락된 user_id의 경우에 이를 빼고 모델을 돌릴 것인지, 아니면 모든 값을 0으로 처리하고 모델을 돌릴것인지에 대한 고민이 필요하다. 위에서도 언급했지만, 가장 좋은 해법은 초반에 이러한 상황자체를 인지하는 것이다.

 

7. 처음에 EDA를 할때 SQL을 사용할 수 있지 않을까?

SQL에 대한 지식은 거의 없지만 대충 쿼리문이라는 게 존재한다는 건 알고있다. 막연하게, 내가 파이썬코드로 구현한 것이 쿼리문으로 어느정도 해소될 수 있지않을까 라는 생각을 했다. 대용량 데이터를 정제하고 이를 wrangling하는 단계에서 SQL쿼리문으로 보다 편이하게 할 수 있을 것이다.