O Problema: Demanda por Dados Superou a Capacidade Humana
No Spotify, com mais de 70.000 datasets e petabytes de dados, fazer uma pergunta simples como "Qual foi o DAU de anúncios em podcast na semana passada?" podia levar horas — encontrar o dashboard certo, chamar o cientista de dados no Slack, esperar a resposta. A demanda por insights cresceu silenciosamente além do que qualquer especialista conseguia atender sozinho.
Jogar todos os schemas em um LLM não funciona nessa escala. Os context windows são limitados, mesmo com um milhão de tokens. E schemas não capturam semântica: uma coluna do tipo INT64 não diz que valores abaixo de 100 são dados de teste legados, ou o que significa "usuário ativo". O modelo escolhe a tabela errada com confiança.
O Spotify precisava de uma camada intermediária — um contexto curado, de propriedade de especialistas do domínio, que captura o que realmente importa sobre uma fatia do warehouse.
A Solução: Modelo de Clusters com Curadoria Humana
O assistente de dados do Spotify, chamado internamente de Vedder, está ativo desde agosto de 2025. Mais de 2.100 Spotifiers já usaram em mais de 13.000 conversas, enviando mais de 60.000 mensagens em 177 clusters cobrindo publicidade, podcasts, música, audiolivros, finanças e mais. Mais de um quarto desses usuários nunca havia escrito SQL antes.
Quando uma pergunta chega, o Vedder escolhe o contexto certo, escreve o SQL, executa e retorna a resposta junto com a query e as fontes — usando um loop ReAct (raciocinar e agir em etapas). Você pode ver como a resposta foi produzida, não apenas o que ela é.
O Modelo de Clusters
Cada cluster representa um domínio de dados (ex: publicidade, analytics de podcast) e é de propriedade de um time nomeado de especialistas. Tem três componentes:
- Datasets: tabelas do warehouse com schema completo e profiling — cardinalidade de colunas, valores comuns, estrutura de partições. Quando o modelo gera uma cláusula
WHERE, ajuda saber quecountrytem valores como 'US', 'GB', 'SE' em vez de adivinhar. - Pairs: exemplos de perguntas e SQL validados. Esse é o mecanismo de few-shot. Especialistas escrevem ou aprovam cada par, ensinando ao LLM como consultar os dados e sua semântica.
- Docs: contexto adicional de negócio — terminologia, pegadinhas, definições que variam por time, quais colunas usar e quais evitar.
Julgamento Humano > Histórico de Queries
Uma tentação: usar o histórico completo de queries do warehouse para gerar pares pergunta-SQL automaticamente. Basta pegar uma query, pedir a um LLM para inferir a pergunta e usar esses pares para ensinar o modelo. Parece escalável.
Mas quando o Spotify testou isso durante a curadoria, os especialistas aceitaram apenas 12,5% dos pares propostos. Os outros 87,5% eram exploração ad-hoc, sessões de debugging, respostas únicas, tabelas erradas ou queries tecnicamente corretas mas que ensinavam o padrão errado. Histórico de queries é rico — mas principalmente ruído.
Cada exemplo passa por um especialista. O modelo raciocina sobre o contexto; não decide o que é verdade sobre os dados. É assim que se constrói confiança.
Mantendo os Clusters Saudáveis: Pontuação Automática de Saúde
Os dados mudam. Schemas evoluem, colunas são renomeadas, tabelas são depreciadas. Um contexto que estava correto mês passado pode estar errado hoje. O Vedder precisa de informações atualizadas sem atenção manual constante.
Cada cluster tem uma pontuação de saúde composta por sinais monitorados continuamente:
- Qual a saúde dos dados subjacentes?
- Quantos pares curados ainda são válidos após mudanças de schema? (Se uma coluna é renomeada, os pares que a referenciam degradam imediatamente.)
- Quão bem o contexto cobre as perguntas que as pessoas estão realmente fazendo?
- Quão reproduzível é o SQL gerado?
Os especialistas veem a pontuação e os sinais subjacentes no dashboard do cluster e usam para decidir onde gastar tempo de curadoria. Cada conversa com o Vedder se torna um ponto de dados que realimenta o sistema — perguntas, respostas, SQL gerado e feedback do usuário são mostrados aos donos do cluster.
Limitações e Cuidados
- Problema do início a frio: Um novo cluster exige esforço manual significativo dos especialistas para semear pares e docs antes de se tornar útil.
- Escalabilidade da curadoria: Conforme o número de clusters cresce, a carga sobre os curadores aumenta. Automatizar parte da curadoria (ex: sinalizar pares obsoletos) ajuda, mas o humano no loop continua essencial.
- Pontos cegos de schema: Mesmo com profiling, parte da lógica de negócio vive fora do banco — em documentação, runbooks ou práticas de time. O modelo atual não ingere isso automaticamente.
Próximos Passos e Direção de Aprendizado
- Explorar ingestão de conhecimento externo: Como trazer documentação e definições de processos para a camada de contexto.
- Melhorar geração automática de pares: Usar pares aprovados por humanos como sementes para treinar um modelo menor que sugira candidatos para revisão.
- Estender além do Spotify: O princípio central — especialistas do domínio curam o contexto — é independente de arquitetura. Qualquer organização com um data warehouse e especialistas pode adotar esse modelo.
Conclusão: Curadoria de Contexto é o Novo Gargalo
O Vedder do Spotify mostra que o verdadeiro gargalo para escalar insights de dados não é o modelo — é o contexto. As pessoas que melhor entendem um domínio de dados são as melhores para curar o que o modelo vê. Isso não substitui cientistas de dados; dá a eles mais alavancagem. Eles gastam menos tempo respondendo perguntas pontuais e mais tempo moldando a camada de conhecimento que responde a milhares.
Para times construindo sistemas similares, comece pequeno: escolha um domínio, peça a um especialista para escrever 10 a 20 pares pergunta-SQL e meça o quanto isso melhora a precisão das consultas. Depois itere.
Leituras relacionadas: