JioStar تطلق مساعدًا صوتيًا بأكثر من 15 لغة خلال 8 أسابيع: الرهان على التقييمات (evals)

عندما يزيد عدد مستخدميك على 500 مليون ويصل عدد المشاهدين المتزامنين للرياضة المباشرة إلى 72.5 مليونًا، فإن عبارة «في العرض التجريبي كان كل شيء يعمل» لا تعني شيئًا. يجب أن يجيب المساعد بسرعة، وألا يختلق، وألا يستنزف الشركة في تكاليف الاستدلال. تحدث فيجاي شيشادري، كبير المعماريين (Chief Architect) في JioStar، في قمة OpenAI بسنغافورة عن كيفية قطع فريقه هذا الطريق. نُشرت المقابلة على مدونة OpenAI، لكن الدروس الهندسية فيها أكثر من الدعاية.

ما الذي بُني ولماذا لم تكفِ التوصيات المعتادة

أضافت JioHotstar مساعدًا حواريًا يعمل على OpenAI API. يقول المشاهد ما يريد مشاهدته ويحصل على الجواب بصيغة مرئية. يسمي شيشادري ذلك voice-visual interface: فاختيار المحتوى مرئي في جوهره، لكن شرح المزاج أو الذوق بالصوت أسهل من النقرات.

مثال من المقابلة: «أنا حزين، أرني شيئًا يرفع معنوياتي». نظام التوصية القائم على سجل المشاهدة لن يفهم أي نوع من الحزن هذا، ولا ما الذي يساعد هذا الشخص عادةً. أما في الحوار فيمكن طلب التوضيح.

والطلبات متنوعة جدًا:

• ترفيهية: «اليوم جمعة، فاجئني» أو وصف فيلم دون ذكر اسمه؛
• رياضية: سلسلة ستات (sixes)، سقوط الويكيتات، مباراة سجّل فيها لاعب عددًا معينًا من النقاط؛
• خبيرة: إحصاءات لكل كرة.

جُمع كل ذلك في واجهة واحدة، بأكثر من 15 لغة، في نحو ثمانية أسابيع. وكان الموعد النهائي بطولة كريكت كبرى في فبراير. أكثر من 60% من المستخدمين يفضلون الصوت على النص.

كيف بُني: الحدود والتقييمات (evals) و«حكم الحكم»

منذ البداية نُظر إلى المهمة على أنها مثلث «الدقة — زمن الاستجابة — التكلفة». وكان كل قرار هندسي يحرّك رؤوس المثلث الثلاثة معًا.

ترتيب العمل لافت. فقد قرر الفريق أولًا ما الذي يجب ألا يجيب عنه المساعد. الواجهة الصوتية تتيح السؤال عن أي شيء، لذا كانت guardrails الخطوة الأولى لا «ما بعد الإطلاق».

ثم جاءت التقييمات (evals). أخذوا مجموعة أسئلة أولية صغيرة ووسّعوها بمساعدة النماذج. لكنهم لم يبدؤوا بالـ prompt، بل بالخبرة البشرية: ففي الإحصاءات الرياضية استعانوا بمحرري مجلات رياضية يعرفون ما سيسأل عنه المشجعون الحقيقيون.

ولجودة الإجابات استخدموا مخطط maker-checker. نموذج يقرر كيف يجيب عن السؤال، وآخر يتحقق من الإجابة بصفته حكمًا من نوع LLM، وهدفه معاكس. ويطرح شيشادري فورًا السؤال التالي: من يراجع الحكم؟ فالمدقق نفسه يصبح موضوع تقييم، ولا يمكن تجاوز هذا العمل.

سرّع Codex توليد حالات التقييم وتحديث النظام. لكن بحسب شيشادري، لا يلغي التجميع السريع الحاجة إلى الحكم والتحقق. عمل فريق صغير من علماء البيانات والمهندسين، وجلس بجانبهم مهندسو forward-deployed من OpenAI.

ما الذي يمكن أخذه من ذلك

الدرس الرئيس عند شيشادري: «evals، evals، ومرة أخرى evals». فالمبتدئون، حسب قوله، يقللون من شأنها حتى عندما يظنون أنهم جاهزون.

الدرس الثاني يخص الإنتاج. نحتاج إلى حلقة تغذية راجعة تتحول فيها سلوكيات المستخدمين والأعطال إلى حالات تقييم جديدة. ويقر شيشادري بأن ضبط هذه الدورة صعب جدًا. وبأثر رجعي، كان سيستثمر مبكرًا أكثر في مراقبة فعالية النموذج: فزمن استجابة P99 مهم، لكنه لا يبيّن هل تفيد الإجابة المستخدم.

الدرس الثالث إداري. ينبغي قياس النتيجة لا النشاط: فعدد أسطر الشيفرة المولّدة لا يدل على القيمة. بالنسبة للمهندس القوي يضاعف Codex المردود، لكن دون مهارة فحص أنظمة الإنتاج يتضاعف الخطر أيضًا. ويصوغ شيشادري ذلك هكذا: في يدك صاروخ، ويجب تسليم المفاتيح للأشخاص المناسبين.

إذا كنت تبني مساعدًا لكتالوج أو دعم أو بحث، فقائمة التحقق قصيرة:

1. حدّد ما لن يجيب عنه النظام.
2. ابنِ مجموعة التقييم الأولية مع خبراء المجال.
3. ضع نموذجًا لغويًا ثانيًا لمراجعة الإجابات، وقيّم هذا المراجِع نفسه على حدة.
4. راقب في الإنتاج جودة الإجابات، لا زمن الاستجابة فقط.

القيود

هذه مقابلة وليست تحليلًا تقنيًا، وقد نشرها المورّد. لا توجد فيها أرقام عن الدقة وزمن الاستجابة وتكلفة الطلب، ولا مقارنة مع البحث السابق، ولا بيانات عن التأثير في التفاعل. كما لم يُكشف كيف صُمم الحكم وبماذا يختلف عن المولِّد. لذلك لا تصلح المادة دليلًا على الفعالية. أما كقائمة بالأولويات الهندسية لإطلاق مساعد في منتج جماهيري فهي مفيدة تمامًا.