JioStars chefsarkitekt om AI-sökning för 500 miljoner användare

I vår serie Executive Function delar ledare som driver förändring med AI med sig av sina perspektiv.

JioStar driver plattformar för underhållning och direktsänd sport som används av över 500 miljoner konsumenter och har hanterat så många som 72,5 miljoner samtidiga tittare på direktsänd sport. I den skalan måste AI vara snabb, tillförlitlig och redo för produktion.

Med OpenAI:s API byggde JioStar in en samtalsbaserad assistent i JioHotstar som hjälper användarna att hitta videor och cricketstatistik. Tittarna kan prata naturligt för att hitta filmer och serier, historiska höjdpunkter, ögonblick från pågående matcher eller cricketstatistik. Resultaten visas visuellt som en del av samtalet.

På OpenAI:s Executive Summit i Singapore samtalade Sidharth Sharma, OpenAI:s chef för marknadsstrategi i ASEAN, med Vijay Seshadri, chefsarkitekt på JioStar. De pratade om att bygga upplevelsen för över 15 språk på ungefär åtta veckor och om lärdomarna för ledare som tar AI från demo till produktion.

Sättet att hitta innehåll har utvecklats väldigt lite de senaste 25 åren. Rekommendationer var den senaste stora förändringen. Mycket av det som kommit sedan dess har varit varianter av samma idé.

Men valet av vad man vill titta på är djupt personligt. Någon kanske säger: ”Jag känner mig ledsen. Visa mig något som gör mig gladare.” Även en så enkel förfrågan rymmer många nyanser. Ledsen på vilket sätt? Vad brukar göra den personen gladare? Vill personen se komedi, något tryggt och välbekant eller något som helt skingrar tankarna?

Ett traditionellt rekommendationssystem kan ha svårt att förstå situationen. Genom ett samtal får tittaren möjlighet att förklara den. Vi kallar det ett röstbaserat visuellt gränssnitt.

Vi började arbeta igenom konceptet i oktober och november, inför en stor cricketturnering i februari. Vi hade ungefär två månader på oss och två väldigt olika målgrupper: underhållningstittare och cricketfans.

En underhållningstittare kanske säger: ”Det är fredagskväll – överraska mig”, eller beskriver en film utan att veta vad den heter. Sporttittare kanske vill ha mer specifik information, som fallna wickets, en serie sexor eller matchen där en spelare gjorde ett visst antal runs. Cricketexperter kanske vill ha statistik om varje boll.

Det är väldigt olika utmaningar när det gäller att hitta innehåll. Vi arbetade med att samla underhållning, sportögonblick och detaljerad cricketstatistik i en och samma upplevelse, på flera språk och på väldigt kort tid.

Redan tidigt såg vi problemet som en avvägning mellan tre faktorer: träffsäkerhet, svarstid och kostnad. Varje tekniskt beslut behövde balansera alla tre samtidigt.

Röstfunktionen gjorde det särskilt viktigt. Över 60 % av våra användare använder rösten i stället för text: de föredrar att säga vad de vill titta på. Svaret måste ändå vara relevant, snabbt och ekonomiskt hållbart i stor skala.

Jag tänker på det som två delar: ett ramverk för utvärdering och ett valideringslager. Före produktionssättningen bör utvärderingsramverket ligga till grund för förändringar. I produktion bör en återkopplingsloop omvandla kundbeteenden och fel till nya testfall för utvärdering.

Den processen kan bli självförstärkande, men det är oerhört svårt att få den att fungera rätt.

Domänexperter är avgörande. För utvärderingar av sportstatistik samarbetade vi med bland andra redaktörer på sporttidningar som förstod vad inbitna fans skulle kunna fråga om. Det räcker inte att börja med en prompt; systemet behöver från början bygga på djup mänsklig expertis.

En sak vi lyckades med var teamet. Vi började med ett litet team av dataforskare och ingenjörer som samlades kring en tydlig problemformulering. OpenAI:s kundnära ingenjörer arbetade sida vid sida med oss för att ytterligare ringa in de få saker som vi absolut måste få rätt.

Det första var avgränsningen. Ett röst- eller textgränssnitt låter användarna fråga nästan vad som helst, så vi började med att bestämma vad systemet inte skulle svara på. Skyddsräckena kom först.

För utvärderingarna började vi med en grundläggande datamängd och använde modeller för att utöka den med fler variationer. Vi skapade vad man i dag skulle kunna kalla ett skapar–granskar-mönster: en modell hjälpte till att avgöra hur en fråga skulle besvaras, medan en annan validerade svaret – en LLM som domare – med ett motstående mål.

Det väckte ytterligare en fråga: vem testar domaren? Att utforma valideringsmodellen var i sig ett utvärderingsproblem. Codex hjälpte teamet att påskynda arbete som att generera testfall för utvärdering och uppdatera systemet, men snabbare utveckling tog inte bort behovet av omdöme och validering.

Jag skulle ha satsat tidigare på att övervaka hur väl modellerna fungerar i produktion.

Traditionella infrastrukturmått som P99-latens är fortfarande viktiga, men de räcker inte. Man behöver också övervaka hur väl modellerna fungerar i produktion.

För det första finns det ett stort gap mellan vad tekniken kan göra och verkligheten i ett företag. Om ditt företag inte har hållit jämna steg med varje lansering av en banbrytande modell är ni inte ensamma.

För det andra: fortsätt att fokusera på resultat snarare än aktivitet. Det är lätt att förväxla synlig aktivitet med verkliga framsteg, särskilt när företag betonar mått på insatser. Antalet genererade kodrader säger till exempel inte om ni har skapat verkligt värde.

Slutligen underskattar de flesta företag den mänskliga kompetens och handlingsförmåga som krävs. Det här kan inte bara vara ett generellt program för kompetensutveckling. Ledare behöver människor som kan använda de här verktygen med gott omdöme. Ge en skicklig ingenjör ett verktyg som Codex så kan effekten mångdubblas. Men utan det omdöme som krävs för att validera produktionssystem mångdubblas också risken.

Du har en raket i händerna. Särskilt i produktionssystem behöver du validering och skyddsräcken, och du måste lämna över nycklarna till rätt personer.