JioStars sjefarkitekt om AI-søk for 500 millioner brukere

I serien Executive Function deler ledere sine perspektiver på hvordan de driver omstilling med AI.

JioStar driver plattformer for underholdning og direktesendt sport som brukes av over 500 millioner forbrukere, og har håndtert opptil 72,5 millioner samtidige seere under direktesendinger av sport. I den skalaen må AI være rask, pålitelig og klar for produksjon.

Ved hjelp av OpenAI API bygget JioStar en samtalebasert assistent inn i JioHotstar for å finne videoer og cricketstatistikk. Seerne kan snakke naturlig for å finne filmer og serier, historiske høydepunkter, øyeblikk fra pågående kamper eller cricketstatistikk. Resultatene vises i en visuell, samtalebasert opplevelse.

På OpenAIs Executive Summit i Singapore snakket Sidharth Sharma, OpenAIs go-to-market-ansvarlige for ASEAN, med Vijay Seshadri, sjefarkitekt i JioStar. Temaet var hvordan de bygget løsningen for mer enn 15 språk på rundt åtte uker, og hva ledere kan lære når de skal ta AI fra demo til produksjon.

Måten vi finner innhold på, har utviklet seg svært lite de siste 25 årene. Anbefalinger var den siste store endringen. Mye av det som har kommet siden, har vært videreutvikling av den samme ideen.

Men hva man vil se på, er et svært personlig valg. Noen kan si: «Jeg er lei meg. Vis meg noe som kan muntre meg opp.» Selv en så enkel forespørsel rommer mange nyanser. Lei seg på hvilken måte? Hva pleier å muntre personen opp? Vil personen se komedie, noe trygt og kjent eller noe som får tankene helt over på noe annet?

Et tradisjonelt anbefalingssystem kan ha vanskelig for å forstå situasjonen der og da. En samtale gir seeren mulighet til å forklare. Vi kaller dette et stemmebasert og visuelt grensesnitt.

Vi begynte å jobbe med konseptet i oktober og november, med en stor cricketturnering i vente i februar. Vi hadde omtrent to måneder og to svært ulike målgrupper: underholdningsseere og cricketfans.

En underholdningsseer kan si «Det er fredag kveld – overrask meg», eller beskrive en film uten å vite tittelen. Sportsseere kan ønske mer spesifikke oppdateringer, som når slagmenn ble slått ut, en rekke seksere eller kampen der en spiller scoret et bestemt antall løp. Cricketeksperter kan ønske statistikk for hver eneste ball.

Dette er svært ulike utfordringer når det gjelder å finne innhold. Vi jobbet med å samle underholdning, sportsøyeblikk og detaljert cricketstatistikk i én opplevelse, på flere språk, på svært kort tid.

Helt fra starten så vi på problemet som en avveining mellom tre hensyn: nøyaktighet, responstid og kostnad. Hver tekniske beslutning måtte balansere alle tre samtidig.

Stemmebruk gjorde dette særlig viktig. Over 60 % av brukerne våre bruker stemmen fremfor tekst: Folk foretrekker å si hva de vil se. Svaret må likevel være relevant, komme raskt og være økonomisk bærekraftig i stor skala.

Jeg ser det som to deler: et evalueringsrammeverk og et valideringslag. Før produksjonssetting bør evalueringsrammeverket gi grunnlag for endringer. I produksjon bør en tilbakemeldingssløyfe omsette kundeatferd og feil til nye evalueringstilfeller.

Denne prosessen kan bli selvforsterkende, men det er svært vanskelig å få den til å fungere godt.

Fageksperter er helt avgjørende. For å evaluere sportsstatistikk samarbeidet vi blant annet med redaktører i sportsmagasiner som forsto hva engasjerte fans kunne spørre om. Du kan ikke starte med bare en prompt; systemet må ha inngående menneskelig fagkunnskap som grunnlag.

Én ting vi lyktes med, var å sette sammen teamet. Vi startet med et lite team av dataforskere og ingeniører med en tydelig problemstilling. OpenAIs ingeniører som jobber direkte med kunder, arbeidet sammen med oss for å konkretisere de få tingene vi absolutt måtte lykkes med.

Det første var å avgrense løsningen. Et stemme- eller tekstgrensesnitt lar brukerne spørre om nesten hva som helst, så vi begynte med å bestemme hva systemet ikke skulle svare på. Sikkerhetsrammene kom først.

For evalueringene startet vi med et grunnleggende datasett og brukte modeller til å utvide det med mer variasjon. Vi laget det man nå kanskje ville kalle et produsent–kontrollør-mønster: Én modell bidro til å avgjøre hvordan et spørsmål skulle besvares, mens en annen fungerte som validator – en LLM som dommer – med en konkurrerende målsetting.

Det reiste et nytt spørsmål: Hvem tester dommeren? Å utforme validatoren var i seg selv en evalueringsutfordring. Codex hjalp teamet med å få fart på oppgaver som å generere evalueringstilfeller og oppdatere systemet, men raskere utvikling fjernet ikke behovet for skjønn og validering.

Jeg ville investert tidligere i å overvåke hvor godt modellene fungerer i produksjon.

Tradisjonelle måltall for infrastruktur, som P99-responstid, er fortsatt viktige, men de er ikke nok. Du må også overvåke hvor godt modellene fungerer i produksjon.

For det første er det et stort gap mellom hva teknologien kan gjøre, og virkeligheten i en bedrift. Hvis bedriften din ikke har holdt tritt med hver eneste lansering av banebrytende modeller, er dere ikke alene.

For det andre må dere holde fast ved å fokusere på resultater fremfor aktivitet. Det er lett å forveksle synlig aktivitet med reell fremgang, særlig når bedrifter legger vekt på å måle innsats. Antall genererte kodelinjer sier for eksempel ikke om dere har skapt reell verdi.

Til slutt undervurderer de fleste bedrifter hvor mye menneskelig kompetanse og selvstendig handlekraft som kreves. Dette kan ikke bare være et generelt opplæringsprogram. Ledere trenger folk som kan bruke disse verktøyene med god dømmekraft. Gi en dyktig ingeniør et verktøy som Codex, og effekten kan mangedobles. Men uten dømmekraften som trengs for å validere produksjonssystemer, mangedobles også risikoen.

Du har en rakett i hendene. Særlig i produksjonssystemer trenger du validering og sikkerhetsrammer, og du må gi nøklene til de rette personene.