Az AWS kontextuális banditokkal személyre szabná a teljes ügyfélszerzési tölcsért

A generált tartalmak után a kiválasztás vált kérdéssé

Az AWS október 1-jei bejegyzése szerint 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 probléma jelentkezik: a sok lehetőség közül melyiket kell megmutatni az egyes ügyfeleknek, és mennyi idő alatt lehet megtanulni, melyik működik a legjobban.

Az Amazon Payments erre a kiválasztási problémára egy többcélú, kontextuális többkarú banditot (multi-armed bandit, MAB) alkalmazott az Amazon SageMaker AI platformon. A módszerben minden tartalomváltozat egy külön „kar”, a rendszer pedig éles forgalomban próbálja ki ezeket. A jól teljesítő változatok egyre több megjelenést kapnak, miközben a modell továbbra is teszteli a bizonytalanabb lehetőségeket.

Ez az úgynevezett kiaknázás és felfedezés közötti egyensúly: a rendszer egyrészt a jelenleg legjobbnak tűnő tartalmat szolgálja ki, másrészt új bizonyítékokat gyűjt a többi változatról. Az AWS szerint a generatív AI által megsokszorozott tartalomváltozatok miatt a banditok szerepe várhatóan nőhet az A/B/n tesztelés mellett.

A LinUCB az ügyfél jellemzői alapján választ

Az Amazon Payments az Upper Confidence Bound, röviden UCB stratégiát választotta. Ez az egyes tartalomváltozatok becsült jutalmát egy bizonytalansági bónusszal egészíti ki, így egyensúlyt teremt a kiaknázás és a felfedezés között. Az AWS kiemeli, hogy a döntési szabály determinisztikus, ezért minden megjelenítés döntése megmagyarázható és szükség esetén reprodukálható.

A hagyományos bandit az egész közönség számára kereshet egyetlen legjobb változatot. A kontextuális bandit ezzel szemben a látogatás jellemzőit is figyelembe veszi. A rendszer az ügyfeleket viselkedési jelekből, például fizetési viselkedésből és tranzakciós összetételből felépített kontextusvektorral ábrázolja. 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 választott módszer a Linear UCB, vagyis a LinUCB. Minden tartalomváltozat külön nyilvántartja, milyen ügyféljellemzők kapcsolódtak konverzióhoz, és milyen látogatásokkal találkozott. A bizonytalansági bónusz így nagyobb azoknál a látogatótípusoknál, amelyeket az adott változat ritkán látott, és kisebb ott, ahol már sok tapasztalat áll rendelkezésre.

Három tölcsérszakaszt optimalizálnak egyszerre

Az Amazon Payments ügyfélszerzési folyamata három lépésből áll: a jelentkezés elindításából, a jelentkezés benyújtásából és a jóváhagyásból. Az AWS szerint ezek a mérőszámok nem feltétlenül mozognak együtt. A kezdésekre optimalizált tartalom szélesebb közönséget vonzhat, miközben a jóváhagyás attól is függ, hogy az ajánlat valóban megfelel-e a jelentkezőnek.

Ha a rendszer csak az egyik szakaszt figyeli, ronthatja a többi eredményét. Az AWS ezt „libikókaproblémának” nevezi. A kizárólagos jóváhagyásoptimalizálás pedig kevés visszajelzést adna, mivel a jóváhagyások ritkák és késleltetve jelennek meg.

A megoldás három külön LinUCB modellt futtat, egyet a kezdésre, egyet a benyújtásra, egyet pedig a jóváhagyásra. A rendszer ezek UCB-pontszámait súlyozott összegként kombinálja, majd az így kapott érték alapján választ tartalomváltozatot. A tesztben megközelítőleg egyenlő súlyokat használtak. Az AWS szerint a jóváhagyások súlya később növelhető, amikor a modell már több tapasztalattal rendelkezik.

Hét hetes online teszt és elérhető kódpélda

Az AWS közlése szerint a vizsgálat egy hét héten át futó online A/B teszt volt. Az egyik ügyfélpopulációnál jelenleg magas, egy számjegyű százalékos relatív javulást látnak a tölcsér végi konverzióban, míg egy másik populációnál nem mértek javulást a meglévő élményhez képest.

A vállalat szerint a különbség oka végül a tartalom volt, nem a modell. A megközelítés kipróbálásához gyorsindító Jupyter-notebookot készítettek Amazon SageMaker AI-hoz. A repository parancssoros bemutatót és egységteszteket is tartalmaz, a módszer pedig szintetikus adatokon is vizsgálható.

Az eredmény a felhasználók szempontjából azt jelentheti, hogy ugyanaz a kampány vagy ajánlat eltérő tartalommal jelenhet meg az egyes látogatók viselkedési jelei alapján. A közölt adatok ugyanakkor csak a vizsgált ügyfélpopulációkra és a hét hetes tesztre vonatkoznak, ezért az AWS bejegyzése nem állít általános javulást minden közönség esetében.