MOSS-Live تقبل صوتًا بتردد 16 كيلوهرتز ولا توقف المحادثة مؤقتًا من أجل البحث

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

تقترح MOSI Intelligence نهجًا مختلفًا. فبحسب المطورين، تواصل MOSS-Live الاستماع أثناء حديثها، وتميّز بين ردّ فعل قصير وأمر بالتوقف، وبعد المقاطعة تعرف كيف تعود إلى الجملة غير المكتملة. تقبل الواجهة في المدخل صوتًا بتردد 16 كيلوهرتز، وتُخرج صوتًا بتردد 48 كيلوهرتز. ويتم الاتصال عبر WebSocket، بينما تُرسل الصورة على شكل إطارات JPEG منفصلة.

ليست طابورًا من الردود بل تدفقًا مشتركًا

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

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

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

نموذجان بدل توقف واحد

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

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

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

ما الذي يجب فحصه قبل التكامل

حتى الآن، تتوفر MOSS-Live كنسخة تجريبية مجانية. ولم تُنشر تعرفة الدفع المستقبلية بحسب مدة الاتصال. لا توجد أوزان للنموذج، والنشر ممكن عبر الواجهة البرمجية فقط. ولا تسرد الوثائق جميع اللغات المدعومة؛ فالعروض التوضيحية تستخدم الإنجليزية والصينية، وجودة الروسية غير معلنة.

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

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