Cinco anos atrás, a personalização de música no Spotify tinha uma equipe pequena. A equipe leu artigos, desenvolveu modelos, escreveu pipelines de dados e construiu serviços. Hoje, a personalização envolve várias equipes em Nova York, Boston e Estocolmo, produzindo conjuntos de dados, engenharia de recurso e servindo produtos aos usuários. Características como Discover Weekly e Release Radar são apenas a ponta de um enorme iceberg de personalização. Uma coisa que tenho notado é a sobrecarga de execução de serviços. Serviços são fáceis de lançar, mas têm um impacto muito real sobre a capacidade de uma equipe inovar e criar novos recursos. Especialmente porque o Spotify tem uma cultura de engenharia do tipo: "you built it, you own it”. O desenvolvimento do produto começa a partir da perspectiva de um usuário final e impulsiona o esforço da engenharia a partir daí. Por exemplo, considere o Discover Page, um portal pessoal para todas as coisas pessoais e músicas novas para você. A equipe se reuniria, inspecionaria o design da página, descobriria que tipo de aprendizado de máquina iria utilizar, construiria os modelos e, em seguida, iria para o produto. Se ele se sai bem, nós o enviamos para uso. Agora, a equipe tem um serviço para manutenção e talvez algumas pessoas para se preocuparem com coisas como estar de plantão. Avançando alguns meses, há uma segunda pergunta: rádio - uma adição perfeitamente razoável para um produto de música. Ele também fornece uma boa maneira de fornecer feedback para seus modelos. Algo que garante que toda o aprendizado de máquina não está evoluindo cegamente. O desenvolvimento de produto tomou o lugar de uma rotina semelhante, e a equipe acabou adotando outro requisito e outro serviço. Isso foi o que aconteceu com aquela pequena equipe de machine learning. Nós temos o Discover Page & Radio. Faríamos o processo do treinamento de dados, construiríamos modelos de fatores latentes. Em outras palavras, nós construímos vetores para cada entidade musical e usuário no Spotify. Os vetores foram armazenados e manipulados em pipelines de dados usando Sparkey e Annoy. O pipeline end-to-end foi costurado usando Luigi & Scalding. A saída seria um conjunto de recomendações que seriam servidas até usuários de um serviço muito simples que foi suportado por Cassandra e escrito usando Apollo. Logo nós crescemos. O Spotify adquiriu uma empresa de inteligência de música, a Echo Nest. Agora existem múltiplos times produzindo dados; várias equipes desenvolvendo recursos de personalização. A quantidade de pensamento por pixel estava crescendo. Nós entregávamos conjuntos personalizados mais ricos e melhores. Descover Weekly, a nova página inicial e as inovações em torno de todos os novos usuários vieram desse esforço. Agora nós enfrentamos novos desafios. As equipes intuitivamente chegaram nos blocos de construção com que estavam mais familiarizados no desenvolvimento de novos algoritmos. Precisávamos separar os ingredientes das receitas, compreender melhor os seus limites. Nós também precisávamos garantir que a experiência personalizada do usuário no Spotfy fosse consistente. Embora existam diferentes facetas e sabores para nossas criações, tudo deve chegar a você. A música é uma experiência emocional. Se você disser ao Spotify que odeia uma música no rádio, nós temos que utilizar essa informação quando formos preparar a sua próxima Discover Weekly. Tecnicamente, decidimos resolver esses dois desafios através da construção de uma infraestrutura de similaridade. Uma plataforma que permitiria que as equipes aprendessem umas com as outras e nos permitiria um feedback consistente em toda personalização. Infelizmente, uma plataforma de algoritmos de genéricos de machine learning é fácil para complicar tudo e mais fácil de satisfazer nenhum de seus usuários. Então começamos devagar. Pegamos um modelo que alimenta partes do Discover Weekly. Ele estava sendo usado em serviços que alimentam recomendações da lista de reprodução na página inicial, nova personalização do usuário na página inicial e Discover Page. Em termos de serviços de backend, isso significaria unificar três sistemas, três serviços on-call e milhares de linhas de código. Nossa API era simples, centrada no usuário e opinativa. Qualquer serviço seria capaz de falar conosco e obter fatos musicais sobre um usuário com base em sua vida no Spotify. Também queríamos permitir a capacidade de desbloquear reações instantâneas em tempo real para o comportamento do usuário. Um desafio técnico interessante com implicações tanto em machine learning quanto no sistema de engenharia havia surgido. Os vetores são muito mais versáteis e fáceis de combinar que as recomendações. Precisávamos projetar o nosso serviço orientado a arquitetura para manipular vetores e construir recomendações como uma última milha de esforço. Nossos modelos eram normalmente treinados em um treinamento de dados instantâneo para vetores de entidades musicais. Tivemos que modificá-los para que pudéssemos separar o processo de geração de vetores de usuário da etapa de formação. Dependendo da quantidade de informações que precisávamos obter sobre o usuário, poderíamos construir vetores com tempo de vida em um pipeline MapReduce ou vetores em tempo real no Storm. Precisávamos garantir que a transação de geração de vetores musicais, e a disponibilidade para todos os motores de processamento, fosse atômica e consistente. Nós construímos um processo de orquestração, um doorman. O trabalho desse processo foi garantir que a saída de um snapshot específico do treinamento de dados fosse atomicamente atualizado em todo o sistema.

Atualmente, estamos aumentando o sistema através da adição de outros modelos, tornando-o mais genérico por meio da adição de diferentes sinais. Esse sistema nos permitiu reduzir a complexidade dos serviços finais. Também nos permitiu disseminar os modelos de machine learning construídos por uma equipe em toda as outras equipes. Temos novos desafios surgindo. Como vamos traduzir e mover toda a nossa infraestrutura para o nosso novo ecossistema baseado Google Cloud? Como vamos construir um framework consistente para garantir que isso seja propagado através de todos os modelos distribuídos em todos os times? Isso irá envolver tanto o sistema de trabalho quanto a própria modificação no modelos de machine learning. *** Artigo do Spotify Labs, escrito por Esh. A tradução foi feita pela Redação iMasters, e você pode conferir o original em https://labs.spotify.com/2016/08/07/commodity-music-ml-services/.

spotifylabs