El Problema: La Demanda de Datos Superó la Capacidad Humana

En Spotify, con más de 70,000 datasets y petabytes de datos, hacer una pregunta simple como "¿Cuál fue el DAU de anuncios en podcast la semana pasada?" podía tomar horas — encontrar el dashboard correcto, contactar al científico de datos en Slack, esperar la respuesta. La demanda de insights creció silenciosamente más allá de lo que cualquier experto podía manejar solo.

Meter todos los esquemas en un LLM no funciona a esta escala. Las ventanas de contexto son limitadas, incluso con un millón de tokens. Y los esquemas no capturan semántica: una columna de tipo INT64 no te dice que los valores menores a 100 son datos de prueba heredados, o qué significa "usuario activo". El modelo elige la tabla equivocada con toda confianza.

Spotify necesitaba una capa intermedia — un contexto curado, propiedad de expertos del dominio, que capture lo que realmente importa sobre una parte del almacén de datos.

Spotify data assistant cluster model diagram showing datasets, pairs, and docs Developer Related Image

La Solución: Modelo de Clusters con Curaduría Humana

El asistente de datos de Spotify, llamado internamente Vedder, ha estado activo desde agosto de 2025. Más de 2,100 Spotifiers lo han usado en más de 13,000 conversaciones, enviando más de 60,000 mensajes a través de 177 clusters que cubren publicidad, podcasts, música, audiolibros, finanzas y más. Más de una cuarta parte de esos usuarios nunca había escrito SQL antes.

Cuando llega una pregunta, Vedder elige el contexto adecuado, escribe el SQL, lo ejecuta y devuelve la respuesta junto con la consulta y las fuentes — usando un bucle ReAct (razonar y actuar en pasos). Puedes ver cómo se produjo la respuesta, no solo qué es.

El Modelo de Clusters

Cada cluster representa un dominio de datos (ej: publicidad, analytics de podcast) y es propiedad de un equipo nombrado de expertos. Tiene tres componentes:

  • Datasets: tablas del almacén con esquema completo y perfilado — cardinalidad de columnas, valores comunes, estructura de particiones. Cuando el modelo genera una cláusula WHERE, ayuda saber que country tiene valores como 'US', 'GB', 'SE' en lugar de adivinar.
  • Pairs: ejemplos de preguntas y SQL validados. Este es el mecanismo de few-shot. Los expertos escriben o aprueban cada par, enseñando al LLM cómo consultar los datos y su semántica.
  • Docs: contexto adicional de negocio — terminología, trampas, definiciones que varían por equipo, qué columnas usar y cuáles evitar.

Juicio Humano > Historial de Consultas

Una tentación: usar el historial completo de consultas del almacén para generar pares pregunta-SQL automáticamente. Solo toma una consulta, pide a un LLM que infiera la pregunta y usa esos pares para enseñar al modelo. Parece escalable.

Pero cuando Spotify lo probó durante la curaduría, los expertos aceptaron solo el 12.5% de los pares propuestos. El otro 87.5% era exploración ad-hoc, sesiones de debugging, respuestas únicas, tablas incorrectas o consultas técnicamente correctas pero que enseñaban el patrón equivocado. El historial de consultas es rico — pero principalmente ruido.

Cada ejemplo pasa por un experto. El modelo razona sobre el contexto; no decide qué es verdad sobre los datos. Así es como se construye la confianza.

Developer interacting with AI data assistant on Slack and web UI for querying datasets Coding Session Visual

Manteniendo los Clusters Saludables: Puntaje Automático de Salud

Los datos cambian. Los esquemas evolucionan, las columnas se renombran, las tablas se deprecican. Un contexto que era preciso el mes pasado puede estar equivocado hoy. Vedder necesita información actualizada sin atención manual constante.

Cada cluster tiene un puntaje de salud compuesto por señales monitoreadas continuamente:

  • ¿Qué tan saludables están los datos subyacentes?
  • ¿Cuántos pares curados siguen siendo válidos después de cambios de esquema? (Si una columna se renombra, los pares que la referencian se degradan inmediatamente.)
  • ¿Qué tan bien cubre el contexto las preguntas que la gente está haciendo realmente?
  • ¿Qué tan reproducible es el SQL generado?

Los expertos ven el puntaje y las señales subyacentes en el dashboard del cluster y los usan para decidir dónde invertir tiempo de curaduría. Cada conversación con Vedder se convierte en un punto de datos que retroalimenta el sistema — preguntas, respuestas, SQL generado y feedback del usuario se muestran a los dueños del cluster.

Limitaciones y Precauciones

  • Problema de arranque en frío: Un cluster nuevo requiere un esfuerzo manual significativo de los expertos para sembrar pares y docs antes de ser útil.
  • Escalabilidad de la curaduría: A medida que crece el número de clusters, aumenta la carga sobre los curadores. Automatizar parte de la curaduría (ej: señalar pares obsoletos) ayuda, pero el humano en el bucle sigue siendo esencial.
  • Puntos ciegos del esquema: Incluso con perfilado, parte de la lógica de negocio vive fuera de la base de datos — en documentación, runbooks o prácticas de equipo. El modelo actual no ingiere eso automáticamente.

Próximos Pasos y Dirección de Aprendizaje

  • Explorar ingestión de conocimiento externo: Cómo traer documentación y definiciones de procesos a la capa de contexto.
  • Mejorar generación automática de pares: Usar pares aprobados por humanos como semillas para entrenar un modelo más pequeño que sugiera candidatos para revisión.
  • Extender más allá de Spotify: El principio central — expertos del dominio curan el contexto — es independiente de la arquitectura. Cualquier organización con un almacén de datos y expertos en la materia puede adoptar este modelo.

Cloud infrastructure with data warehouse and health score dashboard for clusters Technical Structure Concept

Conclusión: La Curaduría de Contexto es el Nuevo Cuello de Botella

El Vedder de Spotify muestra que el verdadero cuello de botella para escalar insights de datos no es el modelo — es el contexto. Las personas que mejor entienden un dominio de datos son las mejores para curar lo que el modelo ve. Esto no reemplaza a los científicos de datos; les da más palanca. Pasan menos tiempo respondiendo preguntas puntuales y más tiempo moldeando la capa de conocimiento que responde a miles.

Para equipos que construyen sistemas similares, empiecen pequeño: elijan un dominio, pidan a un experto que escriba de 10 a 20 pares pregunta-SQL, y midan cuánto mejora la precisión de las consultas. Luego iteran.

Fuente: Spotify Engineering Blog - Encoding Your Domain Expert: The Context Layer Behind Spotify's Data Assistant

Lecturas relacionadas:

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.