[BoostCamp AI Tech / P Stage 2] Day50 - Project Day 10

P Stage 2 : Project Day 10

---

Day 10 list

1. inference code 수정

---

Day 6, 7, 8, 9

안타깝게도…. 코로나19 양성으로 이번주 일정이 다 날라갔습니다. ㅠㅠ
백신 3차를 안 맞아서인지 아니면 그냥 병 자체를 독하게 걸린건지… 감염 5일차인 오늘까지도 큰 회복이 이뤄지진 않고 이번주 내내 잠만 잔 거 같습니다.
대회 2주차 마지막인 10일차인 오늘은 좀 컨디션이 좋아져서 팀원들과 회의를 진행했습니다.
팀원들 토의에서 핵심적인 요소는 bn.argpartition이었습니다.

---

inference code 수정

• 다른 팀들은 동일한 Multi-VAE를 썼는데도 0.14대의 Recaal@10을 기록하고 있는 것이 뭔가 이상했음
• 피어세션 회의에서 bottleneck.argpartition에 대한 의문이 제기됨
• np.argsort로 변경해서 inference하는 것을 제안함

• 수정부분

    # 변경 전
    idx = bn.argpartition(-output, k, axis=1)
    # 변경 후
    idx = np.argsort(-output, axis=1)
  

• 실제로 Recall@10 0.1258 -> 0.1386으로 향상

사후분석

이 argpartition 때문에 문제가 발생한 것이라 왜 이런 문제가 발생했는가? 를 분석했습니다. np.argsort는 결과를 알고 있어서 bottleneck 공식문서의 argpartition을 확인했고 간단한 10개짜리 np.array로 실험도 진행했습니다. 문제는 두 결과의 차이는 없었고 차이라면 부분 정렬이냐 아니냐 였습니다.

문제는 이 사소한 차이때문에 발생했었습니다…;;

저희가 수행한 inference 로직은 다음과 같았습니다.

1. Multi-VAE output을 bn.argpartition(-output, 10, axis=1)로 상위 10개 index sort 진행
2. item을 다시 원본 아이템 번호로 decoding
3. 유저의 이미 시청 아이템이 있으면 제외하고 10개를 추천 리스트에 포함

문제는 여기서 1번과 3번 과정의 통합적인 부분에서 발생했습니다. 이해를 돕고자 예시로 설명하겠습니다.

만약에 밑에 argpartition으로 처리된 index에서 40과 33 아이템이 user가 interaction한 아이템인 경우 차순위인 17과 30을 처리하게됩니다. 이렇게 될 경우 실제 차순위 아이템인 30과 20이 아닌 30과 17이 들어오므로 Recall에 영향을 주게됩니다.
즉 부분 정렬을 해주는 argpartition 특성상 k번째 이후는 score에 따른 순서가 보장되지 못한다는 문제가 있었습니다.
따라서 np.argsort로 수정한 후 성능이 향상하는 것을 확인할 수 있었습니다.