امتیاز بالای یک مدل تشخیص ناهنجاری به‌تنهایی نشانه ارزیابی درست نیست. برای مقایسه قابل‌اعتماد باید مرز دسترسی به داده، نحوه استفاده از برچسب‌ها، پروتکل مقایسه و معیارهای عملکرد به‌صورت شفاف مستند شوند.
در یک گراف، یک گره ممکن است ویژگی‌های عادی داشته باشد، اما ارتباطاتش غیرمعمول باشند. برعکس، گره‌ای با ویژگی‌های متفاوت ممکن است دقیقاً به‌دلیل نقش خاصش در شبکه کاملاً طبیعی باشد. به همین دلیل «غیرعادی» بودن را نباید بدون بررسی زمینه، معادل «اشتباه» یا «مخرب» دانست.
یکی از چالش‌های مهم در پژوهش تشخیص ناهنجاری گرافی این است که آیا عملکرد بهتر مدل واقعاً نتیجه یادگیری بهتر است یا محصول روش ارزیابی؟
اول مشخص کنیم ناهنجاری در چه سطحی است
تشخیص ناهنجاری می‌تواند در سطح گره، یال، زیرگراف یا کل گراف انجام شود. معیارها و برچسب‌ها باید با همان واحد هماهنگ باشند. برای مثال مقایسه مستقیم نتیجه Node Anomaly Detection با یک مسئله Graph-level، بدون توضیح تفاوت هدف، معتبر نیست.
همچنین باید روشن باشد که خروجی مدل صرفاً رتبه‌بندی موارد مشکوک است یا قرار است با یک آستانه، هشدار نهایی تولید کند.
خطای اول: نشت اطلاعات (Data Leakage)
وقتی اطلاعاتی که هنگام تصمیم‌گیری واقعی در دسترس نخواهد بود وارد آموزش یا انتخاب مدل می‌شود، نتیجه آزمایش ممکن است بیش‌ازحد خوش‌بینانه باشد.
نمونه‌های رایج شامل تنظیم Hyperparameter با برچسب‌های مجموعه Test، انتخاب Threshold با استفاده از نتایج نهایی و یادگیری پارامترهای پیش‌پردازش از کل داده پیش از تعیین مرز آزمون است.
تفاوت Transductive و Inductive
در روش Transductive ممکن است استفاده از ساختار گراف بدون برچسب، حتی برای گره‌هایی که بعداً ارزیابی می‌شوند، جزو پروتکل مجاز باشد. چنین استفاده‌ای لزوماً نشت برچسب نیست.
اما در روش Inductive یا یک مسئله زمانی، انتظار داریم مدل برای گره‌ها و روابطی که هنگام آموزش در دسترس نبوده‌اند عمل کند. استفاده از اطلاعات آینده این مرز را نقض می‌کند.
پس مسئله صرفاً دیدن یا ندیدن گره Test نیست؛ باید دقیقاً مشخص باشد چه اطلاعاتی در چه زمانی برای مدل مجاز بوده است.
یک راهکار ساده: قبل از آموزش، فهرست ویژگی‌ها، یال‌ها، بازه زمانی، برچسب‌ها و نحوه انتخاب مدل را برای هر مرحله ثبت کنیم.
خطای دوم: مقایسه ناعادلانه مدل‌ها
اگر یک مدل به ویژگی‌های بیشتر یا Split مناسب‌تری دسترسی داشته باشد، نتیجه مقایسه نمی‌تواند فقط به معماری نسبت داده شود.
در ارزیابی منصفانه بهتر است موارد زیر مشترک یا دست‌کم کاملاً مستند باشند:
- تعریف مسئله و تقسیم داده به Train، Validation و Test
- میزان دسترسی به ویژگی‌های گره و ساختار روابط
- روش تنظیم Hyperparameter و بودجه آزمایش
- معیارها، جهت امتیاز ناهنجاری و نحوه محاسبه آن‌ها
- تعداد اجراها و تغییرپذیری نتیجه در Seedهای متفاوت
وجود یک Baseline غیرگرافی نیز مهم است. شاید ویژگی‌ها به‌تنهایی بخش عمده سیگنال را توضیح دهند و افزودن GNN ارزش متناسبی ایجاد نکند.
خطای سوم: استفاده از معیار گمراه‌کننده
فرض کنیم فقط یک درصد نمونه‌ها واقعاً ناهنجار باشند. مدلی که همه نمونه‌ها را عادی تشخیص دهد به Accuracy برابر ۹۹٪ می‌رسد، اما هیچ ناهنجاری را پیدا نمی‌کند.
برای چنین مسئله‌ای، Accuracy به‌تنهایی مناسب نیست.
- ROC-AUC: توان رتبه‌بندی مدل در آستانه‌های مختلف را نشان می‌دهد، اما در داده به‌شدت نامتوازن ممکن است تصویر عملی کافی ندهد.
- Precision–Recall و AP: کمک می‌کنند بفهمیم چه سهمی از موارد علامت‌گذاری‌شده واقعاً مثبت‌اند و چه مقدار از ناهنجاری‌ها پیدا شده‌اند.
- Precision@K / Recall@K: زمانی کاربردی‌اند که بررسی انسانی فقط برای تعداد محدودی هشدار امکان دارد.
دقت کنیم Average Precision در پیاده‌سازی scikit-learn دقیقاً برابر انتگرال‌گیری ذوزنقه‌ای روی منحنی PR نیست. بهتر است نام معیار و پیاده‌سازی آن را صریح گزارش کنیم.
همچنین نرخ فراوانی ناهنجاری‌ها و اینکه امتیاز بزرگ‌تر به معنی «مشکوک‌تر» است یا نه باید در گزارش ثبت شوند.
خطای چهارم: نادیده‌گرفتن Contamination و ساخت داده
در بسیاری از روش‌های Unsupervised، خود داده بدون برچسب حاوی نمونه‌های غیرعادی است. این موضوع الزاماً آزمایش را نامعتبر نمی‌کند، اما می‌تواند روی رفتار مدل اثر بگذارد.
برای مثال ممکن است یک Graph Autoencoder بعضی ناهنجاری‌ها را هم به‌خوبی بازسازی کند. همچنین ناهنجاری‌های مصنوعی ممکن است خیلی ساده‌تر از نمونه‌های واقعی باشند.
بنابراین بهتر است منشأ ناهنجاری‌ها، شیوه ساخت داده Synthetic، میزان آلودگی Train، تغییرات ناشی از Seed و تفاوت نتایج روی گراف‌های مختلف گزارش شود.
خطای پنجم: یکی‌دانستن «غیرمعمول» و «خطا»
فردی را در یک شبکه همکاری علمی تصور کنید که بین چند گروه مستقل ارتباط ایجاد کرده است. الگوی ارتباط او ممکن است نادر باشد، اما این به معنای مخرب‌بودن نیست.
Anomaly Score یک نشانه آماری یا ساختاری است، نه حکم نهایی. برای استفاده عملی، بهتر است مشخص شود کدام ویژگی، رابطه یا تغییر در ساختار باعث هشدار شده است.
چک‌لیست یک ارزیابی قابل بازتولید
پیش از نتیجه‌گیری از یک مدل، این سؤال‌ها را مرور می‌کنم:
- ناهنجاری در سطح Node، Edge، Subgraph یا Graph تعریف شده است؟
- مدل در Train و Test دقیقاً به کدام ویژگی‌ها و یال‌ها دسترسی دارد؟
- برچسب‌ها در انتخاب مدل، تنظیم Threshold و ارزیابی نهایی چگونه استفاده شده‌اند؟
- مقایسه با Baseline ساده و غیرگرافی انجام شده است؟
- معیارهای ROC-AUC، AP یا PR-AUC و Precision@K متناسب با مسئله انتخاب شده‌اند؟
- نرخ ناهنجاری، تعداد اجراها، Seedها و تغییرپذیری نتایج گزارش شده است؟
- در صورت تغییر Split، نوع گراف یا میزان Contamination، نتیجه چقدر پایدار می‌ماند؟
هدف استفاده از تمام معیارها در هر پروژه نیست؛ هدف این است که فرض‌های ارزیابی دیده شوند.
نتیجه‌گیری
معماری پیچیده‌تر الزاماً مدل قابل‌اعتمادتری نمی‌سازد. ممکن است یک Baseline ساده با ارزیابی شفاف، از مدلی با امتیاز ظاهراً بالاتر و پروتکل مبهم ارزش علمی و اجرایی بیشتری داشته باشد.
اگر قرار است خروجی تشخیص ناهنجاری برای تصمیم‌گیری استفاده شود، طراحی ارزیابی بخشی از مهندسی سیستم است، نه کاری که در پایان پژوهش انجام می‌دهیم.
در مقاله قبلی درباره Graph Autoencoder و تشخیص ناهنجاری بخش مدل‌سازی را بررسی کرده‌ام. کد نمونه متن‌باز نیز در مخزن Graph Anomaly Detection قرار دارد.