Główny architekt JioStar: odkrywanie treści z AI dla 500 mln osób
Rozmowa z Vijayem Seshadrim, głównym architektem JioStar.

W serii Executive Function przedstawiamy perspektywy liderów, którzy wykorzystują AI do wprowadzania zmian.
JioStar prowadzi platformy z treściami rozrywkowymi i transmisjami sportowymi, z których korzysta ponad 500 milionów osób. Transmisje sportowe przyciągały nawet 72,5 miliona widzów jednocześnie. Przy takiej skali AI musi działać szybko, niezawodnie i być gotowa do pracy w środowisku produkcyjnym.
Korzystając z API OpenAI, JioStar wdrożył w JioHotstar asystenta, który pomaga wyszukiwać materiały wideo i statystyki krykietowe poprzez rozmowę. Widzowie mogą mówić w naturalny sposób, by znaleźć filmy i programy, najciekawsze momenty dawnych rozgrywek, fragmenty meczów na żywo lub statystyki krykietowe. Wyniki są prezentowane wizualnie w interfejsie konwersacyjnym.
Podczas konferencji Executive Summit organizowanej przez OpenAI w Singapurze Sidharth Sharma, szef OpenAI ds. strategii prowadzenia na rynek w regionie ASEAN, rozmawiał z Vijayem Seshadrim, głównym architektem JioStar, o stworzeniu tego rozwiązania w ponad 15 językach w około osiem tygodni oraz o wnioskach dla liderów, którzy przechodzą od demonstracji AI do wdrożeń produkcyjnych.
Sposób odkrywania treści niewiele się zmienił przez ostatnie 25 lat. Ostatnią dużą zmianą były rekomendacje. Większość późniejszych rozwiązań to kolejne warianty tego samego pomysłu.
Tymczasem wybór tego, co obejrzeć, jest sprawą bardzo osobistą. Ktoś może powiedzieć: „Jest mi smutno. Pokaż mi coś, co poprawi mi humor”. Nawet taka prosta prośba kryje wiele niuansów. O jaki smutek chodzi? Co zwykle poprawia tej osobie humor? Ma ochotę na komedię, coś kojącego czy coś, co całkowicie odciągnie jej myśli od problemów?
Tradycyjny system rekomendacji może mieć trudność ze zrozumieniem takiej sytuacji. Rozmowa pozwala widzowi ją wyjaśnić. Nazywamy to interfejsem głosowo-wizualnym.
Prace nad koncepcją rozpoczęliśmy w październiku i listopadzie, a na luty zaplanowany był ważny turniej krykietowy. Mieliśmy około dwóch miesięcy i dwie bardzo różne grupy odbiorców: widzów szukających rozrywki i fanów krykieta.
Widz szukający rozrywki może powiedzieć: „Jest piątkowy wieczór — zaskocz mnie” albo opisać film, którego tytułu nie zna. Widzowie sportowi mogą szukać czegoś bardziej konkretnego: momentów wyeliminowania odbijających, serii szóstek albo meczu, w którym zawodnik zdobył określoną liczbę runów. Znawcy krykieta mogą chcieć statystyk dotyczących każdej piłki.
To bardzo różne wyzwania związane z wyszukiwaniem treści. Pracowaliśmy nad połączeniem rozrywki, fragmentów rozgrywek sportowych i szczegółowych statystyk krykietowych w jednym rozwiązaniu, w wielu językach i w bardzo krótkim czasie.
Już na samym początku uznaliśmy, że problem polega na znalezieniu kompromisu między trzema czynnikami: trafnością, opóźnieniem i kosztem. Każda decyzja inżynieryjna musiała uwzględniać wszystkie trzy naraz.
Było to szczególnie ważne ze względu na obsługę głosową. Ponad 60% naszych użytkowników korzysta z głosu zamiast tekstu: ludzie wolą powiedzieć, co chcą obejrzeć. Odpowiedź nadal musi być trafna, szybka i opłacalna przy dużej skali.
Widzę tu dwa elementy: mechanizm ewaluacji i warstwę walidacji. Przed wdrożeniem produkcyjnym mechanizm ewaluacji powinien wskazywać potrzebne zmiany. W środowisku produkcyjnym pętla informacji zwrotnej powinna przekładać zachowania klientów i niepowodzenia systemu na nowe przypadki ewaluacyjne.
Ten mechanizm może sam się napędzać, ale niezwykle trudno sprawić, by działał prawidłowo.
Niezbędni są eksperci dziedzinowi. Przy ewaluacjach dotyczących statystyk sportowych współpracowaliśmy między innymi z redaktorami magazynów sportowych, którzy rozumieli, o co mogą pytać zagorzali kibice. Nie można zacząć od samego polecenia; system trzeba od początku zasilić dogłębną wiedzą ekspertów.
Jedną z rzeczy, które nam się udały, był dobór zespołu. Zaczęliśmy od małego zespołu specjalistów data science i inżynierów oraz jasno określonego problemu. Inżynierowie wdrożeniowi OpenAI pracowali ramię w ramię z nami, pomagając doprecyzować kilka kwestii, które bezwzględnie musieliśmy dobrze rozwiązać.
Pierwszą był zakres. Interfejs głosowy lub tekstowy pozwala użytkownikom pytać niemal o wszystko, więc zaczęliśmy od ustalenia, na co system nie powinien odpowiadać. Zabezpieczenia były na pierwszym miejscu.
Ewaluacje zaczęliśmy od wyjściowego zbioru danych, który rozszerzyliśmy za pomocą modeli o bardziej zróżnicowane przypadki. Stworzyliśmy coś, co dziś można nazwać schematem twórca–kontroler: jeden model pomagał ustalić, jak odpowiedzieć na pytanie, a drugi pełnił funkcję walidatora — modelu LLM w roli sędziego — realizując przeciwstawny cel.
To rodziło kolejne pytanie: kto testuje sędziego? Samo zaprojektowanie walidatora było wyzwaniem ewaluacyjnym. Codex pomógł zespołowi przyspieszyć takie zadania jak generowanie przypadków ewaluacyjnych i aktualizowanie systemu, ale szybsze tworzenie nie wyeliminowało potrzeby krytycznej oceny i walidacji.
Wcześniej zainwestowałbym w monitorowanie skuteczności modelu w środowisku produkcyjnym.
Tradycyjne wskaźniki infrastruktury, takie jak opóźnienie P99, pozostają ważne, ale nie wystarczają. Trzeba też monitorować skuteczność modelu w środowisku produkcyjnym.
Po pierwsze, możliwości technologii dzieli duża przepaść od realiów wewnątrz przedsiębiorstwa. Jeśli twoja firma nie nadąża za każdą premierą pionierskiego modelu, nie jest w tym odosobniona.
Po drugie, konsekwentnie skupiaj się na efektach, a nie na samych działaniach. Łatwo pomylić widoczną aktywność z rzeczywistym postępem, zwłaszcza gdy firmy kładą nacisk na mierzenie nakładów. Na przykład liczba wygenerowanych linii kodu nie mówi, czy powstała realna wartość.
I wreszcie większość przedsiębiorstw nie docenia tego, jak dużych umiejętności i samodzielności działania wymaga to od ludzi. Nie wystarczy ogólny program podnoszenia kwalifikacji. Liderzy potrzebują ludzi, którzy potrafią korzystać z tych narzędzi z rozwagą. Daj dobremu inżynierowi narzędzie takie jak Codex, a efekty jego pracy mogą wzrosnąć wielokrotnie. Bez umiejętności krytycznej oceny przy walidacji systemów produkcyjnych równie mocno rośnie jednak ryzyko.
Masz w rękach rakietę. Zwłaszcza w systemach produkcyjnych potrzebujesz walidacji i zabezpieczeń, a stery musisz powierzyć właściwym ludziom.


