Sådan byggede vi ChatGPT’s nye annonceteknologi med fokus på brugertillid og relevans

Traditionelle annoncesystemer er bygget til at reagere på enkeltstående udtryk for brugerens hensigt. En bruger søger efter eller ser noget online, annoncesystemet modtager disse søgninger og sidevisninger som hændelser, og systemet leder efter matchende annoncer ud fra hændelserne. At bygge annonceteknologi til ChatGPT var anderledes: Brugerens hensigt udvikler sig på tværs af samtaler og ændrer sig over flere udvekslinger i en samtale, nogle gange uden at der opstår et passende øjeblik til annoncering. For at understøtte dette nye paradigme byggede vi et skræddersyet system til annoncelevering. Denne nye type annonceteknologi bygger på en specialtilpasset, banebrydende LLM, der har gennemgået efteruddannelse. Den foretager værktøjskald til søgning (identificering af de bedste muligheder), rangering (forudsigelse af brugerengagement), relevansvurdering (evaluering af annoncens nytteværdi) og afvikling af auktioner til endelig annonceudvælgelse og prissætning.

Vores annoncesystem tager højde for nuancerne i brugerens skiftende mål gennem tre centrale designvalg: 1) annoncesessioner med hukommelse, så oplysninger huskes på tværs af udvekslinger i en samtale og på tværs af flere samtaler, 2) en specialtilpasset LLM, der har gennemgået efteruddannelse og bruger en arkitektur med værktøjskald til at fortolke samtalens kontekst og underliggende hensigt og derefter effektivt udvælge, rangere og levere annoncer, og 3) en annonceudvælgelsesproces, der kører adskilt fra ChatGPT’s svargenerering i sin egen tjeneste, så annoncer ikke påvirker svarene, og ChatGPT’s stemme forbliver neutral. Vi bruger vores LLM, der har gennemgået efteruddannelse, til at orkestrere hele annonceforløbet og finde den rette annonce til det rette tidspunkt ud fra både brugerens aktuelle udveksling og samtalehistorikken. Hvor det tidligere tog år at opbygge et selvforbedrende annoncesystem som dette, nåede ChatGPT Ads en omsætning svarende til 1 milliard dollar på årsbasis mindre end 200 dage efter lanceringen. Nu har over 100.000 annoncører annonceret på ChatGPT siden lanceringen.

En traditionel annonceanmodning begynder normalt med en klart defineret hændelse. En bruger indsender en søgeforespørgsel eller åbner en webside, og annoncesystemet modtager en anmodning. Denne type system er ret enkel: Det henter mulige annoncekandidater, rangerer dem, afholder en auktion for at prissætte muligheden passende og viser den valgte annonce til brugeren. I ChatGPT opstår et så konkret øjeblik ikke naturligt.

Folk går ind i en ChatGPT‑samtale med mål frem for en søgeforespørgsel, der kræver ét svar. De planlægger måske en rejse, vælger software til deres virksomhed, indretter et hjem eller lærer en ny hobby. Det sker ikke alt sammen i én udveksling i en samtale. ChatGPT hjælper ofte brugeren med undervejs at afklare, hvad der er vigtigt.

Som eksempel spurgte vores udviklingsteam ChatGPT, hvordan man træner til et løb: Samtalen begynder med et generelt spørgsmål om løb. Flere udvekslinger senere spørger de om sko til træningen. Samtalens kommercielle betydning ændrer sig, hver gang en ny betingelse kommer til, og denne personlige kontekst udvikler sig på tværs af flere sessioner. Et system, der handlede på den første besked, kunne helt misforstå hensigten og dermed risikere at forringe brugeroplevelsen og stå i vejen for brugeren.

For at bygge vores annoncesystem måtte vi gå videre end den traditionelle arkitektur med anmodning og svar og opbygge annonceteknologien fra bunden. Målet var at finde potentielle økonomiske muligheder og samtidig prioritere brugernes tillid og den værdi, de får.

At gøre hver besked til en selvstændig anmodning som i et traditionelt annoncesystem ville indebære flere risici i vores chat: 1) at fejlfortolke brugerens mål ved at forenkle det for meget, 2) at starte annonceforløbet for tidligt, før brugerens reelle behov er klart, 3) at vise annoncer, der står i vejen for brugerrejsen i stedet for at understøtte den, og 4) at køre annonceforløbet ineffektivt forfra, hver gang anmodningen ændrer sig, hvilket skaber støj og unødige omkostninger. I stedet for at bygge på enkelthændelser opretholder annoncesystemet (som består af søgning, rangering og levering) en session med hukommelse. Det betyder, at annoncesessionen kører under hele den udveksling, der er godkendt til annoncering, og husker og opdaterer oplysninger, efterhånden som de udvikler sig. ChatGPT sender anmodningens oprindelige kontekst til annonceserveren. Annoncesystemet følger og tilpasser sig samtalens udvikling i stedet for at basere sig på én forenklet forespørgsel.

Annonceudvælgelsen kører parallelt med ChatGPT’s normale svargenerering for at sikre, at annonceforløbet ikke påvirker ChatGPT’s svar. Annoncer filtreres og udvælges gennem et separat system, der behandler samtalen ud fra sine egne krav til godkendelse, kvalitet og levering. Denne vigtige arkitektoniske adskillelse – forskellige tjenester med separate modeller og separat kode – lader ChatGPT’s kerneservere stå for at generere det organiske svar. Samtidig vurderer annoncesystemet uafhængigt, om der er en passende mulighed for annoncering, og forbereder i så fald en sponsoreret placering gennem en separat visningsproces.

Ud over at beskytte brugeroplevelsen har denne adskillelse nogle praktiske konsekvenser. ChatGPT er ikke afhængig af annoncesystemet – tjenesterne er på ingen måde sammenvævede og deler ikke model til indholdsgenerering. Hvis annoncevisningssystemet er utilgængeligt eller langsomt, fortsætter genereringen af ChatGPT’s organiske svar derfor upåvirket. Det betyder, at annoncesystemet ikke kan få ChatGPT til at gå ned eller forsinke produktet. En anden fordel ved adskillelsen er, at den fastholder meget høje krav til annoncernes værdi. At returnere uden en annonce er et helt almindeligt og vellykket resultat. Systemet leverer kun en annonce, hvis den tydeligt gavner både brugere og annoncører.

Den anden centrale arkitekturkomponent i vores annonceteknologi er en LLM, der har gennemgået efteruddannelse. Den fortolker samtaler og styrer hele annonceforløbet i en agentbaseret løkke med værktøjskald til annoncesystemets kernefunktioner, fra søgning og rangering til auktion og til sidst levering. Vi kalder denne LLM for orkestratoren.

Første del af et annonceforløb er at forstå brugerens hensigt for at sætte søgningen i gang. Her indsamles hurtigt og bevidst bredt et udvalg af mulige annoncer, som senere filtreres. Når samtalen modtages løbende, får søgningen et rigere, men også mere tvetydigt grundlag, fordi annoncesystemet skal skelne mellem den aktuelle hensigt og forældet kontekst. Orkestratoren skal fortolke henvisninger til tidligere beskeder, genkende, når en bruger taler hypotetisk, og undgå at behandle enhver omtale af et produkt eller en tjeneste som et ønske om at købe noget.

Annonceorkestratoren bruger den tilgængelige samtale og brugerkontekst til at finde gode annoncer gennem gentagne forsøg. Den vælger løbende, hvornår hvilke værktøjer skal kaldes, med det overordnede mål at finde den mest passende annonce til samtalen og konteksten – en annonce, der afvejer høj værdi for brugeren mod høj værdi for annoncøren. Hvis brugeren vælger at få personligt tilpassede annoncer, tager orkestratoren også højde for tilgængelige, ikkefølsomme oplysninger om brugerens tidligere samtaler for at finde de bedst egnede annoncer.

Efterhånden som samtalen skrider frem, og annonceorkestratoren får mere opdaterede oplysninger, kan den foretage en ny række værktøjskald med den opdaterede kontekst for at finde bedre annoncer og sende dem til klienten. Klienten kan derefter bruge de nye annoncer, hvis de når frem i tide.

Orkestratoren er designet til at afveje værdi for brugeren mod værdi for annoncøren og altid sætte brugerne først.

Annoncesystemet består af individuelle værktøjer, som orkestratoren kalder gentagne gange for at finde de bedste annoncer til en samtale. Overordnet omdanner orkestratoren samtaler til korte tekstresuméer, som derefter omdannes til semantiske indlejringer (lagrede betydninger, som et annoncesystem lettere kan søge igennem). Den bruger disse indlejringer til at hente annoncekandidater, filtrerer kandidaterne efter, om de opfylder kravene til visning (ud fra budget, brugerindstillinger og andre indledende kontroller), vurderer deres kvalitet og relevans og foretager en endelig rangering for at finde værdifulde placeringsmuligheder efter et chatsvar. Hver annonce skal derfor opfylde høje krav til både visningsegnethed og relevans for at kunne blive placeret.

Orkestratorens LLM udarbejder først en eller flere forespørgsler, der repræsenterer den relevante kommercielle hensigt. Det kan omfatte en omskrivning af samtalekonteksten for at udvide de kommercielle muligheder ud over direkte søgeforespørgsler og derefter skabe semantiske repræsentationer. Her sammenfatter orkestratoren en samtale med flere udvekslinger til et resumé, som søgesystemet bruger til målrettet at hente annoncer fra vores database.

Annonceplaceringer bliver bedre for både brugere og annoncører, hvis annoncerne kun vises, når der er en dyb forståelse af brugerens hensigt. Flere forespørgsler kan bevare forskellige aspekter af hensigten. En samtale om at planlægge en rejse kan for eksempel indeholde særskilte behov for transport, overnatning eller aktiviteter. Søgesystemet kan bevare disse forskelle i stedet for at komprimere hele samtalen til én enkelt tekststreng.

Lad os som eksempel se på et muligt samtaleforløb om vandresko:

1. Hvad skal jeg nå at se på en todagestur til Yosemite?

2. Bliver det koldt i næste uge?

3. Nye produktserier fra [insert brand]?

Selvom brugeren ikke har knyttet spørgsmålet om skomærket til turen til Yosemite, kan denne samtale være repræsenteret i vores annoncesystem med to forespørgsler, såsom [shoes appropriate for hiking trip] og [new [brand] product lines good for travel]. Dette kan blot være første forsøg. Orkestratoren er designet til løbende at justere disse repræsentationer, indtil den finder annoncer i vores annoncebeholdning, som er særligt værdifulde for brugeren.

Søgeprocessen skaber en bevidst bred pulje af mulige annoncer. Kandidaterne kan komme fra forskellige søgestrategier og kan senere konkurrere under de samme vilkår for visning. Vi opbygger flere indekser, der er optimeret til forskellige system- og produktkrav. For eksempel er indekset til produktfeedannoncer designet til at tage højde for positive eller negative produktanmeldelser, når det henter de bedst mulige annoncer. Det er ikke relevant for andre annoncer, som måske ikke har tilknyttede anmeldelser. Hvert indeks er optimeret til en variant af tilnærmet nærmeste-nabo-søgning (ANN) med indlejringer, der repræsenterer brugerens hensigt. Denne ANN-søgning er en tilnærmelsesalgoritme til søgning i store semantiske indekser. Det betyder, at annoncer hentes meget hurtigt ved at tilnærme sig en god løsning frem for at lede efter »den rigtige« løsning, samtidig med at de fleste relevante kandidater bevares.

Formålet med filtreringen er at udelukke alle annoncekandidater, der ikke opfylder kravene til placering med hensyn til relevans, bud og budget. Afhængigt af kandidaten og konfigurationen kan filtreringen kontrollere følgende: tilgængelighed af annoncemateriale og kampagner (om kampagnen eller annoncematerialet er aktivt), kampagnemålretning (f.eks. hvilke sprog- og regionsindstillinger en kampagne må køre under), politikbegrænsninger (krav til, hvad der må annonceres for), tilgængeligt budget (om kampagnen stadig har budget tilbage), forbrugstakt (om en kampagne bør bruge budget nu eller på et andet tidspunkt af dagen), placeringsegnethed (hvilke typer samtaler annoncen må vises i) og fjernelse af dubletter på annoncør- og kampagneniveau (valg af et passende antal annoncer pr. annoncør for at sikre fair deltagelse på tværs af virksomheder).

Kandidater, der består godkendelseskontrollerne, går videre til en pointvurdering, hvor orkestratoren foretager værktøjskald til forskellige vurderingssystemer. De vurderer forhold af betydning for visningen såsom semantisk relevans (er annoncen relevant for brugerens mål?), forventet engagement (vil annoncen sandsynligvis blive set, klikket på og føre til annoncørens ønskede resultat?) og historiske resultater (har annoncen hidtil klaret sig godt, når den er blevet vist til brugere?). Orkestratoren filtrerer også annoncer for at sikre relevans og sikkerhed inden auktionen. Disse systemer indsnævrer feltet til en mindre pulje af kandidater, der er klar til auktion, men de afgør stadig ikke, hvilken annonce der i sidste ende leveres.

Orkestratoren vurderer de forberedte kandidater i samtalens kontekst og vælger, hvilke annoncekandidater der er egnede nok til at deltage i den endelige auktion. Orkestratoren beslutter ikke direkte, hvilken annonce der skal vises, og den fastsætter heller ikke en pris. Den nominerer kandidater, der passer til konteksten, så auktionsværktøjet kan vurdere dem.

Auktionen anvender de endelige mekanismer til annoncevisning, herunder adgang til auktionen (opfyldelse af et minimumskrav til relevans og værdi), styring af forbrugstakten (mere jævn fordeling af annoncebudgettet), beregning af bud og auktionsparametre, kvalitetsjusteret rangering, prissætning og endelig udvælgelse.

Efter auktionen kan en annonce undlade at blive leveret af to årsager, der begge er særlige for ChatGPT som samtalemedie.

1. Annoncen kan virke upassende i chatten: Selvom selve samtalen er blevet vurderet som sikker til annonceplacering af integritetsmodeller (de modeller, der afgør, hvornår det er passende at vise en annonce), og annoncen er blevet vurderet til at overholde politikkerne, kan den indimellem virke upassende i bestemte samtalers kontekst. Orkestratoren forhindrer, at disse annoncer bliver vist.

2. Annonceanmodningen når måske ikke frem i tide: Hvis ChatGPT‑modellen er klar til at svare, men annoncen endnu ikke er klar til placering, får annonceanmodningen timeout, og annoncen bliver ikke leveret. Et af annoncesystemets mål er derfor at køre så hurtigt som muligt. ChatGPT‑modellens svartid varierer, og vi forsinker ikke chatsvar for at vente på, at annoncer indlæses.

Hvis alle ovenstående kontroller er bestået, sender vi annoncen til frontend, så den kan gengives. Vi betragter dette som levering af en annonce fra serveren, men det er stadig muligt, at vi ikke viser annoncen til brugeren – og sådan er systemet bevidst designet.

I et samtalebaseret produkt som ChatGPT er levering af annoncemateriale fra serveren ikke en garanti for, at annoncen bliver vist. Den skal også nå frem i tide til at indgå i den aktuelle udveksling. Annoncematerialet omfatter titel, beskrivelse, destinationslink og en eventuel handlingsopfordring. Annoncesystemet returnerer desuden en modelgenereret indledning: en kort, neutral introduktion, der forklarer, hvordan annoncen relaterer sig til samtalen. Ved at holde indledningen adskilt fra annoncematerialet bevarer vi annoncørens budskab, samtidig med at ChatGPT’s stemme forbliver neutral.

ChatGPT’s frontend modtager indledningen og annoncematerialet som én samlet pakke. Hvis pakken når frem, før ChatGPT’s svar er færdiggenereret, viser frontend annoncen under svaret, tydeligt markeret som sponsoreret. Hvis den kommer for sent, vises annoncen ikke i den udveksling. Det er forskellen mellem levering af en annonce fra serveren og en annoncevisning til brugeren.

Vores annonceteknologi bruger traditionel logning og datapipelines, hvilket har tre væsentlige fordele: Annoncører kan lettere integrere deres eksisterende systemer med vores teknologi, de kan forbedre deres strategier med rapporteringsdata, og vores team kan finde dele af systemet, der kan forbedres. Ud over disse rapporterings- og optimeringsværktøjer bruger vi en model af høj kvalitet til at evaluere vores levering og træne andre annoncemodeller. Det skaber en effektiv, selvforbedrende proces.

Detaljerede opgørelser over hændelsesforløbet hjælper os med at forstå og forbedre hver del af annoncesystemet for sig. Logbehandlingssystemet registrerer også detaljerede udfald såsom:

• Udvekslingen opfyldte ikke kravene til annoncering.

• En annoncesession blev startet, men der blev ikke anmodet om en søgning.

• Søgningen returnerede ingen kandidater.

• Kandidater blev hentet, men kunne ikke beriges med data eller godkendes til visning.

• En annonce blev leveret, og der blev senere interageret med den.

Disse detaljerede opgørelser hjælper os med at forbedre hver del af annoncevisningssystemet for sig. At blive bedre til at identificere annoncemuligheder kræver et andet datagrundlag end at forbedre søgningen, kandidaternes kvalitet, auktionsdeltagelsen eller leveringens pålidelighed.

Idéen med modelbaseret evaluering er, at vores stærkeste modeller med de bedste evner til ræsonnering observerer og vurderer systemets resultater. Derefter forbedrer de den LLM, der har gennemgået efteruddannelse, ved at træne den til at præstere bedre. Vi kan for eksempel bruge mindre, mere effektive modeller eller modeller med mindre omfattende ræsonnering til orkestrering eller søgning, hvis vores mest kraftfulde model indsamler feedback og træner disse små hjælpere til at løse opgaven bedst muligt.

Vi indsamler og handler på menneskelig feedback (brugernes klik og skjulning af annoncer) samt brugerundersøgelser og direkte feedback fra annoncører gennem vores Ads Manager. Vores team står også til rådighed for feedback under udviklingen, og vi lytter direkte til, hvad både ChatGPT‑brugere og annoncører ønsker. Denne feedback påvirker vores retning endnu mere end modellens observationsbaserede feedback og er en del af grunden til, at vi hurtigt har kunnet arbejde os frem til de rigtige produktbeslutninger. Modellen kan måske forstå brugerens hensigt og tænke kritisk for at levere noget værdifuldt, men mennesker afgør, hvad der er god smag.

For et år siden havde vi intet annoncesystem og kun nogle få personer, der arbejdede med problemområdet. Nu har vi et robust annoncesystem, der understøtter en omsætning på over 1 milliard dollar på årsbasis ud fra det aktuelle niveau, med en LLM-baseret orkestrator, der styrer annonceforløbet. Codex gav os afgørende ekstra kapacitet, så vi kunne opbygge systemet fra bunden og nå denne store milepæl for brugen med hidtil uset hastighed. Fra starten indrettede vi teamet og udviklingsarbejdsgangene til at bruge Codex til hurtigt at bygge og skalere systemet. Vi byggede sikkerhedsmekanismer, så Codex kunne sætte kode i produktion sikkert og pålideligt. Sideløbende opsatte vi plugins til datainfrastrukturen for Codex for markant at forkorte vejen fra indsamling af indsigt til implementering af forbedringer i systemet, herunder nye produktfunktioner, kvalitetsforbedringer og bedre systemydelse.

Kombinationen af systemets grænser (forankret i vores annonceringsprincipper⁠) og vores LLM-baserede orkestrator gør det muligt at gøre annoncering nyttig uden at behandle enhver samtale som en annonceanmodning. Fremover vil vi fortsat eksperimentere med mere dynamiske annonceformater for at øge værdien for både brugere og annoncører, for eksempel ved at give brugerne mulighed for at tale direkte med virksomheder gennem annoncer. Teknologistakkens selvforbedrende arkitektur, der er bygget på OpenAI-modeller med løbende feedbacksløjfer, vil gøre os i stand til hurtigere at forbedre relevans og personlig tilpasning over tid.