Ensinando LLMs a falar Spotify — Yves Raimond e Jacqueline Wood, Spotify

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Teaching LLMs to Speak Spotify — Yves Raimond & Jacqueline Wood, Spotify · Canal: AI Engineer · 19:37 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Modelos de IA

Resumo

Yves Raimond e Jacqueline Wood apresentam a transição da Spotify de recomendações tradicionais para a personalização generativa, em que usuários podem orientar e moldar experiências em linguagem natural. Eles descrevem o Large Taste Model e como semantic IDs permitem que LLMs compreendam itens do catálogo da Spotify e produzam recomendações e explicações. Jacqueline detalha o treinamento em quatro etapas do método NEO e apresenta resultados de ablações e estratégias de inference. Por fim, explicam como avaliações baseadas em LLM judges, fundamentadas em dados comportamentais e perfis de usuários, podem se alinhar às preferências humanas.

Pontos-chave

A personalização generativa amplia as recomendações: além de combinar usuários e conteúdo, gera experiências dinâmicas e interativas.
A Spotify busca tornar a personalização mais transparente e controlável, permitindo que usuários orientem recomendações em linguagem natural.
O Large Taste Model combina previsão e raciocínio e dá suporte a experiências como Spotify DJ, playlists por prompt e perfis de gosto editáveis.
Semantic IDs representam itens do catálogo como tokens discretos que podem ser incorporados ao vocabulário de um LLM.
O método NEO organiza o treinamento em quatro etapas: semantic foundation, domain grounding, capability induction e, opcionalmente, pós-treinamento.
Nos testes apresentados, o treinamento multitarefa igualou ou superou o treinamento de tarefa única, inclusive em recomendações de audiolivros.
Preservar o backbone pré-treinado durante o domain grounding ajudou a manter as capacidades de linguagem e conhecimento geral do modelo.
Beam search teve maior acurácia que top P sampling nos testes descritos, embora implique mais latência.
LLM judges fundamentados em perfis e sinais comportamentais apresentaram maior alinhamento com preferências humanas, sobretudo em consultas ambíguas.

Capítulos

Início	Capítulo	Resumo
00:01	Da recomendação à personalização generativa	Yves Raimond apresenta a escala do catálogo e a evolução da personalização da Spotify, de playlists curadas a experiências dinâmicas e orientáveis.
03:08	Experiências interativas e Large Taste Model	A apresentação mostra exemplos como Spotify DJ, playlists por prompt, perfil de gosto e podcasts personalizados, além de introduzir o sistema que os sustenta.
07:47	Semantic IDs e treinamento do NEO	Jacqueline Wood explica como semantic IDs representam itens do catálogo e apresenta as etapas de treinamento do NEO.
11:25	Ablações e estratégias de inference	A equipe compara treinamento multitarefa, variantes do processo de treinamento e métodos de geração, avaliando seus efeitos sobre desempenho, capacidades e latência.
15:05	Uso em produção e descoberta de conteúdo	A apresentação posiciona o NEO em relação a outros trabalhos e descreve seu uso em produção para ampliar a descoberta de podcasts.
16:10	Avaliações fundamentadas e encerramento	Jacqueline explica como fundamentar LLM judges em dados de usuários e conclui destacando a personalização generativa.

Citações

Não estamos apenas resolvendo a correspondência entre o usuário e o conteúdo; também estamos gerando uma experiência moldada de forma interativa e dinâmica para cada usuário. — 02:36

Estamos passando da personalização como adivinhação para a personalização como raciocínio. — 03:08

Isso ajuda a mitigar o esquecimento catastrófico das capacidades essenciais de linguagem do LLM pré-treinado. — 10:22

Esta é uma nova era de personalização: a personalização generativa. — 18:56

Conceitos e entidades

Spotify (empresa): Empresa de áudio cuja equipe apresenta sistemas de personalização e recomendação baseados em LLMs.
Yves Raimond (pessoa): Apresentador da Spotify que contextualiza a evolução da personalização da plataforma.
Jacqueline Wood (pessoa): Engenheira de machine learning da Spotify que explica o treinamento dos modelos e as avaliações.
Large Taste Model (modelo): Sistema interno da Spotify que combina previsão e raciocínio para personalizar e gerar experiências.
NEO (conceito): Paradigma de treinamento em quatro etapas apresentado para ensinar LLMs a compreender e recomendar itens do catálogo da Spotify.
semantic IDs (conceito): Tokens discretos derivados de embeddings de conteúdo que representam entidades do catálogo da Spotify.
Spotify DJ (ferramenta): Experiência personalizada de reprodução de música que pode ser orientada pelo usuário.
Discover Weekly (ferramenta): Experiência de recomendação da Spotify citada como um dos primeiros casos de uso de recomendações em escala.
Qwen (modelo): LLM de pesos abertos usado nos experimentos de treinamento descritos na apresentação.
Llama (modelo): Família de modelos usada para verificar se os resultados do paradigma de treinamento também se aplicavam a outro backbone.
LLM judges (conceito): LLMs usados para avaliar recomendações e explicações, com resultados mais confiáveis quando fundamentados em dados relevantes.

Tradução completa (pt-BR)

00:01 [música] Sejam todos bem-vindos. Fico muito feliz e agradeço também ao Deven pelo convite para conversarmos hoje. A Jackie e eu vamos apresentar hoje como fazer LLMs falarem Spotify e como viramos nosso sistema de recomendação de cabeça para baixo para torná-lo nativo de LLMs. Só algumas palavras rápidas

00:32 sobre mim. Entrei no Spotify há um ano. Antes disso, trabalhei no Google com personalização para a Busca do Google e, antes disso, trabalhei com personalização na Netflix. Certo, vamos começar. Primeiro, alguns números para descrever a escala do problema que precisamos resolver. O Spotify tem cerca de — fiquei um pouco triste por não vê-lo no gráfico de DAU, porque deveria estar lá em cima — cerca de 760 milhões de usuários ativos

01:04 mensais em cerca de 184 mercados. Mas uma coisa que torna o problema de personalização do Spotify particularmente desafiador é o tamanho do catálogo. Claro, o Spotify tem basicamente toda a música já publicada, um pouco mais de 100 milhões de faixas musicais, mas também oferece vários vídeos, podcasts e audiolivros. Então, o problema de correspondência é, na verdade, surpreendentemente complicado. Hoje, vamos falar

01:34 sobre a dimensão desse problema de correspondência e como estamos resolvendo-o. Vou falar um pouco da história, da nova fase em que estamos entrando, e depois a Jackie vai nos ajudar a entender os detalhes dos modelos e como eles são treinados. Um pouco sobre a história. Inicialmente, a personalização do Spotify foi realmente construída em torno da curadoria. As pessoas montavam playlists manualmente para atender a gostos específicos. E esse ainda é um caso de uso muito comum no Spotify.

02:04 Hoje, temos cerca de 10 bilhões de playlists, e muitas, muitas são criadas a cada hora. Depois, o Spotify passou a usar esses sinais de criação e de ordem para fazer recomendações. Basicamente, passamos a poder transformar esses sinais de criação em algo que pudesse ser aplicado em escala. Um ótimo exemplo disso é o Discover Weekly, lançado em 2014 como um dos primeiros casos de uso de recomendação no Spotify.

02:36 Mas a fase em que estamos entrando agora, sobre a qual vamos falar em mais detalhes, é algo que chamamos de personalização generativa, na qual não resolvemos apenas o problema de correspondência entre o usuário e o conteúdo. Também buscamos gerar uma experiência moldada de forma interativa e dinâmica para cada usuário. Essa transição das recomendações para a personalização generativa envolve algumas grandes mudanças. Uma delas é passar

03:08 da personalização como adivinhação — em que há algoritmos de ranqueamento que produzem uma lista ordenada de entidades do catálogo — para a personalização como raciocínio, que pode inspecionar esses resultados e tentar entender se eles são, de fato, a combinação certa para esse usuário nesse contexto específico. Outro aspecto é passar de algoritmos caixa-preta — é muito difícil inspecionar completamente, por exemplo, um sistema de ranqueamento em várias etapas — para uma personalização transparente e controlável,

03:40 em que o usuário está sempre no controle. Basicamente, damos a esses modelos a capacidade de falar e entender inglês. Outra coisa que esses sistemas podem fazer é não se limitar a recomendar, mas também gerar experiências e explicá-las. Vamos mostrar alguns exemplos disso. Um exemplo que lançamos há alguns anos, portanto bem no início

04:10 dessa jornada, foi o Spotify DJ. O Spotify DJ é algo que você pode iniciar para que comece a tocar música para você, personalizada, é claro. Mas uma coisa interessante é que, desde o ano passado, você pode tocar naquele botão no canto inferior direito e direcioná-lo para onde quiser. A qualquer momento, você pode intervir e informar ao algoritmo o que deseja, e ele vai direcionar a sessão nessa direção. Outro exemplo do que chamamos de personalização generativa é

04:41 mostrado aqui em uma playlist criada com prompt, que o Deanch também apresentou um pouco antes. Aqui, você tem acesso irrestrito ao algoritmo de recomendação do Spotify. Você pode usar prompts de alto nível ou muito detalhados. À esquerda, tenho um prompt que diz: “Crie uma playlist de bandas que vão tocar em San Francisco hoje à noite.” Acontece que há vários shows bons, caso você queira conferir. À

05:11 direita, há um prompt pedindo uma playlist para me acompanhar durante a corrida. O interessante também no exemplo à direita é que a própria experiência é moldada dinamicamente de acordo com a solicitação do usuário, podendo se apresentar e mudar em diferentes etapas da minha corrida. Outra novidade que me deixa muito animado foi lançada na Nova Zelândia há alguns meses e chegará em breve a mais mercados: chama-se perfil de gosto. Ela dá a você a capacidade de inspecionar, em

05:42 linguagem natural, o que o algoritmo do Spotify entendeu sobre você, de uma forma que permite editar e refinar essas informações. Se você perceber que algo está faltando ou está errado. Por exemplo, uma das minhas edições é dizer que toda a música da Disney é dos meus filhos, porque temos vários dispositivos compartilhados em casa, mas, por favor, não me recomendem isso; não é do meu gosto. O algoritmo então leva isso em conta, garantindo que nunca recomendemos isso no contexto errado. Da mesma forma, você também pode usar o perfil de gosto para compartilhar algumas

06:12 aspirações e objetivos. Por exemplo, explorar um novo gênero, conhecer um novo tema ou aprender um novo idioma. Tudo isso pode ser feito. Outra novidade que chegará em breve, anunciada muito recentemente, chama-se podcast pessoal. Nesse caso, o sistema de personalização generativa não se limita a recomendar e organizar experiências: ele também gera conteúdo. Neste exemplo específico, estou gerando um resumo diário, produzido todos os dias. E vou

06:45 deixá-lo me contar o que está acontecendo na minha comunidade. Certo. Agora, vamos aos detalhes. Há um grande sistema que controla todos esses diferentes aplicativos que mencionei, e internamente o chamamos de Large Taste Model. Não somos muito bons em dar nomes a essas coisas internas. Ele tem algumas propriedades. Uma delas é que entende cada interação histórica e cada conteúdo no Spotify. Combina previsão e raciocínio, como mencionei antes. Ou seja, não apenas adivinha, mas também acrescenta raciocínio

07:17 a isso, e dá aos usuários a capacidade de moldar e gerar experiências em tempo real. Portanto, é totalmente controlável e pode receber prompts dos usuários. Hoje, cerca de um em cada quatro assinantes Premium dos EUA interage com esse sistema diariamente. Isso é muito empolgante. Outra coisa empolgante é que implementar esse sistema também nas superfícies de recomendação existentes trouxe alguns ganhos. Observamos ganhos na reprodução automática e na descoberta de podcasts. Também vimos

07:47 ganhos no número de usuários que interagem com as mensagens do DJ. Portanto, observamos ganhos bastante expressivos em várias áreas ao implementar o sistema. Dito isso, vou passar a palavra para a Jackie, que vai falar sobre um dos componentes centrais que sustentam todo esse sistema. Oi, pessoal. Sou a Jackie, ou Jacqueline, engenheira sênior de machine learning no Spotify. Vamos nos aprofundar um pouco e conversar sobre como esses modelos são treinados, pelo menos no Spotify. Os IDs semânticos foram apresentados

08:18 na palestra anterior, mas é assim que incorporamos conhecimento do catálogo do Spotify a esses LLMs de pesos abertos. Eles são criados usando embeddings de conteúdo existentes, como embeddings de episódios de podcast, e aplicando um algoritmo de quantização para convertê-los em um conjunto de tokens discretos. Em seguida, pegamos um LLM de pesos abertos, como o Qwen, e modificamos seu vocabulário para adicionar esses novos

08:50 tokens especiais. Depois, fazemos fine-tuning do modelo para que ele consiga entender tanto a linguagem natural quanto esses novos tokens especiais, os IDs semânticos que representam entidades do catálogo do Spotify. Assim, podemos viabilizar experiências como esta, em que o usuário pode pedir, em linguagem natural, um podcast sobre moralidade. Esse pedido é enviado no prompt junto com o histórico de reprodução do usuário, representado como IDs semânticos. E o modelo responde

09:20 tanto com o ID semântico de um episódio de podcast relevante quanto com uma descrição em linguagem natural do motivo pelo qual o recomendou a esse usuário. Então, como esse modelo é treinado, exatamente? Publicamos um artigo, cujo link está aqui, que descreve nosso paradigma de treinamento, chamado NEO, composto por quatro etapas distintas. A primeira, que já expliquei, é a etapa de fundamento semântico

09:52 em que construímos tokens de ID semântico significativos e os adicionamos ao vocabulário de um LLM de pesos abertos. Chamamos a segunda etapa de ancoragem no domínio, na qual alinhamos os embeddings desses novos tokens de ID semântico ao espaço original de embeddings de linguagem. Fazemos isso aprendendo um mapeamento bidirecional entre IDs semânticos e texto, texto e IDs semânticos, e qualquer

10:22 combinação. Nesta etapa, congelamos o backbone do LLM e treinamos apenas os novos embeddings de ID semântico. Assim, os pesos e embeddings originais do modelo ficam congelados, e aprendemos somente esses novos tokens de ID semântico. Isso nos ajuda a mitigar o esquecimento catastrófico das capacidades centrais de linguagem do LLM pré-treinado. Chamamos a terceira etapa de indução de capacidades

10:54 que consiste em ajuste de instruções multitarefa para tarefas importantes para o Spotify, como as mostradas aqui: recomendação do próximo item, recuperação etc. Isso é feito descongelando o modelo inteiro, com todos os seus pesos e embeddings, e executando fine-tuning de parâmetros completos ou fine-tuning com LoRA nas várias tarefas do Spotify. Depois, há uma quarta etapa opcional para fazer pós-

11:25 treinamento, como fine-tuning com RL etc. Então, quanto faz diferença esse paradigma de treinamento em quatro etapas? Vou apresentar algumas das ablações que fizemos para investigar isso. Primeiro, avaliamos se o treinamento multitarefa prejudica o desempenho, comparando o modelo multitarefa com versões de tarefa única. E observamos de forma consistente, em todas as nossas tarefas, que o modelo multitarefa iguala ou

11:57 até supera o desempenho de tarefa única, o que indica que há algum aprendizado cruzado positivo entre as tarefas. Isso é particularmente perceptível nas recomendações de audiolivros. Como podem ver aqui, esse é um tipo de conteúdo mais recente no Spotify, o que demonstra que esses modelos multitarefa podem ajudar com entidades em situações de cold start, aprendendo com outros itens do catálogo, como recomendações de podcasts: como fazer recomendações significativas de audiolivros.

12:28 Depois, fizemos algumas ablações da própria receita de treinamento. Avaliamos tanto eliminar completamente a etapa de ancoragem no domínio com o backbone congelado quanto combinar essa etapa com a de indução de capacidades, em uma etapa de ajuste de instruções multitarefa. Essas são as linhas A e B aqui, no meio. E vimos que, nos dois casos, o desempenho

12:59 piorou. Mas a maior queda de desempenho veio do uso de um backbone inicializado aleatoriamente, em vez do LLM de pesos abertos pré-treinado que estamos usando. Também avaliamos o uso de pré-treinamento contínuo na etapa de ancoragem no domínio. Como podem ver, a degradação no desempenho específico das tarefas é mínima. Mas o pré-treinamento contínuo realmente afeta as capacidades de linguagem natural e de conhecimento de mundo do

13:31 LLM de backbone pré-treinado que estamos usando. Depois do pré-treinamento contínuo, elas caem para praticamente zero. Já com a etapa de ancoragem no domínio e o backbone congelado, preservamos toda essa capacidade central de linguagem e ainda conseguimos aprender os IDs semânticos. Quero destacar que essas ablações foram feitas com o Qwen, mas também validamos que os resultados se mantêm com o Llama. Portanto, não é algo específico do backbone do modelo, mas sim do próprio paradigma de treinamento.

14:03 Por fim, investigamos diferentes estratégias de inference e seus efeitos sobre a precisão e a latência. Testamos busca em feixe com decodificação restrita e sem ela. Vimos que, mesmo sem decodificação restrita, conseguimos gerar IDs semânticos válidos em 98% das vezes. A decodificação restrita acrescenta um pouco de latência, mas também é útil em casos específicos em que se quer

14:34 direcionar a geração para tipos específicos de conteúdo, por exemplo, recomendar apenas conteúdo novo. Também comparamos a amostragem top-P com a busca em feixe e vimos que a amostragem top-P prejudica bastante a precisão. Portanto, embora a busca em feixe tenha uma latência um pouco maior, decidimos que essa troca valia a pena para nós. O que há de significativo nisso? Há

15:05 muitos trabalhos no setor nessa área: recuperação generativa por ID semântico, sistemas de recomendação com LLMs que usam ferramentas, o artigo Plum etc. Mas o NEO é, na verdade, o primeiro exemplo de combinação de todas essas capacidades em um único sistema que entende itens do catálogo ancorados em dados, pode ser direcionado naturalmente por linguagem, oferece recursos de busca, recomendação e explicação, além de inference sem ferramentas e de baixa latência em

15:37 escala industrial. E já usamos isso em produção. Há também um artigo, com link aqui, sobre como usamos essa abordagem para viabilizar a descoberta de podcasts. Vimos que, com um modelo treinado dessa forma, conseguimos tirar os usuários de padrões habituais e levá-los a ouvir conteúdos menos familiares. E observamos grandes ganhos em produção.

16:10 Nada disso funciona sem avaliações significativas. Então, quero falar um pouco sobre isso, já que nossas recomendações estão se tornando mais generativas e explicativas. Nossas métricas tradicionais de avaliação offline talvez não sejam suficientes. Sim, elas podem nos dizer se o usuário interagiu ou não com aquele conteúdo, mas não conseguem dizer se a recomendação faz sentido para o usuário

16:42 nem se a explicação é precisa, se está alinhada à intenção do usuário etc. É aí que os LLMs como juízes realmente se destacam. Mas, em nosso trabalho no Spotify, descobrimos que é preciso investir em ancorar os LLMs como juízes em dados significativos, para que sejam avaliadores confiáveis e alinhados às preferências humanas. Por exemplo, para avaliar as recomendações de podcast que acabei de mencionar, criamos perfis textuais

17:16 de usuários que resumem o histórico de reprodução deles e os passamos ao LLM como juiz. Vimos que isso correspondia a um alinhamento de 75% entre o LLM como juiz e as preferências humanas. Da mesma forma, é possível usar sinais comportamentais reais para ancorar esses LLMs como juízes. Por exemplo, em uma tarefa de busca, para uma determinada consulta, é possível usar consultas semelhantes e o modo como o usuário interagiu

17:47 com elas no passado e passar essas informações ao modelo. Vimos que, no geral, isso aumentou o alinhamento em 5%, mas, em consultas ambíguas, o aumento foi de 91%. Isso demonstra o valor dessa ancoragem do LLM como juiz, especialmente em casos ambíguos, nos quais os LLMs como juízes tendem a ter dificuldades. Por fim, usamos LLMs como juízes ancorados para ampliar nossas coleções no estilo Cranfield.

18:19 São conjuntos de avaliação construídos selecionando candidatos de várias fontes, criando um conjunto e, em seguida, pedindo a uma pessoa que classifique esse conjunto. No entanto, essa etapa de classificação humana é cara. Por isso, investimos bastante na ancoragem do nosso LLM como juiz e conseguimos um LLM como juiz cujas classificações de sistemas concordam com as humanas, com um valor de concordância de 0,87.

18:56 Em resumo, como vamos ouvir em muitas das palestras de hoje, estamos entrando em uma nova era de personalização: a personalização generativa. E, se quiserem viabilizar recomendações personalizadas, direcionáveis por linguagem, para seus usuários, foi assim que ensinamos LLMs de pesos abertos a falar Spotify. Obrigada. [aplausos]

19:37 >> [música]

Transcrição original

[00:01] [music] Welcome everyone. Um really glad and thank you Deven for inviting us as well to talk today. Uh so um uh Jackie and I are going to present today about making LLMs speak Spotify and how we turned our recommendation system on its head to be LLM native. Uh just a few quick words

[00:32] about myself. Uh I joined Spotify a year ago. Before that I was at Google working on personalization for Google search and prior to that I was uh working on personalization at Netflix. Um all right so let’s dive in. Um first a couple of numbers to describe the scale of the problem that we have to solve. Um Spotify has about I was a little bit sad not to see it on the DAU by chart because it should be up there but it has about 760 million uh active

[01:04] uh users monthly uh in about 184 markets. But one thing that makes uh the Spotify personalization problem particularly challenging is the size of its catalog. Uh so of course you know Spotify has basically all music ever published a bit more than 100 million uh music tracks but it also has a range of videos, podcasts and audio books as well. So the matching problem uh is uh actually surprisingly uh complicated. So today what we’re going to talk about

[01:34] Jackie and I is basically the extent of this matching problem and how we uh how we are solving it. I’m going to talk about a little bit of history, the new phase that we’re entering and then Jackie is going to help us uh go into the guts of the modes as well to understand how those things are trained as well. Uh so a little bit on history. Uh initially Spotify personalization was really built around curation. So uh people basically manually assembling playlists that target specific taste. And that’s still a very common uh use

[02:04] case on Spotify. Right now we have about 10 billion playlists with many many uh created every every hour. Uh then you know Spotify moved into taking these creation signals and order signals and moving into recommendations. So basically being able to turn these uh creation signals to something that can be applied at scale. Uh and a great example of that would be discover weekly for example that was launched in 2014 as one of the one of the early like recommendation use case on on Spotify.

[02:36] But the phase that we entering now which uh uh which we’re going to talk about in more details is something that we call generative personalization where we are not only solving a matching problem from the user to the content. We’re also solving the ability to generate an experience that is interactively and dynamically shaped around each user. And that transition from recommendations to generative personalization involves a couple of different uh a couple of different big shifts. One is move from

[03:08] moving moving from personalization as guessing uh where basically you have a ranking algorithms that spits out a brand ranked list of entities in your catalog to personalization as reasoning that can introspect these results and really try to understand whether that’s indeed the right match for this user in this particular context. The other aspect as well is moving from blackbox algorithms. uh it’s very difficult to fully introspect a multi-stage ranking system for example to transparent and steerable

[03:40] personalization where the user is always fully in control. So uh basically giving the ability to these mods to speak and understand English. The other thing that these these systems can do is uh uh not stopping just at recommending but also generation of experiences and explaining as well. uh and we’re going to show a couple of examples of that. So one example that uh we launched a couple of years ago uh so pretty early

[04:10] in that journey was the Spotify DJ. Uh so the Spotify DJ is something that you can spin up that will start playing music for you of course personalized uh and but one interesting thing about it is that since last year you can tap that button on the bottom uh right and steer it in whatever direction you see fit. So at any point you can chime in and let the algorithm know what you want and it’s going to steer the session in the in in that in that direction. Uh another example of what we call generative personalization is uh

[04:41] showcased in a prompted playlist here that Deanch showed a little bit earlier as well. Uh and here you can you basically have full unfettered access to the recommendation algorithm that Spotify has. uh and you can uh prompt it with very high level prompts or very detailed prompts. On the left hand side here, I have a prompt that tells me uh create me a playlist of bands that are playing in San Francisco tonight. Uh so turns out there’s a bunch of good shows if you’re excited to check them out. On

[05:11] the right hand side, you see a prompt that is asking for a playlist to accompany me on my run. And what’s interesting with the right hand side as well is that you will see that the experience itself gets dynamically shaped as a function of the request on the user to be able to introduce itself and different phases in my run as well. Uh, another one that I’m really excited about, we launched it in New Zealand a couple of months ago and uh, it’s coming soon in more markets is something called the taste profile. And that basically gives you the ability to introspect in

[05:42] natural language what the Spotify algorithm has understood about you in a way that you can edit and refine. Uh, so if you see something that’s missing or something that’s wrong. Uh so for example one of my edit is that all Disney music are my kids because we have a bunch of shared devices at home but please don’t recommend that to me that’s not my taste please. Uh and the algorithm would then take that into account uh making sure that we never recommend this this in the wrong context. Uh and similarly you can also use the taste profile to share some more

[06:12] aspiration uh goals as well. Uh so getting into a new genre, getting into a new topic, uh learning about a new language for example, all of these things can be can be done. Uh another one that’s coming uh soon uh which we uh announced very recently is something called personal podcast where the the the generative personalization system doesn’t stop at just recommending and ascending experiences but also generating content as well. In this particular example, I’m generating a daily brief that’s uh that’s generated on a cadence daily. Uh and I’m going to

[06:45] uh let it uh tell me about what’s happening in my community. All right. So now to go into the guts of it. So there’s one big system that controls like all of these different applications I mentioned and we call that internally some the large taste model. We’re not great at naming these internal things. Um so it has a couple of properties. One is that it understands every historical interaction piece of content on Spotify. Uh it combines prediction and reasoning to the point that I mentioned earlier. So not only guessing but also reasoning layered

[07:17] on top and it gives users the ability to shape and generate experiences in real time. So it’s fully steable and promptable by uh by users. Um and uh as of today about one in four US premium subscribers interact with that system on a daily basis as well. So that’s pretty exciting. Um, one thing that’s exciting as well to uh is that deploying this system across existing recommendation surfaces as well also led to some gains. Uh, we saw gains on autoplay, we saw gains on podcast discoveries. Uh, we saw

[07:47] gains on users interacting with DJ messages as well. So, we saw pretty pretty sizable gains across the board as well by deploying the system. On that note, I’m going to hand it over to Jackie to talk to us about what’s one of the core component that underpins this whole system. Hi everyone, I’m Jackie or Jacqueline, a staff machine learning engineer at Spotify. So let’s dive a little bit deeper and talk about how these models are actually trained at least at Spotify. So semantic IDs were presented

[08:18] in the previous talk, but that is how we are embedding these openweight LLMs with knowledge of Spotify’s catalog. They are created by taking existing content embeddings such as podcast episode embeddings and applying a quantization algorithm to convert them to a set of discrete tokens. We then take a openweight LLM such as Quen and we modify its vocabulary to add these new

[08:50] special tokens and then we fine-tune the model to be able to understand both natural language as well as these new special tokens semantic IDs that represent Spotify catalog entities. So we can power experiences such as this where the user can ask in natural language for a podcast on morality. And that is passed to the prompt along with their listening history represented as semantic IDs. And the model responds

[09:20] both with a relevant semantic ID podcast episode as well as a natural language description of why they recommended that to this user. So how is this model actually trained? Um we published a paper linked here uh describing our training paradigm called NEO which consists of four distinct stages. The first I already covered which is the semantic foundation

[09:52] stage where we construct meaningful semantic ID tokens and then add them to an openway LLM’s vocabulary. The second stage we call domain grounding in which we align these new semantic ID token embeddings in the original language embedding space. We do this by learning a birectional mapping between semantic ids to text, text to semantic ids and any

[10:22] combination. And we actually freeze the LLM backbone at this stage and only train the new semantic ID embeddings. So the original model weights and embeddings are frozen and we just learn those new semantic ID tokens and this helps us to mitigate catastrophic forgetting of the pre-trained LLM’s core language abilities. The third stage we call capability

[10:54] induction which is multitask instruction tuning on tasks that Spotify cares about such as the ones shown here. next item recommendation retrieval etc. This is done by unfreezing the whole model all of its weights and embeddings and running either full parameter fine-tuning or Laura fine-tuning on the multiple Spotify tasks and then there is an optional fourth stage to do post-

[11:25] training such as RL fine-tuning etc. So, how much of a difference does this four-stage training paradigm actually make? I’ll dive into a few of the abilations we’ve done to investigate this. First, we assessed whether multitask training is actually hurting performance by comparing the multitask model against single task variance. And we consistently saw that across our tasks, the multitask model can match or

[11:57] actually beat the single task performance indicating that there is some positive cross-learning happening across the tasks. This is particularly noticeable for audiobook recommendations. If you look here, which is a new newer content type at Spotify, demonstrating that these multitask models can help with cold start entities by learning from other items in the catalog such as podcast recommendations,

[12:28] how to make meaningful audiobook recommendations. Then we did some abilations on the actual training recipe. We evaluated both dropping the frozen backbone domain grounding stage altogether as well as combining the domain grounding stage with the capability induction stage in a multitask instruction tuning stage that those are rows A and B here in the middle and we saw for both of those that it degraded

[12:59] performance but actually the biggest drop in performance was from using a randomly initialized backbone instead of the pre-trained openweight LLM that we are using. We also evaluated using continuous pre-training for the domain grounding stage. And as you can see, it’s it’s minimal actual degradation on the task specific performance. But where continuous pre-training really hits us is on the natural language and world knowledge capabilities of the

[13:31] pre-trained backbone LLM we are using. after we do continuous pre-training, it goes to essentially zero versus if we do the frozen backbone domain grounding. We retain all of that core language ability and are still able to learn the semantic ids. I want to call out that these abilations were done with Quen, but we also validated that these findings hold with Llama. So, it is not specific to the model backbone, but actually the training paradigm itself.

[14:03] And then lastly, we did some investigation on different inference strategies and their effect on accuracy versus latency. We tested beam search with both constrained decoding and not. And we saw that even without constrained decoding, we can generate valid semantic IDs 98% of the time. Constrained decoding does add a little latency overhead, but it’s also helpful for specific cases where you want to

[14:34] target specific types of content, such as only make new content recommendations, for example. We also compared top P sampling to beam search and saw that top P sampling pretty significantly hurts our accuracy. So although beam search is a little more latency intensive, we decided that trade-off worked for us. So what is meaningful about this? There

[15:05] have been lots of work in the industry in the space on generative semantic ID retrieval, toolbased LLM recommenders, the plum paper, etc. But NEO is actually the first example of combining all these capabilities into one system that understands grounded catalog items, is naturally language steerable, can do search, recommendation, explanation use cases, as well as low latency tool-free inference at an

[15:37] industrial scale. And we are using this in production today. Um there’s a paper linked as well here for how we’re using this to power podcast discovery. What we saw is that using a model train like this, we can break users out of their habitual patterns and get them to listen to more unfamiliar content. And we saw huge wins online with this.

[16:10] So none of this works without meaningful evaluations. So I want to talk about that a little bit as our recommendations are becoming more generative and explanatory. We our original maybe traditional offline eval metrics are not sufficient. Yes, they can tell us whether or not the user interacted with that content, but they can’t tell us whether or not the user or that recommendation makes sense

[16:42] for the user, whether the explanation is accurate, whether it aligns with the user’s intent, etc. So, that’s where LLM judges really shine. But in our work at Spotify, we really find that you need to invest in grounding your LLM judges in meaningful data. so that they can be reliable evaluators that align with human preferences. So, a few examples um for evaluating the podcast recommendations that I just mentioned, we create textual

[17:16] user profiles summarizing the users’s listening history and that is passed to the LLM as a judge and we saw that this corresponded with a 75% alignment between the LLM judge and human preferences. Similarly, you can use actual behavioral signals to ground these LLM judges. So, for example, for a search task, you can for a given query, you can take similar queries and how the user has interacted

[17:47] with them in the past and pass that to the model. And we saw that overall it increased alignment by 5% but on ambiguous queries it actually increased alignment by 91%. Showcasing the value these this grounding of the LLM judge plays especially in ambiguous cases where LLM judges tend to struggle. Lastly, we used grounded LM judges to scale up our Cranfield style

[18:19] collections. These are evaluation sets that are constructed by taking candidates from multiple different sources, creating a pool, and then using a human to rank that pool. However, that human ranking stage is expensive. So, we invested in significant grounding for our LM as judge and are able to have an LLM judge that aligns with uh human system rankings with an agreement value of 0.87.

[18:56] In summary, um like we’re going to hear a lot about today in all the talks, there is a new era of personalization among us. this generative personalization. And if you want to power language steerable personalized recommendations for your user, this is how we taught openweight LLMs to speak Spotify. Thank you. [applause]

[19:37] >> [music]