이 영역을 누르면 첫 페이지로 이동
천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

페이지 맨 위로 올라가기

천천히 꾸준히 조용히

천천히 꾸준히 조용히.. i3months 블로그

[Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 3

  • 2026.05.09 17:54
  • Computer Science/Data Science
반응형

 

 

 

https://dacon.io/competitions/official/236690/data

 

제 5회 ETRI 휴먼이해 인공지능 논문경진대회 - DACON

분석시각화 대회 코드 공유 게시물은 내용 확인 후 좋아요(투표) 가능합니다.

dacon.io

 

 

 

 

 

이번에는 XGBoost를 적용해보자. LightGBM / CatBoost / XGBoost 모두 트리를 다루는 전략이 다름.

지금까지는 LightGBM과 CatBoost모델을 피쳐만 바꾸는 방식으로 사용했는데, 이번에는 XGBoost를 사용함.

 

5-Fold 알고리즘은 똑같이 쓴다.

알고리즘의 다양성을 키우면 노이즈를 더 줄일 수 있지 않을까.. 

 

 

 

 

 

일단 성능은 XGBoost가 가장 좋긴 함. 

그리고 제출했을 때 점수가 0.60807 으로 지금까지 결과물 중에서는 가장 좋았다. 

 

 

 


 

 

 

 

이후 여러 가지 가설을 세우고 모델도 바꾸고 다른 방식도 시도해봤는데 결과가 눈에 띄게 좋아지지는 않았음.

그런데 여기서 4가지 시도를 통해 성능을 좀 끌어올릴 수 있었다.

 

1. Adversarial Validation Reweight + Card P

Ensemble 방식 도입 후 진전이 없었다. 

CatBoost 추가하고 XGBoost도 붙이고 Random Seed 돌리고 KFold Split도 했지만 그 이상 진전이 없음.

 

데이터를 다시 들여다보니 두 가지 의심 가는 부분이 있다.

라벨 균형이 사람마다 다르니 모델 출력 뿐만 아니라 사람별로도 조절해 줘야 함. 그리고 Train과 Test의 분포가 다름을 고려해야 한다.

Train과 Test 데이터는 같은 10명이지만 날짜만 다른 것. 

그리고 사람마다 생활 패턴이 다르니 이 부분도 고려해야 한다는 것..

 

GBM은 사람별 baseline을 어느정도는 학습하지만 여러 센서 피쳐와 결합되면서 Tree Split이 센서 위주로 발생해 저 사람별 baseline이 묻힐 수 있음.

 

그러니 Adversarial Validation Reweight를 수행한다. -> Train Rows에 라벨 0, Test Rows에 라벨 1을 부여하고 학습.

잘 분류되는 Train Row는 Test와 다른 분포인거고, 잘 분류되지 않는 Train Row는 Test와 비슷한 Row.

학습에 사용하는 weight 식은 weight = 1 + α × av_score 로 설정한다. (Test와 비슷한 Train Row를 더 강하게 학습)

 

각 Train Row마다 AV 분류기가 출력한 Test일 확률을 av_score로 저장하고 본 모델을 학습할 때 사용한다.

저 수식대로 학습하면 모델이 Test 분포에 더 fit 하게 학습됨. α를 정하는 것도 너무 작으면 효과가 없으니 2정도로 설정.

 

AV로 Train 분포가 다른 문제는 다뤘지만 출력 단계에서 사람별 baseline을 반영하도록 설정해 줘야 한다.

그러니 여기서 Card P 를 도입한다. GBM 출력을 그대로 사용하지 않고, 각 사람의 Train 값 평균과 혼합함.

final = β × GBM_predict + (1-β) × subject_prior 

 

이러면 β가 1일때는 prior를 안 쓰고, β가 0이면 GBM을 아예 무시한다.

Task마다 GBM이 잘 처리하는 정도가 다르니 Task마다 β를 따로 학습시킨다. (Fold-Aware)

 

학습해보니 Q시리즈와 S1은 모두 β가 1으로 나왔고, S2 S3 S4는 각각 0.578 0.408 0.802 수준이였음. 

Q 시리즈는 셀프 피드백이라 그날그날 변동이 크다. 그러니 GBM이 센서 보고 맞추는게 더 합리적인듯..

S 시리즈는 정량적이라 prior를 섞는게 도움이 된다.

 

그래서 두 가지 방법을 적용해서 채점을 돌려보니 성능이 유의미하게 좋아짐 

0.6064 -> 0.6028 -> 0.6021 

 

 

 

 


 

 

 

 

AV Reweight와 Card P 를 적용해서 점수를 좀 깎은 후에 다른 방식을 정말 많이 시도했다.

Sleep Heuristic, Pseudo-Labeling, HRV Proxy, Mega-Ensemble, Monotone Constraints 등;;;; 

근데 하나도 안깎임. 근본적으로 뭔가 잘못된듯.

 

처음에 EDA 할 때 lag-k 분석을 진행했고, lag-1과 lag-7 피쳐를 추가하고 채점했더니 굉장히 안좋게 나왔음.. 

그래서 그 이후로 lag-k 피쳐 안 넣었는데.. 이게 문제인듯.

 

이전에 Train과 Test 분포가 Mismatch 되는 문제가 있어서 AV Reweight로 풀었음. 

Train과 Test 분포가 Mismatch 되면 당연히 lag-k 피쳐도 망가지는 것.. 

 

Train Row의 lag-1은 항상 채워지는데 Test Row의 lag-1은 NaN이 뜨는 경우가 많음.

모델이 Train Fold에서 lag-1이 채워진 패턴을 공부했는데 Test에서 NaN뜨니 성능이 개판임.

 

그러니 lag를 lag-1, lag-7 처럼 고정 날짜로 다루지 말고 가장 가까운 유효한 날짜로 수정한다.

추가로 날짜 간격도 함께 피쳐에 추가해서 이게 하루 전인지 일주일 전인지 모델이 함께 학습하도록 설정함.

처음에 자기상관관계가 있음을 확인하고 이 부분까지 함께 확인했어야 됐는데 아쉬운부분.. 

 

각 Row 에 대해서 lp_prev / lp_next / lp_dprev / lp_dnext 피쳐를 추가하니 총 28개의 피쳐가 추가됨.

Train Test 모두 Train 라벨에서 검색하니 Mismatch도 발생하지 않는다.

 

일단 28개 피쳐를 추가해서 다시 학습해보기 전에, 추가한 lp 피쳐가 라벨과 어떤 관계가 있는지 확인한다.

확인해보니 Q2 Q3 Q1 S3 모두 0.3 언저리.. 자기상관 신호가 센서 신호보다 더 강하다는 것.

그러니 피쳐를 적용하면 무조건 깎을듯.. 적용해보니 잘 깎이긴 한다.

 

lp 피쳐를 한 번만 계산하면 Train 라벨 풀에는 모든 Train Row가 들어간다.

5-fold CV에서 fold 3이 Valid로 설정됐다고 하자. 여기서 fold 3의 다른 Row가 잡힐 수 있음.

즉, 2일의 lp_next가 3일을 바라보지만 3일이 valid set 일 수 있다는 것. 이러면 당연히 잘 맞추지.. 답지 보고 맞추는건데..

그러니 이걸 막으려면 Fold 마다 lp 피쳐를 다시 계산하는 방식으로 학습해야 함.

 

일단 lp 피쳐 넣으면 성능이 오르는건 맞는데, GBM이 이걸 외운건지 아니면 진짜 신호로 판단한건지 확인해야 한다.

Smooth Label intERPolation 을 수행해보자. GBM 자체를 빼고 가까운 Train Day 라벨을 평균내는 것. 

 

weight = exp(-거리² / (2 × σ²)) 계산식으로 가중치를 부여한다.

σ가 2일때 가중치를 계산해보니.. 가까운 날일수록 가중치가 크고 멀어질수록 빠르게 0으로 수렴함.

즉, σ가 작으면 어제나 이틀 전만 보고 σ가 크면 2주 평균을 낸다는 것. 그러니 각 Task마다 어떤 σ가 좋을지 탐색해서 최적값을 찾는다.

 

그리고 이 탐색 결과 자체가 Task 구조를 담게 된다. Q1은 어제 위주로 보고.. Q2는 단기이고.. S3은 중기.. 이런식으로.

그런데 사실 SLERP는 lp 피쳐가 제대로 작동하는지 확인하기 위해서만 쓴건데, 이 SLERP 를 아까 다뤘던 Adversarial Validation Reweight + Card P 모델과 함께 사용해보니 성능이 좀 잘 나온다. 

 

즉, SLERP가 GBM이 못 잡는 정보를 가지고 있는 것.. 

 

그리니 최종본으로 AV + Card P + lp 피쳐 + SLERP 이걸 다 합쳐서 모델을 구축하자.

이걸 기반으로 채점해보니 0.5923 으로 한번에 성능을 많이 깎음.

 

핵심은 센서 데이터를 얼마나 잘 다루는지가 아니라 자기상관을 얼마나 잘 다루는지 였던것.. 

 

 

 


 

 

 

여기서 좀 더 깎아보자.

 

lp 피쳐는 각 Row에서 가까운 유효한 라벨을 가져오는데, 라벨은 Train Row에만 있다.

Test Row가 사이에 끼어있으면 Train Day가 며칠씩 떨어진 경우가 많음.

 

이미 AV + Card P + lp + SLERP 모델에서 Test에 대한 예측을 가지고 있는데.. 이러면 이 예측을 lp가 검색하는 라벨 풀에 Pseudo Label로 추가한다면? -> 며칠씩 떨어진 정도를 최대한 줄일 수 있다.

 

이전에 Pseudo-Labeling을 시도했다가 망했는데, 이전까지는 Pseudo 라벨을 Train 데이터에 넣고 추가 Row에 넣은게 문제.

저러면 Train 분포가 오염되지만 이번에는 Train 데이터는 그대로 두고 lp 검색 풀에만 Pseudo-Label을 추가한다.

직접 돌려보니 자기상관이 강한 Q 시리즈에서 성능이 최적화됐다.

 

추가로 기존 lp 피쳐는 prev와 next를 1개씩만 가져오는데, 가까운 이웃 n개씩 가져오도록 하자.

이러면 피쳐 개수와 Pseudo-Label 도 늘어나지만 성능은 더 좋아진다.

 

이제 지금까지 수집한 정보를 총합해서 모델을 구축해보자.

 

AV + Card P + lp 피쳐 + SLERP + Pseudo-Labeling + Neighboring

각각 OOF가 다 다르고, 데이터를 보는 방식이 다르니 모두 합치면 시너지가 있을 것.

 

 

 

 

 

가중치를 12개로 묶어서 학습했을 때 성능이 가장 좋았다.

 

 

 

 

 

 

 

반응형
저작자표시 (새창열림)

'Computer Science > Data Science' 카테고리의 다른 글

[Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 2  (0) 2026.05.05
[Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 1  (0) 2026.05.04
[Data Science] Data Preprocessing & Feature Engineering  (0) 2026.04.14
[Data Science] Statistical Data Analysis  (0) 2026.04.09
[Data Science] Data Acquisition and Visualization  (0) 2026.03.28

댓글

이 글 공유하기

  • 구독하기

    구독하기

  • 카카오톡

    카카오톡

  • 라인

    라인

  • 트위터

    트위터

  • Facebook

    Facebook

  • 카카오스토리

    카카오스토리

  • 밴드

    밴드

  • 네이버 블로그

    네이버 블로그

  • Pocket

    Pocket

  • Evernote

    Evernote

다른 글

  • [Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 2

    [Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 2

    2026.05.05
  • [Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 1

    [Data Science] ETRI 휴먼이해 인공지능 논문경진대회 - 1

    2026.05.04
  • [Data Science] Data Preprocessing & Feature Engineering

    [Data Science] Data Preprocessing & Feature Engineering

    2026.04.14
  • [Data Science] Statistical Data Analysis

    [Data Science] Statistical Data Analysis

    2026.04.09
다른 글 더 둘러보기

정보

천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

  • 천천히 꾸준히 조용히의 첫 페이지로 이동

검색

방문자

  • 전체 방문자
  • 오늘
  • 어제

카테고리

  • 분류 전체보기 (695) N
    • Algorithm (205)
      • Data Structure (5)
      • Theory && Tip (33)
      • Baekjoon (166)
      • ALGOSPOT (1)
    • Spring (123)
      • Spring (28)
      • Spring Web MVC (20)
      • Spring Database (14)
      • Spring Boot (6)
      • Spring 3.1 (11)
      • Spring Batch (6)
      • Spring Security (16)
      • JPA (12)
      • Spring Data JPA (5)
      • QueryDSL (4)
      • eGovFramework (1)
    • Programming Language (74)
      • C (25)
      • C++ (12)
      • Java (19)
      • JavaScript (15)
      • Python (1)
      • PHP (2)
    • Computer Science (154) N
      • Machine Learning (38)
      • Operating System (18)
      • Computer Network (28)
      • System Programming (22)
      • Universial Programming Lang.. (8)
      • Data Science (8)
      • Embedded Software (4) N
      • Computer Architecture (4)
      • Compiler Design (11)
      • Computer Security (13)
      • BlockChain (0)
    • Database (21)
      • Database (7)
      • MySQL (3)
      • Oracle (3)
      • Redis (5)
      • Elasticsearch (3)
    • DevOps (20)
      • Docker && Kubernetes (8)
      • Jenkins (4)
      • Amazon Web Service (8)
    • Mobile (28)
      • Android (21)
      • Flutter (7)
    • 💡 솔루션 (17)
    • 👥 모각코 (12)
    • 💬 기록 (9)
    • 📚 공부 (7)
    • -------------- (25)

최근 글

나의 외부 링크

메뉴

  • 홈
반응형

정보

i3months의 천천히 꾸준히 조용히

천천히 꾸준히 조용히

i3months

블로그 구독하기

  • 구독하기
  • RSS 피드

티스토리

  • 티스토리 홈
  • 이 블로그 관리하기
  • 글쓰기
Powered by Tistory / AXZ. Copyright © i3months.

티스토리툴바