نظام ذكاء اصطناعي يعيد إنتاج قرار منسّقي الرحلات الجوية لـ296 راكبًا

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

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

النموذج يقرأ الرسائل وPython يحسب المقاعد

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

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

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

الاضطراب الحقيقي كشف قواعد لم تكن في المهمة

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

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

وظهرت أخطاء أيضًا في معالجة الوقت. فعند تصفية المنشورات قد تقع رسالة رفع القيد خارج حدود الفترة المختارة. وفي أحد الحسابات حصل النظام على 1093 دقيقة بدلًا من 1346. وربط المؤلفون بين حدثَي فرض القيد ورفعه، وأضافوا فحوصات للفترات التي تمتد عبر منتصف الليل.

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

ماذا تثبت 164 عملية تشغيل

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

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

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