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

Nossa série Executive Function traz perspectivas de líderes que impulsionam a transformação por meio da IA.
A JioStar opera plataformas de entretenimento e esportes ao vivo usadas por mais de 500 milhões de consumidores e já atendeu até 72,5 milhões de espectadores simultâneos em transmissões esportivas ao vivo. Nessa escala, a IA precisa ser rápida, confiável e estar pronta para produção.
Usando a API da OpenAI, a JioStar criou e integrou ao JioHotstar um assistente conversacional para encontrar vídeos e estatísticas de críquete. Os espectadores podem falar de forma natural para encontrar filmes e séries, lances históricos, momentos de partidas ao vivo ou estatísticas de críquete, recebendo os resultados em uma experiência visual e conversacional.
No Executive Summit da OpenAI em Singapura, Sidharth Sharma, líder de go-to-market da OpenAI para a ASEAN, conversou com Vijay Seshadri, arquiteto-chefe da JioStar, sobre a criação dessa experiência em mais de 15 idiomas em cerca de oito semanas e as lições para líderes que estão levando a IA da demonstração à produção.
A descoberta de conteúdo evoluiu muito pouco nos últimos 25 anos. As recomendações foram a última grande mudança. Muito do que veio depois foram variações da mesma ideia.
Mas escolher o que assistir é algo profundamente pessoal. Uma pessoa pode dizer: "Estou triste. Me mostre algo para me animar." Até esse pedido simples tem muitas nuances. Que tipo de tristeza é essa? O que costuma animar essa pessoa? Ela quer uma comédia, algo reconfortante ou alguma coisa que a distraia por completo?
Um sistema tradicional de recomendação pode ter dificuldade para entender esse momento. A conversa dá ao espectador uma forma de explicar o que está sentindo. Chamamos isso de interface de voz e imagem.
Começamos a desenvolver o 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: espectadores de entretenimento e fãs de críquete.
Alguém em busca de entretenimento pode dizer: "É sexta à noite, me surpreenda", ou descrever um filme sem saber o título. Já quem assiste a esportes pode querer informações mais específicas, como eliminações de rebatedores, uma sequência de rebatidas de seis pontos ou a partida em que um jogador marcou determinado número de corridas. Quem entende de críquete pode querer estatísticas de cada bola.
São desafios de descoberta muito diferentes. Trabalhamos para reunir entretenimento, momentos esportivos e estatísticas detalhadas de críquete em uma única experiência, em vários idiomas e em um prazo muito curto.
Desde o início, definimos o problema como uma busca de equilíbrio entre precisão, latência e custo. Cada decisão de engenharia precisava equilibrar os três ao mesmo tempo.
O uso de voz tornava isso especialmente importante. Mais de 60% dos nossos usuários usam voz em vez de texto: as pessoas preferem falar o que querem assistir. Ainda assim, a resposta precisa ser relevante, rápida e economicamente viável em escala.
Penso nisso 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 mudanças. 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 se fortalecer por conta própria, mas fazê-lo funcionar bem é extremamente difícil.
Especialistas no assunto são essenciais. Nas avaliações de estatísticas esportivas, trabalhamos com pessoas como editores de revistas de esportes, que entendiam o que fãs dedicados poderiam perguntar. Não basta começar com um prompt; é preciso alimentar o sistema com conhecimento humano aprofundado desde o início.
Um dos nossos acertos foi a equipe. Começamos com uma pequena equipe de cientistas de dados e engenheiros, reunida em torno de um problema claramente definido. Os engenheiros da OpenAI alocados no projeto trabalharam conosco para identificar com mais precisão os poucos pontos em que não podíamos errar.
O primeiro foi o escopo. Uma interface de voz ou texto permite que os usuários perguntem quase qualquer coisa, então começamos decidindo o que o sistema não deveria responder. Os mecanismos de proteção vieram primeiro.
Para as avaliações, começamos com um conjunto inicial de dados e usamos modelos para ampliá-lo com mais variações. Criamos o que hoje se poderia chamar de 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 contraposto.
Isso levantou outra questão: quem testa o juiz? Projetar o validador já era, por si só, um problema de avaliação. O Codex ajudou a equipe a acelerar tarefas como gerar casos de avaliação e atualizar o sistema, mas desenvolver mais rápido não eliminou a necessidade de discernimento e validação.
Eu investiria mais cedo no monitoramento da eficácia dos modelos em produção.
Métricas tradicionais de infraestrutura, como a latência P99, continuam importantes, mas não são suficientes. Também é preciso monitorar a eficácia dos modelos em produção.
Primeiro, há uma grande distância entre o que a tecnologia pode fazer e a realidade dentro de uma empresa. Se a sua empresa não conseguiu acompanhar cada anúncio de modelo de fronteira, ela não é a única.
Segundo, mantenha o foco nos resultados, não nas atividades. É fácil confundir movimentação visível com progresso real, principalmente quando as empresas dão ênfase a métricas de esforço. A quantidade de linhas de código geradas, por exemplo, não revela se você criou valor de fato.
Por fim, a maioria das empresas subestima as competências humanas e a autonomia necessárias. Isso não pode se resumir a um programa genérico de capacitação. Os líderes precisam de pessoas capazes de aplicar essas ferramentas com discernimento. Dê uma ferramenta como o Codex a um bom engenheiro e o impacto pode se multiplicar; sem o discernimento necessário para validar sistemas em produção, o risco também se multiplica.
Você tem um foguete nas mãos. Especialmente em sistemas em produção, é preciso ter validação e mecanismos de proteção, além de entregar as chaves às pessoas certas.


