Vijay Seshadri, a JioStar Chief Architectje az OpenAI Executive Summiton Szingapúrban beszélt arról, hogyan építettek be egy beszélgetéses, hang- és vizuális élményt JioHotstarba. A JioStar által működtetett szórakoztatási és élő sportplatformokat több mint 500 millió felhasználó használja; a cég emellett egyszerre legfeljebb 72,5 millió egyidejű élő közvetítésnézőt is kiszolgált. Az ilyen méret mellett az MI-megoldásoknak gyorsnak, megbízhatónak és éles környezetre alkalmasnak kell lenniük.
Mi készült és mire képes
A JioStar az OpenAI API-t használva egy beszélgetéses videó- és krikettstatisztika-felfedező asszisztenst épített JioHotstarba. A nézők természetes nyelven beszélhetnek, hogy filmeket és műsorokat, korábbi összefoglalókat, élő mérkőzéspillanatokat vagy krikettstatisztikákat találjanak meg; a válaszokat vizuális, beszélgetéses formában kapják meg.
Az élmény több mint 15 nyelvet támogató megoldásként készült el nagyjából nyolc hét alatt. A fejlesztési koncepciót a csapat október–november folyamán kezdte kidolgozni, mert februárban egy nagy krikett-torna zajlott, ami fontos határidőt jelentett.
Kihívások: két, eltérő közönség és szűk határidő
A JioStar-nál két nagyon különböző felhasználói csoportot kellett kiszolgálni: a szórakoztató tartalmak nézőit és a krikettrajongókat. Az előbbi csoportnál a felhasználók például azt mondhatják: „Péntek este van — lepj meg”, vagy egy filmet úgy írnak le, hogy nem ismerik a címét. A sportnézők viszont konkrétabb lekérdezéseket tesznek fel, például kiesett wicketekről, hatos sorozatokról vagy arról, hogy melyik meccsen ért el egy játékos egy adott pontszámot. A krikett-szakértők akár minden labdára kiterjedő statisztikákat igényelhetnek.
Ezek eltérő felfedezési feladatok voltak; a csapat célja az volt, hogy legyen egyetlen, többnyelvű élmény, amely egyszerre kezeli az általános szórakoztatást, a mérkőzéspillanatokat és a részletes krikettstatisztikákat rövid idő alatt.
Műszaki mérlegelés: pontosság, késleltetés és költség
Korán meghatározták, hogy a probléma háromirányú kompromisszumként fogható fel: pontosság, késleltetés (latencia) és költség. Minden mérnöki döntésnél egyszerre kellett ezeket egyensúlyozni. A hangalapú interakció különösen érzékennyé tette ezt: a JioStar szerint a felhasználók több mint 60%-a inkább hanggal kommunikál, ezért a válasznak relevánsnak, gyorsnak és skálázhatónak kell lennie költséghatékonyan.
Értékelés, élesítés és validáció
Seshadri két részre bontotta a megközelítést: egy értékelési keretrendszerre és egy validációs rétegre. A bevezetés előtti értékelési fázisban a rendszer változtatásra ösztönözte a fejlesztést; élesítés után pedig egy visszacsatolási hurknak kellett a felhasználói viselkedésből és hibákból új értékelési eseteket generálnia. Ezt a folyamatot nehéz jól megvalósítani.
A csapat domain-szakértőkkel dolgozott együtt: a sportstatisztikák értékelésénél például sportmagazin-szerkesztőkkel működtek együtt, akik megértik, mit kérdeznek a komoly rajongók. Seshadri hangsúlyozta, hogy nem lehet csak promptokkal kezdeni; a rendszert mély emberi szakértelemmel kell betáplálni.
Csapat, eszközök és minták
A kezdeti csapat kicsi volt: néhány adatkutató és mérnök egy világos problémameghatározás körül. OpenAI előre telepített mérnökei is együtt dolgoztak velük, hogy azonosítsák azokat a kulcskérdéseket, amelyeket feltétlenül meg kellett oldani.
A fejlesztés korai szakaszában a csapat meghatározta a hatókört is: mivel a beszéd- vagy szövegfelületen a felhasználók bármit megkérdezhetnek, először azt döntötték el, mit ne válaszoljon a rendszer. Azaz guardrail-eket és korlátokat építettek be.
Az értékelésekhez kezdeti seed-adatkészletet használtak, amelyet modellek segítségével bővítettek többféle variációval. Egy maker-checker mintát alkalmaztak: egyik modell javasolta a választ, míg egy másik modell validator szerepben, versengő célkitűzéssel vizsgálta a javaslatot. Ennek megtervezése önmagában is értékelési feladat volt — ki ellenőrzi a bíró modellt?
A Codex eszközt is használták olyan munkák felgyorsítására, mint az értékelési esetek generálása és a rendszerfrissítések, de Seshadri rámutatott, hogy a gyorsabb építés nem szünteti meg a szakmai ítélet és validáció szükségességét.
Ajánlások a vezetőknek: monitoring, kimenetek és emberi készségek
Seshadri szerint korábban érdemes beruházni a modell-hatékonyságot mérő éles monitoringba. A hagyományos infrastruktúra-mutatók, például a P99 késleltetés, továbbra is fontosak, de önmagukban nem elegendők: monitorozni kell a modellek valós hatékonyságát is.
Kiemelte a gyakorlat és a valóság közötti különbséget: sok vállalat nem követ minden élvonalbeli modellbejelentést, és ez normális. Arra is figyelmeztetett, hogy a vezetők ne tévesszék össze a látható tevékenységet (például generált kódsorok száma) a valódi eredményekkel; inkább az üzleti kimenetekre koncentráljanak.
Végezetül hangsúlyozta, hogy a vállalatok általában alábecslik a szükséges emberi készséget és döntési jogkört. Az MI-alkalmazások nem oldhatók meg csupán általános képzéssel: szükség van emberekre, akik ítélkezni és validálni tudják az éles rendszereket. "Rakétát tartasz a kezedben" — mondta —, ezért különösen az éles rendszerek esetén kell validáció, guardrail és a megfelelő emberek kezébe adni a kulcsokat.
Összefoglalás
JioStar gyorsan, kevesebb mint három hónap alatt egy többnyelvű, hangalapú beszélgetéses felfedezőélményt épített JioHotstarba az OpenAI API használatával, egyesítve általános szórakoztatási keresést, mérkőzés-pillanatokat és részletes krikettstatisztikákat. A projekt tapasztalatai szerinti kulcstényezők a domain-szakértők bevonása, korai guardrail-ek és egy értékelési–validációs folyamat voltak, miközben folyamatos monitoringot és emberi ítélőképességet hangsúlyoznak az éles rendszerek működtetéséhez.
