انتقل Rutube من تجربة Whisper إلى منصة الترجمة والتعرف على الكلام الخاصة به

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

لماذا لم تكن Whisper كافية

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

بين "التعرف على الكلام" و"توفير الترجمات النصية لجميع المحتوى" يوجد

قدر هائل من العمل. كان هذا الفجوة بالذات هو الاستنتاج الرئيسي للفريق.

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

ما أصبحت عليه النظام

في النهاية، توقفت المهمة عن أن تكون "خدمة قائمة على ASR أخرى" وأصبحت منصة ترجمة نصية متكاملة. تكتب Rutube أنه لتحقيق ذلك، اضطروا إلى الانتقال إلى هندسة الخدمات الدقيقة والنظام الخاص بهم للتعرف على الكلام. كان هذا النهج ضرورياً ليس من أجل اتباع الاتجاهات التكنولوجية الموضة، بل من أجل فصل المسؤوليات: يتولى جزء من النظام استقبال الفيديو وتحضيره، وآخر يتولى التعرف نفسه، والثالث يتولى تجميع النتيجة وتسليمها. في الحجم الكبير، هذا أمر حرج لأنه يسمح بتوسيع المكونات الفردية بشكل مستقل ويمنع انهيار خط الأنابيب بسبب الحمل الزائد في مكان واحد.

لمثل هذه المنصة، عدة متطلبات مهمة في نفس الوقت:

• قبول تدفق من ملايين مقاطع الفيديو الجديدة بدون تدخل يدوي
• معالجة مقاطع الفيديو التي تصل مدتها إلى 24 ساعة بدون انهيار خط الأنابيب
• العمل مع لغات غير معروفة والصوتيات المشوشة التي ينشئها المستخدمون
• الحفاظ على جودة النص الكافية للنشر
• البقاء ضمن قيود السرعة وتكلفة المعالجة

الانتقال إلى ASR الداخلي يبدو منطقياً في هذا السياق. عندما يعمل المنتج على UGC بكميات ضخمة، يساعد النموذج الخارجي العام على البدء، لكنه لا يناسب تحسين الضبط للبيانات الفعلية وقيود البنية الأساسية والمقاييس المستهدفة. نظام خاص بك يعطيك المزيد من التحكم في السرعة والجودة والموارد والطريقة التي يتصرف بها التعرف على الحالات الحدية التي تصبح معيار لمنصة فيديو، وليست استثناء.

كيف حققوا السرعة

الرقم الأكثر لفتاً للانتباه في قصة Rutube هو إنتاجية حوالي 1200 مقطع فيديو في الساعة الواحدة لكل instance ASR. هذا مؤشر مهم لأنه في الإنتاج، لا يمكن النظر إلى جودة التعرف بشكل منفصل عن الإنتاجية. إذا أنتج النظام نصاً جيداً لكن تراكمت قائمة انتظار من آلاف مقاطع الفيديو، فإن المستخدم يحصل على فائدة قليلة. إذا كان خط الأنابيب يعمل بسرعة لكنه غير مستقر على مقاطع الفيديو الطويلة أو الصوت السيء، فإن المنتج ينهار في الاستخدام الفعلي. لذا فإن الهندسة هنا مهمة بقدر أهمية النموذج نفسه.

وراء هذا الرقم لا يقف خوارزمية ناجحة واحدة، بل سلسلة من الحلول الهندسية: كيفية تقطيع وتقديم الصوت، كيفية توزيع المهام، كيفية تجنب إضاعة الوقت على المراحل غير الفعالة، وكيفية الحفاظ على الموارد تحت السيطرة. الجانب الاقتصادي مهم أيضاً. كلما زادت الإنتاجية لكل instance ASR، كان من الأسهل توسيع الخدمة بدون نمو انفجاري لتكاليف البنية الأساسية. بالنسبة للمنصات التي تتمتع بتدفق مستمر من UGC، هذا لم يعد مسألة راحة بل اقتصاديات أساسية للمنتج.

ما يعنيه هذا

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