Jeg ledede Dynamic Product Ads på Twitter, hvor vi matchede millioner af brugere til hundredvis af millioner af e-handelsprodukter i realtid. Udgangen var de top 5-6 produkter, som hver bruger var mest tilbøjelige til at købe. Systemet brugte produkt- og brugerembeddings med klassiske ML-modeller til at levere personaliserede annoncer på Twitters skala. Vi så 15-18% forbedringer i CTR og 12% forbedringer i konverteringsraten sammenlignet med brandannoncer. Men nu taler alle om AI og store sprogmodeller, som om de vil revolutionere alt. Så jeg tænkte på, om jeg ville bygge de dynamiske produktannoncer i dag, ville jeg bruge LLM'er? Svaret: Jeg ville bruge LLM'er til omkring 20% af systemet, specifikt til at generere indlejringer, og holde alt andet det samme. Vores oprindelige tilgang Problemet ved hånden: anbefale produkter til en bruger, som de er mest tilbøjelige til at klikke og købe, mens de hurtigt scrolling deres tidslinje. Der var millioner af produkter at vælge fra og annoncører. På toppen af det, der var millioner af brugere scrolling på samme tid. Systemet var nødt til at foretage forudsigelser for millioner af brugere inden for sub-millisekund latens. Ad Serving pipeline ville have brug for at fuldføre forudsigelsen i under 50 millisekunder, maksimalt. Tilgangen var meget lærebog (for 2022 mindst). Produktemballage Vi brugte hver produkts metadata, såsom titel, beskrivelse, kategori, pris osv., og kodede det i et 128-dimensionelt tæt vektorrum. Bruger Embeddings Brugere blev repræsenteret af vektorer baseret på signaler som deres engagement på platformen, profiloplysninger og tidligere køb. Den matchende model På indledningstidspunktet ville vi bruge en to-trins tilgang. Først ville vi køre en hurtig, omtrentlig nabosøgning for at hente kandidatprodukter, hvis indlejringer var tæt på brugerindlejringer. Derefter ville vi bruge et gradientforstærket beslutningstræ til at score disse kandidater og indarbejde yderligere funktioner som nyhed, prissignaler og kontekst som tidspunktet på dagen. Modellen og ANN (omtrentlig nærmeste nabo) var forklarelige, debuggable, og vigtigst af alt, hurtigt nok til Twitters skala. Hvordan ville jeg nærme mig det i dag? Hvis jeg byggede dette system i dag, her er hvad jeg rent faktisk ville ændre. Bedre produktindlejring med LLM-kodere Den største forbedring ville være i at generere bedre produktembeddings. Moderne store sprogmodeller er bemærkelsesværdigt gode til at forstå semantisk betydning og kontekst. I stedet for at stitch sammen produktbeskrivelser (de fleste af dem var ret dårlige til at begynde med), ville jeg bruge en LLM-baseret koder til at generere produktembeddings. Dette betyder noget, fordi et produkt med titlen "løbe sko" ville være semantisk tæt på "sneakers til jogging", selvom de ikke deler de nøjagtige ord. Gør det uden anstrengelse. all-MiniLM-L6-v2 Vi havde engang en Nike-produktkatalogindgang med titlen 'Air Max 270 React', at vores 2022-embeddings ikke kunne matche brugere, der søgte efter 'cushioned løbesko' eller 'athletic sneakers' fordi der ikke var nogen nøgleord overlapning. produktet fik 35-40% færre indtryk end lignende varer i sin første uge, indtil vi samlede nok engagement data. Forbedret koldstart Når et nyt produkt vises i en katalog, kan LLM udtrække rige signaler fra produktbeskrivelser, anmeldelser og billeder for at generere en rimelig indledende indlejring. På samme måde kan moderne kodere bedre forstå deres profiloplysninger og indledende tweets (hvis de har nogen) for at skabe meningsfulde repræsentationer. Så hvor ville LLMs passe ind i den faktiske arkitektur? Hybrid tilgang Jeg ville stadig bruge klassisk ML til faktisk opbevaring og servering af lag. Arkitekturen ville se ud som: Feature LLM or Classic LLM-based encoder to generate user and product embeddings LLM Match embeddings to generate candidate products per user Classic Final scoring and ranking Classic LLM-baseret koder til at generere bruger- og produktembeddings LLM Match indlejringer til at generere kandidatprodukter pr. bruger Klassisk Final scoring og ranking Klassisk Hvorfor skulle jeg bruge klassiske modeller til scoring? Årsagerne er latens, omkostninger og forklarbarhed. LLM'er kan ikke forudsige produkter for millioner af brugere på under 10 millisekunder. De er en overkill for at kombinere numeriske funktioner og træffe en placeringsbeslutning. Klassiske modeller ville gøre dette i mikrosekunder. På Twitters skala oversætter forskellen mellem 1ms og 10ms inference tid til millioner af dollars i infrastrukturomkostninger og målbare fald i brugerengagement. Kørsel LLM inference for hver forudsigelse anmodning ville koste 50-100x mere end vores klassiske tilgang. Hvad med Ad Copy? Der er en masse hype på internettet om at bruge LLM'er til at generere personlig reklame kopi på flyet eller til at argumentere om brugerens hensigt i realtid. Generering af annoncekopiering med LLM'er introducerer uacceptable risici som hallucinationer om produktfunktioner, inkonsekvent branding og indhold, der er svært at gennemgå på denne skala. Systemet ville have brug for at vise millioner af annoncevariationer om dagen, og der ville ikke være nogen måde at gennemgå dem for nøjagtighed og brand sikkerhed. En hallucineret påstand om et produkt som "vandtæt", når det ikke er, eller "FDA-godkendt", når det ikke er, ville skabe juridisk ansvar. Hvad ændrer sig ikke? Det er stadig den sværeste del. Uanset om systemet bruger indlejringer fra 2022 eller LLMs fra 2026, forbliver den grundlæggende udfordring den samme: at konkludere, hvad nogen ønsker af støjende signaler. Nogen, der tweets om løbesko, kan være en maratonløber shopping for deres næste par, eller en tilfældig observatør, der lige har set et løb på tv. Dette problem har brug for gode data til at løse, gennemtænkt funktionsteknik og masser af eksperimenter. Understanding user intent I skalaen tæller hvert millisekund. Brugere ville opgive oplevelser, der føles langsomme. Ad-systemer kan ikke bremse indlæsningen af tidslinjen. Jeg har set flere ML-infrastruktursystemer gå i stykker i A/B-tests, fordi de tilføjede 100ms af latens til et godt olieret system. Modellen kunne være bedre, men latenskravet trumfer alt. Latency requirements Problemer som kold start for nye produkter eller brugere, og datakvalitetsproblemer, når kataloger har manglende eller forkerte produktbeskrivelser, er stadig der. Last-mile problems Et team, der kan køre 10 eksperimenter om ugen med en enklere model, vil konstant overgå et team, der kører 1 eksperiment om ugen med en meget sofistikeret model. Evnen til at teste hurtigt, måle resultater og iterere er mere værdifuld end marginale forbedringer i modelkvalitet. Da vi lancerede Dynamic Product Ads, kørte vi 3-4 eksperimenter om ugen. Vi testede forskellige indlejringsdimensioner, forskellige ANN-algoritmer og forskellige funktioner i scoringmodellen. De fleste eksperimenter mislykkedes. Men de, der arbejdede sammensat. Den hastighed betød mere end at vælge den "perfekte" modelarkitektur. Iteration speed Det egentlige spørgsmål er: Hvor er Bottleneck? For at være ærlig, det meste af diskussionen "hvordan ville du bygge det i dag med moderne AI" går glip af pointen. Spørgsmålet bør ikke være, hvad der er muligt med den nye teknologi. For os handlede flaskehalsen aldrig om kvaliteten af indlejringerne. Det handlede om at forstå brugerens hensigt, håndtere datakvalitetsproblemer i produktkatalogerne og styre problemer med koldstart, samt bygge systemer, der kunne håndtere skala. Hvis jeg byggede dette system i dag, ville jeg bruge 20% af min indsats på at "bruge LLM til at generere bedre indlejringer" og 80% på de samme problemer med skalering, datakvalitet, eksperimentering og forståelse af brugerens hensigt. Den upopulære opfattelse Den teknologiske industri elsker revolutionerende fortællinger. Der var lignende hype omkring blockchain og Web3 for et par år siden. Men sandheden er, at de fleste produktions ML-systemer arbejder, skalerer og tjener penge. Den revolutionerende tilgang til at bruge LLM ville gøre 5% forbedring, men ville være 10x langsommere og 100x dyrere. Moderne AI er virkelig værdifuld, når den anvendes omhyggeligt til flaskehalse, ikke som en erstatning for hele systemet, der allerede fungerer.
