كبير معماريي أنظمة JioStar: اكتشاف المحتوى بـAI لنصف مليار مستخدم
حوار مع فيجاي سيشادري، كبير معماريي الأنظمة في JioStar.
تعرض سلسلتنا Executive Function وجهات نظر قادة يعملون على إحداث تحوّل باستخدام AI.
تدير JioStar منصات للترفيه والبث الرياضي المباشر يستخدمها أكثر من 500 مليون مستهلك، وقد استوعبت ما يصل إلى 72.5 مليون مشاهد للبث الرياضي المباشر في الوقت نفسه. على هذا النطاق، يجب أن يكون AI سريعًا وموثوقًا وجاهزًا للتشغيل الفعلي.
باستخدام واجهة API من OpenAI، طوّرت JioStar مساعدًا لاكتشاف الفيديوهات وإحصاءات الكريكيت عبر المحادثة، ودمجته في JioHotstar. يمكن للمشاهدين التحدث بلغة طبيعية للعثور على أفلام وبرامج ولقطات بارزة من الماضي ولحظات من مباريات مباشرة أو إحصاءات الكريكيت، وتُعرض النتائج ضمن تجربة محادثة بصرية.
في قمة OpenAI للقيادات التنفيذية في سنغافورة، تحدث سيدهارث شارما، رئيس استراتيجية الوصول إلى السوق لدى OpenAI في منطقة آسيان، مع فيجاي سيشادري، كبير معماريي الأنظمة في JioStar، عن تطوير هذه التجربة بأكثر من 15 لغة في نحو ثمانية أسابيع، والدروس المستفادة للقادة الذين ينقلون AI من العرض التجريبي إلى التشغيل الفعلي.
لم تتطور طرق اكتشاف المحتوى إلا قليلًا خلال السنوات الخمس والعشرين الماضية. كانت التوصيات آخر تحول كبير. ومعظم ما تلاها لم يكن سوى تطوير للفكرة نفسها.
لكن اختيار ما نشاهده أمر شخصي للغاية. قد يقول شخص: «أشعر بالحزن. اعرض لي شيئًا يبهجني». حتى هذا الطلب البسيط ينطوي على تفاصيل دقيقة كثيرة. أي نوع من الحزن؟ ما الذي يبهج هذا الشخص عادةً؟ هل يريد عملًا كوميديًا، أم محتوى يبعث على الراحة، أم شيئًا يصرف انتباهه تمامًا؟
قد يصعب على نظام توصيات تقليدي فهم حالته في تلك اللحظة. أما المحادثة فتتيح للمشاهد التعبير عنها. نسمّي هذا واجهة صوتية بصرية.
بدأنا بلورة الفكرة في أكتوبر ونوفمبر، وكانت هناك بطولة كريكيت كبرى مرتقبة في فبراير. كان أمامنا نحو شهرين وجمهوران مختلفان تمامًا: مشاهدو المحتوى الترفيهي وعشاق الكريكيت.
قد يقول مشاهد للمحتوى الترفيهي: «إنها ليلة مساء الجمعة، فاجئني»، أو يصف فيلمًا لا يعرف عنوانه. أما مشاهدو الرياضة فقد يريدون تفاصيل أكثر تحديدًا، مثل لحظات إخراج الضاربين، أو سلسلة من الضربات السداسية، أو المباراة التي سجّل فيها لاعب عددًا معينًا من الركضات. وقد يرغب خبراء الكريكيت في إحصاءات عن كل كرة.
هذه تحديات مختلفة جدًا في اكتشاف المحتوى. عملنا على الجمع بين المحتوى الترفيهي واللحظات الرياضية وإحصاءات الكريكيت التفصيلية في تجربة واحدة، بلغات متعددة، خلال فترة قصيرة جدًا.
منذ البداية، صغنا المسألة باعتبارها مفاضلة بين ثلاثة عوامل: الدقة وزمن الاستجابة والتكلفة. كان على كل قرار هندسي أن يوازن بين العوامل الثلاثة معًا.
وجعل التفاعل الصوتي هذه الموازنة مهمة على نحو خاص. أكثر من 60% من مستخدمينا يستخدمون الصوت بدلًا من النص؛ فالناس يفضّلون التعبير بالكلام عما يريدون مشاهدته. ومع ذلك، يجب أن تظل الاستجابة ملائمة وسريعة ومجدية اقتصاديًا عند تقديمها على نطاق واسع.
أراه مكوّنًا من جزأين: إطار للتقييم وطبقة للتحقق. قبل التشغيل الفعلي، ينبغي أن يدفع إطار التقييم إلى إجراء التعديلات اللازمة. وأثناء التشغيل الفعلي، ينبغي أن تحوّل حلقة التغذية الراجعة سلوك العملاء وحالات الإخفاق إلى حالات تقييم جديدة.
يمكن أن تزداد فاعلية دورة التحسين هذه مع كل جولة، لكن ضبطها بالغ الصعوبة.
لا غنى عن خبراء المجال. لتقييم أداء المساعد في الإجابة عن أسئلة الإحصاءات الرياضية، استعنا بأشخاص مثل محرري المجلات الرياضية ممّن يعرفون ما قد يسأل عنه المشجعون المتابعون للرياضة عن كثب. لا يمكنك البدء بمطالبة وحدها؛ بل تحتاج إلى تزويد النظام بخبرة بشرية عميقة منذ البداية.
كان تشكيل الفريق أحد الأمور التي أحسنّا فيها الاختيار. بدأنا بفريق صغير من علماء البيانات والمهندسين، مع تحديد واضح للمشكلة. وعمل مهندسو OpenAI المنتدبون إلى فريقنا معنا لتحديد عدد محدود من الأولويات بدقة أكبر، وهي الجوانب التي كان لا بد من إتقانها.
كان أولها نطاق عمل النظام. تتيح الواجهة الصوتية أو النصية للمستخدمين طرح أي سؤال تقريبًا، لذا بدأنا بتحديد ما ينبغي للنظام ألّا يجيب عنه. جاءت ضوابط الحماية أولًا.
أما التقييمات، فبدأنا فيها بمجموعة بيانات أولية، واستخدمنا نماذج لتوسيعها وإضافة مزيد من التنوع إليها. أنشأنا ما قد يُسمّى اليوم نمط المُنشئ والمُدقّق: ساعد النموذج الأول في تحديد كيفية الإجابة عن السؤال، بينما تولّى النموذج الثاني التحقق من الإجابة. وكان هذا النموذج الثاني نموذجًا لغويًا كبيرًا (LLM) يؤدي دور الحَكَم وله هدف ينافس هدف النموذج الأول.
وأثار ذلك سؤالًا آخر: من يختبر الحكم؟ كان تصميم أداة التحقق بحد ذاته تحديًا في التقييم. ساعد Codex الفريق على تسريع أعمال مثل توليد حالات التقييم وتحديث النظام، لكن سرعة التطوير لم تُلغِ الحاجة إلى التقدير السليم والتحقق.
كنت سأستثمر في وقت أبكر في مراقبة فعالية النموذج أثناء التشغيل الفعلي.
تظل مقاييس البنية التحتية التقليدية، مثل زمن الاستجابة عند المئين 99 (P99)، مهمة، لكنها لا تكفي. تحتاج أيضًا إلى مراقبة فعالية النموذج أثناء التشغيل الفعلي.
أولًا، هناك فجوة كبيرة بين ما تستطيع التكنولوجيا فعله والواقع داخل المؤسسة. إذا لم تكن شركتك قد واكبت كل إعلان عن نموذج رائد، فهي ليست وحدها.
ثانيًا، واصل التركيز على النتائج بدلًا من حجم النشاط. من السهل الخلط بين النشاط الظاهر والتقدم الحقيقي، خصوصًا حين تركّز الشركات على مقاييس المدخلات. فعدد أسطر التعليمات البرمجية المُولّدة، مثلًا، لا يخبرك ما إذا كنت قد أوجدت قيمة حقيقية.
أخيرًا، تقلّل معظم المؤسسات من تقدير ما يتطلبه الأمر من مهارات بشرية وقدرة على المبادرة واتخاذ القرار. لا يمكن اختزال ذلك في برنامج عام لتنمية المهارات. يحتاج القادة إلى أشخاص يستطيعون استخدام هذه الأدوات بحسن تقدير. امنح مهندسًا متمكنًا أداة مثل Codex، وقد يتضاعف أثر عمله؛ لكن من دون التقدير السليم اللازم للتحقق من أنظمة التشغيل الفعلي، تتضاعف المخاطر أيضًا.
بين يديك صاروخ. تحتاج إلى التحقق وضوابط الحماية، خصوصًا في أنظمة التشغيل الفعلي، وعليك أن تسلّم زمام الأمور إلى الأشخاص المناسبين.
