브런치 사용자를 위한 글 추천 대회 - 모델(1)

4. What is the Kakao Team Baseline ?

먼저, 우리팀의 베이스라인을 만들기 전에 주최측에서 만든 베이스라인을 확인하도록 하겠습니다.

 

README.md의 파일 내용을 읽어보면, 추천방식은 Rule-based기반2월1일부터 3월1일까지 가장 인기가 좋았던 글 100건을 추천하는 방식이고 과정은 아래와 같습니다.

 

  1. 학습데이터와 개발데이터를 나눔.

  2. 개발데이터에서 평가할 사용자 리스트를 추출.

  3. 학습데이터로 만든 모델을 통해서 2에서 뽑은 사용자의 평가점수를 매김.

  4. 모든데이터를 학습데이터로 사용해서 3000명의 제출 모델을 만듬.

결론적으로, 제출물의 경우 아래와 같이 모든 유저 3000명이 똑같은 추천 결과물을 가지게 됩니다.

-#user_1 @bakchacruz_34 @wo-motivator_133 @wo-motivator_133

-#user_2 @bakchacruz_34 @wo-motivator_133 @wo-motivator_133

-#user_3 @bakchacruz_34 @wo-motivator_133 @wo-motivator_133

-#user_4 @bakchacruz_34 @wo-motivator_133 @wo-motivator_133

MAP

NDCG

Entropy

0.017014

0.052218

4.605170

제출을 해보면 위와 같은 결과를 얻을 수 있고, NDCG에 비해서 MAP가 많이 낮고 동일한 값을 추천했기 때문에 Entropy가 많이 낮은 것을 알 수 있습니다.

 

문제점

 

  • user마다 추천하는 결과물이 똑같다

    • Entropy 측면에서 나쁘다.

    • 전체의 선호가 반영되지 개인의 선호는 반영되지 않는다.

  • 2월 1일 ~ 3월 1일까지 선정한 기준이 없다.

    • read와 평가기간이 겹치는 구간은 2월 22일~28일이고 2월 초보다 이떄의 읽은 정보가 더 중요할 수 있다.

    • 3월의 글을 추천하지 못한다. read에는 최대 2월까지의 정보만 있기때문에 3월에 작성된 글은 자연스럽게 제거될 수 밖에 없고, dev의 평가기간은 2월 22일부터 3월 14일로 14일동안의 읽은 정보가 빠지게 된다.

  • 이제까지 읽은 정보가 반영되지 않는다.

    • 사람들이 많이 읽은 글이라는것은 이미 읽었을 확률이 높고 위의 user가 그 글을 읽었으면, 그렇지 않은 글보다 또 읽을 확률이 적을 것이다.

  • 평가할 리스트를 뽑는게 모호하다.

    • README에 적혀있는대로, 주의 평가시 사용하게될 데이터와는 다르게 여기서 분할한 데이터에는 한 사용자가 본 데이터가 학습과 평가 데이터에 모두 등장할 수도 있습니다.

  • metadata, contents 및 다른 정보를 활용하지 않는다.

5. Make the our Baseline

먼저 4에서 발견한 문제점에서 해결하기 쉬운 것 부터 실험하면서 베이스라인을 만들어보았습니다.

 

  • 문제점1. 2월 1일 ~ 3월 1일까지 선정한 기준이 모호하다.

    • 기존 : 2월 1일 ~ 3월 1일 : 0.017014 / 0.052218 / 4.605170

    • 시도1. 2월 28일 : 0.021131 / 0.071307 / 4.577835

    • 시도2. 2월 22일 ~ 28일 : 0.025898 / 0.083142 / 4.662016

    • 시도3. 2월 14일 ~ 3월 1일 : 0.021779 / 0.065412 / 4.707867

    • 시도4. 1월 1일 ~ 3월 1일 : 0.018345 / 0.053224 / 4.797080

  • 문제점2. 이제까지 읽은 정보가 반영되지 않는다.

    • 해결. 이제까지 읽은 정보는 제거하고 추천하도록 한다.

      • 문제점2.1. 언제부터 언제까지 읽은 정보를 제거할 것인가?

      • 시도1. 2월 이후의 정보 : 정확도가 조금 상승 , 다양성이 조금 상승

      • 시도2. 1월 이후의 정보 : 정확도가 많이 상승, 다양성이 많이 상승

      • 시도3. 전체 기간의 정보 : 정확도, 다양성 모두 상승하지만 시도1, 2에 비해서는 나빠짐.

  • 문제점3. 개인의 선호가 반영되지 않는다.

    • 시도1. 개인의 선호도를 만들기.

      • 선호도1 : 작가별 글을 읽은 총 횟수.

      • 선호도2 : 작가별 읽은 글의 비율. (읽은 글 / 전체 글)

      • 선호도3 : 작가의 글을 읽은 총 날. (방문해서 읽은 횟수)

  • 문제점4. metadata 및 contents의 정보를 활용하지 않음.

    • 시도1. 글의 최신성을 반영하여 가중치를 만든다.

    • 시도2. 글의 주기성을 반영하여 다른 추천모델을 만든다. (위클리 매거진, 매거진)

    • 시도3. 구독의 여부에 따라 모델을 다르게 만든다.

  • 코드 

    아래의 3가지 파일이 초창기 대회 2주일안에 만들었던 파일들입니다. 

    • Popular_based: 기존의 베이스라인 코드를 토대로 조금 수정한 버전.

    • Following_based : 구독하는 작가의 글을 중점적으로 추천하도록 한 버전. 

    • Series_based : 글의 내용이 이어지면 연속해서 읽는 것을 반영한 버전.

Popular_based_Recommendation.zip
0.00MB
Following_based_Recommendation.zip
0.01MB
Series_based_Recommendation.zip
0.01MB

댓글(0)

Designed by JB FACTORY