أعلنت Microsoft عن MAI-Transcribe-2-Streaming في 1 أكتوبر 2026. يستقبل النموذج الصوت أثناء التحدث ويعيد نصاً متغيراً قبل إصدار النص النهائي. وللمطور الذي يضيف تسميات توضيحية مباشرة أو إدخالاً صوتياً إلى تطبيق، يتمثل السؤال المفيد في كيفية وصول هذه التحديثات إلى التطبيق ومتى يمكنه اعتبار النص مستقراً.

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

التغيير الأبرز

  • قدمت Microsoft نموذج بث يعيد نصاً مؤقتاً مع وصول الصوت، ثم يؤكد مقاطع التفريغ النصي. أما مسار نسخ الملفات المنفصل MAI-Transcribe-2 فيعالج الصوت المسجل ويوثق مجموعة مختلفة من الخيارات.
  • على التطبيق الذي يستخدم Realtime API إرسال صوت منسق على النحو الصحيح، والتعامل مع مراجعات الذيل المؤقت، وتحديد وقت طلب تفريغ مكتمل. وتحدد هذه الخيارات ما يراه المستخدمون ومتى يمكن لمنطق التطبيق اللاحق الاعتماد على النص النهائي.
  • نموذج البث في معاينة عامة من دون اتفاقية مستوى خدمة. ولا توصي Microsoft باستخدامه في أحمال الإنتاج. أما ادعاءات السرعة والدقة المنشورة فهي ادعاءات الإطلاق والمعايير المرجعية، وليست قياسات أجراها هذا الدليل.

اختر مسار الاتصال

يعرض كتالوج Microsoft Foundry النموذج MAI-Transcribe-2-Streaming، إصدار 2026-08-06، بوصفه نموذجاً في مرحلة المعاينة بإدخال صوتي وإخراج نصي. وتعرض نظرة Microsoft العامة بتاريخ 1 أكتوبر مسارين لدمجه: Realtime API باستخدام بروتوكول WebSocket شبيه بـOpenAI Realtime، أو Azure Speech SDK. ويعيد كلاهما نتائج تعرف وسيطة ونهائية. ويتولى SDK إدارة الاتصال وتدفق الصوت، بينما يكشف مسار Realtime الأحداث مباشرة.

أما مسار Realtime API، فتشترط Microsoft اشتراكاً في Azure ومورداً على Microsoft Foundry في منطقة مدعومة ونشراً لنموذج البث. اتصل بالعنوان wss://{your_resource_name}.services.ai.azure.com/mai/v1/realtime?intent=transcription باستخدام رمز bearer من Microsoft Entra أو مفتاح API. وتوصي الوثائق بالمصادقة عبر Entra. وبعد session.created، أرسل session.update مع تسمية النشر وتحديد تنسيق الإدخال. ولا يمكن تغيير الإعداد بعد أول إضافة للصوت، حتى بعد تنفيذ commit.

تنسيق الإدخال الموثق هو PCM16 خام بإشارة موقعة وترتيب little-endian وقناة أحادية، بتردد 16 أو 24 كيلوهرتز، ويُرسل في مقاطع base64 ضمن رسائل input_audio_buffer.append. وهي بيانات PCM من دون ترويسة WAV. وتوصي Microsoft بمقاطع صغيرة، مثل 10 إلى 20 مللي ثانية، لتقليل زمن الاستجابة، مع الإشارة إلى أن المقاطع الأكبر تقلل عبء الشبكة. وتقرأ عينة Python الصوت من الميكروفون على دفعات مدتها 100 مللي ثانية؛ فنصيحة المقاطع الصغيرة وحجم الدفعة في العينة خياران مختلفان، وليسا نتيجة قاستها BIG CHANGE.

أما مسار Speech SDK فيتطلب SDK بالإصدار v1.52.0 واشتراكاً في Azure ومورداً على Foundry أو Speech. وتضبط عينة Microsoft بلغة Python الخاصية speech_config.model على MAI-Transcribe-2-Streaming، وتوفر صوتاً أحادي القناة بتردد 16 كيلوهرتز وعمق 16 بت عبر تدفق دفع، وتستمع إلى الحدثين recognizing و recognized، وتستخدم العينة ملف audio.pcm لتوضيح تدفق الدفع؛ أما التطبيق فيوفر مصدر الصوت الخاص به. هذه واجهات موثقة وأنواع أحداث متوقعة، وليست اختبار توافق على مستوى حساب أجرته هذه الجهة.

افصل النص المؤقت عن النص المؤكد

تؤثر دلالات أحداث Realtime في تصميم الواجهة المباشرة. يحتوي الحدث conversation.item.input_audio_transcription.delta على نص جرى تثبيته حديثاً، ويضيفه التطبيق العميل إلى مخزنه المؤكد من دون تغيير المسافات. أما الحدث intermediate فيحتوي على كامل الذيل المؤقت الحالي. ويستبدل كل ذيل جديد الذيل السابق. ويمكن للشاشة عرض النص المؤكد مع الذيل الحالي؛ لكن تخزين كل حدث وسيط كسطر جديد يكرر الكلمات مع مراجعة النموذج لها.

يرسل العميل الحدث input_audio_buffer.commit عند توقف رصده أو عند نهاية التسجيل. وتقول Microsoft إن هذا يطلب إصدار التفريغ النهائي بأسرع ما يمكن؛ ويؤكد الحدث input_audio_buffer.committed اعتماد هذا الإرسال، بينما يوفر الحدث conversation.item.input_audio_transcription.completed النص النهائي الكامل للصوت منذ الإرسال السابق. ويذكر دليل Realtime أن كشف الأدوار على الخادم والإرسال التلقائي غير متاحين في إعداد جلسة هذا النموذج. لذلك يحتاج التطبيق الصوتي إلى تحديد فاصل خاص به للتوقف أو نهاية الدور إذا أراد إكمال المقاطع تلقائياً. وتصف الوثائق عقد الأحداث؛ لكنها لا تحدد كاشفاً واحداً مناسباً لجميع الحالات.

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

الإتاحة والمناطق والسعر

تقول Microsoft إن النموذج متاح عالمياً، مع توجيه Azure للطلبات إلى مناطق تقديم الخدمة. وتذكر صفحتا التكامل الصادرتان في 1 أكتوبر منطقتين متاحتين مختلفتين: يسرد دليل Realtime منطقة Sweden Central وCentral US وSouth India؛ بينما يسرد دليل Speech SDK منطقة Sweden Central وCentral US وSoutheast Asia. وتذكر الصفحتان East US 2 بوصفها متاحة قريباً. تحقق من خيارات النشر والمنطقة الحالية للمسار الذي تنوي استخدامه؛ فالصفحتان لا تقدمان قائمة موحدة متسقة. ولا ينبغي فهم الإتاحة العالمية على أنها ضمان لمعالجة البيانات في موقع محدد.

يورد الإعلان سعراً تمهيدياً قدره $0.54 لكل ساعة صوت حتى نهاية 2026. ويعادل ذلك حسابياً 9 دولارات لكل 1000 دقيقة صوتية، قبل احتساب أي خدمات أو بنية تحتية منفصلة يستخدمها التطبيق. وتحيل Microsoft من أدلتها إلى صفحتي أسعار Foundry Models وSpeech service للمسارين على التوالي. ولا تقدم المصادر التي راجعناها سعراً بعد الفترة التمهيدية أو فاتورة مختبرة؛ لذا يتطلب وضع ميزانية للنشر التحقق من الأسعار الحالية.

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

أما دليل MAI-Transcribe-2 في Azure Speech المنفصل فيوثق إدخال الملفات وخيارات منها تحديد المتحدثين والطوابع الزمنية على مستوى الكلمات وترجيح الكلمات الرئيسية وأنماط النص المنقح أو الحرفي. ولا تفترض أن هذه الضوابط تعمل مع MAI-Transcribe-2-Streaming؛ فأدلة تكامل البث لا توثقها. وإذا كان المنتج يحتاج إلى هذه المخرجات، فقيّم نموذج الملفات أو تحقق من دعم البث عبر الوثائق الحالية واختبار قبل بناء المنتج عليها.

المصادر ومزيد من القراءة

  • إعلان Microsoft AI، 1 أكتوبر 2026: ادعاءات الإطلاق واللغات والسرعة والسعر التمهيدي. وقد نُسبت أعلاه ادعاءات Microsoft بشأن الدقة والسرعة الداخلية إلى الشركة.
  • كتالوج نماذج Microsoft Foundry، روجع في 2 أكتوبر: إصدار النموذج ومرحلة المعاينة وأنواع الإدخال والإخراج؛ والكتالوج ليس اختبار أداء.
  • نظرة عامة على البث، دليل Realtime API ودليل Speech SDK، حُدثت في 1 أكتوبر: مسارا التكامل الموثقان وشروط المعاينة وسلوك الأحداث والأمثلة وجداول المناطق. ولم تشغّل BIG CHANGE الأمثلة.
  • MAI-Transcribe-2 في Azure Speech، روجع في 2 أكتوبر: مسار نسخ الملفات المنفصل وعناصر التحكم الموثقة فيه. ولا تثبت قائمة ميزاته تكافؤها مع مسار البث.
  • معيار البث من Artificial Analysis والمنهجية، روجعت في 2 أكتوبر: تصميم المعيار المستقل وتعريفات التوقيت. ولم يكشف النص العام المسترجع عن صف نتيجة محدد للنموذج يتيح تأكيد ترتيبه بصورة مستقلة.