متجر الميزات (Feature Store): كيف أنقذنا مشروعنا من جحيم “الانحراف التدريبي-التنبؤي”؟

مقدمة: لما النموذج تبعنا “انجَن” في الإنتاج

يا جماعة الخير، بدي أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه بحياتي. كنا شغالين على نظام توصيات (Recommendation System) لمتجر إلكتروني كبير. فريق علم البيانات، وأنا معهم، قضينا أسابيع نبني ونحسن في نموذج التعلم الآلي. النتائج في مرحلة الاختبار كانت خرافية، دقة عالية، ومقاييس بتقول إنه النموذج هاد رح يكسر الدنيا.

احتفلنا، وشربنا القهوة، وسلمنا النموذج لفريق هندسة البرمجيات عشان يرفعوه على الإنتاج (Production). الأيام الأولى كانت الأمور تمام التمام. لكن بعد أسبوع، بلشت توصلنا شكاوي. مدير المنتج بحكي: “يا أبو عمر، شو القصة؟ المستخدمين بطلوا يتفاعلوا مع التوصيات!”، وفريق التسويق بقول: “المبيعات اللي جاية من التوصيات نزلت بشكل حاد!”.

دخلنا في دوامة، ما إلها أول من آخر. قضينا أيام وليالي نفحص كل إشي: كود النموذج، البنية التحتية للخوادم، واجهة برمجة التطبيقات (API)… كل شيء كان سليم 100%. صابنا إحباط شديد، وصرت أشك في كل شغلي. معقول كل هالتعب راح عالفاضي؟ معقول الذكاء الاصطناعي هاد “كلام فاضي” زي ما بحكوا بعض الناس؟

في لحظة يأس، وإحنا بنقارن سجلات (logs) نظام التدريب مع سجلات نظام الإنتاج، واحد من المهندسين الشباب صاح: “يا جماعة، شوفوا هون! قيمة ميزة ‘عدد عمليات الشراء في آخر 7 أيام’ مختلفة بين النظامين لنفس المستخدم وفي نفس اللحظة!”.

كانت هاي هي اللحظة الفارقة. اكتشفنا إنه العالم اللي بنُدرّب فيه النموذج، غير تمامًا عن العالم اللي بعيش فيه النموذج وبتخذ قراراته. كنا ضحية لواحد من أخطر وأخبث الأعداء في عالم تعلم الآلي: “الانحراف التدريبي-التنبؤي” (Training-Serving Skew). ومن هون بلشت رحلة الإنقاذ الحقيقية.

ما هو “الانحراف التدريبي-التنبؤي” (Training-Serving Skew)؟

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

هذا الانحراف له عدة أشكال، وأخطرها هو اللي ما بننتبهله:

أنواع الانحراف الشائعة

• الانحراف الزمني (Temporal Skew): بتدرّب نموذجك على بيانات من السنة الماضية، لكن سلوك المستخدمين اليوم تغير تمامًا بسبب مواسم، أحداث، أو تريندات جديدة. النموذج “عايش في الماضي” وغير قادر على مجاراة الحاضر.
• انحراف المفهوم (Concept Drift): هاد قريب من الانحراف الزمني، لكنه أعمق. هون العلاقة بين المدخلات والمخرجات نفسها بتتغير. مثلاً، في فترة وباء كورونا، أصبح “معقم اليدين” فجأة سلعة مرتبطة بـ “الكمامات”، وهو ارتباط لم يكن موجودًا من قبل.
• الانحراف في التنفيذ (Implementation Skew): وهاد هو الوحش اللي واجهناه في قصتنا. هون المشكلة مش في البيانات نفسها، بل في طريقة حساب الميزات (Features). بتكون عندك نسختين من الكود اللي بحسب الميزات: واحدة للتدريب (عادة بتكون مكتوبة بـ Python في Jupyter Notebook) وواحدة للإنتاج (ممكن تكون مكتوبة بـ Java أو Go في خدمة مصغرة Microservice). أي اختلاف بسيط بين هدول النسختين، حتى لو كان خطأ صغير، رح يسبب كارثة.

جذور المشكلة: ليش بصير هاد الحكي؟

المشكلة هاي مش صدفة، إلها أسباب جذرية في طريقة بناء أنظمة تعلم الآلي التقليدية:

“في عالم تعلم الآلي، غالبًا ما يتحدث علماء البيانات بلغة (Python)، بينما يتحدث مهندسو البرمجيات بلغة أخرى (مثل Java أو Go). ترجمة منطق الميزات بين هاتين اللغتين هي وصفة شبه مؤكدة للأخطاء والانحراف.”

• فرق في الفِرق والتكنولوجيا (Different Teams, Different Stacks): عالم البيانات يستخدم مكتبات مثل Pandas و Scikit-learn لتحضير البيانات وتدريب النموذج في بيئة “دفعة واحدة” (Batch). مهندس البرمجيات، من جهة أخرى، يبني خدمة سريعة ومنخفضة التأخير (Low-latency) للإنتاج باستخدام لغات وتقنيات مختلفة تمامًا. عملية “الترجمة” اليدوية لمنطق حساب الميزات بين العالمين هي المصدر الأول للأخطاء.
• فرق في مصادر البيانات (Different Data Sources): بيانات التدريب غالبًا ما تأتي من مستودع بيانات ضخم (Data Warehouse) مثل BigQuery أو Snowflake. بينما بيانات التنبؤ في الإنتاج قد تأتي من قاعدة بيانات تشغيلية (Operational Database) أو من مجرى أحداث فوري (Event Stream) مثل Kafka. الاختلاف في المصادر يمكن أن يؤدي إلى اختلافات دقيقة في البيانات.
• فرق في التوقيت (Different Timings): عند التدريب، قد تحسب ميزة مثل “متوسط قيمة سلة المشتريات لآخر شهر” دفعة واحدة لكل المستخدمين. أما في الإنتاج، تحتاج لحسابها بسرعة فائقة لمستخدم واحد فقط. هذا الاختلاف في سياق الحساب (Batch vs. Real-time) يمكن أن يكشف عن أخطاء منطقية لم تكن واضحة في بيئة التدريب.

الحل المنقذ: رحّبوا بـ “متجر الميزات” (Feature Store)

بعد ما فهمنا أصل المشكلة، كان واضح إنه الحل مش في “تصليح الأخطاء” كل مرة، بل في تغيير الطريقة اللي بنشتغل فيها من الأساس. الحل كان بتبني مفهوم جديد نسبيًا في عالم عمليات تعلم الآلي (MLOps) اسمه: متجر الميزات (Feature Store).

متجر الميزات هو منصة مركزية لإدارة دورة حياة الميزات الهندسية في مؤسستك. فكر فيه على أنه “مصدر الحقيقة الوحيد” (Single Source of Truth) لكل ميزاتك. هو اللي بوحد طريقة تعريف، حساب، تخزين، وتقديم الميزات لكل من بيئة التدريب وبيئة الإنتاج.

المكونات الأساسية لمتجر الميزات

• سجل الميزات (Registry): مكان مركزي لتعريف الميزات، توثيقها، واكتشافها. كل ميزة إلها اسم، وصف، مالك، ونوع بيانات.
• محرك الحساب (Transformation Engine): هاد هو القلب النابض. هو المسؤول عن تنفيذ منطق حساب الميزة. والنقطة الجوهرية هنا هي أن نفس كود التحويل يُستخدم لتوليد الميزات التاريخية للتدريب والميزات الفورية للتنبؤ.
• مخزن غير متصل (Offline Store): قاعدة بيانات تحليلية (مثل BigQuery, Snowflake, S3) لتخزين كميات هائلة من قيم الميزات التاريخية. علماء البيانات يستخدمون هذا المخزن للحصول على بيانات التدريب.
• مخزن متصل (Online Store): قاعدة بيانات سريعة جدًا ومنخفضة التأخير (مثل Redis, DynamoDB) لتخزين أحدث قيمة لكل ميزة. خدمات الإنتاج تستخدم هذا المخزن للحصول على الميزات بسرعة فائقة لعمل تنبؤات فورية.
• واجهة التقديم (Serving API): واجهة برمجة تطبيقات (API) عالية الأداء تتيح لنماذج الإنتاج طلب “متجه ميزات” (Feature Vector) لكيان معين (مثل مستخدم أو منتج) والحصول عليه في أجزاء من الثانية.

كيف أنقذ متجر الميزات مشروعنا؟ (مثال عملي)

خلونا نرجع لمثالنا، الميزة اللي سببتلنا المشكلة كانت user_7day_purchase_count. الخطأ كان بسيط جدًا لكنه مدمر:

• في كود التدريب (Python)، كنا نحسب عدد المشتريات في الفترة [now - 7 days, now]، أي شاملة لليوم السابع.
• في كود الإنتاج (Java)، وبسبب خطأ بسيط، كان الحساب يتم على الفترة (now - 7 days, now]، أي مستثنيًا أي عملية شراء حدثت بالضبط قبل 7 أيام.

مع متجر الميزات، اختلف الوضع تمامًا. استخدمنا أداة مفتوحة المصدر مثل Feast لتعريف الميزة مرة واحدة فقط.

الخطوة 1: تعريف الميزة في مكان واحد (باستخدام صيغة تشبه Feast)

# feature_repo/definitions.py
from feast import Entity, FeatureView, FileSource
from feast.types import Int64
from datetime import timedelta

# 1. تعريف الكيان اللي بنعمله ميزات (مثلاً: المستخدم)
user = Entity(name="user_id", description="User ID")

# 2. تعريف مصدر البيانات الخام
purchase_logs_source = FileSource(
    path="data/purchase_logs.parquet",
    timestamp_field="event_timestamp"
)

# 3. تعريف "عرض الميزات" الذي يحتوي على منطق الحساب
# هذا هو التعريف الوحيد للميزة في كل النظام
user_purchase_view = FeatureView(
    name="user_7day_purchase_count",
    entities=[user],
    ttl=timedelta(days=8), # مدة صلاحية الميزة
    source=purchase_logs_source,
    online=True, # اجعل هذه الميزة متاحة للإنتاج الفوري
    features=[
        # يمكن إضافة تحويلات معقدة هنا
        # لكن Feast يقوم بالتحويلات التجميعية البسيطة تلقائياً
    ],
    # في أدوات أكثر تقدماً، نكتب كود التحويل هنا بلغة SQL أو Python
)

الخطوة 2: توليد البيانات

نقوم بتشغيل أمر واحد من متجر الميزات. هذا الأمر يقرأ البيانات الخام، يحسب الميزات التاريخية، ويخزنها في المخزن غير المتصل (للتدريب) والمخزن المتصل (للتنبؤ).

$ feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")

الخطوة 3: الحصول على بيانات التدريب

عالم البيانات الآن لا يكتب أي منطق لحساب الميزات، بل يطلبها مباشرة من متجر الميزات.

# training.py
from feast import FeatureStore

store = FeatureStore(repo_path="feature_repo")

# dataframe يحتوي على أرقام المستخدمين وتواريخ لإنشاء بيانات التدريب
entity_df = ... 

training_data = store.get_historical_features(
    entity_df=entity_df,
    features=["user_7day_purchase_count:count"] # اسم الميزة كما هي معرّفة
).to_df()

# تدريب النموذج باستخدام training_data...

الخطوة 4: الحصول على بيانات التنبؤ في الإنتاج

خدمة الإنتاج أيضًا لا تكتب أي منطق، بل تطلب الميزة من المخزن المتصل السريع.

# serving_api.py (مثال بلغة Python للتوضيح)
from feast import FeatureStore

store = FeatureStore(repo_path="feature_repo")

# طلب الميزات لمستخدم واحد
feature_vector = store.get_online_features(
    features=["user_7day_purchase_count:count"],
    entity_rows=[{"user_id": 12345}]
).to_dict()

# استخدام feature_vector لعمل التنبؤ...
# feature_vector -> {'user_7day_purchase_count:count': [12]}

بهذه الطريقة، اختفى “الانحراف في التنفيذ” تمامًا. نفس التعريف، نفس المنطق، نفس الميزة… في التدريب وفي الإنتاج. أصبحنا واثقين 100% أن النموذج يرى نفس البيانات تمامًا في كلا العالمين.

نصائح من خبرة أبو عمر

• ابدأ بسيطًا: لا تحتاج إلى شراء أغلى وأعقد متجر ميزات من اليوم الأول. يمكنك بناء نسخة مبسطة (Proto-Feature Store) باستخدام مبادئه الأساسية: سكربتات Python مشتركة، قاعدة بيانات Redis للمخزن المتصل، ومخزن بيانات مثل S3 أو BigQuery للمخزن غير المتصل. المهم هو تبني مبدأ المصدر الواحد للحقيقة.
• التعاون هو المفتاح: متجر الميزات ليس مسؤولية فريق علم البيانات وحده أو فريق الهندسة وحده. هو جسر يربط بين العالمين. “مش شغل فلان أو علان، هاد شغل الكل”. يجب أن يشارك الجميع في تصميمه وتبنيه.
• المراقبة ثم المراقبة: تطبيق متجر الميزات ليس نهاية المطاف. يجب عليك بناء لوحات متابعة (Dashboards) لمراقبة “نضارة” الميزات (Feature Freshness)، جودة البيانات المدخلة، وتأخير خدمة الميزات في الإنتاج.
• فكر في التكلفة: حساب وتخزين الميزات، خاصة الميزات الفورية (Real-time)، يمكن أن يكون مكلفًا. خطط لميزاتك بحكمة، ولا تحسب إلا ما تحتاجه فعلًا.

الخلاصة: الأساسات أولاً! 🚀

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

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

نصيحتي الأخيرة لكل من يعمل في هذا المجال: قبل أن تبني أعقد النماذج، وقبل أن تستخدم أحدث الشبكات العصبونية، اسأل نفسك: هل بيانات التدريب وبيانات الإنتاج عندي تتحدثان نفس اللغة؟ إذا كان الجواب “لا” أو “لا أعرف”، فمهمتك الأولى هي توحيدهما. ركز على الأساسات، والنتائج المذهلة ستأتي حتمًا. 🙏