بنية مرجعية لأنظمة الذكاء الاصطناعي في التمويل

كل مشروع ذكاء اصطناعي مالي نتولّاه ينتهي به الأمر إلى الطبقات الست نفسها تقريباً: طبقة بيانات تضمن الصحّة الزمنية (point-in-time correctness)، واسترجاع (retrieval) يجري على الوثائق والسجلات، والنموذج الذي يقوم بالاستدلال، وحواجز أمان (guardrails) تقيّد ما يمكنه إخراجه، ومراجعة بشرية حيث تكون المخاطر مرتفعة، وسِجلّ تدقيق (audit trail) يتيح لك إعادة بناء أي قرار لاحقاً. تتغيّر البنية الطوبولوجية (topology)، أما الشكل فلا يتغيّر.

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

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

الرقم الذي يقرؤه النموذج يجب أن يكون الرقم الذي كان صحيحاً في اللحظة التي اتُّخذ فيها القرار. يبدو هذا بديهياً، غير أنه يُنتهَك على الدوام. فنموذج يقيّم طلب قرض ضمن مجموعة التدريب يرى رقم إيرادات المقترض الذي أُعيد بيانه (restated) بعد ربعين سنويّين. هذا التصحيح يتسرّب رجعياً إلى السمات، فيبدو التقييم دون الاتصال (offline eval) ممتازاً، ثم يقصّر الأداء في اليوم الذي يلتقي فيه النظام بمقترضٍ لا يمكنك رؤية مستقبله. النظر إلى الأمام (lookahead) هو أغلى خلل في الذكاء الاصطناعي المالي وأصعبه ملاحظةً، لأن كل شيء في النظام المتسرّب يبدو سليماً إلى أن يصل الإنتاج.

لذلك تحمل طبقة البيانات التزامات لا تحملها خطوط الأنابيب العامة:

• الصحّة الزمنية (point-in-time correctness). كل سجلّ يجيب عن سؤال «ماذا كنا نعرف، ومتى عرفناه»، لا مجرد «ما هو الصحيح الآن».
• تتبّع النشأة (lineage). لأي رقم استهلكه النموذج، يمكنك تسمية النظام المصدر، وخطوة الاستخراج، والتحويل الذي أنتجه.
• تحليل الكيانات (entity resolution). الطرف المقابل نفسه يظهر بثلاث سلاسل نصية مختلفة عبر أربعة أنظمة، وأنت بحاجة إلى هوية واحدة قبل أن تتمكّن من الاستدلال حول التعرّض (exposure) أو سجلّ التعهّدات (covenant history).
• التسوية (reconciliation). حين يُبلّغ مصدران عن رقم بصورة مختلفة، يُظهَر التباين ويُحلّ بقاعدة، لا أن يُطمَس بمتوسّط حسابي صامت.

أخطِئ في هذه الطبقة، فلن ينقذك نموذج ولا حيلة استرجاع ولا موجّه (prompt). أصِبها، فإن معظم ما تبقّى هندسة عادية.

الاسترجاع والنموذج هما الجزء القابل للاستبدال

هذه هي الطبقة التي يقضي الناس أطول وقت في الجدال حولها، وهي أقلّ الطبقات أهميةً لمسألة نجاح النظام من عدمه. الاسترجاع يسحب الإفصاحات التنظيمية ذات الصلة، وبنود العقود، والمذكّرات السابقة، والسجلات الداخلية إلى السياق (context). والنموذج يستدلّ عليها. وكلاهما قابل للاستبدال إلى حدّ بعيد؛ فأنت ستستبدل النموذج مرة واحدة على الأقل خلال عمر النظام، وينبغي للبنية أن تفترض ذلك.

أمران يستحقّان الانتباه هنا. أولاً، الاسترجاع فوق الوثائق المالية نادراً ما يخدمه البحث الدلالي (semantic search) وحده. فالاستعلام عن حدّ تعهّدٍ محدَّد أو عن بندٍ في إفصاح تنظيمي هو تطابق لفظي (lexical) بقدر ما هو دلالي، والاسترجاع الهجين (hybrid retrieval) الذي يجمع بينهما يتفوّق باستمرار على أيٍّ منهما منفرداً. فالأرقام والمصطلحات المعرَّفة والإحالات إلى الأقسام دقيقة بطبيعتها، والتضمينات الكثيفة (dense embeddings) تُموّهها.

ثانياً، يحتاج النموذج إلى مجموعة تقييم (eval set) تعكس العمل الفعلي، لا معياراً عاماً. فبالنسبة لمساعد مذكّرات الائتمان، يعني ذلك مذكّرات حقيقية بأرقام معلومة الصحّة ومصحِّحاً (grader) يفحص الأرقام لا النثر. وبالنسبة لمساعد مراقبة المعاملات، يعني ذلك تنبيهات موسومة بميزانية إيجابيات كاذبة (false-positive budget) محدَّدة، لأن كُلفة النظام تُقاس بساعات المحلّلين التي تُنفَق في تصفية الضجيج. من دون مجموعة تقييم قطاعية أنت تضبط النظام على «الإحساس»، والإحساس ينجرف.

حواجز الأمان والمراجعة والتدقيق هي حيث يختلف التمويل

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

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

المراجعة البشرية تُوضَع بحسب الجوهرية (materiality)، لا بصورة موحّدة. والسؤال التصميمي هو أيّ الحالات تمرّ مباشرة وأيّها تتوقّف لأجل إنسان. وجِّه الحالات وفق ثقة النموذج المُعايَرة (calibrated confidence) وكلفة الخطأ: فالحالات منخفضة المخاطر عالية الثقة تصبح معالجةً مباشرة (straight-through processing)، ويُنفَق انتباه المراجِع على الحالات الملتبسة والمكلفة. فطبقة مراجعة تطلب من إنسان أن يفحص كل شيء هي طبقة لا يستخدمها أحد بحلول الشهر الثالث.

سِجلّ التدقيق ليس ملفّ سِجلّات (log file). فلأي قرار أنتجه النظام، ينبغي أن تكون قادراً على إعادة بناء المدخلات كما كانت في حينها، والأدلّة المُسترجَعة، وإصدار النموذج، وحواجز الأمان التي انطلقت، ومَن راجعه. هذا ما تتوقّعه تعميمة SR 11-7 من إدارة مخاطر النماذج (model risk management)، وما يتوقّعه قانون الذكاء الاصطناعي الأوروبي (EU AI Act) من حفظ السجلات للأنظمة عالية المخاطر، وهو أيضاً ما ستريده أول مرة يُطعَن فيها في رقم نهاية الربع ويسأل أحدهم كيف توصّلت الآلة إليه.

حيث يعيش الانجراف ونهاية الربع

حقيقتان تشغيليّتان تقبعان تحت الطبقات الست جميعاً. النماذج والبيانات تنجرف (drift)، لذا فمجموعة التقييم ليست بوّابة إطلاق تجتازها مرّة؛ بل تعمل وفق جدول زمني على بيانات حديثة، والمعايرة التي تنزلق تُعامَل بوصفها حادثة (incident). وللتمويل ساعة تدقّ. فنهاية الربع تكدّس الحجم وترفع كلفة كل خطأ في اللحظة نفسها التي يبلغ فيها الطلب على الإنتاجية ذروته، لذا على توجيه المراجعة البشرية وحواجز الأمان أن يصمدا تحت الحِمل، لا في العرض التوضيحي فحسب. فالأيام التي تحسم نجاح التصميم من عدمه هي تلك التي يكون فيها الطابور عميقاً وموعد الإقفال محدِقاً. أما التصميم الذي يصمد فقط حين تهدأ حركة المرور فلم يلتقِ بها قط.