Evals de LLM: construye un embudo, no una bifurcación

El blog de ingeniería de Spotify soltó una nota sobre cómo correr experimentos más chidos con evaluaciones de modelos de lenguaje grande. La versión corta: trata los evals como un embudo, no como una bifurcación. No esparzas casos de prueba por todos lados. Empieza chiquito, agrega capas y mide qué cambia.

El post explica por qué los equipos se quedan atascados cuando intentan evaluar modelos demasiado amplios y demasiado pronto. En vez de dividir el trabajo en una docena de buckets de prueba al azar, construyes una secuencia: checks básicos, luego los más duros, luego los casos borde. Cada capa filtra el ruido antes de que la siguiente agregue complejidad.

La idea es práctica. No es un framework nuevo. Es una forma de organizar los datos de prueba para que de verdad veas qué se rompe, cuándo se rompe y qué está haciendo mal el modelo en cada paso. Si tus evals son una bifurcación, estás adivinando. Si son un embudo, estás midiendo.

El post enlaza a la página de ingeniería de Spotify para más detalle. TLDR Data lo resumió, y el blog original de Brooker también se conecta con un post más amplio sobre qué es fácil versus qué es difícil con los LLMs.

### Por qué nos importa:
Si estás corriendo herramientas de IA en tu shop o construyendo algo para la gente, deja de tratar los evals como una lista de tareas y empieza a tratarlos como un embudo — porque cuando el modelo falla, necesitas saber exactamente dónde, no solo que falló.