A/B testing de prompts: cómo saber si una versión es mejor de verdad
El A/B testing de prompts compara dos versiones de instrucciones con usuarios reales. Cómo planear la prueba, qué medir y por qué necesita muestras grandes.
¿Por qué no basta con probar el prompt a mano?
Porque un prompt puede verse bien en tres ejemplos y fallar en el tráfico real. Las pruebas manuales tienen dos problemas: son pocas y las elige quien escribió el prompt.
FeatBit propone una secuencia de despliegue de cinco pasos:
- Evaluación offline. Compara control y variante con ejemplos representativos, casos de falla conocidos y una rúbrica. Si la variante no pasa aquí, no llega a usuarios.
- Exposición interna. Activa la variante con una bandera para empleados o un grupo de confianza.
- Exposición limitada. Asigna una cohorte pequeña y vigila telemetría y reportes de soporte.
- Prueba A/B balanceada. Compara control y variante con asignación limpia, cuando la variante ya es segura de medir.
- Decisión y limpieza. Promueve, revierte o revisa, y elimina las ramas de prompt y las banderas que sobran.
¿Por qué las respuestas de IA necesitan muestras más grandes?
Un modelo no da siempre la misma respuesta, aunque bajes la temperatura a cero. Según Atlan, que cita un estudio de 2024 de Atil y colegas, la precisión de un mismo prompt puede oscilar hasta 15 % entre ejecuciones idénticas. La misma fuente estima que la varianza de un LLM es, en orden de magnitud, mayor que en una prueba de producto normal, así que el cálculo de muestra de siempre se queda corto.
Dos reglas prácticas que salen de esa variabilidad:
- Calcula la muestra con tu propia varianza, estimada a partir de las puntuaciones de la evaluación offline, y con un efecto mínimo detectable que decidas antes.
- Recuerda la relación cuadrática: si quieres detectar una diferencia a la mitad del tamaño, necesitas unas cuatro veces más muestras.
| Efecto mínimo que quieres detectar | Muestra relativa |
|---|---|
| 20 % o más | 1× (base) |
| Cerca de 10 % | Cerca de 4× |
| Cerca de 5 % | Cerca de 16× |
Estas proporciones salen de la regla cuadrática, no de un estudio específico. Úsalas como orden de magnitud.
¿Qué medir?
No uses una sola métrica de conversión. Una prueba de prompts necesita un paquete:
- Calidad automática. Un modelo juez puntúa relevancia, fidelidad al contexto y claridad. Revisa LLM-as-judge para ver sus trampas.
- Señales del usuario. Pulgares, encuestas cortas y, como indicador indirecto, reintentos y salidas tempranas de la sesión.
- Operación. Latencia hasta la respuesta completa y tokens por variante. Una variante más precisa que tarda el doble puede no ser mejor.
Antes de exponer usuarios, puedes puntuar la variante con la misma rúbrica sobre entradas reales, en modo sombra. Así detectas problemas sin afectar a nadie.
¿Cómo se reparte el tráfico?
- Asigna por usuario, no por petición. Traceloop insiste en que un mismo usuario vea siempre la misma versión del prompt para que la prueba sea justa. Si cada mensaje cae en una variante distinta, la misma persona ve las dos y los datos se contaminan.
- Empieza con un porcentaje bajo. Una guía de Traceloop usa 10 % como ejemplo de canario: la variante nueva convive con el control y recibe una parte pequeña del tráfico.
- No mires el resultado a diario. Parar cuando una variante va ganando produce ganadores falsos. Espera al tamaño de muestra que definiste.
Ejemplo
Ejemplo ilustrativo: un asistente de soporte redacta respuestas a clientes. El equipo cree que un prompt con más contexto de políticas dará mejores respuestas. Antes de probar, escriben la hipótesis: “la variante sube la relevancia en la rúbrica al menos 10 % y no sube la latencia más de 15 %”. Calculan que necesitan miles de conversaciones por variante, no cientos.
Durante la prueba miran el promedio de relevancia, pero también un segmento: las consultas de devoluciones. La variante mejora el promedio, pero empeora ese segmento porque el contexto de políticas es demasiado largo para esa consulta. Sin revisar por segmento, habrían lanzado una mejora que perjudica a un grupo de clientes.
Para el marco general de estas pruebas, lee regresiones en prompts y golden datasets. Para las métricas de fondo, métricas de calidad de una feature de IA. Y para el experimento clásico en productos, la página de A/B testing en la sección de investigación.
Plantilla de hipótesis
Escribe la hipótesis antes de asignar tráfico, con esta forma:
Si cambiamos [qué], entonces [métrica primaria] subirá al menos [efecto mínimo] en [segmento], sin que [guardrail] empeore más de [límite].
Ejemplo: “Si agregamos la política de devoluciones al contexto, la relevancia en la rúbrica subirá al menos 10 % en consultas de devolución, sin que la latencia p95 suba más de 15 %.”
La forma obliga a tres decisiones previas: qué métrica decide, cuánto debe mejorar para valer el cambio y qué no puede empeorar. Si no puedes llenar un hueco, todavía no estás listo para el experimento.
Errores comunes
- Cambiar prompt, modelo y temperatura a la vez, y no saber qué funcionó.
- Decidir con una muestra pequeña porque el resultado “se ve bien”.
- Mirar solo el promedio y no los segmentos.
- Ignorar el costo y la latencia.
- Dejar ramas de prompt y banderas viejas en el código después de decidir.