NPCI الهندية تختبر وكلاء الذكاء الاصطناعي المصرفيين: ما يصل إلى 12% من «النجاحات» تخطّت خطوات إلزامية

أصدرت National Payments Corporation of India (NPCI)، وهي المؤسسة التي تدير البنية التحتية الوطنية للمدفوعات في البلاد، معيار TauIndianBankBench. وهو مجموعة من 1000 مهمة يعمل فيها نموذج لغوي مساعدًا في بنك تجزئة. يتحدث النموذج مع عميل يؤدي دوره نموذج آخر، ويستدعي أدوات: يحجب بطاقة، ويغلق وديعة، ويطّلع على جدول الدفعات. والخلاصة الرئيسية للمؤلفين: إذا اقتصر التحقق على الحالة النهائية لقاعدة البيانات، كما تفعل معظم الاختبارات المشابهة، فإن 6.5–12.0% من الجلسات «الناجحة» لدى جميع النماذج تتضمن في الواقع مخالفة للإجراء.

لماذا لا تكفي قاعدة البيانات النهائية؟

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

والمشكلة أن كثيرًا من الخطوات الإلزامية في القواعد لا يسجّل شيئًا في قاعدة البيانات. ومن الأمثلة الواردة في الورقة:

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

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

فحصان بدل فحص واحد

تحصل كل جلسة على حكمين: «اجتازت/لم تجتز»:

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

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

مكوّنات المعيار

• بنك اصطناعي يضم 944 عميلًا: حسابات، وبطاقات، وودائع، وقروض، وأوامر دائمة، وحالة KYC، وسجل العمليات. • 34 أداة: 33 أداة خدمية وأداة واحدة لتحويل العميل إلى موظف بشري. ومن الأدوات الخدمية تقرأ 20 أداة البيانات فقط، وتتعلق 13 بالكتابة (11 منها تغيّر السجلات، واثنتان تُصدران طلب دفتر شيكات أو نسخة من كشف الحساب).

• 24 وثيقة في قاعدة المعرفة: حدود المدفوعات، وتحديث KYC، وتأمين الودائع، وضريبة الفوائد، ومواعيد استرداد المدفوعات، والمخططات الحكومية. • 50 عائلة مهام في أربع فئات: مهام متعددة الخطوات المترابطة، ومهام بشرط ينبغي ملاحظته قبل الإجراء (مثلًا أن العميل لا يستوفي الشروط)، وعمليات نادرة، ومهام ضابطة بسيطة. ويبلغ متوسط سلسلة الاستدعاءات 3.

54 استدعاء، من استدعاء واحد إلى ستة. • من بين 1000 مهمة، تتطلب 962 استدعاءً واحدًا على الأقل للقراءة، و114 لا تتطلب أي عملية كتابة.

تتوفر شرائح من المجموعة: المجموعة الكاملة من 1000 مهمة، ونسخة مخففة من 200 مهمة (أربع من كل عائلة)، وتقسيمها إلى جزأين للتدريب والاختبار، كي يتاح الضبط الدقيق للنموذج وقياس النتيجة بإنصاف.

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

ماذا أظهرت النماذج الستة

اختبر المؤلفون ستة نماذج مفتوحة، خمسة منها من عائلة Gemma 4. وفيما يلي النتائج:

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

وللتحقق من نزاهة المقارنة نفسها، قورنت نسخة المقيِّم المنفَّذة بنسخة مستقلة على 600 جلسة مسجلة، وتطابقت الأحكام في جميع الحالات. وقبل الإصدار أعادت الحزمة حساب 5000 جلسة وأعادت إنتاج جميع التقييمات. وتكرر ترتيب النماذج أيضًا على إعداد تشغيل آخر للنماذج.

ماذا يعني هذا للبنوك والمطورين

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