وضع WebSocket من OpenAI يغيّر قواعد اللعبة في الذكاء الاصطناعي الصوتي

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

ولفهم حجم هذا التغيير، لا بد من معرفة كيف كان وكلاء الذكاء الاصطناعي الصوتيون يعملون حتى الآن. كانت البنية الكلاسيكية أشبه بخط إنتاج من ثلاث محطات منفصلة. أولًا، يُرسَل صوت المستخدم إلى نموذج التعرّف على الكلام (Speech-to-Text)، الذي يحوّله إلى نص.

ثم يُمرَّر هذا النص إلى نموذج لغوي كبير مثل GPT لتوليد الرد. وأخيرًا، يذهب الرد النصي إلى نظام تركيب الكلام (Text-to-Speech) الذي ينطقه صوتيًا. وكل انتقال من هذه الانتقالات يعني طلب API مستقلًا واتصال شبكة مستقلًا وطابورًا مستقلًا على الخادم.

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

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

وقد أصبح ذلك ممكنًا تقنيًا بفضل عدة عوامل. أولًا، أصبحت نماذج OpenAI نفسها متعددة الوسائط بالأصل، فـGPT-4o وخلفاؤه قادرون على التعامل مع الصوت مباشرة دون نسخ نصي وسيط. ثانيًا، يدعم بروتوكول WebSocket، خلافًا لـHTTP التقليدي، الاتصال ثنائي الاتجاه الكامل (full-duplex)، إذ يمكن نقل البيانات في الاتجاهين في وقت واحد، وهو ما يلائم محاكاة الحوار الطبيعي تمامًا. ثالثًا، يتيح التوليد المتدفق بدء تشغيل الرد قبل أن ينتهي النموذج من صياغته، تمامًا كما يبدأ الإنسان بسماع محدّثه من المقطع الأول، ولا ينتظر حتى يكمل الجملة بأكملها.

يصعب المبالغة في تقدير تبعات ذلك على القطاع. فقد ظلت الواجهات الصوتية حتى اليوم منتجًا محدود الانتشار، ويعود ذلك إلى حد بعيد إلى مشكلة التأخير تحديدًا. فـSiri وAlexa وGoogle Assistant تعاني جميعها من توقفات ملحوظة تجعل الحديث غير طبيعي. ويفتح خفض التأخير إلى مستوى قريب من الزمن الفعلي الباب أمام سيناريوهات جديدة كليًا: طب عن بُعد بمساعد ذكي يتفاعل فورًا مع كلام المريض، وتطبيقات تعليمية يجري فيها معلّم خصوصي يعمل بالذكاء الاصطناعي حوارًا حيًا دون توقفات مزعجة، وشخصيات غير لاعبة (NPC) في الألعاب ترد بسرعة الممثل الحي، ومراكز اتصال مؤسسية لا يمكن فيها تمييز موظف الذكاء الاصطناعي عن الإنسان من حيث سرعة الاستجابة.

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

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

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