Spotify에서는 팟캐스트 검색 엔진에 어떤 인공지능 기술을 적용했을까?#

본 글은 Spotify 블로그에 있는 내용을 기반하여 작성되었습니다.

Spotify 소개#

회사 소개#

Spotify는 2006년 스웨덴에서 설립된 음악 스트리밍 서비스 회사입니다. Spotify는 사용자들에게 인터넷을 통해 수백만 곡의 음악과 팟캐스트, 오디오북 등의 콘텐츠를 제공하고 있습니다. 2022년 기준으로 1억개 이상의 음악과 5백만개의 팟캐스트, 그리고 30만개 이상의 오디오북이 Spotify에서 제공되고 있습니다. 그리고 Spotify는 이러한 콘텐츠들의 저작권자들에게 로열티를 지급하고 있습니다.

Spotify의 미션은 인간이 창의력이라는 잠재력을 발휘하기 위해 백만여명의 창작자들에게 그들의 예술로 살 수 있는 기회를 주고, 수십 억 명의 팬들에게 그들의 예술을 즐기고 영감을 받을 수 있는 기회를 주는 것입니다. 그에 따라 Spotify는 출시된 이후 음악 감상 방식을 완전히 바꾸었으며, 모든 사람들이 음악과 오디오 콘텐츠를 쉽게 접할 수 있도록 기존에 오디오 콘텐츠를 구매하고 소유하는 전통적인 거래 방식에서 스트리밍을 통해 필요할 때마다 접근하는 접근 방식의 산업으로 바꾸는데 이바지 했다고 볼 수 있습니다.

Spotify는 사용자들의 취향과 관심에 맞는 콘텐츠를 추천하고 재생하는 기술을 개발하고 있고 또한 콘텐츠 제작자들에게 플랫폼을 제공하여 그들의 작품을 전 세계에 알릴 수 있도록 지원하고 있습니다.

비지니스 모델#

Spotify는 두 가지 비지니스 모델을 운영하고 있습니다. 하나는 광고가 삽입되는 무료 서비스(Ad-Supported Service)이고, 다른 하나는 월정액을 내면 광고 없이 콘텐츠를 즐길 수 있는 프리미엄(Premium) 서비스입니다.

풀고자 하는 문제#

Spotify에서는 2022년 3월 까지만 하더라도 앱 내의 각종 컨텐츠를 탐색할 수 있는 검색 엔진을 주로 term matching 알고리즘에 기반하여 운영을 했다고 합니다. 예를 들어 “electric cars climate impact” 라는 쿼리를 입력하면, 검색 엔진이 참고할 수 있는 인덱싱된 컨텐츠의 메타데이터를 보고, 쿼리에 있던 단어들이 모두 메타데이터에 존재한다면 검색 결과로 반환이 되는 것입니다.

하지만 사용자는 원하는 콘텐츠를 찾기 위해 해당 콘텐츠에서 언급되는 정확한 단어를 인지하지 못한 상태에서 검색을 하는 경우도 많고, 이런 경우에 term matching에 기반한 검색 엔진은 사용자가 원하는 결과물이 데이터베이스에 존재하더라도 검색 결과로 반환하지 못할 수 있습니다.

문제 해결을 위한 솔루션#

이러한 문제를 해결하기 위해 Spotify에서는 Natural Language Search (NLS) 기법을 도입했습니다. 연구 분야에서는 Semantic Search라고 알려진 기법입니다. NLS을 사용한 검색엔진은 쿼리한 단어의 정확한 일치가 아니라 의미론적으로 연관된 콘텐츠를 쿼리와 매칭하여 결과를 반환합니다.

글 후반부에 나올 예정이지만, NLS가 기존 term matching을 완전 대체 한것이 아니라, term matching의 결과물과 NLS 결과물을 reranking을 해서 최종적인 결과물을 사용자에게 반환하도록 프로덕션 환경에서 구현을 해두고 있습니다.

1. 프로젝트 시나리오에 적합한 임베딩용 pre-trained 모델 선택하기#

Natural Language Search를 구현하기 위해서는 Dense Retrieval이라는 머신러닝 기술을 사용해야 합니다. Dense Retrieval은 입력된 쿼리와 반환되어야 하는 팟캐스트의 에피소드를 공통된 임베딩 공간 (shared embedding space)에 투영시켜서 벡터화를 하는 기법입니다. 그리고 나서 쿼리 벡터와 에피소드 벡터간의 거리가 가까울수로 의미론적으로 같다고 판단하여 결과를 반환하게 됩니다.

즉, 본 솔루션 구축에 가장 먼저 선행 되어야 하는 것은 Spotify가 지닌 팟캐스트 데이터와 앞으로 입력될 수 있는 쿼리들에 대해 적합한 벡터를 생성해줄 수 있는 언어 모델을 선택하는 것이였습니다.

Spotify에서는 최종적으로 Universal Sentence Encoder CMLM 모델을 사용했습니다. 왜냐하면 팟캐스트 에피소드 벡터는 에피소드의 제목과 에피소드의 설명 글을 합쳐서, 여러 문장들을 기반으로 벡터가 생성되는데, 보다 퀄리티 좋은 벡터를 생성하기 위해서 문장 임베딩 (sentence embedding)을 잘하는 모델이 필요했습니다.

Universal Sentence Encoder CMLM 모델을 사용한 또 다른 이유는 해당 모델이 100개 언어 이상의 방대한 데이터를 기반으로 pre-trained된 모델이였기 때문입니다. Spotify는 여러 언어로 제작된 팟캐스트를 보유하고 있다보니 여러 언어에 대해 품질 좋은 임베딩을 만들고 또 확장성을 위해 이러한 다국어 모델을 사용했다고 볼 수 있겠습니다.

2. fine-tuning용 데이터 준비#

Spotify가 지닌 팟캐스트 에피소드들에 대해 성능 높은 Natural Language Search용 임베딩 벡터를 생성하게끔 하기 위해, 앞서 선택한 pre-trained 모델을 fine-tuning 해야 했습니다.

어떻게 fine-tuning용 데이터를 구축했는지도 아주 세밀하게 Spotify 공식 블로그에 소개가 되어 있습니다.

Spotify에서는 fine-tuning을 위한 학습용 데이터를 3가지 유형으로 구축했고, 이와 별도의 방법으로 검증용 데이터를 구축해서 총 4가지 유형의 데이터를 구축했습니다.

첫번째롤 학습용 데이터 유형은 다음과 같습니다.

  1. term matching 기반으로 구현된 검색엔진에서 성공적으로 매칭된 (쿼리, 에피소드) 쌍들

  2. term matching 기반으로 구현된 검색엔진에서 첫번째 쿼리 시도는 실패했지만 그 후 몇 번의 다른 쿼리를 입력하여 성공적으로 매칭이 된 경우에 대해, (성공되기 전에 실시한 쿼리, 추후 매칭에 성공된 에피소드) 쌍들

  3. 유명한 팟캐스트 에피소드에 대해 딥러닝 모델로 생성한 쿼리를 매칭 시켜서 만든 (딥러닝으로 합성된 쿼리, 에피소드) 쌍들

특히나 2번 데이터 유형 같은 경우, 실제 사용자가 입력한 쿼리에 대해 Natural Language Search를 쓰면 반환이 될법한 데이터라고 볼 수 있겠습니다.

검증용 데이터로는 데이터 라벨러가 직접 큐레이팅한 데이터를 사용했고, Natural Language Search를 사용했을 때 탐지 될만한 의미론적으로 유사한 (쿼리, 에피소드) 쌍들을 구축해서 사용했다고 합니다.

모델의 일반화를 보다 더 확실하게 검증하기 위해 검증용 데이터에 언급된 팟캐스트 에피소드들은 학습용 데이터에는 없도록 학습용 데이터에 대한 처리를 진행했다고 합니다.

3. 학습#

Spotify팀은 데이터 준비 과정에서 positive 샘플, 즉 의미론적으로 유사한 (쿼리, 에피소드) 쌍을 구축 했습니다. 모델 학습을 할 때는 positive 샘플 뿐만 아니라 어떤 경우에 의미론적으로 유사하지 않도록 임베딩 해야 하는 것을 알려주는 negative 샘플 또한 중요한 데이터입니다. 블로그에서 negative 샘플 구축 과정을 세부적으로 다루고 있는 것을 볼 수 있습니다.

4. 평가#

모델 학습 후 평가 단계에서 활용한 지표들에 대해선 공식 Spotify 블로그에서 확인 가능합니다.

5. 프로덕션 환경에 통합#

쿼리 벡터 생성을 위한 쿼리용 인코더, 에피소드 벡터 생성을 위한 에피소드용 인코더에 대한 fine-tuning이 완료가 되면, 이제 해당 인코더와 인코더에서 나온 벡터들을 프로덕션 환경에 통합시키는 것이 필요 했습니다.

Spotify에서는 에피소드 인코더로 생성한 에피소드 벡터들을 Vespa 검색 엔진 서비스에 저장을 해서, 추후 쿼리 벡터가 입력되면 Vespa 검색 엔진 서비스에서 제공하는 Approximate Nearest Neighbor Search (ANN Search) 기능을 통해 빠르게 품질 높은 검색 결과물을 찾아서 반환했다고 합니다. ANN 기법은 실제 프로덕션 환경에서 빠르게 쿼리 벡터와 가까운 거리의 아이템 벡터를 찾는 기술입니다.

쿼리용 인코더는 Google Cloud Vertex AI에 배포해서 쿼리가 입력되면 해당 쿼리에 대해 추론을 실시하도록 구현했다고 합니다.

가끔씩은 NLS보다 기존 term matching이 더 좋은 결과물을 반환 하기도 하고, NLS만 사용하면 검색 비용이 너무 비싸지기 때문에, 최종적으로는 두 가지를 통합하여 두 개의 검색 엔진으로 부터 반환된 결과물을 reranking하는 모델을 중앙에 넣어서 사용한다고 합니다.

결과#

새로운 검색 엔진과 기존 엔진에 대한 A/B 테스트 결과 팟캐스트 관여 (podcast engagement)에 대한 상당한 증가가 있었다고 합니다.

개인 평가 의견#

IT 공부를 할 때나 IT 솔루션 구현 환경 후기에서 많이 보이는 There is no silver bullet 이라는 문구가 여기에서도 어김없이 등장합니다. 검색 엔진 분야에서도 해당 문구가 적용되며, 그래서 결국 term matching과 Natural Language Search 검색 엔진을 함께 최종적으로 프로덕션 환경에서 사용하는 것을 볼 수 있습니다.

최종적으로 여러 검색 엔진에 쿼리를 보내고, 각각의 후보군들을 통합한 후 reranking 하는 방식으로 프로덕션에 구현한 것으로 보이는데, 이 과정에서 latency 최적화는 추가적으로 필요로 했는지, 필요했다면 어떤식으로 접근했는지 궁금했습니다.

또한 Spotify R&D 블로그가 기술적으로 되게 상세하게 다루는 점 또한 느낄 수 있었습니다.

마지막으로 A/B 테스팅에 대한 결과가 단순히 텍스트로 상당히 증가했다 라고 공유하는 것이아닌, 수치적인 지표로 공유해줬다면 더 좋았을 것이라는 생각이 들었습니다. 하지만 이것은 단순 Spotify 뿐만 아니라 다른 기업들의 기술 블로그에서도 A/B 테스트의 결과로 수치적인 지표는 자세하게 공유가 안되는 추세를 확인할 수 있습니다. 아마 실제 내부적으로 현업에서 사용되는 지표다 보니 공개가 제한될 수도 있어 보입니다.

Reference#

  1. Microsoft Copilot

  2. Spotify 블로그

  3. Spotify - Financials