Comparar versiones sin engañarse, baseline offline, pruebas A/B y métricas de resguardo

El viernes salió un prompt nuevo para el asistente de ventas, para todo el tráfico. El lunes la conversión cayó cuatro puntos. Ese mismo fin de semana la competencia lanzó una promoción y llovió en las tres ciudades más grandes. Nadie puede decir si el prompt empeoró algo, mejoró algo o no cambió nada: el experimento no tiene con qué compararse.

Dos etapas antes de decidir

Cualquier cambio (prompt, modelo, parámetros de recuperación, herramientas) pasa por dos filtros, en este orden:

1. Offline, contra la línea de base (baseline). La versión nueva corre sobre la misma suite de regresión (regression suite) que la versión actual: el dataset representativo de la lección anterior, con sus casos borde. El criterio de paso se fija antes: no empeorar en ningún segmento crítico y mejorar en lo que se buscaba. Es barato, rápido y frena la mayoría de los errores antes de que lleguen a un usuario.
2. En vivo, con una prueba A/B (A/B test). Lo que pasó el filtro offline se prueba con tráfico real repartido al azar entre las dos versiones y al mismo tiempo, con la métrica de éxito y el tamaño de muestra (sample size) definidos de antemano.

La simultaneidad es lo que hace que el resultado sirva. Comparar “la semana antes contra la semana después” mezcla el cambio con la estacionalidad, las campañas, el clima y cualquier otra cosa que haya pasado en el medio. Con las dos versiones corriendo a la vez sobre usuarios asignados al azar, lo único que distingue a los grupos es el cambio.

Leer el resultado

Lo que ves	Qué hacer
Mejora chica después de pocos días, lejos del tamaño de muestra fijado	Seguir hasta el tamaño acordado: puede ser ruido
La métrica principal mejora, pero el costo por conversación o las derivaciones empeoran	Pesar las métricas de resguardo (guardrail metrics) antes de lanzar
Mejora en promedio, empeora en un segmento	Mirar por segmento; quizás conviene lanzar solo donde gana
Mejora estable, resguardos dentro del rango, segmentos parejos	Lanzar de forma gradual y seguir midiendo

Las métricas de resguardo son las que no estás intentando mejorar pero no podés romper: costo, latencia p95, tasa de rechazos innecesarios, incidentes de seguridad, quejas. Se definen junto con la métrica principal, no después de ver los números.

Iterar de a un cambio

• Una variable por vez: si cambiás el prompt y el modelo juntos y mejora, no sabés cuál de los dos fue.
• Prompts versionados, como código, con registro de qué se probó, contra qué y con qué resultado.
• La suite crece con producción: cada falla real que aparece se anonimiza y se suma a la suite, para que la próxima versión no la repita.
• Lanzamiento gradual con vuelta atrás rápida: primero un porcentaje chico del tráfico, después el resto.

Las trampas típicas

• Lanzar a todo el tráfico y comparar antes y después, “ajustando a mano” por los eventos conocidos.
• Cortar el A/B a los dos días porque la métrica principal ya da positivo.
• Rechazar la variante en automático porque sube un poco el costo, sin pesar cuánto mejora.
• Decidir leyendo veinte transcripciones de cada versión y votando cuál “suena mejor”.
• Lanzar a todos y revertir si las quejas superan un umbral: los usuarios hacen de banco de pruebas.
• Volver a correr la prueba con otro modelo cuando lo que falta es muestra.

En el examen

Si un cambio se lanzó sin comparación y nadie sabe qué pasó, buscá el proceso de dos etapas: suite offline contra la versión anterior y después A/B con tráfico al azar, simultáneo y con la métrica fijada de antemano. Si el A/B ya está corriendo y muestra una mejora chica con poca muestra, la respuesta es completar el tamaño acordado y mirar resguardos y segmentos antes de decidir. Descartá las opciones que deciden con ruido o con impresiones.