JioStar: descoberta com IA para 500 milhões de utilizadores
Uma conversa com Vijay Seshadri, arquiteto-chefe da JioStar.

A nossa série Executive Function apresenta perspetivas de líderes que impulsionam a transformação através da IA.
A JioStar gere plataformas de entretenimento e desporto em direto utilizadas por mais de 500 milhões de consumidores e já chegou a suportar 72,5 milhões de espetadores em simultâneo em transmissões desportivas em direto. A essa escala, a IA tem de ser rápida, fiável e estar pronta para produção.
Com a API da OpenAI, a JioStar integrou no JioHotstar um assistente de conversação para descobrir vídeos e estatísticas de críquete. Os espetadores podem falar naturalmente para encontrar filmes e séries, momentos históricos, lances de jogos em direto ou estatísticas de críquete, recebendo os resultados numa experiência visual e de conversação.
No Executive Summit da OpenAI, em Singapura, Sidharth Sharma, responsável de go-to-market da OpenAI para a ASEAN, conversou com Vijay Seshadri, arquiteto-chefe da JioStar, sobre o desenvolvimento desta experiência em mais de 15 línguas, em cerca de oito semanas, e as lições para os líderes que levam a IA da demonstração à produção.
A descoberta de conteúdos evoluiu muito pouco nos últimos 25 anos. As recomendações foram a última grande mudança. Grande parte do que se seguiu tem sido uma variação da mesma ideia.
Mas escolher o que ver é algo profundamente pessoal. Uma pessoa pode dizer: «Estou triste. Mostra-me algo que me anime.» Até este pedido simples tem muitas nuances. Que tipo de tristeza é? O que costuma animar essa pessoa? Quer uma comédia, algo reconfortante ou algo que a distraia por completo?
Um sistema de recomendação tradicional pode ter dificuldade em compreender esse momento. A conversa dá ao espetador uma forma de o explicar. Chamamos a isto uma interface de voz e imagem.
Começámos a trabalhar no conceito em outubro e novembro, com um grande torneio de críquete previsto para fevereiro. Tínhamos cerca de dois meses e dois públicos muito diferentes: espetadores de entretenimento e fãs de críquete.
Um espetador de entretenimento pode dizer «É sexta-feira à noite, surpreende-me», ou descrever um filme sem saber o título. Os espetadores de desporto podem querer informação mais específica, como eliminações, uma série de batidas de seis pontos ou o jogo em que um jogador marcou um determinado número de corridas. Os conhecedores de críquete podem querer estatísticas de cada lançamento.
São problemas de descoberta muito diferentes. Trabalhámos para reunir entretenimento, momentos desportivos e estatísticas detalhadas de críquete numa única experiência, em várias línguas, num prazo muito curto.
Desde muito cedo, definimos o problema como um equilíbrio entre três fatores: exatidão, latência e custo. Cada decisão de engenharia tinha de equilibrar os três em simultâneo.
A utilização da voz tornava esse equilíbrio especialmente importante. Mais de 60% dos nossos utilizadores usam a voz em vez do texto: as pessoas preferem dizer o que querem ver. Ainda assim, a resposta tem de ser relevante, rápida e economicamente viável em grande escala.
Vejo-o em duas partes: uma estrutura de avaliação e uma camada de validação. Antes da entrada em produção, a estrutura de avaliação deve levar a alterações. Em produção, um ciclo de feedback deve transformar o comportamento dos clientes e as falhas em novos casos de avaliação.
Esse ciclo pode reforçar-se a si próprio, mas é extremamente difícil fazê-lo funcionar bem.
Os especialistas na área são essenciais. Para as avaliações de estatísticas desportivas, trabalhámos com pessoas como editores de revistas de desporto, que compreendiam o que os fãs mais dedicados poderiam perguntar. Não basta começar apenas com um prompt; é preciso alimentar o sistema, desde o início, com conhecimentos humanos aprofundados.
Uma das coisas em que acertámos foi na equipa. Começámos com uma pequena equipa de cientistas de dados e engenheiros, com o problema claramente definido. Os engenheiros da OpenAI destacados para trabalhar connosco ajudaram-nos a identificar com maior precisão os poucos aspetos em que não podíamos falhar.
O primeiro foi o âmbito. Uma interface de voz ou texto permite aos utilizadores perguntar quase tudo, por isso começámos por decidir a que perguntas o sistema não deveria responder. As salvaguardas vieram primeiro.
Para as avaliações, começámos com um conjunto de dados inicial e usámos modelos para o ampliar com maior variedade. Criámos aquilo a que hoje se poderia chamar um padrão de criação e verificação: um modelo ajudava a determinar como responder a uma pergunta, enquanto outro atuava como validador — um LLM como juiz — com um objetivo concorrente.
Isso levantou outra questão: quem testa o juiz? Conceber o validador era, por si só, um problema de avaliação. O Codex ajudou a equipa a acelerar tarefas como gerar casos de avaliação e atualizar o sistema, mas desenvolver mais depressa não eliminou a necessidade de discernimento e validação.
Investiria mais cedo na monitorização da eficácia dos modelos em produção.
As métricas tradicionais de infraestrutura, como a latência P99, continuam a ser importantes, mas não são suficientes. Também é preciso monitorizar a eficácia dos modelos em produção.
Em primeiro lugar, há uma grande distância entre o que a tecnologia permite fazer e a realidade dentro de uma empresa. Se a sua empresa não tem acompanhado todos os anúncios de modelos de fronteira, não é a única.
Em segundo lugar, mantenha o foco nos resultados, não na atividade. É fácil confundir atividade visível com progresso significativo, sobretudo quando as empresas dão destaque a métricas de esforço. O número de linhas de código geradas, por exemplo, não indica se foi criado valor significativo.
Por fim, a maioria das empresas subestima as competências e a autonomia que as pessoas precisam de ter. Não basta um programa genérico de formação. Os líderes precisam de pessoas capazes de aplicar estas ferramentas com discernimento. Dê a um bom engenheiro uma ferramenta como o Codex e o impacto pode multiplicar-se; sem discernimento para validar os sistemas em produção, o risco também se multiplica.
Temos um foguetão nas mãos. Sobretudo nos sistemas em produção, é preciso ter validação e salvaguardas, e entregar o comando às pessoas certas.


