نکات کلیدی

یک سیستم یکپارچه مدیریت ML نیازمند ارکستراسیون دقیق چندین مؤلفه است، از ردیابی آزمایش‌ها با MLflow تا سروینگ مدل با FastAPI.
بصری‌سازی تعاملی از طریق Streamlit امکان نمونه‌سازی سریع، اعتبارسنجی و ارتباط با ذی‌نفعان را فراهم می‌کند و هم به‌عنوان ابزار توسعه و هم به‌عنوان بستری برای تحلیل رفتار مدل عمل می‌کند.
برای مدیریت منابع و نیازهای مقیاس‌پذیری، به‌ویژه برای سرویس مانیتورینگ، از فناوری‌های کانتینرسازی مانند Docker و Kubernetes استفاده کنید.
سه‌گانه مانیتورینگ (Prometheus، Grafana و Evidently AI) با ترکیب متریک‌های زیرساختی، قابلیت‌های بصری‌سازی و مانیتورینگ اختصاصی ML، مشاهده‌پذیری جامع سیستم را فراهم می‌کند تا عملکرد قابل‌اعتماد مدل تضمین شود.
رویکرد دوگانه تشخیص دریفت داده و تحلیل Shapley Additive exPlanations (SHAP) درک عمیقی از رفتار مدل و الگوهای اهمیت ویژگی بین تراکنش‌های کوچک و بزرگ ایجاد می‌کند و به کشف تقلب قابل‌تفسیرتر و قابل‌اعتمادتر می‌انجامد.

پایپ‌لاین‌های یادگیری ماشین چندین مؤلفه کلیدی را در بر می‌گیرند: پیش‌پردازش داده، آزمایش‌گری مدل، آموزش، استقرار و ارزیابی. مهندسان یادگیری ماشین اغلب در محیط‌های پروداکشن با چالش‌های قابل‌توجهی مواجه می‌شوند، مانند دشواری بازتولید کد از نوت‌بوک‌ها و پیدا کردن نسخه درست مدل هنگام انتقال مدل‌ها از نوت‌بوک‌هایی که توسط دانشمندان داده توسعه یافته‌اند.

برای استقرار یک نمونه اولیه در پروداکشن، باید جنبه‌های مختلفی را با دقت در نظر بگیریم؛ مانند بازآرایی کد برای مقیاس‌پذیری، پیاده‌سازی کنترل نسخه، کانتینرسازی و تست خودکار همراه با یکپارچه‌سازی پیوسته. اتخاذ ذهنیت پروداکشن‌محور و شیوه‌های مشاهده‌پذیری در مراحل ابتدایی توسعه مدل می‌تواند فرآیند استقرار را به‌طور چشمگیری تسهیل کند. ما می‌توانیم سیستم‌های یادگیری ماشین محکم‌تر و قابل‌نگهداری‌تری بسازیم که برای کاربردهای دنیای واقعی مناسب‌ترند.

ساخت پایه ML

همان‌طور که در شکل ۱ در ادامه نشان داده شده است، یک پایپ‌لاین یادگیری ماشین با پردازش داده آغاز می‌شود، جایی که اطلاعات خام جمع‌آوری و برای تحلیل پردازش می‌شوند. سپس در مرحله آزمایش‌گری و آموزش، دانشمندان داده الگوریتم‌ها، تکنیک‌های مهندسی ویژگی و معماری‌های مدل را بررسی می‌کنند تا الگوها را یاد بگیرند. سپس مدل آموزش‌دیده در مرحله استنتاج مستقر می‌شود تا بر اساس داده‌های جدید ورودی از طریق APIها پیش‌بینی انجام دهد.

در مرحله مانیتورینگِ بعدی، با ردیابی متریک‌های عملکرد سیستم و تشخیص دریفت، اثربخشی مدل را تضمین می‌کنیم. سازمان‌ها می‌توانند با طی کردن این گام‌های جامع، جریان کار خود را ساده کنند، همکاری تیمی را بهبود دهند و تحویل راه‌حل‌های مبتنی بر هوش مصنوعی را سرعت ببخشند.

پایپ‌لاین‌های ML به‌عنوان یک چارچوب ساختاریافته حیاتی برای مدیریت پیچیدگی رو به رشد پروژه‌های مدرن یادگیری ماشین در توسعه و استقرار مدل‌ها عمل می‌کنند و به دانشمندان داده و مهندسان اجازه می‌دهند به جای درگیر شدن در جزئیات عملیاتی، روی نوآوری تمرکز کنند.

شکل ۱: جریان کاری یک پروژه یادگیری ماشین

ساخت یک پایپ‌لاین ML مشاهده‌پذیر (Building an Observable ML Pipeline)

این مقاله یک پایپ‌لاین ML و مشاهده‌پذیری آن را برای تشخیص تقلب کارت اعتباری در دنیای واقعی نشان می‌دهد. وقتی مشتریان کارت‌های دیجیتال خود را می‌کشند، انتظار یک تصمیم فوری دارند: تأیید یا رد. پشت این تصمیم در کسری از ثانیه، یک سیستم پیچیده یادگیری ماشین قرار دارد که باید دقیق، مشاهده‌پذیر، قابل‌نگهداری و قابل‌اعتماد باشد. این مقاله بررسی می‌کند چگونه یک سیستم تشخیص تقلب مشاهده‌پذیر بسازیم و بینش‌های عملی از توسعه تا مانیتورینگ پروداکشن را به اشتراک می‌گذارد.

دیتاست تقلب کارت اعتباری بر اساس تراکنش‌های واقعی انجام‌شده با کارت‌های اعتباری در سپتامبر ۲۰۱۳ توسط دارندگان کارت اروپایی است. با این حال، این یک نسخه ساده‌سازی‌شده و پیش‌پردازش‌شده است، و این اپلیکیشن نمونه، جریان کاری انتقال از توسعه محلی مدل به یک پلتفرم متمرکز را نمایش می‌دهد. این فرآیند در سیستم‌های واقعی تشخیص تقلب کاربرد دارد، جایی که جزئیات گسترده تراکنش و ویژگی‌های از پیش مهندسی‌شده، مشابه ساختار دیتاست Kaggle، برای آموزش مدل‌هایی استفاده می‌شوند که تراکنش‌های متقلبانه را پیش‌بینی می‌کنند.

تمرکز بر ساخت یک پلتفرم و جریان کاری مشاهده‌پذیر است، نه عملکرد نهاییِ خودِ مدل روی داده‌های واقعی تقلب. دیتاست همچنین اطلاعاتی درباره مبلغ تراکنش، زمان، و ویژگی‌های از پیش پردازش‌شده (V1-V28) ارائه می‌دهد که مؤلفه‌های اصلی به‌دست‌آمده با PCA هستند. از scikit-learn، یک کتابخانه متن‌باز یادگیری ماشین پایتون، برای توسعه یک مدل رگرسیون لجستیک برای داده‌های کارت اعتباری استفاده شد.

مدل احتمال این‌که تراکنش تقلب باشد را پیش‌بینی می‌کند. بدون تمرکز زیاد روی توسعه مدل، بیایید بفهمیم چگونه از توسعه محلی مدل به یک پلتفرم آزمایش‌گری متمرکز و مقیاس‌پذیر گذار کنیم؛ پلتفرمی که پیمایش در فرآیند پیچیده ساخت و پیاده‌سازی مدل را آسان‌تر می‌کند.

کانتینرسازی (Containerization)

این یک رویه خوب است که از ابتدا با ذهنیت مقیاس‌پذیری طراحی کنیم و از ابزار کانتینرسازی مانند Docker استفاده کنیم تا اطمینان حاصل شود کد اپلیکیشن می‌تواند هرجا اجرا شود. درون کانتینر Docker، هر مؤلفه همراه با وابستگی‌های لازم و محیط‌های اجرایی بسته‌بندی می‌شود تا یکپارچگی سیستم حفظ شود و قابلیت مقیاس‌پذیری در محیط‌های مختلف فراهم گردد. این سیستم از Apache Kafka به‌عنوان یک پلتفرم استریم رویداد توزیع‌شده برای مدیریت داده‌های تراکنش بلادرنگ استفاده می‌کند. قابلیت مقیاس‌پذیری افقی Docker و توانایی Kafka در پردازش جریان‌های بزرگ داده به سیستم اجازه می‌دهد حتی زیر بار سنگین هم سازگار و کارآمد باقی بماند. در زمان پیاده‌سازی پایپ‌لاین استنتاج، دوباره به استریم داده برمی‌گردیم.

مزیت‌های اصلی کانتینرهای Docker این است که:

کم‌مصرف از نظر منابع هستند (بدون ماشین مجازی).
مستقل از پلتفرم هستند.
با استفاده از ایمیج‌های پایه، نیازمندی‌ها را ساده می‌کنند.

فایل .dockerfile توضیح می‌دهد چگونه اپلیکیشن ساخته می‌شود که به‌صورت یک پروژه GitHub در دسترس است. مدل تشخیص تقلب چندین مؤلفه دارد که هرکدام در یک کانتینر جدا قرار می‌گیرند و این در docker-compose.yml منعکس شده است. شکل ۲ را ببینید تا بفهمید کانتینرهای Docker چگونه ساختاربندی شده‌اند تا پایپ‌لاین‌های آزمایش‌گری و استنتاج مدل تشخیص تقلب را پشتیبانی کنند.

شکل ۲: معماری کانتینرهای داکر برای سیستم تشخیص تقلب در زمان واقعی

ردیابی آزمایش‌ها و رجیستری مدل با MLflow

ساخت یک پایپ‌لاین ML قابل بازتولید: MLflow ستون فقرات ردیابی آزمایش‌ها و مدیریت رجیستری مدل در سیستم تشخیص تقلب ماست. با راه‌اندازی MLflow با "mlflow.set_tracking_uri("http://mlflow:5001")"، یک مکان متمرکز برای همه آزمایش‌ها و مدل‌ها ایجاد می‌کنیم. هر آزمایش تحت فضای نام "fraud_detection" با استفاده از mlflow.set_experiment("fraud_detection") سازمان‌دهی می‌شود تا رویکردهای مختلف مدل‌سازی از هم جدا باشند.

ما هنگام آموزش مدل‌ها از قابلیت ردیابی اجرای MLflow با context managerِ "mlflow.start_run()" استفاده می‌کنیم. این کار اجازه می‌دهد همه اطلاعات مرتبط درباره هر جلسه آموزش را ثبت کنیم. درون هر run، پارامترهای مدل مانند نوع مدل، روش مقیاس‌دهی، تعداد ویژگی‌ها و متریک‌های عملکرد مانند دقت (accuracy)، precision و recall، یک رکورد جامع از هر آزمایش می‌سازند. پس از آموزش موفق، مدل‌ها با "mlflow.sklearn.log_model()" همراه با یک نسخه و نام مشخص ثبت می‌شوند. رجیستری مدل تاریخچه شفافی از نسخه‌های مدل را نگه می‌دارد و ردیابی نسخه‌های staging و production و ویژگی‌های عملکردی آن‌ها را آسان می‌کند.

برای ساخت و اجرای کانتینر Docker به‌طوری که در رجیستری MLflow قابل دسترس باشد

با این تنظیمات، همه اطلاعات مرتبط درباره هر جلسه آموزش را ثبت می‌کنیم. درون هر run، پارامترهای مدل مانند نوع مدل، روش مقیاس‌دهی، تعداد ویژگی‌ها و متریک‌های عملکرد مانند accuracy، precision و recall یک رکورد جامع از هر آزمایش ایجاد می‌کنند، همان‌طور که در شکل ۳ نشان داده شده است. پس از آموزش موفق، مدل‌ها با "mlflow.sklearn.log_model()" با یک نسخه و نام مشخص ثبت می‌شوند. رجیستری مدل تاریخچه روشنی از نسخه‌های مدل و متریک‌های عملکرد آن‌ها را نگه می‌دارد و ردیابی نسخه‌های staging و production را آسان می‌کند.

شکل ۳: ردیابی معیارهای عملکرد مدل

یکی از ارزشمندترین جنبه‌های پیاده‌سازی ردیابی آزمایش و رجیستری مدل، توانایی مقایسه آزمایش‌های مختلف است. شکل ۴ یک مخزن متمرکز برای همه آزمایش‌های مدل را نشان می‌دهد و از محیط‌های محلی مانند اسکریپت‌های مستقل، نوت‌بوک‌ها یا محیط‌های دیگر فاصله می‌گیرد. دانشمندان داده می‌توانند به‌راحتی عملکرد نسخه‌های مختلف مدل را مقایسه کنند، اثر تغییرات پارامترها را تحلیل کنند و درباره این‌که کدام مدل‌ها به پروداکشن ارتقا یابند تصمیم آگاهانه بگیرند. این رویکرد سیستماتیک برای ردیابی آزمایش تضمین می‌کند سیستم تشخیص تقلب ما قابل بازتولید، قابل نگهداری و آماده پروداکشن باقی بماند.

شکل ۴: نمایش اجرای مدل‌ها برای آزمایش‌ها

ساخت یک دمو تعاملی با Streamlit

Streamlit به دلیل سادگی و قابلیت‌های قدرتمندش انتخابی عالی برای ساخت دموهای تعاملی یادگیری ماشین است. می‌توان از آن به‌صورت خلاقانه برای راه‌اندازی ویژگی‌های کلیدی مانند تشخیص تقلب بلادرنگ، کنترل‌های ورودی تعاملی برای جزئیات تراکنش، امتیازهای احتمالی بصری، بصری‌سازی اهمیت ویژگی، تحلیل دقیق تراکنش و موارد بیشتر استفاده کرد.

اجزای کلیدی

اپلیکیشن به اجزای ضروری ساختاربندی شده است که با هم کار می‌کنند تا یک رابط کاربری دمو تشخیص تقلب جامع روی اپ Streamlit ارائه شود:

بارگذاری مدل: یکپارچه‌سازی روان با MLflow
رابط کاربری: چیدمان تمیز دو ستونه برای پارامترهای ورودی
پیش‌بینی‌های بلادرنگ: بازخورد فوری درباره ریسک تراکنش
تحلیل بصری: نمودارهای تعاملی که اهمیت ویژگی را نشان می‌دهند
مدیریت خطا: مدیریت خطای مقاوم همراه با پیام‌های کاربرپسند

برای ساخت دمو اپ Streamlit تشخیص تقلب، اسکریپت می‌تواند شبیه این باشد:

برای بالا آوردن اپ دمو Streamlit تشخیص تقلب، کافی است دستور زیر را اجرا کنید: اپ Streamlit روی پورتی که در فایل docker-compose.yml برای کلید streamlit_playground تعیین شده، فعال خواهد شد. سپس رابط کاربری را همان‌طور که در شکل ۵ نشان داده شده می‌بینید.

شکل ۵: رابط کاربری تعاملی مدل تشخیص تقلب در اپلیکیشن Streamlit

تحلیل بلادرنگ ویژگی‌ها با Streamlit

یک مزیت بزرگ دیگر، ساخت تحلیل‌های بصری است که اهمیت مدل را نشان می‌دهد. مدل همه ویژگی‌ها را با هم در نظر می‌گیرد تا پیش‌بینی‌اش را انجام دهد، و احتمال نهایی تقلب از الگوی ترکیبیِ همه ویژگی‌ها به دست می‌آید. دانستن این‌که کدام مقادیر ویژگی، همان‌طور که در شکل ۶ نشان داده شده، یا کدام ویژگی‌ها و خصوصیات روی احتمال تقلب اثر گذاشته‌اند، کمک بزرگی به مدل می‌کند و باعث می‌شود بیشتر بهبود پیدا کند.

شکل ۶: نمایش ۱۰ ویژگی برتر مؤثر بر پیش‌بینی مدل تشخیص تقلب

میله‌ها مقادیر ویژگی را نشان می‌دهند، نه احتمال تقلب را
مقادیر آبی/مثبت و قرمز/منفی الگوهای متفاوت تراکنش را نمایش می‌دهند.
مدل یاد می‌گیرد کدام ترکیب از این الگوها نشان‌دهنده تقلب است
یک مقدار آبی (مثبت) به‌تنهایی الزاماً به معنی تقلب نیست
این ترکیب همه ویژگی‌هاست که پیش‌بینی نهایی را تعیین می‌کند

مزیت‌های عملی دمو Streamlit

نمونه‌سازی سریع (Rapid Prototyping): رفتار مدل را با ورودی‌های مختلف فوراً تست می‌کند
اعتبارسنجی (Validation): تکرار سریع و راستی‌آزمایی آسان عملکرد مدل در سناریوهای مختلف
مانیتورینگ مدل (Model Monitoring): تشخیص زودهنگام دریفت مدل یا رفتارهای غیرمنتظره
تست فرضیه (Hypothesis Testing): اعتبارسنجی فرضیات درباره اهمیت ویژگی و تصمیم‌های مدل
مستندسازی (Documentation): مستندسازی زنده از رفتار مدل و ویژگی‌ها
همکاری (Collaboration): پلتفرم مشترک برای گفتگوهای تیمی درباره رفتار مدل
آموزش (Training): روشی عالی برای آن‌بورد کردن اعضای جدید تیم روی پروژه

ساخت پایپ‌لاین استنتاج (Building Inference Pipeline)

ما باید یک پایپ‌لاین استنتاج بسازیم تا پیش‌بینی‌های مدل برای کاربر قابل دسترس شود. سرویس Fast API نقطه پایانی اصلی برای پیش‌بینی‌های بلادرنگ تشخیص تقلب است که از طریق فایل docker-compose.yml ارکستره می‌شود. این سرویس با MLflow ارتباط برقرار می‌کند تا جدیدترین فایل pickle مدل پروداکشن را که از آموزش تولید شده بارگذاری کند و درخواست‌های تراکنش ورودی را پردازش کند. Apache Kafka برای قابلیت‌های استریم استفاده می‌شود. سرویس استریم پایه پردازش داده بلادرنگ را فراهم می‌کند. این سرویس جریان‌های تراکنش را با Kafka و Zookeeper مدیریت می‌کند و زمینه را برای پیاده‌سازی‌های آینده مانیتورینگ بلادرنگ و به‌روزرسانی پیوسته مدل فراهم می‌سازد.

جریان استنتاج زمانی شروع می‌شود که یک درخواست تراکنش به endpoint API ما برخورد می‌کند. سرویس FastAPI با استفاده از tracking URI تنظیم‌شده (http://mlflow:5001) جدیدترین فایل مدل را از رجیستری مدل MLflow بارگذاری می‌کند. این تنظیم تضمین می‌کند که جدیدترین مدل پروداکشن برای پیش‌بینی‌ها استفاده می‌شود، در حالی که کنترل نسخه و قابلیت بازتولید حفظ می‌شود.

هر پیش‌بینی همراه با شناسه یکتای خود، ویژگی‌های ورودی، نتیجه پیش‌بینی و زمان پردازش لاگ می‌شود. این نقاط داده برای مانیتورینگ عملکرد مدل و تشخیص انواع دریفت‌ها در پروداکشن حیاتی هستند؛ مانند تغییر در ویژگی‌ها و عملکرد، یا حتی برای تضمین کیفیت داده.

مدیریت منابع و مقیاس‌پذیری

پیکربندی docker-compose شامل مدیریت دقیق منابع است، به‌خصوص برای سرویس مانیتورینگ که محاسبات پیچیده و تولید گزارش را انجام می‌دهد. ما محدودیت‌های حافظه مشخصی تا سقف 4G و 2G برای رزرو حافظه اختصاص داده‌ایم تا عملکرد پایدار تضمین شود:

این تنظیمات اجازه می‌دهد پایپ‌لاین استنتاج ما بارهای پروداکشن را مدیریت کند و در عین حال مانیتورینگ عملکرد قابل‌اعتماد را حفظ نماید. جدا کردن دغدغه‌ها بین سرویس‌ها (API، استریم، مانیتورینگ) امکان مقیاس‌دهی مستقل و نگهداری جداگانه هر مؤلفه را فراهم می‌کند.

پایپ‌لاین استنتاج سیستم تشخیص تقلب ما که با FastAPI و MLflow ساخته شده، یک پایه محکم برای پیش‌بینی‌های بلادرنگ فراهم می‌کند. یک سرور واحد فقط می‌تواند تعداد محدودی درخواست هم‌زمان را مدیریت کند، در حالی که با افزایش حجم تراکنش‌ها و سخت‌گیرانه‌تر شدن نیازهای زمان پاسخ، فشار بالا می‌رود. علاوه بر این، رویکرد سروینگ مدل ما که مدل را برای پیش‌بینی‌ها از MLflow بارگذاری می‌کند، باید برای سناریوهای توزیع‌شده بهینه شود. بنابراین، باید از معماری تک‌نمونه‌ای به یک سیستم توزیع‌شده تکامل پیدا کنیم که بتواند میلیون‌ها تراکنش را با زمان پاسخ زیر یک ثانیه مدیریت کند. پیاده‌سازی کامل مقیاس‌دهی افقی یک مسیر تدریجی است که به برنامه‌ریزی و اجرای دقیق نیاز دارد. بیایید ابزارهای ضروری‌ای را بررسی کنیم که پایه یک سیستم تشخیص تقلب مقیاس‌پذیر را شکل می‌دهند.

Kubernetes: پایه مقیاس‌دهی افقی (Kubernetes: The Foundation for Horizontal Scaling)

Kubernetes انتخاب طبیعی برای ارکستراسیون سرویس‌های تشخیص تقلب و فراهم کردن استقرار، مقیاس‌دهی و مدیریت خودکار اپلیکیشن‌های کانتینری ماست. توانایی آن در مدیریت rolling updateها، خودترمیمی کانتینرهای ازکارافتاده و مدیریت کارآمد منابع، آن را برای حفظ عملکرد یکنواخت در چندین نمونه از API تشخیص تقلب ایده‌آل می‌کند. علاوه بر Kubernetes، ابزارهای بالانس بار و مدیریت سرویس مانند NGINX Ingress Controller برای توزیع ترافیک و Istio برای قابلیت‌های service mesh باید مدنظر قرار بگیرند.

در حالی که پیاده‌سازی Kubernetes شایسته یک بررسی عمیق است، نکته کلیدی این است که این مؤلفه‌ها به‌صورت تدریجی و هم‌زمان با افزایش حجم تراکنش معرفی شوند.

مشاهده‌پذیری مدل: نبض سیستم‌های ML در پروداکشن (Model Observability)

مانیتورینگ جامع در سیستم‌های ML پروداکشن نیازمند رویکردی چندوجهی است، همان‌طور که در شکل ۷ نشان داده شده است، به‌ویژه برای کاربردهای حیاتی مانند تشخیص تقلب. استک مانیتورینگ سه ابزار تخصصی را ترکیب می‌کند: Prometheus، Grafana و Evidently AI. هرکدام نقش یکتایی در تضمین قابلیت اطمینان و عملکرد سیستم دارند.

سه‌گانه مانیتورینگ (The Monitoring Trinity)

شکل ۷: استراتژی‌های مشاهده‌پذیری مدل

Prometheus ستون فقرات جمع‌آوری متریک‌هاست و متریک‌های سطح سیستم و عملیاتی را جمع می‌کند. این ابزار داده‌های سری زمانی درباره عملکرد API، استفاده از منابع و الگوهای درخواست را به‌طور کارآمد جمع‌آوری و ذخیره می‌کند. همچنین به‌عنوان مانیتور سلامت سیستم عمل می‌کند و علائم حیاتی مانند موارد زیر را ردیابی می‌کند:

زمان‌های پاسخ برای درخواست‌های پیش‌بینی
توان‌گذر (throughput) و نرخ خطای API
زمان‌های بارگذاری مدل
استفاده از منابع در سراسر سرویس‌ها

Grafana قابلیت‌های قدرتمند بصری‌سازی و هشداردهی سفارشی فراهم می‌کند. این ابزار اجازه می‌دهد متریک‌های سیستم با KPIهای کسب‌وکار ترکیب شوند تا داده‌های خام به بینش‌های قابل اقدام تبدیل شوند، از طریق داشبوردهای تعاملی که برای ذی‌نفعان فنی و کسب‌وکاری قابل استفاده‌اند. Grafana به ما کمک می‌کند روندها را ببینیم، هشدارها را تنظیم کنیم و نماهای جامع بسازیم که متریک‌های ML، عملکرد سیستم و KPIهای کسب‌وکار را کنار هم قرار می‌دهد.

Evidently AI ابزار مانیتورینگ اختصاصی ML ماست که روی چیزهایی تمرکز می‌کند که برای دانشمندان داده و عملکرد مدل بیشترین اهمیت را دارد. این ابزار در تشخیص دریفت داده، تحلیل تغییرات عملکرد مدل و تولید گزارش‌های دقیق درباره رفتار مدل تشخیص تقلب عالی عمل می‌کند. این ابزار کمک می‌کند به پرسش‌های کلیدی‌ای مثل «آیا مدل ما هنوز مطابق انتظار کار می‌کند؟» و «آیا الگوهای تراکنش به‌طور معناداری تغییر کرده‌اند؟» پاسخ بدهیم.

در حالی که هر ابزار می‌تواند بخشی از مسئولیت‌های دیگری را پوشش دهد، ترکیب آن‌ها یک راه‌حل مانیتورینگ تخصصی و محکم فراهم می‌کند که همه جنبه‌های سیستم تشخیص تقلب را پوشش می‌دهد، از عملکرد مدل تا سلامت سیستم و اثر کسب‌وکار.

دو جنبه حیاتی سیستم ML، دریفت داده و عملکرد مدل هستند که آن‌ها را با تحلیل Shapley Additive exPlanations (SHAP) بررسی می‌کنیم تا سیستم تشخیص تقلب قابل‌اعتماد و قابل‌تفسیر باقی بماند.

تشخیص دریفت داده

پیاده‌سازی ما بر تشخیص دریفت معنادار تمرکز دارد، که در تشخیص تقلب حیاتی است، جایی که الگوهای تراکنش می‌توانند به‌سرعت تغییر کنند. با استفاده از Evidently AI، دریفت را در بخش‌های مختلف تراکنش مانیتور می‌کنیم و دریفت داده را بصری‌سازی می‌کنیم، همان‌طور که در شکل ۸ نشان داده شده است. برای اهداف نمایشی، سناریوهای دنیای واقعی را با دستکاری الگوهای تراکنش شبیه‌سازی کردیم تا نشان دهیم سیستم ما چگونه دریفت را تشخیص می‌دهد و به آن پاسخ می‌دهد. داده‌ها را طوری مهندسی کردیم که سناریوهای دریفت واقع‌گرایانه را به روش‌های زیر نمایش دهد:

تحلیل الگوی تراکنش

ما تراکنش‌ها را بر اساس آستانه‌های پولی معنادار بخش‌بندی کردیم. این روش برای تشخیص تقلب بسیار ارزشمند است، چون الگوها اغلب در اندازه‌های مختلف تراکنش تفاوت‌های چشمگیری دارند.

تحلیل توزیع تراکنش (Transaction Distribution Analysis)

ما طیف کامل مبالغ تراکنش را با استفاده از شاخص‌های آماری کلیدی تحلیل می‌کنیم: mix، max، mean، median و چندک‌های p25 و P75.

تراکنش‌های کوچک (≤ ۱۰۰ دلار) اغلب نشان‌دهنده هزینه‌های روزمره مصرف‌کننده هستند.
تراکنش‌های بزرگ (> ۵۰۰ دلار) ممکن است نشان‌دهنده پرداخت‌های کسب‌وکار یا انتقال‌های باارزش بالا باشند. این مقدار می‌تواند در کاربردهای واقعی بالاتر تنظیم شود. بر اساس دیتاست کارت اعتباری ما، مرجع تراکنش‌ها در بازه ۵۰۰ دلار بالاتر است، بنابراین امکان نمایش دریفت در مبالغ تراکنش وجود داشت.

شکل ۸: تحلیل دریفت و توزیع تراکنش‌ها

تحلیل دریفت ویژگی‌ها (Feature Drift Analysis)

در سیستم تشخیص تقلب ما، ویژگی‌های V1-V28 مؤلفه‌های تبدیل‌شده با PCA از داده تراکنش اصلی هستند. وقتی دریفت این ویژگی‌ها را تحلیل می‌کنیم، به دنبال تغییرات معنادار در الگوهای زیربنایی تراکنش می‌گردیم. دریفت در این ویژگی‌ها می‌تواند نشان‌دهنده موارد زیر باشد:

ظهور تکنیک‌های جدید تقلب
تغییر در الگوهای تراکنش‌های سالم
تغییر در رفتار مصرف‌کننده
تکامل روش‌های پرداخت کسب‌وکار

دریفت در هر یک از این ویژگی‌ها، همان‌طور که در شکل ۹ نشان داده شده، می‌تواند نشان‌دهنده تغییر در الگوهای زیربنایی تراکنش‌های کارت اعتباری باشد.

همه ویژگی‌های V1-V28 را برای تغییرات در طول زمان مانیتور کنید.
دریفت را در مقیاس‌های زمانی مختلف (روزبه‌روز، هفته‌به‌هفته) تحلیل کنید تا الگوهای متفاوت ثبت شوند.
با مانیتور دقیق دریفت در همه ویژگی‌های V1-V28، سیستم‌های تشخیص تقلب می‌توانند با الگوهای تراکنش در حال تکامل سازگار شوند و اثربخشی خود را در شناسایی فعالیت‌های بالقوه متقلبانه حفظ کنند.

شکل ۹: تشخیص دریفت

گزارش شکل ۱۰ متریک‌های کلی عملکرد مدل ROC و منحنی‌های Precision-Recall را روی Evidently نشان می‌دهد.

شکل ۱۰: معیارهای عملکرد مدل

ترکیب متریک‌های ارزیابی عملکرد مدل و مانیتورینگ دریفت، یک نمای جامع از سلامت مدل در پروداکشن فراهم می‌کند. بصری‌سازی این متریک‌ها با داشبوردها و گزارش‌های تعاملی به تیم‌های فنی و ذی‌نفعان کسب‌وکاری کمک می‌کند بینش‌های عملکرد مدل را درک کنند و بر اساس آن اقدام کنند.

تحلیل SHAP برای تفسیرپذیری مدل

برای تکمیل تشخیص دریفت، از مقادیر SHAP استفاده می‌کنیم تا بفهمیم مدل ما چگونه در انواع مختلف تراکنش تصمیم می‌گیرد. این تحلیل هم برای اعتبارسنجی مدل و هم برای اعتماد ذی‌نفعان حیاتی است.

برای تولید تحلیل SHAP برای یک مدل تشخیص تقلب، اهمیت ویژگی‌های تراکنش‌های کوچک و بزرگ را مقایسه می‌کنیم. تحلیل SHAP می‌تواند نشان دهد الگوهای تقلب بین تراکنش‌های کوچک و بزرگ چگونه تفاوت دارند. برای مثال، برخی ویژگی‌ها ممکن است در تراکنش‌های بزرگ بیشتر از تراکنش‌های کوچک نشان‌دهنده تقلب باشند. فراوانی بالای تراکنش‌های کوچک نیز می‌تواند نشانه‌ای از فعالیت متقلبانه بالقوه باشد.

شکل ۱۱: اهمیت ویژگی‌های تراکنش‌های کوچک و بزرگ

این نمودار اهمیت ویژگی، شکل ۱۱، مقایسه بین تراکنش‌های کوچک و بزرگ است و نشان می‌دهد:

چندین ویژگی سطح‌های متفاوتی از اهمیت بین تراکنش‌های کوچک و بزرگ نشان می‌دهند و این‌که اهمیت چگونه جابه‌جا می‌شود
برخی ویژگی‌ها در هر دو اندازه تراکنش اهمیت ثابت دارند. V4، V3 و V14 در هر دو اندازه تراکنش اثر دارند
میله‌های بلندتر نشان‌دهنده اثرگذاری بیشتر بر پیش‌بینی‌های مدل هستند.
میله‌های نارنجی (تراکنش‌های فعلی/بزرگ) اغلب الگوهای متفاوتی نسبت به میله‌های قهوه‌ای (مرجع/تراکنش‌های کوچک) نشان می‌دهند
مدل هنگام ارزیابی تراکنش‌های کوچک در مقابل بزرگ، از ترکیب‌های متفاوت ویژگی استفاده می‌کند.

شکل ۱۲: نمودارهای خلاصه SHAP برای داده‌های تراکنش‌های کوچک و بزرگ

بیایید بفهمیم چگونه نمودارهای خلاصه شکل ۱۲ را تفسیر کنیم. هر ردیف نماینده یک ویژگی است (V1-V28، Time، Amount). محور X مقدار SHAP (اثر بر خروجی مدل) را نشان می‌دهد. هر نقطه نماینده یک تراکنش منفرد است. رنگ‌ها مقدار ویژگی را نشان می‌دهند (قرمز = بالا، آبی = پایین).

چگونه نقاط را بخوانیم

نقاط سمت راست (مقادیر مثبت SHAP) احتمال تقلب را افزایش می‌دهند
نقاط سمت چپ (مقادیر منفی SHAP) احتمال تقلب را کاهش می‌دهند
پراکندگی نقاط بازه اثرگذاری را نشان می‌دهد
خوشه‌بندی نقاط الگوهای رایج را نشان می‌دهد

تفاوت‌های کلیدی بین نمودارها (Key Differences Between Plots)

تراکنش‌های کوچک (Reference)

ویژگی‌های V3، V4 و V14 اثرهای قوی نشان می‌دهند
ویژگی زمان (Time) توزیع متعادل نشان می‌دهد
V5 اهمیت متوسط دارد
بیشتر ویژگی‌ها خوشه‌های متمرکز نزدیک صفر دارند

تراکنش‌های بزرگ (Current)

Time و V5 اهمیت بیشتری پیدا می‌کنند
ویژگی Amount معنادارتر می‌شود
V3 و V4 همچنان اثر قوی روی پیش‌بینی‌های مدل دارند
پراکندگی گسترده‌تر نقاط نشان‌دهنده اثرهای متنوع‌تر است

این بصری‌سازی کمک می‌کند بفهمیم کدام ویژگی‌ها برای تشخیص تقلب در اندازه‌های مختلف تراکنش حیاتی‌تر هستند و اثر آن‌ها چگونه تغییر می‌کند. برخی ویژگی‌ها برای تراکنش‌های بزرگ مهم‌تر می‌شوند و پراکندگی نقاط نشان می‌دهد الگوها در تراکنش‌های بزرگ پیچیده‌ترند. بر اساس تشخیص دریفت و تحلیل SHAP، ما می‌فهمیم چه زمانی عملکرد مدل تغییر می‌کند و چرا این تغییرات رخ می‌دهد، و این امکان نگهداری پیش‌دستانه سیستم ML را فراهم می‌کند.

چالش‌ها در ساخت سیستم‌های ML

ساخت و نگهداری یک سیستم ML پروداکشن برای تشخیص تقلب چندین چالش به‌هم‌پیوسته دارد:

در حین پیاده‌سازی پایپ‌لاین استنتاج، باید اقدامات امنیتی برای حفاظت از endpointهای API و داده‌های حساس تراکنش انجام شود. این موضوع یک لایه دیگر به پیچیدگی نگهداری سیستم اضافه می‌کند. این اطلاعات اضافی را درباره امن‌سازی APIها برای اپلیکیشن‌های ML و AI در محیط‌های ابری مانند AWS و Google Cloud بخوانید.

مدیریت سیستم‌های توزیع‌شده پیچیده روی Kubernetes همراه با لودبالنسرها چالش‌های زیرساختی و عملکردی ایجاد می‌کند، به‌خصوص در حفظ زمان پاسخ زیر یک ثانیه برای میلیون‌ها تراکنش و مدیریت کارآمد منابع محاسباتی در میان کانتینرها. برخی مطالعات موردی دنیای واقعی نشان می‌دهند سازمان‌ها چگونه با استفاده از Kubernetes با موفقیت این چالش‌ها را حل کرده‌اند. برای بینش بیشتر، بخوانید چگونه بر چالش‌های Kubernetes برای استقرار آسان غلبه کنیم.

مانیتورینگ دشواری‌های ویژه‌ای دارد؛ از جمله ایجاد توازن بین جزئی‌نگری و عملکرد سیستم، به‌خصوص در تعیین آستانه‌های مناسب برای تشخیص دریفت و مدیریت سیستم‌های هشدار بدون ایجاد خستگی هشدار (alert fatigue). مقاله monitoring and explainability برای مدل‌ها در پروداکشن را بخوانید تا اهمیت داشتن سیستم‌های ML مشاهده‌پذیر را درک کنید. همچنین می‌توانید درباره تشخیص جابه‌جایی دیتاست در مقاله Failing Loudly: An Empirical Study of Methods for Detecting Dataset Shift بیشتر بخوانید. دریفت داده همیشه به معنی افت مدل نیست، چون مدل‌ها می‌توانند تعمیم دهند یا تحمل خطای متفاوتی داشته باشند. بنابراین، روش‌ها و آستانه‌های تشخیص دریفت را با توجه به کاربرد و داده خود تنظیم کنید، چون راه‌حل یکسان برای همه وجود ندارد و باید از هشدارهای کاذب جلوگیری کرد. برای مثال، یک مدل طبقه‌بندی با امتیاز ROC AUC مقادیری بین ۰ تا ۱ می‌گیرد. می‌توانید آستانه را ۰.۶۰ قرار دهید. در این حالت، ۱ یعنی دریفت مطلق و نیازمند اقدام فوری است.

نمونه دیگر در نظر گرفتن معیار فاصله کسینوسی برای تشخیص دریفت در embeddingهای متنی است؛ مدلی که احساسات مشتری را پیش‌بینی می‌کند ممکن است فقط دریفت بالاتر از فاصله کسینوسی ۰.۸ را هشدار دهد، در حالی که مدلی که تشخیص‌های پزشکی را بر اساس داده متنی طبقه‌بندی می‌کند ممکن است در فاصله ۰.۲ نیاز به هشدار داشته باشد. فعالان ML باید آستانه‌های هشدار را با توجه به نیازهای خاص اپلیکیشن تنظیم و با آن‌ها آزمایش کنند. برای اطلاعات بیشتر درباره این موضوع، drift in ML embeddings را بخوانید.

نگهداری عملیاتی نیازمند هماهنگی دقیق به‌روزرسانی‌های مدل، استقرارهای سیستم و مستندسازی است، در حالی که باید بدهی فنی در پایپ‌لاین‌های ML مدیریت شود. همه این‌ها به توجه پیوسته نیاز دارد تا سیستم محکم باقی بماند. مقاله “The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction” ۲۸ تست مشخص و نیاز مانیتورینگ را که از سیستم‌های ML پروداکشن واقعی استخراج شده‌اند شرح می‌دهد و یک نقشه راه برای بهبود آمادگی پروداکشن و کاهش بدهی فنی ارائه می‌کند. مقاله دیگری به نام Hidden Technical Debt in Machine Learning Systems از مفهوم بدهی فنی برای برجسته کردن هزینه‌های پنهان نگهداری در سیستم‌های ML دنیای واقعی استفاده می‌کند و عوامل ریسک ویژه ML و ضدالگوهای سطح سیستم را که هنگام طراحی سیستم باید در نظر گرفت بررسی می‌کند.