신입 리서치 엔지니어의 개인화 콘텐츠 추천 모델 구현기
안녕하십니까, TVING Data Engineer 팀의 Research Engineer 주찬형이라고 합니다.
저는 이곳에 와서 AI 기술 기반의 추천 시스템 연구 및 개발 업무에 임하게 되었습니다.
입사 이후로 1년도 지나지 않은 시간이지만, 아래 소개된 point들 위주로 고찰이 담긴 저의 이야기를 전달해드리려 합니다.
- 리서치 엔지니어로서 나는 어떻게 회사에 기여할 수 있을까?
- “문제 해결”에 대한 효율적이고 바람직한 자세는 무엇으로 정의할 수 있을까?
다소 함축적으로 표현된 이 두가지 포인트는 이 글이 끝나더라도, 그 대답들에 대해서 현재진행형으로 가져가고 싶은 저의 고민입니다. 제가 판단하기에, 향후 경험이 적절히 쌓인 시니어가 된다면 이러한 질문에 명확한 대답을 할 수 있는 사람이 될 수 있다면 좋겠다고 생각했기 때문입니다.
글을 남기는 것은 정보 전달 뿐만 아니라 여러 사람들의 생각을 주고받을 수 있는 소통의 장을 만드는 멋진 일이라고 생각합니다. 저의 고민을 여러분들과 나눠, 서로가 성장할 수 있는 질문을 감히 제기할 수 있다면 제 목적은 달성했다 라고 말씀드릴 수 있겠습니다. 이를 통해 여러분들의 다양한 생각들을 저 또한 경험할 수 있길 바랍니다.
우리가 각자 맡고 있는 포지션
대학교 재학 당시, 저는 교수 지도하에 연구활동 경험을 쌓았습니다. 어느정도의 연구 결과가 나오고 나서는 논문과 발표 자료 등을 준비하는 과정에 진입했는데, 인생 첫 논문을 작성하는데 어려움을 겪던 저에게 교수님은 돌발적인 질문(?)을 했었습니다.
엘리베이터를 탔는데, 모르는 할아버지랑 단둘이 타게 됐다고 치자. 그 할아버지가 내리기 전에 너가 쓴 논문 내용을 이해시켜야 한다면 어떤 식으로 설명할 수 있겠나?
그 할아버지가 내리기 전에 제가 먼저 내려서 도망가는 방법이 먼저 떠오를 정도로 말문이 턱 막히는 질문이었습니다. 연구 분야에 일반적으로 요구되는 전문적인 전공 지식이 없는 청자에게 제가 작성한 논문에서 주장하는 논리를 납득시키는 일은 굉장히 어렵게 느껴지는 일이라 생각합니다.
하나의 상황 가정이긴 했으나, 명확하고 간결한 표현을 통해 각자의 의견을 주고 받는 것은 효율적인 커뮤니케이션의 주요한 요인으로 작용할 수 있다는 것이 핵심이라고 느꼈습니다.
현대에 이르러 IT 시장의 수요가 늘어남에 따라, 우리의 직무도 그만큼 다양화, 세분화되고 있습니다. 다양한 블럭 조각으로 만들어낼 수 있는 product, project의 범위가 더욱 유동적으로 변할 수 있는 경향 또한 자연스럽게 인과관계를 막론하고 수요자와 공급자 모두 상호 작용하고 있다고 생각합니다.
이처럼 다양해지는 IT 포지션의 생태계에서, 팀을 갖춰 프로젝트를 진행할 때 우리는 서로 할 수 있는 일, 해야하는 일에 대해서 명확해질 필요가 있을 것입니다.
제가 리서치 엔지니어라는 포지션에서, 팀과 회사에 어떤 식으로 기여할 수 있을까요?
그러한 이해를 바탕으로, 여러분들은 자신이 어떤 일을 하는 사람인지 명확한 소개가 가능하신가요?
리서치 엔지니어는 무슨 일을 하는 사람인가?
신입으로서, 저는 저 자신에 대해 위 질문에 가장 먼저 대답을 얻고 싶었습니다. 제가 할 일을 명확히 안다면, 팀원들에게 협업하기에 좋은 직원이 될 수 있을 것이며, 저 자신 또한 일을 잘하려면 어떤 쪽으로 계발해나가야 할까 알 수 있을 것이라 생각이 들었기 때문입니다.
https://www.indeed.com/career-advice/finding-a-job/research-engineers
구글에 “what is research engineer”라고 검색하면 바로 찾을 수 있는 문서입니다. 궁금하면 알아서 찾아봐라는 의도로 당황하셨을거라 생각합니다만, 그런 의도가 아니라 흔히 이렇게 알려져있는 리서치 엔지니어 직무에 대한 일반적인 이해를 바탕으로, 궁극적으로는 리서치 엔지니어로서 저만의 정체성을 고민하고 싶었습니다.
위 문서 내용을 참고하여, 일반적인 리서치 엔지니어에 대한 이해는 특정 기업, 산업이 갖고있는 문제에 대해 연구 및 개발을 통해 기술적으로 기여하는 직무를 수행하는 사람으로 정의가능할 것 같습니다.
개인적으로는, “논문 읽고 기술 구현해서 개발하는 사람”으로 받아들이는게 편하지 않을까 생각합니다.
“논문 읽고”라는 부분이 일반 엔지니어와 리서치 엔지니어의 실질적인 차이라고 생각하며, 논문을 읽고 쓰는 역량이 비교적 활성화된 그들은 종사하고 있는 분야의 연구 커뮤니티와 활발히 교류할 수 있고 자연스럽게 어떤 기술이 자신이 풀고자 하는 문제에 적용가능한지 폭넓은 insight를 제공 및 판단할 수 있을 것이라 생각합니다.
(리서치 엔지니어가 아니면 논문 읽는 능력이 떨어진다 라고 말씀드리는 것은 아닙니다! ^_^;;;;)
저는 컴퓨터 공학과 AI 역량을 가지고 있고, 주로 풀고자 하는 문제는 추천 시스템 개발 및 고도화에 해당하기 때문에 “추천 AI Research Engineer”로 구체적으로 표현할 수 있을 것 같습니다.
같은 추천 분야라도 리서치는 꽤 폭넓게 시도될 수 있는데, 이런 직무를 맡은 이상,
저는 연구의 방향성을 “최신 추천 분야의 연구 동향 및 어마무시한 성능을 낼 수 있는 SOTA 모델 구현”이 아닌 “현재 티빙에서 사용할 수 있는 자원들을 고려했을 때, AI 기술을 통해 개선할 수 있는 점을 연구하기”
로 잡아야 한다고 생각했습니다.
연구하고자는 분야를 좁힐 수록 저와 비슷한 고민을 하는 사람들과 더 빨리 만날 수 있습니다. 맹목적으로 최신 연구를 접하는 것보다, 풀고자 하는 문제나 분야의 범위를 먼저 줄여나가고, 좁혀진 영역에 최신 연구 리서치를 진행하면 논문의 Introduction에서 저자가 푸념(?)하는 부분에서 어마어마한 동질감을 느낄 수 있습니다( ‘너두 그랬어? 나두 ㅠㅠㅠㅠ 흑흑’ 과 같은 감정 ).
즉, 나와 비슷한 고민을 하는 연구 집단을 빠르게 만나야 회사에 최적의 솔루션을 제안하는 과정의 스타트를 끊을 수 있겠다고 생각했으며, 저는 입사 후 “TVING의 현 추천 시스템” 분석을 가장 먼저 시작했습니다. 제가 풀고자 하는 문제를 명확하게 하는데는, “현황”을 면밀히 살펴보는 것이 중요할 것입니다.
저의 연구 실력을 뽐내는 것이 아닌, 나를 고용해준 기업이 겪는 문제를 똑바로 해결할 수 있어야 하는 것이 제 직무라고 생각했기 때문입니다.
정리하면, 리서치 엔지니어로서 제 직무를 수행하는데 있어서 다음 로직의 사이클을 설계할 수 있겠다고 생각했습니다.
- 현황 파악하기
- 풀고자 하는 문제를 명확히 하기
- 어떻게 개선할 수 있을지 리서치 진행하기
- 여러 방법론들 중 1번에서 파악한 환경에 효율적으로 기능할 수 있을 안을 구성하기
- 구현 및 실험 통해 결과 검증하기
- 인사이트 공유
리서치 엔지니어 앞에 “추천 AI”가 붙었으니 문제 인식과 해결 방법을 찾는 2,3번에 AI 분야와 추천 도메인의 자료들을 리서치를 진행하겠지만, 그런 기술적인 부분은 우리가 해결하고자 할 문제에 대해서 유동적으로 변화할 필요가 있고 최적화된 방법론을 고르는데 있어 그 기술적인 시야는 넓어져야 할 것 입니다. 따라서 위 로직은 사용하는 기술만 달라질 뿐, 저 자신에게 일반화된 사이클로 기능할 수 있을 것이라 생각합니다.
나의 Task, 추천
사용자가 특정 서비스를 사용하는데 있어, 소비하는 대상을 “아이템”이라고 표현합시다.
옷 쇼핑 사이트를 사용한다면, 사용자가 구매하고자 하는 옷이 곧 아이템이 될 수 있습니다.
음악, 영화 감상 서비스라면, 말 그대로 음악이나 영화가 아이템이 됩니다.
추천은 요구사항에 따라 다양한 형태로 제공될 수 있습니다.
현재 조회하고 있는 아이템과 비슷한 다른 아이템을 추천해준다거나, 같이 구매하기 좋은 다른 종류의 아이템을 추천해주는 기능도 생각해볼 수 있습니다.
또한 복수의 아이템을 추천 결과 리스트로 구성하여 노출하거나, 소수의 아이템을 팝업 형태로 노출한다거나, UI 요소와 같이 고민해볼 수 있습니다.
높음 품질의 추천 시스템은 이와 같이 잠재적인 선호도가 높다고 판단되는 아이템을 추천해줌으로써, 사용자가 직접 소비하고자 하는 아이템을 서칭해야 하는 비용을 절약해줄 수 있으며, 보다 다양한 아이템 풀의 소비 범위를 제공하여 사용자의 만족도를 높일 수 있는 기대효과를 가집니다.
즉, 추천시스템의 목적은 소비할 만한 아이템을 추천해줌으로써 사용자 경험을 개선시키는 것입니다.
한편, 이 아이템을 사용자의 개인적인 취향에 맞게 추천해주는 시스템을, “개인화 추천 시스템”이라 불리고 있습니다.
일반적으로 개인화 추천 기능을 구현하기 위해, 기존의 추천시스템에 Personalized Ranking 알고리즘을 도입합니다.
personalized ranking 알고리즘은 **“개개인이 해당 아이템에 얼마나 선호하는가”**를 나타낼 수 있는 데이터를 기반으로 적용가능하며, 평점과 같이 명시적으로 사용자의 선호도를 파악가능한 것을 explicit feedback data이라 합니다.
이와 반대로 유저 클릭, 로그 등으로 간접적, 암묵적으로 선호도를 근사할 수 있게 구성된 데이터는 implicit feedback data라고 합니다. 유저가 특정 아이템을 조회하는 시간이 비교적 다른 아이템보다 긴 시간으로 기록된 로그가 있다면, 암묵적으로 선호도가 높다고 가정하는 등의 데이터 설계가 가능합니다.
직관적으로, 선호도를 직접적으로 표현한 평점 데이터를 활용한 최적화 알고리즘을 설계한다면, 위와 같이 사용자가 아직 평점을 매기지 않은 아이템에 평점을 예측하는 것을 목표로 할 수 있습니다.
그렇지만, explicit feedback data로만 구성된 알고리즘의 설계는 크게 두 가지의 이유로 지양됩니다.
- Real-world scenario에서는 explicit feedback data의 수집 비용이 훨씬 높을 수 있다. 대부분의 feedback은 explicit이라기 보다는 implicit에 가깝다. (우리는 우리가 본 모든 영화에 엄격한 자기 자신만의 기준으로 수치화하려 노력하지는 않는다.)
- 특정 유저가 접하지 않은 아이템 혹은 평점이 매겨지지 않은 아이템은 유저가 실제로 싫어하는 아이템이라고 항상 말할 수 없다.
이에 따라 현실적인 추천 시스템을 위해서는, implicit feedback data로부터 유저의 실제 만족도, 선호도를 추출할 수 있게 엔지니어링하고, 선호도에 따라 랭킹을 매겨 리스트 형태로 아이템을 output으로 내보낼 수 있게 시스템을 설계하는 것입니다.
아이템마다 매겨진 유저의 선호도를 personalized rank의 정답으로 구성한 데이터셋을 가지고 새로운 아이템에 rank를 예측하게 하는 것은 통계/확률론 관점에서 회귀나 분류 문제로 치환가능할 것입니다. 이는 곧 ML/DL과 같은 AI 알고리즘을 사용할 수 있다는 의미입니다.
아래는 point-wise learning을 일반화한 식인데, 아이템마다 학습을 진행하여 점 단위의 오차를 기반으로 학습을 진행한다고 볼 수 있습니다.
아이템의 집합을 D로 표현하고, 그 원소를 di라고 표현한다면, 추천시스템이 예측한 i번째 아이템의 rank를 fθ(di)라고 표현한다면, 실제 정답에 해당하는 y(di)와의 차이를 오차로 정의하여 최적화를 진행할 수 있을 것입니다.
이러한 basis idea를 가지고 개인화 추천 시스템을 설계하는데 데이터 기반의 학습 및 최적화 알고리즘은 다양한 연구가 진행되고 있습니다.
가장 먼저 한 일, 현황 파악
현황을 파악하는 것은 연구를 통해 개선할 수 있을 점을 찾는 일이기에 현 문제점을 찾는 일이 됩니다.
( 어떻게 보면 회사에 들어가서 가장 먼저한 일이 자신을 뽑아준 회사 비판하기가 되어 꽤 용기가 필요할 듯 싶습니다. 하지만 TVING은 저의 비판을 올바르게 받아들여 줍니다. 쿨하고 멋진 회사. )
먼저, 데이터와 알고리즘 관점으로 현황을 분석하고자 했습니다. AI 기반의 시스템 설계에 앞서, 고품질의 데이터셋과 통계/확률론을 기반으로 한 고도화된 알고리즘은 동시에 높은 우선순위로 고려되어야할 점으로 보았기 때문입니다.
우리가 현재 사용할 수 있었던 데이터는 크게 두 개 정도로 설명 가능합니다.
- 메타 데이터 : 영화를 예로, 출연진, 감독, 장르, 시놉시스 등.
- 로그 데이터 : 실시간으로 수집되는 유저의 interaction 로그 데이터. 예를 들어, 콘텐츠 시청 시간, 접근 경로, 구동 디바이스 환경, 계정 및 이용권 정보 등.
그에 상응하여 알고리즘 또한 사용되고 있었습니다.
- 유사한 아이템 추천 — Item Vectorization
- 유저가 좋아할 만한 아이템 — User Vectorization
Vectorization은 어떤 정보를 특정 공간에 mapping함으로써 벡터 기반의 연산이 가능하게 할 뿐만 아니라 learnable parameter로 머신, 딥러닝 알고리즘의 주 연산 대상이 될 수 있게 합니다.
현 추천 알고리즘은 각각 메타 데이터로 구성한 아이템 프로필 벡터, 로그 데이터로부터 구성한 유저 프로필 벡터를 기반으로 유사도 계산을 통해 구현된 것으로 파악했습니다.
뭐가 문제인지 어떻게 알아야 할까?
논문의 흔히 ‘Problem Statement’ 섹션으로 소개되는 부분을 떠올릴 수 있습니다. 같은 분야, 관심사라도 사람마다 무엇을 문제로 정의할 지는 다릅니다. 그렇다고 문제라고 느끼는 근거를 감정으로 받아들이라는 것은 당연히 아닙니다. 철저하게 객관적인 근거들을 스스로 찾아내서 이것은 풀어야하는, 풀만한 가치가 있는 문제라고 모두를 납득시킬 수 있다면 바람직한 문제 정의라고 생각합니다.
위와 같은 저의 소신에 따라서, 파악한 현황으로부터 어떤 것이 개선할만한 문제가 될 수 있을지 고민했고 그에 따라 가장 먼저 한 것은 사용된 알고리즘에 대해 치밀하게 공부하기 입니다.
기존 알고리즘보다 최신 알고리즘, 또는 해당 task에 적합한 SOTA 모델을 도입해보는 것이 당장의 성능을 개선할 수 있는 접근방법이 될 수는 있겠으나 이러한 방법은 적합하지 않다고 판단합니다.
그 이유는 다음과 같습니다.
- SOTA는 해당 분야에서 일반적인 성능을 자랑하는 것이지, 우리가 풀고자 하는 문제에 specific 하게 최적화된 방법론은 아니다.
- SOTA는 일반적으로 여러 연구들이 공동으로 사용하는 데이터셋 기준으로 성능을 비교하여 최고 성능을 기록한 것이다. 본인이 사용하는 데이터셋의 분포는 공공 데이터셋과 상당히 다를 것이다.
즉, SOTA를 비롯한 특정 방법론을 선택하는 것이 디테일한 문제 정의보다 먼저 진행되는 것은 말이 되지 않다고 다소 과감하게 표현하고 싶습니다.
그렇다고 사용된 알고리즘을 공부하는 것은 다소 느긋한 일이 아닐까 생각할 수 있습니다.
하지만 이 과정을 거치면 기존 알고리즘의 input, output의 구조를 파악할 수 있고 그는 곧 우리가 추구하는 task에서 일반적으로 요구하는 알고리즘의 작동방식을 알아낼 수 있습니다.
이미지 내 main object를 분류하는 CNN 알고리즘에서 input이 이미지의 픽셀 데이터이고 output이 0과 1사이의 스칼라 값으로 나오는 것으로 구성되는 로직은 갑자기 번뜩 탄생한 것은 아닐 것입니다.
input, output의 구조를 파악하는 것은 보다 고품질의 데이터셋 구성을 설계하는데 좋은 Insight를 제공하며, 알고리즘의 작동방식을 면밀히 이해하는 것은 보다 고도화된 알고리즘을 선택하는 기준 그리고 적합하게 customize 할 수 있는 능력에 도움을 준다고 생각합니다.
풀고자 하는 문제와 적절한 해결책 찾기
현 데이터, 알고리즘에 대한 충분한 이론 파악과 현 구현과정을 면밀히 파악한 결론은 다음과 같습니다.
- 메타 데이터의 feature 중 ‘장르’ 부분에 성능이 상당히 편중됐다. 메타가 아이템을 구분하는데 있어 더 디테일하게 구성가능할 수록, vectorization 기반의 고차원의 공간에서의 연산, 유사도 계산이 적절하게 이뤄져 자연스럽게 세분화된 추천 성능으로 이어지며 직관적으로 보다 높은 user satisfaction을 보장한다.
— > ‘시놉시스’나 ‘작품 태그’ 와 같이 콘텐츠에 대해 더욱 다양, 세밀하게 표현하는 메타를 활용할 수 있으나 현 데이터 파악 결과, 해당 데이터는 심각한 noise, sparsity를 갖고 있어 실질적으로 알고리즘의 input으로 사용 불가능하다.
- 유저 로그 데이터는 implicit feedback data이며, unobserved item을 유저가 선호하지 않은 샘플로 분류해 데이터를 구성하는 것은 학습에 적절한 레이블링이 아니다. 반대로, 유저와 interaction된 아이템을 선호하는 아이템으로 구성하는 것 또한 마찬가지다.
— > implicit feedback dataset을 사용해 개인화된 추천 task를 이뤄내기 위해서 user actual satisfaction을 represent하기 위한 데이터셋 재구성 그리고 latent-factor model 기반의 알고리즘의 사용이 권장된다.
이러한 확인 이후, 저의 본격적인 직무 수행은 이 중 후자의 문제에 해당하는
“고도화된 개인화 추천 모델 연구 및 개발”에 초점이 맞춰지게 됐습니다.
유저의 시청 이력을 input, 가장 좋아할만한 아이템을 output 으로 구성 가능한 알고리즘
추천 시스템에 대한 연구나 개발은 정말 다양하게 이뤄질 수 있지만, 저만의 로직을 통해 수많은 접근 방법 중
‘현 데이터셋으로 구성가능한 새로운 알고리즘 도입’ 이 해결책을 찾는 리서치의 방향성으로 설정됐습니다.
현 데이터셋은 Implicit feedback data, 새로운 알고리즘은 personalized recommendation, ranking algorithm 이라는 키워드로 치환 가능했으며, 보다 구체적인 리서치가 가능했습니다.
이렇게 좁혀진 리서치 범위에서는 저는 이제서야 최신 연구부터 찾아보는 편입니다.
특히, 위 사진으로 설명되는 Related Work와 같은 섹션을 살펴봅니다. 최신 연구의 related work 섹션을 살펴보면, 그들이 제안하는 방법론이 현 연구 동향에서 어떤 positioning이 가능한지, 어떤 학술적인 contribution을 이뤄내려 하는지 알 수 있습니다.
자연스럽게 그들과 내가 일치한 관심사에서 발생해왔던 정반합의 역사를 엿볼 수 있으며, 그 긴 역사에서의 최신 방법론이기 때문에 제가 해결하고싶은 문제에 대한 최신 해결책으로 대응 가능하다고 생각합니다. ( 항상 대응하는 것은 아니나 적어도 이 related work에서 소개되는 다른 레퍼런스를 또 기호선택하면 효율적인 리서치가 진행될 수 있다고 느낍니다. )
저는 paperswithcode(https://paperswithcode.com/)이란 사이트를 적극 활용했습니다. 논문 저자가 직접 구현한 코드를 같이 쉽게 확인 가능한 점이 주로 사용하는 이유로 뽑을 수 있습니다.
논문이나 특정 레퍼런스를 기반으로 대상을 구현하는 것은 리서치 엔지니어가 리서치를 실질적인 결과물로 만드는데 아주 중요하면서 기본적인 역량입니다. 연구가 활발히 이뤄지는 분야인 만큼 이러한 구현 결과를 공유하는데 적극적이여야 하며, 실제로 논문에서 주장한 수식이나 모델링 아이디어가 적절하게 구현된 것이 맞는지 검증하는 것 또한 역시 적극적으로 이뤄져야 합니다.
그에 따라, 구현에 대한 피드백을 주고받기 어렵거나 결과물이 존재하지 않는 레퍼런스의 경우, 저는 최대한 기피하는 편입니다. 정확하게 구현했다는 가정 하에, 리서치 엔지니어는 구현 뼈대를 바탕으로 각자가 풀고싶은 문제에 맞게 customize 및 튜닝하는 것 또한 잘 해내야 할 일이기 때문입니다. 논문 내용만으로 구현은 어려울 수 있습니다. 모든 논문이 구현을 따라할 수 있게 친절히 설명해줄 의무가 없기 때문입니다…
하지만 정확한 수식만 잘 정의가 되어있다면 그 또한 올바르게 구현해내는 것이 이 직무가 가져야할 중요한 역량이라고 생각합니다. 앞서 언급한대로, 구현 결과물 들이 있지않은 논문이라고 해서 적용해 볼 가치가 없는 것은 절대 아니기 때문입니다. 구현 욕구를 불태우는 논문을 읽었다면, 저자에게 직접 메일을 보내 검증해 봅시다!
해결안 customize 및 검증
여러 해결안 중 가장 먼저 선택된 이 NCF 모델이 기존 대비 효과적인 방법이 될 수 있는지 검증하는 과정을 거쳐야 할 것입니다.
가장 먼저 ‘정확히 구현’ 했는지 확인합니다.
해결안에서 사용한 데이터셋이 본인도 사용할 수 있다면 ,
논문에서 명시한 성능 수치와 동일하게 나오는지 확인하는 것이 best일 것 같습니다.
그 다음은 customize의 최적화를 위해 실험을 구성해야 합니다.
저는 실제로 사용할 데이터셋으로부터 규모가 작은 실험 데이터셋을 구성하여 예비 실험을 진행했습니다.
저는 예비실험의 목표를 성능 개선 위주가 아닌 “현 task에 적합한 알고리즘이라고 할 수 있는가”에 초점을 맞췄습니다.
모델을 개발하자마자 성능 고도화와 하이퍼파라미터 튜닝을 시도하는 것은 좋은 일이 아니라고 생각합니다. 고도화, 튜닝 모두 프로덕트화 하기전에 선행되어야할 과제는 맞으나, 일반적으로 프로덕트 및 실서비스화에 사용할 데이터셋은 다양한 실험에 적합한 데이터 규모가 아닙니다.
성능 개선을 목표로 하는 실험은 실 데이터셋과 분포가 유사하지만 작은 규모의 데이터셋을 사용해야 효과적으로 진행될 수 있으며, 이는 해결안 자체가 현 비즈니스 로직 및 시스템, 인프라 등 모델 외의 다양한 요인들을 고려했을 때 적합한지 검증이 우선되어야 할 것이라 생각합니다.
이 예비 실험의 목표를 검증하기 위해서는 먼저 ‘적합성’의 기준을 선정해야 합니다.
‘어떤 추천 결과가 개인화된 추천이 잘 된 것인지’의 기준입니다.
하지만, 아쉽게도 우리가 고군분투하는 이 ‘추천’ 도메인에서 어떤 것이 좋은 추천이 되는지 검증하는 것은 task 특성 상 굉장히 어렵습니다.
HR@K, NDCG@K (https://sungkee-book.tistory.com/11) 등과 같은 아름다운 offline metric이 있으나 cat&dog과 같이 ‘사람이 좋아할만한 아이템’에는 정확한 정답이 없습니다. 데이터셋 자체도 평점과 같이 explicit하지 않기 때문에, 해당 offline metric은 해당 유저가 봤던 아이템을 실제로 모델이 봤다고 추론했는지 여부를 검증할 뿐입니다.
그렇기에 이 추후 A/B 테스트는 offline metric이 online metric과 얼마나 일치하는 경향을 보이는지와 같은 task에 대한 이해를 바탕으로 모델 성능을 실 추천 성능에 대한 검증이 가능할 것입니다.
그렇다면, 특정 offline metric에 대한 하이퍼파라미터 튜닝도 크게 의미가 없는 상황에서 제가 실험을 통해 얻어낼 것은 역시 알고리즘의 output이 개인화 추천에 적합하다고 할 수 있는지 사례들을 분석해보는 것이라고 생각됩니다.
어떤 요인을 선택해서 알고리즘을 수행시키면 해당 적합성에 가까워질지는 실험 구성의 기준이 됐습니다.
‘좋은 추천’ = ‘높은 user actual satisfaction’
이라는 제가 설정한 전제 하에, 한가지 가설을 세웠습니다.
시청 시간이 많을 수록, 해당 아이템에 대한 만족도가 높다고 할 수 있다.
NCF 알고리즘의 Input으로 사용되는 implicit data의 positive / negative interaction을 구분하는 기준을 바로 이 ‘시청 시간’으로 선정가능했고 이 요인을 실험마다 다르게 설정하여 실험을 진행했습니다.
이는 ‘문제 정의’ step 간 implicit feedback data가 가질 수 있는 문제 요소들에 대해 리서치를 진행하던 중,
“Beyond Clicks: Dwell Time for Personalization”, recsys’2014 (http://www.hongliangjie.com/publications/recsys2014.pdf) 로부터 인사이트를 제공받을 수 있었습니다.
위와 같이, 저도 이 추천 서비스를 사용할 사람으로서 판단할 수 있는 기준으로 적어도 ‘적합하지 않음’을 구별해낼 수는 있습니다. ( 위 예에 따라 직관적으로는, “장르" 기반이 의사결정의 기준이 될 수 있을 것 같습니다. )
저는 위와 같은 결과를 여러 취향의 가진 유저들의 시청 이력을 매뉴얼하게 구분해서 추출하고, 여러 팀에 공유하는 미팅을 가졌습니다.
어느정도의 합의를 거치고, 성능 고도화 작업에 임했습니다.
성능 고도화
이 단계에서부터 앞서 언급한 저의 6단계 로직은 순환 반복됩니다.
현재까지 개발된 모델과 알고리즘의 결과를 분석하고,
고도화할 수 있는 부분을 문제로 정의하고,
해결책을 리서치하고,
여러 해결안 중 현황에 적합한 하나의 해결안을 선택하고,
구현 및 실험을 통해 검증하고,
그 인사이트 및 결과를 공유합니다.
하지만 “성능”을 고도화 한다는 점이 목표가 된 이상, 모델의 최적화 과정이 병행되어야 합니다.
따라서 저는 이 과정에서 하이퍼 파라미터 튜닝을 진행해야 한다고 판단, 그에 따라 실험 데이터의 규모 및 분포를 실 사용 데이터와 유사하게 구성했습니다.
확장된 규모의 데이터셋을 파악한 결과, 제가 정의해야하는 문제는 새롭게 초점이 맞춰졌습니다.
아이템의 interaction 수를 popularity라고 수치화 할 때, OTT 서비스 환경에서 수집되는 로그 데이터 상 편중성이 심각한 롱테일 분포를 띄고 있었습니다.
이에 따라 예비실험에서 발견하지 못했던 observation을 얻을 수 있었습니다.
- 유저 규모는 확장됐으나, 아이템의 규모는 예비실험과 거의 동일하다.
- 모델 추천 결과가 인기 아이템으로 도배되어 예비실험의 ‘적합성’ 기준으로 대부분 성능 미달이다.
- 시청 이력이 적은 유저일 수록, 모델의 추천 confidence score의 value-scale의 편차가 커진다.
observation-a (이하 ob-a)으로부터 추론 가능한 사실은 유저 규모가 늘어나도 아이템 규모는 수렴하여 편중성이 심화된 롱테일 분포를 형성한다는 것입니다. 실서비스의 지속적으로 증가할 유저 풀을 고려할 때 이 부분은 문제로 정의할 필요가 있다고 생각했습니다.
ob-b의 원인을 분석한 결과, object detection task에서 활용되는 ‘focal-loss’의 고안 배경을 떠올릴 수 있습니다. 인기 아이템을 개인화된 선호 성향과 다소 거리를 둔 암묵적인 전제이긴 하나, 인기 아이템을 object detection task에서의 배경 픽셀로 치환해 생각해보면 자주 등장하는 트레이닝 샘플로 구성되어 False Positive 문제를 일으켜 추천 성능을 저하시키는 요소라고 판단 가능합니다.
ob-c는 예비실험에서는 상관관계가 옅었던, 유저가 시청한 콘텐츠 개수와 알고리즘 성능 간의 상관관계를 암시합니다. 직관적으로 예상 가능하지만, CF 계열의 알고리즘을 사용하는 이상, 시청 이력이 적은 유저의 vector는 많은 유저에 비해 sparse한 벡터를 가지고 있기 때문에 해당 유저에 대한 추천 성능은 저하될 수 있을 것입니다.
이러한 사실을 바탕으로 저는 이 ‘popularity-bias’ 문제를 해결한다면 추천 알고리즘을 고도화할 수 있을 것이라 판단했습니다.
popularity-bias를 키워드로 리서치한 결과, 크게 3가지 step에서 적용가능한 방법론들을 찾을 수 있었습니다.
이 과정 역시, 현황을 파악한 것을 기반으로 최적의 방법론을 선택하려 했습니다.
- Pre-Processing : 데이터 분포 자체에 debiasing algorithm을 적용하는 방법입니다. AI 기반의 알고리즘 전반적으로, 데이터를 왜곡 및 품질을 훼손하지 않는 선에서 sampler의 변경 및 data augmentation이 효과적으로 사용될 수 있으나 현 로그 데이터는 augmentation이 어려운 특성을 갖고 있었고, 이외 알고리즘의 적용 또한 성능 개선의 기대가 어려워 채용하지 않았습니다.
- In-Processing : training 간 적용할 수 있는 방법입니다. 위와 같이 기존의 loss function에 regularization term을 추가하여 redesign하는 방법인데, popular item에 모델이 overfitting하는 것을 방지할 수 있는 효과적인 대안으로 생각되나, 위 방법은 모델의 confidence score와 아이템 인기도의 분포에 대한 PCC (피어슨 상관계수)를 minimize하는 것이 다소 학습 자체에 전반적으로 인기 아이템에 대한 모델의 confidence를 저하시키기 때문에 새로운 inference bias를 낳을 수 있습니다. 앞서 관측한 사실에 따라 어디까지나 “좋은 추천”의 성능을 저하시키는 요인 중 하나로 가정했을 뿐이라 이러한 방법론은 다소 과격하다고 볼 수 있습니다.
- Post-Processing : 학습이 끝난 모델의 추론 결과에 적용할 수 있는 방법입니다. 이 방법에는 Popularity Compensation ( Popularity-Opportunity Bias in Collaborative Filtering, WSDM, 2021 의 6.1 섹션) 알고리즘을 사용할 수 있습니다.
결론적으로, post-processing 단계에서 사용할 수 있는 Popularity Compensation (PC) method와 확장된 데이터셋에 하이퍼 파라미터 튜닝한 모델로 해당 문제를 해결하려 했습니다.
Method 1 : VAR
NCF 논문에서 구성한 검증 방법에서는 HR@K, NDCG@K가 metric으로 사용되고 있는데, 해당 metric 만으로는 모델의 추천 결과에 대해 얼마나 popularity-bias로부터 free한지 검증이 불가능했습니다.
당시, HR@25, NDCG@25가 각각 약 80%, 60%대를 기록한 모델이며 시청 이력의 경향과 관계 없이 인기 아이템으로 도배가 된 결과로 확인됐습니다.
validation 간, unseen positive sample에 모델이 올바른 추론을 했더라도, 나머지 24개의 item이 얼마나 “좋은 추천”에 해당하는지는 고려되지 않는 HR@K의 계산법에 의해 popularity-bias의 부정적인 영향은 전혀 고려가 되지 않았습니다.
user-item interaction을 binary한 feedback data로 구성하는 NCF의 input은 NDCG@K 또한 마찬가지였습니다. 해당 검증방식은 1개의 unseen postivie sample과 validation batch size-1 개 만큼의 negative sample로 진행되는데, positive sample이 하나인 점과 binary feedback data는 복수의 relevance를 고려하지 않는다는 점때문에, top@K 내의 rank에 따른 페널티 방식이 적용되고 있지 않았습니다.
즉, HR@K와 NDCG@K는 추천 모델의 정확성 자체는 검증할 수 있는 metric으로 사용할 수 있을지 몰라도, popularity-bias 의 영향은 전혀 검증할 수 없었습니다.
그에 따라 추천 결과에 등장한 아이템의 개수가 보다 다양한 결과 (VARiety) 로 파라미터가 튜닝한 모델이 해당 bias가 비교적 완화된 학습 성향을 보인다는 직관적인 아이디어 하에, VAR이라는 metric을 자체 도입했습니다.
VAR = 추천 결과에 등장한 unique한 아이템의 개수 / 유저와 interaction된 총 아이템 개수
VAR을 optimize하기 위해 하이퍼 파라미터 ( batch size, 레이어 수, 임베딩 사이즈, 벡터의 hidden size, 트레이닝 네거티브 샘플링 회수 등등 )을 grid search하는 튜닝 작업을 진행했습니다.
개선 전의 모델 (Best NDCG, HR) 은 평균 **22%**대의 VAR을 기록했으나 개선 후의 모델 (Best VAR) 은 평균 79% 대의 VAR 수치를 기록했습니다. 개선 전후 모델의 HR과 NDCG는 거의 차이가 없었다는 것도 확인된 사실이었습니다.
Method 2 : Popularity Compensation ( PC )
논문의 PC 알고리즘의 rule은 아래 세 가지로 소개됐습니다.
- 보상제는 인기도에 따라 고려되어야 한다. 인기도가 낮은 아이템은 보상제도의 대상이 되어야 한다.
- 보상제는 유저의 선호도에 따라 고려되어야 한다. 선호도가 강하게 집계될수록, 보상의 영향력도 짙어져야 한다.
- 보상제는 각 유저의 value-scale에 따라 Normalized된 score로 이뤄져야 한다.
핵심적으로 위 PC 알고리즘은 post-processing method인 만큼, 모델의 기존 prediction score에 위 세 규칙을 고려해서 산출된 보상 점수를 더해주는 형태로 새로운 prediction score로 계산합니다.
‘인기도가 낮을수록 높은 점수가 더해진다’ 를 대변하는 popularity의 역수처리는 둘째치고, 3번째 rule에 해당하는 시청 이력 개수와 모델 score value-scale을 normalize한 new predicition score을 얻을 수 있다는 점이 확장한 데이터셋 규모에서 발견한 observation-c 사항에 강력하게 대응할 수 있다는 점이 powerful하게 느껴졌습니다.
또한 위 수식에 사용된 알파와 베타는 각각 인기도를 고려한 보상 점수의 가중치, 모델의 기존 prediction score의 가중치를 조절할 수 있는 hyperparameter로 동작합니다.
언급한 hyperparameter를 모두 0.5로 세팅하고 간단한 적용 결과를 보여봤습니다.
위에 있는 아이템일 수록 higher rank라고 보면 되고, rank(높을 수록 prediction score또한 높음)와 popularity의 관계에 대해서 전반적으로 다음과 같은 양상을 보입니다.
인기도가 낮은 아이템이 rank가 낮은 경우 비교적 큰 보상 점수를 부여받아 더 높은 rank에 위치할 수 있게 된다.
Future Work
인기 편중성과 추천 결과의 다양성에 따른 실 성능 검증
PC의 하이퍼파라미터 역시 VAR에 영향을 끼치는 수치가 될 것입니다. 기존의 검증 과정에서 후처리 전 후로 metric을 비교 검증하는 실험이 진행되어야 하며, PC의 하이퍼 파라미터 조합 별 추천 결과의 경향성 역시 분석되어야 합니다.
모델의 성능이 얼마나 아이템의 인기도와 추천 rank 간 상관관계를 가지고 있는지 위의 두 가지 metric으로 결과를 분석가능 합니다. 저 수치가 낮을수록 인기 아이템이 편중된 추천으로부터 벗어난 성능을 기록할 수 있다고 볼 수 있지만, 본질적으로 “좋은 추천”을 가려내야 하는 모델 성능의 검증에 있어서 A/B 테스트와 같은 외부 피드백을 필요로 할 것 입니다. Offline metric 만으로는 “개인화”를 수치화하는데 한계가 있을 것이기 때문입니다.
리서치 엔지니어로서의 회고
글의 첫 부분에서 제 자신에 던진 질문입니다.
- 리서치 엔지니어로서 나는 어떻게 회사에 기여할 수 있을까?
- “문제 해결”에 대한 효율적이고 바람직한 자세는 무엇으로 정의할 수 있을까?
긴 시간은 아니었으나, 입사 후 약 4~5개월이 지난 이 시점에서 위 두 질문에 어떻게 대답할 수 있을지 궁금합니다.
리서치 엔지니어로서, 저는 회사가 갖고있는 문제를 제가 풀 수 있는 문제로 재정의하여 효율적인 리서치를 통해 해결안을 구현 및 검증하여 기존 시스템의 개선을 이루고자 했습니다.
문제 해결에는 저만의 로직을 구성하고 적어도 ‘현재의 목표는 이것이다. 그리고 다음의 목표는 이것이다.’ 라는 방향성을 명확하게 가져가려 애썼습니다.
위 두 대답의 원천은 입사 초반 “리서치 엔지니어”의 직무에 대한 나만의 명확한 이해를 이루려 노력한 것이 기여한 것이라 생각합니다.
당연히 완벽한 대답들은 아니라고 생각합니다만, 이러한 자문자답의 과정은 저의 직무 수행에 끊임없이 변화하는 틀을 제공해줄 수 있는 원동력이 될 것이라 생각합니다. 그렇기에 현재 진행형이며, 그 대답또한 시간이 지남에 따라 계속 바뀔 것이라 생각합니다.
따라서 회고의 대상은 단순히 내가 현 시점에서 어떻게 대답할 수 있는가 뿐만 아니라, 현재 나의 대답에는 어떤 문제가 있었는지도 확인하는 것이 포함되어야 할 것입니다.
회고 또한 리서치 엔지니어링의 대상이 될 수 있다면 개선점을 논리적으로 도출할 수 있을 것입니다.
좋았던 점
- 리서치의 범위를 좁혀가려는 노력은 실제로 이전보다 빠른 속도로 해결안을 찾는데 기여했다.
- 현황부터 파악하려는 점은 리서치 스텝 간의 논리적 연결성을 끈끈하게 하는데 좋은 기저가 됐다. 이로 인해 결과 공유에 있어, 좋은 설명이나 발표가 될 수 있었던 것 같다.
- 나만의 로직을 세워 보다 계획적으로 리서치-구현-검증 과정을 수행한 것은 리서치의 방향성이 본질을 흐리지 않게 도움을 많이 주었다. 이전에는 리서치에 상당 부분을 신중하게 시간을 투자하고 구현으로 넘어갔는데, 팀의 애자일 개발 문화에 따라 나의 리서치 방식의 사이클도 짧게 가져갔는데 목표를 일관되게 가져갈 수 있었던 것 같다.
아쉬웠던 점
- 가설과 실험을 통해 검증하는 과정은 더 다양하게 이뤄져야한다고 느꼈다. 어떤 실험 구성을 설계해야 상호 배타적이며 효율적이고 유의미한 결론 도출이 가능할 지 고민하는 것에 시간을 더욱 투자할 필요가 있다고 느꼈다.
- VAR metric이나 popularity bias는 올바르게 예비실험을 통해 도출된 사실이나, 그 근거로 뒷받침할 수 있었던 HR@K, NDCG@K과 같은 기존 metric의 문제점의 원인 분석이 팀원의 피드백으로 그 이후에나 진행됐다. 기존 metric 이므로 실험 이전에 구현 검증 단계에서 알아낼 수 있었던 사실 같다. 해당 단계서 해야할 일을 하지 않았다고 판단된다.
대응안
- 결과 분석 — 새로운 가설 수립 및 실험 구성 단계를 더욱 세분화하고 순환적인 구조를 가져가면 보다 유의미한 가설을 세울 수 있고 실험을 구성하는데 더욱 부담이 줄어들 것 같다. 실험 구성에 관련된 서적이나 아티클을 읽어보고 참고해보면 좋을 것이라 생각한다.
- 이러한 부분들이 팀원과 페어 프로그래밍, 리팩토링 과정에서 많이 발견됐다. 코드 리뷰나 테스트에 있어 더 활발히 이뤄져야 할 것 같다.
정리하면,
이후의 저는 실험 구성과 코드 수준의 개발 작업에 더 심혈을 기울이는 것을 목표로 잡을 수 있을 것 같습니다.
저만의 로직에서, 여러 해결안 중 최적의 해결안을 선정하고 검증하는데 복수의 해결안을 동시 구현하고 비교 분석하는 것이 병행되면 보다 객관적인 의사결정이 가능할 것이라 생각했는데, 해당 역량들을 계발해 나간다면 구현과 검증 시간이 빨라질 수 있으므로 좋은 방향으로 기여할 수 있을 것이라 판단합니다!
맺음말
저의 고군분투, 주관적인 이야기들로 꽉 차있는 글을 읽어주심에 감사함을 표하고, 서로 자가성장을 위해서 어떤 방법이나 경험들을 쌓아가고 있는지 이야기를 주고받았으면 좋겠습니다.
감사합니다!
