Tarification optimale pour un profit maximal avec Amazon SageMaker

Ceci est un article invité de Viktor Enrico Jeney, ingénieur principal en apprentissage automatique chez Adspert.

annonceur est un ISV basé à Berlin qui a développé un outil de gestion des enchères conçu pour optimiser automatiquement les campagnes de marketing et de publicité à la performance. Le principe de base de l'entreprise est d'automatiser la maximisation des bénéfices de la publicité de commerce électronique à l'aide de l'intelligence artificielle. Le développement continu des plates-formes publicitaires ouvre la voie à de nouvelles opportunités, qu'Adspert utilise de manière experte pour le succès de ses clients.

L'objectif principal d'Adspert est de simplifier le processus pour les utilisateurs tout en optimisant les campagnes publicitaires sur différentes plateformes. Cela inclut l'utilisation des informations recueillies sur les différentes plates-formes équilibrées par rapport au budget optimal défini à un niveau supérieur à chaque plate-forme. L'objectif d'Adspert est d'optimiser la réalisation des objectifs d'un client, quelle que soit la plate-forme utilisée. Adspert continue d'ajouter des plates-formes si nécessaire pour donner à nos clients des avantages significatifs.

Dans cet article, nous partageons comment Adspert a créé l'outil de tarification à partir de zéro en utilisant différents services AWS comme Amazon Sage Maker et comment Adspert a collaboré avec le Laboratoire de données AWS pour accélérer ce projet de la conception à la construction en un temps record.

L'outil de tarification réévalue un produit sélectionné par le vendeur sur un marché de commerce électronique en fonction de la visibilité et de la marge bénéficiaire afin de maximiser les bénéfices au niveau du produit.

En tant que vendeur, il est essentiel que vos produits soient toujours visibles car cela augmentera les ventes. Le facteur le plus important dans les ventes de commerce électronique est simplement que votre offre soit visible pour les clients au lieu de l'offre d'un concurrent.

Bien que cela dépende certainement de la plate-forme de commerce électronique spécifique, nous avons constaté que le prix du produit est l'un des chiffres clés les plus importants pouvant affecter la visibilité. Cependant, les prix changent souvent et rapidement ; pour cette raison, l'outil de tarification doit agir en temps quasi réel pour augmenter la visibilité.

Présentation de la solution

Le diagramme suivant illustre l'architecture de la solution.

La solution contient les composants suivants :

1. Amazon Relational Database Service (Amazon RDS) pour PostgreSQL est la principale source de données, contenant des informations sur les produits stockées dans une base de données RDS pour Postgres.
2. Les informations sur les changements de liste de produits arrivent en temps réel dans un Service Amazon Simple Queue (Amazon SQS) file d'attente.
3. Les informations sur les produits stockées dans Amazon RDS sont ingérées en temps quasi réel dans la couche brute à l'aide du modèle de capture de données modifiées (CDC) disponible dans Service de migration de base de données AWS (AWS DMS).
4. Les notifications de liste de produits provenant d'Amazon SQS sont ingérées en temps quasi réel dans la couche brute à l'aide d'un AWS Lambda la fonction.
5. Les données source d'origine sont stockées dans le Service de stockage simple Amazon (Amazon S3) compartiment de couche brute utilisant le format de données Parquet. Cette couche est la seule source de vérité pour le lac de données. Le partitionnement utilisé sur ce stockage prend en charge le traitement incrémentiel des données.
6. Colle AWS les tâches d'extraction, de transformation et de chargement (ETL) nettoient les données produit, suppriment les doublons et appliquent la consolidation des données et des transformations génériques non liées à une analyse de rentabilisation spécifique.
7. La couche d'étape Amazon S3 reçoit des données préparées qui sont stockées au format Apache Parquet pour un traitement ultérieur. Le partitionnement utilisé sur le stage store prend en charge le traitement incrémentiel des données.
8. Les tâches AWS Glue créées dans cette couche utilisent les données disponibles dans la couche d'étape Amazon S3. Cela inclut l'application de règles métier spécifiques à chaque cas d'utilisation et les calculs requis. Les données de résultats de ces tâches sont stockées dans la couche d'analyse Amazon S3.
9. La couche d'analyse Amazon S3 est utilisée pour stocker les données utilisées par les modèles ML à des fins de formation. Le partitionnement utilisé sur le magasin organisé est basé sur l'utilisation des données attendue. Cela peut être différent du partitionnement utilisé sur la couche de scène.
10. Le modèle ML de retarification est une implémentation Scikit-Learn Random Forest en mode script SageMaker, qui est formée à l'aide des données disponibles dans le compartiment S3 (la couche d'analyse).
11. Une tâche de traitement de données AWS Glue prépare les données pour l'inférence en temps réel. La tâche traite les données ingérées dans le compartiment S3 (couche d'étape) et appelle le point de terminaison d'inférence SageMaker. Les données sont préparées pour être utilisées par le modèle de retarification SageMaker. AWS Glue a été préféré à Lambda, car l'inférence nécessite différentes opérations de traitement de données complexes comme les jointures et les fonctions de fenêtre sur un volume élevé de données (des milliards de transactions quotidiennes). Le résultat des appels du modèle de retarification est stocké dans le compartiment S3 (couche d'inférence).
12. La tâche de formation SageMaker est déployée à l'aide d'un point de terminaison SageMaker. Ce point de terminaison est appelé par le processeur d'inférence AWS Glue, générant des recommandations de prix en temps quasi réel pour augmenter la visibilité du produit.
13. Les prédictions générées par le point de terminaison d'inférence SageMaker sont stockées dans la couche d'inférence Amazon S3.
14. La fonction d'optimisation des prédictions Lambda traite les recommandations générées par le point de terminaison d'inférence SageMaker et génère une nouvelle recommandation de prix qui se concentre sur la maximisation du profit du vendeur, en appliquant un compromis entre le volume des ventes et la marge des ventes.
15. Les recommandations de prix générées par l'optimiseur de prédictions Lambda sont soumises à l'API de retarification, qui met à jour le prix du produit sur la place de marché.
16. Les recommandations de prix mises à jour générées par l'optimiseur de prédictions Lambda sont stockées dans la couche d'optimisation Amazon S3.
17. La tâche de chargeur de prédiction AWS Glue recharge dans la base de données source RDS pour Postgres SQL les prédictions générées par le modèle ML à des fins d'audit et de création de rapports. AWS Glue Studio a été utilisé pour implémenter ce composant ; il s'agit d'une interface graphique qui facilite la création, l'exécution et la surveillance des tâches ETL dans AWS Glue.

Préparation des données

L'ensemble de données pour le modèle de visibilité d'Adspert est créé à partir d'une file d'attente SQS et ingéré dans la couche brute de notre lac de données en temps réel avec Lambda. Ensuite, les données brutes sont nettoyées en effectuant des transformations simples, comme la suppression des doublons. Ce processus est implémenté dans AWS Glue. Le résultat est stocké dans la couche intermédiaire de notre lac de données. Les notifications fournissent aux concurrents pour un produit donné, leurs prix, leurs canaux d'exécution, leurs délais d'expédition et bien d'autres variables. Ils fournissent également une mesure de visibilité dépendante de la plate-forme, qui peut être exprimée sous la forme d'une variable booléenne (visible ou non visible). Nous recevons une notification chaque fois qu'un changement d'offre se produit, ce qui représente plusieurs millions d'événements par mois sur tous les produits de nos clients.

De cet ensemble de données, nous extrayons les données d'apprentissage comme suit : pour chaque notification, nous apparions les offres visibles avec chaque offre non visible, et vice versa. Chaque point de données représente une compétition entre deux vendeurs, dans laquelle il y a clairement un gagnant et un perdant. Cette tâche de traitement est implémentée dans une tâche AWS Glue avec Spark. L'ensemble de données d'entraînement préparé est poussé vers le compartiment d'analyse S3 pour être utilisé par SageMaker.

Former le modèle

Notre modèle classe pour chaque paire d'offres, si une offre donnée sera visible. Ce modèle nous permet de calculer le meilleur prix pour nos clients, d'augmenter la visibilité en fonction de la concurrence et de maximiser leur profit. En plus de cela, ce modèle de classification peut nous donner un aperçu plus approfondi des raisons pour lesquelles nos annonces sont visibles ou non visibles. Nous utilisons les fonctionnalités suivantes :

• Rapport de nos prix aux prix des concurrents
• Différence dans les canaux d'exécution
• Quantité de commentaires pour chaque vendeur
• Note d'évaluation de chaque vendeur
• Différence dans les délais d'expédition minimum
• Différence dans les délais d'expédition maximaux
• Disponibilité du produit de chaque vendeur

Adspert utilise SageMaker pour former et héberger le modèle. Nous utilisons l'implémentation Scikit-Learn Random Forest dans Mode de script SageMaker. Nous incluons également un prétraitement de fonctionnalités directement dans le pipeline Scikit-Learn dans le script de formation. Voir le code suivant :

import numpy as np

def transform_price(X):
    X = X.to_numpy()
    return np.log(
        X[:, 0] / np.nanmin([X[:, 1], X[:, 2]], axis=0),
    ).reshape(-1, 1)

def difference(X):
    X = X.to_numpy()
    return (X[:, 0] - X[:, 1]).reshape(-1, 1)

def fulfillment_difference(X):
    X = X.astype(int)
    return difference(X)

L'une des fonctions de prétraitement les plus importantes est transform_price, qui divise le prix par le minimum du prix du concurrent et d'une colonne de prix externe. Nous avons constaté que cette fonctionnalité a un impact significatif sur la précision du modèle. Nous appliquons également le logarithme pour laisser le modèle décider en fonction des différences de prix relatives, et non des différences de prix absolues.

Dans le training_script.py script, nous définissons d'abord comment construire le Scikit-Learn ColumnTransformer pour appliquer les transformateurs spécifiés aux colonnes d'un dataframe :

import argparse
import os
from io import StringIO

import joblib
import numpy as np
import pandas as pd
from custom_transformers import difference
from custom_transformers import fulfillment_difference
from custom_transformers import transform_price
from sklearn.compose import ColumnTransformer
from sklearn.ensemble import RandomForestClassifier
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import FunctionTransformer
from sklearn.preprocessing import OneHotEncoder

def make_preprocessor():
    return ColumnTransformer([
        ('price_by_smallest_cp', FunctionTransformer(transform_price),
         ['price', 'competitor_price', 'external_price']),
        (fulfillment_difference, FunctionTransformer(fulfillment_difference),
         ['fulfillment', 'competitor_'fulfillment']),
        ('feedback_count', 'passthrough',
         ['feedback_count', 'competitor_feedback_count']),
        ('feedback_rating', 'passthrough',
         ['feedback_rating', 'competitor_feedback_rating']),
        (
            'availability_type',
            OneHotEncoder(categories=[['NOW'], ['NOW']],
                          handle_unknown='ignore'),
            ['availability_type', 'competitor_availability_type'],
        ),
        ('min_shipping', FunctionTransformer(difference),
         ['minimum_shipping_hours', 'competitor_min_shipping_hours']),
        ('max_shipping', FunctionTransformer(difference),
         ['maximum_shipping_hours', 'competitor_max_shipping_hours']),
    ], remainder='drop')

Dans le script de formation, nous chargeons les données de Parquet dans un dataframe Pandas, définissons le pipeline du ColumnTranformer et par RandomForestClassifier, et entraînez le modèle. Ensuite, le modèle est sérialisé à l'aide de joblib:

if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('--output-data-dir', type=str,
                        default=os.environ['SM_OUTPUT_DATA_DIR'])
    parser.add_argument('--model-dir', type=str,
                        default=os.environ['SM_MODEL_DIR'])
    parser.add_argument('--train', type=str,
                        default=os.environ['SM_CHANNEL_TRAIN'])

    args = parser.parse_args()

    # load training data
    input_files = [os.path.join(args.train, file)
                   for file in os.listdir(args.train)]
    if len(input_files) == 0:
        raise ValueError
    raw_data = [pd.read_parquet(file) for file in input_files]
    train_data = pd.concat(raw_data)

    # split data set into x and y values
    train_y = train_data.loc[:, 'is_visible']

    if train_y.dtype != 'bool':
        raise ValueError(f'Label 'is_visible' has to be dtype bool but is'
                         f' {train_y.dtype}')

    train_X = train_data.drop('is_visible', axis=1)

    # fit the classifier pipeline and store the fitted model
    clf = Pipeline([
        ('preprocessor', make_preprocessor()),
        ('classifier', RandomForestClassifier(random_state=1)),
    ])
    clf.fit(train_X, train_y)
    joblib.dump(clf, os.path.join(args.model_dir, 'model.joblib'))

Dans le script de formation, nous devons également implémenter des fonctions d'inférence :

• entrée_fn – Est responsable de l'analyse des données du corps de la requête de la charge utile
• modèle_fn - Charge et renvoie le modèle qui a été vidé dans la section de formation du script
• prédire_fn – Contient notre implémentation pour demander une prédiction au modèle en utilisant les données de la charge utile
• prédire_proba – Afin de tracer des courbes de visibilité prédites, nous renvoyons la probabilité de classe en utilisant la predict_proba fonction, au lieu de la prédiction binaire du classifieur

Voir le code suivant:

def input_fn(request_body, request_content_type):
    """Parse input data payload"""
    if request_content_type == 'text/csv':
        df = pd.read_csv(StringIO(request_body))
        return df
    else:
        raise ValueError(f'{request_content_type} not supported by script!')


def predict_fn(input_data, model):
    """Predict the visibilities"""
    classes = model.classes_

    if len(classes) != 2:
        raise ValueError('Model has more than 2 classes!')

    # get the index of the winning class
    class_index = np.where(model.classes_ == 1)[0][0]

    output = model.predict_proba(input_data)
    return output[:, class_index]


def model_fn(model_dir):
    """Deserialized and return fitted model

    Note that this should have the same name as the serialized model in the
    main method
    """
    clf = joblib.load(os.path.join(model_dir, 'model.joblib'))
    return clf

La figure suivante montre les importances des caractéristiques basées sur les impuretés renvoyées par le Classificateur de forêt aléatoire.

Avec SageMaker, nous avons pu former le modèle sur une grande quantité de données (jusqu'à 14 milliards de transactions quotidiennes) sans surcharger nos instances existantes ni avoir à configurer une machine séparée avec suffisamment de ressources. De plus, étant donné que les instances sont immédiatement arrêtées après la tâche de formation, la formation avec SageMaker était extrêmement rentable. Le déploiement du modèle avec SageMaker a fonctionné sans aucune charge de travail supplémentaire. Un seul appel de fonction dans le SDK Python est suffisant pour héberger notre modèle en tant que point de terminaison d'inférence, et il peut également être facilement demandé à d'autres services utilisant le SDK Python SageMaker. Voir le code suivant :

from sagemaker.sklearn.estimator import SKLearn

FRAMEWORK_VERSION = "0.23-1"
script_path = 'training_script.py'
output_location = f's3://{bucket}/{folder}/output'
source_dir = 'source_dir'

sklearn = SKLearn(
    entry_point=script_path,
    source_dir=source_dir,
    framework_version=FRAMEWORK_VERSION,
    instance_type='ml.m5.large',
    role=role,
    sagemaker_session=sagemaker_session,
    output_path=output_location)

sklearn.fit({'train': training_path})

L'artefact du modèle est stocké dans Amazon S3 par la fonction d'ajustement. Comme on le voit dans le code suivant, le modèle peut être chargé en tant que SKLearnModel objet à l'aide de l'artefact du modèle, du chemin du script et d'autres paramètres. Ensuite, il peut être déployé sur le type d'instance et le nombre d'instances souhaités.

model = sagemaker.sklearn.model.SKLearnModel(
    model_data=f'{output_location}/sagemaker-scikit-learn-2021-02-23-11-13-30-036/output/model.tar.gz',
    source_dir=source_dir,
    entry_point=script_path,
    framework_version=FRAMEWORK_VERSION,
    sagemaker_session=sagemaker_session,
    role=role
)
ENDPOINT_NAME = 'visibility-model-v1'
model.deploy(
    initial_instance_count=1,
    instance_type='ml.m5.large',
    endpoint_name=ENDPOINT_NAME
)

Évaluer le modèle en temps réel

Chaque fois qu'une nouvelle notification est envoyée pour l'un de nos produits, nous souhaitons calculer et soumettre le prix optimal. Pour calculer les prix optimaux, nous créons un ensemble de données de prédiction dans lequel nous comparons notre propre offre avec l'offre de chaque concurrent pour une gamme de prix possibles. Ces points de données sont transmis au point de terminaison SageMaker, qui renvoie la probabilité prévue d'être visible par rapport à chaque concurrent pour chaque prix donné. On appelle la probabilité d'être visible la visibilité prévue. Le résultat peut être visualisé sous la forme d'une courbe pour chaque concurrent, décrivant la relation entre notre prix et la visibilité, comme le montre la figure suivante.

Dans cet exemple, la visibilité vis-à-vis du concurrent 1 est presque une fonction constante par morceaux, suggérant que nous devons principalement baisser le prix en dessous d'un certain seuil, à peu près le prix du concurrent, pour devenir visible. Cependant, la visibilité contre le concurrent 2 ne diminue pas aussi fortement. En plus de cela, nous avons encore 50% de chances d'être visibles même avec un prix très élevé. L'analyse des données d'entrée a révélé que le concurrent a un faible nombre de notes, qui se trouvent être très mauvaises. Notre modèle a appris que cette plate-forme de commerce électronique spécifique désavantage les vendeurs dont les évaluations sont médiocres. Nous avons découvert des effets similaires pour les autres fonctionnalités, comme le canal d'exécution et les délais d'expédition.

Les transformations de données et les inférences nécessaires par rapport au point de terminaison SageMaker sont implémentées dans AWS Glue. Le travail AWS Glue fonctionne par micro-lots sur les données en temps réel ingérées depuis Lambda.

Enfin, nous voulons calculer la courbe de visibilité agrégée, qui est la visibilité prédite pour chaque prix possible. Notre offre est visible si elle est meilleure que toutes les offres des autres vendeurs. En supposant l'indépendance entre les probabilités d'être visible par rapport à chaque vendeur compte tenu de notre prix, la probabilité d'être visible par rapport à tous les vendeurs est le produit des probabilités respectives. Cela signifie que la courbe de visibilité agrégée peut être calculée en multipliant toutes les courbes.

Les figures suivantes montrent les visibilités prévues renvoyées par le point de terminaison SageMaker.

La figure suivante montre la courbe de visibilité agrégée.

Pour calculer le prix optimal, la courbe de visibilité est d'abord lissée puis multipliée par la marge. Pour calculer la marge, nous utilisons les coûts des marchandises et les frais. Le coût des marchandises vendues et les frais sont les informations statiques sur les produits synchronisées via AWS DMS. Sur la base de la fonction de profit, Adspert calcule le prix optimal et le soumet à la plateforme de commerce électronique via l'API de la plateforme.

Ceci est implémenté dans l'optimiseur de prédiction AWS Lambda.

La figure suivante montre la relation entre la visibilité prévue et le prix.

La figure suivante montre la relation entre le prix et le profit.

Conclusion

L'approche existante d'Adspert en matière de maximisation des bénéfices est axée sur la gestion des enchères pour augmenter les rendements de la publicité. Cependant, pour obtenir des performances supérieures sur les marchés de commerce électronique, les vendeurs doivent tenir compte à la fois de la publicité et des prix compétitifs de leurs produits. Avec ce nouveau modèle ML pour prédire la visibilité, nous pouvons étendre nos fonctionnalités pour également ajuster les prix des clients.

Le nouvel outil de tarification doit être capable de former automatiquement le modèle ML sur une grande quantité de données, ainsi que des transformations de données en temps réel, des prédictions et des optimisations de prix. Dans cet article, nous avons parcouru les principales étapes de notre moteur d'optimisation des prix et l'architecture AWS que nous avons mise en œuvre en collaboration avec AWS Data Lab pour atteindre ces objectifs.

Faire passer les modèles ML du concept à la production est généralement complexe et prend du temps. Vous devez gérer de grandes quantités de données pour entraîner le modèle, choisir le meilleur algorithme pour l'entraîner, gérer la capacité de calcul tout en l'entraînant, puis déployer le modèle dans un environnement de production. SageMaker a réduit cette complexité en rendant beaucoup plus simple la création et le déploiement du modèle ML. Après avoir choisi les bons algorithmes et frameworks parmi le large éventail de choix disponibles, SageMaker a géré toute l'infrastructure sous-jacente pour former notre modèle et le déployer en production.

Si vous souhaitez commencer à vous familiariser avec SageMaker, le Atelier Journée Immersion peut vous aider à comprendre de bout en bout comment créer des cas d'utilisation ML à partir de l'ingénierie des fonctionnalités, les différents algorithmes intégrés et comment former, régler et déployer le modèle ML dans un scénario de type production. Il vous guide pour apporter votre propre modèle et effectuer un lifting et déplacement de la charge de travail ML sur site vers la plate-forme SageMaker. Il présente en outre des concepts avancés tels que le débogage de modèle, la surveillance de modèle et AutoML, et vous aide à évaluer votre charge de travail ML via l'objectif AWS ML Well-Architected.

Si vous souhaitez obtenir de l'aide pour accélérer la mise en œuvre de cas d'utilisation impliquant des données, des analyses, de l'IA et du ML, sans serveur et la modernisation des conteneurs, veuillez contacter le Laboratoire de données AWS.

À propos des auteurs

Victor Enrico Jeney est un ingénieur principal en apprentissage automatique chez Adspert basé à Berlin, en Allemagne. Il crée des solutions aux problèmes de prédiction et d'optimisation afin d'augmenter les profits des clients. Viktor a une formation en mathématiques appliquées et adore travailler avec les données. Pendant son temps libre, il aime apprendre le hongrois, pratiquer les arts martiaux et jouer de la guitare.

Ennio Pastore est architecte de données au sein de l'équipe AWS Data Lab. Il est un passionné de tout ce qui touche aux nouvelles technologies qui ont un impact positif sur les entreprises et les moyens de subsistance en général. Ennio a plus de 9 ans d'expérience dans l'analyse de données. Il aide les entreprises à définir et à mettre en œuvre des plates-formes de données dans des secteurs tels que les télécommunications, la banque, les jeux, la vente au détail et les assurances.