JioStar : la découverte par l’IA pour 500 M d’utilisateurs

Notre série Executive Function donne la parole aux dirigeants qui pilotent la transformation par l’IA.

JioStar exploite des plateformes de divertissement et de sport en direct utilisées par plus de 500 millions de consommateurs, et a accueilli jusqu’à 72,5 millions de spectateurs simultanés lors de retransmissions sportives. À cette échelle, l’IA doit être rapide, fiable et prête pour la production.

À l’aide de l’API OpenAI, JioStar a intégré à JioHotstar un assistant conversationnel de recherche de vidéos et de statistiques de cricket. Les spectateurs peuvent s’exprimer naturellement pour trouver des films et des séries, des moments forts historiques, des séquences de matchs en direct ou des statistiques de cricket, avec des résultats présentés dans une expérience visuelle et conversationnelle.

Lors de l’Executive Summit d’OpenAI à Singapour, Sidharth Sharma, responsable de la stratégie de mise sur le marché d’OpenAI pour l’ASEAN, s’est entretenu avec Vijay Seshadri, architecte en chef de JioStar, sur la création de cette expérience dans plus de 15 langues en huit semaines environ, et sur les enseignements à en tirer pour les dirigeants qui font passer l’IA de la démonstration à la production.

La découverte de contenus a très peu évolué au cours des 25 dernières années. Les recommandations ont été le dernier grand tournant. Une grande partie de ce qui a suivi n’a été qu’une déclinaison de cette même idée.

Mais choisir quoi regarder est profondément personnel. Quelqu’un pourrait dire : « Je me sens triste. Montre-moi quelque chose qui me remontera le moral. » Même cette simple demande contient beaucoup de nuances. De quel type de tristesse s’agit-il ? Qu’est-ce qui remonte habituellement le moral à cette personne ? Veut-elle une comédie, un programme réconfortant ou quelque chose qui lui change complètement les idées ?

Un système de recommandation traditionnel peut avoir du mal à comprendre cet état d’esprit. La conversation donne au spectateur un moyen de l’expliquer. Nous appelons cela une interface vocale et visuelle.

Nous avons commencé à travailler sur le concept en octobre et novembre, en vue d’un grand tournoi de cricket prévu en février. Nous avions environ deux mois et deux publics très différents : les amateurs de divertissement et les supporters de cricket.

Un amateur de divertissement pourrait dire : « C’est vendredi soir, surprends-moi », ou décrire un film sans en connaître le titre. Les amateurs de sport peuvent rechercher des informations plus précises, comme les chutes de guichets, une série de six ou le match au cours duquel un joueur a marqué un certain nombre de points. Les experts du cricket peuvent vouloir des statistiques sur chaque balle.

Ce sont des problématiques de découverte très différentes. Nous avons travaillé à réunir divertissement, moments sportifs et statistiques détaillées de cricket dans une seule expérience, en plusieurs langues, dans un délai très court.

Très tôt, nous avons posé le problème comme un arbitrage entre trois critères : précision, latence et coût. Chaque décision d’ingénierie devait équilibrer les trois à la fois.

La voix rendait cet enjeu particulièrement important. Plus de 60 % de nos utilisateurs utilisent la voix plutôt que le texte : les gens préfèrent dire ce qu’ils veulent regarder. La réponse doit néanmoins rester pertinente, rapide et économiquement viable à grande échelle.

Je le conçois en deux parties : un cadre d’évaluation et une couche de validation. Avant la mise en production, le cadre d’évaluation doit conduire à des ajustements. En production, une boucle de rétroaction doit transformer les comportements des clients et les défaillances en nouveaux cas d’évaluation.

Ce cercle vertueux peut s’auto-amplifier, mais il est extrêmement difficile à mettre au point.

Les experts du domaine sont essentiels. Pour les évaluations portant sur les statistiques sportives, nous avons travaillé notamment avec des rédacteurs de magazines sportifs qui comprenaient les questions que les passionnés pouvaient poser. On ne peut pas partir d’un simple prompt ; il faut nourrir le système d’une expertise humaine approfondie.

L’un de nos bons choix a été la composition de l’équipe. Nous avons commencé avec une petite équipe de data scientists et d’ingénieurs, autour d’une problématique clairement définie. Les ingénieurs d’OpenAI déployés sur le terrain ont travaillé à nos côtés pour préciser les quelques points sur lesquels nous devions absolument réussir.

Le premier était le périmètre. Une interface vocale ou textuelle permet aux utilisateurs de demander presque n’importe quoi. Nous avons donc commencé par décider à quoi le système ne devait pas répondre. Les garde-fous ont été la priorité.

Pour les évaluations, nous sommes partis d’un jeu de données initial et avons utilisé des modèles pour l’enrichir de variantes. Nous avons créé ce que l’on pourrait aujourd’hui appeler un schéma producteur-vérificateur : un modèle aidait à déterminer comment répondre à une question, tandis qu’un autre faisait office de validateur — un LLM jouant le rôle de juge — avec un objectif concurrent.

Cela a soulevé une autre question : qui teste le juge ? La conception du validateur était elle-même un problème d’évaluation. Codex a aidé l’équipe à accélérer des tâches comme la génération de cas d’évaluation et la mise à jour du système, mais développer plus vite n’a pas supprimé le besoin de discernement et de validation.

J’investirais plus tôt dans le suivi de l’efficacité des modèles en production.

Les indicateurs d’infrastructure traditionnels, comme la latence P99, restent importants, mais ils ne suffisent pas. Il faut aussi suivre l’efficacité des modèles en production.

D’abord, il existe un grand décalage entre les possibilités de la technologie et la réalité au sein d’une entreprise. Si votre entreprise n’a pas suivi le rythme de chaque annonce de modèle de pointe, vous n’êtes pas seuls.

Ensuite, restez concentrés sur les résultats plutôt que sur l’activité. Il est facile de confondre agitation visible et progrès réel, surtout lorsque les entreprises privilégient les indicateurs de moyens. Le nombre de lignes de code générées, par exemple, ne vous dit pas si vous avez créé une réelle valeur.

Enfin, la plupart des entreprises sous-estiment les compétences humaines et la capacité d’action nécessaires. Cela ne peut pas se limiter à un programme de formation générique. Les dirigeants ont besoin de personnes capables d’utiliser ces outils avec discernement. Donnez à un ingénieur compétent un outil comme Codex et l’impact peut être démultiplié ; sans le discernement nécessaire pour valider les systèmes en production, les risques se multiplient aussi.

Vous avez une fusée entre les mains. Surtout pour les systèmes en production, il faut de la validation et des garde-fous, et il faut confier les clés aux bonnes personnes.