Comment DoorDash repousse les limites de l'expérimentation avec des dessins entrelacés

We've traditionally relied on A/B testing at DoorDash to guide our decisions. However, when precision and speed are crucial, this method often falls short. The limited sensitivity of A/B tests - their ability to detect real differences between groups - can result in users being exposed to suboptimal changes for extended periods. For example, in our search and ranking use cases, achieving reliable results often required several weeks of testing across all traffic, which not only delays the introduction of new ideas but also prolongs the negative impact of underperforming changes.

Interleaving design offers significantly higher sensitivity - more than 100 times that of traditional methods - by allowing multiple conditions to be tested simultaneously on the same user as shown in Figure 1. Interleaving design generally provides a more accurate and granular understanding of user preferences, allowing us to iterate more quickly and with higher confidence.

In this post, we dive into how we've implemented interleaving designs at DoorDash. We also explore how we've refined the design to be even more sensitive than what is reported in the industry (see Table 1), discuss the challenges we've faced, and provide recommendations for handling those challenges.

Ce qui rend les modèles entrelacés très sensibles

Presque toutes les statistiques relatives à l'expérimentation peuvent être résumées par la formule conceptuelle qui tient compte du rapport signal/bruit. Si vous souhaitez que les expériences fournissent des informations plus claires, vous pouvez le faire :

• Renforcer le signal: Testez des changements significatifs, où les hypothèses sont fondées sur des anecdotes ou des données courantes. Il faut également s'assurer que les utilisateurs sont exposés au changement et qu'ils s'y engagent.  
• Réduire le bruit: Expliquez le bruit à l'aide de techniques telles que CUPED - expérience contrôlée utilisant des données pré-expérimentales - ou générez des populations plus homogènes. Vous pouvez également choisir d'augmenter la taille des échantillons.

La plupart des gens ont supposé que l'entrelacement permettait d'obtenir des résultats sensibles en réduisant le bruit. Plus précisément, étant donné qu'un utilisateur est exposé à toutes les conditions de traitement, la conception contribue naturellement à réduire la variance, car chaque utilisateur sert de contrôle. Mais outre cet avantage, nous avons remarqué que la mise en place de l'entrelacement permet d'améliorer le signal dans les données grâce à deux propriétés, comme le montre la figure 2 :

• Identifie le non-engagement: L'entrelacement permet d'identifier les utilisateurs qui ne participent pas activement au contenu et de les supprimer.

• Identifie les paires non compétitives: Nous pouvons également identifier les cas où les classificateurs génèrent des listes d'apparence similaire, ce qui nous permet de renforcer le signal en supprimant les données où les recommandations entre le traitement et le contrôle sont trop similaires.

Ces deux techniques vous permettent d'améliorer encore la sensibilité de l'entrelacement car elles éliminent efficacement la dilution des données, comme nous l'avons vu dans notre précédent article sur la dilution. Dans la section suivante, nous expliquons pourquoi ces trois facteurs sont si importants pour améliorer la sensibilité. 

Contrôle de la variance intra-sujet

A fundamental reason for why interleaving designs are so much more sensitive than regular A/B designs is that the same user is tested under multiple conditions, allowing each participant to serve as their own control. For example, the device used, a user's search preferences, or other relevant information are all controlled by the nature of the design. Internally, when explaining the benefits of interleaved designs to stakeholders, we say that it's like running A/B tests in which all your subjects are identical twins. But not just any twins - these are perfect clones who share the same phenotype and environment right up to the moment you run the test. This imagery helps people understand that interleaved designs have an enormous potential to drive down variance. Despite the widespread use of within-subjects (repeated) designs in industries such as pharma, education, neuroscience, and sports science, their relative lack of adoption in the tech industry remains a surprising anomaly.

Dans l'entrelacement, l'effet de la conception intra-sujet est encore plus prononcé car nous présentons simultanément les conditions de traitement sur le même écran, ce qui minimise les variables confusionnelles telles que les effets d'apprentissage, les effets croisés ou d'autres facteurs de confusion temporels, comme le montre la figure 3. Dans le contexte de DoorDash, l'un des facteurs de confusion les plus importants est le niveau de faim de l'utilisateur lorsqu'il arrive sur notre application. Plutôt que de présenter un classificateur le jour 1 et un autre le jour 2, les présenter dans le même contexte nous permet d'éliminer le bruit dû aux niveaux de satiété.

Gestion de la dilution due aux paires concurrentes

Interleaved designs also drive up sensitivity by showing if the experience exposed to the user is truly different between treatment and control. An interleaved design generates final output from two lists, allowing us to identify immediately whether those lists are too similar, as shown in Figure 4 below. In most machine learning applications, different modeling approaches are improvings things on the margin. In many cases, the search results returned by two rankers will largely overlap. An interleaved design lets us measure this overlap and analyze the data for competitive pairs - where rankers disagree on the recommendation - which leads to a signal boost. 

Gestion de la dilution due au non-engagement

An interesting observation we made when looking at interleaved experiments - as well as search and ranking experiments in general - is that many user actions make it look as if the user is not paying attention or making any choices on the presented content. For instance, although we would generate a carousel with interleaved options, the user would not actively engage with the content and make a decision. As a result, including this data in interleaved analyses dilutes the signal.

Here is another way to understand non-engagement. Let's say we present a user with two drinks - Coke and Pepsi - and ask them which they like more. If the user does not engage or refuses to try any options, it might indicate:

• L'utilisateur n'est pas intéressé par les résultats présentés.
• L'utilisateur n'est pas dans un état d'esprit de prise de décision à ce moment-là.

While these are important insights, examining data from this undifferentiated feedback does not help to determine user preference or understand which drink is preferred. Attention and non-engagement is a fascinating research subject; many folks approach it by looking at additional metrics such as dwell time or how often a user backtracks as per Chucklin and Rijke, 2016. Fortunately, interleaving allows us to identify non-engagement more effectively so that we may remove impressions that are not meaningful. If a user does not take an action, we simply remove the exposure rather than marking the performance of the interleaved ranker as a tie.ctively so that we may remove impressions that are not meaningful. If a user does not take an action, we simply remove the exposure rather than marking the performance of the interleaved ranker as a tie. A/B tests can't effectively address non-engagement because they treat all data equally, including non-engaged interactions, which dilutes the signal and obscures true user preferences.

Résultats

Le tableau 2 présente les résultats de cinq expériences en ligne dans lesquelles nous indiquons l'amélioration moyenne de la sensibilité relative entre les différentes méthodes par rapport à une configuration A/B. Dans plusieurs expériences, nous avons constaté que la suppression de la dilution permettait d'accroître encore davantage la sensibilité de l'entrelacement, ce qui se traduit par des tailles d'échantillon requises beaucoup plus faibles. Ces résultats nous ont tellement surpris que nous avons dû nous arrêter plusieurs fois pour effectuer des tests A/A supplémentaires afin de nous assurer que nous n'avions pas introduit de bogue dans notre SDK, notre pipeline d'analyse ou le calcul des métriques. 

It's important to highlight that the sensitivity improvement depends on the metric.  For clickthrough rate, we have observed half of the sensitivity boost observed in the checkout-conversion metric. Nonetheless, across all use cases we found that removing dilutive exposures drives very large gains in sensitivity.

Configuration et évaluation des expériences d'entrelacement

Les designs entrelacés sont entièrement pris en charge par DoorDash, avec une intégration transparente dans notre SDK, l'interface utilisateur d'expérimentation et les outils d'analyse internes. Cette intégration étroite garantit que les équipes habituées aux tests A/B peuvent passer aux modèles entrelacés d'une manière standardisée, minimisant ainsi l'effort d'intégration. Dans cette section, nous explorons les détails clés de la mise en œuvre de l'intégration de la randomisation par entrelacement dans notre SDK d'expérimentation.

Traditional A/B experiments know the values that should be served at the time the experiment is configured. At its simplest, an A/B experiment would be configured with the values of either false - for the control experience, or true - for the treatment experience that enables the feature. At runtime, the business logic would read the true/false value directly from the experiment.

Prenons l'exemple d'une interface client A/B traditionnelle :

interface TraditionalClient {
  fun getBoolean(
      // The name of the experiment to evaluate
      name: String,

      // Contextual information to determine outcome and randomization
      context: Context,
     
      // A safe value to use in case of errors
      fallback: Boolean,
  ): Boolean
}

L'appel au client pourrait ressembler à ceci :

val isEnabled = client.getBoolean("is_new_feature_enabled", Context(), false)

If (isEnabled) {
    newFlow()
} else {
    oldFlow()
}

L'entrelacement diffère de la méthode A/B traditionnelle en ce sens que les listes d'objets entrelacés ne peuvent pas être connues au moment de la configuration. Toutefois, cette distinction ne nous empêche pas d'utiliser nos objets d'expérience existants pour contrôler un flux d'expériences entrelacées. Par exemple, une interface d'expérience nous aide toujours :

1. Décider qui doit participer à l'expérience
2. Ajout progressif d'utilisateurs à l'expérience
3. Éteindre l'expérience à distance
4. Sélection d'une variante gagnante

Pour les expériences d'entrelacement, les variantes nous indiquent quelles listes doivent être entrelacées, le cas échéant, au lieu de nous dire explicitement quelle valeur servir.

Un client d'entrelacement se présente comme suit :

// The client can interleave any object as long as it implemented 'Interleavable'
interface Interleavable {
   // The type of object. 'store' as an example
   fun itemKey(): String

   // A unique key representing the underlying object. The store's ID an example
   fun itemId(): String
}


// Essentially a named list of objects that may be interleaved
interface InterleaveData<T : Interleavable> {
   val name: String
   fun items(): List<T>
}

interface InterleavingClient {
   // Templated interface. Pass in any object you want to interleave as long as it is "interleavable"
   fun <T : Interleavable> interleave(
       // A unique identifier used to connect the result to an analysis metric
       interleaveId: String,

       // The name of the experiment that controls if the experiment is enabled and what lists to interleave
       experiment: String,

       // Context that defines the user. Determines whether the user has access to the experiment
       context: Context,

       // A fallback list of items if anything goes wrong
       fallback: InterleaveData<T>,

       // A list of the named lists that might be interleaved as part of the result
       vararg data: InterleaveData<T>,
   ): List<T>
}

L'expérience peut être configurée pour séparer différents groupes d'utilisateurs en segments. Dans la méthode A/B traditionnelle, c'est le segment correspondant qui décide en fin de compte de la valeur servie à l'utilisateur. Ici, c'est le segment apparié qui décide laquelle des listes doit être intercalée. Cela signifie qu'au moment de l'exécution, vous pouvez introduire un nombre arbitraire de listes et choisir dynamiquement un sous-ensemble d'entre elles à entrelacer. 

Exemple :

val control = FixedInterleaveData(
   variantName = "control",
   items = listOf(Food("apples"), Food("bananas"), Food("cucumbers")),
)

val treatment1 = FixedInterleaveData(
   variantName = "treatment_1",
   items = listOf(Food("oranges"), Food("apples"), Food("cucumbers")),
)

val treatment2 = FixedInterleaveData(
   variantName = "treatment_2",
   items = listOf(Food("oranges"), Food("tomatoes"), Food("bananas")),
)

val result = client.interleave(
   interleaveId = "8346168",
   experiment = "food_experiment",
   fallback = control,
   context = Context(),

   // 3 different named lists are passed in
   control,
   treatment1,
   treatment2,
)

Nous avons ici trois listes d'aliments nommées : control, treatment_1 et treatment_2. L'expérience food_experiment décidera en fin de compte laquelle de ces listes doit être tissée en fonction du contexte transmis et de la manière dont food_experiment a été configuré. Une, deux ou les trois listes peuvent être sélectionnées.

Vous remarquerez que les listes d'aliments sous-jacentes sont configurées via des données d'entrelacement fixes. Chaque tableau d'éléments est réalisé immédiatement avant même d'appeler interleave. Cela peut être problématique si vous prévoyez de tester plusieurs listes et que le coût de génération de chaque liste est élevé. Pour éviter les appels coûteux et fastidieux, nous proposons également des données d'entrelacement paresseuses :

data class LazyInterleaveData<T : Interleavable>(
  override val variantName: String,
  val itemGenerator: () -> List<T>,
) : InterleaveData<T>

L'ingénieur doit fournir la fonction responsable de la génération de la liste sans réaliser la liste immédiatement. Le client d'entrelacement sous-jacent n'exécutera les générateurs que pour le sous-ensemble de listes nécessaires à l'entrelacement. Cela permet d'atténuer les problèmes de performance lorsque les listes entrelacées sont très volumineuses.

Algorithme d'entrelacement

As an abstraction, think of each list to be interleaved as containing players to be drafted for a single team. The same player may show up on each list but at a different rank. Assume each list of players is ordered from most- to least-favorite. To continue the analogy, let's look at an example in which we label the lists as teams. 

L'algorithme d'entrelacement peut être expliqué plus facilement par le fait que N capitaines d'équipe sélectionnent leurs joueurs. Imaginez la situation suivante :

1. Chaque capitaine dispose d'une liste de joueurs classés du plus souhaitable au moins souhaitable.
2. Some players may exist on a few of the captains' lists, while others may only exist on a single captain's list.
3. À chaque tour, tous les capitaines recrutent un joueur pour leur équipe. Chaque capitaine appelle le joueur le plus souhaitable qui n'a pas encore été sélectionné.
   • If all captains select different players, then we insert the players into each list in order of the captain's preference. The players then belong to the respective captains who selected them. All players are marked as competitive.
   • If some captains attempt to select the same player during a turn, we find an untaken player in the captain's list. This player and all players added this turn are marked as not competitive.
   • Les joueurs compétitifs viennent toujours en groupes de taille égale au nombre de capitaines.
4. Si un capitaine n'est pas en mesure de sélectionner un joueur lors d'un tour donné, tous les joueurs sélectionnés lors de ce tour sont marqués comme non compétitifs.
5. Parmi les joueurs sélectionnés en compétition, il y aura un nombre égal de choix par chaque capitaine.

Exemple de listes quasi identiques

Cet exemple montre que les deux capitaines font des choix similaires pour les quatre premiers éléments, qui sont donc considérés comme non compétitifs. Seuls les deux derniers éléments reflètent une nette différence dans les recommandations des capitaines. 

Exemple de listes non concordantes

In this example, the first player is preferred by both captains. Because both captains have the same preference, performance due to player A is not considered when measuring the captains' success in drafting players. Using data from noncompetitive pairs would hurt the signal we can measure in the experiment.

Comment nous gérons l'attribution des événements

One of the most challenging aspects of setting up interleaving at DoorDash is figuring out how to handle event attribution. We've done an extensive literature review on this topic and talked with multiple practitioners from other companies that implemented interleaving. We were surprised to find very little consistency in the approach to performance attribution.

L'approche la plus courante consiste à agréger un score de préférence sur une ou plusieurs sessions, voire sur plusieurs jours, pour chaque utilisateur. Le résultat, obtenu à l'aide de la formule illustrée à la figure 5, calcule pour chaque utilisateur un score qui indique s'il aime le classeur A ou B en fonction de son comportement en matière de clics.  

Bien que cette approche puisse fonctionner, elle pose deux problèmes :

• Met l'accent sur les clics: Cette approche limite votre capacité à ne prendre en compte que les clics pour calculer les scores de préférence. Par exemple, un classificateur obtiendrait un gain en générant plus de clics, même si les mesures en aval, telles que les achats, sont principalement affectées par un autre classificateur.
• Ne gère pas la dilution: Comme indiqué précédemment, la plupart des données relatives à la recherche et au classement n'ont pas d'activité métrique. L'utilisateur contribue effectivement à un zéro pour tous les traitements. L'inclusion des égalités rend les configurations d'entrelacement moins sensibles. 

Overall, we went with an approach that favors direct attribution. We track metrics associated with user behavior at the most granular level - the individual item level. Figure 6 below showcases how we collect data and aggregate it before running a paired t-test. Note that the whole process is handled automatically in our system; users don't have to write any complex pipelines for generic use cases and an analysis can be set up in less than two minutes. 

La suppression des expositions dilutives pose un problème en rendant difficile l'établissement de comparaisons entre expériences pour une mesure donnée. Nous résolvons toutefois ce problème en traduisant l'impact localisé en impact global, en supposant que les unités de contrôle et de traitement reçoivent toutes deux le nouveau classificateur de traitement. La figure 7 ci-dessous montre comment les estimations de l'impact localisé et de l'impact global sont présentées à nos utilisateurs. Un utilisateur peut alors utiliser la mesure de l'impact global pour mieux comprendre si son traitement fera bouger l'aiguille de manière significative.

Défis de l'entrelacement 

L'entrelacement des plans n'est pas une solution miracle pour améliorer la sensibilité des expériences. Dans l'ensemble, les expériences d'entrelacement génèrent plus de complexité et s'accompagnent de problèmes de généralisation. Dans ce qui suit, nous décrivons certains des défis et nos recommandations sur la manière de les relever.

Mesurer les différences de performance

Lors de la mise en place d'une expérience d'entrelacement, nous devons générer les listes entrelacées avant la randomisation, ce qui implique généralement de faire appel à deux algorithmes de classement. Même si les appels sont effectués de manière asynchrone ou par le biais d'une évaluation paresseuse, l'impact de la latence sur le système peut être suffisamment important pour que la configuration de l'entrelacement ne parvienne pas à capturer une dégradation. Considérons le scénario suivant : 

• Le Ranker A donne des résultats moins précis, mais sa latence est très bonne et il ne perturbe pas l'expérience de l'utilisateur.
• Le Ranker B affiche des résultats plus pertinents, mais il est 40 % plus lent que le Ranker A et pourrait perturber l'expérience de l'utilisateur.

During initial testing of the two rankers in an interleaved setup, it may seem that ranker B outperforms A in terms of relevance and user satisfaction based on metrics such as click-through and conversion rates. This conclusion would be misleading. Interleaved metrics might not capture ranker B's latency and subsequent performance degradation, offsetting the impact of ranker B's more relevant results. 

Recommandation

Fortunately there is a very simple solution to this problem. As shown in Figure 8 below, you can analyze interleaved traffic against reserved traffic in the context of an A/B experiment by specifically targeting app performance metrics. Specifically, divide the traffic into interleaved and reserved; because the traffic allocation is random, you can run a regular A/B test. If the resulting metrics indicate that the interleaved traffic has caused substantial app performance degradation, you can then follow up to optimize the ranking system's reliability. Note that this solution is free because we generally recommend that users perform an A/B test in parallel with an interleaved experiment.

Validité externe et effets d'interférence

Les expériences d'entrelacement peuvent poser des problèmes liés à la validité externe. Dans la pratique, les utilisateurs interagissent généralement avec un seul classificateur à la fois plutôt qu'avec un mélange de plusieurs classificateurs. Selon les circonstances, cela signifie que la configuration de l'entrelacement peut ne pas se généraliser au comportement réel de l'utilisateur en dehors de la phase de test. En outre, en exposant un utilisateur à de multiples alternatives, nous renonçons à notre capacité à mesurer les effets à long terme ; nous ne pouvons mesurer que ce que les utilisateurs préfèrent à un moment donné, lorsqu'ils peuvent comparer et opposer plusieurs éléments d'une liste.

To best illustrate why external validity is important, consider the hypothetical job offer example shown in Figure 9 below. If you're asked to select a salary - either $50,000 or $100,000 per year - you likely will behave rationally and choose the higher amount. But if you're given only one choice - $50,000 - without the ability to compare and contrast, the likelihood of you accepting that offer will be higher than zero. In other words, if users are offered only one choice, they might take it simply because there is no alternative. This highlights that interleaving designs can effectively amplify user preferences even when A/B testing might lead to a flat effect. 

Recommandation 

Pour les équipes qui commencent à mener des expériences intercalaires, nous recommandons d'adopter une approche en deux phases afin d'obtenir des preuves empiriques du lien entre les résultats des tests intercalaires et des tests A/B. Il est à noter que les deux phases peuvent être menées en parallèle. Notez que les deux phases peuvent se dérouler en parallèle. L'objectif final est de comprendre si la configuration entrelacée génère un ensemble de conclusions cohérentes similaires à celles d'une expérience A/B. Si, après une douzaine d'expériences, la relation entre les mesures entrelacées et les mesures A/B est forte, vous pouvez vous fier plus souvent à la seule configuration entrelacée pour prendre des décisions concernant les navires.

Garder le rythme

Un autre problème posé par les conceptions entrelacées est qu'elles offrent des améliorations de sensibilité si importantes qu'une équipe n'a peut-être pas encore mis en place un processus permettant de tirer parti de l'amélioration de la vélocité. Imaginez ce à quoi le processus pourrait ressembler avant et après l'adoption de l'entrelacement, comme le montre la figure 10 :

• Before interleaving: Teams typically ran experiments for two to six weeks. The focus was primarily on significant model changes likely to yield clear results, which lead to emphasizing zero-to-one work rather than incremental improvements such as removing features or testing refactoring work. Experiment decisions were made during weekly review meetings where new experiments were discussed and planned. Changes were tested on a large proportion of traffic - more than half. This increased the risk of exposing a significant number of users to potentially suboptimal model variants for extended periods.
• Après l'entrelacement : Le temps nécessaire pour obtenir des résultats concluants est passé de plusieurs semaines à quelques heures. Le processus de prise de décision a été automatisé et se concentre désormais sur la minimisation des risques. Lorsque les mesures se dégradent, les ingénieurs peuvent revenir rapidement sur les changements sans attendre la prochaine réunion d'évaluation. Les expériences réussies sont rapidement promues en tests A/B afin d'évaluer l'impact à long terme. La prise de décision est décentralisée, ce qui permet à chaque membre de l'équipe de lancer des expériences dans le cadre de garde-fous spécifiques. Le rayon d'exposition aux variantes sous-optimales est réduit à moins d'un ou deux pour cent du trafic ; la capacité de mesurer efficacement l'impact des changements permet aux équipes de consacrer davantage d'efforts aux améliorations progressives. 

To get the highest possible leverage from interleaving, you need to optimize other parts of the process. Although methodological advancements play a key role in driving experimentation velocity, it's also important to reflect on the role of process and culture. If teams are not structured to operate with extreme levels of ownership, a clear guardrails process, and minimal red tape, increased levels of sensitivity may not help drive faster and better product iteration. In the next section, we detail how teams can improve their capacity to run more experiments to keep up with the improvements inherent in interleaving.

Recommandation : Réduire les temps de rampe, de collecte et de décision

Tout d'abord, nous recommandons aux équipes de suivre un ensemble restreint d'indicateurs industriels qui fournissent un bon signal sur le succès des classeurs. Il est courant que les expériences de recherche et de classement comportent des dizaines d'indicateurs qui examinent l'impact d'un changement de plusieurs points de vue. Il est toutefois important de maintenir la charge cognitive à un niveau peu élevé, afin de permettre aux ingénieurs de se concentrer sur deux ou trois mesures seulement qui présentent des compromis clairs. Nos recommandations sont les suivantes :

Avec ces trois paramètres, les utilisateurs peuvent ensuite suivre le cadre décisionnel ci-dessous :

By focusing on these metrics and decision-making framework, you can heavily reduce the durations involved in ramping, collecting, and - most importantly - deciding on next steps. This keeps the team's cognitive burden for decisions low. 

Recommandation : Réduire les délais de développement

Bien que les nouveaux travaux soient toujours ceux qui demandent le plus d'efforts, la sensibilité accrue des conceptions d'entrelacement permet de tester des changements qui n'étaient pas réalisables auparavant. Voici quelques exemples de ce que l'entrelacement rend possible :

• L'élagage des caractéristiques: Grâce à l'entrelacement, nous pouvons déterminer rapidement et précisément l'impact de la suppression de certaines caractéristiques des algorithmes de classement. Par exemple, si certaines fonctionnalités sont fragiles et difficiles à maintenir, nous pouvons tester leur suppression pour voir si elles sont vraiment nécessaires au maintien de la qualité du classement. Cela pourrait permettre d'alléger la base de code et d'en faciliter la maintenance sans compromettre les performances.
• Micro-optimisations : L'entrelacement nous permet de tester de petits changements progressifs qui auraient pu être trop subtils pour être mesurés avec précision avec des tests A/B traditionnels. Il peut s'agir de modifications des pondérations de classement, d'ajustements mineurs des paramètres de l'algorithme ou de légères modifications dans le calcul des fonctionnalités. Ces micro-optimisations peuvent se traduire par des améliorations significatives de l'expérience globale de l'utilisateur.
• Ajustements de l'opérateur: Il est rare que les résultats du classement soient utilisés tels quels. Dans la pratique, certains résultats sont renforcés par des opérateurs extérieurs à la boucle de classement. Malheureusement, ces changements sont rarement vérifiés et testés. Grâce à l'entrelacement, les opérateurs peuvent avoir une meilleure visibilité sur l'efficacité de leurs ajustements.  
• Traitement des cas particuliers: Il est difficile d'optimiser un système en fonction de types de requêtes peu courants ou de cas particuliers lors de l'élaboration de modèles de classement. Grâce à l'entrelacement, il devient plus facile de mesurer les améliorations progressives résultant de l'optimisation de la queue des résultats de recherche.

En résumé, l'entrelacement permet de tester un plus grand nombre de caractéristiques de manière itérative et avec une plus grande précision.

Recommandation : Mettre en place des garde-corps

Étant donné que les expérimentateurs disposent d'une plus grande marge de manœuvre et s'approprient davantage l'entrelacement, des garde-fous appropriés doivent être mis en place pour éviter les erreurs et décourager les comportements non conformes aux intérêts de l'utilisateur. Nos recommandations sont les suivantes

• Limiter le trafic à 2 ou 5 %: Appliquer une limite stricte à l'allocation du trafic pour une expérience d'entrelacement donnée. Utilisez des outils de surveillance pour garantir le respect de cette limite et alerter ou interrompre automatiquement les expériences qui la dépassent. Étant donné la nature très sensible des conceptions d'entrelacement, il ne devrait y avoir aucune raison d'augmenter le rayon d'action au-delà de 5 %. 
• Increase transparency: Ensure that all of a team's experimental changes are done so that team members and managers can get a bird's-eye view of everything. Dashboards that collocate all actively running experiments and draw a heatmap from metric movements can quickly highlight any required actions. We also recommend creating a shared communication channel for alerts.
• Reculs automatisés: Établir et appliquer des retours en arrière automatisés qui arrêtent l'expérience lorsque cela est nécessaire. Les scénarios décrits dans les compromis métriques peuvent être entièrement codés pour automatiser ce processus de prise de décision.
• N'examiner que les promotions A/B : Consacrer l'essentiel de l'attention à l'examen des décisions de promotion à la phase A/B plutôt qu'à l'examen des expériences d'entrelacement.

Recommandation : Accumulez les victoires avant de passer à la phase A/B

To increase velocity, don't immediately promote any winning ranker candidate from an interleaving experiment to an A/B setup. Because interleaving designs offer more than a 100-fold increase in sensitivity, an A/B experiment might not be powerful enough to capture a change. Instead, we recommend that engineers continuously iterate within an interleaving setup and only move a ranker to A/B after they have stacked sufficient improvements.  

Conclusion

L'entrelacement peut changer la donne en améliorant la sensibilité des expériences. En augmentant de manière significative la sensibilité des expériences, il permet de détecter des changements significatifs beaucoup plus rapidement et avec plus de précision que dans les tests A/B traditionnels. Plus important encore, il permet de réaliser des tests dans un rayon d'action beaucoup plus restreint, évitant ainsi à la majorité du trafic d'être exposée à des idées de mauvaise qualité. 

Interleaving's success hinges on its ability to reduce noise and increase signal through within-subject variance control and to handle dilution from noncompetitive pairs and non-engagement. These advantages make interleaving an essential tool for our teams, enabling them to make data-driven decisions rapidly and with greater confidence. Nonetheless, to harness the full potential of interleaving, it's crucial to establish robust guardrails and change the culture and process of experimentation. Teams with suboptimal experimentation workflows ultimately won't be able to leverage interleaving effectively.

Overall, we're excited to have built a platform that supports interleaving and makes the configuration and analyses of these setups easy to perform. 

Remerciements

Merci à Jay Zhang de l'équipe Homepage et à Muxi Xu de l'équipe New Verticals de nous avoir aidés à configurer et à tester les configurations d'entrelacement. Merci à Janice Hou de nous avoir aidés à définir les sources d'événements utilisées dans le calcul des métriques. Nous remercions également Yixin Tang et Qiyun Pan pour leur aide dans l'extension de la méthode delta afin de prendre en charge les tests t appariés, ainsi que Jun Jin et Qilin Qi pour avoir insisté sur la priorité à donner au travail d'entrelacement. Merci également à Sagar Akella pour ses précieux commentaires sur cet article de blog.