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

لماذا بدا النموذج القديم معطلاً

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

ردت OpenAI بهيكلية بدون أدوار (turn-less). ففي كل ثانية، يقرر GPT-Live ما إذا كان سيستمر في الاستماع، أو الاستمرار في التحدث، أو التوقف، مما يتيح لك مقاطعة المساعد في منتصف الرد أو طرح سؤال متابعة دون انتظار دورة استجابة كاملة.

بنية الـ full-duplex بكلمات بسيطة

  1. فصل حلقة الصوت عن مسار الاستنتاج – يتولى المسار السريع (fast path) عملية التبادل الصوتي المستمر، بينما يقوم المسار البطيء (slow path) بتنفيذ المهام الأثقل مثل عمليات البحث في الويب أو استدعاء الأدوات. يحافظ المسار السريع على حيوية المحادثة بينما يعمل المسار البطيء، مما يقضي على لحظة "الصمت أثناء التفكير" المزعجة.
  2. بروتوكول WARP – تتطلب اتصالات الويب التقليدية عمليات مصافحة (handshakes) متعددة قبل أن يتدفق الصوت، وغالباً ما تكون ست رحلات ذهاب وإياب. يقوم بروتوكول OpenAI المخصص بدمج هذه الخطوات في رحلة واحدة، مما يجعل بدء الجلسة يبدو فورياً تقريباً.
  3. استخدام Go بدلاً من Python لضمان اتساق زمن الاستجابة – نقل الفريق المكونات التي تعمل في الوقت الفعلي من Python، التي تُقدر لسرعة تطويرها، إلى Go، التي توفر أوقات تنفيذ أكثر قابلية للتنبؤ. في مجال الذكاء الاصطناعي الصوتي، يهم التأخير في أسوأ الحالات أكثر من متوسط السرعة؛ فالتلعثم الواحد يكسر حالة الاندماج، لذا فإن زمن الاستجابة المتسق هو الأهم.
  4. التوسع لما وراء الـ GPU – مع وجود مئات الملايين من المستخدمين، انتقلت نقطة الاختناق من نوى الحوسبة الخاصة بالنموذج إلى البنية التحتية المحيطة. وجدت OpenAI أن الـ CPUs ووصلات الشبكة تصل إلى حالة التشبع قبل الـ GPUs، لذا أضافوا توجيهاً (routing) وإدارة اتصالات أكثر ذكاءً لإبقاء الـ GPUs تعمل بكفاءة دون إثقال كاهل بقية البنية.

ماذا يعني هذا للمطورين

  • فصل معالجة الصوت عن منطق العمل (business logic) – حافظ على حلقة خفيفة الوزن وتعمل دائماً لمعالجة مدخلات الميكروفون ومخرجات السماعة. قم بنقل أي شيء يمكنه الانتظار — مثل استعلامات قواعد البيانات أو استدعاءات API الخارجية — إلى خيط (thread) أو خدمة منفصلة.
  • إعطاء الأولوية لاستقرار زمن الاستجابة – قم بقياس وقت الاستجابة، مع التركيز على التأخير في أسوأ الحالات بدلاً من مجرد المتوسط. اللغات وبيئات التشغيل التي تمنح تحكماً أدق في الجدولة (مثل Go و Rust) قد تستحق الجهد الهندسي الإضافي.
  • تقليل العبء الإضافي للاتصال – كل عملية مصافحة إضافية تضيف أجزاء من الثانية تتراكم مع الوقت. قم بدمج المصادقة، والتفاوض على البث، واختيار الترميز (codec) في عملية تبادل واحدة، وسوف يلاحظ المستخدمون الفرق.

المقايضات والأسئلة المفتوحة

تصميم الـ full-duplex يضيف تعقيداً.

ما الذي يجب مراقبته لاحقاً