معاملاتنا كانت تُسرق في وضح النهار: كيف أنقذنا ‘الكشف عن الاحتيال بالتعلم الآلي’ من جحيم الخسائر المالية؟

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

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

نظامنا التقليدي القائم على القواعد (Rule-based system) كان مثل حارس أمن عجوز يغفو في نوبته. المحتالون كانوا أذكى منه، يغيرون أساليبهم بسرعة، ونحن كنا نخسر المال والسمعة مع كل دقيقة تمر. هنا، كان لا بد من حل جذري، حل لا يعتمد على قواعد ثابتة، بل يتعلم ويتطور. كان هذا هو المدخل إلى عالم “الكشف عن الاحTIال باستخدام تعلم الآلة”، القصة التي سأرويها لكم اليوم.

لماذا تفشل الأنظمة التقليدية في كشف الاحتيال؟

قبل أن نغوص في الحل، دعونا نفهم أصل المشكلة. الأنظمة التقليدية تعتمد على مجموعة من القواعد الصريحة التي يكتبها المبرمجون والمحللون الماليون. على سبيل المثال:

  • إذا كانت قيمة المعاملة أكبر من 1000 دولار، ضعها قيد المراجعة.
  • إذا تمت 3 معاملات من نفس البطاقة في أقل من 5 دقائق، ارفضها.
  • إذا كان عنوان IP من دولة مدرجة في القائمة السوداء، امنع المعاملة.

هذه القواعد مفيدة، لكنها قاصرة جداً. لماذا؟

  1. ثابتة وجامدة: المحتالون يغيرون تكتيكاتهم باستمرار. قد يبدأون في تنفيذ عمليات بأقل من 1000 دولار، أو يوزعون هجماتهم على فترات زمنية أطول لتجنب اكتشافهم.
  2. تولد إنذارات كاذبة كثيرة (False Positives): قد ترفض معاملة شرعية لعميل حقيقي فقط لأنها تطابقت مع إحدى القواعد الصارمة، مما يسبب إحباطاً للعميل وخسارة للشركة.
  3. لا تكتشف الأنماط المعقدة: الاحتيال الحديث ليس مجرد معاملة واحدة كبيرة، بل شبكة معقدة من العلاقات بين مستخدمين وهميين، وأجهزة مختلفة، وسلوكيات تبدو طبيعية إذا نظرت لكل منها على حدة.

باختصار، كنا نحاول محاربة دبابة بمسدس ماء. كان لا بد من استدعاء سلاح أذكى.

تعلم الآلة: الحارس الذي لا ينام

تعلم الآلة (Machine Learning) هو فرع من الذكاء الاصطناعي يسمح للأنظمة بالتعلم من البيانات وتحديد الأنماط واتخاذ القرارات بأقل قدر من التدخل البشري. بدلاً من إعطائه قواعد صريحة، نحن نعطيه بيانات تاريخية للمعاملات (آلاف أو ملايين المعاملات) ونخبره: “هذه كانت شرعية، وهذه كانت احتيالية. الآن، تعلم الفرق بينهما!”.

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

الرحلة العملية لبناء نظام كشف الاحتيال

دعونا نتحدث بشكل عملي. كيف نبني هذا النظام “بالزبط”؟ العملية تمر بعدة مراحل حاسمة.

المرحلة الأولى: جمع البيانات (الذهب الحقيقي)

البيانات هي وقود نماذج تعلم الآلة. بدون بيانات جيدة، حتى أفضل الخوارزميات ستفشل. في حالتنا، كنا بحاجة إلى كل معلومة ممكنة عن كل معاملة:

  • بيانات المعاملة: المبلغ، العملة، وقت وتاريخ المعاملة.
  • بيانات المستخدم: تاريخ إنشاء الحساب، عدد المعاملات السابقة، متوسط قيمة معاملاته.
  • بيانات الجهاز والجلسة: عنوان IP، نوع الجهاز (موبايل/ديسكتوب)، بصمة المتصفح (Browser Fingerprint).
  • بيانات الموقع: بلد المعاملة، وهل تتطابق مع بلد إصدار البطاقة أو بلد إقامة المستخدم المعتاد.
  • الوسم (Label): أهم معلومة على الإطلاق! هل كانت هذه المعاملة احتيالية (Fraud) أم شرعية (Legit)؟ هذا هو ما سيتعلم منه النموذج.

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

المرحلة الثانية: هندسة الميزات (الفن السري)

البيانات الخام ليست كافية. نحتاج إلى تحويلها إلى “ميزات” (Features) ذات معنى يمكن للنموذج فهمها. هذه هي مرحلة هندسة الميزات، وهي فن وعلم في آن واحد. هنا قمنا بتحويل البيانات الأولية إلى رؤى أعمق. أمثلة على ميزات قمنا بإنشائها:

  • frequency_last_hour: عدد المعاملات لنفس المستخدم في الساعة الأخيرة.
  • amount_deviation_from_avg: مدى انحراف مبلغ المعاملة الحالية عن متوسط معاملات المستخدم السابقة.
  • is_new_device: هل هذا الجهاز يستخدم لأول مرة في هذا الحساب؟ (قيمة 1 أو 0).
  • ip_country_vs_card_country: هل بلد عنوان IP يختلف عن بلد إصدار البطاقة؟ (قيمة 1 أو 0).

هذه الميزات تعطي النموذج سياقاً أوسع بكثير من مجرد النظر إلى مبلغ المعاملة.

المرحلة الثالثة: اختيار الخوارزمية وتدريب النموذج

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

  • Logistic Regression: خوارزمية بسيطة وسريعة، جيدة كنقطة بداية لفهم أهمية الميزات.
  • Random Forest: ممتازة جداً! هي عبارة عن مجموعة من “أشجار القرار” تعمل معاً. قوية جداً في التعامل مع أنواع مختلفة من البيانات وتقاوم الـ Overfitting.
  • Gradient Boosting (مثل XGBoost أو LightGBM): هذه هي “الأسلحة الثقيلة”. دقيقة للغاية وقادرة على التقاط علاقات معقدة جداً. غالباً ما تكون هي الخيار الأفضل في المسابقات وفي أنظمة الإنتاج الحقيقية.

للتوضيح، إليكم مثال مبسط جداً باستخدام Python ومكتبة scikit-learn. تخيل أن لدينا ملف transactions.csv يحتوي على بياناتنا.


import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

# 1. تحميل وهندسة الميزات (بشكل مبسط)
df = pd.read_csv('transactions.csv')

# Features (X) and Target (y)
# الميزات التي سيستخدمها النموذج للتعلم
features = ['amount', 'frequency_last_hour', 'is_new_device', 'ip_country_vs_card_country']
target = 'is_fraud' # هذا هو ما نريد توقعه (1 = احتيال, 0 = شرعي)

X = df[features]
y = df[target]

# 2. تقسيم البيانات: جزء للتدريب وجزء للاختبار
# 80% للتدريب، 20% للاختبار لتقييم أداء النموذج على بيانات لم يرها من قبل
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42, stratify=y)

# 3. اختيار النموذج وتدريبه
# سنستخدم Random Forest كمثال
model = RandomForestClassifier(n_estimators=100, random_state=42, class_weight='balanced')

print("بدء تدريب النموذج...")
model.fit(X_train, y_train)
print("اكتمل التدريب!")

# 4. تقييم النموذج
print("nتقييم أداء النموذج على بيانات الاختبار:")
predictions = model.predict(X_test)
print(classification_report(y_test, predictions))

# 5. استخدام النموذج لتوقع معاملة جديدة
new_transaction = {
    'amount': [47.5],
    'frequency_last_hour': [3],
    'is_new_device': [1],
    'ip_country_vs_card_country': [1]
}
new_df = pd.DataFrame(new_transaction)

prediction = model.predict(new_df)
prediction_proba = model.predict_proba(new_df)

if prediction[0] == 1:
    print(f"nتوقع المعاملة الجديدة: احتيال! (بنسبة ثقة {prediction_proba[0][1]*100:.2f}%)")
else:
    print(f"nتوقع المعاملة الجديدة: شرعية. (بنسبة ثقة {prediction_proba[0][0]*100:.2f}%)")

نصيحة أبو عمر بخصوص التقييم: لا تنخدع بمقياس الدقة (Accuracy) وحده! في بيانات الاحتيال، 99% من المعاملات تكون شرعية. يمكن لنموذج غبي أن يتوقع “شرعي” لكل المعاملات ويحصل على دقة 99%، لكنه عديم الفائدة لأنه لم يكتشف أي عملية احتيال. ركز على مقاييس مثل Precision (الدقة في التنبؤات الإيجابية) و Recall (القدرة على التقاط جميع حالات الاحتيال الفعلية). هناك موازنة بينهما يجب أن تديرها بحكمة.

تحديات العالم الحقيقي وما بعد الكود

بناء النموذج كان نصف المعركة فقط. المعركة الحقيقية بدأت عند محاولة تطبيقه في بيئة الإنتاج الحية.

مشكلة البيانات غير المتوازنة (Imbalanced Data)

كما ذكرت، عدد المعاملات الاحتيالية قليل جداً مقارنة بالشرعية (مثلاً 1 لكل 1000). هذا يجعل النموذج يميل إلى تجاهل فئة الاحتيال. لحل هذه المشكلة، استخدمنا تقنيات مثل:

  • تعديل وزن الفئات (Class Weighting): كما في مثال الكود class_weight='balanced'، هذا يخبر الخوارزمية أن “تعاقب” نفسها بشدة أكبر إذا أخطأت في تصنيف معاملة احتيالية.
  • أخذ العينات (Sampling): إما بتقليل عدد العينات من الفئة الأكبر (Undersampling) أو بتوليد عينات اصطناعية من الفئة الأصغر (Oversampling) باستخدام تقنيات مثل SMOTE.

سباق التسلح المستمر

المحتالون لا يستسلمون. عندما بدأ نظامنا الجديد في إيقاف هجماتهم، بدأوا في تغيير أساليبهم. ولّا هو النموذج تبعنا بلش يضعف أداؤه. هذا يعني أن النموذج ليس شيئاً تبنيه مرة واحدة وتنساه. يجب أن يكون هناك نظام مستمر لـ:

  • المراقبة (Monitoring): مراقبة أداء النموذج باستمرار.
  • إعادة التدريب (Retraining): إعادة تدريب النموذج بشكل دوري (مثلاً كل أسبوع) على البيانات الجديدة ليتعلم الأنماط الاحتيالية الحديثة.

الحاجة إلى السرعة والتفسير

يجب أن يعطي النموذج قراره في أجزاء من الثانية (milliseconds) حتى لا يشعر العميل بأي تأخير. هذا يعني أن النموذج يجب أن يكون فعالاً ومحسّناً للسرعة. بالإضافة إلى ذلك، عندما يرفض النظام معاملة، غالباً ما نحتاج إلى معرفة السبب. “لماذا تم رفض هذه المعاملة بالذات؟”. هنا تأتي أهمية نماذج التفسير (Explainability) مثل SHAP و LIME التي تساعدنا على فهم “عقل” النموذج وتقديم مبررات منطقية لقراراته.

الخلاصة: من جحيم الخسائر إلى بر الأمان

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

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

يعطيكم ألف عافية! 💪

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

مقابلات تصميم النظم كانت صندوقًا أسود: كيف أنقذني ‘إطار عمل منهجي’ من جحيم الإجابات العشوائية؟

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

18 أبريل، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

طلباتنا كانت تضرب قاعدة البيانات بلا رحمة: كيف أنقذنا ‘التخزين المؤقت’ (Caching) من جحيم الاستجابة البطيئة؟

في هذه المقالة، أشارككم قصة حقيقية عن كيفية تحول تطبيقنا من بطيء ومكلف إلى صاروخي الأداء بفضل تقنية التخزين المؤقت (Caching). سنغوص في أعماق هذه...

18 أبريل، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

إعداداتنا كانت تتغير عشوائيًا: كيف أنقذنا Ansible من جحيم الانحراف في التكوين (Configuration Drift)؟

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

18 أبريل، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

أخطاؤنا كانت تُدفن سرًا: كيف أنقذتنا ‘ثقافة السلامة النفسية’ من جحيم الخوف من الفشل؟

في عالم البرمجة، الخطأ الواحد قد يكلف الكثير. لكن الخوف من الخطأ يكلف أكثر بكثير. هذه مقالة من قلب التجربة عن "السلامة النفسية" وكيف تحوّل...

18 أبريل، 2026 قراءة المزيد
اختبارات الاداء والجودة

واجهاتنا كانت تتغير خلسة: كيف أنقذتنا ‘الاختبارات البصرية التراجعية’ من جحيم ‘البيكسل الضائع’؟

أشارككم قصة حقيقية عن خطأ بصري بسيط كاد أن يسبب كارثة في أحد المشاريع، وكيف أصبحت الاختبارات البصرية التراجعية (Visual Regression Testing) هي طوق النجاة...

18 أبريل، 2026 قراءة المزيد
البودكاست