Главный архитектор JioStar об ИИ-поиске для 500 млн человек

В нашей серии Executive Function руководители делятся опытом преобразований с помощью ИИ.

JioStar управляет платформами с развлекательным контентом и прямыми спортивными трансляциями, которыми пользуются более 500 миллионов человек. Число одновременных зрителей спортивных трансляций достигало 72,5 миллиона. При таком масштабе ИИ должен быть быстрым, надёжным и готовым к промышленной эксплуатации.

С помощью API OpenAI компания JioStar встроила в JioHotstar диалогового ассистента для поиска видео и статистики по крикету. Зрители могут обычными словами попросить найти фильмы и сериалы, яркие эпизоды прошлых игр, моменты текущего матча или статистику по крикету. Результаты отображаются в визуальном интерфейсе, где можно продолжить диалог.

На саммите руководителей OpenAI в Сингапуре Сидхарт Шарма, руководитель OpenAI по стратегии вывода на рынок в странах АСЕАН, побеседовал с Виджаем Сешадри, главным архитектором JioStar. Они обсудили, как примерно за восемь недель создать сервис с поддержкой более 15 языков и какие уроки стоит извлечь руководителям, которые переводят ИИ из демоверсии в промышленную эксплуатацию.

За последние 25 лет поиск контента изменился совсем мало. Последним крупным сдвигом стало появление рекомендаций. Многое из того, что появилось позже, лишь развивало ту же идею.

Но выбор того, что посмотреть, — глубоко личное дело. Человек может сказать: «Мне грустно. Покажи что-нибудь, что поднимет мне настроение». Даже в таком простом запросе много нюансов. Что это за грусть? Что обычно поднимает этому человеку настроение? Ему хочется комедии, чего-то уютного и знакомого или чего-то, что поможет полностью отвлечься?

Традиционной рекомендательной системе бывает трудно понять такое состояние. Диалог даёт зрителю возможность его объяснить. Мы называем это голосовым визуальным интерфейсом.

В октябре и ноябре мы начали прорабатывать концепцию, а на февраль был запланирован крупный турнир по крикету. У нас было около двух месяцев и две очень разные аудитории: любители развлекательного контента и поклонники крикета.

Зритель, который ищет развлекательный контент, может сказать: «Вечер пятницы — удиви меня» или описать фильм, не зная его названия. Любители спорта могут искать что-то более конкретное: падения калиток, серию шестёрок или матч, в котором игрок набрал определённое число ранов. Знатокам крикета может понадобиться статистика по каждой подаче.

Это совершенно разные поисковые задачи. За очень короткий срок нам предстояло объединить развлекательный контент, спортивные моменты и подробную статистику по крикету в одном сервисе с поддержкой нескольких языков.

С самого начала мы сформулировали задачу как поиск баланса между точностью, задержкой и стоимостью. В каждом инженерном решении нужно было учитывать все три фактора одновременно.

Для голосового взаимодействия это было особенно важно. Более 60% наших пользователей выбирают голос, а не текст: люди предпочитают вслух говорить, что хотят посмотреть. При этом ответ должен быть релевантным и быстрым, а его стоимость — приемлемой даже при большой нагрузке.

Я выделяю в ней две части: систему оценочных тестов и уровень проверки. До запуска результаты оценочных тестов должны помогать определять, что нужно изменить. После запуска контур обратной связи должен превращать данные о поведении пользователей и сбоях в новые тестовые сценарии.

Этот цикл может сам набирать обороты, но правильно его выстроить чрезвычайно сложно.

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

С командой мы точно не ошиблись. Мы начали с небольшой команды специалистов по данным и инженеров и чётко сформулированной задачи. Инженеры OpenAI по внедрению работали вместе с нами и помогли точнее определить несколько ключевых вещей, в которых мы не имели права ошибиться.

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

Для оценочных тестов мы взяли исходный набор данных и с помощью моделей расширили его, добавив больше разнообразных вариантов. Мы создали схему, которую сейчас можно назвать «исполнитель — проверяющий»: одна модель помогала определить, как ответить на вопрос, а другая проверяла ответ, выступая в роли LLM-судьи с противоположной задачей.

Это породило новый вопрос: а кто проверяет судью? Разработка проверяющей модели сама по себе стала задачей оценки качества. Codex помог команде ускорить такие задачи, как создание тестовых сценариев и обновление системы, но ускорение разработки не отменило необходимости в экспертных решениях и проверках.

Я бы раньше вложился в мониторинг эффективности модели в рабочей среде.

Традиционные инфраструктурные метрики, такие как задержка P99, по-прежнему важны, но их недостаточно. Нужно также отслеживать эффективность модели в реальной эксплуатации.

Во-первых, между возможностями технологий и реальностью внутри компании существует большой разрыв. Если ваша компания не успевает внедрять каждую новую передовую модель, вы не одиноки.

Во-вторых, сохраняйте фокус на результатах, а не на активности. Видимую деятельность легко принять за реальный прогресс, особенно когда компании делают упор на показатели затраченных усилий. Например, число сгенерированных строк кода не говорит о том, создали ли вы реальную ценность.

Наконец, большинство компаний недооценивают, насколько важны профессионализм людей и их способность действовать самостоятельно. Одной общей программой обучения здесь не обойтись. Руководителям нужны люди, способные применять эти инструменты осмысленно. Дайте сильному инженеру такой инструмент, как Codex, и эффект может вырасти многократно. Но без умения критически оценивать рабочие системы риски тоже умножаются.

У вас в руках ракета. Особенно в рабочих системах необходимы проверки и защитные ограничения, а управление нужно доверять тем, кто с ним справится.