Diseño de A/B test para selección de modelo LLM en producción

Contexto

Operamos una plataforma de comercio conversacional donde los merchants usan un asistente basado en LLM para conversar con clientes e impulsar ventas sobre canales de mensajería. El modelo base es una palanca con impacto real: un modelo mejor puede significar más conversiones, pero también mayor costo por mensaje. Apareció una nueva generación del modelo base (candidato). En teoría prometía mejor razonamiento, pero "en teoría" no paga las cuentas: antes de comprometer una migración necesitábamos evidencia en producción, con merchants reales y conversaciones reales.

Problema

Un A/B limpio sobre esto parece simple hasta que lo mirás de cerca. Tres cosas lo hacían no trivial:

• Conversiones ralas y merchants heterogéneos: las conversiones por conversación son eventos ralos, y los merchants de mayor volumen abarcan verticales, tipos de catálogo y tasas base de conversión distintas.
• Trampa de la unidad de análisis: la unidad natural de asignación (sesión, que se resetea tras un período sin respuesta del cliente) no es la unidad natural de análisis. Dos sesiones de una misma conversación no son independientes — analizar a nivel sesión produciría pseudo-replicación e inflaría los p-values.
• Riesgo asimétrico de rollout: rollear un modelo peor daña trust y revenue directamente; rollear uno mejor tarde es recuperable. El test debía proteger el downside.

Metodología

Diseño del experimento:

• Asignación: aleatoria 50/50 a nivel sesión de conversación vía feature flag, con toda la cohorte expuesta a ambas variantes.
• Unidad de análisis: conversación, no sesión, para evitar pseudo-replicación. Las conversaciones mixtas (que vieron ambos modelos) se excluyeron del análisis.
• Métricas: evento de venta marcada como primaria (cobertura completa) y orden registrada como secundaria (cobertura parcial). Ticket promedio por currency como exploratoria.
• Estadística: test de dos proporciones (z-test) para conversión, Mann-Whitney U para ticket (no asume normalidad en montos). Umbral convencional de significancia.
• Ventana: varias semanas de tráfico en producción.

Validación del diseño

Antes de mirar los resultados, verifiqué que el test se comportara como estaba diseñado:

• Asignación sticky: la gran mayoría de las conversaciones quedaron pegadas a un solo modelo a lo largo de sus sesiones. El resto se excluyó del análisis.
• Split balanceado: desviación mínima del 50/50 a nivel agregado y todos los merchants individuales dentro del rango esperado. Sin drift.
• Tracking de lift acumulado: el lift se volvió significativo temprano en la ventana y se mantuvo por encima del umbral hasta el cierre. Resultado robusto, no una ventana afortunada.

Resultados

• Lift agregado de conversión de dos dígitos a favor del modelo candidato, estadísticamente significativo. Magnitud similar en la métrica secundaria de orden registrada.
• Lift dramáticamente mayor — varias veces el agregado — concentrado en el segmento de merchants con catálogo integrado a una plataforma e-commerce de terceros. En el segmento con catálogo nativo el lift fue mucho menor y no significativo.
• Ticket promedio sin cambios significativos en ninguna combinación merchant/currency. El valor está en volumen de ventas, no en ticket.
• Un par de merchants mostraron lift negativo relevante: ambos con catálogo nativo, volumen medio, tasa base alta de conversión y prompts altamente customizados.

Aprendizajes

• El promedio escondía la historia real: el lift agregado era también un spread amplio entre merchants, desde fuertemente positivo hasta claramente negativo. La segmentación por fuente de catálogo explicó casi todo el comportamiento — la segmentación por país casi nada.
• Data de catálogo más estructurada amplifica la capacidad del modelo. Mecanismo probable: los merchants con plataforma integrada manejan promociones como data estructurada; los merchants con catálogo nativo las encastran en el prompt en texto libre, donde un modelo más capaz es más sensible a inconsistencias.
• Asignación a nivel sesión está bien si analizás a nivel conversación. El alto sticky rate confirmó que en la práctica eran casi equivalentes, pero la elección metodológica impactaba los p-values — para próximos experimentos, conviene mover la granularidad del feature flag a nivel conversación.
• Antes de escalar, el costo es la decisión bloqueante. Un lift porcentual dado es una decisión distinta a 1.5x, 3x o 10x de costo de inferencia. El tracking de costo por merchant es el análisis gating antes de decidir un rollout.