Optimale Preise für maximalen Gewinn mit Amazon SageMaker

Dies ist ein Gastbeitrag von Viktor Enrico Jeney, Senior Machine Learning Engineer bei Adspert.

Anzeigen ist ein in Berlin ansässiger ISV, der ein Bid-Management-Tool zur automatischen Optimierung von Performance-Marketing- und Werbekampagnen entwickelt hat. Das Kernprinzip des Unternehmens besteht darin, die Gewinnmaximierung von E-Commerce-Werbung mit Hilfe künstlicher Intelligenz zu automatisieren. Die kontinuierliche Weiterentwicklung von Werbeplattformen eröffnet neue Möglichkeiten, die Adspert für den Erfolg seiner Kunden gekonnt nutzt.

Das Hauptziel von Adspert ist es, den Prozess für die Nutzer zu vereinfachen und gleichzeitig Werbekampagnen über verschiedene Plattformen hinweg zu optimieren. Dazu gehört die Nutzung der über die verschiedenen Plattformen hinweg gesammelten Informationen, die gegen das optimale Budget abgewogen werden, das auf einer Ebene über jeder Plattform festgelegt wird. Der Fokus von Adspert liegt darauf, die Zielerreichung eines Kunden zu optimieren, unabhängig davon, welche Plattform verwendet wird. Adspert fügt Plattformen nach Bedarf hinzu, um unseren Kunden erhebliche Vorteile zu bieten.

In diesem Beitrag teilen wir mit, wie Adspert das Pricing-Tool mit verschiedenen AWS-Services wie z. B. von Grund auf neu erstellt hat Amazon Sage Maker und wie Adspert mit der zusammengearbeitet hat AWS-Datenlabor dieses Projekt vom Entwurf bis zum Bau in Rekordzeit zu beschleunigen.

Das Preisgestaltungstool bepreist ein vom Verkäufer ausgewähltes Produkt auf einem E-Commerce-Marktplatz basierend auf der Sichtbarkeit und der Gewinnspanne neu, um die Gewinne auf Produktebene zu maximieren.

Als Verkäufer ist es wichtig, dass Ihre Produkte immer sichtbar sind, da dies den Umsatz steigert. Der wichtigste Faktor bei E-Commerce-Verkäufen ist einfach, ob Ihr Angebot für Kunden sichtbar ist und nicht das Angebot eines Konkurrenten.

Obwohl es sicherlich von der jeweiligen E-Commerce-Plattform abhängt, haben wir festgestellt, dass der Produktpreis eine der wichtigsten Kennzahlen ist, die die Sichtbarkeit beeinflussen können. Die Preise ändern sich jedoch oft und schnell; Aus diesem Grund muss das Pricing-Tool nahezu in Echtzeit agieren, um die Sichtbarkeit zu erhöhen.

Lösungsübersicht

Das folgende Diagramm zeigt die Lösungsarchitektur.

Die Lösung enthält die folgenden Komponenten:

1. Amazon Relational Database Service (Amazon RDS) für PostgreSQL ist die Hauptdatenquelle, die Produktinformationen enthält, die in einer RDS for Postgres-Datenbank gespeichert sind.
2. Informationen zu Änderungen der Produktliste kommen in Echtzeit an Amazon Simple Queue-Dienst Warteschlange (Amazon SQS).
3. In Amazon RDS gespeicherte Produktinformationen werden nahezu in Echtzeit in die Rohschicht aufgenommen, wobei das in verfügbare CDC-Muster (Change Data Capture) verwendet wird AWS-Datenbankmigrationsservice (AWS DMS).
4. Von Amazon SQS stammende Benachrichtigungen zu Produktlisten werden mithilfe von nahezu in Echtzeit in die Rohschicht aufgenommen AWS Lambda Funktion.
5. Die ursprünglichen Quelldaten werden in der gespeichert Amazon Simple Storage-Service (Amazon S3) Raw-Layer-Bucket im Parquet-Datenformat. Diese Schicht ist die Single Source of Truth für den Data Lake. Die auf diesem Speicher verwendete Partitionierung unterstützt die inkrementelle Verarbeitung von Daten.
6. AWS-Kleber Extraktions-, Transformations- und Ladejobs (ETL) bereinigen die Produktdaten, entfernen Duplikate und wenden Datenkonsolidierung und generische Transformationen an, die nicht an einen bestimmten Geschäftsfall gebunden sind.
7. Die Amazon S3-Stage-Schicht erhält aufbereitete Daten, die zur weiteren Verarbeitung im Apache Parquet-Format gespeichert werden. Die im Stage Store verwendete Partitionierung unterstützt die inkrementelle Verarbeitung von Daten.
8. Die in dieser Schicht erstellten AWS Glue-Jobs verwenden die in der Amazon S3-Stufenschicht verfügbaren Daten. Dies umfasst die Anwendung von anwendungsfallspezifischen Geschäftsregeln und erforderlichen Berechnungen. Die Ergebnisdaten dieser Jobs werden in der Analyseschicht von Amazon S3 gespeichert.
9. Die Amazon S3-Analytics-Schicht wird verwendet, um die Daten zu speichern, die von den ML-Modellen für Trainingszwecke verwendet werden. Die im kuratierten Speicher verwendete Partitionierung basiert auf der erwarteten Datennutzung. Dies kann sich von der Partitionierung unterscheiden, die auf der Bühnenschicht verwendet wird.
10. Das Repricing-ML-Modell ist eine Scikit-Learn Random Forest-Implementierung im SageMaker-Skriptmodus, die mit Daten trainiert wird, die im S3-Bucket (der Analyseebene) verfügbar sind.
11. Ein AWS Glue-Datenverarbeitungsauftrag bereitet Daten für die Echtzeit-Inferenz vor. Der Job verarbeitet im S3-Bucket (Stage-Layer) aufgenommene Daten und ruft den SageMaker-Inferenzendpunkt auf. Die Daten werden für die Verwendung durch das Neubewertungsmodell von SageMaker vorbereitet. AWS Glue wurde Lambda vorgezogen, da die Inferenz verschiedene komplexe Datenverarbeitungsvorgänge wie Verknüpfungen und Fensterfunktionen für ein hohes Datenvolumen (Milliarden von täglichen Transaktionen) erfordert. Das Ergebnis der Neupreismodellaufrufe wird im S3-Bucket (Inferenzebene) gespeichert.
12. Der SageMaker-Trainingsjob wird mithilfe eines SageMaker-Endpunkts bereitgestellt. Dieser Endpunkt wird vom AWS Glue-Inferenzprozessor aufgerufen und generiert nahezu in Echtzeit Preisempfehlungen, um die Produktsichtbarkeit zu erhöhen.
13. Die vom SageMaker-Inferenzendpunkt generierten Vorhersagen werden in der Amazon S3-Inferenzebene gespeichert.
14. Die Lambda-Prognoseoptimierungsfunktion verarbeitet die vom SageMaker-Inferenzendpunkt generierten Empfehlungen und generiert eine neue Preisempfehlung, die sich auf die Maximierung des Verkäufergewinns konzentriert und einen Kompromiss zwischen Verkaufsvolumen und Verkaufsmarge anwendet.
15. Die vom Lambda-Prognoseoptimierer generierten Preisempfehlungen werden an die Repricing-API übermittelt, die den Produktpreis auf dem Marktplatz aktualisiert.
16. Die vom Lambda-Vorhersageoptimierer generierten aktualisierten Preisempfehlungen werden in der Amazon S3-Optimierungsebene gespeichert.
17. Der AWS Glue Prediction Loader-Job lädt die vom ML-Modell generierten Vorhersagen für Audit- und Berichtszwecke erneut in die RDS-Quelldatenbank für Postgres SQL. Zur Implementierung dieser Komponente wurde AWS Glue Studio verwendet; Es ist eine grafische Oberfläche, die das Erstellen, Ausführen und Überwachen von ETL-Jobs in AWS Glue vereinfacht.

Datenaufbereitung

Der Datensatz für das Sichtbarkeitsmodell von Adspert wird aus einer SQS-Warteschlange erstellt und mit Lambda in Echtzeit in die Rohschicht unseres Data Lake aufgenommen. Anschließend werden die Rohdaten bereinigt, indem einfache Transformationen durchgeführt werden, z. B. das Entfernen von Duplikaten. Dieser Prozess ist in AWS Glue implementiert. Das Ergebnis wird in der Staging-Schicht unseres Data Lake gespeichert. Die Benachrichtigungen liefern den Wettbewerbern für ein bestimmtes Produkt ihre Preise, Erfüllungskanäle, Lieferzeiten und viele weitere Variablen. Sie bieten auch ein plattformabhängiges Sichtbarkeitsmaß, das als boolesche Variable (sichtbar oder nicht sichtbar) ausgedrückt werden kann. Wir erhalten bei jeder Angebotsänderung eine Benachrichtigung, was sich bei allen Produkten unserer Kunden auf mehrere Millionen Ereignisse pro Monat summiert.

Aus diesem Datensatz extrahieren wir die Trainingsdaten wie folgt: Für jede Benachrichtigung koppeln wir die sichtbaren Angebote mit allen nicht sichtbaren Angeboten und umgekehrt. Jeder Datenpunkt stellt einen Wettbewerb zwischen zwei Verkäufern dar, bei dem es einen klaren Gewinner und Verlierer gibt. Dieser Verarbeitungsauftrag wird in einem AWS Glue-Auftrag mit Spark implementiert. Das vorbereitete Trainings-Dataset wird zur Verwendung durch SageMaker in den Analyse-S3-Bucket gepusht.

Trainiere das Modell

Unser Modell klassifiziert für jedes Angebotspaar, ob ein bestimmtes Angebot sichtbar sein wird. Dieses Modell ermöglicht es uns, den besten Preis für unsere Kunden zu kalkulieren, die Sichtbarkeit basierend auf dem Wettbewerb zu erhöhen und ihren Gewinn zu maximieren. Darüber hinaus kann uns dieses Klassifizierungsmodell tiefere Einblicke in die Gründe dafür geben, warum unsere Einträge sichtbar oder nicht sichtbar sind. Wir verwenden die folgenden Funktionen:

• Verhältnis unseres Preises zu den Preisen der Wettbewerber
• Unterschied in den Fulfillment-Kanälen
• Anzahl der Rückmeldungen für jeden Verkäufer
• Feedback-Bewertung jedes Verkäufers
• Unterschied in den Mindestlieferzeiten
• Unterschied in den maximalen Lieferzeiten
• Verfügbarkeit des Produkts jedes Verkäufers

Adspert verwendet SageMaker, um das Modell zu trainieren und zu hosten. Wir verwenden die Implementierung von Scikit-Learn Random Forest in SageMaker-Skriptmodus. Wir fügen auch einige Funktionsvorverarbeitungen direkt in die Scikit-Learn-Pipeline in das Trainingsskript ein. Siehe folgenden Code:

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)

Eine der wichtigsten Vorverarbeitungsfunktionen ist transform_price, der den Preis durch das Minimum des Mitbewerberpreises und eine externe Preisspalte dividiert. Wir haben festgestellt, dass diese Funktion einen relevanten Einfluss auf die Modellgenauigkeit hat. Wir wenden auch den Logarithmus an, um das Modell auf der Grundlage relativer Preisunterschiede und nicht absoluter Preisunterschiede entscheiden zu lassen.

Im training_script.py -Skript definieren wir zunächst, wie das Scikit-Learn erstellt wird ColumnTransformer So wenden Sie die angegebenen Transformatoren auf die Spalten eines Datenrahmens an:

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')

Im Trainingsskript laden wir die Daten von Parquet in einen Pandas-Datenrahmen, definieren die Pipeline der ColumnTranformer und für RandomForestClassifier, und trainieren Sie das Modell. Anschließend wird das Modell mit serialisiert 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'))

Im Trainingsskript müssen wir auch Funktionen für die Inferenz implementieren:

• input_fn – Ist verantwortlich für das Parsen der Daten aus dem Request-Body der Payload
• model_fn – Lädt das Modell, das im Trainingsabschnitt des Skripts abgelegt wurde, und gibt es zurück
• vorhersage_fn – Enthält unsere Implementierung, um mithilfe der Daten aus der Nutzlast eine Vorhersage vom Modell anzufordern
• vorhersage_wahrscheinlich – Um vorhergesagte Sichtbarkeitskurven zu zeichnen, geben wir die Klassenwahrscheinlichkeit mit zurück predict_proba Funktion anstelle der binären Vorhersage des Klassifikators

Siehe folgenden Code:

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

Die folgende Abbildung zeigt die auf Verunreinigungen basierenden Feature-Wichtigkeiten, die von zurückgegeben werden Zufälliger Waldklassifizierer.

Mit SageMaker konnten wir das Modell mit einer großen Datenmenge (bis zu 14 Milliarden tägliche Transaktionen) trainieren, ohne unsere bestehenden Instanzen zu belasten oder einen separaten Computer mit ausreichend Ressourcen einrichten zu müssen. Da die Instanzen nach dem Trainingsjob sofort heruntergefahren werden, war das Training mit SageMaker außerdem äußerst kosteneffizient. Die Modellbereitstellung mit SageMaker funktionierte ohne zusätzlichen Arbeitsaufwand. Ein einziger Funktionsaufruf im Python-SDK reicht aus, um unser Modell als Inferenzendpunkt zu hosten, und es kann auch problemlos von anderen Diensten angefordert werden, die das SageMaker-Python-SDK verwenden. Siehe folgenden Code:

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})

Das Modellartefakt wird in Amazon S3 durch die Fit-Funktion gespeichert. Wie im folgenden Code zu sehen ist, kann das Modell als geladen werden SKLearnModel -Objekt mithilfe des Modellartefakts, des Skriptpfads und einiger anderer Parameter. Anschließend kann es auf den gewünschten Instanztyp und die Anzahl der Instanzen bereitgestellt werden.

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
)

Bewerten Sie das Modell in Echtzeit

Immer wenn eine neue Benachrichtigung für eines unserer Produkte gesendet wird, möchten wir den optimalen Preis berechnen und übermitteln. Um optimale Preise zu berechnen, erstellen wir einen Vorhersagedatensatz, in dem wir unser eigenes Angebot mit dem Angebot jedes Wettbewerbers für eine Reihe möglicher Preise vergleichen. Diese Datenpunkte werden an den SageMaker-Endpunkt weitergeleitet, der die vorhergesagte Wahrscheinlichkeit zurückgibt, gegenüber jedem Wettbewerber für jeden gegebenen Preis sichtbar zu sein. Wir nennen die Wahrscheinlichkeit, sichtbar zu sein vorhergesagte Sichtbarkeit. Das Ergebnis kann für jeden Wettbewerber als Kurve visualisiert werden, die das Verhältnis zwischen unserem Preis und der Sichtbarkeit darstellt, wie in der folgenden Abbildung dargestellt.

In diesem Beispiel ist die Sichtbarkeit gegenüber Wettbewerber 1 fast eine stückweise konstante Funktion, was darauf hindeutet, dass wir hauptsächlich den Preis unter einen bestimmten Schwellenwert senken müssen, ungefähr den Preis des Wettbewerbers, um sichtbar zu werden. Allerdings nimmt die Sichtbarkeit gegenüber Konkurrent 2 nicht so stark ab. Obendrein haben wir auch bei einem sehr hohen Preis noch eine 50%ige Chance sichtbar zu sein. Die Analyse der Eingabedaten ergab, dass der Wettbewerber eine geringe Anzahl von Bewertungen hat, die zufällig sehr schlecht sind. Unser Modell hat gelernt, dass diese spezielle E-Commerce-Plattform Verkäufern mit schlechten Feedback-Bewertungen einen Nachteil verschafft. Wir haben ähnliche Effekte für die anderen Funktionen entdeckt, wie den Erfüllungskanal und die Versandzeiten.

Die notwendigen Datentransformationen und Rückschlüsse auf den SageMaker-Endpunkt werden in AWS Glue implementiert. Der AWS Glue-Job arbeitet in Mikrobatches an den von Lambda erfassten Echtzeitdaten.

Schließlich wollen wir die aggregierte Sichtbarkeitskurve berechnen, die die prognostizierte Sichtbarkeit für jeden möglichen Preis darstellt. Unser Angebot ist sichtbar, wenn es besser ist als die Angebote aller anderen Verkäufer. Unter der Annahme einer Unabhängigkeit zwischen den Wahrscheinlichkeiten, gegenüber jedem Verkäufer sichtbar zu sein, bei unserem Preis, ist die Wahrscheinlichkeit, gegenüber allen Verkäufern sichtbar zu sein, das Produkt der jeweiligen Wahrscheinlichkeiten. Das heißt, die aggregierte Sichtbarkeitskurve kann durch Multiplikation aller Kurven berechnet werden.

Die folgenden Abbildungen zeigen die vorhergesagten Sichtbarkeiten, die vom SageMaker-Endpunkt zurückgegeben werden.

Die folgende Abbildung zeigt die aggregierte Sichtbarkeitskurve.

Zur Berechnung des optimalen Preises wird zunächst die Sichtbarkeitskurve geglättet und anschließend mit der Marge multipliziert. Zur Berechnung der Marge verwenden wir die Warenkosten und die Gebühren. Die Kosten der verkauften Waren und Gebühren sind die statischen Produktinformationen, die über AWS DMS synchronisiert werden. Basierend auf der Gewinnfunktion berechnet Adspert den optimalen Preis und übermittelt ihn über die API der Plattform an die E-Commerce-Plattform.

Dies ist im AWS Lambda-Vorhersageoptimierer implementiert.

Die folgende Abbildung zeigt die Beziehung zwischen prognostizierter Sichtbarkeit und Preis.

Die folgende Abbildung zeigt den Zusammenhang zwischen Preis und Gewinn.

Zusammenfassung

Der bestehende Ansatz von Adspert zur Gewinnmaximierung konzentriert sich auf das Bid-Management, um die Werbeeinnahmen zu steigern. Um auf E-Commerce-Marktplätzen eine hervorragende Leistung zu erzielen, müssen Verkäufer jedoch sowohl die Werbung als auch die wettbewerbsfähige Preisgestaltung ihrer Produkte berücksichtigen. Mit diesem neuen ML-Modell zur Vorhersage der Sichtbarkeit können wir unsere Funktionalität erweitern, um auch die Preise der Kunden anzupassen.

Das neue Pricing-Tool muss in der Lage sein, das ML-Modell auf einer großen Datenmenge automatisiert zu trainieren sowie Datentransformationen, Vorhersagen und Preisoptimierungen in Echtzeit durchzuführen. In diesem Beitrag sind wir durch die wichtigsten Schritte unserer Preisoptimierungs-Engine und der AWS-Architektur gegangen, die wir in Zusammenarbeit mit dem AWS Data Lab implementiert haben, um diese Ziele zu erreichen.

Die Umsetzung von ML-Modellen vom Konzept bis zur Produktion ist in der Regel komplex und zeitaufwändig. Sie müssen große Datenmengen verwalten, um das Modell zu trainieren, den besten Algorithmus für das Training auswählen, die Rechenkapazität während des Trainings verwalten und das Modell dann in einer Produktionsumgebung bereitstellen. SageMaker reduzierte diese Komplexität, indem es das Erstellen und Bereitstellen des ML-Modells viel einfacher machte. Nachdem wir die richtigen Algorithmen und Frameworks aus der großen Auswahl an verfügbaren Optionen ausgewählt hatten, verwaltete SageMaker die gesamte zugrunde liegende Infrastruktur, um unser Modell zu trainieren und es in der Produktion bereitzustellen.

Wenn Sie sich mit SageMaker vertraut machen möchten, können Sie die Immersion Day-Workshop kann Ihnen dabei helfen, ein umfassendes Verständnis dafür zu erlangen, wie Sie ML-Anwendungsfälle aus Feature-Engineering und den verschiedenen integrierten Algorithmen erstellen und wie Sie das ML-Modell in einem produktionsähnlichen Szenario trainieren, optimieren und bereitstellen. Es führt Sie dazu, Ihr eigenes Modell einzubringen und ein On-Premise-ML-Workload-Lift-and-Shift auf die SageMaker-Plattform durchzuführen. Es demonstriert außerdem fortgeschrittene Konzepte wie Modell-Debugging, Modellüberwachung und AutoML und hilft Ihnen, Ihre ML-Workload durch die AWS ML Well-Architected-Linse zu bewerten.

Wenn Sie Hilfe bei der Beschleunigung der Implementierung von Anwendungsfällen benötigen, die Daten, Analysen, KI und ML, Serverless und Containermodernisierung beinhalten, wenden Sie sich bitte an die AWS-Datenlabor.

Über die Autoren

Viktor Enrico Jeney ist Senior Machine Learning Engineer bei Adspert mit Sitz in Berlin, Deutschland. Er erstellt Lösungen für Vorhersage- und Optimierungsprobleme, um den Gewinn der Kunden zu steigern. Viktor hat einen Hintergrund in angewandter Mathematik und liebt die Arbeit mit Daten. In seiner Freizeit lernt er gerne Ungarisch, praktiziert Kampfsport und spielt Gitarre.

Ennio Pastore ist Datenarchitekt im AWS Data Lab-Team. Er begeistert sich für alles, was mit neuen Technologien zu tun hat, die sich positiv auf Unternehmen und die allgemeine Lebensgrundlage auswirken. Ennio hat über 9 Jahre Erfahrung in der Datenanalyse. Er unterstützt Unternehmen bei der Definition und Implementierung von Datenplattformen in verschiedenen Branchen wie Telekommunikation, Banken, Spiele, Einzelhandel und Versicherungen.