LG AIMERS 4기 PHASE 2 해커톤 및 수료 후기

ML,DL

LG AIMERS 4기 PHASE 2 해커톤 및 수료 후기

lee_zo.o 2024. 3. 11. 01:23

LG AIMERS 4기로 활동하면서 진행한 해커톤 경험을 기록한 글

PHASE 2는 2월1일 ~ 2월 26일까지 약 한달간 진행된 해커톤 프로젝트였다.

해커톤 어떻게 ?

해커톤 주제는 "MQL 데이터 기반 B2B 영업기회 창출 예측 모델 개발" 이었다.

고객의 MQL데이터(train.csv)가 주어졌다. 여기에는 고객의 국적, 고객의 회사명, 고객의 유형, 요청 제품 카테고리 등 고객과 관련된 28개의 피처와 데이터가 주어졌고, 이를 기반으로 is_converted(영업전환여부) 라는 피처가 Ture인지 False인지를 예측하는 binary classification 모델을 만들어야 했다.

train.csv 에는 is_converted가 결측값이 아닌 true/false로 나타나있었기 때문에, 이를 통해 Supervised Learning을 시도해 볼 수 있었다. 최종적으로는 train.csv 데이터 기반으로 구현한 model을 is_conveted 값이 없는 submission.csv (새로운 데이터) 에서도 잘 동작하는 모델을 만들어야 했다.

대회를 진행하기에 앞서, 나는 모델링이나 데이터 분석이 처음이었기 때문에, 팀 빌딩을 하기로 마음 먹었다. 그러나, 관련 스펙이나 경험이 없어 받아주는 팀이 없었다. 결국 경험이 없는 사람들만을 모아 총 4명으로 팀 빌딩을 하였고, 모르는 만큼 더 시간을 투자하고 열정있게 해커톤에 임했다. 2월 한달은 다른 활동 없이 해커톤에만 전념했던 것 같고, 매일 4,5시간 씩은 코딩을 했다.

대회를 진행하면서 실시간으로 우리팀의 순위와 public score를 볼 수 있게 되어있었다. public score는 f1 score를 기반으로 채점되었다. 하지만 여러번 제출하면서 단순 f1 score뿐만 아니라, duration time이나 overfitting등 여러 요소가 고려되는 것을 볼 수 있었다. 대회가 끝나면 또 다른 기준으로 채점된 private score로 최종 순위를 내는 형태로 진행되었다.

수료 조건은 public score 0.52 이상이었다. 우리 팀은 최종 score 0.73으로 안전하게 수료하였고, 상위 10%까지 순위를 올리기도 하였으나 아쉽게 phase 3에 진출하지는 못했다. phase 3는 총 100명만 갈 수 있었고 약 상위 3% 정도만 갈 수 있는 수준이었다.

하루에 제출은 5번으로 제한되어있어서, 나중에는 여러 방법을 시도해보고 싶어도 시도해보지 못하는 상황도 있는게 안타까웠다.

앞서 말했지만, 우리 팀은 모두 다 이런 해커톤에 경험이 전무했다. LG AIMERS에서 decision tree를 이용해 구현한 예시 모델 코드를 제공해주었는데, 이 예시 코드이해하는 것도 어려운 수준이었다. 그래서, 약 1주간 해커톤은 시작하지도 못하고, 예시코드를 분석하고 데이터분석 & 모델링을 어떻게 해야되는지에 대한 공부를 하였다.

예시코드의 순서는 이러했다.

사용 라이브러리 임포트 -> 데이터 로드 -> 레이블 인코딩 -> 평가를 위해 training data를 training set과 test set으로 분할 -> 모델 학습 -> 모델 평가 -> 코드 제출

정확히 이해할 순 없었으나, 일단 train.csv 파일을 로드해서 데이터를 확인하고 이에 맞게 데이터 전처리를 수행하는 과정이구나는 알 수 있었다.

추가적으로 구글링을 하고 관련 서적을 읽어보면서, 아래와 같은 방향성을 갖고 해커톤 문제를 풀어보기로 했다.

내가 받은 train.csv를 구조화해서 EDA와 데이터 전처리, 결측치 및 이상치 처리 등을 진행 -> 모델 학습 -> loss 를 train loss와 val loss을 각각 출력해서 overfitting 일어났는지 확인 및 처리

먼저 우리 팀은 역할 분담을 하기로 했다. 나는 데이터분석 및 전처리를 맡기로 하였고, 다른 분들은 모델링을 맡기로 하였다.

데이터 분석 어떻게 했나?

데이터 분석을 해본적이 없었기 때문에, 여러 블로그나 유튜브 영상을 참고했지만 도무지 감히 오지 않았다. 그러던 중 아래 책을 알게되었고, 아주 큰 도움을 받았다.

https://ridibooks.com/books/443000818

이것이 데이터 분석이다 with 파이썬

이것이 데이터 분석이다 with 파이썬 작품소개: 실생활 예제로 쉽게, 단계별 분석에 따라 구조적으로 배우는 데이터 분석 입문서데이터를 다루는 데 언어나 라이브러리는 도구일 뿐입니다. 진짜

ridibooks.com

다음 책은 EDA, 결측값 처리, 이상치 처리, 텍스트 마이닝, 웹 크롤링, regression 예측 모델, classification 모델 등 데이터 분석부터 시작하여 데이터 전처리와 탐색적 데이터 분석 그리고 더 나아가 이를 머신러닝 모델에 적용하고 평가하는 과정까지를 실습 예제들과 함께 알려주는 책이다. 데이터 분석 & 모델링의 전반적인 과정을 이해할 수 있었고, 관련 라이브러리들이나 데이터 분석 지식들을 얻을 수 있었다.

나는 이 책에서 공부한 내용을 우리 해커톤에 그대로 적용하였다.

탐색적 데이터 분석(EDA) & 데이터 전처리

각 피처들의 자료형 파악

먼저 주어진 29개 피처들의 자료형을 파악했다. 우리가 예측해야하는 is_conveted는 bool 자료형이었고, 수치형 피처(int64 float64) 13개 범주형 피처(object) 15개로 구성된 데이터 셋이었다. 이를 통해, 추후 모델링에서는 범주형 피처들을 수치형으로 바꾸는 전처리 과정이 필요하겠음을 파악할 수 있었다.

결측치 파악

결측값이 없다면, 해당 피처는 총 59299의 데이터 수를 가진다. 이 수치를 통해 피처별로 결측값이 몇% 있는지 알아낼 수 있었다.

예측하고자 하는 피처인 is_converted와의 상관관계

상관관계가 높은 피처들에 대해서는 결측치가 높더라도 어떻게든 삭제하지 않고 활용하려고 하였음. 수치형 피처에 대해서는 pearson사용하였고, 범주형 피처에 대해서는 상관관계 분석을 위해 카이제곱검정을 수행함. 카이제곱 값이 높고 p-value가 0에가까울 수록 is_conveted와 강한 상관성이 있음을 파악함. 이렇게 is_conveted 예측에 필요한 피처들을 가려

이상치 처리

각 수치형 데이터들의 이상치는 상하한값으로 대체하였다. 결측값에서 평균값을 쓰기 위해서, 결측값 처리 이전에 이상치 처리를 진행하였음

결측값 처리 : 결측값 처리방법으로는 피처 하나하나 분석하면서, 데이터 특성을 반영하여 아래와 같이 진행하였다.

피처 삭제 / 평균값으로 대치 / 중앙값으로 대체 / 최빈값으로 대체 / 0으로 대체 / 다른 상관성 높은 피처의 특성 반영하여 값 대체 / Other , OT로 값 대체 / unknown 등

최초 데이터분석과 어떻게 결측값 이상치를 처리했는지는 아래와 같음.
모델링하는 과정에서 계속해서 이 방식들도 수정되었다. 평균값으로 대체하던걸 중앙값으로 대체하기도 하고, 연관도가 높은 두 피처를 가지고 새로운 피처를 만들기도 하고, 어떤 피처는 삭제해보기도 하는 등 여러 방법을 시도하면서 모델 분류 성능을 높이고자 하였다.
최종 코드는 게시글 가장 아래에 깃허브 리포지토리 링크로 첨부하겠다.

수치형 피처 분석

bant_submit ⇒ 사용

설명 : 예산, 고객의 직책/직급, 요구사항, 희망 납기일 항목에 대해서 작성된 값의 비율

자료형 : float64
결측값 : 0
이상치 : 0
is_converted와 상관관계 : -0.002
수치형 피처들 중 com_reg_ver_win_rate 와 가장 높은 상관관계 가지나, 약함 : -0.36

⇒ 사용할 경우 예산, 직책, 요구사항, 타임라인과 관련된 피처들과 같이 모델링에 사용해야한다. (ex, customer-type, customer-country, enterprise, expected-timeline, business-area, business-sunarea, lead-owner, response_corporate 등등)

com_reg_ver_win_rate⇒ 사용

설명 : Vertical Level 1, business unit, region을 기준으로 oppty 비율을 계산

자료형 : float64
결측값 : 75%
이상치 : 1340
is_converted와 상관관계 : 0.34
수치형 피처들 중 ver_win_ratio_per_bu, lead_owner와 0.42,0.45의 상관관계 갖음

0.003788이 713회 나왔다는 뜻

⇒ lead_owner 변수를 그룹화 기준으로 사용하여, 각 lead_owner 그룹별 com_reg_ver_win_rate의 중앙값 계산하고, 해당 결측치를 이 값으로 채운다.

⇒ 채우고 나서도 채워지지않은 결측치는 전체 데이터의 중앙값으로 다시 채운다

customer_idx ⇒ 사용

설명 : 고객의 회사명

자료형 : int64
결측값 : 0
이상치 : 0
is_converted와 상관관계 : -0.05
수치형 피처들 중 bant_submit, historical_exisiting_cnt 와 -0.1, 0.1 정도의 상관관계

historical_existing_cnt ⇒ 사용

설명 : 이전에 Converted(영업 전환) 되었던 횟수

자료형 : float64
결측값 : 76%
이상치 : 1676
is_converted와 상관관계 : -0.00
수치형 피처들 중 bant_submit 과 -0.2 상관관계지님

⇒ 누락값을 0으로, 누락값에 대해 영업전환 된 적 없음으로 판단.

id_strategic_ver , it_strategic_ver ,idit_strategic_ver ⇒ 사용

id_strategic_ver, it_strategic_ver : (도메인 지식) 특정 사업부(Business Unit), 특정 사업 영역(Vertical Level1)에 대해 가중치를 부여

idit_strategic_ver : id_strategic_ver이나 it_strategic_ver 값 중 하나라도 1의 값을 가지면 1 값으로 표현

자료형 : float64
결측값 : id_strategic_ver : 94% , it_strategic_ver 98%, idit_strategic_ver: 92%
이상치 : 0
is_converted와 상관관계 : 파악불가

⇒ 결측값이 매우 높은데 반해, 세 피처 모두 갖는 데이터가 1.0 밖에 없어서,, 결측값에 대해 가중치 0으로 처리

lead_desc_length ⇒ 사용

설명: 고객이 작성한 Lead Descriptoin 텍스트 총 길이

자료형 : int64
결측값 : 0
이상치 : 5558
is_converted와 상관관계 : 0.11

⇒ 텍스트 길이는 , 모두 다를 수 있기때문에, 이상치가 높다고 해서 크게 문제될 부분은 아니다. 이상치 상하한값으로

ver_cus ⇒ 사용

설명 : 특정 Vertical Level 1(사업영역) 이면서 Customer_type(고객 유형)이 소비자(End-user)인 경우에 대한 가중치

자료형 : int64
결측값 : 0
이상치 : x
is_converted와 상관관계 :0.06
ver_pro, ver_win_rate_x 와 0.27, 0.28

⇒ 1이 가중치인데, 이상치로 분류됨 즉 이상치가 아님 ⇒ 그냥 사용

ver_pro ⇒사용

설명 : 특정 Vertical Level 1(사업영역) 이면서 특정 Product Category(제품 유형)인 경우에 대한 가중치

자료형 : int64
결측값 : 0
이상치 :x
is_converted와 상관관계 :0.00
ver_win_rate_x 와 0.4

ver_win_rate_x ⇒ 사용

설명 : 전체 Lead 중에서 Vertical을 기준으로 Vertical 수 비율과 Vertical 별 Lead 수 대비 영업 전환 성공 비율 값을 곱한 값

자료형 : float64
결측값 : 68%
이상치 : 4097
is_converted와 상관관계 :-0.04
ver_pro 와 0.4의 상관관계

⇒ 0.003079 일때 4097개 이상치이므로 , 상하한값으로 이상치 치환 후

⇒ 결측값은 ver_pro와의 상관관계를 이용해 중앙값 계산

ver_win_ratio_per_bu ⇒ 사용

설명 : 특정 Vertical Level1의 Business Unit 별 샘플 수 대비 영업 전환된 샘플 수의 비율을 계산

자료형 : float64
결측값 : 74%
이상치 : 409
is_converted와 상관관계 :0.1
com_reg_ver_win_rate와 0.45

⇒ 0.128571부터 이상치로 분류됨

⇒ 이상치는 상하한값으로 대체

⇒ 결측치는 business unit별 중앙값으로 대체

⇒ 대체 안된 나머지 결측치는 전체 데이터 중앙값으로 다시 대체

lead_owner ⇒ 사용

설명 : 영업 담당자 이름

자료형 : int64
결측값 : 0
is_converted와 상관관계 :0.09
com_reg_ver_win_rate와 0.42

범주형 피처 분석

customer_country

설명 : 고객의 국적

결측 : 1%

⇒ 결측값에 대해 Others라는 뜻을 나타내는 OT로 대체함

customer_country.1 ⇒ 미사용

⇒ cutomer_country와 98% 동일하므로 삭제

business_unit ⇒ 사용

설명 : MQL 요청 상품에 대응되는 사업부

결측값 : x

customer_type ⇒ 사용

설명 : 고객 유형

결측 : 74%

End-customer와 End customer는 같은 의미이므로 통합 외에도, Specifiter/Influencer, Home Owner , End-user등 비슷한 피처들 통합

⇒ 결측값에 대해 Other으로 대체

enterprise ⇒ 사용

설명 : 고객 유형

customer_job ⇒ 사용

설명 : 고객의 직업군

⇒ 결측값에 대해 other로 대체하겠음

⇒ 추가로 상위 10개의 직업군뺀 나머지 직업군들을 다 other로

inquiry_type ⇒ 사용

설명 : 고객의 문의 유형

⇒ 유사카테고리에 대해 대소문자 통일 , 유사명 하나로 통합

⇒ 결측값은 other로 대체

customer_position⇒ 사용

설명 : 고객의 회사 직책

response_corporate ⇒사용

설명 : 담당 자사 법인명

response_corporate
LGEIL    16908
LGESP     9311
LGEUS     5955
LGEMS     2768
LGEPH     2651
LGEGF     2149
LGECB     2079
LGEUK     1651
LGESJ     1469
LGECL     1339
LGEPS     1252
LGEIS     1146
LGEPR     1131
LGEDG     1051
LGEPL      850
LGEEG      704
LGEVH      614
LGEES      592
LGETK      541
LGEAR      491
LGEKR      433
LGEHK      383
LGEAP      366
LGESL      348
LGEMK      331
LGEFS      302
LGEAF      288
LGEIN      281
LGELF      274
LGESA      268
LGECI      263
LGETH      185
LGEEF      159
LGEPT      111
LGEML      110
LGEBN       99
LGEYK       78
LGECH       65
LGEHS       51
LGETT       47
LGEJP       41
LGEAS       33
LGESW       31
LGEMC       30
LGERO       29
LGEEB       13
LGEAG        8
LGERA        8
LGECZ        7
LGELA        2
LGEUR        1
LGEIR        1
LGEBT        1

product_category

설명 : 요청 제품 카테고리

결측치 : 32.67%

⇒ other로 대체

product_subcategory ⇒ 미사용

설명 : 요청 제품 하위 카테고리

결측치 : 84.43%

⇒ 피처 제거

product_modelname ⇒ 미사용

요청 제품 모델명

결측치 : 84%

⇒ 피처 제거

expected_timeline ⇒ 사용

설명 : 고객의 요청한 처리 일정

⇒ 아래 기준으로 범주통일

less than 3 months
3 months ~ 6 months
6 months ~ 9 months
9 months ~ 1 year
more than a year
Unknown (결측치 및 기타 불분명한 기간을 포함)

business_area ⇒ 사용

설명 : 고객의 사업 영역

결측 68%

결측값 other로 대체

business_subarea ⇒ 미사용

설명 : 고객의 세부 사업 영역

결측 90%

⇒ 피처삭제

customer_country

설명 : 고객의 국적

결측 : 1%

⇒ 결측값에 대해 Others라는 뜻을 나타내는 OT로 대체함

customer_country.1 ⇒ 미사용

⇒ cutomer_country와 98% 동일하므로 삭제

business_unit ⇒ 사용

설명 : MQL 요청 상품에 대응되는 사업부

결측값 : x

customer_type ⇒ 사용

설명 : 고객 유형

결측 : 74%

End-customer와 End customer는 같은 의미이므로 통합 외에도, Specifiter/Influencer, Home Owner , End-user등 비슷한 피처들 통합

⇒ 결측값에 대해 Other으로 대체

enterprise ⇒ 사용

설명 : 고객 유형

customer_job ⇒ 사용

설명 : 고객의 직업군

⇒ 결측값에 대해 other로 대체하겠음

⇒ 추가로 상위 10개의 직업군뺀 나머지 직업군들을 다 other로

inquiry_type ⇒ 사용

설명 : 고객의 문의 유형

⇒ 유사카테고리에 대해 대소문자 통일 , 유사명 하나로 통합

⇒ 결측값은 other로 대체

customer_position⇒ 사용

설명 : 고객의 회사 직책

response_corporate ⇒사용

설명 : 담당 자사 법인명

response_corporate
LGEIL    16908
LGESP     9311
LGEUS     5955
LGEMS     2768
LGEPH     2651
LGEGF     2149
LGECB     2079
LGEUK     1651
LGESJ     1469
LGECL     1339
LGEPS     1252
LGEIS     1146
LGEPR     1131
LGEDG     1051
LGEPL      850
LGEEG      704
LGEVH      614
LGEES      592
LGETK      541
LGEAR      491
LGEKR      433
LGEHK      383
LGEAP      366
LGESL      348
LGEMK      331
LGEFS      302
LGEAF      288
LGEIN      281
LGELF      274
LGESA      268
LGECI      263
LGETH      185
LGEEF      159
LGEPT      111
LGEML      110
LGEBN       99
LGEYK       78
LGECH       65
LGEHS       51
LGETT       47
LGEJP       41
LGEAS       33
LGESW       31
LGEMC       30
LGERO       29
LGEEB       13
LGEAG        8
LGERA        8
LGECZ        7
LGELA        2
LGEUR        1
LGEIR        1
LGEBT        1

product_category

설명 : 요청 제품 카테고리

결측치 : 32.67%

⇒ other로 대체

product_subcategory ⇒ 미사용

설명 : 요청 제품 하위 카테고리

결측치 : 84.43%

⇒ 피처 제거

product_modelname ⇒ 미사용

요청 제품 모델명

결측치 : 84%

⇒ 피처 제거

expected_timeline ⇒ 사용

설명 : 고객의 요청한 처리 일정

⇒ 아래 기준으로 범주통일

less than 3 months
3 months ~ 6 months
6 months ~ 9 months
9 months ~ 1 year
more than a year
Unknown (결측치 및 기타 불분명한 기간을 포함)

business_area ⇒ 사용

설명 : 고객의 사업 영역

결측 68%

결측값 other로 대체

business_subarea ⇒ 미사용

설명 : 고객의 세부 사업 영역

결측 90%

⇒ 피처삭제

유사 카테고리 통합

데이터를 시각적으로 나타내보니, 같은 데이터인데 대소문자가 다르거나 혹은 유사 카테고리로 통합할 수 있어보이는 데이터들이 보였다. 그래서 이를 반영하여 데이터 전처리를 진행했다. 범주형 데이터 중 기간을 나타내는 피처도 있었는데, 이는 기간을 범주화하여 다시 데이터를 구성하였다.

무의미한 피처 삭제

어떤 피처들은 서로 갖고 있는 데이터 분포와 값이 거의 98% 동일한 통계로 존재하기도 하였는데, 이런 경우 데이터 중복으로 모델 학습 효율이 낮아질 것을 대비해 한 피처를 삭제하기도 하였다. 결측 비율이 높으면서, 직관적으로 불필요하다고 생각되는 피처도 삭제하였다.

레이블 인코딩

머신러닝 모델을 학습시킬때 범주형 보다는 수치형 데이터로 학습시키는 것이 좋다. 그래서 범주형 데이터를 series 형태로 받아 모든 요소를 숫자형 데이터로 변환하는 레이블 인코딩 과정을 거쳤다.

data set 분리

전처리를 모두 마친 train.csv 데이터에 대해서 이를 test set과 train set으로 분리하였다. 처음에는 test_size를 0.2로 하였다.

오버샘플링 & 언더샘플링 적용

train.csv에서 is_conveted 의 true/false 분포를 보고 False가 True보다 훨씬 많은 클래스 불균형 상태임을 파악하였고, 비율을 조정해가며 언더샘플링과 오버샘플링을 적용했었다. 머신러닝 모델에서 분류를 잘 하기 위해서는 두 틀래스의 비율을 비슷하게 세팅해줘야 한다.

모델링 어떻게 했나

모델 선택

내가 데이터분석 및 전처리를 할 동안, 다른 팀원분들께서 내가 전처리한 데이터에 대해 가장 잘 분류하는 모델을 찾아 주셨다. 모델 선정 방법은 복잡도가 낮은 모델부터 높은 모델 순으로 적용시켜보았다. 처음에는 Logistic regression을 사용하였으나, 성능이 좋지 못하였고 Decision tree, RandomForest, Support Vector Machine 등을 사용해보다가, 최종적으로 XGBoost에서 성능이 제일 좋은 것을 확인하였고, XGBoost와 LightBGM을 앙상블하는 것으로 모델을 확정하였다. 해당 Classifier는 soft voting을 적용하였다. 이때 가장 f1 score가 높게 나왔다.

임계값 설정

평가 지표로 f1 score를 활용하였기 때문에, 이를 높일 수 있는 방법이 무엇이있을까 고민하다가, 분할한 train과 test set에 양성 클래스(true) 에 대한 예측 확률을 계산하고, 임계값 threshold를 기준으로 True/False를 다시 결정하도록 하였다. f1 score가 가장 높게 나오는 최적의 임계값을 찾기 numpy 라이브러리의 argmax를 사용하였다.

from sklearn.metrics import precision_recall_curve, f1_score

# 정밀도, 재현율, 임계값 계산
precision, recall, thresholds = precision_recall_curve(y_val, pred_proba_val)

# F1 점수 계산
f1_scores = 2*(precision*recall)/(precision+recall)

# 최대 F1 점수와 해당 임계값 찾기
max_f1_index = np.argmax(f1_scores)
max_f1 = f1_scores[max_f1_index]
best_threshold = thresholds[max_f1_index]

print(f"최대 F1 점수: {max_f1}, 최적 임계값: {best_threshold}")

모델 평가

해커톤 채점이 f1 score 기반이었기 때문에, 모델 평가 역시 f1 score를 이용하였다. train loss와 val loss 그리고 f1 score 를 각각 출력하여 overfitting / underfitting을 잡고자 하였다.

최적의 파라미터 찾기

이 부분은 여러 방법 이용해보았으나, 일일이 노가다로 하는게 가장 효율이 좋았다.
Xgb, lightGBM model의 특성을 고려하여 가장 모델 성능이 좋게 나오는 learning_rate와 n_extimators(트리의 개수) 매개변수의 값을 찾고자 하였다.
오버피팅이 일어나면 max_depth나 num_leaves를 줄이거나 L1, L2 정규화를 진행하여 모델 복잡도를 줄이고자 하였다.
min_child_sample을 조정하여 각 노드에서 필요한 최소 데이터 샘플 수를 바꿔보기도 하였다.
양성 클래스와 음성 클래스의 가중치 비율을 조절하는 scale_pos_weight라는 변수를 추가하여 비율이 작은 데이터에 더 많은 가중치를 부여하는 등 데이터 불균형을 줄이려는 시도를 하기도 하였다.
test_size도 처음에는 0.2로 시작하다가 늘려도보고 줄여도 보면서 최적의 값을 찾고자 하였다.
XGB와 LGBM은 내부적으로 cross-entropy loss fucntion을 사용하기 때문에, 이를 통해 예측값과 실제값간 차이를 최소화하여 파라미터를 optimization한다.
여러 시도해보다가, 가장 좋았던 방법은 모델을 완전히 오버피팅 시킨 후, 오버피팅을 조금씩 없애가면서 가장 높은 f1 score를 나타내는 파라미터를 찾는 것이었다.

첫째주는 해커톤 문제 자체에 대해 이해하고자 하였고,
둘째주는 데이터분석 전처리를 하였으며
셋째, 넷째주는 팀원들과 같이 최적 파라미터를 찾기위한 모델링에 시간을 썼다.

AI 해커톤이 처음인지라 우여곡절이 많았지만,, 같이 열심히 해준 팀원들이 있어 잘 마무리 할 수 있었던 것 같다.
한 달이 길다면 길고 짧다면 짧지만, 수료를 하기에는 충분한 시간이었다고 생각한다.

거의 한달동안 쉬는 날 없이, 팀 등수를 높이기 위해 해커톤에만 시간을 쏟았고
하루 길면 10시간 짧으면 2,3시간까지도 시간을 썼던 것 같다.
알고 있는 지식만으로 해결하려는 자세보다는, 여러 방법들을 찾아보고 새로운 시도를 할 때, 생각도 못한 성능 향상이 일어났던 것 같다.
어떤 모델을 선택하느냐에 따라 모델링 방법에도 조금씩 차이가 있기 때문에, 내가 사용하는 모델이 어떤 모델인지에 대해 충분히 공부하고 파라미터 조정틀 진행하는 것이 중요한 것 같다. 우리는 이 점이 많이 부족했다.

우리 팀은 최종적으로 (137/844 명 중)의 랭킹으로 해커톤을 마무리했다.
지식적으로 부족한 점이 많고, 모르는 것도 아직 너무 많지만,,,
처음 해보는 해커톤인 것을 감안하면 아주 뿌듯하고 유의미한 결과를 낸 것 같아 기쁘다!

PHASE3가 목표라면 경험있는 팀원들을 만나거나, 혹은 자신이 어느정도 경험이 있어야 될 것 같다.
처음부터 오프라인에 진출하기에는, 데이터 자체도 전처리하기 까다로운 부분들이 있었고, 관련 지식이 부족해서 이론은 알지만 실제로 시도해보지 못했던 것들도 여럿 있었다.
만약 나처럼 처음이라면 참가의 의의를 두고 수료를 목표로, 많은 시간을 투자해야 할 것 이다.

이상 phase 2 후기 마침

https://github.com/LGAimers4-hackathon/is_converted_hackerton/tree/main

GitHub - LGAimers4-hackathon/is_converted_hackerton: 영업전환예측모델 구현

영업전환예측모델 구현. Contribute to LGAimers4-hackathon/is_converted_hackerton development by creating an account on GitHub.

github.com