بناء خطوط معالجة الخصائص بدقة زمنية لحظية

تجيب خطوط معالجة الخصائص ذات الدقة الزمنية اللحظية عن سؤال واحد لكل قيمة تنتجها: هل كانت هذه القيمة معلومة في اللحظة التي نحاول التنبؤ عندها؟ تكون الخاصية صحيحة زمنياً (point-in-time correct) حين لا تعكس إلا البيانات التي وصلت فعلاً وسُجّلت قبل الطابع الزمني للحدث أو عنده. أخطئ في هذا القيد، وسيتعلّم نموذجك المستقبل، ويحقّق نتائج رائعة خارج الإنتاج، ثم ينهار يوم إطلاقه فعلياً.

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

من أين يتسرّب المستقبل

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

أكثر الأنماط التي نراها شيوعاً:

• خصائص مشتقة من الهدف. حقل يُملأ عند إغلاق الحالة، لا عند اتخاذ القرار. مثل chargeback_amount وdays_to_default وfinal_disposition. هذه ترتبط ارتباطاً تاماً بالتصنيف (label) لأنها جزئياً هي التصنيف نفسه.
• تجميعات على نافذة زمنية خاطئة. عدد معاملات خلال 30 يوماً محسوب بنافذة تمتد من الحدث إلى الأمام، أو نافذة تشمل ضمناً الحدث الجاري تقييمه.
• بيانات مصدر مُعاد صياغتها. يرسل مورّد رقماً ثم يصحّحه بعد أسبوع. إذا خزّنت النسخة الأحدث فقط، فإن كل اختبار تراجعي (backtest) يقرأ التصحيح بدلاً من الرقم الأصلي المنشور. وتصحيحات نهاية الربع من أكثر المخالفات شيوعاً.
• أبعاد بطيئة التغيّر تُعامَل كأنها ثابتة. عنوان، أو رمز قطاع، أو سجل مالك منتفع (beneficial owner) تغيّر بعد الحدث لكنه يطمس الصف الذي تصله به.

لا شيء من هذه يُطلق خطأً. كلها تضخّم المقاييس خارج الإنتاج، ولا يصمد أي من هذا التحسّن أمام احتكاكه بالإنتاج.

طابع زمن المعرفة هو العمود الحامل

يبدأ الحل بالاعتراف بأن معظم بيانات التمويل تحمل ساعتين. هناك وقت وقوع الشيء، أي زمن الحدث أو الزمن الساري (effective time). وهناك وقت اكتشاف أنظمتك له، أي زمن المعرفة أو زمن الإدخال (ingestion time). تسوية حوالة تتم يوم الاثنين لكنها تُقيَّد في دفترك بعد ظهر الثلاثاء. وكالة تقييم تحدّث درجة بتاريخ مرجعي هو الأول من الشهر، لكنك تتسلّم الملف في الرابع.

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

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

الوصلات عند تاريخ محدد، منجَزة بحيث تصمد على نطاق واسع

القلب الآلي لخط المعالجة هو الوصلة عند تاريخ محدد (as-of join). لكل حدث مُصنَّف، تمدّ يدك إلى مصدر خاصية وتسحب آخر قيمة يقع طابعها الزمني عند حدّ الحدث الفاصل أو قبله. لا القيمة المساوية تماماً، ولا الأقرب، ولا أبداً ما جاء بعده. إنجاز هذا صفاً صفاً بسيط لكنه بطيء بشكل لا يُحتمل؛ وإنجازه كعملية على مجموعات هو دمج مرتّب (sorted merge) على مفتاح الزمن داخل كل كيان.

بضع قواعد نلتزم بها:

• حدّ فاصل واحد لكل حدث، يُحسب مرة واحدة. كل خاصية لحدث معيّن تُحلّ إزاء الطابع الزمني نفسه عند التاريخ المحدد. فإن استخدمت خصائص مختلفة حدوداً فاصلة مختلفة، لن تستطيع أن تستدلّ على ما رآه النموذج.
• المسار البرمجي نفسه خارج الإنتاج وداخله. التحويل الذي يبني صفوف التدريب وذاك الذي يخدم طلباً حياً ينبغي أن يكونا الدالة نفسها تقرأ التعريفات نفسها. حين يتباعدان، يتسلّل انحراف التدريب عن الخدمة (training-serving skew) ويبدو تماماً كالتسرّب.
• تأخير متعمّد للخاصية. إذا كانت إشارة ما تصل عادة بعد يومين من زمن حدثها، فإننا أحياناً نؤخّر الخصائص بمقدار ذلك التأخر حتى في التدريب، كي يتعلّم النموذج على مستوى الحداثة الذي سيتوفّر له فعلاً عند الاستدلال. والتفاؤل بشأن وصول البيانات هو بحد ذاته صورة من صور التسرّب.
• سلسلة نسب (lineage) يمكن أن تعرضها على مدقّق. ينبغي أن تُنسب كل قيمة خاصية إلى السجلات والنسخ المصدرية التي أنتجتها، عند الطوابع الزمنية التي كانت سارية. وفي ظل توقعات إدارة مخاطر النماذج بموجب SR 11-7، وفي أي شيء يمسّ قراراً سلبياً بحق العميل، لا يكون هذا الأثر اختيارياً.

إثبات أن خط المعالجة أمين

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

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

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