Evaluaciones con LLM El Embudo Que Hace Más Inteligentes Tus Tests A/B (No Redundantes)

El Nuevo Superpoder: Juicio Automatizado de Calidad a Escala

¡Hola Devs! Por años, el A/B testing ha sido el estándar de oro para decisiones de producto. En Spotify, solo alrededor del 12% de los tests A/B terminan en un resultado positivo enviado a producción — pero el 64% produce aprendizaje válido: una regresión detectada, una idea descartada, una hipótesis refinada. La tasa de éxito subestima el valor de la experimentación.

Ahora tenemos una nueva capacidad: evaluaciones con LLM. Estos jueces automatizados pueden evaluar dimensiones que antes no podíamos escalar — relevancia, coherencia, tono, alineación de intención — más rápido y más barato que la anotación humana, en cualquier dato desde conjuntos de prueba hasta variantes de tests A/B.

El insight crítico: las evaluaciones y los experimentos miden cosas diferentes. La relación correcta es un embudo, no un tenedor. Como describen los investigadores Schultzberg y Ottens (2024), las evaluaciones van antes de tu experimento, no en lugar de él.

Verificación vs. Validación: Entiende la Diferencia

Las evaluaciones con LLM verifican: ¿la salida cumple con los estándares de calidad? Los experimentos validan: ¿los usuarios reales responden como se predijo?

Un stack de evaluaciones fuerte significa que no pruebas para descubrir si el cambio hace lo que pretendes. Las evaluaciones ya te lo dijeron. Pruebas para validar que el cambio intencionado genera el resultado de negocio que se esperaba, y para acotar el riesgo de dañar el negocio.

# Ejemplo simplificado: usando un juez LLM para filtrar prompts candidatos

def evaluar_candidato(prompt: str, modelo_juez: str = "gpt-4") -> dict:
    """
    Devuelve una puntuación de calidad y problemas señalados para un prompt.
    Esto corre ANTES del test A/B para descartar variantes de baja calidad.
    """
    respuesta = openai.chat.completions.create(
        model=modelo_juez,
        messages=[
            {"role": "system", "content": "Eres un juez de calidad. Evalúa el siguiente prompt en relevancia, coherencia y tono. Salida JSON con score (0-1) y lista de problemas."},
            {"role": "user", "content": prompt}
        ],
        response_format={"type": "json_object"}
    )
    return json.loads(respuesta.choices[0].message.content)

# Uso en un embudo
candidatos = [prompt_a, prompt_b, prompt_c]
filtrados = []
for c in candidatos:
    resultado = evaluar_candidato(c)
    if resultado["score"] > 0.7:  # solo pasa candidatos de alta calidad al A/B
        filtrados.append(c)
# Ahora corre el test A/B solo en los candidatos filtrados

Las evaluaciones también generan hipótesis. Considera un equipo que construye un juez LLM para señalar contenido que rompe la confianza — por ejemplo, una recomendación compartida con un usuario que no encaja. El juez revela patrones que el equipo no sabía que existían. Esos patrones se convierten en correcciones de producto. Después de que la corrección se lanza, el mismo juez puede verificar si funcionó: las violaciones señaladas deberían bajar. Eso es la evaluación haciendo dos trabajos: descubrir qué mejorar y confirmar que la mejora se realizó.

Dos Capas de Calibración, Un Solo Ciclo de Retroalimentación

Las evaluaciones son proxies. Sustituyen una puntuación por un resultado que realmente te importa. Esa sustitución solo es válida mientras la puntuación sigue al resultado real — la misma dinámica que describimos con métricas proxy.

Ahora los jueces LLM añaden una segunda capa de calibración sobre métricas cuantitativas tradicionales (ranking scores, precisión, recall). Ambas capas necesitan validación contra resultados online. Ambas pueden sufrir drift. Cuando el juez dice que la Variante A es mejor, ¿realmente ofrece una mejor experiencia de usuario, o el juez está recompensando patrones superficiales que no generan resultados?

Por ejemplo, cuando Anthropic lanzó el modelo Opus 4.5, las evaluaciones de código de Qodo no mostraron mejora, pero el modelo había mejorado sustancialmente en tareas más largas — un experimento controlado lo habría captado. El descalibrado funciona en ambos sentidos. Sin calibración de señal offline-online, nuestras evaluaciones son opiniones, no evidencia.

El Ciclo de Retroalimentación en la Práctica

Al ajustar continuamente las evaluaciones para mejorar su mapeo a resultados online, las evaluaciones se convierten en herramientas de verificación cada vez mejores. No estamos descartando que, en el futuro, a medida que la IA avance, las evaluaciones puedan mapear lo suficientemente bien como para empezar a actuar como validaciones — pero solo si el ciclo de calibración offline/online está en su lugar.

Cerrando el Ciclo: De Opiniones a Evidencia

Equipos bajo presión de velocidad a veces llaman a los tests A/B "costosos". Sabemos por experiencia que lanzar sin un experimento puede ser increíblemente costoso, si una gran regresión en métricas de negocio pasa desapercibida. Cuanto más complejo es el sistema, más importante es acotar el riesgo.

Consejo práctico para tu equipo:

1. Corre evaluaciones temprano y seguido para encontrar los mejores tratamientos.
2. Deja que el experimento valide que usuarios y sistemas reales responden como se predijo.
3. Monitorea métricas que no optimizaste — los guardrails capturan regresiones.
4. Corre tus evaluaciones LLM en los propios datos del test A/B. ¿La versión que el juez prefirió realmente tuvo mejor rendimiento con los usuarios? Esto extiende el embudo de evaluación tradicional.

Cuando el gap entre las puntuaciones de la evaluación y los resultados del experimento es grande, eso es oro diagnóstico. Cada ciclo ayuda a calibrar el siguiente. Si los usuarios que recibieron la versión mejorada muestran un engagement a largo plazo superior, el equipo confirmó que lo que el juez mide realmente importa. Si las puntuaciones del juez mejoraron pero los resultados de los usuarios no, esa es la señal de calibración: el juez está capturando algo, pero no la cosa que genera valor.

Limitaciones y Cuidados

• Las evaluaciones tienen dificultades con tareas de larga duración y comportamiento a largo plazo por construcción. Son instantáneas, no trayectorias.
• Los jueces LLM pueden alucinar o mostrar sesgo. Siempre valida con revisión humana en un subconjunto.
• La calibración no es un esfuerzo único. A medida que los modelos y el comportamiento del usuario evolucionan, tus evaluaciones también deben evolucionar.

Próximos Pasos

• Empieza con un juez LLM simple para una dimensión (ej.: consistencia de tono).
• Construye un pipeline pequeño que corra evaluaciones antes de cada test A/B.
• Después del test, compara las puntuaciones de las evaluaciones con los resultados del experimento.
• Itera en los prompts y thresholds de tu juez basado en el gap.

Para más sobre la arquitectura detrás de separar personalización y experimentación, checa nuestro análisis de por qué stacks de tecnología separados para personalización y experimentación. Y si tienes curiosidad sobre cómo la IA está pasando de prototipado a producción, mira nuestro análisis de la nueva plataforma v0 de Vercel.

Este artículo se basa en investigaciones y prácticas internas de Spotify, originalmente publicado en Spotify Engineering.