JioStars chefarkitekt om AI-søgning for 500 mio. brugere

I vores serie Executive Function deler ledere deres perspektiver på at skabe forandring med AI.

JioStar driver platforme til underholdning og livesport, som bruges af over 500 millioner forbrugere, og har håndteret op til 72,5 millioner samtidige seere til livesport. I den skala skal AI være hurtig, pålidelig og klar til drift.

Med OpenAI API har JioStar indbygget en samtalebaseret assistent i JioHotstar, som hjælper brugerne med at finde videoer og cricketstatistik. Seerne kan tale naturligt for at finde film og serier, historiske højdepunkter, øjeblikke fra igangværende kampe eller cricketstatistik, og resultaterne præsenteres i en visuel, samtalebaseret oplevelse.

På OpenAI’s Executive Summit i Singapore talte Sidharth Sharma, OpenAI’s chef for go-to-market i ASEAN, med Vijay Seshadri, chefarkitekt hos JioStar, om at udvikle oplevelsen til over 15 sprog på cirka otte uger – og om, hvad ledere kan lære af at tage AI fra demo til drift.

Måden, vi finder indhold på, har ændret sig meget lidt de seneste 25 år. Anbefalinger var det seneste store skift. Meget af det, der fulgte, har været variationer over den samme idé.

Men valget af, hvad man vil se, er dybt personligt. En person kan sige: »Jeg er ked af det. Vis mig noget, der gør mig i bedre humør.« Selv den enkle anmodning rummer mange nuancer. Ked af det på hvilken måde? Hvad plejer at gøre personen i bedre humør? Vil personen se komedie, noget trygt og velkendt eller noget, der helt kan aflede tankerne?

Et traditionelt anbefalingssystem kan have svært ved at forstå situationen. Samtalen giver seeren mulighed for at forklare den. Vi kalder det en grænseflade, der kombinerer tale og visning.

Vi begyndte at arbejde med konceptet i oktober og november, og der ventede en stor cricketturnering i februar. Vi havde cirka to måneder og to meget forskellige målgrupper: underholdningsseere og cricketfans.

En underholdningsseer kan sige: »Det er fredag aften – overrask mig«, eller beskrive en film uden at kende titlen. Sportsseere ønsker måske en mere specifik opdatering, for eksempel faldne wickets, en række seksere eller den kamp, hvor en spiller scorede et bestemt antal runs. Cricketeksperter vil måske have statistik om hver eneste bold.

Det stiller meget forskellige krav til at finde indhold. Vi arbejdede på at samle underholdning, sportsøjeblikke og detaljeret cricketstatistik i én oplevelse på tværs af flere sprog på meget kort tid.

Meget tidligt definerede vi problemet som en afvejning mellem nøjagtighed, svartid og omkostninger. Hver teknisk beslutning skulle balancere alle tre hensyn på én gang.

Talefunktionen gjorde det særligt vigtigt. Over 60 % af vores brugere anvender tale frem for tekst: Folk foretrækker at sige, hvad de vil se. Svaret skal stadig være relevant, hurtigt og økonomisk bæredygtigt i stor skala.

Jeg tænker på det som to dele: en evalueringsramme og et valideringslag. Før idriftsættelsen skal evalueringsrammen føre til ændringer. Under driften skal en feedbacksløjfe omsætte kundeadfærd og fejl til nye evalueringstilfælde.

Det kredsløb kan blive selvforstærkende, men det er ekstremt svært at få til at fungere ordentligt.

Fageksperter er afgørende. Til evalueringer af sportsstatistik samarbejdede vi blandt andet med redaktører fra sportsmagasiner, som forstod, hvad dedikerede fans kunne finde på at spørge om. Du kan ikke begynde med en prompt alene; du skal give systemet et fundament af dyb menneskelig ekspertise.

Noget af det, vi ramte rigtigt med, var teamet. Vi begyndte med et lille team af dataforskere og ingeniører med en klar problemformulering. OpenAI’s udstationerede ingeniører arbejdede side om side med os for at indkredse de få ting, vi absolut skulle have styr på.

Det første var afgrænsningen. En tale- eller tekstbaseret grænseflade lader brugerne spørge om næsten hvad som helst, så vi begyndte med at beslutte, hvad systemet ikke skulle svare på. Sikkerhedsrammerne kom først.

Til evalueringerne begyndte vi med et indledende datasæt og brugte modeller til at udvide det med mere variation. Vi skabte det, man i dag kunne kalde en producent-kontrollant-struktur: Én model hjalp med at afgøre, hvordan et spørgsmål skulle besvares, mens en anden fungerede som validator – en LLM som dommer – med et modstridende mål.

Det rejste et nyt spørgsmål: Hvem tester dommeren? At designe validatoren var i sig selv en evalueringsopgave. Codex hjalp teamet med at fremskynde arbejdet med blandt andet at generere evalueringstilfælde og opdatere systemet, men hurtigere udvikling fjernede ikke behovet for dømmekraft og validering.

Jeg ville tidligere investere i at overvåge, hvor godt modellen fungerer i drift.

Traditionelle infrastrukturmål som P99-svartid er stadig vigtige, men de er ikke nok. Man skal også overvåge, hvor godt modellen løser opgaverne i drift.

For det første er der stor afstand mellem teknologiens muligheder og virkeligheden i en virksomhed. Hvis din virksomhed ikke har kunnet følge med, hver gang en ny banebrydende model blev annonceret, er I ikke alene.

For det andet skal man holde fokus på resultater frem for aktivitet. Det er let at forveksle synlig aktivitet med reelle fremskridt, især når virksomheder lægger vægt på at måle indsatsen. Antallet af genererede kodelinjer fortæller for eksempel ikke, om man har skabt reel værdi.

Endelig undervurderer de fleste virksomheder, hvor meget det kræver af menneskelige kompetencer og selvstændig handlekraft. Det kan ikke klares med et generelt opkvalificeringsprogram alene. Ledere har brug for folk, der kan bruge disse værktøjer med dømmekraft. Giv en dygtig ingeniør et værktøj som Codex, og effekten kan mangedobles; uden dømmekraften til at validere systemer i drift mangedobles risikoen også.

Du står med en raket i hænderne. Især i systemer, der er i drift, har du brug for validering og sikkerhedsrammer, og du skal give nøglerne til de rette mennesker.