Heartbeat Thinking تعلّم الوكلاء الصوتيين العمل أثناء حديثك: انخفاض زمن الاستجابة بنسبة −36,4%

تتصرف الوكلاء الصوتيون المزوّدون بأدوات عادةً بالطريقة نفسها: ينهي المستخدم كلامه، وعندها فقط تبدأ فترة الانتظار. يجمع النموذج الوسائط، ويستدعي API، وينتظر الرد، ثم يصوغ جوابه. ورقة بحثية جديدة منشورة في Hugging Face Daily Papers بعنوان Heartbeat Thinking تحاول استغلال هذا الوقت. وعلى الاختبار المعياري FDBench v3 رفع هذا النهج تغطية الأدوات 16 نقطة مئوية، وخفّض متوسط زمن الرد النهائي بنسبة 36,4% مقارنة بالمخطط الأساسي على طراز SHANKS.

لماذا ينهار التشغيل الاستباقي في منتصف الجملة

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

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

كيف تعمل «نبضات القلب»

يغيّر المؤلفون منطق معالجة التحديثات. فالمقطع الجديد من الكلام لا يلغي العمل الجاري، بل يطلق استدعاء Thinker مستقلًا. أما الاستدعاءات الجارية والأدوات التي أُرسلت بالفعل فتُكمل عملها بهدوء. يبدأ Thinker بشكل دوري، كالنبض، ومن هنا جاء الاسم. ويقرأ كل تشغيل مصدرين: النص الجزئي المفرّغ الأحدث، والسجل المشترك للاستدلالات المكتملة ونتائج الأدوات.

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

ماذا أظهرت الاختبارات

قارن الباحثون النظام بالنوافذ على طراز SHANKS في ثلاث مجموعات: SpeechFCEval وFDBench v3 وAudioCRAG. والمقاييس مختلفة. ففي مهام استدعاء الدوال قيس التغطية الاستباقية للأدوات، أما في AudioCRAG، حيث يهم البحث، فقيس مدى إعادة استخدام ما جرى العثور عليه.

• يرفع الأسلوب التغطية الإجمالية للأدوات أو إعادة استخدام نتائج الاسترجاع (retrieval) مقارنة بالمخطط الأساسي القائم على النوافذ.
• FDBench v3: تغطية الأدوات +16 نقطة مئوية.
• FDBench v3: متوسط زمن الرد النهائي −36,4%.
• يختلف الأثر في جودة إنجاز المهمة النهائية باختلاف الاختبار المعياري: فالتحسن ليس متماثلًا في كل الحالات.

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

ما الذي ينبغي تغييره في الوكلاء الصوتيين في بيئات الإنتاج

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

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