بناء وكيل صوت ومحادثة متصل بالأنظمة الداخلية

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

وفيما يلي كيف يحدث ذلك تقنيًا، والقيود المرتبطة به.

الفرق الجوهري عن IVR التقليدي

الـ IVR شجرة خيارات ثابتة: اضغط 1 للمبيعات، 2 للدعم. أي طلب خارج الشجرة يفشل. والوكيل الصوتي مختلف في ثلاثة أمور.

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

وهذا الفارق الثالث تحديدًا هو ما يجعل التكامل مع الأنظمة ممكنًا أصلًا.

المعمارية: نمط السلسلة (Cascade)

النمط الافتراضي والأكثر تحكمًا يمر بأربع مراحل متتابعة لكل دورة حوار.

• الاتصالات (Telephony): استقبال المكالمة عبر SIP أو WebRTC.
• تحويل الكلام لنص (STT): يجب أن يكون streaming لا batch، أي يحوّل أثناء الكلام لا بعده.
• النموذج اللغوي (LLM): يفهم النية ويقرر الرد أو استدعاء أداة.
• تحويل النص لكلام (TTS): ينطق الرد بصوت طبيعي.

وفوق هذه المراحل تجلس طبقة التنسيق (Orchestration) التي تدير الدورة كلها. البديل هو نموذج Speech-to-Speech واحد، لكنه صندوق مغلق لا يمكن ضبطه للهجات المحلية. لذلك السلسلة هي الافتراضي الصحيح للعربية.

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

ما الذي تحله طبقة التنسيق

هذه الطبقة مسؤولة عن كل ما يجعل المحادثة تبدو طبيعية لا آلية.

• تحديد نهاية الدور: متى انتهى المتصل من كلامه فعلًا؟
• المقاطعة (barge-in): إسكات الوكيل فورًا حين يبدأ المستخدم بالكلام.
• كلمات التأكيد القصيرة أثناء الاستماع لتبدو المحادثة حية.
• ملء الفراغ الصوتي أثناء انتظار النموذج بدل صمت محرج.
• الاحتفاظ بحالة الجلسة عبر دورات الحوار.
• استدعاء الأنظمة الخارجية أثناء المكالمة.

كيف يبدو استدعاء نظام أثناء المكالمة

سيناريو واقعي: موظف يتصل ليسأل عن حالة طلب صيانة. ما يحدث فعليًا:

• المتصل يقول: «أبي أعرف ما صار في طلب الصيانة حقي».
• الوكيل يحتاج رقم هوية أو رقم طلب، فيسأل عنه.
• بعد الحصول عليه، يستدعي دالة معرَّفة مسبقًا مثل get_ticket_status برقم الطلب كمعامل.
• البوابة الوسيطة تستقبل الاستدعاء، تتحقق من الصلاحيات، وتستعلم من نظام التذاكر.
• ترجع النتيجة كبيانات منظمة: الحالة، تاريخ آخر تحديث، الفني المسؤول.
• الوكيل يصيغها بلغة طبيعية وينطقها.

الخطوة الرابعة هي جوهر التصميم الآمن. الوكيل لا يتصل بنظام التذاكر مباشرة أبدًا. بل يمر عبر طبقة تتحكم بما يُسمح به.

الأدوات حسب نموذج التشغيل

الاختيار بين مفتوح ومُدار ليس تقنيًا فقط. الاستضافة الذاتية تعطيك سيطرة على مكان البيانات، وهذه نقطة نظامية لا رفاهية هندسية في السعودية.

أربعة أسئلة تفصل الادعاء عن الواقع

عند تقييم أي مزوّد، هذه الأسئلة تكشف القدرة الفعلية على التكامل:

• هل يدعم استدعاء الدوال أثناء المكالمة لا بعدها فقط؟ وكم يضيف كل استدعاء من زمن استجابة؟
• هل يدعم رؤوس مصادقة مخصصة. OAuth2 أو مفاتيح API أو mTLS؟
• هل يستطيع الوصول لأنظمة محلية خلف جدار ناري، أم يشترط كشفها للإنترنت؟
• هل يوفّر webhooks للأحداث: بداية المكالمة ونهايتها، النص الكامل، والنتيجة؟

السؤال الثالث هو الفاصل عمليًا. أغلب المنصات المُدارة تتطلب نقطة نهاية عامة، وهذا يعني أنك ستبني طبقة وسيطة على أي حال.

المعمارية الواقعية للأنظمة المحلية

التصميم الذي يعمل: الوكيل يتحدث إلى بوابة API تملكها أنت، وهي وحدها من يتحدث لأنظمتك الداخلية.

هذه الطبقة تعطيك أربعة مكاسب دفعة واحدة:

• تحكم دقيق بالصلاحيات: تحدد بالضبط أي عمليات مسموحة وعلى أي بيانات.
• سجل تدقيق لكل استدعاء: من طلب ماذا ومتى وبأي نتيجة.
• إخفاء تفاصيل الأنظمة الداخلية عن المزوّد الخارجي.
• حرية تبديل مزوّد الصوت لاحقًا دون إعادة بناء التكاملات من الصفر.

والمكسب الرابع يُغفل عادة. سوق الوكلاء الصوتية يتغيّر بسرعة، ومن يبني تكاملاته مباشرة داخل منصة مزوّد واحد يدفع ثمن التبديل مرتين.

ميزانية الاستجابة تحكم كل قرار

في العالم الصوتي، زمن الاستجابة هو المنتج نفسه. ولا يُقيَّم أي مكوّن دون حساب كلفته الزمنية.

• أقل من 300 ملي ثانية: يُحس طبيعيًا كإنسان.
• من 300 إلى 500: مقبول وطبيعي.
• من 500 إلى 800: يبدأ يبدو آليًا.
• فوق 1500: المتصل يقفل الخط.

كل استدعاء API أثناء المكالمة يُخصم من هذه الميزانية. أمامك خياران: تصميم استدعاءات سريعة جدًا بفهارس مناسبة، أو تشغيل صوت انتظار قصير أثناء الجلب. والثاني أسهل وأكثر واقعية مع الأنظمة القديمة.

الجانب النظامي في السعودية

هذا القسم يُطرح في الأسبوع الأول لا في الشهر السادس، لأن النظام قد يوقف المشروع قبل أن تفعل التقنية.

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

ونقطة أخلاقية تتحول تدريجيًا لمتطلب نظامي: إفصاح الوكيل عن كونه نظامًا آليًا لا إنسانًا في بداية المكالمة.

هذا ليس استشارة قانونية. راجع cst.gov.sa وsdaia.gov.sa مباشرة، وأشرك الجهة القانونية قبل أي التزام تعاقدي.

من أين تبدأ عمليًا

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

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