JioStar lanzó en 8 semanas un asistente de voz en más de 15 idiomas: la apuesta por las evals

Cuando tienes más de 500 millones de usuarios y hasta 72,5 millones de espectadores viendo deporte en directo al mismo tiempo, la frase «en la demo funcionaba» no significa nada. El asistente debe responder rápido, no mentir y no arruinar a la empresa con el coste de inferencia. Vijay Seshadri, Chief Architect de JioStar, contó en la cumbre de OpenAI en Singapur cómo su equipo recorrió ese camino. La entrevista se publicó en el blog de OpenAI, pero contiene más lecciones de ingeniería que publicidad.

Qué se construyó y por qué las recomendaciones habituales no bastaban

En JioHotstar añadieron un asistente conversacional basado en la API de OpenAI. El espectador dice qué quiere ver y recibe la respuesta en formato visual. Seshadri lo llama voice-visual interface: elegir contenido es, en esencia, una tarea visual, pero explicar un estado de ánimo o un gusto resulta más fácil con la voz que con clics.

Un ejemplo de la entrevista: «Estoy triste, enséñame algo que me anime». Un sistema de recomendación basado en el historial de visionado no entenderá qué tipo de tristeza es ni qué suele ayudar a esa persona. En una conversación, en cambio, se puede pedir una aclaración.

Las consultas, además, son muy variadas:

• de entretenimiento: «hoy es viernes, sorpréndeme» o la descripción de una película sin dar el título;
• deportivas: una serie de sixes, la caída de wickets, un partido en el que un jugador anotó cierto número de puntos;
• de nivel experto: estadísticas de cada bola.

Todo esto se reunió en una sola interfaz, en más de 15 idiomas y en unas ocho semanas. La fecha límite era un gran torneo de críquet en febrero. Más del 60% de los usuarios prefiere la voz al texto.

Cómo se construyó: límites, evals y un «juez para el juez»

Desde el principio el equipo trató el problema como un triángulo de «precisión, latencia y coste». Cada decisión de ingeniería movía los tres vértices a la vez.

El orden de trabajo es interesante. Primero, el equipo decidió a qué no debía responder el asistente. Una interfaz de voz permite preguntar cualquier cosa, así que los guardrails fueron el primer paso, no algo para «después del lanzamiento».

Después llegaron las evals. Partieron de un conjunto pequeño de preguntas iniciales y lo ampliaron con ayuda de modelos. Pero no empezaron por el prompt, sino por la experiencia humana: para las estadísticas deportivas recurrieron a editores de revistas deportivas, que saben qué preguntarán los aficionados de verdad.

Para la calidad de las respuestas usaron un esquema maker-checker. Un modelo decide cómo responder a la pregunta y otro revisa la respuesta como juez LLM, con un objetivo opuesto al del primero. Seshadri plantea de inmediato la siguiente pregunta: ¿quién revisa al juez? El validador es en sí mismo un problema que hay que evaluar, y ese trabajo no se puede omitir.

Codex aceleró la generación de casos de eval y la actualización del sistema. Pero, según Seshadri, montar rápido no sustituye al criterio ni a la validación. Trabajó un equipo pequeño de científicos de datos e ingenieros, con ingenieros forward-deployed de OpenAI sentados a su lado.

Qué conviene llevarse

La principal lección de Seshadri: «evals, evals y más evals». Según él, quienes empiezan las subestiman incluso cuando se creen preparados.

La segunda lección tiene que ver con producción. Hace falta un circuito de retroalimentación en el que el comportamiento de los usuarios y los fallos se conviertan en nuevos casos de eval. Seshadri reconoce que ese volante de inercia es muy difícil de poner en marcha. Visto en retrospectiva, habría invertido antes en monitorizar la eficacia del modelo: la latencia P99 importa, pero no muestra si la respuesta ayuda al usuario.

La tercera lección es de gestión. Conviene medir el resultado, no la actividad: el número de líneas de código generadas no dice nada sobre su valor. A un ingeniero sólido, Codex le multiplica el rendimiento, pero sin la capacidad de verificar sistemas de producción también se multiplica el riesgo. Seshadri lo resume así: tienes un cohete en las manos y las llaves hay que entregárselas a las personas adecuadas.

Si estás desarrollando un asistente para un catálogo, soporte o búsqueda, la lista de comprobación es corta:

1. Define a qué no responderá el sistema.
2. Reúne el conjunto inicial de evals junto con expertos en la materia.
3. Pon un segundo LLM a verificar las respuestas y evalúa por separado a ese verificador.
4. En producción, vigila la calidad de las respuestas, y no solo la latencia.

Limitaciones

Se trata de una entrevista, no de un análisis técnico, y la publica un proveedor. No hay cifras de precisión, latencia ni coste por consulta, ni comparación con la búsqueda anterior, ni datos sobre el efecto en el engagement. Tampoco se explica cómo está construido exactamente el juez ni en qué se diferencia del generador. Por eso el material no sirve como prueba de eficacia. Como lista de prioridades de ingeniería para lanzar un asistente en un producto masivo, resulta bastante útil.