Hlavní architekt JioStar: hledání s AI pro 500 milionů lidí

Náš seriál Executive Function přináší pohledy lídrů, kteří s pomocí AI prosazují zásadní změny.

JioStar provozuje platformy se zábavním obsahem a živými sportovními přenosy, které využívá přes 500 milionů uživatelů. Sportovní přenosy na nich sledovalo až 72,5 milionu diváků současně. V takovém měřítku musí být AI rychlá, spolehlivá a připravená na ostrý provoz.

S využitím API OpenAI zabudovala společnost JioStar do JioHotstar konverzačního asistenta pro vyhledávání videí a kriketových statistik. Diváci mohou běžnou řečí vyhledávat filmy a pořady, památné momenty z minulosti, okamžiky z právě hraných zápasů nebo kriketové statistiky. Výsledky se jim zobrazují ve vizuálním rozhraní propojeném s konverzací.

Na akci OpenAI Executive Summit v Singapuru hovořil Sidharth Sharma, vedoucí strategie uvedení na trh v OpenAI pro region ASEAN, s Vijayem Seshadrim, hlavním architektem JioStar. Probírali, jak tuto funkci vyvinuli pro více než 15 jazyků zhruba za osm týdnů a co si z toho mohou odnést lídři, kteří převádějí AI z ukázek do ostrého provozu.

Způsob objevování obsahu se za posledních 25 let změnil jen velmi málo. Poslední velkou změnou byla doporučení. Většina toho, co přišlo potom, jen obměňovala stejnou myšlenku.

Výběr toho, na co se dívat, je ale velmi osobní. Člověk může říct: „Je mi smutno. Ukaž mi něco, co mě rozveselí.“ I tak jednoduchý požadavek v sobě skrývá spoustu nuancí. Jaký smutek prožívá? Co ho obvykle rozveselí? Chce komedii, něco příjemného na uklidnění, nebo něco, u čeho úplně přijde na jiné myšlenky?

Tradiční doporučovací systém může mít problém takové rozpoložení pochopit. Konverzace dává divákovi možnost ho vysvětlit. Říkáme tomu hlasově-vizuální rozhraní.

Koncept jsme začali rozpracovávat v říjnu a listopadu a v únoru nás čekal velký kriketový turnaj. Měli jsme zhruba dva měsíce a dvě velmi odlišné skupiny diváků: zájemce o zábavní obsah a fanoušky kriketu.

Divák hledající zábavu může říct: „Je pátek večer, překvap mě,“ nebo popsat film, jehož název nezná. Sportovní diváci mohou chtít konkrétnější přehled, třeba, kolik padlo branek, sérii šestek nebo zápas, ve kterém hráč získal určitý počet přeběhů. Znalci kriketu mohou chtít statistiky ke každému nadhozu.

Z hlediska vyhledávání jde o velmi odlišné úlohy. Pracovali jsme na tom, abychom ve velmi krátké době propojili zábavu, sportovní momenty a podrobné kriketové statistiky do jednoho rozhraní v několika jazycích.

Hned na začátku jsme si problém vymezili jako hledání rovnováhy mezi přesností, latencí a náklady. Každé technické rozhodnutí muselo zohlednit všechny tři aspekty najednou.

Kvůli hlasovému ovládání to bylo obzvlášť důležité. Více než 60 % našich uživatelů používá hlas místo textu: lidé raději řeknou, na co se chtějí dívat. Odpověď přitom musí být relevantní, rychlá a ekonomicky únosná i při velkém počtu uživatelů.

Vnímám ho jako dvě části: hodnoticí rámec a validační vrstvu. Před nasazením do ostrého provozu by měl hodnoticí rámec poskytovat podněty ke změnám. V ostrém provozu by pak zpětnovazební smyčka měla proměňovat chování zákazníků a selhání systému v nové testovací případy pro hodnocení.

Tento cyklus se může sám dál posilovat, ale je nesmírně obtížné ho správně nastavit.

Odborníci na danou oblast jsou nepostradatelní. Při hodnocení sportovních statistik jsme spolupracovali například s redaktory sportovních časopisů, kteří věděli, na co se mohou zapálení fanoušci ptát. Nemůžete začít jen samotným promptem; do základů systému musíte vložit hluboké odborné znalosti lidí.

Jednou z věcí, které se nám povedly, bylo sestavení týmu. Začali jsme s malým týmem datových vědců a vývojářů a s jasně definovaným problémem. Inženýři OpenAI, kteří pracují přímo se zákazníky, nám pomáhali přesněji určit těch několik věcí, které jsme museli zvládnout naprosto správně.

První z nich bylo vymezení rozsahu. Hlasové nebo textové rozhraní umožňuje uživatelům ptát se téměř na cokoli, a tak jsme nejprve rozhodli, na co systém odpovídat nemá. Bezpečnostní pravidla byla na prvním místě.

Pro hodnocení jsme začali s výchozí datovou sadou a pomocí modelů ji rozšířili o další varianty. Vytvořili jsme uspořádání, kterému by se dnes dalo říkat princip tvůrce a kontrolora: jeden model pomáhal určit, jak na otázku odpovědět, zatímco druhý fungoval jako validátor – LLM v roli rozhodčího – s protichůdným cílem.

To vyvolalo další otázku: kdo otestuje rozhodčího? Už samotný návrh validátoru byl úlohou vyžadující hodnocení. Codex týmu pomohl urychlit například generování testovacích případů pro hodnocení a aktualizace systému. Rychlejší vývoj ale neodstranil potřebu úsudku a validace.

Dříve bych investoval do sledování účinnosti modelů v ostrém provozu.

Tradiční metriky infrastruktury, jako je latence P99, jsou i nadále důležité, ale nestačí. Je třeba sledovat i účinnost modelů v ostrém provozu.

Zaprvé, mezi možnostmi technologií a realitou uvnitř firem je velká propast. Pokud vaše firma nedrží krok s každým oznámením průkopnického modelu, nejste v tom sami.

Zadruhé, soustřeďte se dál na výsledky, ne na samotnou aktivitu. Je snadné zaměnit viditelný ruch za skutečný pokrok, zvlášť když firmy kladou důraz na vstupní metriky. Například počet vygenerovaných řádků kódu vám neřekne, zda jste vytvořili skutečnou hodnotu.

A nakonec většina firem podceňuje, jaké dovednosti a schopnost samostatně jednat to od lidí vyžaduje. Nelze se omezit na obecný program dovedností. Lídři potřebují lidi, kteří dokážou tyto nástroje používat s dobrým úsudkem. Dejte schopnému vývojáři nástroj jako Codex a jeho přínos se může znásobit. Bez úsudku potřebného k validaci systémů v ostrém provozu se ale násobí i riziko.

Máte v rukou raketu. Zvlášť u systémů v ostrém provozu potřebujete validaci a bezpečnostní pravidla a jejich řízení musíte svěřit správným lidem.