معمار JioStar: کشف محتوا با هوش مصنوعی برای ۵۰۰ میلیون کاربر

در مجموعه «کارکرد اجرایی»، دیدگاه‌های مدیرانی را می‌شنویم که با هوش مصنوعی تحول ایجاد می‌کنند.

JioStar پلتفرم‌های سرگرمی و پخش زنده ورزشی را اداره می‌کند که بیش از ۵۰۰ میلیون مصرف‌کننده دارند و تاکنون میزبان ۷۲٫۵ میلیون بیننده هم‌زمان برای پخش زنده مسابقات ورزشی بوده‌اند. در چنین مقیاسی، هوش مصنوعی باید سریع، قابل‌اعتماد و آماده بهره‌برداری باشد.

JioStar با استفاده از API شرکت OpenAI، دستیاری گفت‌وگومحور برای یافتن ویدئو و آمار کریکت در JioHotstar ساخته است. بینندگان می‌توانند با گفتار طبیعی، فیلم و برنامه، صحنه‌های برتر مسابقات گذشته، لحظات مسابقات زنده یا آمار کریکت را پیدا کنند و نتایج را در تجربه‌ای بصری و گفت‌وگومحور ببینند.

در اجلاس مدیران OpenAI در سنگاپور، سیدارت شارما، مدیر راهبرد ورود به بازار OpenAI در منطقه آسه‌آن، با ویجی سشادری، معمار ارشد JioStar، گفت‌وگو کرد. موضوع این گفت‌وگو ساخت این تجربه برای بیش از ۱۵ زبان در حدود هشت هفته و درس‌هایی برای مدیرانی بود که هوش مصنوعی را از نسخه نمایشی به مرحله بهره‌برداری می‌رسانند.

شیوه کشف محتوا در ۲۵ سال گذشته تغییر چندانی نکرده است. آخرین تحول عمده، پیشنهاد محتوا به کاربران بود. بخش بزرگی از آنچه پس از آن رخ داده، صرفاً بهبود همان ایده بوده است.

اما انتخاب اینکه چه چیزی تماشا کنیم، امری کاملاً شخصی است. ممکن است کسی بگوید: «دلم گرفته. چیزی نشانم بده که حالم را بهتر کند.» حتی همین درخواست ساده هم ظرافت‌های زیادی دارد. چه نوع ناراحتی‌ای دارد؟ معمولاً چه چیزی حالش را بهتر می‌کند؟ دنبال کمدی است، چیزی آرامش‌بخش می‌خواهد یا برنامه‌ای که کاملاً حواسش را از ناراحتی پرت کند؟

ممکن است درک حال‌وهوای آن لحظه برای یک سیستم پیشنهاددهنده سنتی دشوار باشد. گفت‌وگو به بیننده امکان می‌دهد آن را توضیح دهد. ما این را رابط صوتی و بصری می‌نامیم.

در اکتبر و نوامبر کار روی ایده را آغاز کردیم و قرار بود یک تورنمنت مهم کریکت در فوریه برگزار شود. حدود دو ماه فرصت داشتیم و با دو گروه مخاطب بسیار متفاوت روبه‌رو بودیم: بینندگان محتوای سرگرمی و طرفداران کریکت.

بیننده محتوای سرگرمی ممکن است بگوید: «عصر جمعه است؛ غافلگیرم کن»، یا فیلمی را توصیف کند بی‌آنکه نامش را بداند. بینندگان ورزش ممکن است دنبال اطلاعات مشخص‌تری باشند؛ مثلاً لحظات اوت‌شدن بازیکنان، چند ضربه شش‌امتیازی یا مسابقه‌ای که در آن بازیکنی تعداد مشخصی ران گرفته است. کارشناسان کریکت ممکن است آمار تک‌تک توپ‌ها را بخواهند.

این‌ها نیازهای بسیار متفاوتی در زمینه کشف محتوا هستند. تلاش کردیم در زمانی بسیار کوتاه، محتوای سرگرمی، لحظات ورزشی و آمار دقیق کریکت را در تجربه‌ای یکپارچه و چندزبانه گرد هم بیاوریم.

از همان ابتدا، مسئله را برقراری توازن میان سه عامل تعریف کردیم: دقت، تأخیر و هزینه. هر تصمیم مهندسی باید هم‌زمان هر سه عامل را در نظر می‌گرفت.

تعامل صوتی، اهمیت این موضوع را دوچندان می‌کرد. بیش از ۶۰٪ کاربران ما به‌جای متن از صدا استفاده می‌کنند: مردم ترجیح می‌دهند به زبان بیاورند که چه می‌خواهند تماشا کنند. با این حال، پاسخ باید مرتبط و سریع باشد و ارائه آن در مقیاس بزرگ صرفه اقتصادی داشته باشد.

من آن را در دو بخش می‌بینم: یک چارچوب ارزیابی و یک لایه اعتبارسنجی. پیش از بهره‌برداری، چارچوب ارزیابی باید مبنای اعمال تغییرات باشد. در محیط عملیاتی، یک چرخه بازخورد باید رفتار مشتریان و موارد خطا را به آزمون‌های ارزیابی جدید تبدیل کند.

این چرخه می‌تواند خودش را تقویت کند، اما راه‌اندازی درست آن بسیار دشوار است.

حضور متخصصان آن حوزه ضروری است. برای ارزیابی آمار ورزشی، با افرادی مانند سردبیران مجلات ورزشی کار کردیم که می‌دانستند طرفداران جدی چه سؤال‌هایی ممکن است بپرسند. نمی‌توانید کار را فقط با یک اعلان شروع کنید؛ باید از ابتدا دانش تخصصی عمیق انسان‌ها را وارد سیستم کنید.

یکی از کارهایی که درست انجام دادیم، تشکیل تیم مناسب بود. با تیم کوچکی از دانشمندان داده و مهندسان شروع کردیم که تعریف روشنی از مسئله داشتند. مهندسان مستقر در محل مشتریِ OpenAI در کنار ما کار کردند تا دقیق‌تر مشخص کنیم کدام چند مورد را حتماً باید درست انجام دهیم.

اولین مورد، دامنه کار بود. رابط صوتی یا متنی به کاربران اجازه می‌دهد تقریباً هر چیزی بپرسند؛ بنابراین ابتدا مشخص کردیم سیستم به چه چیزهایی نباید پاسخ دهد. ضوابط ایمنی در اولویت بودند.

برای ارزیابی، از یک مجموعه‌داده اولیه شروع کردیم و با کمک مدل‌ها آن را گسترش دادیم و تنوع بیشتری به آن بخشیدیم. الگویی ساختیم که امروز شاید آن را «سازنده–بازبین» بنامید: یک مدل کمک می‌کرد شیوه پاسخ‌دادن به سؤال مشخص شود و مدل دیگری با هدفی در تقابل با آن، نقش اعتبارسنج را داشت؛ یعنی استفاده از الگوهای زبانی بزرگ (LLM) در نقش داور.

این موضوع سؤال دیگری پیش آورد: چه کسی داور را می‌آزماید؟ طراحی اعتبارسنج، خودش یک مسئله ارزیابی بود. Codex به تیم کمک کرد کارهایی مانند تولید آزمون‌های ارزیابی و به‌روزرسانی سیستم را سریع‌تر انجام دهد، اما ساخت سریع‌تر، نیاز به قضاوت و اعتبارسنجی را از بین نبرد.

زودتر برای پایش اثربخشی مدل در محیط عملیاتی سرمایه‌گذاری می‌کنم.

معیارهای سنتی زیرساخت، مانند تأخیر P99، همچنان مهم‌اند، اما کافی نیستند. اثربخشی مدل را هم باید در محیط عملیاتی پایش کنید.

اول اینکه میان توانایی‌های فناوری و واقعیت درون یک سازمان، فاصله زیادی وجود دارد. اگر شرکت شما نتوانسته با معرفی تک‌تک مدل‌های پیشرو همگام شود، تنها نیستید.

دوم اینکه همواره بر نتیجه تمرکز کنید، نه صرفاً بر فعالیت. به‌راحتی ممکن است جنب‌وجوش ظاهری را با پیشرفت واقعی اشتباه بگیرید، به‌ویژه وقتی شرکت‌ها بر سنجه‌های ورودی تأکید می‌کنند. مثلاً تعداد خطوط کد تولیدشده نشان نمی‌دهد که آیا ارزش واقعی ایجاد کرده‌اید یا نه.

در نهایت، بیشتر سازمان‌ها میزان مهارت و اختیار عمل انسانیِ لازم را دست‌کم می‌گیرند. نمی‌توان صرفاً به یک برنامه عمومی آموزش مهارت بسنده کرد. مدیران به افرادی نیاز دارند که بتوانند این ابزارها را با قضاوت درست به کار بگیرند. ابزاری مثل Codex را به یک مهندس توانمند بدهید تا تأثیر کارش چند برابر شود؛ اما بدون قضاوت درست برای اعتبارسنجی سیستم‌های عملیاتی، ریسک هم چند برابر می‌شود.

موشکی در اختیار دارید. به‌ویژه در سیستم‌های عملیاتی، به اعتبارسنجی و ضوابط ایمنی نیاز دارید و باید کنترل را به افراد مناسب بسپارید.