JioStar: scoprire contenuti con l’IA per 500 milioni di utenti

La nostra serie Executive Function raccoglie i punti di vista dei leader che guidano la trasformazione attraverso l’IA.

JioStar gestisce piattaforme di intrattenimento e sport in diretta utilizzate da oltre 500 milioni di persone e ha raggiunto picchi di 72,5 milioni di spettatori simultanei per le dirette sportive. Su questa scala, l’IA deve essere veloce, affidabile e pronta per l’uso in produzione.

Usando l’API OpenAI, JioStar ha integrato in JioHotstar un assistente conversazionale per scoprire video e statistiche sul cricket. Gli spettatori possono parlare in modo naturale per trovare film e programmi, momenti salienti del passato, azioni delle partite in diretta o statistiche sul cricket, ricevendo i risultati attraverso un’esperienza visiva e conversazionale.

All’Executive Summit di OpenAI a Singapore, Sidharth Sharma, responsabile go-to-market di OpenAI per l’ASEAN, ha parlato con Vijay Seshadri, responsabile dell’architettura di JioStar, dello sviluppo di questa esperienza in oltre 15 lingue in circa otto settimane e degli insegnamenti per i leader che portano l’IA dalla demo alla produzione.

Il modo di scoprire i contenuti è cambiato pochissimo negli ultimi 25 anni. L’ultima grande svolta sono stati i consigli personalizzati. Gran parte di ciò che è venuto dopo è stata una rielaborazione della stessa idea.

Ma scegliere cosa guardare è una decisione profondamente personale. Una persona potrebbe dire: “Mi sento triste. Mostrami qualcosa che mi tiri su di morale.” Anche una richiesta così semplice racchiude molte sfumature. Di che tipo di tristezza si tratta? Che cosa tira su di morale quella persona di solito? Vuole una commedia, qualcosa di rassicurante o qualcosa che la distragga completamente?

Un sistema di raccomandazione tradizionale potrebbe faticare a comprendere quello stato d’animo. La conversazione offre allo spettatore un modo per spiegarlo. La chiamiamo interfaccia vocale e visiva.

Abbiamo iniziato a elaborare l’idea tra ottobre e novembre, in vista di un importante torneo di cricket a febbraio. Avevamo circa due mesi e due pubblici molto diversi: gli spettatori dei contenuti di intrattenimento e gli appassionati di cricket.

Chi cerca intrattenimento potrebbe dire: “È venerdì sera, sorprendimi”, oppure descrivere un film senza conoscerne il titolo. Chi segue lo sport potrebbe volere aggiornamenti più specifici, come le eliminazioni dei battitori, una serie di colpi da sei punti o la partita in cui un giocatore ha segnato un certo numero di punti. Gli esperti di cricket potrebbero volere statistiche su ogni lancio.

Sono esigenze di ricerca molto diverse. Abbiamo lavorato per riunire intrattenimento, momenti sportivi e statistiche dettagliate sul cricket in un’unica esperienza, in più lingue e in tempi molto brevi.

Fin dall’inizio abbiamo inquadrato il problema come un compromesso fra tre fattori: accuratezza, latenza e costi. Ogni decisione ingegneristica doveva bilanciare tutti e tre contemporaneamente.

L’interazione vocale rendeva questo equilibrio particolarmente importante. Oltre il 60% dei nostri utenti usa la voce anziché il testo: le persone preferiscono dire ciò che vogliono guardare. La risposta deve comunque essere pertinente, rapida ed economicamente sostenibile su larga scala.

Lo concepisco in due parti: un framework di valutazione e un livello di validazione. Prima della messa in produzione, il framework di valutazione dovrebbe indicare quali modifiche apportare. In produzione, un ciclo di feedback dovrebbe trasformare il comportamento dei clienti e i malfunzionamenti in nuovi casi di valutazione.

Questo circolo virtuoso può alimentarsi da solo, ma farlo funzionare bene è estremamente difficile.

Gli esperti del settore sono essenziali. Per le valutazioni sulle statistiche sportive, abbiamo collaborato con figure come i redattori di riviste sportive, che sapevano quali domande avrebbero potuto fare gli appassionati più esperti. Non si può partire soltanto da un prompt: occorre dare al sistema una base di conoscenze umane approfondite.

Una delle scelte azzeccate è stata la composizione del team. Siamo partiti con un piccolo team di data scientist e ingegneri, concentrato su un problema ben definito. I Forward Deployed Engineer di OpenAI ci hanno affiancato per individuare con ancora più precisione i pochi aspetti su cui non potevamo assolutamente sbagliare.

Il primo era il perimetro delle funzionalità. Un’interfaccia vocale o testuale consente agli utenti di chiedere quasi qualsiasi cosa, quindi abbiamo iniziato decidendo a quali domande il sistema non avrebbe dovuto rispondere. Le misure di sicurezza sono venute prima di tutto.

Per le valutazioni, siamo partiti da un dataset iniziale e abbiamo usato i modelli per ampliarlo introducendo più varianti. Abbiamo creato quello che oggi si potrebbe definire uno schema di generazione e verifica: un modello aiutava a stabilire come rispondere a una domanda, mentre un altro fungeva da validatore, un LLM con il ruolo di giudice, perseguendo un obiettivo contrapposto.

Questo ha sollevato un’altra domanda: chi mette alla prova il giudice? La progettazione del validatore era di per sé un problema di valutazione. Codex ha aiutato il team ad accelerare attività come la generazione di casi di valutazione e l’aggiornamento del sistema, ma uno sviluppo più rapido non ha eliminato la necessità di giudizio critico e validazione.

Investirei prima nel monitoraggio dell’efficacia dei modelli in produzione.

Le metriche infrastrutturali tradizionali, come la latenza P99, restano importanti, ma non bastano. Occorre monitorare anche l’efficacia dei modelli in produzione.

Primo, c’è un grande divario tra ciò che la tecnologia può fare e la realtà all’interno di un’azienda. Se la vostra azienda non è riuscita a tenere il passo con ogni annuncio di un modello di frontiera, non siete i soli.

Secondo, continuate a concentrarvi sui risultati anziché sulle attività. È facile scambiare il fermento visibile per un progresso concreto, soprattutto quando le aziende danno risalto alle metriche che misurano gli input. Le righe di codice generate, per esempio, non dicono se avete creato un valore concreto.

Infine, la maggior parte delle aziende sottovaluta le competenze e l’autonomia decisionale richieste alle persone. Non ci si può limitare a un programma di formazione generico. Ai leader servono persone capaci di usare questi strumenti con criterio. Date a un ingegnere competente uno strumento come Codex e l’impatto può moltiplicarsi; senza il giudizio critico necessario per validare i sistemi in produzione, però, si moltiplica anche il rischio.

Avete un razzo tra le mani. Soprattutto nei sistemi in produzione, servono validazione e misure di sicurezza, e bisogna affidare i comandi alle persone giuste.