لماذا يجب أن تتبع اختبارات الحِمل للذكاء الاصطناعي الصوتي مسار المكالمة الفعلي

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

للاطلاع على المنهجية العامة (زيادة التزامن تدريجيًا، والقيم المئوية لـزمن الاستجابة، ومجموعات اختبارات الانحدار)، راجع دليلنا حول اختبار حِمل الوكلاء الصوتيين. تتناول هذه المقالة عمليات النشر التي تتولى فيها منصّة UCaaS أو CCaaS التحكم في المكالمات.

لماذا لا يثبت اختبار الحِمل المباشر عبر SIP أو API أن عملية النشر تعمل؟

لأنه يتخطى كل مرحلة يمرّ بها المتصلون. يرسل الاختبار المباشر المكالمات مباشرةً إلى endpoint الخاص بـ SIP لدى مزوّد الذكاء الاصطناعي أو إلى API الخاص به. أما مكالمة الإنتاج فتسلك مسارًا أطول: تصل من شركة الاتصالات، ثم تصل إلى منصّة مركز التواصل أو منصّة UCaaS لديك، وتمرّ عبر IVR أو منطق التوجيه، ثم تُحوَّل تحويلًا أعمى (blind transfer) إلى نقطة دخول الذكاء الاصطناعي الصوتي، وبعدها إما أن تنتهي هناك أو تُحوَّل مجددًا إلى قائمة انتظار بشرية.

لكل مرحلة حدّ سعتها الخاص وسلوك SIP الخاص بها والجهة المسؤولة عن إعدادها، ولا يختبر الاختبار المباشر أيًّا منها. إليك ثلاثة أمثلة من وثائق Retell:

• تُضبط السعة في أكثر من موضع. يُطبَّق حدّ التزامن في Retell على مستوى كل مساحة عمل (تبدأ مساحات العمل بنظام الدفع حسب الاستخدام بـ 20 مكالمة متزامنة). ويشير دليل Retell الخاص بـ Five9 إلى أن Five9 تطبّق حدود سعة trunk الخاصة بها، كما ينصّ دليل Avaya على التأكد من أن عدد SIP trunks المُعدّة يغطي عدد المكالمات المتزامنة المتوقعة. والاختبار الذي يتجاوز المنصّة لا يصل إلى حدّها أبدًا.
• طريقة الاتصال تغيّر ما يستطيع الذكاء الاصطناعي فعله. تدعم منصّة Retell خدمة elastic SIP trunking (الطريقة الموصى بها) والاتصال عبر SIP URI. ومع طريقة SIP URI، لا تتوفر ميزة التحويل المدمجة في Retell، لذا يجب التعامل مع التحويلات وإنهاء المكالمات عبر منطقك الخاص. ولن يكشف الاختبار المباشر هذه الفجوة أبدًا.
• تعتمد التحويلات على الطرف الآخر. يستخدم التحويل البارد (cold transfer) في Retell رسالة SIP INVITE افتراضيًا، أو SIP REFER إذا كان مزوّد الاتصالات لديك يدعمها. أما ما إذا كانت REFER تعمل، وما إذا كانت الترويسات المخصّصة تبقى بعدها، فيعتمد على مزوّدك، لا على الذكاء الاصطناعي.

كيف يبدو مسار المكالمة الفعلي عندما تتولى منصّة مركز تواصل التحكم في المكالمات؟

إنه سلسلة من خمس مراحل، ويجب أن تمرّ كل مكالمة اختبار عبرها جميعًا.

هناك تفصيلتان من وثائق Retell مهمتان هنا. مع طريقة SIP URI، تحتاج كل مكالمة أولًا إلى طلب Register Phone Call، ويجب أن تصل المكالمة إلى ذلك URI خلال 5 دقائق وإلا انتهت بالحالة registered_call_timeout، لذا يجب أن تواكب خدمة التسجيل لديك الحِمل أيضًا. وعلى جانب الخروج، يشير دليل Retell الخاص بـ Genesys Cloud إلى أن المكالمات التي تحوّلها Genesys إلى وجهات أخرى تختار trunk من خطط الأرقام والمسارات الصادرة الخاصة بالموقع (Site): وهي إعدادات في المنصّة لا يصل إليها الاختبار المباشر أبدًا.

أين تظهر الأعطال الخاصة بالمسار عند ذروة الحجم؟

حيث يلتقي نظامان، وعادةً حين يبدأ أحدهما في وضع المكالمات في قائمة الانتظار. راقب ما يلي أثناء الزيادة التدريجية:

1. الحدّ الأضيق للسعة هو الذي يحكم. إذا كان trunk منصّتك يسمح بمكالمات متزامنة أقل مما تسمح به مساحة عمل الذكاء الاصطناعي، فسيتعثّر المتصلون داخل المنصّة بينما تبدو لوحة تحكم الذكاء الاصطناعي سليمة. حدّد سعة شركة الاتصالات وtrunk المنصّة وحدّ التزامن للذكاء الاصطناعي معًا.
2. قوائم انتظار المكالمات الواردة لدى الذكاء الاصطناعي. عندما تبلغ المكالمات الواردة حدّ التزامن في Retell، تحتفظ منصّة Retell بالمكالمات الجديدة لمدة 40 ثانية تقريبًا. وإذا لم تتوفر خانة شاغرة، تحوّل المتصل إلى fallback_number مُعدّ مسبقًا، أو تنهي المكالمة بالحالة concurrency_limit_reached إذا لم يُضبط أي رقم. حدّد مسبقًا وجهة هذا الرقم الاحتياطي (غالبًا العودة إلى قائمة الانتظار البشرية في منصّتك)، واختبر أنه يعمل تحت الحِمل.
3. مزاحمة المكالمات الصادرة للمكالمات الواردة. تتشارك جميع المكالمات الصوتية في مساحة العمل مجمّع تزامن واحدًا. فإذا كانت مساحة العمل نفسها تشغّل أيضًا حملات صادرة، يمكن للتزامن المحجوز للمكالمات الواردة أن يحتفظ بخانات للمكالمات المحوَّلة إليها.
4. معدّل إنشاء المكالمات. تضبط منصّة Retell عدد المكالمات في الثانية لكل مسار اتصالات، وتشير وثائقها إلى أن CPS في Custom Telephony يتوسّع مع مستوى التزامن لديك. وقد تصل دفعة من التحويلات في بداية الساعة إلى حدّ المعدّل قبل أن تصل إلى حدّ التزامن.
5. إعدادات الشبكة والوسائط. تنشر منصّة Retell عدة نطاقات من عناوين IP لإضافتها إلى قائمة السماح (بعضها ينطبق فقط على حركة مرور معيّنة في الولايات المتحدة)، وبروتوكولات النقل التي تدعمها (TCP موصى به، وUDP، وTLS، وmTLS)، والترميزات (PCMU، وPCMA، وG.722). وقائمة السماح التي لا تغطي إلا بعض هذه النطاقات قد تنجح في اختبار صغير وتفشل عند الحجم الكبير.
6. تغييرات SIP أثناء المكالمة. يمكن للمنصّات إرسال رسائل re-INVITE لتحديث جلسة أو نقل الوسائط أو تعليق مكالمة. تستجيب منصّة Retell لرسائل re-INVITE داخل الحوار لتحديث الجلسات، وإعادة ربط الوسائط، وتغيير الترميز، وإعادة توليد مفاتيح SRTP، والتعليق أو استئنافه؛ فتأكد من أن رسائل re-INVITE من منصّتك تتصرف بالطريقة نفسها عند الحجم الكبير.

كيف تولّد حركة مرور اختبارية عبر المسار الفعلي؟

أطلق مكالمات الاختبار من خارج شبكتك، واتصل بالأرقام العامة نفسها التي يستخدمها المتصلون. فهذه هي الطريقة الوحيدة لكي تتحمّل كل مرحلة الحِمل.

• اختر مولّد مكالمات يتصل برقمك العام. تُجري ميزة المكالمات المجمّعة في Retell مكالمات صادرة من Retell، كما تُجري اختبارات المحاكاة في Retell محادثات نصية، لذا لا تعيد أيٌّ منهما إنتاج مكالمة واردة تحوّلها منصّتك. يُجري بعض شركاء الاختبار مكالمات حقيقية؛ فعلى سبيل المثال، تصف Hamming وكلاءها الصوتيين وهم يتصلون بوكلائك. اسأل أي مورّد اختبار عمّا إذا كانت مكالماته تدخل عبر شبكة الهاتف العامة أم تتصل مباشرةً بالوكيل.
• ضع وسمًا على كل مكالمة اختبار. اجعل منصّتك تضيف ترويسة SIP مخصّصة من نوع X- (مثل معرّف تشغيل الاختبار) عند التحويل. تستخرج منصّة Retell ترويسات X- الواردة إلى الحقل custom_sip_headers الخاص بالمكالمة وإلى المتغيرات الديناميكية، بحيث يمكنك ربط كل مكالمة ذكاء اصطناعي بسجلّها في المنصّة.
• زِد الحِمل على مراحل. ابدأ دون الذروة المتوقعة، ثم تجاوزها تدريجيًا، ثم اترك حركة المرور تنخفض وتأكد من عودة النظام إلى وضع الخمول.
• احجز وقت جميع الجهات المسؤولة. ينبغي أن تنضم شركة الاتصالات ومسؤول المنصّة ومورّد الذكاء الاصطناعي الصوتي جميعًا. ويُجري دليل Retell الخاص بـ Five9 اختبار التكامل النهائي في جلسة مشتركة.
• ارفع الحدود قبل الاختبار، لا أثناءه. تحقّق من حدود التزامن وCPS للذكاء الاصطناعي في صفحة Limits (تقترح الحاسبة المدمجة قيمًا بناءً على حركة المرور في ساعة الذروة)، وتأكد من تطابق سعة trunk في المنصّة معها.

ما إشارات SIP التي يجب مراقبتها أثناء الاختبار؟

راقب إشارات كل مكالمة من أول INVITE حتى آخر BYE، على جانبي التحويل. يمكن أن تتضمن تفاصيل المكالمة في Retell علامة تبويب Packet Capture تحتوي على إشارات SIP الخاصة بالمكالمة، ويشرح دليل تصحيح الأخطاء باستخدام PCAP كيفية قراءتها في Wireshark. وإذا كنت تشغّل trunk خاصًا بك، توصي وثائق Retell بالالتقاط على الخادم أو البوابة التي تُنهي SIP، وهي عادةً SBC لديك.

ابحث عن:

• إعداد سليم على ساق التحويل: INVITE، ثم 100 Trying، ثم 180 Ringing، ثم 200 OK، ثم ACK.
• استجابات الخطأ: 403 (قائمة السماح أو الأذونات)، و404 (SIP URI خاطئ أو خطأ في التوجيه)، و408 أو 477 (endpoint يتعذّر الوصول إليه أو خطأ في النقل)، و486 (مشغول)، و503 (الخدمة غير متاحة).
• التحويل إلى الخارج: رسالة REFER أو INVITE جديدة، بحسب طريقة التحويل، وما إذا كانت ترويسات X- قد بقيت. وتحذّر وثائق Retell من أن الترويسات المخصّصة قد تُحذف عندما يتم التحويل إلى رقم PSTN بدلًا من endpoint خاص بـ SIP.
• من أرسل BYE، ومتى: يجب أن تنتهي كل مكالمة برسالة BYE من الطرف الذي تتوقعه.

تمنحك أحداث webhook في Retell (call_started، وcall_ended، وأحداث transfer_*) جدولًا زمنيًا لكل مكالمة لمطابقته مع الالتقاطات.

ما الذي يجب اعتباره نجاحًا؟

يعني النجاح أن الأرقام متطابقة عبر جميع الأنظمة، لا مجرد أن الذكاء الاصطناعي ظل يعمل. استخدم قائمة التحقق هذه:

• تتطابق أعداد المكالمات بين سجلات شركة الاتصالات وتقارير المنصّة وسجل مكالمات الذكاء الاصطناعي خلال فترة الاختبار.
• انتهت كل مكالمة ذكاء اصطناعي بسبب قطع اتصال متوقع (user_hangup، agent_hangup، call_transfer)، ولم تظهر أسباب من نوع concurrency_limit_reached أو error_*.
• وصل كل تحويل إلى موظف بشري إلى قائمة الانتظار الصحيحة، مع معرّف المتصل والترويسات المتوقعة.
• لا توجد استجابات SIP 4xx أو 5xx على سيقان التحويل، باستثناء تلك التي تعمّدت إطلاقها.
• تدفّق الصوت في الاتجاهين في المكالمات التي أُخذت منها عينات.
• بقي التزامن في الذروة دون كل حدّ في السلسلة، مع هامش كافٍ.
• بعد توقف حركة المرور، عاد التزامن إلى الصفر على جانب الذكاء الاصطناعي، ولم تُظهر المنصّة أي جلسات عالقة.

يستحق هذا الفحص الأخير خطة اختبار خاصة به، لأن المكالمات التي لا تُغلق بالكامل بعد التحويل قد تستهلك التزامن عند الذروة. نتناول إغلاق المكالمات في دليل منفصل.

ما الذي يجب أن تسأل عنه مورّد الذكاء الاصطناعي الصوتي قبل الاختبار؟

اطرح أسئلة تجعل المورّد يُظهر المسار، لا الذكاء الاصطناعي فحسب:

1. ما طريقة الاتصال التي توصون بها لمنصّتنا، وما الذي تغيّره في التحويلات وإنهاء المكالمات؟
2. ما طرق تحويل SIP التي تدعمونها (INVITE، REFER)، وما الذي تتطلبه كل منها من منصّتنا؟
3. كيف نمرّر ترويسات SIP المخصّصة ونقرؤها في الاتجاهين؟
4. أين تُضبط حدود التزامن وعدد المكالمات في الثانية لديكم، وماذا يحدث للمكالمة عند بلوغ الحدّ، وهل يمكننا رفعها للاختبار؟
5. هل يمكننا الاطلاع على إشارات SIP وأسباب قطع الاتصال لكل مكالمة، وهل سيراجع فريق الاتصالات لديكم الالتقاطات معنا؟

تتضمن وثائق Retell أدلة إعداد لـ Genesys Cloud وFive9 وAvaya وAmazon Connect، ودليلًا عامًا حول الاتصالات المخصّصة (custom telephony)، ودليلًا للتزامن يغطي كل حدّ. وللتحويلات من الوكيل إلى الخارج، راجع تحويل المكالمات وكيف يعمل التسليم من الذكاء الاصطناعي إلى البشر.

إذا كانت منصّتك تتولى التحكم في المكالمات وتحتاج إلى وكيل صوتي بالذكاء الاصطناعي يعمل خلفها، فاطّلع على منصّة الذكاء الاصطناعي الحواري للمؤسسات من Retell، وتواصل مع الفريق للتخطيط لاختبار حِمل على مسار مكالماتك الفعلي.

قراءات ذات صلة: اختبار الحِمل لإغلاق المكالمات، وسير العمل من CRM إلى الذكاء الاصطناعي الصوتي، والمزيد من الأدلة في مركز Retell Learn.