JioStar: content vinden met AI voor 500 miljoen gebruikers
Een gesprek met Vijay Seshadri, hoofdarchitect bij JioStar.

In onze serie Executive Function delen leiders hun visie op de transformatie die zij met AI aansturen.
JioStar beheert platforms voor entertainment en livesport die door meer dan 500 miljoen consumenten worden gebruikt. Bij livesport bedienden die platforms al tot 72,5 miljoen gelijktijdige kijkers. Op die schaal moet AI snel, betrouwbaar en klaar voor productie zijn.
Met de OpenAI API bouwde JioStar een assistent in JioHotstar waarmee gebruikers via een gesprek video's en cricketstatistieken kunnen vinden. Kijkers kunnen in hun eigen woorden vragen naar films en series, hoogtepunten uit het verleden, momenten uit livewedstrijden of cricketstatistieken. De resultaten krijgen ze visueel te zien als onderdeel van het gesprek.
Tijdens de Executive Summit van OpenAI in Singapore sprak Sidharth Sharma, hoofd go-to-market voor ASEAN bij OpenAI, met Vijay Seshadri, hoofdarchitect bij JioStar. Ze bespraken hoe het team deze functionaliteit in ongeveer acht weken voor meer dan 15 talen bouwde en welke lessen dat opleverde voor leiders die AI van demo naar productie brengen.
De manier waarop mensen content ontdekken is de afgelopen 25 jaar nauwelijks veranderd. Aanbevelingen waren de laatste grote verandering. Veel van wat daarna kwam, was een variatie op hetzelfde idee.
Maar kiezen wat je wilt kijken is heel persoonlijk. Iemand kan zeggen: "Ik voel me somber. Laat me iets zien dat me opvrolijkt." Zelfs in zo'n eenvoudig verzoek zit veel nuance. Om wat voor somberheid gaat het? Waar wordt die persoon meestal vrolijk van? Wil diegene een komedie, iets vertrouwds of iets dat alle aandacht opeist?
Een traditioneel aanbevelingssysteem kan moeite hebben om zo'n moment te begrijpen. In een gesprek kan de kijker uitleggen wat die zoekt. We noemen dit een interface die spraak en beeld combineert.
We begonnen het concept in oktober en november uit te werken, met een groot crickettoernooi in februari in het vooruitzicht. We hadden ongeveer twee maanden en twee heel verschillende doelgroepen: entertainmentkijkers en cricketfans.
Een entertainmentkijker zegt bijvoorbeeld: "Het is vrijdagavond, verras me", of beschrijft een film zonder de titel te kennen. Sportkijkers zoeken misschien een specifiekere update, zoals gevallen wickets, een reeks zessen of de wedstrijd waarin een speler een bepaald aantal runs scoorde. Cricketkenners willen misschien statistieken over elke bal.
Dat zijn heel verschillende zoekvraagstukken. We werkten eraan om entertainment, sportmomenten en gedetailleerde cricketstatistieken in heel korte tijd samen te brengen in één gebruikerservaring, in meerdere talen.
Al vroeg benaderden we het vraagstuk als een afweging tussen nauwkeurigheid, responstijd en kosten. Bij elke technische beslissing moesten we die drie tegelijk in evenwicht houden.
Door de spraakfunctie was dat extra belangrijk. Meer dan 60% van onze gebruikers gebruikt spraak in plaats van tekst: mensen zeggen liever hardop wat ze willen kijken. Ook op grote schaal moet het antwoord relevant en snel zijn en moeten de kosten beheersbaar blijven.
Ik zie het als twee onderdelen: een evaluatiekader en een validatielaag. Vóór de ingebruikname moet het evaluatiekader aanleiding geven tot aanpassingen. In productie moet een feedbacklus het gedrag van klanten en fouten omzetten in nieuwe evaluatiegevallen.
Die cyclus kan zichzelf gaan versterken, maar het is buitengewoon moeilijk om dat goed voor elkaar te krijgen.
Domeinexperts zijn onmisbaar. Voor de evaluaties van sportstatistieken werkten we onder meer samen met redacteuren van sporttijdschriften, die begrepen welke vragen fanatieke fans zouden stellen. Je kunt niet met alleen een prompt beginnen; je moet het systeem vanaf het begin voeden met diepgaande menselijke expertise.
Eén ding dat we goed hadden aangepakt, was de samenstelling van het team. We begonnen met een klein team van datawetenschappers en engineers en een heldere probleemstelling. Engineers van OpenAI die direct bij klanten meewerken, hielpen ons om scherper te bepalen welke paar zaken absoluut goed moesten zijn.
Het eerste was de afbakening. Via een spraak- of tekstinterface kunnen gebruikers vrijwel alles vragen, dus bepaalden we eerst waarop het systeem geen antwoord mocht geven. Veiligheidswaarborgen kwamen op de eerste plaats.
Voor de evaluaties begonnen we met een basisdataset, die we met behulp van modellen uitbreidden met meer variatie. We maakten wat je nu een maker-controleurpatroon zou kunnen noemen: één model hielp bepalen hoe een vraag beantwoord moest worden, terwijl een ander het antwoord valideerde — een LLM als beoordelaar — met een tegengesteld doel.
Dat riep een nieuwe vraag op: wie test de beoordelaar? Het ontwerpen van de validator was op zichzelf al een evaluatievraagstuk. Codex hielp het team om taken zoals het genereren van evaluatiegevallen en het bijwerken van het systeem te versnellen. Maar sneller bouwen maakte oordeelsvermogen en validatie niet minder noodzakelijk.
Ik zou eerder investeren in het monitoren van de effectiviteit van het model in productie.
Traditionele infrastructuurmetingen, zoals P99-responstijd, blijven belangrijk, maar zijn niet voldoende. Je moet ook monitoren hoe effectief het model in productie is.
Ten eerste is er een grote kloof tussen wat de technologie kan en de realiteit binnen een onderneming. Als je bedrijf niet elke aankondiging van een grensverleggend model heeft kunnen bijbenen, ben je niet de enige.
Ten tweede: blijf je richten op resultaten in plaats van op activiteiten. Zichtbare bedrijvigheid wordt makkelijk verward met wezenlijke vooruitgang, vooral wanneer bedrijven de nadruk leggen op het meten van input. Het aantal gegenereerde regels code zegt bijvoorbeeld niets over de vraag of je echt waarde hebt gecreëerd.
Tot slot onderschatten de meeste ondernemingen hoeveel menselijke deskundigheid en zelfstandig handelen hiervoor nodig zijn. Een algemeen opleidingsprogramma alleen volstaat niet. Leiders hebben mensen nodig die deze tools met goed oordeelsvermogen kunnen inzetten. Geef een goede engineer een tool als Codex en de impact kan vele malen groter worden. Maar zonder het oordeelsvermogen om productiesystemen te valideren, nemen de risico's net zo hard toe.
Je hebt een raket in handen. Zeker in productiesystemen heb je validatie en veiligheidswaarborgen nodig, en moet je de juiste mensen aan het stuur zetten.


