Como o Spotify Gerou 1,4 Bilhão de Histórias Personalizadas para o Wrapped 2025

O Desafio: Um Bilhão de Histórias, Um Único Momento de Lançamento

Personalização em escala raramente é só sobre o algoritmo. Quando o Spotify decidiu ir além das estatísticas anuais para o Wrapped 2025, o objetivo era identificar dias marcantes no histórico de cada usuário e gerar uma história criativa baseada em dados. A meta? 350 milhões de usuários elegíveis, até cinco histórias por usuário — cerca de 1,4 bilhão de relatórios — tudo pré-gerado antes de um único lançamento global.

O desafio técnico central não era só o volume. Era a interseção de quatro problemas difíceis:

• Seleção heurística precisa de dias significativos a partir de um ano de dados ruidosos.
• Saída consistente, segura e criativa do LLM em escala.
• Inferência econômica sem sacrificar a qualidade.
• Armazenamento concorrente livre de condições de corrida sob enorme taxa de escrita.

Este post detalha as decisões arquiteturais e práticas de engenharia que tornaram isso possível, com base no blog de engenharia do Spotify como fonte principal.

Mergulho na Arquitetura: Das Heurísticas ao Armazenamento

1. Encontrando o 'Dia Marcante' — Pipeline de Heurísticas

O Spotify projetou um conjunto ordenado por prioridade de heurísticas para classificar cada dia no ano do usuário. Algumas eram simples (maior número de minutos ouvidos), outras mais complexas (mais nostálgico — picos em catálogo antigo). O pipeline era distribuído, agregando dias candidatos por usuário e armazenando em object storage.

# Exemplo simplificado da lógica de pontuação heurística
# Cada heurística retorna uma pontuação para um determinado dia do usuário
def pontuar_dia(estatisticas_dia: dict, perfil_usuario: dict) -> float:
    pontuacoes = []
    # Heurística: Maior Dia de Música
    if estatisticas_dia['total_minutos'] == perfil_usuario['max_minutos']:
        pontuacoes.append(1.0)
    # Heurística: Dia Mais Incomum
    desvio_gosto = calcular_desvio_gosto(estatisticas_dia['generos'], perfil_usuario['media_generos'])
    if desvio_gosto > 0.8:
        pontuacoes.append(0.9)
    # Heurística: Nostalgia (proporção de catálogo antigo)
    razao_nostalgia = estatisticas_dia['minutos_catalogo_antigo'] / estatisticas_dia['total_minutos']
    if razao_nostalgia > 0.6:
        pontuacoes.append(0.8)
    # Pontuação final (média ponderada por prioridade)
    return sum(p * w for p, w in zip(pontuacoes, [1.0, 0.7, 0.5])) / sum([1.0, 0.7, 0.5])

2. Engenharia de Prompt para Consistência

A equipe dividiu o prompt em duas camadas:

• System prompt: Definia o contrato criativo — storytelling baseado em dados, tom espirituoso, restrições de segurança.
• User prompt: Incluía logs de audição reais, bloco de estatísticas (LLMs são ruins em matemática), país do usuário e relatórios já gerados para evitar repetição.

O processo de prompting foi iterativo: um protótipo comparava saídas entre versões, usando um LLM-como-juiz em loop de avaliação.

3. Destilação de Modelo — Encolhendo o Modelo, Ampliando a História

Rodar modelos de fronteira para 1,4 bilhão de inferências era economicamente inviável. A solução foi um pipeline de destilação:

• Modelo professor: LLM de fronteira gerava saídas de referência de alta qualidade.
• Dataset ouro: Curado e revisado para voz, restrições e estilo.
• Modelo aluno: Modelo menor fine-tunado, otimizado com Direct Preference Optimization (DPO) usando avaliações humanas A/B testadas.

O modelo de produção fine-tunado alcançou forte paridade de preferência com o baseline original, a uma fração do custo.

4. Armazenamento Concorrente Sem Locks

O maior desafio de concorrência: até cinco relatórios por usuário gerados em paralelo. Uma abordagem ingênua de ler-modificar-escrever causaria condições de corrida. A solução elegante do Spotify foi o design de schema orientado a colunas.

-- Schema conceitual para escritas concorrentes
-- O status de conclusão de cada relatório é armazenado em um qualificador de coluna separado
-- Chave: user_id | Família de colunas: report_status | Qualificador: YYYYMMDD (ex: 20250315)
-- Ordem de escrita: 1) tabela de conteúdo do relatório, 2) coluna de metadados (marcando completo)
-- Sem locks porque dias diferentes acessam colunas diferentes

-- Exemplo de operação de escrita (pseudo-código)
INSERT INTO conteudo_relatorio (user_id, data_yyyymmdd, relatorio_json) VALUES (?, ?, ?);
UPDATE status_relatorio SET 20250315 = 'completo' WHERE user_id = ?;

5. Pré-Escalonamento e Carga Sintética para o 'Big Bang'

O Wrapped é lançado globalmente em um único momento — sem rollout gradual. O escalonamento reativo é muito lento. A equipe:

• Pré-escalonou pods de computação e capacidade de banco de dados horas antes do lançamento.
• Executou testes de carga sintética em todas as regiões geográficas para aquecer pools de conexão e caches.
• Garantiu que nada estivesse frio quando o tráfego real chegasse.

Avaliação, Remediação e o Humano no Loop

Nessa escala, mesmo uma taxa de falha de 0,1% significa milhões de histórias quebradas. A revisão humana sozinha é impossível. O Spotify construiu um framework de avaliação automatizada:

• LLM-como-juiz avaliando cada relatório em precisão, segurança, tom e formatação.
• Logging estruturado com IDs de relatório e metadados completos para rastreabilidade.
• Loop de remediação: relatórios problemáticos identificados → correspondência de padrões SQL/regex → exclusão em lote → atualização de guardrails → reexecução.

Um exemplo real: um bug de fuso horário fez com que alguns relatórios de 'Maior Dia de Descoberta' celebrassem o número errado de artistas. Como o framework de avaliação rastreou o problema até o pipeline upstream, a equipe corrigiu o bug, excluiu os relatórios afetados em lote e os reexecutou com segurança.

Limitações e Cuidados

• Sensibilidade do prompt: Instruções em excesso levaram a saídas menos criativas. A equipe aprendeu que menos é mais.
• Avaliação em escala: A amostragem é necessária, mas casos extremos podem escapar — o loop de remediação é crítico.
• Disciplina de custos: Destilação e DPO reduziram custos, mas a infraestrutura para pré-escalonamento e testes de carga sintética não é trivial.

Próximos Passos

• Explorar personalização em tempo real usando o mesmo pipeline de heurísticas + LLM para experiências no aplicativo.
• Investigar storytelling multimodal (trechos de áudio, resumos visuais) junto com texto.
• Otimizar ainda mais o pipeline de destilação com arquiteturas de modelo mais recentes e eficientes.

Conclusão: Engenharia para o Momento Emocional

O Spotify Wrapped 2025 é uma aula de engenharia para escala, segurança e ressonância emocional. As principais lições para qualquer equipe construindo personalização com IA:

1. Heurísticas + IA funcionam melhor do que IA sozinha. A seleção de dias baseada em regras forneceu entradas fundamentadas e interpretáveis para o LLM.
2. Concorrência é um problema de modelagem de dados. Um schema orientado a colunas eliminou a necessidade de lógica complexa de locking.
3. Avaliação não é opcional. Construa o loop de feedback desde o primeiro dia — ele vai te salvar no lançamento.
4. Pré-escalonamento vence escalonamento reativo. Para lançamentos de alto risco, testes de carga sintética são obrigatórios.

"Nessa escala, a chamada ao LLM é a parte fácil. O trabalho real está no planejamento de capacidade, replay e recuperação, disciplina de custos, loops de segurança e na preparação para um único momento de lançamento de alto risco."

Se você está arquitetando sistemas similares, confira nosso guia sobre arquitetando observabilidade conversacional para troubleshooting com IA, e entenda por que personalização e experimentação precisam de stacks tecnológicos separados.