OpenAI تشرح إعادة هيكلة WebRTC وراء محادثات الصوت الأسرع

يبدو الذكاء الاصطناعي الصوتي طبيعيًا فقط عندما تختفي الشبكة

نشرت OpenAI نظرة نادرة على مستوى البنية التحتية حول كيفية تقديمها لذكاء اصطناعي صوتي منخفض الكمون على نطاق عالمي، موضحةً إعادة تصميم لبنية WebRTC لديها لدعم تفاعلات الكلام في الوقت الحقيقي عبر منتجات تشمل صوت ChatGPT وRealtime API وسير عمل الوكلاء الذي يحتاج إلى معالجة الصوت بينما لا يزال المستخدم يتحدث.

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

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

لماذا يهم WebRTC لمنتجات الذكاء الاصطناعي

يؤكد منشور OpenAI أن WebRTC لا يزال أساسًا عمليًا لذكاء اصطناعي صوتي من العميل إلى الخادم لأنه يوحد الأجزاء الصعبة من تقديم الوسائط التفاعلية. ويشمل ذلك إنشاء الاتصال والعبور عبر NAT باستخدام ICE، والنقل المشفر عبر DTLS وSRTP، والتفاوض على برامج الترميز، وضبط الجودة عبر RTCP، وقدرات من جانب العميل مثل إلغاء الصدى وتخزين اهتزاز الحزم.

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

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

قيود التوسع التي فرضت إعادة التصميم

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

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

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

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

الكمون أصبح الآن ميزة في المنتج

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

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

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

ما الذي تشير إليه هذه الإفصاحات

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

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

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

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

هذه المقالة مبنية على تقرير من OpenAI. اقرأ المقال الأصلي.