دفعي أم آني؟ أنماط الاستدلال في الذكاء الاصطناعي المالي

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

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

ما الذي يحتمله القرار

السؤال المفيد ليس عن سرعة النموذج، بل عن العمر المسموح لمدخلاته لحظة تصرّف أحدهم بناءً على المخرج. دوّن ذلك لكل حالة استخدام قبل أن تمسّ معمارية الخدمة.

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

بمجرد أن تصوغ المسألة على أنها احتمال، ينكشف التقسيم من تلقاء نفسه. الجانب الدفعي يتولّى كل ما يُشتق من بيانات جرت مطابقتها وتسويتها بالفعل. والجانب الآني يتولّى فقط ما يُدخله الطلب. والحدّ بينهما هو حيث يذهب معظم جهد التصميم، لأن هناك تتصادم القِدَم مع صحّة النقطة الزمنية (point-in-time).

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

احسب مسبقًا، ثم ابحث

النمط الدفعي سهل الوصف وسهل الخطأ فيه. تُشغّل النموذج على لقطة (snapshot) من الخصائص، وتكتب كل نتيجة إلى مخزن منخفض زمن الاستجابة مع مفتاح الكيان وختم وقت مرجعي (as-of timestamp)، وعند الطلب تجلب القيمة المخزّنة. تنتقل كلفة الاستدلال خارج المسار الساخن كليًا. تجري الخدمة المتصلة قراءة مفتاح-قيمة بدل استدعاء نموذج، فيصبح زمن استجابتها محدودًا بالمخزن، وتنهار كلفتها لكل طلب.

ثلاثة أمور يجب أن تتحقق لكي يصمد هذا:

• كل درجة مخزّنة تحمل ختم الوقت المرجعي للبيانات التي حُسبت منها. من دونه لا تستطيع الإجابة عن سؤال “اعتبارًا من متى كان هذا صحيحًا”، ولا تستطيع إعادة بناء قرار من أجل مسار تدقيق (audit trail) أو مراجعة مخاطر نموذج (model-risk review). درجة مخزّنة بلا وقت مرجعي لن تنجو من تلك المراجعة؛ إذ تطلب من أحدهم أن يثق برقم بلا أثر منشأ (provenance).
• المهمة الدفعية متساوية القدرة (idempotent) وقابلة للاستنساخ. إعادة تشغيلها على اللقطة نفسها تنتج الدرجات نفسها. وإن لم تكن كذلك، فلديك لا-حتمية مخفية، وتصبح سلسلة النَّسَب (lineage) لديك عديمة القيمة أول مرة يسأل فيها أحدهم عن سبب تغيّر رقم.
• الخصائص التي تغذّي المسار الدفعي صحيحة زمنيًا (point-in-time correct). الحساب المسبق يسهّل إدخال التسريب (leakage)، لأن الإغراء يدفعك إلى الربط بما يحمله المستودع الآن بدلًا مما كان معلومًا عند حدّ الوقت المرجعي. درجة دفعية مبنية على بيانات مستقبلية (lookahead) ستبدو ممتازة دون اتصال، ثم تفشل بصمت في الإنتاج.

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

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

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

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

هنا يختبئ انحراف التدريب/الخدمة (train/serve skew). الخاصية التي تحسبها في نافذة تدفّق لحظة الطلب يجب أن تطابق الخاصية التي يعيد بناءها مسار المعالجة الدفعي زمنيًا (point-in-time) أثناء التدريب. فإن بُني عدّاد التدفّق وعدّاد التدريب بشيفرتين مختلفتين، انحرفا، وبدأت مقاييسك دون اتصال تكذب عليك. الخاصية نفسها، بتعريف واحد، يمارسها المساران كلاهما. هذا الانضباط هو ما يجعل مخزن الخصائص (feature store) يستحقّ وجوده في هذه المعمارية.

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