[빵그리의 오븐 추천시스템 구축기]4.상품 메타데이터 기반 유사상품 추천

이전 이야기

https://thrcle.tistory.com/8

[빵그리의 오븐 추천시스템 구축기]3.사용자 데이터 분석 기반 메인 홈화면 상품 추천

 

---

Intro

안녕하세요! 오니입니다.

앞선 포스팅에서 유저데이터 부족&콜드스타트 문제의 상황에서 추천시스템 구축을 위해 2가지 관점에서 나누었다고 언급하였는데요.

 

1. [메인 홈화면]사용자 분석을 통한 세그먼트별 인기상품 추천
2. [상품 상세페이지] 상품 메타데이터 기반 유사상품 추천

 

이번 포스팅에서는 이전 포스팅에 이어 상품 메타데이터 기반 유사상품 추천에 대해 다뤄보겠습니다.

---

우선 추천시스템에서 롱테일 현상은 사용자의 관심이 인기 아이템에 과하게 집중되는 것을 막고, 다양성을 고려해 드물게 소비되는 비인기 아이템까지 추천함으로써 사용자 만족도를 높이고 매출을 극대화하는 것을 의미합니다. 

 

 

추천시스템의 가장 단순한 접근이 바로 전체 사용자에게 인기가 많은 (조회, 찜, 구매 등등) 순으로 정렬하는 것인데요.

이렇게 접근하면 새로운 품목을 추가했을 때, 상위에 노출되지 못하는 아이템 콜드 스타트 문제가 발생합니다. 

따라서 유저 A가 아이템 B에 대한 찜버튼을 선택했을 때 유사도 기반 아이템을 추천해주는 방식을 고려하였습니다.

---

수집 및 사용 데이터

상품 관련 데이터의 경우 네이버 스마트 스토어의 데이터를 크롤링하여 사용하였습니다.

스마트스토어의 경우 상품 선택 후 옵션에서 맛 등을 선택할 수 있는 구조로 되어있어 상품의 단위를 설정해야했습니다.

상품 단위를 product_board, 맛별 옵션 정보를 product로 정의하여 테이블을 설계되었습니다. 

⭐️ 데이터가 수집된 방식에 따라, 추천 시스템 구현방식도 영향을 받습니다.
추천시스템 기획단계에서는 맛단위(product)까지 세분화된 수준으로 구현하려고 하였으나, 보통 상품 상세 페이지는 이미지를 첨부하는 경우가 많은데, 맛단위로 구분하여 데이터 수집이 어렵다는 한계가 있어 product_board단위로 추천하도록 설계하였습니다.

사용 데이터

• 수집한 상품데이터 210개의 크롤링한 데이터는 리뷰, 가격, 판매 스토어명, 상품명, 옵션 영양성분에 대한 데이터였고 수집 후 가공 과정을 거쳐 상품 카테고리(쿠키,케이크, 도넛 등), 태그(고단백, 비건) 정보를 추가하였습니다. 
• 수집과정에서의 어려웠던 부분은 바로 영양성분 정보였습니다. 마트, 편의점 등에 유통 및 판매하는 식재품과 달리 판매자가 직접 생산 및 판매하는 경우는 영양정보 고지 의무가 없어(‘식품위생법 시행령’ 제21조제2호) 영양성분 정보가 null값으로 수집되는 경우가 예상보다 많았습니다. 다만, 프로틴 함량 및 저당을 강조하는 경우는 함량 및 정보가 포함된 경우가 많아 태그 정보를 생성하는 것은 크게 문제되지 않았습니다. 

---

전처리 

전처리 방식의 경우 특수문자, Stopwords, 중복 단어를 제거해주었고, 품명/옵션명에서의 수량 및 계량 정보를 삭제 처리하였습니다.

 

---

모델링 과정

• 모델링 방식은 기본적인 TF-IDF, Word2vec을 시도하였습니다.

• word2vec 모델의 경우 푸드 도메인에 더 특화될 수 있도록 만개의 레시피 레시피 정보-조리법, 식물성 지향 식품회사 제품-설명, 빵그리의 오븐 등록 상품을 입력데이터로 활용하였습니다. 이때 문맥을 통해 각 토큰간의 유사도를 계산하였습니다.
• 품명 정보를 입력하였을 때 유사도가 높은 제품명 순으로 최종 3개를 출력하도록 하였습니다. 

---

모델 평가

• 모델을 평가하는 기준은 다양한 접근이 가능하지만, 사용한 기준은 1)coverage:전체 상품 중 추천된 아이템의 비중 2)내부 정성 평가로 진행하였습니다.
• coverage를 기준으로 전체적으로 약 80% 이상의 제품이 유사 상품 대상에 해당하였습니다.
• 정성평가의 기준의 경우 1.성분 기준(글루텐프리, 비건, 저당 등)으로 봤을 때 유사한가? 2) 맛과 빵 종류 기준(휘낭시에, 케이크 등)으로 봤을 때 유사한가? 에 대해 점수를 부여하는 방식으로 진행하였습니다. 

---

서비스 적용

• 마음에 드는 상품의 경우 '구매하러 가기' 버튼을 눌러 해당 판매 스토어로 이동하게 되는데, 테스트 과정에서 추천 상품을 눌러서 이동했을 때 품절로 인해 구매할 수 없는 경우가 있었습니다. 수제 디저트의 특성상 품절 여부를 확인하고, 품절된 경우를 제외하는 과정이 서비스적으로 필요하다고 판단하여 추천 하기 전 제외하는 로직을 적용하였습니다. 

스토리 보드

 

적용 화면

 

---

데모부스 시연

해당 프로젝트는 백엔드 개발자, 디자이너, 기획자, 머신러닝 엔지니어 등 여러 팀원분들과 함께 진행했던 뜻깊은 과정들이었습니다. 

11/23에 진행한 가짜연구소 grand gathering행사에 참여해 데모부스에서 시연 및 이벤트를 진행하며 지금까지의 과정에 대해 공유하는 시간을 가졌습니다.

 

 

---

마무리하며

 추천시스템에 대한 호기심으로부터 출발해서 1개월 스터디+1.5개월동안 실전 프로젝트를 진행하면서 많은 것을 느끼고 배운 시간이었습니다. 리더역할인 모임장으로서도, 추천시스템 모델링하는 입장에서도 계속해서 저의 현 상태를 객관화할 수있는 환경이었고 또 부족한 실력에 대한 항마력 테스트(?)를 하면서 내적인 스트레스를 많이 받기도 했던 시간이었습니다. 

 

이번 모임장을 맡으면서 가장 많이 느꼈던 부분은 커뮤니케이션 부분이었습니다. 사실 그동안은 커뮤니케이션 역량이라는 것이 '상대방의 의견을 존중하면서도 나의 의견을 잘 전달하는 것' 수준으로 생각하고 크게 '나의 이런 부분을 개선해봐야겠다'라고 느낄 만한 적이 없었는데, 이번 기회를 통해 저라는 사람이 모임장이 되었을 때 어떤 팀원이 고맙고 좋은지, 팀원은 어떤 모임장을 기대하는지에 대한 시야가 넓어졌습니다. 느낀 점을 정리해보자면 다음과 같습니다.

• 팀원들은 모임장이 사소한 부분(오프라인 모임에서의 식사 장소 추천 등)까지도 정해주는 것을 좋아한다. 
• 같이 회의를 통해 나눈 얘기라도 모임 전후로 안건정리를 해주는 것을 지향한다. 
• 주로 온라인으로 소통하는만큼, 모임장/팀장은 답장 및 작은 이모티콘 반응에도 생각보다 많은 힘을 얻는다. 
• 몇개월동안 같이 보며 프로젝트를 진행하는 상황이라면 rapo를 형성하는 것이 생각보다 중요하며, rapo형성에는 오프라인 모임이 효과적이다. 
• 서로 의견을 제안하는 자리에서, 의견을 말하기 전에 상대방의 의견 중 좋은 부분&동의하는 부분을 먼저 언급하고 자신의 의견을 말한다. 

추천 시스템 구현 관점에서는 

• 한정적인 데이터로 인해 다양한 모델 알고리즘을 적용해보지 못했다는 아쉬움은 남지만 모델시스템이 어떻게 실제 서비스에 적용되는지에 대한 과정 및 협업 프로세스를 배울 수 있었습니다. 
• 다음 추천 시스템 구현에서는 더 많은 리뷰데이터로부터 다양한 모델링 알고리즘 적용에 대한 경험을 쌓아볼 예정입니다.