بناء سجل عميل ذهبي لذكاء اصطناعي مالي

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

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

حلّ الكيانات يقرّر مَن هو مَن

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

النمط الذي يصمد نمط متعدد الطبقات:

• طبّع أولاً. وحّد حالة أحرف البريد الإلكتروني، وجرّد الأسماء من الحركات والتشكيل، وفكّك العناوين إلى مكوّناتها، ووحّد لواحق الشركات بحيث تنطبق “Ltd” و”Limited” و”LTD.” على صيغة واحدة. معظم حالات عدم المطابقة الزائفة تنجم عن التنسيق لا عن غموض حقيقي.
• قسّم إلى كتل (blocking) لتجعل المشكلة قابلة للحل. لا يمكنك مقارنة كل سجل بكل سجل آخر. جمّع المرشّحين وفق مفتاح رخيص، فلنقل الأحرف الأربعة الأولى من اسم عائلة مُطبَّع مضافاً إليها الرمز البريدي، بحيث تجري المقارنات داخل سلال صغيرة.
• طابِق حتمياً حيثما أمكن. الإصابة الدقيقة على رقم تعريف ضريبي أو معرّف وطني موثّق هي مطابقة، وانتهى الأمر. هذه تحلّ الجزء الأكبر من مجتمع سجلاتك ولا تحتاج تفسيراً أبعد من القاعدة نفسها.
• سجّل نقاطاً احتمالياً على المتبقّي. بالنسبة للسجلات المتبقية، رجّح اتفاق كل حقل واختلافه. تطابق تاريخ الميلاد دليل قوي؛ تطابق الاسم الأول دليل ضعيف. تسجيل فيليجي-سنتر (Fellegi-Sunter) يصوغ هذا رياضياً ويمنحك عتبة قابلة للضبط.

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

قواعد البقاء تقرّر أيّ قيمة تفوز

بمجرد تجميع السجلات في كيان واحد، تتناقض فيما بينها. نظام إدارة العلاقات يقول إن العميل يقيم في ليون؛ نظام الفوترة يقول باريس. أحدها يحتفظ برقم هاتف لم يطلبه أحد منذ ثلاث سنوات؛ والآخر يحتفظ برقم وُثِّق الشهر الماضي. قواعد البقاء (survivorship) هي مجموعة القواعد التي تنتقي القيمة التي سيقدّمها السجل الذهبي.

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

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

دوّن هذه القواعد لكل حقل، لا لكل سجل. فالمصدر الفائز لعنوان ليس هو المصدر الفائز لنطاق مخاطر. واحتفظ بكل قيمة مرشّحة رفضها السجل، موسومة بأصلها ووقتها. حين يسأل مُصادِق لماذا يُظهِر السجل الذهبي عنواناً بعينه، تريد أن تُريه القيمة التي قدّمها، والقيم التي رفضها، والقاعدة التي رجّحت بينها. هذا هو مسار النسب (lineage) لديك، وهو ما يحوّل السجل من كتلة معتمة إلى شيء يقبله كل من المدقّق ومراجع مخاطر النماذج (model risk reviewer).

صحّة النقطة الزمنية أو لا شيء

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

الحل هو معاملة السجل كسجل قابل للإلحاق فقط (append-only) وثنائي الزمن (bitemporal). خزّن ساعتين: متى كان الشيء صحيحاً في العالم، ومتى سجّلته أنظمتك. عندها يصبح كل قراءة استعلاماً كما كان الحال في لحظة مختارة (as-of). فمعاملة تعود لمارس تُقيَّم مقابل العميل كما كان مفهوماً في مارس. وتشغيل مطابقة (reconciliation) يعيد إنتاج ما ادّعاه تقرير بالضبط يوم نُشر، لأن السجل قادر على العودة بالزمن.

هذا أيضاً ما يجعل السجل آمناً للتقديم إلى مخزن ميزات (feature store). فالميزات المحسوبة من سجل ذهبي ثنائي الزمن تحمل تواريخ سريان صحيحة، بحيث تقرأ مجموعة التدريب ومسار التقييم اللحظي (online scoring) التعريف نفسه للعميل في اللحظة المنطقية نفسها. من دون ذلك، يتسلّل انحراف التدريب عن التقديم (training-serving skew) عبر طبقة البيانات ذاتها، ولن يُغلق أي قدر من ضبط النموذج تلك الفجوة.

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