Cómo ejecutar toneladas de experimentos al mismo tiempo usando un grupo de control adaptativo

Las pruebas A/B están muriendo, y estoy aquí para eso. La evaluación discreta y limitada en el tiempo de un pequeño conjunto de intervenciones (a veces solo una intervención) simplemente no produce resultados procesables duraderos de manera consistente.

• Hay demasiadas cosas que podría probar potencialmente. En cualquier situación comercial del mundo real, la cantidad de cosas para probar se vuelve abrumadora muy rápido, si está utilizando un marco de prueba A / B. El abrumador es una limitación del enfoque de prueba, no una característica del entorno de prueba.

  
  

• Puede llevar mucho tiempo ejecutar una prueba y mucho, mucho tiempo ejecutar muchas pruebas . Debe tener cuidado de que las diferentes pruebas no se superpongan en los usuarios a los que impactan. Debe evitar los días y lugares que la empresa no está dispuesta a incluir en una prueba. Acapara muchos recursos para ejecutar pruebas A/B.

  
  

• Una prueba potencialmente sacrifica mucho impacto en la variante perdedora : si ejecuta A contra B durante un mes y descubre que A funcionó mucho mejor, eso significa que le mostró a la mitad de sus usuarios la variante de bajo rendimiento durante todo un mes. Perdiste todo ese valor. Nadie está contento con eso.

  
  

• La efectividad a largo plazo de una prueba nunca es segura. El impacto de cualquier elección que haga puede verse influenciado por la hora del día, el día de la semana, la hora del mes, la época del año, los eventos mundiales, los cambios en el mercado, simplemente porque A fue mejor que B en el mes en que lo probó, no significa que siempre será mejor. Y ninguna prueba A/B puede decirle la vida útil de sus resultados.

Si desea una discusión un poco más profunda sobre los problemas con las pruebas A/B, la gente de [Babbel](https://Ejecute toneladas de experimentos al mismo tiempo usando un grupo de control adaptativo) tiene una buena presentación sobre el tema, y este tutorial sobre comentarios de bandidos es una excelente perspectiva de varios líderes de la industria.

Los bandidos armados múltiples son el futuro, y el futuro es ahora, y ahora tenemos nuevos problemas.

En una configuración de prueba A/B tradicional, tiene la variante A y la variante B. En la mayoría de las situaciones del mundo real, A o B es "mejor" solo en el sentido estadístico.

Si ejecuta una prueba y A obtiene una tasa de éxito del 20% y B obtiene una tasa de éxito del 10%, A claramente "gana"... pero ¿qué pasa con las personas que respondieron a B? ¿Van a estar bien con obtener A? Tanto las pruebas A/B como los algoritmos de bandido te obligan a sacrificar tus preferencias minoritarias por el bien de la mayoría. No tiene por qué ser así, así es como funcionan esos instrumentos en particular. Una mejor estrategia es llevar la opción A a las personas que prefieren la opción A y la opción B a las personas que responden a la opción B. Entonces:

• Enviar opción A a 100 personas y opción B a 100 personas.
• La tasa de éxito del 20% de la opción A significa que obtuvo 20 éxitos.
• La tasa de éxito del 10% de la opción B significa que obtuvo 10 éxitos.

Seamos generosos y supongamos que la mitad de las personas que respondieron a la opción B en realidad habrían respondido a la opción A si hubieran visto eso en su lugar.

Eso significa:

• Mostrar solo la opción A después de realizar la prueba arroja una tasa de éxito del 12,5% (los 20 que respondieron a A, más los 5 que respondieron a B pero habrían respondido a A, dividido por el total de 200 personas en ambos grupos).
• Enviar la opción A a las personas que quieren A y B a las personas que quieren B produce una tasa de éxito del 15%.

Entonces, al ajustar la forma en que implementa cada tratamiento en función de los resultados, deja menos valor sobre la mesa. Eso es todo lo que hace un algoritmo bandido: cubre las apuestas: B tiene la mitad de éxito que A, por lo que en realidad muestra B la mitad de las veces. Puede hacer esto con muchas opciones diferentes al mismo tiempo (no solo A y B), la implementación y el reajuste automáticos hacen que sea menos costoso ejecutar pruebas, no sacrifica tanto valor por perder variantes y el sistema puede ajustarse a los cambios en las preferencias del usuario o al entorno de decisión más amplio.

¡Todos los problemas de las pruebas A/B resueltos!

Pero esto puede resultar contraproducente.

¿Con qué frecuencia mostrará B a las personas que prefieren A, o mostrará A a las personas que prefieren B, porque está basando su decisión en estadísticas agregadas en lugar de preferencias individuales? De hecho, es posible que el algoritmo Bandit funcione peor que la prueba A/B en este tipo de situaciones. Y, por supuesto, todas estas cosas pueden cambiar con el tiempo. Tal vez la mitad de las personas a las que les gustó B en realidad cambien con el tiempo para preferir A. Y una cuarta parte de las personas a las que les gustó A cambien con el tiempo para gustar B. Sus estadísticas agregadas y, por lo tanto, la decisión que tomará sobre qué mostrar a quién. , seguirá siendo exactamente el mismo. Eso no es óptimo.

Los algoritmos de bandidos regulares tienen costos ocultos o, más bien, toman los costos de las pruebas A/B y los barajan en diferentes lugares para que no los note tan fácilmente. Configura su algoritmo y comienza a enviar y todo se ve muy bien... hasta que comienza a darse cuenta de algunos de los problemas que mencioné en los párrafos anteriores. Tal vez el equilibrio de preferencias entre A y B sea diferente para, por ejemplo, los usuarios nuevos que para los usuarios recurrentes. Tal vez esas preferencias sean diferentes para diferentes geografías. Tal vez incluso los usuarios experimentados se puedan dividir en usuarios avanzados y usuarios habituales. Es por eso que la gente ha inventadobandidos contextuales , que en realidad es solo una palabra elegante para bandidos más segmentación.

Ahora tiene que hacer muchos más informes para comprender qué segmentos de su base de usuarios pueden tener diferentes perfiles de preferencia. Por lo tanto, redujo los informes necesarios para analizar los experimentos, pero aumentó los informes necesarios para determinar el alcance de su bandido. Y ha aumentado la cantidad de trabajo necesario para convertir esos informes en un alcance real. Y una vez que tiene estos diferentes segmentos, se da cuenta de que tal vez necesite más creatividades para tener en cuenta ese contexto, por lo que es más trabajo. Y luego está el trabajo de ingeniería para construir las tuberías que llevarán al usuario correcto al bandido correcto. Y está el trabajo que debe hacer en su sistema de mensajería para asegurarse de que admita todas estas cosas que suceden en segundo plano.

Los bandidos resuelven muchos problemas de las pruebas A/B, pero los bandidos que son realmente efectivos crean nuevas necesidades analíticas y nuevos obstáculos logísticos que no son fáciles de resolver. Esta es una de las razones por las que las pruebas A/B siguen siendo tan populares: el proceso es tan común que existen muchas herramientas para ayudar con el trabajo pesado.

Las pruebas dinámicas requieren una evaluación dinámica, que requiere un grupo de control dinámico.

Así que ayudé a diseñar y crear un producto que facilita las pruebas complejas de bandidos contextuales, tan fácil que crea un contexto separado para cada usuario individual en su sitio o aplicación. Puede encontrar más detalles sobre ese producto aquí , ese no es realmente el objetivo de esta publicación, por lo que no hablaré más al respecto. De lo que quiero hablar aquí es de cómo solucionamos el problema de evaluar cientos de miles de pruebas adaptativas individualizadas por día.

Los detalles se pueden encontrar en nuestro artículo sobre arXiv .

He escrito antes sobre los desafíos prácticos, analíticos y, a veces, incluso éticos inherentes a la construcción de un grupo de exclusión para evaluar experimentos. Todavía mantengo eso. Evaluamos nuestros experimentos adaptativos utilizando un control sintético , porque eso no implica privar a los usuarios de intervenciones potencialmente beneficiosas. Sin embargo, los métodos de control sintéticos tradicionales pueden estar llenos de dificultades analíticas, ya que esencialmente está modelando el proceso de generación de datos de referencia para el entorno en el que está realizando su experimento. Agregue montones y montones de experimentos paralelos, muchos de los cuales tienen lugar en entornos superpuestos, y una solución analítica para el problema de control se vuelve... desalentadora.

Por eso no fuimos por ese camino.

Gary King y sus colegas de Harvard, hace varios años, idearon un método maravillosamente simple para extraer inferencias causales a partir de datos de observación. Se llama Coarsened Exact Matching (CEM). Puede encontrar el artículo seminal aquí y los fundamentos teóricos aquí .

La idea es sencilla:

1. Recopile todas sus observaciones de su intervención (prueba) que se lleva a cabo.
2. Recopile un montón de observaciones donde la intervención no tuvo lugar pero podría haberlo hecho.
3. Elija atributos que puedan medir la similitud entre cualquier par particular de observaciones de los dos grupos.
4. Atributos "gruesos" en variables categóricas. Entonces, si "edad" es un atributo, puede agruparlo en categorías de edad.
5. Haga coincidir cada observación de intervención con una observación de no intervención en función de la coincidencia exacta de atributos gruesos. Esto significa que elegirá solo un subconjunto de observaciones que no son de intervención y, a menudo, también terminará descartando algunas de sus observaciones de intervención, pero lo que le quede se combinará.
6. Modele la diferencia entre los dos grupos refinados.

CEM aleja la complejidad de la inferencia causal de los métodos analíticos (puede usar el método que prefiera) y la coloca en los métodos de creación de conjuntos de datos. Es similar, conceptualmente, a sobremuestrear o submuestrear un conjunto de datos de desequilibrio en un problema de clasificación.

Nos dimos cuenta de que podíamos usar este mismo tipo de lógica para encontrar contextos de control apropiados para nuestros experimentos de bandidos al incluir el tiempo como una de las características con las que coincidir. Ya coincidimos con ciertos atributos de intervención: el tipo de intervención que recibió un usuario y el nivel de actividad que el usuario exhibió en la aplicación en el momento de la intervención. Pero luego también definimos una ventana de observación y nos aseguramos de que cualquier usuario coincidente haya recibido una intervención en un período de tiempo cercano a la intervención para la que buscamos un control, pero no dentro del período de observación de la intervención en sí.

Esto nos permite tener controles emparejados a nivel de usuario para la mayoría de las pruebas que ejecutamos. Los algoritmos de Bandit eliminan parte de la complejidad de las pruebas A/B a escala, pero ocultan otras partes de esa complejidad. Nuestro método de control toma esa complejidad oculta y la resuelve para que podamos obtener los beneficios adaptativos de la asignación de bandidos, pero la clara inferencia y atribución de las pruebas A/B.

Así que aquí está su lista de tareas pendientes:

1. Para cada intervención que realice, identifique una ventana de anticipación y una de retrospectiva. La ventana de anticipación es lo que usa para ver cómo respondió el usuario a la intervención, y la ventana de anticipación es donde busca casos de control.
2. Para cada intervención, identifique un conjunto de otras intervenciones que (1) tuvieron lugar dentro de la ventana de observación y (2) no tienen una ventana de observación que se superpone a la ventana de observación la intervención que está buscando un control.
3. Haga coincidir los usuarios que recibieron esas posibles intervenciones de control con el usuario que recibió la intervención para la que busca un control. Puede hacer coincidir cualquier criterio que desee: nivel de actividad, similitud de la intervención recibida, etc.
4. Seleccione al azar un usuario de los que superan el proceso de emparejamiento.
5. Suponga que envió la intervención original no solo al usuario que realmente la recibió, sino también al usuario que ha seleccionado como control.
6. Mida la diferencia de respuesta entre los usuarios de prueba y de control durante el período de tiempo que le interese.

Nuevamente, puede encontrar más información en el documento sobre arXiv .