“¿Qué prompt es mejor?” suena como una pregunta simple. En la práctica, evaluar outputs de IA es uno de los problemas más difíciles en IA aplicada. La evaluación humana es costosa y lenta. Las métricas automatizadas como BLEU o ROUGE pierden matices. Y la evaluación de un solo juez LLM está sesgada por la posición, la verbosidad y las propias preferencias del modelo juez.
Construimos un sistema de bakeoff que aborda estos problemas con puntuación multi-juez, aleatorización de posición e intervalos de confianza estadística. Este artículo cubre la arquitectura, las estadísticas y las lecciones que aprendimos.
¿Qué es un Bakeoff?
Un bakeoff es una comparación estructurada de dos o más “brazos” de IA — diferentes prompts, modelos, recipes o workflows — evaluados contra los mismos inputs. Piénselo como pruebas A/B para outputs de IA, pero con puntuación automatizada en lugar de tasas de clics de usuario.
JieGou soporta 6 modos de bakeoff:
- Prompt vs. prompt — Misma recipe, diferentes plantillas de prompt
- Modelo vs. modelo — Misma recipe, diferentes proveedores de LLM
- Recipe vs. recipe — Recipes completamente diferentes
- Workflow vs. workflow — Diferentes workflows de múltiples pasos
- Modelo de workflow vs. modelo — Mismo workflow, diferentes modelos
- Prueba A/B — Enrutamiento de producción en vivo con feedback de usuarios
Cada bakeoff puede tener hasta 8 brazos y 10 inputs, con un tope de 40 celdas totales (brazos por inputs) para mantener los costos razonables.
Evaluación LLM-as-Judge
Cada celda es evaluada por un juez LLM usando un enfoque de comparación por lista. En lugar de puntuar cada output de forma independiente (lo que pierde contexto relativo), el juez ve todos los outputs de los brazos lado a lado y los puntúa contra criterios definidos.
Los criterios de evaluación tienen peso y puntúan de 0 a 100. La configuración predeterminada usa:
| Criterio | Peso |
|---|---|
| Relevancia | 30% |
| Completitud | 25% |
| Claridad | 20% |
| Precisión | 15% |
| Formato | 10% |
Los usuarios pueden personalizar estos criterios o crear los suyos. Los pesos deben sumar 100%.
El prompt del juez presenta el output de cada brazo con una etiqueta aleatorizada (A, B, C…) y solicita puntuaciones estructuradas. Usamos invokeLLMStructured() con un esquema Zod para asegurar que el juez devuelva puntuaciones válidas y parseables.
Aleatorización de Posición
Un sesgo conocido en la evaluación de LLM es la preferencia de posición — los modelos tienden a favorecer outputs presentados primero o último. Aleatorizamos el mapeo de brazo a etiqueta en cada llamada de evaluación. El brazo 1 podría etiquetarse como “C” en una ejecución y “A” en la siguiente.
Esto no elimina el sesgo de posición, pero lo distribuye aleatoriamente entre los brazos en lugar de favorecer sistemáticamente a uno. A lo largo de múltiples inputs, el efecto se promedia.
Consenso Multi-Juez
La evaluación de un solo juez es inherentemente ruidosa. Diferentes modelos tienen diferentes preferencias, e incluso el mismo modelo puede dar diferentes puntuaciones para el mismo input. Ejecutamos 2-3 jueces independientes en paralelo sobre la misma evaluación y medimos su acuerdo.
Tau de Kendall mide la correlación de rangos contando pares concordantes y discordantes. Si dos jueces clasifican al brazo A por encima del brazo B, es un par concordante. Si no están de acuerdo, es discordante. El coeficiente varía de -1 (desacuerdo perfecto) a 1 (acuerdo perfecto).
Rho de Spearman proporciona una medida complementaria: 1 - (6 * suma de diferencias de rango al cuadrado) / (n * (n^2 - 1)).
Clasificamos el acuerdo como:
- Alto — Tau de Kendall ≥ 0.7
- Moderado — 0.4 ≤ tau < 0.7
- Bajo — tau < 0.4
Un acuerdo bajo es en sí mismo una señal útil. Generalmente significa que los criterios son ambiguos, los outputs son demasiado similares para diferenciar, o la tarea no tiene una respuesta claramente “mejor”.
Los rankings de consenso se calculan promediando las puntuaciones entre jueces, con conteos de victorias agregados para cada brazo.
Confianza Estadística
Para cada brazo, calculamos un intervalo de confianza del 95% alrededor de la media de puntuación: media +/- 1.96 * desviación estándar / raíz cuadrada(n), donde n es el número de inputs.
Cuando los intervalos de confianza se solapan entre dos brazos, lo señalamos — la diferencia puede no ser estadísticamente significativa. Esto evita que los equipos tomen decisiones basadas en ruido. Una diferencia de 2 puntos en 3 inputs probablemente es aleatoria. Una diferencia de 15 puntos en 10 inputs con ICs que no se solapan vale la pena actuar.
Integración de Pruebas A/B
Los bakeoffs responden “cuál es mejor en teoría”. Las pruebas A/B responden “cuál funciona mejor en producción”.
Cuando una prueba A/B está activa, las ejecuciones de workflow entrantes se enrutan aleatoriamente a diferentes brazos (división 50/50). Los usuarios proporcionan calificaciones con estrellas (1-5) como feedback sobre cada output, y ejecutamos una prueba chi-cuadrado para significancia estadística.
La prueba se detiene automáticamente cuando se cumplen dos condiciones: valor p < 0.05 y al menos 30 respuestas de feedback por brazo. Esto previene tanto conclusiones prematuras como pruebas innecesariamente largas.
Las decisiones de enrutamiento se almacenan en caché en Redis con un TTL de 30 segundos para consistencia — el mismo usuario consultando el endpoint repetidamente dentro de la ventana de caché obtiene el mismo brazo.
Gestión de Costos
La evaluación multi-juez multiplica los costos de ejecución por el número de jueces (2-3x). Proporcionamos estimaciones de costo por adelantado antes de que un bakeoff comience, usando medianas históricas de uso de tokens como líneas base y contabilizando el multiplicador del juez.
El tope de 40 celdas (8 brazos por 10 inputs) y el límite de 10 criterios mantienen los bakeoffs individuales acotados. Para brazos de workflow, usamos proyecciones de tokens de múltiples pasos que consideran el modelo de cada paso y el tamaño esperado de entrada/salida.
Lo Que Aprendimos
La aleatorización de posición es esencial, no opcional. En nuestras primeras pruebas sin aleatorización, el output presentado primero ganaba el 60-65% de las evaluaciones independientemente de la calidad. La aleatorización llevó esto al 48-52%, que está dentro del ruido.
Dos jueces detectan la mayoría de los desacuerdos. Pasar de 1 a 2 jueces mejoró dramáticamente la confiabilidad. Pasar de 2 a 3 jueces la mejoró más pero con rendimientos decrecientes. Para la mayoría de los casos de uso, 2 jueces con reporte de tau de Kendall es el punto óptimo.
Los intervalos de confianza cambian el comportamiento. Antes de agregar el reporte de IC, los equipos optimizaban para diferencias de 1-2 puntos. Ahora ven intervalos solapados y los interpretan correctamente como “sin diferencia significativa”. Esto ahorra tiempo de ingeniería que se habría gastado persiguiendo ruido.
Los esquemas de salida estructurada hacen la evaluación confiable. Las primeras versiones usaban respuestas de juez en forma libre y parseaban puntuaciones con regex. Esto fallaba constantemente — los modelos agregaban explicaciones, usaban diferentes formatos o se saltaban criterios. Cambiar a salida estructurada validada con Zod eliminó por completo los fallos de parseo.