في الذكاء الاصطناعي الصوتي، معرفة متى ينبغي التحدث أصعب مما تبدو. يتبادل البشر دفة الحديث بسلاسة في جزء من الثانية، لكن أنظمة الذكاء الاصطناعي الصوتية السابقة لم تستطع مجاراة هذا الإيقاع. اعتمدت بنيتها القائمة على الأدوار على نماذج صغيرة تُعرف بكاشفات الأدوار، وكانت مهمتها شاقة: إن خمّنت مبكرًا قاطعت المستخدم، وإن تأخرت بدا الرد بطيئًا. ولم يكن النموذج اللغوي الكبير (LLM) الأكبر بكثير يبدأ العمل إلا بعد أن يتخذ الكاشف قراره.
يزيل GPT‑Live، نظامنا الصوتي من الجيل الثالث، كاشف الأدوار من مسار الصوت. نموذجه الصوتي ثنائي الاتجاه بالكامل، ما يعني أنه يستطيع الاستماع والتحدث في الوقت نفسه. يلغي ذلك الحاجة إلى كاشف منفصل ويجعل المحادثة أكثر فورية وطبيعية. وعند الحاجة إلى استدلال أعمق أو استخدام الأدوات، يستطيع GPT‑Live أيضًا الرجوع إلى نماذجنا الرائدة، مثل GPT‑5.5، من دون مقاطعة تدفق المحادثة. تمنح هذه القدرات مجتمعةً GPT‑Live مزيجًا غير مسبوق من سرعة الاستجابة في المحادثة ومستوى الذكاء.
تطلب تقديم هذه التجربة على نطاق واسع بنية نظام جديدة محسّنة لانخفاض زمن الاستجابة. بخلاف استدلال الطلب والاستجابة المعتاد، يبث نظامنا الصوت الوارد إلى النموذج الصوتي والكلام الصادر إلى المستخدم، بينما يعالج التفويض عبر مسار غير متزامن منفصل. خلال الأشهر الستة الماضية، أعدنا تصميم استدلال النموذج وإدارة السياق ونقل الوسائط للحفاظ على سلاسة تدفق الكلام من البداية إلى النهاية.
وتنشئ البنية أيضًا حدًا واضحًا بين المسار الصوتي الأساسي ومنطق التطبيق. يسهّل ذلك تخصيص سلوك التطبيق من دون التأثير في سرعة الاستجابة. يشغّل هذا الأساس مجموعة متنامية من قدرات ChatGPT الصوتي، ومنها القدرة المطروحة حديثًا على التحكم في حاسوبك وتنسيق وكلائك في تطبيق ChatGPT لسطح المكتب.
سنوضح في هذا المنشور لماذا لم تلبِّ الأنظمة السابقة القائمة على الأدوار احتياجاتنا، وكيف صممنا النظام الجديد لسرعة الاستجابة في كل طبقاته. سنتناول الاستدلال ذا الحالة، والإدارة الديناميكية للسياق، والتفويض غير المتزامن، والتحسين على مستوى البروتوكول؛ وهي تعمل معًا ليبدو GPT‑Live حيًا بحق.
ورثت البنى الصوتية السابقة طبيعة النماذج اللغوية الكبيرة (LLM) النصية القائمة على الأدوار، لكن كل دور كان يُمثّل بكتلة صوتية منفصلة بدلًا من النص. في الأنظمة المتسلسلة، كانت عمليات تحويل الكلام إلى نص، والنموذج اللغوي الكبير (LLM)، وتحويل النص إلى كلام تعمل بالتتابع. زاد هذا التسلسل زمن الاستجابة وتجاهل إشارات مثل نبرة الصوت ووتيرته.
حسّنت نماذج تحويل الكلام إلى كلام هذا النهج بمعالجة الصوت مباشرةً. أتاح تدريب النموذج على فهم الكلام وتوليده مباشرةً الحفاظ على تفاصيل تضيع في النسخ النصي والاستجابة بسرعة أكبر. لكن النظام ظل يعتمد على كاشف الأدوار لتحديد متى يمكن أن يبدأ الاستدلال. تولى النموذج جانبًا أكبر من التفاعل، لكن التفاعل ظل قائمًا على الأدوار.
يضع GPT‑Live النموذج الصوتي في زمام المحادثة: يتدفق الصوت إلى النموذج ومنه، بينما يجري الاستدلال الأعمق واستخدام الأدوات بصورة غير متزامنة. مهمة النظام الأساسية هي الحفاظ على حلقة وسائط بلا انقطاع. أما الأعمال الأخرى، مثل استدعاء النماذج الرائدة وحفظ المحادثة، فتجري خارج المسار الحي.
ليس من السهل دائمًا إبقاء حلقة الوسائط هذه بلا انقطاع. قد يتحول أي تأخير في النقل أو المعالجة أو الاستدلال إلى توقف مسموع أو تشوّه صوتي. كان النظام السابق القائم على الأدوار يتحمل بعض التفاوت في توقيت وصول كتلة صوتية. لكن نظام الوسائط الحية يحتاج إلى تسليم كل إطار صوتي في موعده.
وفّر لنا عملنا السابق على ChatGPT الصوتي وRealtime API أساسًا مهمًا. كنا قد أعدنا بناء بنيتنا التحتية الصوتية لبث الصوت والفيديو مباشرةً إلى أنظمتنا ومنها بزمن استجابة أقل وأكثر قابلية للتنبؤ. دفع GPT‑Live هذا التصميم إلى مدى أبعد، إذ بث الوسائط حتى النموذج عبر نظام استدلال جديد ذي حالة، مصمم للمحادثة المستمرة.
لكن الاستدلال المتدفق لم يكن سوى جزء من الحل. ولكي يعمل بكفاءة في بيئة الإنتاج، كان علينا أيضًا ضمان موثوقية تسليم الصوت من العميل إلى منظومة الاستدلال ومعالجة تحديات الاحتفاظ بالحالة.
كان من قراراتنا المبكرة فصل تدفق الوسائط تحديدًا عن منطق التطبيق والأعمال. ينتقل الصوت بين العميل والنموذج الصوتي عبر مسار سريع مخصص. يجري التفويض واستخدام الأدوات وأعمال التطبيق الأخرى خلف حد RPC غير متزامن. قد تؤخر أداة بطيئة أو خدمة خلفية نتيجتها، لكنها لا تستطيع إيقاف تدفق الوسائط.
ويمنح هذا الفصل النظام أيضًا حدًا واضحًا للتخصيص. يمكن للتطبيقات تغيير أدواتها وسياساتها وسلوك أنظمتها الخلفية من دون التأثير في الواجهة الأمامية للوسائط المسؤولة عن استمرار تدفق الصوت. يظل المسار الحي صغيرًا وقابلًا للتنبؤ ومركّزًا على العمل الواجب تنفيذه آنيًا.
كتبنا الواجهة الأمامية للوسائط ومنطق الاستدلال بلغة Go، بدلًا من تطبيق Python السابق القائم على asyncio. حسّن ذلك سلاسة تسليم الإطارات بدرجة كبيرة، إذ أصبح المئين 95 في النظام الجديد مساويًا للمئين 50 في النظام السابق.
يوفّر WebRTC أساس النقل. فهو مصمم لوسائط منخفضة زمن الاستجابة، ويمكنه مواصلة العمل رغم فقدان الحزم وانحراف الساعة وتغيرات اتصال العميل. إذا وصلت الحزم متأخرة، يستطيع WebRTC تمديد الصوت قليلًا لمنع الفجوات، ثم تسريع التشغيل لفترة وجيزة للحاق بالوقت الفعلي.
ومن خلال تقليل التخزين المؤقت والحظر في أنحاء النظام، يمكننا توفير استجابة في أقل من ثانية كما يتوقع البشر من المحادثة.
للاستدلال ذي الحالة مقايضاته التشغيلية الخاصة. قد تظل الجلسة الصوتية نشطة طويلًا، لكن سياقها ينمو باستمرار، وتبدأ مثيلات النموذج وتتوقف وفقًا للطلب.
لمعالجة هذه المسائل، أنشأنا آلية تسليم سلسة بين مثيلات النموذج. عند الحاجة إلى انتقال، يمكننا تهيئة مثيل نموذج بديل إلى جانب المثيل الحالي، وتعبئته مسبقًا بسياق الجلسة الراهن، وتشغيل الاستدلال على كليهما بالتوازي، ثم التحويل حين يصبح المثيل الجديد جاهزًا تمامًا.
وتدعم الآلية الأساسية نفسها أيضًا تكثيف السياق الديناميكي. مع استمرار المحادثة، قد يتجاوز سياقها المتراكم في النهاية حد سياق النموذج. يمكن لتكثيف السياق تقليص حجمه ليلائم الحد، لكن العملية تستغرق وقتًا. ولأنه يغيّر السياق السابق، فإنه يبطل أيضًا ذاكرة التخزين المؤقت للمفاتيح والقيم (KV) في النموذج، التي تخزّن مفاتيح وقيم الانتباه من الرموز التي عولجت سابقًا. تتطلب إعادة بناء تلك الحالة تعبئة مسبقة جديدة، ما يضيف مزيدًا من التأخير.
وبدلًا من ذلك، نتعامل مع تكثيف السياق بوصفه انتقالًا آخر مُدارًا. بينما يواصل مثيل النموذج الأصلي المحادثة، يكثّف النظام السياق ويجهز مثيلًا بديلًا بالسياق الجديد. بمجرد أن يصبح ذلك المثيل جاهزًا، يمكننا التحويل إليه من دون أي انقطاع في الوسائط. يتيح ذلك للنظام دعم المكالمات الطويلة، مع تكثيف السياق عند الحاجة.
تبقى الأعمال الثقيلة خارج المسار الحي، فلا تفقد المحادثة إيقاعها حتى أثناء التسليم.
تمنح قدرة GPT‑Live على استدعاء النماذج الرائدة الحالية قوة كبيرة، إذ تفصل عمليًا «التحدث» عن «التفكير» الأعمق. لكن جعل هذه البنية ثنائية النموذج تبدو كنظام واحد تطلّب حل مشكلتين هندسيتين مترابطتين.
التفويض للعمل الأعمق
يوفر GPT-Live استجابات سريعة وطبيعية، بينما يتولى GPT-5.5 عمليات البحث في الخلفية
أولًا، يجب أن تعود النتائج بسرعة تكفي لتفيد الحوار الجاري، لذلك كان علينا تقليل زمن الاستجابة عبر مسار التفويض بأكمله، من التوجيه ومعالجة المطالبة إلى الاستدلال واستدعاءات الأدوات. وفي الوقت نفسه، لا تزال أنظمة أخرى في المنتج تحتاج إلى رسائل منفصلة، لذا كان علينا تمثيل المحادثة الجارية بصيغة يمكنها فهمها.
عند إرسال تفويض، نحسّن الزمن حتى ينتج النموذج الرائد شيئًا مفيدًا للمحادثة. يمكن للنموذج الصوتي إبقاء الحوار جاريًا لفترة وجيزة بينما يستدل نموذج رائد أو يستخدم الأدوات، لكنه لا يستطيع إخفاء استجابة بطيئة بلا حدود. لذلك اعتبرنا حلقة التفويض الكاملة — التوجيه ومعالجة المطالبة والاستدلال واستدعاءات الأدوات — جزءًا من ميزانية سرعة الاستجابة.
أول تحسين هو إعداد النموذج الرائد وأي أدوات يحتاج إليها قبل طلب التفويض. عند بدء جلسة صوتية، ينشئ خادم التطبيق جلسة استدلال للنموذج الرائد ويعبئها مسبقًا بسياق المحادثة الأولي، لضمان اكتمال معالجة المطالبة قبل أول طلب مفوّض.
ثم نبقي جلسة الاستدلال متاحة طوال المحادثة الصوتية ونستخدم ثباتًا مستقرًا للجلسة في الطلبات المتعاقبة. تعمل هذه الأساليب، إلى جانب التخزين المؤقت للمطالبة، على تحسين زمن الاستجابة مع إبقاء التعافي من تعطل أحد العمال سهلًا.
يؤثر جهد الاستدلال وحدود المخرجات ومخططات الأدوات والرحلات ذهابًا وإيابًا بين النموذج والأداة أيضًا في توقيت تلقي المحادثة نتيجة مفيدة، وقد عدّلنا هذه العوامل لتسريع الاستجابات. ومن خلال تقليل العمل اللازم في مسار التفويض، مكّنا النموذج الصوتي من دمج نتائج نماذجنا الرائدة بسرعة.
رغم أن النموذج الصوتي يعمل على تدفقات كلام مستمرة، لا تزال أنظمة كثيرة حوله تعمل وفق أدوار المستخدم والمساعد، ومنها واجهة محادثة ChatGPT وأجزاء من بنيتنا التحتية للتحليلات والسلامة. لذلك يفكك خادم التطبيق المحادثة المتداخلة والملتبسة أحيانًا إلى رسائل منفصلة.
مع وصول الصوت، يستخدم الخادم نصوصًا جزئية وإشارات توقيت لاستنتاج المتحدث الذي يملك دفة الحديث وبناء طابور من الرسائل. تظل الرسالة الأحدث مؤقتة؛ إذ قد يتغير نصها وتوقيتها والمتحدث المنسوبة إليه مع وصول مزيد من الكلام. حين يستأثر متحدث بالكلام مدة تكفي لضمان موثوقية الإسناد، يثبّت الخادم الرسالة المقابلة.
يزيد تداخل المتحدثين الأمر تعقيدًا. لا ينبغي بالضرورة أن يصبح إقرار وجيز من المساعد أثناء حديث المستخدم (مثل “mm hmm,” أو “okay”) رسالة مستقلة. لكن غالبًا ما ينبغي أن تصبح مداخلة المساعد الجوهرية كذلك. وبالمثل، نعطي الأولوية لتماسك ردود المساعد المعروضة حتى عندما يتحدث المستخدم في منتصفها.
توازن كل سياسة لتقسيم الكلام بين الحداثة واليقين. يؤدي التثبيت المبكر جدًا إلى سجل مجزأ وترتيب غير مستقر، بينما يؤخر الانتظار طويلًا النصوص والميزات المعتمدة عليها. لذلك يحتفظ النظام بمنظورين مترابطين للمحادثة: منظور توقعي للحالة الراهنة وسجل موثوق لما قيل. يمكن لعرض المحادثة في واجهة مستخدم التطبيق التعامل مع التحديثات، لذا يستخدم المنظور التوقعي. لكن التسجيل في مسار التحليلات يتطلب نصًا نهائيًا.
يمنح ذلك بقية ChatGPT عرضًا مستقرًا للحوار من دون فرض تبادل الأدوار على المسار الصوتي الحي.
تبدأ سرعة الاستجابة لحظة نقر المستخدم على الزر. مع GPT‑Live، يجب على النظام إنشاء مسار الوسائط وبدء تمرير الصوت عبر النموذج قبل أن تبدأ المحادثة. وهذا يضع كل جزء من تسلسل بدء التشغيل على المسار الحرج.
كما ذكرنا، يوفر WebRTC أساسًا قويًا للعمل الآني، لكن بدء جلسة WebRTC قياسية يتطلب عددًا كبيرًا على نحو مفاجئ من مصافحات البروتوكولات ورحلات الشبكة ذهابًا وإيابًا. سبق WebRTC التركيز على تقليل الرحلات ذهابًا وإيابًا، وهو ما شكّل بروتوكولات لاحقة مثل QUIC. ونتيجة لذلك، تكرر بروتوكولاته الأساسية أحيانًا العمل عند استخدامها معًا. فمثلًا، تضمّن كل بروتوكول آليته الخاصة لمكافحة هجمات حجب الخدمة، حتى حين لا تكون مطلوبة ضمن منظومة WebRTC الكاملة.
حللنا المنظومة وطوّرنا بروتوكول WebRTC المختصر للرحلات ذهابًا وإيابًا (WARP(يفتح في نافذة جديدة))، الذي يقلص بدء تشغيل الوسائط والبيانات من ست رحلات شبكية إلى رحلة واحدة فقط. يحقق WARP ذلك بمجموعة من تحسينات البروتوكول المتوافقة مع الإصدارات السابقة: تحميل مصافحة DTLS على ICE (SPED(يفتح في نافذة جديدة))، واستخدام مصافحة DTLS 1.3(يفتح في نافذة جديدة) الأسرع، والتفاوض المسبق على مصافحة SCTP (SNAP(يفتح في نافذة جديدة))، والتفاوض المسبق على قنوات البيانات بدلًا من استخدام DCEP(يفتح في نافذة جديدة).
صممنا WARP كمجموعة من المواصفات المفتوحة، بالتعاون مع مساهمين من مجتمع WebRTC، كي تستفيد المنظومة الأوسع من هذا العمل. نعمل على تطوير المقترحات عبر مجموعة عمل TSVWG التابعة لـ IETF، وقد أُضيف دعم WARP بالفعل إلى كل من libwebrtc وPion، فيما تتواصل الجهود في تطبيقات WebRTC الأخرى.
بعد تحسين مصافحة الوسائط، برز تأخير متبقٍ: تبادل الإشارات المستخدم لمشاركة معاملات SDP قبل أن يتمكن WebRTC من الاتصال. لإزالة ذلك التبادل من المسار الحرج، طوّرنا ما نسمّيه Instant Connect. يتفاوض على هذه المعاملات مسبقًا من دون حجز سعة الخادم ومن دون أي تغييرات في تطبيقات WebRTC الحالية.
يعمل Instant Connect بالتوازي مع تدفق الإشارات القياسي. إذا كانت المعاملات المتفاوض عليها مسبقًا صالحة، يمكن للخادم إنشاء الجلسة عند وصول أول حزمة وسائط. وإذا كانت قديمة أو غير صالحة، يكون تدفق الإشارات قد بدأ بالفعل، فيستطيع العميل الرجوع إليه من دون زمن استجابة إضافي.
يقلص Instant Connect وWARP معًا بدرجة كبيرة الزمن بين نية المستخدم وبدء تدفق الوسائط الحية. بعد إخراج تبادل SDP من المسار الحرج واختزال WARP لمصافحة النقل، يستطيع العميل الآن بدء جلسة بحزمة UDP واحدة. يستطيع الخادم الاستجابة فورًا، ما يتيح لبقية النظام بدء العمل الذي يهم المستخدم فعلًا: الاستماع والرد.
قد يبدو النظام سريعًا نظريًا، لكنه قد يتعطل تحت ضغط حركة صوتية حقيقية. قبل السماح لـ GPT‑Live بالتحدث مع المستخدمين، أجرينا اختبارًا صامتًا وجّهنا فيه نسبة صغيرة ومتزايدة تدريجيًا من جلسات ChatGPT الصوتي في بيئة الإنتاج إلى كل من تجربة وضع الصوت المتقدم الحالية ونظامنا الجديد. واصل وضع الصوت المتقدم خدمة المستخدمين كالمعتاد، بينما شغّل المسار الموازي الاستدلال في وضع القراءة فقط. عرّض ذلك النظام لعملاء وشبكات ومدد جلسات وتوزيعات جغرافية حقيقية، من دون تغيير ما يسمعه المستخدمون.
كان من أول الدروس أن السعة لا يمكن اختزالها في إنتاجية وحدات معالجة الرسومات. تظل الجلسات الصوتية مفتوحة وترسل الإطارات باستمرار، لذا يجب توسيع نطاق معالجات التدفقات وطوابير الانتظار ومسارات الشبكة على جانب وحدة المعالجة المركزية بالتوازي مع الاستدلال. تحت الحمل الحقيقي، بلغ أحد المكونات الداعمة حد التشبع قبل ما توقعته تقديرات اختبار الحمل، فتراكمت طلبات الاستدلال وتفاقم زمن الاستجابة. غيّرنا سؤال السعة من «كم طلبًا تستطيع وحدة معالجة الرسومات التعامل معه؟» إلى «كم جلسة متزامنة يستطيع النظام دعمها مع إبقاء كل إطار في موعده؟»
جعل الاختبار أيضًا الموقع الجغرافي اعتبارًا أساسيًا. قد يضيف توجيه جلسة إلى سعة بعيدة تأخيرًا عند نقاط عدة أثناء بدء التشغيل والبث. بدأنا التحقق من عمليات طرح النموذج بالتزامن مع السعة الإقليمية وإعدادات توجيه الحركة، ثم تحليل زمن الاستجابة حسب الموقع الجغرافي للمصدر. ساعد تقريب الاستدلال من المستخدمين، لكنه رسّخ أيضًا درسًا أوسع: تعتمد سرعة الاستجابة الشاملة على كل خدمة في المسار، لا على خادم النموذج وحده.
ولم تظهر أعطال أخرى إلا خلال دورات حياة واقعية للجلسات. كشفت الجلسات الطويلة عن ضغوط على الذاكرة واستمرارية البيانات. اختبرت عمليات إعادة الاتصال تكثيف السياق واستعادة الحالة. كشفت حالات انقطاع اتصال العميل العادية عن حالات تسابق في مصافحة إيقاف التشغيل. نادرًا ما ظهرت هذه المشكلات في اختبارات الحمل القصيرة، لأنها اعتمدت على الوقت والحالة المتراكمة والسلوك عبر حدود الخدمات.
وأخيرًا، أجبرنا الاختبار في بيئة الإنتاج على تحسين قابلية الرصد وضوابط الطرح. وجدنا مقاييس تخلط بين مصادر مختلفة لزمن الاستجابة، ولوحات معلومات تخفي بياناتها المجمعة محركات منفردة معطلة، وانحرافًا في الإعدادات بين الأنظمة المختبرة والمنشورة. استجابةً لذلك، أضفنا قياسًا عن بُعد أكثر تفصيلًا، وتحققًا مقارنةً بإعدادات معروفة بسلامتها، وزيادات مرحلية، وإمكانية عزل المسارات المنفردة أو تعطيلها سريعًا. أصبح الاختبار الصامت بروفة مبكرة للإطلاق، لا لاختبار حجم الحركة التي يستطيع النظام قبولها فحسب، بل أيضًا لمدى سرعة اكتشاف الأعطال واحتوائها والتعافي منها.
تطلب توسيع GPT‑Live إلى نطاق ChatGPT بناء نظام جديد بالكامل حول مبدأ أساسي واحد: يجب أن يظل الصوت متدفقًا. يبقي الاستدلال المتدفق النموذج ثنائي الاتجاه مزوّدًا بالصوت. يضمن مسار وسائط مخصص تسليم الإطارات بموثوقية. يتيح التفويض غير المتزامن إجراء التفكير الأعمق بالتوازي. يحافظ النقل المحسّن على سرعة استجابة التجربة حتى وصولها إلى المستخدم.
بدأت البنية التي تقف وراء GPT‑Live تتحول بالفعل إلى منصّة أوسع للتفاعل الآني. وهي تشغّل ChatGPT الصوتي مع توسعه من المحادثة إلى تنسيق الوكلاء، وستشكّل أساس واجهة GPT‑Live API المقبلة. ومع مرور الوقت، ستتيح امتداد التجارب الصوتية إلى مزيد من الأجهزة والتطبيقات والوسائط من دون التضحية بالفورية التي تجعل المحادثة الصوتية تبدو حية.
إذا كانت هذه من نوعية المشكلات الهندسية التي تود حلها، فانضم إلى فريقنا.
