Amazon Payments personalisiert seinen Akquise-Funnel mit Contextual Bandits

Vom Erzeugen zum Auswählen von Inhalten

AWS versteht die Arbeit als nächsten Schritt, nachdem generative KI personalisierte Inhalte günstig herstellbar gemacht hat. In einem früheren Beitrag zeigte das Unternehmen, wie sich mit Amazon Bedrock personalisierte Inhalte in großem Umfang erstellen lassen, und zwar im Rahmen von Markenrichtlinien und Schutzmechanismen. Offen ist nun die Auswahl: Welche von vielen Varianten soll jeder Kunde sehen, und wie schnell kann ein System die Antwort lernen?

Ein Multi-Armed-Bandit (MAB) ist ein Verfahren des bestärkenden Lernens für Situationen mit vielen Optionen und begrenztem Traffic. Jede Inhaltsvariante gilt dabei als „Arm“. Das System testet die Arme im Live-Traffic und verlagert die Ausspielungen schrittweise zu den erfolgreichen, hält aber einen Teil zurück, um die übrigen weiter zu prüfen. AWS beschreibt das als Zielkonflikt zwischen Exploitation und Exploration. Weil ein Bandit beides dauerhaft betreibt, verbessert er sich fortlaufend, wenn neue Varianten hinzukommen, und muss nicht auf das Ende eines Tests warten. AWS betont, dass A/B/n-Tests weiterhin ihren Platz haben, erwartet aber, dass Bandits mit steigender Variantenzahl an Bedeutung gewinnen.

LinUCB und der Kontextvektor

Amazon Payments entschied sich für die Upper-Confidence-Bound-Strategie (UCB), die den Arm mit der höchsten geschätzten Belohnung plus einem Unsicherheitsaufschlag auswählt. Laut AWS liefert ihre deterministische Auswahlregel für jede Ausspielung eine nachvollziehbare und reproduzierbare Entscheidung.

Ein Standard-Bandit lernt einen einzigen besten Arm für das gesamte Publikum, daher braucht Personalisierung Kontext. AWS weist darauf hin, dass segmentierte Bandits für jede manuell definierte Gruppe eine eigene Instanz betreiben und jede Gruppe eigenen Traffic benötigt. Kontextuelle Bandits stützen sich dagegen auf einen Merkmalsvektor, sodass ein in einem Kontext gelerntes Muster auf ähnliche Besuche übertragen wird. In der Produktion wird jeder Kunde durch Verhaltenssignale wie Zahlungsverhalten und Transaktionsmix repräsentiert. Die Entity-ID dient nur dazu, die Empfehlung dem richtigen Besucher zuzuordnen, und fließt nie als Eingabe in das Modell ein.

Das Team wählte Linear UCB (LinUCB), eingeführt von Li et al. (2010). AWS bezeichnet das Verfahren als recheneffizient, nachvollziehbar und geeignet für einen großen Armraum bei wenigen Warm-Start-Daten. Es nimmt an, dass die erwartete Belohnung eines Arms eine lineare Funktion des Kontextvektors ist, wodurch es auf bislang unbekannte Besucher verallgemeinern kann. Der Explorationsaufschlag hängt vom Kontext ab: Er ist groß für einen Besuchertyp, den ein Arm selten gesehen hat, und klein für einen, den er oft gesehen hat.

Optimierung über den gesamten Funnel

Die Customer Journey besteht in diesem Anwendungsfall aus drei Schritten: Antragsbeginn, Einreichung und Genehmigung. AWS zufolge bewegen sich diese Phasen nicht im Gleichschritt. Inhalte, die die Zahl der Antragsstarts steigern, sprechen tendenziell ein breites Publikum an, doch die Genehmigung hängt davon ab, ob das Angebot zum Antragsteller passt. Die Optimierung einer Phase kann daher eine andere beeinträchtigen. AWS nennt das das Wippenproblem. Auch die alleinige Optimierung auf Genehmigungen hat eine Schwäche, denn sie sind selten und treten verzögert auf, sodass dem Modell Signale fehlen.

Die Lösung betreibt pro Phase ein LinUCB-Modell und kombiniert deren UCB-Scores in einer gewichteten Linearkombination. Die Gewichte können sich an Geschäftsprioritäten orientieren oder in einem Kalibrierungsschritt gelernt werden. Das Team verwendete annähernd gleiche Gewichte. AWS regt an, Genehmigungen nach dem Warmlaufen des Modells stärker zu gewichten oder bei umstrittenem Zielkonflikt eine Pareto-Front zu nutzen.

Zur Abstimmung: Für den Explorationsparameter Alpha ist laut AWS 1,0 ein sinnvoller Standardwert, der typische Bereich liegt zwischen 0,1 und 2,0. AWS rät, bei großem Armraum und knapper Historie mit einem höheren Wert zu beginnen und ihn zu senken, sobald sich Belege ansammeln. Zu hohe Werte verschwenden Traffic auf schwache Arme, zu niedrige bergen das Risiko, sich auf einen suboptimalen Arm festzulegen.

Was die Ergebnisse bedeuten

Das berichtete Ergebnis fällt gemischt aus. Eine Kundengruppe erzielte einen relativen Anstieg der Conversion am Ende des Funnels im hohen einstelligen Prozentbereich, eine andere verzeichnete keine Verbesserung. AWS erklärt: „Das Problem lag am Ende nicht am Modell, sondern an den Inhalten.“ Die Quelle legt nahe, dass die Auswahl nur dann hilft, wenn die verfügbaren Varianten dem Modell etwas Brauchbares zur Auswahl bieten.

AWS stellt außerdem ein Code-Repository bereit, darunter ein Quick-Start-Jupyter-Notebook, eine Kommandozeilen-Demo und Unit-Tests, damit Teams das Verfahren mit synthetischen Daten auf Amazon SageMaker AI ausprobieren können.