JioStar lance en 8 semaines un assistant vocal en plus de 15 langues : le pari des evals

Quand on compte plus de 500 millions d'utilisateurs et jusqu'à 72,5 millions de spectateurs regardant du sport en direct en même temps, la phrase « ça marchait dans la démo » ne veut rien dire. L'assistant doit répondre vite, ne pas dire n'importe quoi et ne pas ruiner l'entreprise en coûts d'inférence. Vijay Seshadri, Chief Architect de JioStar, a raconté lors du sommet OpenAI à Singapour comment son équipe a parcouru ce chemin. L'entretien a été publié sur le blog d'OpenAI, mais il contient plus de leçons d'ingénierie que de publicité.

Ce qui a été construit et pourquoi les recommandations classiques ne suffisaient pas

JioHotstar a ajouté un assistant conversationnel reposant sur l'API OpenAI. Le spectateur dit ce qu'il veut regarder et reçoit une réponse sous forme visuelle. Seshadri parle d'une voice-visual interface : le choix d'un contenu est par nature visuel, mais il est plus simple d'expliquer une humeur ou un goût à la voix qu'avec des clics.

Exemple tiré de l'entretien : « Je suis triste, montre-moi quelque chose qui me remonte le moral ». Un système de recommandation fondé sur l'historique de visionnage ne comprendra pas de quelle tristesse il s'agit ni ce qui aide habituellement cette personne. Dans un dialogue, on peut demander des précisions.

Les requêtes sont très variées :

• divertissement : « on est vendredi, surprends-moi » ou la description d'un film dont on ne connaît pas le titre ;
• sport : une série de sixes, la chute de guichets, un match où un joueur a marqué un certain nombre de points ;
• expertes : des statistiques balle par balle.

Tout cela a été réuni dans une seule interface, en plus de 15 langues, en environ huit semaines. L'échéance était un grand tournoi de cricket en février. Plus de 60 % des utilisateurs préfèrent la voix au texte.

Comment ils l'ont construit : limites, evals et « juge du juge »

Dès le départ, le problème a été posé comme un triangle « précision – latence – coût ». Chaque décision d'ingénierie déplaçait les trois sommets à la fois.

L'ordre des travaux est intéressant. L'équipe a d'abord déterminé à quoi l'assistant ne devait pas répondre. Une interface vocale permet de demander n'importe quoi ; les guardrails ont donc été la première étape, et non un chantier « après le lancement ».

Vinrent ensuite les evals. L'équipe est partie d'un petit jeu de questions initial qu'elle a élargi à l'aide de modèles. Mais elle n'a pas commencé par le prompt : elle est partie de l'expertise humaine. Pour les statistiques sportives, des rédacteurs de magazines sportifs, qui savent ce que demanderont les vrais fans, ont été mobilisés.

Pour la qualité des réponses, le schéma maker-checker a été retenu. Un modèle décide comment répondre à la question, un autre vérifie la réponse en tant que juge LLM, avec un objectif opposé. Seshadri pose aussitôt la question suivante : qui vérifie le juge ? Le validateur devient lui-même un objet d'évaluation, et ce travail ne peut pas être sauté.

Codex a accéléré la génération des cas d'eval et la mise à jour du système. Mais, selon Seshadri, un assemblage rapide ne dispense ni du jugement ni de la validation. Une petite équipe de data scientists et d'ingénieurs a travaillé, avec des ingénieurs forward-deployed d'OpenAI à leurs côtés.

Ce qu'il faut en retenir

La leçon principale de Seshadri : « evals, evals et encore des evals ». Selon lui, les débutants les sous-estiment, même lorsqu'ils se croient prêts.

La deuxième leçon concerne la production. Il faut une boucle de retour où le comportement des utilisateurs et les défaillances se transforment en nouveaux cas d'eval. Seshadri reconnaît qu'un tel volant d'inertie est très difficile à mettre en place. Avec le recul, il aurait investi plus tôt dans le suivi de l'efficacité du modèle : la latence P99 est importante, mais elle ne dit pas si la réponse aide l'utilisateur.

La troisième leçon relève du management. Il faut mesurer le résultat, pas l'activité : le nombre de lignes de code générées ne dit rien de la valeur. Pour un ingénieur solide, Codex multiplie le rendement, mais sans compétence de vérification des systèmes de production, le risque est lui aussi multiplié. Seshadri le formule ainsi : vous avez une fusée entre les mains, et il faut confier les clés aux bonnes personnes.

Si vous construisez un assistant pour un catalogue, le support ou la recherche, la check-list est courte :

1. Définissez à quoi le système ne répondra pas.
2. Constituez le jeu d'evals initial avec des experts du domaine.
3. Placez un second LLM pour vérifier les réponses et évaluez séparément ce vérificateur.
4. Suivez en production la qualité des réponses, et pas seulement la latence.

Limites

Il s'agit d'un entretien, pas d'une analyse technique, publié par un fournisseur. On n'y trouve aucun chiffre sur la précision, la latence ou le coût d'une requête, aucune comparaison avec l'ancienne recherche, ni de données sur l'impact sur l'engagement. La façon dont le juge est conçu et ce qui le distingue du générateur ne sont pas non plus détaillés. Ce contenu ne peut donc pas servir de preuve d'efficacité. En revanche, comme liste de priorités d'ingénierie pour lancer un assistant dans un produit grand public, il est tout à fait utile.