JioStar lançou em 8 semanas um assistente de voz em mais de 15 idiomas: a aposta foi em evals

Quando você tem mais de 500 milhões de usuários e até 72,5 milhões de espectadores assistindo a esportes ao vivo ao mesmo tempo, a frase "na demo funcionava" não significa nada. O assistente precisa responder rápido, não pode inventar respostas e não pode quebrar a empresa com o custo de inferência. Vijay Seshadri, Chief Architect da JioStar, contou no summit da OpenAI em Singapura como sua equipe percorreu esse caminho. A entrevista foi publicada no blog da OpenAI, mas traz mais lições de engenharia do que publicidade.

O que foi construído e por que as recomendações tradicionais não davam conta

O JioHotstar passou a oferecer um assistente conversacional baseado na API da OpenAI. O espectador diz o que quer assistir e recebe a resposta de forma visual. Seshadri chama isso de voice-visual interface: a escolha de conteúdo é visual por natureza, mas explicar um humor ou um gosto por voz é mais fácil do que por cliques.

Um exemplo da entrevista: "Estou triste, mostre algo que me anime". Um sistema de recomendação baseado no histórico de visualização não entende que tipo de tristeza é essa nem o que costuma ajudar aquela pessoa. Numa conversa, é possível pedir esclarecimentos.

Os pedidos, aliás, são bastante variados:

• de entretenimento: "hoje é sexta-feira, me surpreenda" ou a descrição de um filme sem citar o título;
• esportivos: uma sequência de sixes, a queda de wickets, uma partida em que um jogador marcou determinado número de pontos;
• de especialistas: estatísticas bola a bola.

Tudo isso foi reunido em uma única interface, em mais de 15 idiomas e em cerca de oito semanas. O prazo final era um grande torneio de críquete em fevereiro. Mais de 60% dos usuários preferem voz a texto.

Como foi construído: limites, evals e o "juiz do juiz"

Desde o início, o problema foi tratado como um triângulo: precisão, latência e custo. Qualquer decisão de engenharia movia os três vértices ao mesmo tempo.

A ordem do trabalho chama atenção. Primeiro, a equipe definiu a que o assistente não deve responder. Uma interface de voz permite perguntar qualquer coisa, por isso os guardrails vieram como primeiro passo, e não "depois do lançamento".

Em seguida, vieram os evals. A equipe partiu de um pequeno conjunto inicial de perguntas e o ampliou com ajuda de modelos. Mas o ponto de partida não foi o prompt, e sim a experiência humana: para estatísticas esportivas, foram chamados editores de revistas esportivas, que sabem o que os fãs de verdade vão perguntar.

Para a qualidade das respostas, foi usado o esquema maker-checker. Um modelo decide como responder à pergunta; outro verifica a resposta como LLM-juiz, com um objetivo oposto ao do primeiro. Seshadri já emenda a pergunta seguinte: quem verifica o juiz? O validador também vira um problema a ser avaliado, e esse trabalho não pode ser pulado.

O Codex acelerou a geração de casos de eval e a atualização do sistema. Mas, segundo Seshadri, a montagem rápida não elimina a necessidade de julgamento e validação. Trabalhou no projeto uma equipe pequena de cientistas de dados e engenheiros, com engenheiros forward-deployed da OpenAI ao lado.

O que levar para o seu projeto

A principal lição de Seshadri: "evals, evals e mais evals". Segundo ele, quem está começando os subestima, mesmo quando se considera preparado.

A segunda lição diz respeito à produção. É preciso um ciclo de feedback em que o comportamento dos usuários e as falhas se transformem em novos casos de eval. Seshadri reconhece que esse ciclo é muito difícil de colocar para girar. Olhando em retrospecto, ele teria investido mais cedo no monitoramento da eficácia do modelo: a latência P99 é importante, mas não mostra se a resposta ajuda o usuário.

A terceira lição é de gestão. O que vale medir é o resultado, não a atividade: o número de linhas de código geradas não diz nada sobre valor. Para um engenheiro experiente, o Codex multiplica a produtividade, mas sem a habilidade de validar sistemas em produção, o risco também se multiplica. Seshadri resume assim: você tem um foguete nas mãos, e as chaves precisam ficar com as pessoas certas.

Se você está criando um assistente para catálogo, suporte ou busca, o checklist é curto:

1. Defina a que o sistema não vai responder.
2. Monte o conjunto inicial de evals junto com especialistas no assunto.
3. Coloque um segundo LLM para verificar as respostas e avalie separadamente esse verificador.
4. Acompanhe em produção a qualidade das respostas, e não apenas a latência.

Limitações

Esta é uma entrevista, não uma análise técnica, e foi publicada por um fornecedor. Não há números de precisão, latência ou custo por requisição, nem comparação com a busca anterior ou dados sobre o impacto no engajamento. Também não foi revelado como exatamente o juiz funciona nem em que ele difere do gerador. Por isso, o material não serve como prova de eficácia. Como lista de prioridades de engenharia para lançar um assistente em um produto de massa, porém, é bastante útil.