Comment exécuter des tonnes d'expériences en même temps à l'aide d'un groupe de contrôle adaptatif ?

Les tests A/B sont en train de mourir, et je suis là pour ça. L'évaluation discrète et limitée dans le temps d'un petit ensemble d'interventions (parfois une seule intervention) ne produit tout simplement pas systématiquement des résultats exploitables de manière durable.

• Il y a trop de choses que vous pourriez potentiellement tester. Dans n'importe quelle situation commerciale réelle, le nombre de choses à tester devient écrasant très rapidement - si vous utilisez un cadre de test A/B. La surcharge est une limitation de l'approche de test, pas une caractéristique de l'environnement de test.

  
  

• L'exécution d'un test peut prendre beaucoup de temps et beaucoup de temps pour exécuter de nombreux tests . Vous devez faire attention à ce que différents tests ne se chevauchent pas chez les utilisateurs qu'ils impactent. Vous devez éviter les jours et les lieux que l'entreprise n'est pas disposée à lier à un test. Il monopolise beaucoup de ressources pour exécuter des tests A/B.

  
  

• Un test sacrifie potentiellement beaucoup d'impact sur la variante perdante - si vous exécutez A contre B pendant un mois et constatez que A a beaucoup mieux fonctionné, cela signifie que vous avez montré à la moitié de vos utilisateurs la variante peu performante pendant un mois entier. Vous avez perdu toute cette valeur. Personne n'est content de ça.

  
  

• L'efficacité à long terme d'un test n'est jamais certaine. L'impact de tout choix que vous faites peut être influencé par l'heure de la journée, le jour de la semaine, la période du mois, la période de l'année, les événements mondiaux, les changements sur le marché - simplement parce que A était meilleur que B le mois où vous l'avez testé, ne veut pas dire que ce sera toujours mieux. Et aucun test A/B ne peut vous dire la durée de conservation de ses résultats.

Si vous voulez une discussion un peu plus approfondie sur les problèmes liés aux tests A/B, les gens de [Babbel](https://Exécuter des tonnes d'expériences en même temps en utilisant un groupe de contrôle adaptatif) ont une bonne présentation sur le sujet, et ce tutoriel sur les commentaires des bandits est une excellente perspective de plusieurs leaders de l'industrie.

Les bandits multi-armés sont l'avenir, et l'avenir est maintenant, et maintenant nous avons de nouveaux problèmes.

Dans un cadre de test A/B traditionnel, vous avez la variante A et vous avez la variante B. Dans la plupart des situations réelles, A ou B est "meilleur" uniquement au sens statistique.

Si vous exécutez un test et que A obtient un taux de réussite de 20 % et que B obtient un taux de réussite de 10 %, A "gagne" clairement… mais qu'en est-il des personnes qui ont répondu à B ? Vont-ils être d'accord pour obtenir A ? Les tests A/B et les algorithmes de bandit vous obligent à sacrifier vos préférences minoritaires au profit de la majorité. Il n'est pas nécessaire que ce soit ainsi - c'est simplement ainsi que fonctionnent ces instruments particuliers. Une meilleure stratégie consiste à proposer l'option A aux personnes qui préfèrent l'option A, et l'option B aux personnes qui répondent à l'option B. Donc :

• Envoyez l'option A à 100 personnes et l'option B à 100 personnes.
• Le taux de réussite de 20 % de l'option A signifie que vous avez obtenu 20 réussite.
• Le taux de réussite de 10 % de l'option B signifie que vous avez obtenu 10 réussite.

Soyons généreux et supposons que la moitié des personnes qui ont répondu à l'option B auraient répondu à l'option A si elles avaient vu cela à la place.

Cela signifie:

• Le fait de ne montrer que l'option A une fois le test terminé donne un taux de réussite de 12,5 % (les 20 personnes qui ont répondu à A, plus les 5 personnes qui ont répondu à B mais qui auraient répondu à A, divisées par les 200 personnes au total dans les deux groupes).
• Envoyer l'option A aux personnes qui veulent A et B aux personnes qui veulent B donne un taux de réussite de 15 %.

Ainsi, en ajustant la façon dont vous déployez chaque traitement en fonction des résultats basés, vous laissez moins de valeur sur la table. C'est tout ce qu'un algorithme de bandit fait - il couvre les paris : B a deux fois moins de succès que A, donc vous montrez B la moitié du temps. Vous pouvez le faire avec de nombreuses options différentes en même temps (pas seulement A et B), le déploiement et le réajustement automatiques rendent l'exécution des tests moins coûteuse, vous ne sacrifiez pas autant de valeur à la perte de variantes, et le système peut s'adapter aux changements dans les préférences de l'utilisateur ou à l'environnement décisionnel plus large.

Tous les problèmes d'A/B testing résolus !

Mais cela peut se retourner contre vous.

À quelle fréquence allez-vous montrer B aux personnes qui préfèrent A, ou montrer A aux personnes qui préfèrent B, parce que vous basez votre décision sur des statistiques globales plutôt que sur des préférences individuelles ? Il est en fait possible que l'algorithme de bandit fonctionne moins bien que le test A/B dans ce genre de situations. Et, bien sûr, toutes ces choses peuvent changer avec le temps. Peut-être que la moitié des personnes qui ont aimé B changent en fait avec le temps pour préférer A. Et un quart des personnes qui ont aimé A changent avec le temps pour aimer B. Vos statistiques globales, et donc la décision que vous prendrez sur ce que vous montrerez à qui , restera exactement le même. Ce n'est pas optimal.

Les algorithmes de bandit réguliers entraînent des coûts cachés - ou plutôt, ils prennent les coûts des tests A/B et les mélangent à différents endroits afin que vous ne le remarquiez pas aussi facilement. Vous configurez votre algorithme et commencez à envoyer et tout semble parfait… jusqu'à ce que vous commenciez à réaliser certains des problèmes que j'ai mentionnés dans les paragraphes précédents. Peut-être que l'équilibre des préférences pour A par rapport à B est différent pour, par exemple, les nouveaux utilisateurs que pour les utilisateurs qui reviennent. Peut-être que ces préférences sont différentes pour différentes zones géographiques. Peut-être que même les utilisateurs expérimentés peuvent être divisés en ceux qui sont des utilisateurs expérimentés et ceux qui ne sont que des habitués. C'est pourquoi les gens ont inventédes bandits contextuels , qui sont en fait un mot fantaisiste pour les bandits plus la segmentation.

Vous devez maintenant faire beaucoup plus de rapports pour comprendre quels segments de votre base d'utilisateurs peuvent avoir des profils de préférences différents. Vous avez donc réduit les rapports nécessaires pour analyser les expériences, mais vous avez augmenté les rapports nécessaires pour cibler votre bandit. Et vous avez augmenté la quantité de travail nécessaire pour transformer ces rapports en une véritable portée. Et une fois que vous avez ces différents segments, vous vous rendez compte que vous avez peut-être besoin de plus de créations pour tenir compte de ce contexte, donc c'est plus de travail. Et puis il y a le travail d'ingénierie pour construire les pipelines qui amèneront le bon utilisateur au bon bandit. Et il y a le travail que vous devez faire dans votre système de messagerie pour vous assurer qu'il prend en charge tout ce qui se passe en arrière-plan.

Ainsi, les bandits résolvent de nombreux problèmes de tests A/B, mais les bandits vraiment efficaces créent de nouveaux besoins analytiques et de nouveaux obstacles logistiques qui ne sont pas faciles à résoudre. C'est l'une des raisons pour lesquelles les tests A/B sont toujours aussi populaires : le processus est suffisamment courant pour qu'il existe de nombreux outils pour vous aider à faire le gros du travail.

Les tests dynamiques nécessitent une évaluation dynamique, qui nécessite un groupe de contrôle dynamique.

J'ai donc aidé à concevoir et à créer un produit qui facilite les tests de bandit contextuels complexes - si facile qu'il crée un contexte distinct pour chaque utilisateur individuel sur votre site ou votre application. Vous pouvez trouver plus de détails sur ce produit ici , ce n'est pas vraiment le but de ce post, donc je n'en parlerai plus. Ce dont je veux parler ici, c'est comment nous avons résolu le problème de l'évaluation de centaines de milliers de tests adaptatifs individualisés par jour.

Les détails peuvent être trouvés dans notre article sur arXiv .

J'ai déjà écrit sur les défis pratiques, analytiques et parfois même éthiques inhérents à la constitution d'un groupe récalcitrant afin d'évaluer les expériences. Je m'en tiens toujours à cela. Nous évaluons nos expériences adaptatives à l'aide d'un contrôle synthétique , car cela n'implique pas de priver les utilisateurs d'interventions potentiellement bénéfiques. Cependant, les méthodes de contrôle synthétique traditionnelles peuvent être pleines de pièges analytiques, car vous modélisez essentiellement le processus de génération de données de base pour l'environnement dans lequel vous menez votre expérience. Ajoutez de nombreuses expériences parallèles, dont beaucoup se déroulent dans des environnements qui se chevauchent, et une solution analytique au problème de contrôle devient… intimidante.

C'est pourquoi nous n'avons pas emprunté cette voie.

Gary King et ses collègues de Harvard, il y a plusieurs années, ont proposé une méthode merveilleusement simple pour tirer une inférence causale à partir de données d'observation. C'est ce qu'on appelle la correspondance exacte grossière (CEM). Vous pouvez trouver l'article fondateur ici et les fondements théoriques ici .

L'idée est simple :

1. Recueillez toutes vos observations de votre intervention (test) en cours.
2. Recueillir un tas d'observations où l'intervention n'a pas eu lieu mais aurait pu avoir lieu.
3. Choisissez des attributs qui peuvent mesurer la similarité entre une paire particulière d'observations des deux groupes.
4. Attributs "Coarsen" en variables catégorielles. Donc, si "âge" est un attribut, vous pouvez le regrouper en catégories d'âge.
5. Faites correspondre chaque observation d'intervention à une observation de non-intervention en fonction de la correspondance exacte des attributs grossiers. Cela signifie que vous ne choisirez qu'un sous-ensemble d'observations de non-intervention, et souvent vous finirez également par supprimer certaines de vos observations d'intervention, mais ce qui vous reste sera mis en correspondance.
6. Modélisez la différence entre les deux groupes raffinés.

CEM éloigne la complexité de l'inférence causale des méthodes analytiques - vous pouvez utiliser la méthode que vous préférez - et la place à la place dans les méthodes de création d'ensembles de données. C'est similaire, conceptuellement, au sur- ou sous-échantillonnage d'un ensemble de données de déséquilibre dans un problème de classification.

Ce que nous avons réalisé, c'est que nous pouvions utiliser ce même type de logique pour trouver des contextes de contrôle appropriés pour nos expériences de bandits en incluant le temps comme l'une des caractéristiques à faire correspondre. Nous correspondons déjà sur certains attributs d'intervention - le type d'intervention qu'un utilisateur a reçu et le niveau d'activité que l'utilisateur a affiché sur l'application au moment de l'intervention. Mais ensuite nous définissons également une fenêtre d'observation et nous nous assurons que tout utilisateur apparié aura reçu une intervention à une période proche de l'intervention pour laquelle nous recherchons un contrôle, mais pas dans la période d'observation de l'intervention elle-même.

Cela nous permet d'avoir des contrôles correspondants au niveau de l'utilisateur pour la majorité des tests que nous exécutons. Les algorithmes de bandit éliminent une partie de la complexité des tests A/B à grande échelle, mais masquent d'autres parties de cette complexité. Notre méthode de contrôle prend cette complexité cachée et la résout afin que nous puissions obtenir les avantages adaptatifs de l'affectation des bandits, mais l'inférence et l'attribution claires des tests A/B.

Voici donc votre liste de choses à faire :

1. Pour chaque intervention que vous faites, identifiez une fenêtre d'anticipation et une fenêtre d'analyse. La fenêtre d'anticipation est ce que vous utilisez pour voir comment l'utilisateur a répondu à l'intervention, et la fenêtre d'analyse est l'endroit où vous recherchez des cas de contrôle.
2. Pour chaque intervention, identifiez un groupe d'autres interventions qui (1) ont eu lieu dans la fenêtre d'anticipation, et (2) n'ont pas de fenêtre d'anticipation qui chevauche la fenêtre d'anticipation de l'intervention pour laquelle vous recherchez un contrôle.
3. Faites correspondre les utilisateurs qui ont reçu ces interventions de contrôle potentielles avec l'utilisateur qui a reçu l'intervention pour laquelle vous recherchez un contrôle. Vous pouvez faire correspondre tous les critères que vous souhaitez - niveau d'activité, similitude de l'intervention reçue, etc.
4. Sélectionnez au hasard un utilisateur parmi ceux qui réussissent le processus de correspondance.
5. Imaginez que vous avez envoyé l'intervention d'origine non seulement à l'utilisateur qui l'a réellement reçue, mais également à l'utilisateur que vous avez sélectionné comme témoin.
6. Mesurez la différence de réponse entre vos utilisateurs de test et de contrôle pour la période qui vous intéresse.

Encore une fois, vous pouvez trouver plus d'informations dans l'article sur arXiv .