Amazon Payments a folosit un contextual bandit multi-obiectiv pe SageMaker AI pentru a personaliza un funnel de achiziție. Rezultatul raportat într-un test A/B de șapte săptămâni: un lift relativ de ordinul unei singure cifre mari la conversia finală, pentru un singur segment de clienți. Alt segment nu a înregistrat nicio îmbunătățire. Constrângerea reală a fost conținutul, nu modelul.

Asta e tot articolul, condensat. Restul e ce faci cu informația. Pentru un marketer care produce acum conținut personalizat cu AI generativ la cost aproape zero, problema nu mai e „ce texte scriu”, ci „pe care dintre cele 400 de variante o arăt acestui vizitator, acum, și cât durează până aflu răspunsul”. AWS a publicat un studiu de caz detaliat pe blogul lor de machine learning, iar noi îl citim ca operatori, nu ca cercetători.

De ce A/B testul clasic nu mai ține pasul cu volumul

Modelul clasic de experimentare are o limită structurală: testezi două, maxim trei variante, aștepți semnificația statistică, apoi oprești și muți traficul pe câștigător. Funcționează când produci trei bannere pe lună. Nu funcționează când un pipeline generativ îți scoate 200 de combinații de imagine și tagline într-o oră.

Un multi-armed bandit rezolvă exact asta. Tratează fiecare variație ca pe un „braț”, servește trafic real către toate, și mută progresiv afișările către cele care performează, păstrând mereu o felie de trafic pentru explorare. Nu așteaptă să se încheie testul, pentru că nu există un „test care se încheie”. Compromisul dintre exploatare (servești ce merge acum) și explorare (mai încerci ce nu știi) rulează continuu.

AWS notează în materialul lor că A/B/n testingul încă are locul lui, dar se așteaptă ca bandiții să câștige teren pe măsură ce AI generativ accelerează numărul de variații. Sunt de acord cu nuanța. Nu înlocuiești testarea, o folosești pentru decizii structurale (layout, preț, ofertă) și lași banditul să aloce trafic între variațiuni de conținut.

Dacă te interesează cum arată partea de conținut văzută dinspre Google, avem o analiză separată despre ghidul de conținut main content și EOT/SA, relevantă pentru ce materiale intră în pool.

Bandit contextual: diferența care contează pentru un cont real

Un bandit standard învață un singur câștigător pentru toată audiența. Un bandit contextual condiționează decizia pe caracteristici ale vizitei. În producție, Amazon Payments nu folosește segmente fixe („bărbați 25-34”), ci un vector de semnale comportamentale: comportament de plată, mix de tranzacții, altele similare.

Punctul fin, și ăsta e detaliul pe care mulți îl ratează când citesc repede: ID-ul de entitate (cheia opacă gen entity_id) e folosit DOAR pentru a ruta recomandarea înapoi la vizitatorul corect. Nu e niciodată input în model. Adică modelul învață tipare, nu memorizează indivizi. Pentru oricine e prins între performanță și conformitate pe date personale, asta e distincția care contează la o discuție cu juridicul.

Algoritmul ales e LinUCB (Li et al., 2010). Nu e cel mai nou, dar e computational eficient, determinist în selecție, deci auditabil și reproductibil, și funcționează cu un spațiu mare de brațe și date puține la început. Fiecare braț ține două registre actualizate incremental: unul pentru semnalele care au dus la conversii, altul pentru ce vizitatori a văzut. Împărțirea lor dă estimarea. Bonusul de explorare e dependent de context: mare pentru un tip de vizitator rar văzut, mic pentru unul familiar. Un bandit simplu explorează la o rată globală; LinUCB ajustează explorarea per vizitator.

Problema leagănului: de ce optimizarea unui singur pas strică restul

Funnelul din studiu are trei pași: start aplicație, trimitere, aprobare. Și aici apare capcana pe care o vezi și în conturi de e-commerce cu funnel lung.

Conținutul optimizat pentru „start-uri” atrage o audiență largă. Dar aprobarea depinde de potrivirea reală dintre ofertă și aplicant. Dacă optimizezi un singur pas izolat, îl poți degrada pe altul. AWS numește asta problema leagănului. Invers, dacă optimizezi doar pentru aprobări, mori de foame: aprobările sunt rare și întârziate, modelul nu primește destul semnal.

Soluția lor: un model LinUCB per etapă, combinate printr-o sumă ponderată a scorurilor. Ponderile se pot seta după priorități de business sau calibra separat. Ei au folosit ponderi aproximativ egale și menționează că ai putea crește greutatea aprobărilor după ce modelul e cald, sau folosi o frontieră Pareto dacă trade-off-ul e real contestat.

Feedbackul întârziat e tratat cu o fereastră de atribuire. Start-urile și trimiterile actualizează modelul imediat. Rezultatele de aprobare sunt ținute până la următorul ciclu de procesare în batch, ca să eviți biasul negativ din aplicații în așteptare. Se aliniază natural cu cadența lor săptămânală.

Constrângerea nu e modelul, e pool-ul de brațe

Aici e lecția cea mai utilă din tot studiul de caz, și AWS o spune direct: într-o populație liftul a fost de ordinul unei cifre mari, în alta zero. Problema a fost conținutul, nu modelul.

Un bandit e la fel de bun ca pool-ul de brațe pe care îl are la dispoziție. Dacă toate variațiile tale sunt variații ale aceleiași idei mediocre, banditul va alege cel mai bun dintr-un set slab. Excelent la alocare, inutil la calitate.

Cum au rezolvat-o structural: compoziție din blocuri mici, verificate individual. Imaginile tematice pe industrie și tagline-urile orientate pe beneficiu formează spațiul de brațe prin produs cartezian. Fiecare braț e o pereche (imagine, tagline). Un număr modest de blocuri produce un pool mare de variații distincte.

Controlul se face prin trei straturi:

Asta se leagă direct de subiectul AI Overviews pe 83% din căutările de brand: ai nevoie de volum de conținut bun, dar și de mecanisme care să aleagă ce funcționează, nu doar să producă.

Arhitectura pe AWS, pe scurt

SageMaker AI e serviciul central: training, procesare în batch, versionare, monitorizare. Au ales arhitectură batch din două motive: problema de selecție e offline (feedbackul se acumulează în zile), și comportamentul de selecție al vizitatorilor nu se schimbă destul de repede încât să justifice actualizări de model în timp real.

Fluxul săptămânal:

  1. Colectare date. Impresii și rezultate (start, submit, approve) sunt logate la finalul sesiunii și ajung în S3.
  2. Update model și inferență. Un job SageMaker AI Processing încarcă starea recentă a modelului din S3, descoperă automat prefixul cel mai recent, separă datele în feedback și inferență, actualizează incremental și scorează fiecare prospect. Au ales Processing job pentru că workloadul e un singur pas care face și update, și scor.
  3. Persistență și output. Starea modelului se scrie înapoi în S3 într-o cale datată, deci ai versionare și rollback natural. Recomandările per client ajung într-un key-value store cu latență mică (gen DynamoDB) care stă în fața traficului live.

Warm-start: modelele au pornit dintr-o perioadă de atribuire randomizată de conținut, ca banditul să aibă date nepărtinitoare la start. Asta e important. Dacă pornești banditul pe date deja biaxate de o regulă veche, înveți prejudecata, nu realitatea.

Bucla completă de personalizare, de la date la execuție, se intersectează și cu ce se întâmplă la nivel de platformă. Avem o analiză pe Shopify Next Gen Events și controlul real asupra update-urilor, pentru cine vrea să înțeleagă cum arată guvernanța datelor în comerț.

Ce înseamnă pentru tine

Ești antreprenor sau marketer în România. Ai un magazin online, un SaaS, un serviciu cu lead-uri. Ce extragi concret din asta?

Primul lucru: nu ai nevoie de 200 de variații ca să începi. Ai nevoie de 3-5 blocuri bune pe două dimensiuni (de exemplu imagine și mesaj) și de un sistem care alocă trafic inteligent. Chiar și un bandit simplu, fără context, care alocă între combinații de pagini de produs, poate bate un A/B test care rulează trei săptămâni și se oprește.

Al doilea: gândește funnelul ca pe un lanț, nu ca pe un punct. Dacă optimizezi doar adăugarea în coș, s-ar putea să atragi cumpărători care abandonează la plată. Dacă optimizezi doar checkout-ul finalizat, semnalul e rar și modelul învață lent. Împarte obiectivul pe etape și decide conștient cum le ponderezi.

Al treilea, și cel mai important: investește în pool-ul de conținut. Un model sofisticat peste conținut slab e doar o mașină de alocat trafic către mediocritate, eficient. Verifică blocurile individual, nu combinațiile. Ține totul într-un design system ca să nu ajungi cu 50 de variații care arată ca 50 de site-uri diferite.

Al patrulea: nu confunda ID-ul de client cu un feature de model. E o regulă de igienă, nu doar de conformitate.

Un avertisment de verificare. AWS raportează un lift de ordinul unei singure cifre mari, pentru UN segment, într-un test A/B de șapte săptămâni. Al doilea segment a avut zero îmbunătățire. Nu extrapola asta la „bandiții dau +8% la orice”. Rezultatul e specific contextului, pool-ului de conținut și populației. Dacă cineva îți vinde contextual bandits ca pe o ghiulea universală, cere-i pool-ul de brațe și segmentarea.

Întrebări frecvente

Trebuie să am echipă de ML ca să implementez asta? Nu neapărat pentru o versiune simplă. Există implementări de bandiți în biblioteci standard, iar AWS oferă un notebook de tip quick start pe SageMaker AI pentru a testa abordarea pe date sintetice. Pentru varianta contextuală multi-obiectiv în producție, cu feedback întârziat și integrare în funnel, ai nevoie de cineva care știe ce face. Nu e un task de duplicat dintr-un tutorial.

Cu ce diferă de un A/B test normal? A/B testul separă traficul în grupuri fixe, așteaptă semnificație statistică, apoi decide. Banditul alocă dinamic, învață continuu, și nu are un moment de „stop”. Bonus: poți adăuga variații noi oricând, fără să repornești testul. Costul e că auditabilitatea e mai complexă și ai nevoie de discipline de logging.

Cât de des trebuie rulat update-ul de model? În studiul de caz, săptămânal, ca baseline conservator. AWS notează că frecvența poate crește odată ce modelul demonstrează lift stabil, și că feedbackul de aprobare întârziat se incorporează în batch-urile ulterioare. Pentru un magazin online cu ciclu scurt de feedback, un update mai des poate avea sens. Testează cadența, nu o presupune.

Concluzia ALLSoft

AI-ul generativ rezolvă producția de conținut. Banditul rezolvă selecția. Ambele sunt utilaje, nu strategii. Analiza datelor, construcția pool-ului de brațe, definirea ponderilor pe etape, decizia despre ce înseamnă „lift acceptabil” pentru businessul tău: rămân decizii umane. Media buyerul senior care înțelege funnelul, citește datele și decide ce scalează și ce taie e cel care face diferența între un model care rulează și unul care produce rezultate.

La ALLSoft Agency lucrăm exact așa: pornim de la datele tale reale, construim testul, măsurăm, apoi scalăm. Fără hype, fără promisiuni de lift inventat. Dacă vrei să discuți cum ai putea aplica personalizarea inteligentă în contul tău, scrie-ne pe allsoftagency.ro și punem pe masă ce se poate măsura.