Архитектът на JioStar за AI търсене при 500 млн. потребители

Поредицата ни Executive Function представя гледните точки на ръководители, които движат трансформацията чрез AI.

JioStar управлява платформи за развлекателно съдържание и спорт на живо с над 500 милиона потребители и е обслужвала до 72,5 милиона едновременни зрители на спортни предавания на живо. При такъв мащаб AI трябва да е бърз, надежден и готов за реална експлоатация.

С помощта на API на OpenAI JioStar вгради в JioHotstar разговорен асистент за откриване на видеосъдържание и статистики за крикет. Зрителите могат да говорят естествено, за да намерят филми и предавания, запомнящи се моменти от миналото, моменти от мачове на живо или статистики за крикет, а резултатите се представят визуално в хода на разговора.

На срещата на върха за ръководители на OpenAI в Сингапур Сидхарт Шарма, ръководител „Пускане на пазара“ за АСЕАН в OpenAI, разговаря с Виджай Сешадри, главен архитект на JioStar, за разработването на тази функционалност за над 15 езика за около осем седмици и за уроците за ръководителите, които преминават от демонстрации на AI към реална експлоатация.

Начинът на откриване на съдържание се е променил съвсем малко през последните 25 години. Препоръките бяха последната голяма промяна. Голяма част от последвалите нововъведения са вариации на същата идея.

Но изборът какво да гледаме е дълбоко личен. Някой може да каже: „Тъжно ми е. Покажи ми нещо, което ще ме развесели.“ Дори тази проста молба съдържа много нюанси. Каква точно е тъгата? Какво обикновено развеселява този човек? Комедия ли иска, нещо успокояващо или нещо, което напълно да го откъсне от мислите му?

За традиционната система за препоръки може да е трудно да разбере това моментно състояние. Разговорът дава на зрителя възможност да го обясни. Наричаме това гласово-визуален интерфейс.

Започнахме да разработваме концепцията през октомври и ноември, а през февруари предстоеше голям турнир по крикет. Разполагахме с около два месеца и имахме две много различни аудитории: зрители на развлекателно съдържание и фенове на крикета.

Зрител, който търси развлечение, може да каже: „Петък вечер е — изненадай ме“, или да опише филм, без да знае заглавието му. Зрителите на спорт може да търсят по-конкретна информация, например паднали уикети, поредица от шестици или мача, в който даден играч е отбелязал определен брой рънове. Познавачите на крикета може да искат статистика за всяка топка.

Това са много различни задачи за откриване на съдържание. Работихме по обединяването на развлекателно съдържание, спортни моменти и подробни статистики за крикет в общ интерфейс на множество езици за много кратко време.

Още в началото определихме задачата като търсене на баланс между три фактора: точност, време за отговор и разходи. Всяко инженерно решение трябваше да балансира и трите едновременно.

Гласовото взаимодействие направи това особено важно. Над 60% от потребителите ни използват глас вместо текст: хората предпочитат да кажат какво искат да гледат. Но отговорът трябва да остане уместен, бърз и икономически изгоден дори при голям мащаб.

Разглеждам я като две части: рамка за оценяване и слой за валидиране. Преди внедряването рамката за оценяване трябва да насочва какви промени са нужни. В реална експлоатация цикълът на обратна връзка трябва да превръща поведението на клиентите и неуспехите в нови тестови случаи за оценка.

Този цикъл може да започне да се усилва сам, но е изключително трудно да го накараш да работи правилно.

Експертите в съответната област са незаменими. За тестовете за оценка на спортните статистики работихме с хора като редактори на спортни списания, които разбираха какво биха попитали запалените фенове. Не можете да започнете само с подкана; трябва да заложите в основата на системата задълбочени човешки знания и опит.

Едно от нещата, с които се справихме добре, беше подборът на екипа. Започнахме с малък екип от специалисти по наука за данните и инженери и с ясно формулиран проблем. Инженерите на OpenAI, които работят пряко с клиентите по внедряването, ни помогнаха да уточним малкото на брой неща, с които непременно трябваше да се справим.

Първото беше обхватът. Гласовият или текстовият интерфейс позволява на потребителите да питат почти всичко, затова започнахме с решението на какво системата не бива да отговаря. Защитните механизми бяха на първо място.

За тестовете за оценка започнахме с начален набор от данни и използвахме модели, за да го разширим с по-разнообразни примери. Създадохме това, което днес бихте нарекли схема „създател–проверяващ“: един модел помагаше да се определи как да се отговори на въпрос, а друг изпълняваше ролята на валидатор — голям езиков модел като съдия — с противопоставена цел.

Това повдигна друг въпрос: кой проверява съдията? Самото проектиране на валидатора беше задача, свързана с оценяването. Codex помогна на екипа да ускори задачи като генерирането на тестови случаи за оценка и актуализирането на системата, но по-бързата разработка не премахна нуждата от преценка и валидиране.

Бих инвестирал по-рано в наблюдение на ефективността на модела в реална експлоатация.

Традиционните инфраструктурни показатели, като времето за отговор на 99-ия персентил (P99), остават важни, но не са достатъчни. Трябва да следите и ефективността на модела в реална експлоатация.

Първо, има голяма пропаст между възможностите на технологията и реалността в едно предприятие. Ако компанията ви не е успяла да навакса с всеки нов обявен авангарден модел, не сте единствените.

Второ, продължавайте да се съсредоточавате върху резултатите, а не върху извършената работа. Лесно е да объркате видимата активност със съществен напредък, особено когато компаниите наблягат на показателите за вложени усилия. Броят генерирани редове код например не показва дали сте създали реална стойност.

И накрая, повечето предприятия подценяват нужните умения и способността на хората да действат самостоятелно. Това не може да се сведе до обща програма за обучение. Ръководителите имат нужда от хора, които умеят да прилагат тези инструменти с добра преценка. Дайте на способен инженер инструмент като Codex и ефектът може да се умножи; без нужната преценка за валидиране на системите в реална експлоатация обаче рискът също се умножава.

В ръцете си държите ракета. Особено при системите в реална експлоатация са нужни валидиране и защитни механизми, а управлението трябва да поверите на правилните хора.