🤖 AI

HMAF: A Hierarchical Multi-Slot GD-RTB Allocation Framework

Le papier propose HMAF, un cadre hiérarchique unifié qui intègre l'optimisation de contraintes hors ligne avec la prise de décision par liste en ligne pour équilibrer efficacement l'exécution des contrats de livraison garantie à long terme et la maximisation des revenus d'enchères en temps réel à court terme dans des environnements publicitaires multi-emplacements complexes, atteignant des améliorations de performance significatives dans les scénarios de marketing de Meituan.

Auteurs originaux : Tianxing Bu, Zhaoqi Zhang, Linyou Cai, Miao Xie, Shengri Xue, Tan Qu, Qianlong Xie, Xingxing Wang, Siqiang Luo, Gao Cong

Publié 2026-06-10

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Tianxing Bu, Zhaoqi Zhang, Linyou Cai, Miao Xie, Shengri Xue, Tan Qu, Qianlong Xie, Xingxing Wang, Siqiang Luo, Gao Cong

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un restaurant très fréquenté (la plateforme publicitaire) qui possède deux types de clients :

Les VIP (Contrats GD) : Ce sont de gros annonceurs qui ont signé un contrat il y a plusieurs mois. Ils ont payé un prix fixe et ont dit : « Nous devons obtenir 10 000 réservations de tables (impressions publicitaires) au cours du mois prochain, peu importe les conditions. » Si le restaurant ne parvient pas à les installer, il doit payer une pénalité.
Les clients de passage (Publicités RTB) : Ce sont des annonceurs qui arrivent chaque jour et disent : « Je paierai le prix du marché actuel pour une table en ce moment même. » Le restaurant veut remplir ces tables avec les enchérisseurs les plus généreux afin de gagner le plus d'argent possible aujourd'hui.

Le Problème :
Le restaurant dispose d'un nombre limité de tables (emplacements publicitaires) sur chaque page. Parfois, les VIP ont besoin d'une table, mais les clients de passage offrent une somme énorme pour cette même table.

Si vous donnez la table au client de passage, vous gagnez plus d'argent aujourd'hui, mais vous risquez de ne pas avoir assez de tables pour les VIP d'ici la fin du mois.
Si vous donnez la table au VIP, vous gardez son contrat satisfaisant, mais vous pourriez manquer une énorme rentrée d'argent provenant d'un client de passage.
Les systèmes précédents essayaient de résoudre cela soit en ignorant les VIP jusqu'à la fin du mois (ce qui est risqué), soit en utilisant des règles simples et rigides comme « Les VIP passent toujours en premier » (ce qui gaspille de l'argent).

La Solution : HMAF (Le Gestionnaire de Restaurant Intelligent)
Le document présente un nouveau système appelé HMAF (Hierarchical Multi-Slot Allocation Framework - Cadre d'allocation hiérarchique multi-emplacements). Considérez-le comme une équipe de gestion en trois étapes qui fait fonctionner votre restaurant parfaitement.

Étape 1 : Le Planificateur (La phase « Plan »)

Avant même que le restaurant n'ouvre pour la journée, le Planificateur examine tout le calendrier du mois.

Ce qu'il fait : Il calcule exactement combien de tables les VIP ont besoin et combien sont disponibles. Il détermine le « prix fictif » (shadow price) de chaque table.
L'analogie : Imaginez que le Planificateur réalise : « La table 4 au deuxième étage est très populaire, mais nous n'en avons que 5. Si nous donnons la table 4 à un VIP, cela nous coûte beaucoup de revenus potentiels des clients de passage. Mais si nous la donnons à un client de passage, nous pourrions manquer le contrat du VIP. »
Le résultat : Le Planificateur crée un ensemble de « règles de base » (appelées variables duales) qui indiquent au personnel : « La table 4 est chère en ce moment ; ne la donnez à un VIP que s'il est vraiment urgent. Sinon, gardez-la pour les clients de passage à haut revenu. »

Étape 2 : Le Calibreur (La phase « Calibrate »)

Lorsqu'un client arrive (un utilisateur ouvre l'application), le Calibreur prend les règles du Planificateur et ajuste les scores des publicités en temps réel.

Ce qu'il fait : Il observe les VIP et les clients de passage. Si un contrat VIP est en retard sur son objectif de livraison, le Calibreur donne à ce VIP un « boost » dans son score, le rendant plus susceptible d'obtenir une table. Si un VIP est déjà en avance, le boost est supprimé.
L'analogie : C'est comme un agent de circulation à la porte. Si la section VIP est vide, l'agent fait entrer les VIP plus rapidement. Si la section VIP est pleine, l'agent laisse entrer les clients de passage qui paient le plus cher. Il équilibre les deux groupes de manière dynamique, seconde après seconde.

Étape 3 : L'Exécuteur (La phase « Execute »)

C'est le décideur final qui attribue réellement les tables.

Ce qu qu'il fait : Dans un restaurant moderne, vous n'avez pas seulement une table, mais toute une rangée de tables (une page « multi-slots »). L'Exécuteur ne choisit pas seulement la meilleure table unique ; il choisit la meilleure disposition pour toute la rangée.
L'analogie : Imaginez l'Exécuteur comme un chef dressant un plateau. Il ne se contente pas de mettre le plat le plus cher au milieu ; il dispose l'ensemble du plateau (l'écran de l'utilisateur) de manière à ce que les VIP obtiennent leurs places spécifiques sans bloquer la vue des clients de passage, tout en s'assurant que l'ensemble du plateau soit esthétique et rapporte le plus d'argent.
La Magie : Cette partie utilise un réseau « Générateur-Évaluateur ». Le Générateur crée quelques dispositions de places possibles (par exemple : « Et si nous mettions le VIP ici et le client de passage là ? »). L'Évaluateur agit comme un juge, examinant toutes ces options et choisissant celle qui rapporte le plus d'argent tout en satisfaisant les VIP.

Les Résultats

Le document indique que ce système a été testé chez Meituan, une plateforme géante de livraison de nourriture en Chine (considérez cela comme un immense restaurant numérique).

Le résultat : En utilisant ce gestionnaire en trois étapes, Meituan a réussi à installer 3,72 % de VIP en plus (remplissant plus de contrats) ET à gagner 1,59 % d'argent total en plus grâce aux clients de passage.
Pourquoi c'est surprenant : Habituellement, si vous installez plus de VIP, vous gagnez moins d'argent car vous ne pouvez pas facturer autant aux clients de passage. Mais parce que HMAF est très intelligent sur la question de quelle table donner à qui (en utilisant les « prix fictifs » du Planificateur), il a trouvé un moyen de faire les deux en même temps.

En résumé :
HMAF est comme un gestionnaire de restaurant super intelligent qui ne se contente pas de réagir aux clients lorsqu'ils arrivent. Au lieu de cela, il planifie tout le mois, ajuste la politique d'entrée en temps réel en fonction de l'occupation de la section VIP, et dispose les tables parfaitement pour s'assurer que tout le monde obtient ce dont il a besoin tout en générant le profit maximal pour le restaurant.

Résumé Technique : HMAF – Un cadre d'allocation hiérarchique multi-slots pour le GD-RTB

1. Formulation du Problème

Le papier traite du défi complexe de l'allocation d'impressions dans les écosystèmes publicitaires en ligne à grande échelle où les contrats de Livraison Garantie (GD - Guaranteed Delivery) coexistent avec les enchères en temps réel (RTB - Real-Time Bidding). Plus précisément, les auteurs se concentrent sur les environnements multi-slots (ex: flux de contenu) où une seule vue de page contient plusieurs emplacements publicitaires (slots).

Le problème central est formulé comme une tâche d'allocation unifiée visant à maximiser le revenu total de la plateforme (somme des valeurs d'enchère RTB et des valeurs contractuelles GD) sous des contraintes strictes :

Contraintes de livraison GD : Garantir que les contrats respectent les volumes minimums et maximums d'impressions ( $B_j$ ) pour éviter les pénalités.
Contraintes d'offre (Supply) : Chaque requête (vue de page) peut être allouée à au plus une publicité par slot.
Contraintes de Vue de Page (PV) : Limites fines sur le nombre d'impressions qu'une requête spécifique peut contribuer à travers plusieurs slots afin de prévenir la fatigue publicitaire et la surexposition.

Les auteurs identifient trois défis fondamentaux pour résoudre ce problème :

Complexité NP-difficile : Le problème généralise le problème du sac à dos multidimensionnel (MKP) sous des contraintes de PV fines, rendant l'optimisation globale computationnellement intraitable pour des millions de requêtes.
Compromis eCPM-Fulfillment : Équilibrer la maximisation du revenu à court terme (eCPM élevé) avec les garanties de livraison de contrat à long terme est difficile ; une exécution agressive nuit souvent au revenu, tandis qu'un focus pur sur le revenu risque une sous-livraison.
Supervision faible : Contrairement à la prédiction de CTR standard, le classement hybride manque de labels de vérité terrain explicites pour la liste optimale, nécessissant au système d'apprendre à partir de retours implicites et différés dérivés de l'état global de la livraison.

2. Méthodologie : Le Cadre HMAF

Les auteurs proposent HMAF (Hierarchical Multi-Slot Allocation Framework), qui décompose le problème intraitable en un paradigme Planifier–Calibrer–Exécuter. Ce cadre couple étroitement l'optimisation hors ligne des contraintes avec la prise de décision neuronale en ligne.

A. Étape de Planification (Plan) : Module d'allocation contraint par la Vue de Page

Ce module formule le problème d'allocation comme un problème d'optimisation contraint hors ligne.

Objectif : Minimise une fonction de perte qui équilibre la réalisation du contrat, l'intérêt de l'utilisateur et une nouvelle contrainte de Vue de Page (PV) pour limiter l'exposition par slot.
Mécanisme : Le problème est résolu en utilisant la relaxation lagrangienne et les conditions KKT. Au lieu de résoudre directement le problème primal, le système met à jour de manière itérative les variables duales ( $\alpha, \beta, \delta$ $α, β, δ$ ) via des étapes de gradient projeté.
- $\alpha_j$ : Prix fictif (shadow price) pour la demande contractuelle (pression de livraison).
- $\beta_i$ : Prix fictif pour la capacité de la requête.
- $\delta_{ij}$ : Prix fictif pour les contraintes de PV au niveau du slot.
Sortie : Ces variables duales agissent comme des "prix fictifs" encodant la rareté des ressources globales et la pression de livraison, servant de signaux de contrôle compacts pour les étapes en aval.

B. Étape de Calibrage (Calibrate) : Module de pré-classement guidé par le duel

Ce module fait le pont entre la planification hors ligne et l'exécution en ligne en injectant les variables duales dans le score de classement.

Scoring Unifié : Il définit un score de classement ( $rs_j$ ) pour les candidats GD et RTB.
Modulation guidée par le duel : Pour les publicités GD, le score est ajusté par un terme $x_{ij} \cdot PID_{Error}$ , où $x_{ij}$ est la confiance d'allocation dérivée de l'optimisation hors ligne. Cela ajuste dynamiquement la compétitivité en fonction de la pression de livraison spécifique au contexte plutôt que d'appliquer un contrôle PID uniforme.
Fonction : Cette étape effectue un filtrage et un classement grossiers, réduisant considérablement l'espace de décision tout en préservant la qualité de l'allocation.

C. Étape d'Exécution (Execute) : Module d'allocation listwise Générateur-Évaluateur

Cette étape gère le classement final par liste (listwise) à travers plusieurs slots, traitant la nature dépendante de la position des publicités multi-slots.

Espace de caractéristiques augmenté par le duel : Les variables duales hors ligne ( $\alpha, \beta, \delta$ ) sont injectées comme caractéristiques d'état global dans le réseau neuronal, offrant une "prévoyance" sur les contraintes du système.
Générateur : Un encodeur basé sur Transformer modélise les interactions candidat-position, produisant une matrice de probabilité pour l'assignation des candidats aux slots. Il génère une liste primaire et des listes perturbées pour l'exploration.
Évaluateur : Un superviseur listwise sélectionne la liste de classement optimale parmi les candidats générés en estimant une récompense ( $R(S_k)$ ) qui agrège les métriques prédites et les contraintes de livraison.
Objectif d'entraînement : Le modèle est entraîné à l'aide d'une fonction de perte combinée :
- $L_{ce}$ : Perte d'entropie croisée alignant les prédictions avec l'assignation optimale de l'évaluateur.
- $L_{re}$ : Perte sensible à la récompense pénalisant les écarts entre l'eCPM prédit et réalisé, corrigeant les biais systématiques.

3. Contributions Clés

Cadre Unifié : La proposition de HMAF, un cadre hiérarchique qui intègre l'optimisation des contraintes hors ligne avec la prise de décision neuronale en ligne, fournissant une base architecturale robuste pour l'allocation multi-slot GD-RTB.
Trois Composants Cores :
- Un module d'Optimisation contrainte par la Vue de Page qui capture les contraintes d'offre fines et dérive des signaux duaux.
- Un module de Classement Unifié guidé par le Duel qui calibre le scoring en ligne en utilisant les variables duales hors ligne pour équilibrer l'eCPM et la réalisation.
- Un module Générateur-Évaluateur qui permet le classement listwise en modélisant conjointement les interactions candidat-position sous un guidage global.
Validation Empirique : Des expériences à grande échelle et des tests A/B en ligne démontrant des améliorations statistiquement significatives tant dans les taux de livraison que dans le revenu total.

4. Résultats Expérimentaux

Le cadre a été évalué à l'aide d'un jeu de données provenant de l'environnement de production de Meituan (plus de 123M d'impressions, 32 jours) et déployé lors de tests A/B en ligne.

Performance Hors Ligne :

HMAF a surpassé les bases de référence (incluant CF, PID, AUAF, CONFLUX et LIBRA) sur toutes les métriques.
Group AUC (GA) : 0,8984 (contre 0,8538 pour la meilleure base, LIBRA).
Taux de Livraison (DR) : 0,9638 (contre 0,9554 pour LIBRA).
Taux d'Utilité (UR) : 0,9812 (contre 0,9513 pour LIBRA).
RTB eCPM : A atteint le score normalisé le plus élevé (1,0000).

Tests A/B en Ligne (2 mois, répartition du trafic 50/50) :

Taux de Livraison GD : Augmentation de 3,72 % (statistiquement significative, p-value 0,018).
Revenu Publicitaire Total : Augmentation de 1,59 % (statistiquement significative, p-value 0,024).
Efficacité du Système : La planification hors ligne s'exécute en environ 2 heures sur 20 machines ; l'inférence en ligne est légère (<50ms par vue de page).
Signification des Résultats : Les auteurs notent que l'obtention simultanée de gains en livraison et en revenu est contre-intuitive. Ils attribuent cela à la capacité du modèle GE à déplacer intelligemment les impressions GD vers des slots non premium (en utilisant les signaux $\delta_{ij}$ ), libérant ainsi l'inventaire à haute valeur pour le RTB.

5. Signification et Revendications

Le papier affirme que HMAF répond avec succès au conflit inhérent entre l'efficacité du revenu à court terme et les garanties de livraison à long terme dans les marchés publicitaires hybrides. En introduisant un paradigme Planifier–Calibrer–Exécuter, le cadre dépasse les règles de priorité heuristiques ou les pipelines découplés.

Les auteurs soulignent que la capacité du cadre à gérer les contraintes multi-slots fines et l'optimisation combinatoire NP-difficile via une approche neuronale guidée par le duel est sa principale innovation. Ils affirment que HMAF fournit une "base architecturale fiable" pour l'allocation GD-RTB et a été déployée avec succès dans le système de production de Meituan, générant une valeur commerciale mesurable. Le papier conclut que le cadre est adaptable à d'autres plateformes ayant des configurations GD-RTB similaires, reposant uniquement sur les exigences de livraison garantie, les valeurs d'enchères en temps réel et les contraintes d'exposition multi-slots.