في إطار بناء نموذج تنبؤي لسلوك الشراء لدى العملاء، واجهت تحديات شائعة في هندسة الميزات، تُصنف إلى قسمين رئيسيين: إدارة غير كافية للميزات، وتأخير عالٍ في عملية هندسة الميزات. لحل هذه التحديات، تم استخدام مخزن الميزات (Feast) والإطار الموزع للحساب (Ray) لبناء أنظمة متكاملة وقابلة للتوسع في بيئات التعلم الآلي الإنتاجية. السياق يدور حول بناء نموذج تنبؤي لشراء عميل خلال 30 يومًا، باستخدام بيانات من مشروع UCI Online Retail التي تغطي عمليات شراء تجارية لمتجر إلكتروني بريطاني بين ديسمبر 2010 وديسمبر 2011. تم التركيز على ميزات بسيطة مبنية على نافذة زمنية سابقة مدتها 90 يومًا، مثل مؤشرات RFM (الاستجابة، التكرار، القيمة المالية)، بالإضافة إلى سلوك العميل. تم تصميم نموذج نافذة متكررة (Rolling Window) بحيث يتم حساب الميزات من نافذة 90 يومًا قبل كل تاريخ "نقطة قطع" (cutoff)، بينما تُحسب العلامات (1 إذا شرَى العميل، 0 إذا لم يشترِ) من نافذة 30 يومًا بعدها. وبما أن نقاط القطع تفصل بينها 30 يومًا، فإن النموذج يُنتج تسع صور (snapshots) من البيانات. لإدارة الميزات بكفاءة، تم استخدام Feast، وهو مخزن ميزات مفتوح المصدر يُعد مصدرًا موحدًا للميزات أثناء التدريب والاستخدام الفعلي. يدعم Feast الميزات "الخارجية" (offline) والمتزامنة (online)، مع التركيز هنا على الميزات الخارجة لتناسب السيناريو التنبؤي. يتم تعيين الميزات (مثل RFM وسلوك العميل) في مخزن مركزي عبر ما يُعرف بـ "View" (مُشاهد الميزات)، مع تحديد مصادر البيانات وحقول التوقيت لضمان صحة البيانات في لحظة معينة (point-in-time correctness). أما Ray، فهو إطار موزع للحساب يُستخدم لتوسيع العمليات الحسابية عبر عدة نوى أو أجهزة. في هذا السياق، تم استخدام Ray Core لتشغيل مهام متوازية لحساب الميزات لكل نافذة زمنية من أصل تسع نوافذ، مما يقلل زمن التنفيذ بشكل كبير. يتم تغليف دالة الحساب بـ @ray.remote لتحويلها إلى مهمة موزعة، ثم تنفيذها عبر مجموعة من العمال (workers). في التنفيذ، تم تهيئة البيئة باستخدام حزم Python مثل Feast وRay وPostgreSQL (عبر Docker) كمصدر مركزي للسجل. تم تعريف الكيانات (مثل customer_id) ومصادر البيانات، ثم إنشاء مُشاهد ميزات للفئتين المذكورتين. تم تكوين ملف feature_store.yaml لتحديد بيئة التخزين والسجل، مع استخدام PostgreSQL بدلًا من SQLite لمحاكاة بيئة إنتاجية قادرة على دعم الوصول المتزامن. بعد تطبيق التكوين عبر feast apply، أصبحت الميزات جاهزة للحصول عليها. لتدريب النموذج، تم إنشاء "مُسلسل كيانات" (entity spine) يحتوي على معرفات العملاء وتاريخ الحدث، ثم استُخدمت لاسترجاع الميزات المطلوبة عبر واجهة Feast، مع ضمان التوقيت الصحيح للبيانات. في مرحلة التنبؤ، تكرر نفس العملية، مع تغيير تاريخ القطع لتمثيل الحالات المستقبلية. الفائدة الأساسية هنا تكمن في التماسك: الميزات المستخدمة في التدريب والتنبؤ متطابقة تمامًا، مما يقلل من تفاوت النموذج. النتيجة النهائية هي بناء أنبوب تدريب وتنبؤ متكامل، يُحسن من كفاءة هندسة الميزات، ويضمن التكرار والموثوقية، مع إمكانية التوسع في بيئة إنتاجية حقيقية. استخدام Feast وRay معًا يمثل نموذجًا مثاليًا لمعالجة التحديات التقليدية في هندسة الميزات، وتمكين الفرق من بناء أنظمة تعلم آلي فعّالة وقابلة للتطوير.