Multi-Armed Bandits vs. Test A/B: la Guía Completa

Todo el que corre tests lo suficiente tropieza con la misma frustración: mientras tu test A/B todavía está corriendo, la mitad del tráfico sigue viendo la variación que, poco a poco, va quedando claro que es la peor. Ese es el precio combinado de testear con rigor, lo pagas con “costo de oportunidad” para comprar una respuesta confiable. Solo que existe toda una familia de algoritmos diseñada exactamente para reducir ese precio: los multi-armed bandits.

El bandit no es un sustituto del test A/B, es una herramienta con un objetivo distinto. Esta guía explica qué es un bandit, cómo decide hacia dónde mandar a cada visitante, cuándo vale más que un A/B clásico (y cuándo no), y muestra, con números reales calculados por el mismo motor estadístico que corre las calculadoras de este blog, cuánto cuesta cada enfoque en el mismo escenario. Al final, una tabla neutral compara lo que VWO, Optimizely, Kameleoon y otras herramientas del mercado realmente publican sobre el tema, con fuente para cada afirmación.

Qué es un multi-armed bandit

El nombre viene de una imagen antigua de casino: un “bandido de un solo brazo” (one-armed bandit) es la máquina tragamonedas clásica, con una palanca. Un multi-armed bandit es el problema de decisión de alguien frente a varias de esas máquinas al mismo tiempo, cada una con una tasa de pago desconocida y posiblemente distinta de las demás. En cada jugada, eliges una máquina, jalas la palanca y observas el resultado. El objetivo es fácil de enunciar y difícil de resolver bien: maximizar el total ganado a lo largo de todas las jugadas, sabiendo que cuanto más juegas en una máquina, más aprendes sobre ella, pero también renuncias a jugar en las otras.

Cambia “máquina” por “variación de tu página” y “jugada” por “visitante”, y tienes el problema exacto que un bandit resuelve en un test online. Cada variación (A, B, C…) es un brazo. Cada visitante que llega es una jugada. La “tasa de pago” de cada brazo es la tasa de conversión real de esa variación, que no conoces de antemano y que solo vas estimando con más precisión conforme llega el tráfico.

La diferencia de postura respecto a un test A/B es sutil, pero cambia todo lo que viene después: un test A/B trata la fase de recolección de datos y la fase de decisión como dos etapas separadas (primero juntas evidencia con una división fija, después decides). Un bandit trata la recolección y la decisión como la misma cosa, ocurriendo en tiempo real, jugada a jugada.

Bandit vs. test A/B: la diferencia central

Un test A/B clásico es un experimento de horizonte fijo: decides, antes de empezar, la asignación de tráfico (normalmente 50/50) y el tamaño de muestra necesario, lo corres hasta llegar ahí, y solo entonces declaras un ganador. La asignación no cambia ni un milímetro entre el primer visitante y el último, aunque a mitad de camino ya esté claro que una variación está perdiendo feo.

Un bandit reasigna el tráfico continuamente. Empieza cerca de una división igualitaria (porque, al inicio, no sabe qué brazo es mejor) y va empujando más visitantes hacia el brazo que parece ganar, mientras reduce, sin llegar a cero, el tráfico hacia los brazos que parecen perder. Con cada nueva conversión observada, la estimación de cada brazo se actualiza y la asignación se ajusta de nuevo.

Esto crea un intercambio (trade-off) bien definido, y es el corazón de toda esta guía:

• La ganancia del bandit: menos “costo de oportunidad” durante el propio test. Como el tráfico migra hacia lo que va bien antes del final, pierdes menos conversiones posibles mientras todavía estás aprendiendo.
• La pérdida del bandit: no produce un valor p, ni una significancia estadística en el sentido clásico, al final. Optimizely documenta esto de forma directa: los multi-armed bandits no generan significancia estadística y no usan un control o línea base formal; el resultado que recibes es la mejora de desempeño sobre una división igualitaria, no un veredicto estadístico con nivel de confianza asociado.

En otras palabras: el A/B optimiza para aprender con rigor; el bandit optimiza para ganar mientras aprende. Ninguno de los dos es “mejor” de forma absoluta, resuelven problemas diferentes, y elegir el equivocado para tu caso sale caro por los dos lados: correr un A/B cuando el costo de la variación perdedora es alto desperdicia conversión sin necesidad; correr un bandit cuando necesitas defender una decisión formalmente te deja sin el número que sostiene esa defensa.

Cómo funciona en la práctica: exploración vs. explotación

El nombre técnico para el intercambio que todo bandit resuelve es exploration/exploitation trade-off (exploración vs. explotación). Explorar es gastar tráfico en brazos sobre los que todavía tienes poca certeza, con la esperanza de descubrir que uno de ellos es, en realidad, el mejor. Explotar es concentrar tráfico en el brazo que, con la información disponible hasta ahora, parece el mejor.

Un algoritmo que solo explora nunca converge, sigue jugando a ciegas para siempre y desperdicia conversión probando brazos malos indefinidamente. Un algoritmo que solo explota (siempre elige el brazo que parece mejor según los primeros datos) corre el riesgo de fijarse demasiado pronto en una elección equivocada, porque los primeros datos de cualquier brazo son ruidosos: un brazo genuinamente mejor puede parecer peor en las primeras decenas de visitantes, solo por azar, y un algoritmo puramente codicioso nunca le daría una segunda oportunidad después de eso. Los tres algoritmos clásicos resuelven este equilibrio de formas distintas.

Epsilon-greedy: el más simple de explicar

El epsilon-greedy reserva una fracción fija y pequeña de tráfico, llamada épsilon (ε, por ejemplo 10%), para exploración pura y aleatoria entre todos los brazos, y manda el resto (1-ε) siempre al brazo que parece mejor en el momento. Es fácil de implementar y de explicar, pero tiene un defecto estructural: explora de la misma forma todo el tiempo, gastando el mismo 10% en brazos claramente malos después de miles de visitantes que el que gastaba el primer día, cuando la incertidumbre era genuina. Variaciones del método (como el épsilon decreciente, que reduce ε poco a poco) intentan corregir esto a mano, pero siguen siendo un ajuste manual, no una respuesta automática a la incertidumbre real de cada brazo.

UCB (Upper Confidence Bound): optimismo ante la incertidumbre

El UCB cambia la exploración aleatoria por una regla más elegante: para cada brazo, calcula la tasa de conversión estimada más un bono de optimismo, proporcional a la incertidumbre sobre ese brazo (cuantos menos datos, mayor el bono), y elige siempre el brazo con el mayor valor combinado. Un brazo poco probado gana un “beneficio de la duda” automático que lo vuelve atractivo incluso con una tasa estimada mediana, lo que empuja la exploración exactamente hacia donde falta información, sin necesitar un parámetro fijo como el ε. Conforme llegan más datos, el bono de cada brazo se reduce y la elección converge naturalmente hacia el que de hecho es mejor.

Muestreo de Thompson: el estándar de producción bayesiano

El muestreo de Thompson es el algoritmo que más aparece en producción cuando la base es bayesiana, exactamente el terreno donde Donnu ya opera. La idea, explicada sin fórmula: para cada brazo, mantienes una distribución de probabilidad (“qué tan probable es cada tasa de conversión posible de ese brazo”, dado lo observado hasta ahora, típicamente una distribución Beta cuando la métrica es una tasa de conversión). Con cada nuevo visitante, el algoritmo sortea un valor aleatorio de la distribución de cada brazo y manda al visitante hacia el brazo que sorteó el valor más alto. Después, actualiza la distribución de ese brazo con el resultado observado (convirtió o no), dejando la curva más estrecha y más precisa.

El truco es que ese muestreo aleatorio ya incorpora el equilibrio correcto entre explorar y explotar, sin necesitar ningún parámetro manual como el ε del epsilon-greedy. Un brazo con pocos datos tiene una distribución ancha (mucha incertidumbre), así que a veces el sorteo saca un valor bien alto de él aunque la media parezca mediana, y termina recibiendo tráfico de exploración de forma orgánica. Un brazo con muchos datos y una tasa claramente mala tiene una distribución estrecha y baja, así que casi nunca sortea un valor lo bastante alto como para ser elegido, lo que reduce el tráfico que va hacia él sin llevarlo a cero de una vez.

Esta es también la razón por la que el muestreo de Thompson encaja tan bien en un producto que ya es bayesiano por defecto: la distribución de creencia sobre cada brazo es exactamente el mismo tipo de objeto que un motor bayesiano de test A/B ya calcula para responder “cuál es la probabilidad de que B sea mejor que A”. El bandit y el test A/B bayesiano comparten la misma matemática de fondo; la diferencia está en qué haces con ella: decidir tráfico en tiempo real, o reportar una probabilidad al final.

Cuándo usar un bandit en vez de A/B (y cuándo no usarlo)

La pregunta correcta no es “cuál es mejor”, es “qué necesita esta decisión específica”. El bandit tiende a valer más cuando:

• El costo de mostrar la variación perdedora es alto e inmediato. Probar precios, por ejemplo: cada visitante que ve el precio “equivocado” es una venta potencialmente perdida ahora mismo, no solo un dato estadístico. Un bandit reduce esa sangría más rápido que un A/B 50/50 fijo.
• El tráfico es altísimo y la decisión es de optimización continua, no un hito único. Un titular de página de inicio con millones de visitas al día, o un algoritmo de recomendación que necesita adaptarse sin parar, encaja mejor en un bandit corriendo continuamente que en una secuencia de tests A/B cerrados uno por uno.
• Tienes muchos candidatos (A/B/n con decenas de variaciones) y no puedes dar el mismo tráfico a todos. Un bandit ya asigna menos tráfico a los brazos débiles desde temprano, lo que evita quemar muestra en variaciones claramente peores.

El A/B clásico sigue siendo la elección correcta cuando:

• Necesitas una respuesta que aguante ser defendida formalmente. Una decisión de producto o de negocio que va a citarse en un informe, presentarse a un inversor o usarse para justificar una inversión mayor generalmente exige un número con nivel de confianza, no “mejoró sobre una división igualitaria”.
• El cambio necesita durar y ser analizado por segmento después. Si quieres saber cómo se desempeñó la variación en mobile vs. desktop, por canal de adquisición, o por cohorte, necesitas datos recolectados bajo una asignación estable y comparable, exactamente lo que un bandit, al cambiar la asignación todo el tiempo, dificulta.
• La decisión es binaria y definitiva: cambiar de proveedor de checkout, rediseñar el flujo de registro, o cualquier cambio donde revertir sea costoso. Quieres un veredicto claro de “esto funciona, sí o no”, no una optimización continua.

El trade-off que nadie esconde

Vale la pena repetirlo con todas las letras, porque es la parte que el marketing de “optimización automática” tiende a suavizar: un bandit no produce un ganador declarado con 95% de confianza de la misma forma que un test A/B. La documentación de la propia Optimizely es directa sobre esto, las optimizaciones de multi-armed bandit no generan significancia estadística; el algoritmo optimiza el total de conversiones reasignando tráfico hacia la variación que está desempeñándose mejor en el momento, sin analizar formalmente por qué una variación supera a otra, y sin usar un control o línea base en el sentido del A/B clásico.

Esto no es un defecto de implementación que algún proveedor vaya a corregir en un próximo lanzamiento, es la naturaleza del problema que el bandit resuelve. El bandit es una herramienta de optimización (maximizar el resultado acumulado durante el período de test); el A/B es una herramienta de inferencia causal (estimar, con un margen de error conocido, si un cambio específico causa una mejora específica). Son preguntas distintas, y un buen bandit responde bien a la primera sin responder a la segunda.

En la práctica, esto importa en el momento en que necesitas defender la decisión. “La variación B convirtió 30% más y recibió la mayor parte del tráfico a lo largo del test” es una frase legítima para un bandit, pero no carga el mismo peso que “B convirtió 30% más, con un valor p de 0,003 e intervalo de confianza del 95% entre +0,5 y +2,5 puntos porcentuales”, la frase que un test A/B debidamente dimensionado permite decir. Si tu cultura de decisión exige el segundo tipo de frase (para un consejo, un inversor, o solo para que el propio equipo de producto duerma tranquilo), el bandit solo no entrega eso, aunque de hecho haya entregado más conversión durante el proceso.

Un ejemplo numérico resuelto

Para salir de la teoría, vamos a usar el mismo motor estadístico que corre las calculadoras de este blog y a comparar, con números concretos, lo que un test A/B fijo cuesta en oportunidad perdida frente a un bandit adaptativo, en el mismo escenario.

El escenario: una página con 10.000 visitantes por semana, tasa de conversión actual del 5%, y una variación B que, en realidad (aunque no lo sepas de antemano), convierte al 6,5%, el mismo lift del 30% relativo usado como ejemplo en la guía de significancia estadística de este blog. Quieres detectar un efecto mínimo del 10% relativo, con 95% de confianza y 80% de poder, el estándar de mercado.

Corre estos números en la calculadora de abajo (ya está con este escenario cargado) y confirma el tamaño de muestra y la duración:

Tasa de conversión actual%Efecto mínimo detectablerelativo (%)absoluto (pp)Confianza909599%Poder8090%Visitantes por semana (total)Testbilateralunilateral

-Visitantes por variación

-Total (2 variaciones)

-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

El motor de muestra de este blog (el mismo de src/lib/stats.ts, sin alteraciones en la matemática congelada) devuelve 31.234 visitantes por variación, 62.468 en total, corriendo durante 44 días con ese tráfico semanal.

El costo del A/B fijo 50/50

Durante los 44 días completos, la mitad del tráfico (31.234 visitantes) sigue viendo la variación A, aunque, bastante antes del final, los datos ya estén apuntando hacia B. Haciendo la cuenta de conversiones esperadas en este diseño:

• Conversiones esperadas de A: 31.234 × 5% ≈ 1.562.
• Conversiones esperadas de B: 31.234 × 6,5% ≈ 2.030.
• Total esperado con A/B fijo: ≈ 3.592 conversiones en los 62.468 visitantes.

Ahora, el techo teórico: si todo el tráfico, desde el primer visitante, hubiera ido a B (la variación de hecho mejor, en un escenario hipotético donde ya lo supieras con certeza absoluta), el resultado sería:

• 62.468 × 6,5% ≈ 4.060 conversiones.

La diferencia, ≈ 468 conversiones, es el “costo de oportunidad” que el diseño 50/50 fijo paga por su propia disciplina: mantiene la mitad del tráfico en la variación inferior de principio a fin, porque la asignación se decidió antes de que llegara ningún dato y no cambia hasta que el test termina. Es exactamente ese costo el que un bandit intenta reducir.

Una asignación adaptativa en el mismo escenario

Para ilustrar la lógica (no para simular con exactitud ningún motor comercial específico, ya que la curva real depende del algoritmo, del prior elegido y de la varianza observada), vamos a dividir los mismos 44 días y los mismos 62.468 visitantes en tres fases, con la asignación hacia B subiendo conforme se acumula la evidencia:

Fase	Días	Visitantes (aprox.)	Asignación para B	Asignación para A
1: todavía incierto	1 a 11	~15.617	50%	50%
2: la evidencia empieza a aparecer	12 a 26	~21.296	65%	35%
3: evidencia fuerte, pero nunca 100%	27 a 44	~25.555	80%	20%

Sumando las dos variaciones a lo largo de las tres fases: A recibe cerca de 20.374 visitantes y B cerca de 42.095. Las conversiones esperadas quedan así:

• A: 20.374 × 5% ≈ 1.019 conversiones.
• B: 42.095 × 6,5% ≈ 2.736 conversiones.
• Total ilustrativo con bandit adaptativo: ≈ 3.755 conversiones.

Comparando los tres números lado a lado, con el mismo tráfico total:

El punto central de este ejemplo no es el número exacto (que cambia con el algoritmo, el prior y la tasa real de conversión), es la forma del resultado: un bandit bien configurado queda sistemáticamente entre el A/B fijo y el techo teórico, sin llegar nunca al techo porque ningún bandit serio deja de explorar por completo (eso sería apostar todo a una lectura que aún puede estar equivocada), pero tampoco quedando tan atrás como una división 50/50 mantenida de principio a fin. Y, como se vio arriba, entrega esa ganancia sin producir, al final, un valor p o una significancia en el sentido clásico.

Tabla comparativa: A/B clásico vs. bandit vs. bandit contextual

Criterio	A/B clásico	Bandit (simple)	Bandit contextual
Asignación de tráfico	Fija (ej.: 50/50) de principio a fin	Cambia a lo largo del tiempo, según la evidencia	Cambia por visitante, según su contexto
Produce significancia estadística formal	Sí, valor p e intervalo de confianza	No, en el sentido clásico (Optimizely es explícita sobre esto)	No, en el sentido clásico
Mejor para	Decisiones que necesitan ser defendidas y documentadas	Optimización continua, costo alto de mostrar la variación perdedora	El “ganador” cambia por perfil (dispositivo, canal, comportamiento)
Análisis por segmento después del test	Directo, la asignación fue estable	Difícil, la asignación ya cambió sola durante el test	Es el propio objetivo del método
Exige más dato/infraestructura	No, es el diseño más simple	Un poco más (actualización continua)	Bastante más (modelo por atributo de contexto, datos en tiempo real)
Riesgo de decisión equivocada	Bajo, si está bien dimensionado y ejecutado	Bajo costo de oportunidad, pero sin prueba formal de causa	El mismo del bandit simple, más la complejidad de mantener varios modelos

Ninguna fila de esta tabla es “siempre la mejor”. Existe para que elijas según lo que tu decisión específica exige, y no por lo que suena más moderno.

Herramientas que ofrecen bandits (visión neutral)

Buena parte del mercado de test A/B ya ofrece algún sabor de bandit, generalmente como un recurso al lado del A/B clásico, no como sustituto de él. Vale la pena mirar lo que cada proveedor publica sobre su propio enfoque, con la debida salvedad de que las especificaciones de producto cambian y el mejor lugar para confirmar detalles siempre es la documentación oficial más reciente.

• VWO (SmartStats). VWO documenta su SmartStats como un motor bayesiano, con un prior no informativo (todas las tasas de conversión posibles empiezan igualmente probables) que se va actualizando conforme llegan los datos, permitiendo monitorear el test continuamente sin la penalización estadística de un diseño frecuentista fijo. La propia VWO, en su centro de ayuda oficial, afirma que la técnica reduce el tiempo de test a la mitad frente al diseño tradicional. Vale el matiz de siempre: los números de reducción de tiempo divulgados por un proveedor sobre su propio producto merecen leerse como el mejor escenario de la empresa, no como un promedio garantizado para cualquier cuenta.
• Optimizely (multi-armed bandit y bandit contextual). Optimizely documenta los dos formatos por separado. El bandit simple busca la única variación de mejor desempeño para todo el mundo; el bandit contextual, que la empresa describe como parte de su capa de IA (Opal), personaliza la elección según atributos del visitante, como dispositivo, ubicación o historial de comportamiento. Como ya se citó, la documentación de Optimizely es clara al afirmar que las optimizaciones de bandit no generan significancia estadística ni usan un control formal, a diferencia del producto de experimentación clásica de la misma empresa.
• Kameleoon (CUPED). Kameleoon no vende bandit como diferencial central, vende CUPED (Controlled Experiment Using Pre-Experiment Data), una técnica de reducción de varianza basada en el método de variables de control: usa datos de antes del experimento como covariable para reducir el ruido de la métrica medida, sin necesitar más tráfico. La propia Kameleoon reporta una reducción de hasta 60% en el tamaño de muestra necesario con la técnica bien aplicada. CUPED y bandit resuelven problemas distintos (CUPED acelera un A/B clásico que sigue produciendo significancia; bandit cambia la significancia formal por optimización continua), y vale la pena no confundir los dos al comparar proveedores.
• Spotify Engineering (separación entre personalización y experimentación). En enero de 2026, Spotify publicó en su blog de ingeniería una descripción de cómo la empresa separa deliberadamente la pila técnica que hace personalización, que incluye bandits contextuales, de la pila que hace experimentación formal. El artículo ilustra un bandit contextual eligiendo entre variaciones de un botón de checkout según atributos del visitante (como carrito, edad y ubicación), en vez de correr un A/B tradicional para encontrar “el” botón ganador único. Y refuerza el punto central de esta guía: un algoritmo de recomendación que solo optimiza para el engagement inmediato, sugiriendo siempre música ya conocida, mejora las métricas de corto plazo pero puede reducir el descubrimiento de contenido nuevo y perjudicar la satisfacción de largo plazo. El punto que más importa para esta guía: aunque tenga bandits corriendo en producción, Spotify sigue evaluando esos sistemas mediante tests A/B formales que comparan versiones de ellos, exactamente la división de trabajo que este artículo defiende: optimización continua de un lado, veredicto formal del otro.

Herramienta	Enfoque divulgado	Lo que queda fuera sin confirmación directa
VWO	Bayesiano (SmartStats), prior no informativo, test secuencial	La reducción de tiempo “a la mitad” es un número divulgado por la propia empresa
Optimizely	MAB simple y contextual (vía Opal), documentación explícita de que no genera significancia	Detalles del algoritmo exacto de bandit usado internamente
Kameleoon	CUPED (reducción de varianza, no bandit en sí)	Si la empresa ofrece bandit nativo además de CUPED, revisa la documentación actual
Spotify Engineering	Bandits contextuales en producción (personalización), evaluados por A/B formal aparte	Los detalles de implementación son internos, el artículo público es de alto nivel

Donnu A/B se posiciona en este mapa como una herramienta bayesiana nativa: el mismo motor que ya calcula “cuál es la probabilidad de que B sea mejor que A” para un test clásico es la base matemática que un bandit como el muestreo de Thompson necesita. Hoy el producto se enfoca en test A/B con lectura bayesiana honesta; el bandit es la extensión natural de ese motor, no un recurso genérico pegado encima.

Hazlo Automático con Donnu

Acabas de ver los dos lados reales de esta elección: un test A/B clásico entrega un veredicto que aguanta ser defendido, con valor p, intervalo de confianza y una asignación estable fácil de analizar después por segmento, al costo de mantener tráfico en la variación perdedora hasta el final. Un bandit reduce ese costo de oportunidad reasignando tráfico en tiempo real, al costo de no entregar, al final, una significancia estadística formal. Ninguna herramienta te libra de elegir: todavía necesitas decidir si tu situación pide rigor de inferencia causal u optimización continua, y la respuesta cambia de test a test.

Donnu ya corre hoy sobre un motor bayesiano nativo, exactamente la base matemática que sostiene a los dos mundos: el mismo cálculo de “cuál es la probabilidad de que B sea mejor que A” que declara un ganador honesto en un A/B también es lo que alimenta a un bandit como el muestreo de Thompson cuando la decisión pide optimización continua en vez de un veredicto único. No necesitas elegir la herramienta correcta a ciegas, Donnu ya parte de la estadística que ambos escenarios exigen.

Lee también qué es un test A/B y cómo funciona, significancia estadística explicada con la fórmula detrás, el problema del peeking y por qué detenerte pronto arruina un test, y la pieza hermana de esta guía, bandit contextual explicado, para cuando el “ganador” cambia según quién está mirando.

Empieza un test gratis de 14 días y corre tu próximo experimento sobre una base estadística que ya es bayesiana por defecto.

Referencias

• Optimizely. Run a multi-armed bandit (MAB) optimization in Feature Experimentation y Multi-armed bandit (glosario). docs.developers.optimizely.com y optimizely.com/optimization-glossary/multi-armed-bandit.
• Optimizely. Run Contextual Multi-Armed Bandit optimizations. docs.developers.optimizely.com.
• VWO. Enhanced SmartStats, Bayesian powered sequential testing engine. vwo.com/why-us/technology/statistics.
• Kameleoon. What we learned from running 200+ experiments on CUPED. kameleoon.com/blog/cuped.
• Spotify Engineering. Why We Use Separate Tech Stacks for Personalization and Experimentation (enero de 2026). engineering.atspotify.com.
• Russo, D. J., Van Roy, B., Kazerouni, A., Osband, I. & Wen, Z. A Tutorial on Thompson Sampling. Foundations and Trends in Machine Learning, 2018. arxiv.org/abs/1707.02038.
• Auer, P., Cesa-Bianchi, N. & Fischer, P. Finite-time Analysis of the Multiarmed Bandit Problem (el artículo que formaliza el UCB). Machine Learning, 47, 235-256, 2002.