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

알고리즘 | 정형 | 분류 | 시스템 | AUC

  • moneyIcon 상금 : 총 1,000만원
  • 2,008명 마감

 

문제 설계에 관하여 토론을 하고 싶은 부분이 있습니다.

2021.01.31 07:05 10,071 조회

코드 공유에 올라온 코드와, 대회안내 글, 데이터 설명에 관한 글을 읽고 직접 데이터 분석을 시작했는데, 뭔가 이질적인 부분(?)을 발견했습니다.

이 부분이 제가 잘못생각하고 있는 부분인지, 아니면 정말 오류인지 토론하고 싶어 글을 올리게 되었습니다.


제가 생각하기에 좀 이상한(?) 부분들은 크게 두가지 입니다.

(1) 미래의 에러 로그 데이터도 이용해서 과거의 고객 불만을 예측한다?("예측시점"에 관한 정보를 고려해서 데이터 제공을 해야 하지 않을까요?)

(2) 예측되는 기준이 되는 key값이 user_id 기준인데, 이 부분이 와닿지가(?) 않네요.


(1) 우선 첫번째, 예측 시점에 관한 문제점입니다.

합리적으로 생각을 해본다면, "시스템 데이터를 통해 사용자의 불편을 예지하기 위해"서는, 고객들의 불만이 접수된 "이전"의 데이터만을 이용해서 불만예측을 해야 합니다.

하지만, 주어진 데이터들을 보면 불만이 접수된 "이후"의 데이터에 대한 접근이 가능하고, 코드 공유 글들을 보면 그것들도 같이 이용해 예측을 하고 있는것 같습니다.

아직 다른 토론 글에서도 이부분을 언급하지 않은걸 보면, 많은 개발자들이 이 부분을 간과하고 있는것 같고 (사실 예측용 데이터에서는 이 부분에 대한 정보가 주어지지 않기 때문에 사실상 고려 할수도 없음), 주최측에서도 고려를 하지 않고 있는것 같네요.


하나의 예시를 보겠습니다.

train_problem_data.csv 데이터 중 user_id가 14311인 row를 보겠습니다.

이렇게 user_id와 time (불만이 접수된 시간이겠죠?)이 주어집니다.

time 칼럼을 보면, 2020-11-13 19:00:00 에 불편이 접수된걸 확인할수가 있습니다.


그럼, 같은 user_id (14311)를 가지고 train_err_data.csv를 보겠습니다.

이렇게, user_id 14311에 관련된 에러 로그들은 총 928개가 있고, 이 중 591개는 불만이 접수된 이후에 발생한 에러 로그들입니다.

이를 고려하지 않고 모두 인풋 변수들로 사용을 한다면, 제목 그대로 고객 불편 접수 이후에 발생한 "미래에 발생한 에러 로그들도" 이용을 해서 고객 불만을 예측하는 모습이 됩니다.


(혹시라도 설명이 부족할까봐) 다시 예시를 드린다면, user_id 14311가 가전제품 model_1과 model_2를 11/10일에 구입을 하였고, 계속적인 에러로 1/13일날 불편 접수를 했고, 현재 시점은 1/30일이라고 가정을 해본다면, 개발자들은 11/10 부터 1/30일 까지 모든 데이터를 가지고 11/14일 불편을 예측하는 격이 되는것 같습니다.


사실 이 부분이 실제 상황에서의 모델 성능에 얼마나 도움이 될지는 미지수 입니다.

하지만 보다 실제 상황과 가까운 세팅에서 예측 성능을 확인하기위해서는 이 부분이 고려되어야 하지 않을까 싶습니다.

결론적으로, 주최측에서 고객 불편 접수이후의 에러 로그들은 없애서 주던지, 아니면 개발자가 개별적으로 없애던지 해야 정확한 예측 모델이 만들어 질것 같습니다.


(2) 두번째는, 예측되는 기준이 user_id 인데, 좀 이상한것 같습니다.

앞의 예시를 보면 user_id 14311은 두가지 제품, 혹은 모델, 을 가지고 있습니다 (train_err_data.csv 만 보자면)

근데 고객 불편 접수 (train_problem_data.csv) 데이터를 보면, 이 user_id 14311이 model_1에 대한 불편접수인지, model_2에 대한 불편접수인지, 아님 둘다에 대한 불편 접수인지 알수가 없습니다.

실제 모델 개발을 하고 적용을 하려고 해도, 제품과 그의 펌웨어에 대한 다양한 로그 정보들을 가지고 "유저 A의 불편 접수 가능성"을 예측하는 것 보다, "유저 A가 제품 B에 대해서 불편을 접수할 가능성"을 예측하는게 더 논리적인(?) 부분이지 않을까 싶습니다.


예시를 들자면, user_id 14311이 model_2에 대해 불만이 있고, 불편 접수를 하였는데, model_1에 대한 에러 로그도 예측에 사용된 모습이어서 뭔가 찝찝하네요.


(이 부분은 제가 이쪽 사정을 잘 몰라 이렇게 생각하는 부분일수도 있습니다. 유저 단위로만 예측을 하는게 어느 부분에서는 더 나은 부분이 있어서 이렇게 문제 설계를 한것일수도 있을것 같네요 - 뭔가 유저 패턴이라던지, 소비자 패턴이라던지 등등. 다만 관계자가 아닌 3자로써는 이해가 안됩니다)


(3) 종합적으로 예시 시나리오는 짜본다면,

  • "user_id 14311은 model_1 제품을 2020년 11월 1일날 구입을 하였고, model_2 제품을 2020년 11월 14일날 구입을 하였습니다. 이 중 model_2가 사자마자 문제가 발생되어, user_id 14311은 2020년 11월 14일 model_2에 대한 불편을 접수를 했습니다."
  • 개발자들은 "시스템 데이터를 통해 사용자의 불편을 예지하기 위해 사용자 불편 예측모델을 만들고 있습니다. 이를 위해 모델의 학습에는 user_id 14311의 model_2 제품에 대한 2020년도 11월 14일의 불편접수기록도 사용됩니다. 예측모델이 앞서 언급된 불편접수 기록 발생한것을 학습하기 위해  2020년도 11월 1일 부터 2020년 11월 30일까지 user_id 14311이 model_1, model_2에 대한 모든 에러와 시스템 로그들을 이용하였습니다"
  • 뭔가 이질적이고 찝찝한부분,,, 혹시 아시겠나요?


"주어진 문제만 잘 해결하면 되지 괜히 왜 문제를 굳이 찾지?" 라고 생각하실수도 있는데 저는 개인적으로 이런게 괜히 너무 찝찝하네요 ㅎㅎ

그리고 계속 눈팅(?)만하다 어제 처음 데이터 분석을 한거라 저의 접근방식에 오류가 있을수도 있습니다.

혹시나 그렇다면 알려주시면 감사하겠습니다!


글 솜씨도 너무 부족한편이라 글도 엄청 길고, 말하고자 하는 부분도 중구난방인데, 읽어주셔서 감사합니다!

로그인이 필요합니다
0 / 1000
Coding is my life
2021.01.31 07:29

1번은 이전 토론에서 지적된 사항입니다. 세아아부지님이 올린 글이었던 거 같아요.

juhha
2021.01.31 07:38

댓글 읽고 찾아보니 있더군요 ㅎㅎ 이부분에 대해서는 데이콘이나 주최측에서 답글이 없는걸 보니 어쩔수 없이 진행을 해야 하는것 같네요.

Statistics
2021.01.31 15:47

제 생각으로, 데이터의 시점문제는 어떻게 해결할 수가 없습니다. 
일반적인 "해지/해촉/이탈/퇴사"의 문제에서는 "train데이터 기준은 1월 1일, target은 12월 31일 기준 해지한 사람"과 같이 명확하게 시점을 고정할 수 있습니다. 
그런데 이 불만제기 문제는 
 1. 한사람이 얼마든지 여러번 불만을 제기할 수 있고
 2. 가입 시점과 불만 제기 시점이 너무나 다양하며
 3. Target이 "Y"인 사람들에 대해서 불만제기 직전까지 데이터만 주어지면 그것이 일종의 leakage가 되어 "Y"를 쉽게 유추할 수 있기 때문에
어쩔 수 없이 한달 간 전체 시점의 전체 데이터를 제공한 것으로 보입니다.

그래서 모형의 성능과는 별개로 취지를 살리거나 더 나은 설명을 위해서 "예지"와 관련된 분석이나 시도를 많이 해보는 것이 중요할 것 같습니다. 

2)의 문제는 참가자의 몫으로 보입니다. 
참가자가 원한다면 user_id+model로 id를 더 세분화해서 문제를 해결하고, 예측할 때 복수의 model을 가지고 있는 사람은 각 model의 예측 확률의 최댓값을 최종 예측값으로 지정할 수 있을 것 같네요.

juhha
2021.02.01 14:09

아 앞서 댓글에서 세아아부지 님 글 읽고 비슷한 생각을 한 사람들이 있구나 했습니다 ㅎㅎ 이번 댓글도 좋은 지적입니다. 감사합니다 ^^