Az AWS kontextusfüggő bandittal személyre szabja a vásárlási tölcsért

Az Amazon Payments kontextusfüggő, több célra optimalizált banditrendszerrel választja ki, melyik személyre szabott tartalom jelenjen meg az egyes látogatóknak. Az AWS szerint egy héthetes online A/B-tesztben az egyik ügyfélcsoportnál magas, egy számjegyű százalékos relatív javulást láttak a tölcsér végső konverziójában.
- Az Amazon Payments kontextusfüggő LinUCB-banditot használ tartalomválasztásra.
- A rendszer az alkalmazásindítást, a benyújtást és a jóváhagyást egyszerre optimalizálja.
- Egy ügyfélpopulációnál magas, egy számjegyű relatív javulást láttak a végső konverzióban.
- Egy másik ügyfélcsoportnál nem javult az eredmény a korábbi élményhez képest.
- Az AWS Jupyter-notebookot, parancssoros demót és egységteszteket is közzétett.
A generált tartalmak után a kiválasztás lett a feladat
A generatív mesterséges intelligencia gyorsan és alacsony költséggel képes nagy mennyiségű, személyre szabott tartalmat előállítani. Ezzel azonban új kérdés jelent meg: az elérhető változatok közül melyiket kell megmutatni az adott ügyfélnek, és mennyi idő alatt lehet megtanulni, melyik működik a legjobban?
Az AWS 2026. október 1-jén közzétett bemutatója szerint az Amazon Payments ezt a kiválasztási problémát egy Amazon SageMaker AI-on futó, több célra optimalizált kontextusfüggő többkarú bandittal oldotta meg. A rendszer a termék megszerzéséhez vezető tölcsérben választ a tartalomváltozatok között.
Az eredményeket egy héthetes online A/B-tesztben vizsgálták. Az AWS közlése szerint az egyik ügyfélpopulációban magas, egy számjegyű százalékos relatív növekedést mértek a tölcsér végső konverziójában, egy másik csoportnál viszont nem javult az eredmény a korábbi élményhez képest. A vállalat szerint a problémát végül a tartalom, nem pedig a modell okozta.
A bandit folyamatosan tanul a látogatásokból
A többkarú bandit megerősítéses tanulási módszer olyan helyzetekre, ahol sok lehetőséghez kevés forgalom áll rendelkezésre. A rendszer minden tartalomváltozatot egy karnak tekint, élő forgalmon próbálja ki őket, majd fokozatosan több megjelenítést ad azoknak, amelyek jobban teljesítenek.
Közben a forgalom egy részét továbbra is a kevésbé ismert változatokra fordítja. Ez az exploitation, vagyis a jelenleg legjobbnak tartott lehetőség használata, valamint az exploration, vagyis az új lehetőségek kipróbálása közötti egyensúly. A bandit így folyamatosan tanul, és az új változatok megjelenésekor sem kell feltétlenül megvárni egy teszt lezárását.
Az Amazon Payments az Upper Confidence Bound, röviden UCB stratégiát választotta. Ez az egyes változatok becsült jutalmát egy bizonytalansági bónusszal egészíti ki. Az AWS szerint a determinisztikus döntési szabály auditálható és reprodukálható, így szükség esetén megmagyarázható, miért egy adott tartalom jelent meg.
A LinUCB az ügyfél jellemzőihez igazítja a választást
A hagyományos bandit egyetlen legjobb változatot keres az egész közönség számára. A kontextusfüggő bandit ezzel szemben a látogatás jellemzői alapján dönt. Az Amazon Payments éles rendszere minden ügyfelet viselkedési jelekből összeállított kontextusvektorral ír le. Ezek között a fizetési viselkedéshez és a tranzakciók összetételéhez hasonló jellemzők szerepelnek.
A rendszer nem előre rögzített csoportokhoz rendel külön modellt. Az AWS szerint a kontextusvektorral megtanult mintázat a hasonló látogatásokra is átvihető, külön csoportonkénti forgalomigény nélkül. Az entitásazonosító csak arra szolgál, hogy a megtanult ajánlást a megfelelő látogatóhoz irányítsák, a modell bemeneteként nem használják.
A megoldás a Linear UCB, vagyis LinUCB módszert alkalmazza. Minden kar külön nyilvántartja, milyen jutalmakhoz kapcsolódtak az egyes látogatói jelek, valamint azt is, milyen látogatókat látott már. A becslési bizonytalanság nagyobb marad azoknál a látogatótípusoknál, amelyekkel az adott változat ritkán találkozott, és csökken, ahogy több bizonyíték gyűlik össze.
Három tölcsérszakaszt optimalizálnak egyszerre
Az Amazon Payments ügyfélszerzési útja három lépésből áll: az alkalmazás elindításából, a benyújtásból és a jóváhagyásból. A vállalat ezért nem egyetlen mutatóra építette a rendszert, hanem mindhárom szakaszhoz külön LinUCB-modellt futtat.
Az AWS ezt a problémát mérleghatásként írja le. A kezdésekre optimalizált tartalom szélesebb közönséget vonzhat, miközben a jóváhagyás attól függ, hogy az ajánlat valóban illeszkedik-e a jelentkezőhöz. Ha csak a jóváhagyást optimalizálnák, kevés és későn érkező visszajelzésből kellene tanulniuk.
A három modell UCB-pontszámait súlyozott összegben egyesítik, majd azt a változatot választják, amelynek kombinált értéke a legmagasabb. A súlyok üzleti prioritások alapján adhatók meg, vagy külön kalibrációs lépéssel tanulhatók. A bemutatott megoldásban megközelítőleg azonos súlyokat használtak.
Az AWS egy Jupyter-notebookot, parancssoros bemutatót és egységteszteket is közzétett a módszer kipróbálásához. A példa szintetikus adatokon futtatható Amazon SageMaker AI-ban. A rendszer felfedezési paramétere, az alfa, magasabb értéknél több kísérletezést, alacsonyabb értéknél erősebb kihasználást eredményez. Az AWS által megadott tipikus tartomány 0,1 és 2,0 között van.


