الخطوط الجوية السنغافورية تستبدل روبوت الدردشة القائم على السيناريوهات بنموذج لغوي كبير وتضاعف رضا العملاء CSAT

إنه ألم مألوف لكل من بنى منظومة دعم للعملاء: روبوت دردشة قائم على السيناريوهات. يجب وصف كل نية (intent)، ورسم كل فرع مسبقًا، بينما يكتب الشخص شيئًا من قبيل «أُلغيت رحلتي، ولديّ نقل وفندق، ماذا أفعل؟». فيردّ الروبوت بقائمة من خمسة بنود. مرّت الخطوط الجوية السنغافورية بهذه التجربة وأعادت كتابة روبوتها Kris على أساس نموذج لغوي كبير (LLM). وتشارك الشركة أرقامًا وتفاصيل معمارية يمكن استخلاص بعض الدروس منها.

ما الذي تغيّر في Kris

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

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

والنتيجة بحسب شركة الطيران: ارتفع CSAT إلى الضعف. كما زُوّد الموظفون بأداة منفصلة لتلخيص المكالمات تعمل على الواجهة نفسها، ليقضوا وقتًا أقل في مراجعة ما بعد المحادثة. وانخفض متوسط وقت معالجة الطلب بنحو 10%.

Flight Recommender: النموذج يستدعي الأدوات ولا يختلق الأسعار

المنتج الثاني هو Flight Recommender. يصف العميل رحلته بلغة عادية بدل أن يظل يحرّك مرشحات التواريخ والوجهات مرارًا. وقد زاد الاستخدام خلال عام بما يقارب ثلاثة أضعاف.

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

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

الذكاء الاصطناعي في دورة التطوير كلها، لا في الكود فقط

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

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

وهناك أيضًا منصة داخلية اسمها Jarvis مع ضبط للصلاحيات. يعمل الموظفون فيها مع ملفات PDF وWord وExcel والعروض التقديمية، ويبنون مسارات عملهم (workflow) وقواعد معرفة صغيرة خاصة بهم. ويستخدمها شهريًا أكثر من 60% من العاملين.

ما يجب أخذه في الاعتبار عند القراءة

هذه حالة منشورة على موقع OpenAI، أي مادة ذات هدف تجاري. لم تُكشف منهجية قياس CSAT، ولا يتضح بما قورنت النتائج ولا خلال أي فترة. أما أرقام وقت المعالجة (نحو 10%) والتطوير (حتى 20%) فهي أكثر تواضعًا بكثير من «الضعف» الذي في العنوان. ومن الأفضل اعتبارها مؤشرًا واقعيًا لا وعدًا.

الخلاصة العملية للفرق التي تبني الدعم أو البحث:

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