JioStar за 8 недель запустил голосового ассистента на 15+ языках: ставка на evals

Когда у тебя больше 500 млн пользователей и до 72,5 млн зрителей, одновременно смотрящих лайв-спорт, фраза «в демо всё работало» ничего не значит. Ассистент должен отвечать быстро, не врать и не разорить компанию на инференсе. Chief Architect JioStar Виджай Шешадри рассказал на саммите OpenAI в Сингапуре, как его команда прошла этот путь. Это интервью опубликовано в блоге OpenAI, но инженерных уроков в нём больше, чем рекламы.

Что построили и почему обычные рекомендации не справлялись

В JioHotstar добавили разговорного помощника на OpenAI API. Зритель говорит, что хочет посмотреть, и получает ответ в визуальном виде. Шешадри называет это voice-visual interface: выбор контента по сути визуален, но объяснить настроение или вкус голосом проще, чем кликами.

Пример из интервью: «Мне грустно, покажи что-нибудь, что подбодрит». Рекомендательная система по истории просмотров не поймёт, какая именно это грусть и что обычно помогает этому человеку. В диалоге можно уточнить.

Запросы при этом очень разные:

• развлекательные: «сегодня пятница, удиви меня» или описание фильма без названия;
• спортивные: серия шестёрок, падение калиток, матч, где игрок набрал нужное число очков;
• экспертные: статистика по каждому мячу.

Всё это собрали в одном интерфейсе, на 15+ языках, примерно за восемь недель. Дедлайном был крупный турнир по крикету в феврале. Больше 60% пользователей предпочитают голос тексту.

Как строили: границы, evals и «судья для судьи»

С самого начала задачу рассматривали как треугольник «точность — задержка — стоимость». Любое инженерное решение двигало сразу все три вершины.

Порядок работ интересен. Сначала команда решила, на что ассистент отвечать не должен. Голосовой интерфейс позволяет спросить что угодно, поэтому guardrails шли первым шагом, а не «после запуска».

Потом evals. Взяли небольшой исходный набор вопросов и расширили его с помощью моделей. Но стартовали не с промпта, а с человеческой экспертизы: для спортивной статистики привлекли редакторов спортивных журналов, которые знают, что спросят настоящие фанаты.

Для качества ответов использовали схему maker-checker. Одна модель решает, как ответить на вопрос, другая проверяет ответ как LLM-судья, причём у неё противоположная цель. Шешадри сразу задаёт следующий вопрос: кто проверяет судью? Валидатор сам оказывается задачей для оценки, и эту работу нельзя пропустить.

Codex ускорил генерацию eval-кейсов и обновление системы. Но, по словам Шешадри, быстрая сборка не отменяет суждения и валидации. Работала небольшая команда дата-сайентистов и инженеров, рядом с ней сидели forward-deployed инженеры OpenAI.

Что из этого взять себе

Главный урок Шешадри: «evals, evals и ещё раз evals». Новички, по его словам, недооценивают их даже тогда, когда считают себя готовыми.

Второй урок касается продакшена. Нужна обратная связь, в которой поведение пользователей и сбои превращаются в новые eval-кейсы. Шешадри признаёт, что такой маховик очень трудно настроить. Задним числом он бы раньше вложился в мониторинг эффективности модели: P99-задержка важна, но не показывает, помогает ли ответ пользователю.

Третий урок управленческий. Мерить стоит результат, а не активность: число строк сгенерированного кода не говорит о ценности. Сильному инженеру Codex умножает отдачу, но без навыка проверять продакшен-системы умножается и риск. Шешадри формулирует это так: у вас в руках ракета, и ключи надо отдавать правильным людям.

Если делаешь ассистента для каталога, поддержки или поиска, чек-лист короткий:

1. Определи, на что система отвечать не будет.
2. Собери стартовый eval-набор вместе с предметными экспертами.
3. Поставь второй LLM проверять ответы и отдельно оцени сам этот проверяющий.
4. Следи в продакшене за качеством ответов, а не только за задержкой.

Ограничения

Это интервью, а не технический разбор, и опубликовано оно вендором. Здесь нет цифр по точности, задержке и стоимости запроса, нет сравнения с прежним поиском и данных о влиянии на вовлечённость. Как именно устроен судья и чем он отличается от генератора, тоже не раскрыто. Поэтому как доказательство эффективности материал не годится. Как перечень инженерных приоритетов для запуска ассистента в массовом продукте он вполне полезен.