یک مدل تشخیص تقلب در آزمایشگاه با Accuracy برابر ۹۸٪ آمادهٔ انتشار است. تیم آن را روی پرداختهای فروشگاه فعال میکند؛ چند ساعت بعد، تعداد زیادی سفارش سالم مسدود میشوند. مدل «کمدقت» نبود: دادهٔ Test از آینده نشت کرده بود، کلاس تقلب کمتر از یک درصد بود، Threshold بدون توجه به هزینهٔ خطا انتخاب شده بود و هیچ Slice جداگانهای برای دستگاه، درگاه یا الگوی خرید تازه وجود نداشت.
تست سیستمهای AI/ML فقط اجرای چند Metric روی یک فایل Test نیست. باید داده و برچسب، Artifact مدل، Feature pipeline، API سرویسدهی، تصمیم محصول، اثر بر انسان و رفتار پس از انتشار را با هم بیازمایید. در این راهنما یک چارچوب Risk-based و قابلاجرا میسازیم: از Data lineage و Leakage تا Precision/Recall، Calibration، Fairness، Robustness، Shadow، Drift و Release Gate.
دامنهٔ مقاله: تمرکز اصلی بر Predictive ML مانند Classification و Ranking است؛ در بخشی مستقل تفاوت تست Generative AI و LLM را توضیح میدهیم. اگر مقصود شما استفاده از AI برای تولید Test case یا تحلیل Failure است، آن موضوع را در راهنمای هوش مصنوعی در تست نرمافزار بخوانید.
خلاصهٔ اجرایی: چه چیزی باید قبل از Release ثابت شود؟
- مسئله درست تعریف شده: کاربر متأثر، پیامد خطا، Non-goal و Human override روشناند.
- داده قابلردیابی است: منبع، مجوز، Window زمانی، نسخه، Label policy و Transformation ثبت شدهاند.
- Leakage کنترل شده: آینده، Target proxy، Duplicate و یک Entity مشترک میان Train/Test نتیجه را مصنوعی نکردهاند.
- مدل از Baseline بهتر است: نه فقط در Average، بلکه روی Sliceهای پرریسک و با عدمقطعیت گزارششده.
- Threshold تجاری است: هزینهٔ False Positive و False Negative، ظرفیت بررسی انسانی و SLO تصمیم در آن دیده میشود.
- سیستم کامل پایدار است: Training-serving skew، Timeout، Fallback، Latency، مجوز و Privacy آزموده شدهاند.
- انتشار قابلکنترل است: Shadow/Canary، Guardrail، Stop condition، Rollback و Owner آمادهاند.
- پایش به Outcome وصل است: Drift ورودی با افت واقعی مدل اشتباه گرفته نمیشود و تأخیر Label لحاظ شده است.
این نگاه با رویکرد Risk-based در ISO/IEC TS 42119-2:2025 همراستاست. استاندارد، روشهای سری ISO/IEC/IEEE ۲۹۱۱۹ را در زمینهٔ سیستمهای AI به کار میگیرد؛ اما Threshold و Gate محصول باید از Risk context خود سازمان بیاید، نه از یک عدد جهانی.
تست AI/ML دقیقاً چه تفاوتی با تست نرمافزار سنتی دارد؟
| ویژگی | نرمافزار قاعدهمحور | سیستم AI/ML | پیامد برای تست |
|---|---|---|---|
| منبع رفتار | کد و Rule صریح | کد + داده + فرایند آموزش | نسخهٔ داده و Feature بخشی از Build است |
| Oracle | اغلب خروجی دقیق | اغلب کیفیت توزیعی/احتمالی | Metric، Slice، Tolerance و Human review لازم است |
| Regression | تغییر کد | کد، داده، Label، Seed، کتابخانه یا مدل پایه | Lineage و Reproducibility حیاتی است |
| Failure | Exception یا خروجی غلط | افت تدریجی، خطای نامتوازن، Confidence کاذب | پایش Outcome و Slice پس از Release لازم است |
| محیط | Contract نسبتاً پایدار | توزیع جهان تغییر میکند | Drift و Feedback loop باید آزموده شوند |
دو سوءبرداشت رایج را کنار بگذارید. اول، هر مدل لزوماً در Inference تصادفی نیست؛ بسیاری از Pipelineها با ورودی، Artifact و تنظیمات یکسان خروجی تکرارپذیر دارند. دوم، احتمالیبودن مدل به معنی مبهمبودن همهٔ تستها نیست: Schema، Authentication، Serialization، محاسبهٔ Feature و Ruleهای قطعی هنوز Expected دقیق دارند. فقط Oracle کیفیت مدل اغلب آماری یا مبتنی بر Risk است.
مرز تست را در چهار لایه تعریف کنید
۱. داده و برچسب
آیا دادهٔ درست، مجاز، نماینده و بدون Leakage وارد آموزش و ارزیابی شده است؟ این لایه Schema، کیفیت، Lineage، Sampling، Label و Split را پوشش میدهد.
۲. Model artifact و ارزیابی آفلاین
آیا مدل روی Dataset قفلشده، نسبت به Baseline و در Sliceهای مهم، با Metric متناسب با هزینهٔ خطا بهتر است؟ اینجا Threshold، Calibration، Robustness و Regression سنجیده میشوند.
۳. Pipeline، Serving و زیرساخت
آیا همان Transformation در Training و Production اجرا میشود؟ آیا Model loading، Feature freshness، Timeout، Fallback، Latency و Authorization درستاند؟ برای سرویسهای توزیعشده، Contractهای این لایه را کنار راهنمای تست میکروسرویسها طراحی کنید.
۴. محصول، انسان و عملیات آنلاین
آیا Decision واقعاً Outcome مطلوب میسازد و آسیب تازه ایجاد نمیکند؟ Shadow، Canary، Human override، Alert، Rollback و سنجش اثر کاربر به این لایه تعلق دارند.
این تفکیک جلوی یک خطای مدیریتی را میگیرد: «F1 بهتر شد» بهتنهایی نمیگوید سیستم برای Release امنتر شده است. مدل ممکن است بهتر باشد اما API کند، Feature کهنه، Policy اشتباه یا تجربهٔ اعتراض کاربر ناقص باشد.
از Risk و Test Oracle شروع کنید، نه از ابزار
NIST AI RMF 1.0 ویژگیهای اعتمادپذیری را Valid/Reliable، Safe، Secure/Resilient، Accountable/Transparent، Explainable/Interpretable، Privacy-enhanced و Fair با Bias زیانبار مدیریتشده میبیند. چهار Function آن، Govern، Map، Measure و Manage، یک چکلیست صددرصدی نیست؛ چارچوبی برای وصلکردن Evidence فنی به زمینه و تصمیم ریسک است.
برای هر قابلیت AI یک Risk statement قابلآزمون بنویسید:
اگر مدل در خریدهای کاربران تازه False Positive بالایی داشته باشد، آنگاه سفارش سالم مسدود و اعتماد کاربر کم میشود؛ بنابراین FPR این Slice، نرخ Override، زمان بررسی و مسیر اعتراض باید Gate و Owner مشخص داشته باشند.
| Risk | Oracle یا Evidence | Gate | اقدام شکست |
|---|---|---|---|
| تقلب عبور کند | Recall و زیان ریالی روی Window زمانی مستقل | کمتر از Baseline نشود؛ کف مصوب رعایت شود | Reject یا Review band را گسترش دهید |
| خرید سالم مسدود شود | FPR، نرخ Appeal و Slice کاربران تازه | سقف محصول رعایت شود | Threshold/Policy را اصلاح کنید |
| تصمیم دیر برسد | p95/p99 کل Journey و Timeout rate | SLO سرویس | Fallback یا Rollback |
| اطلاعات حساس نشت کند | Log scan، Access test و Retention evidence | صفر Secret/PII غیرمجاز | Stop release و Incident path |
عدد واقعی Gate را Product، Domain expert، Data science، QA، Security و Risk/Legal با توجه به پیامد تعیین میکنند. مثالهای این مقاله آموزشیاند؛ برای حوزههای مالی، پزشکی، استخدام یا زیرساخت حیاتی، ارزیابی مستقل و کنترل انسانی متناسب لازم است.
مثال پیوسته: مدل تشخیص تقلب فروشگاه ایرانی
مدل برای هر پرداخت امتیاز ریسک بین صفر و یک میسازد. محصول سه Action دارد: پذیرش خودکار، بررسی انسانی و رد/توقف موقت. Ground truth تقلب ممکن است چند هفته بعد از تطبیق مالی یا اعتراض معلوم شود؛ پس Label فوری کامل نیست.
هزینهٔ خطا
- False Negative: تراکنش متقلب عبور میکند؛ زیان مالی و عملیاتی رخ میدهد.
- False Positive: خرید سالم متوقف میشود؛ Conversion، رضایت و اعتماد آسیب میبیند.
- Review overload: حتی مدل دقیق میتواند بیش از ظرفیت تیم پرونده بسازد.
- Latency: Decision خوب اما دیر، Checkout را خراب میکند.
بنابراین Threshold پیشفرض ۰٫۵ هیچ تقدسی ندارد. تیم باید Curve معیارها، هزینهٔ تقریبی هر خطا، ظرفیت Review و توزیع واقعی Traffic را کنار هم ببیند. ممکن است دو Threshold تعریف شود: زیر ۰٫۳ پذیرش، ۰٫۳ تا ۰٫۷ بررسی و بالاتر از ۰٫۷ توقف؛ این اعداد فقط نمونهاند و باید با Evidence محلی تعیین شوند.
واحد ارزیابی و Split
اگر یک مشتری یا Device در Train و Test تکرار شود، مدل شاید هویت را حفظ کند و Generalization مصنوعی نشان دهد. Split را بر اساس زمان و Entity طراحی کنید: Train از Window قدیمیتر، Validation برای انتخاب، و Test نهایی از بازهٔ بعدی که تا پایان تصمیم قفل میماند. دادهٔ پس از زمان Decision، Chargeback آینده یا Feature مشتق از Outcome نباید به ورودی برسد.
تست داده: قبل از آموزش جلوی نتیجهٔ دروغین را بگیرید
در ML، Dataset یک وابستگی نسخهدار است. راهنمای مدیریت داده تست برای Masking، دادهٔ مصنوعی و حداقلسازی داده مکمل این بخش است.
Contract داده
| بعد | تست نمونه | Evidence |
|---|---|---|
| Schema | نام/نوع/واحد، Required، Categoryهای مجاز | Schema version و Failure report |
| Completeness | Null rate به تفکیک Source و روز | Trend و Threshold قراردادی |
| Validity | مبلغ منفی، زمان آینده، شماره/کد نامعتبر | Count و نمونهٔ Redacted |
| Uniqueness | Duplicate transaction/entity | Duplicate key report |
| Freshness | سن Feature هنگام Decision | p95 age و late-arrival rate |
| Distribution | تغییر Category، Quantile و Missingness | مقایسه با Baseline Window |
| Lineage | Source→Transform→Feature→Dataset | نسخه و checksum قابلردیابی |
اگر Dataset از چند جدول، Migration یا Backfill ساخته میشود، Constraint و Integrity منبع را هم مستقل بیازمایید؛ راهنمای تست پایگاه داده برای Invariant، Transaction، Migration و Evidence مکمل این Contract است.
Label را مثل Requirement تست کنید
- تعریف عملیاتی Label و Window بلوغ آن چیست؟
- نمونههای مبهم یا Dispute چگونه adjudicate میشوند؟
- نرخ توافق Labelerها و علت اختلاف چیست؟
- آیا Positiveهای کشفنشده بهاشتباه Negative شمرده شدهاند؟
- آیا Label پس از یک Policy change معنای قبلی را دارد؟
- آیا دادهٔ حذفشده یا رضایتپسگرفته از مشتقات نیز پاک میشود؟
Agreement بالا لزوماً Label درست نمیسازد؛ ممکن است همه از Guideline اشتباه پیروی کنند. نمونهبرداری مستقل توسط Domain expert و ثبت تغییر نسخهٔ Label policy ضروری است.
چک Leakage
- Temporal leakage: Feature بعد از لحظهٔ پیشبینی ساخته شده است.
- Target leakage: Proxy مستقیم Outcome وارد Feature شده است.
- Entity leakage: مشتری، Device یا Case یکسان در دو Split است.
- Preprocessing leakage: Imputer، Normalizer یا Vocabulary روی کل Dataset Fit شده است.
- Duplicate leakage: رکورد تقریباً یکسان در Train و Test تکرار شده است.
- Selection leakage: بارها روی Test نهایی تصمیم گرفته و Test عملاً Validation شده است.
برای مقادیر عددی و Contractهای قطعی، تقسیمبندی همارزی و تحلیل مقدار مرزی هنوز مفید است: صفر/منفی/حداکثر مبلغ، Empty/Null، مرز تاریخ، Unicode فارسی و Category ناشناخته را مستقل تست کنید.
ارزیابی آفلاین مدل: Accuracy کافی نیست
Confusion matrix و هزینهٔ خطا
برای کلاس «تقلب»:
Precision = TP / (TP + FP): از مواردی که مدل تقلب اعلام کرده، چند مورد واقعاً تقلب بودهاند؟Recall = TP / (TP + FN): از کل تقلبها، چند مورد کشف شدهاند؟FPR = FP / (FP + TN): از خریدهای سالم، چه سهمی اشتباه علامت خوردهاند؟
اگر فقط ۰٫۵٪ تراکنشها تقلب باشند، مدلی که همیشه «سالم» میگوید Accuracy برابر ۹۹٫۵٪ دارد و عملاً بیفایده است. Precision و Recall نیز بدون Prevalence، Threshold، Window و هزینه تفسیر کامل ندارند. AUC رتبهبندی کلی را خلاصه میکند، اما رفتار در Operating point واقعی و ظرفیت Review را تضمین نمیکند.
Baseline و Champion/Challenger
مدل تازه را حداقل با اینها مقایسه کنید:
- Rule یا Heuristic موجود؛
- نسخهٔ فعلی Production؛
- مدل ساده و قابلتوضیح؛
- Random/majority baseline در جای مناسب؛
- Ablation برای فهم ارزش هر Feature group.
هر تغییر باید Dataset، Metric implementation و Threshold یکسان داشته باشد. «بهبود دو درصدی» بدون Confidence interval، حجم نمونه و Slice میتواند Noise باشد.
Threshold را با Curve و ظرفیت انتخاب کنید
- Metricهای Precision/Recall/FPR را در Thresholdهای مختلف محاسبه کنید.
- هزینه یا Utility تقریبی هر Outcome را با Product/Operations بنویسید.
- تعداد Case روزانهٔ Review را در Traffic واقعی برآورد کنید.
- Threshold را روی Validation انتخاب کنید؛ Test قفلشده فقط برای گزارش نهایی است.
- پس از Release، Threshold و Policy را نسخهدار و قابل Rollback نگه دارید.
Calibration
اگر مدل برای ۱۰۰۰ مورد امتیاز حدود ۰٫۸ میدهد، انتظار داریم نزدیک به ۸۰٪ آن گروه Outcome مثبت داشته باشند؛ این شهود Calibration است. Reliability diagram، Brier score یا معیار مناسب میتواند کمک کند، اما Calibration کلی ممکن است Sliceهای بد را پنهان کند. تغییر Prevalence نیز Calibration را جابهجا میکند.
عدمقطعیت آماری
- حجم نمونه و تعداد Positive هر Slice را گزارش کنید.
- Confidence interval یا Bootstrap مناسب را کنار Point estimate بیاورید.
- چندین Run آموزش را در مدلهای حساس به Seed مقایسه کنید.
- برای Sample کوچک، نتیجه را «نامطمئن» بنامید؛ آن را به Pass قطعی تبدیل نکنید.
- Multiple comparison را در بررسی Sliceهای فراوان نادیده نگیرید.
Slice testing: میانگین خوب، آسیب محلی را پنهان میکند
Slice باید از Risk و الگوی استفاده بیاید، نه صرفاً هر ستونی که در Dataset وجود دارد. نمونهها برای فروشگاه ایرانی:
| Slice | چرا مهم است؟ | Metric/Gate نمونه |
|---|---|---|
| کاربر تازه/قدیمی | History کم ممکن است امتیاز را منحرف کند | FPR و Review rate جداگانه |
| وب/Android/iOS | Feature availability متفاوت است | Missingness، Recall، Latency |
| درگاه/روش پرداخت | توزیع و Failure mode فرق دارد | Coverage و FN cost |
| مبلغ و ساعت مرزی | Rare/high-impact case | Recall در Rangeهای مصوب |
| نسخهٔ App | Schema یا Feature قدیمی | Unknown category و Error rate |
| تقاطع دو Slice | Average هرکدام ممکن است مسئله را پنهان کند | Metric + uncertainty، در صورت حجم کافی |
هر Slice کوچک را به نتیجهٔ اخلاقی قطعی تبدیل نکنید. Sample size، Label quality و Context را ثبت کنید. همچنین دادهٔ حساس را فقط با مبنای مجاز، دسترسی حداقلی و هدف مشخص استفاده کنید.
Metamorphic، Property-based و Robustness testing
وقتی Expected دقیق برای هر ورودی ندارید، رابطهای را تست کنید که باید حفظ شود:
- تغییر فاصله یا شکل «ی/ی» و «ک/ک» نباید Category نامرتبط بسازد، مگر اینکه Feature عمداً به آن حساس باشد.
- Permutation ورودیهای مستقل نباید نتیجهٔ Aggregate را تغییر دهد.
- تغییر کوچک و غیرمعنادار نباید جهش بزرگ ناموجه ایجاد کند.
- Feature حذفشده یا مجازنبودنی نباید از Cache قدیمی برگردد.
- افزایش Risk signal معتبر باید رفتار Monotonic موردانتظار را حفظ کند، اگر Design چنین تضمینی دارد.
این Properties باید Domain-approved باشند؛ «هر تغییر کوچک باید خروجی یکسان بدهد» قانون جهانی نیست. Robustness را روی Noise واقعی، Missing feature، Outlier، Compression، Input malformed و Dependency failure بسنجید.
Adversarial ML با Threat model
NIST AI 100-2e2025 تهدیدهایی مانند Evasion، Poisoning و Privacy attack را در چرخهٔ AI طبقهبندی میکند. تست امنیتی AI باید Threat actor، Goal، Knowledge، Capability و Surface را مشخص کند:
- آیا مهاجم میتواند Featureهای ورودی را برای عبور تغییر دهد؟
- آیا Training data یا Label pipeline قابل Poisoning است؟
- آیا API با Query فراوان اطلاعات Model/Data را افشا میکند؟
- آیا Artifact، Registry، Dependency یا Notebook مجوز بیش از حد دارد؟
- آیا Log شامل Feature حساس، Prompt، Token یا شناسهٔ واقعی است؟
این آزمایشها فقط در Scope مجاز و محیط کنترلشده انجام شوند. راهنمای تست امنیت نرمافزار برای Threat modeling، کنترل دسترسی و مدیریت Evidence مکمل است.
Fairness، Explainability و Privacy را چگونه بیازماییم؟
Fairness یک Metric جهانی ندارد
معیارهایی مانند Demographic parity، Equalized odds یا Equality of opportunity میتوانند در یک Context با هم ناسازگار باشند. ابتدا Stakeholder متأثر، نوع آسیب، Role سیستم در تصمیم و Policy انسانی را مشخص کنید؛ سپس Metric و Slice متناسب را انتخاب کنید.
- عملکرد کلی و Sliceهای مرتبط را با عدمقطعیت گزارش کنید.
- Intersectionها را فقط با حجم و حفاظت کافی بررسی کنید.
- دادهٔ حساس را برای «اندازهگیری خوب» بیمجوز جمع نکنید.
- مسیر Override، Appeal و پاسخگویی انسانی را هم تست کنید.
- عبارت «Bias حذف شد» را با Evidence محدود جایگزین کنید: چه Biasی، روی کدام داده و Window؟
Explainability مدرک صحت نیست
SHAP، LIME یا Feature attribution میتواند برای کشف Proxy، Leakage یا رفتار غیرمنتظره مفید باشد؛ اما Explanation زیبا ثابت نمیکند مدل درست، علّی یا منصفانه است. Stability توضیح، سازگاری با دانش دامنه و پاسخ به Counterfactualهای معتبر را بررسی کنید و محدودیت ابزار را ثبت کنید.
Privacy در کل چرخه
- حداقلسازی Feature و هدف استفاده؛
- مجوز و Retention برای Raw data، Dataset، Artifact و Backup؛
- Masking/Pseudonymization همراه با ارزیابی بازشناسایی؛
- حذف داده در مشتقات و Snapshotها؛
- دسترسی Role-based به Registry، Feature store و Experiment tracker؛
- Redaction در Log، Trace، Dashboard و Failure artifact.
Reproducibility: چه چیزی باید نسخهدار باشد؟
برای بازتولید یک نتیجه فقط Seed کافی نیست. Release را به Manifest زیر وصل کنید:
- Commit کد و نسخهٔ Pipeline؛
- Dataset ID، Query/Snapshot، Window و checksum؛
- Label policy و نسخهٔ Feature definition؛
- Algorithm، Hyperparameter، Seed و Configuration؛
- نسخهٔ کتابخانه، Runtime، Container و Driver؛
- Hardware/accelerator و تنظیمات محاسباتی مؤثر؛
- Metric code، Slice definition و Threshold؛
- Model artifact hash و امضای Approval.
برخی عملیات GPU یا Sampling مولد میتوانند با Seed هم دقیقاً تکرار نشوند. در این موارد، Runهای تکراری، Tolerance ازپیشتعریفشده و توزیع نتایج را ثبت کنید. Tolerance را بعد از دیدن Failure آنقدر بزرگ نکنید که Regression پنهان شود.
تست Pipeline و Serving: مدل خوب میتواند در سیستم بد شکست بخورد
Training-serving skew
- Transform یک ورودی ثابت در Training و Serving برابر یا در Tolerance باشد.
- Timezone، واحد پول، Encoding و Missing value semantics یکی باشد.
- Feature version و freshness در Response/Trace قابلردیابی باشد.
- Unknown category و Schema قدیمی Fallback مشخص داشته باشند.
- Batch و Online scoring روی Golden records مقایسه شوند.
Contract و Failure mode
- Schema ورودی/خروجی، Range امتیاز، Model version و Error code؛
- Model load ناقص، Artifact خراب یا Registry unavailable؛
- Feature store timeout/کهنه، Queue backlog و Dependency failure؛
- Retry، Circuit breaker و Idempotency در Decision؛
- Fallback به Rule/model قبلی یا Human review؛
- مجوز Tenant/User و جلوگیری از IDOR یا Cross-tenant leakage.
Performance و Capacity
Latency مدل را جدا و Journey کامل را هم اندازه بگیرید: Feature fetch، Serialization، Queue، Inference و Post-processing. p50 بهتنهایی Tail را پنهان میکند؛ p95/p99، Throughput، Timeout، CPU/GPU/Memory، Queue depth، Cold start و Cost per decision را در Load model واقعی گزارش کنید.
Release Gate عملی برای مدل
Gate باید نسخهدار، قابلاجرا و متصل به Decision باشد. یک نمونه:
| Gate | Evidence | Pass rule نمونه | Owner |
|---|---|---|---|
| Data | Schema، Leakage، label maturity، lineage | هیچ Leakage بحرانی؛ Contractهای Required سبز | Data owner |
| Offline quality | Baseline، Metric، CI، Slice | Recall/FPR مصوب و عدم Regression بحرانی | DS + Product |
| Safety/fairness | Harm cases، Slice، override/appeal | سقف آسیب و Review مستقل رعایت شود | Risk/domain |
| Security/privacy | Threat tests، access، logs، retention | Issue بحرانی باز نباشد | Security/privacy |
| System | Contract، skew، latency، fallback | SLO و Failure policy پاس شود | Engineering/SRE |
| Online readiness | Shadow/canary، guardrail، rollback | Owner، dashboard و kill switch آزموده | Release owner |
Pass rule عمومی در این جدول عمداً عدد ثابت ندارد. برای مثال تقلب، نسخهٔ واقعی میتواند بگوید: «Recall تقلبهای پرزیان از Baseline با Margin مصوب کمتر نشود؛ FPR کاربران تازه از سقف مصوب عبور نکند؛ p95 Journey زیر SLO باشد؛ و ظرفیت Review روزانه تجاوز نکند.» Dataset و Window باید کنار همین اعداد ثبت شوند.
Shadow، Canary و آزمون آنلاین امن
Shadow
Traffic واقعی به مدل تازه Mirror میشود اما تصمیم آن روی کاربر اعمال نمیشود. این مرحله Schema، Latency، Drift، Cost و اختلاف با مدل فعلی را نشان میدهد. Shadow بدون Ground truth فوری کیفیت نهایی را ثابت نمیکند و میتواند همچنان دادهٔ حساس را پردازش کند؛ Privacy و ظرفیت را جدی بگیرید.
Canary
اثر مدل برای سهم کوچک و قابلشناسایی Traffic فعال میشود. Allocation باید Bias ناموجه نداشته باشد و Guardrailها پیشاپیش تعیین شوند:
- نرخ توقف خرید سالم و Appeal؛
- Conversion و Abandonment؛
- Review queue و زمان پاسخ؛
- Fraud loss با Label delay؛
- Latency/Error/Timeout؛
- Sliceهای پرریسک.
Stop، rollback و roll-forward
Stop condition باید Machine-readable یا حداقل Operationally explicit باشد: چه Metricی، در چه Window، با چه حداقل Sample و چه Ownerی؟ Rollback فقط بازگرداندن Artifact نیست؛ Threshold، Feature version، Cache، Policy و Schema نیز باید سازگار باشند. برای طراحی سطح ریسک، مشاهدهپذیری و Kill switch از راهنمای تست Shift-Right در Production استفاده کنید.
Drift را درست نامگذاری و پایش کنید
| نوع تغییر | معنا | قابلمشاهده بدون Label؟ |
|---|---|---|
| Data/covariate drift | توزیع ورودی یا P(X) تغییر کرده | اغلب بله |
| Label/prior drift | شیوع Outcome یا P(Y) تغییر کرده | پس از رسیدن Label |
| Concept drift | رابطهٔ ورودی و Outcome یا P(Y|X) تغییر کرده | معمولاً با Label/Proxy معتبر |
| Quality drift | Metric واقعی مدل افت کرده | با Ground truth و Window |
PSI یا فاصلهٔ توزیع ورودی بهتنهایی Concept drift را ثابت نمیکند. تغییر ورودی ممکن است بیاثر باشد و افت مدل ممکن است بدون Drift واضح یک Feature رخ دهد. Dashboard باید اینها را جدا نگه دارد:
- Schema، Missingness، freshness و unknown category؛
- Feature distribution و prediction distribution؛
- Outcome metric پس از Label delay؛
- Calibration و Slice performance؛
- Business outcome، override و complaint؛
- نسخهٔ Model/Feature/Policy و Traffic allocation.
بازآموزی خودکار پس از Alert Drift، بدون Dataset review و Release Gate، ریسک را خودکار میکند. Retraining باید همان Gate داده، مدل، سیستم و آنلاین را طی کند.
تست Generative AI و LLM چه تفاوتی دارد؟
برای Chatbot، RAG یا Agent نمیتوان Precision/Recall طبقهبندی را بیواسطه معیار اصلی گرفت. NIST AI ۶۰۰-۱، پروفایل Generative AI ریسکهای ویژهٔ این سیستمها را در امتداد AI RMF بررسی میکند. Test plan مولد باید Task و Failure taxonomy خودش را داشته باشد.
Golden set وظیفهمحور
- Task success و پوشش Intent واقعی؛
- صحت Fact و Groundedness نسبت به Source مجاز؛
- کیفیت Citation و امکان Trace به Passage؛
- رعایت Schema برای JSON/Structured output؛
- عدم افشای داده، Secret و System instruction؛
- Refusal درست: نه بیشازحد، نه کمتر از Policy؛
- Latency، Token/Cost و Rate limit؛
- زبان فارسی، RTL، نیمفاصله و ورودی ترکیبی فارسی/انگلیسی.
Agent و Tool use
پاسخ متنی خوب کافی نیست. Authorization هر Tool، Confirmation برای Action پراثر، Argument validation، Idempotency، Budget، Timeout و Audit log را تست کنید. Prompt injection در سند بازیابیشده نباید مجوز Tool را تغییر دهد. Action خارجی را در Sandbox و با دادهٔ مصنوعی ارزیابی کنید.
Oracle چندلایه
Exact match برای Schema و Factهای قطعی؛ Rule-based check برای Citation/PII؛ Model-based judge برای مقیاس؛ و Human expert برای نمونهٔ حساس. Judge نیز مدل است: Rubric، نسخه، Bias، توافق با انسان و Failureهایش را بسنجید. چند Sample با Temperature/Seed ثبتشده اجرا کنید و فقط بهترین خروجی را گزارش نکنید.
CI/CD برای ML: تستها را بر اساس سرعت و ریسک لایهبندی کنید
مقالهٔ کلاسیک The ML Test Score از Google Research ۲۸ نیاز تست و پایش را برای آمادگی Production صورتبندی میکند. پیام مهم آن هنوز کاربردی است: Production readiness فقط Model accuracy نیست.
| Lane | تست | زمان اجرا |
|---|---|---|
| Fast/PR | Unit transform، schema fixture، metric unit test، serialization، small golden set | هر Commit/PR |
| Training | Lineage، leakage، reproducibility، baseline، slice، calibration | هر Candidate |
| System | Registry→serving، skew، contract، load، fallback، security | Candidate/release |
| Pre-release | Full frozen set، risk review، release card، rollback drill | پیش از Approval |
| Online | Shadow، canary، guardrail، drift/outcome monitoring | Rollout و مداوم |
آزمون کند را بیدلیل وارد Fast lane نکنید؛ اما Failure در Nightly پرریسک هم نباید بدون Owner و Gate رها شود. Flaky statistical test را با Tolerance علمی، Repeat و حجم نمونه اصلاح کنید، نه با Rerun تا سبز شود.
Model Release Card: قالب قابلکپی
Model/feature/policy version: …
Purpose / users / decision: …
Non-goals و prohibited use: …
Risk owner / approval: …
Training/validation/test windows: …
Data lineage / label policy / exclusions: …
Baseline / metrics / threshold: …
Slice results / sample size / uncertainty: …
Robustness / fairness / privacy / security evidence: …
Known limitations و unsupported inputs: …
System SLO / fallback / human override: …
Shadow/Canary allocation و guardrails: …
Monitoring / label delay / alert owner: …
Stop condition / rollback artifact: …
Approval date / next review: …
این Card جای Model card عمومی یا سند Governance را نمیگیرد؛ یک رابط تصمیم Release است. هر ادعا باید به Artifact قابلبازتولید لینک شود. برای جلوگیری از Vanity metric، راهنمای متریکهای تست نرمافزار را برای تعریف Denominator، Window، Owner و Decision مطالعه کنید.
برنامهٔ ۳۰روزه برای ساخت فرایند تست AI/ML
هفتهٔ اول: مرز، ریسک و Baseline
- Decision، کاربران متأثر، Non-goal و Failureهای پرهزینه را بنویسید.
- Inventory داده، مدل، Feature، سرویس و Owner را کامل کنید.
- Baseline فعلی، Dataset قفلشده و Label delay را ثبت کنید.
- Metric و Slice را از Risk استخراج کنید.
هفتهٔ دوم: Gate داده و ارزیابی آفلاین
- Schema/freshness/lineage و Leakage tests را خودکار کنید.
- Confusion matrix، Threshold curve، Calibration و Slice report بسازید.
- Reproducibility manifest و Artifact hash را در Pipeline ذخیره کنید.
- Golden/critical cases را با Domain expert بازبینی کنید.
هفتهٔ سوم: سیستم، امنیت و عملیات
- Training-serving parity، Contract، Fallback و Load را تست کنید.
- Threat model، Access و Privacy evidence را تکمیل کنید.
- Dashboard نسخهمحور، Alert owner و Runbook بسازید.
- Rollback/kill switch را در محیط کنترلشده تمرین کنید.
هفتهٔ چهارم: Shadow، Canary و بازنگری
- Shadow را با Budget و Data controls اجرا کنید.
- Release card و تصمیم Approval را ثبت کنید.
- Canary کوچک با Guardrail و Stop condition روشن اجرا کنید.
- Failureها، Label delay و شکاف Evidence را در Retrospective وارد Backlog کنید.
نکات ویژه برای داده و محصول فارسی در ایران
- Unicode: «ی/ی»، «ک/ک»، نیمفاصله، اعداد فارسی/لاتین و Normalization باید Contract روشن داشته باشند.
- زمان: تقویم جلالی/میلادی، Timezone تهران، تغییر Offset تاریخی و Cutoff زمانی را تست کنید.
- پول: ریال/تومان، Scale، Separator و تبدیل واحد باید در Feature و Label یکسان باشند.
- شناسه و آدرس: موبایل با ۰/+۹۸، کدپستی، نام شهر و Transliteration را با دادهٔ مصنوعی/ماسکشده پوشش دهید.
- دسترسی Provider: محدودیت جغرافیایی، تغییر Model/API، Rate limit، قطع سرویس و Data residency را در Fallback لحاظ کنید.
- زبان: Dialect، غلط املایی، Finglish، متن راستبهچپ و ترکیب English/Persian را Slice کنید.
- حریم خصوصی: Notebook، Experiment tracker، Prompt log و Dataset export را مثل Production data محافظت کنید.
این Sliceها نسخهٔ ثابت همهٔ محصولات نیستند. با Traffic واقعی، Threat model و کاربران خود انتخابشان کنید و از نگهداری بیهدف اطلاعات حساس بپرهیزید.
اشتباههای رایج در تست AI/ML
- Accuracy بالا = آمادهٔ انتشار: Imbalance، هزینهٔ خطا و Slice دیده نمیشوند.
- Test set بارها مصرف میشود: مدل به ارزیابی نهایی Overfit میشود.
- Random split برای دادهٔ زمانی: آینده و Entity مشترک نتیجه را آلوده میکنند.
- Threshold برابر ۰٫۵: هزینه و ظرفیت عملیات نادیده گرفته میشود.
- Drift ورودی = Concept drift: بدون Label رابطهٔ X و Y اثبات نشده است.
- Retrain خودکار = تعمیر: دادهٔ بد یا Attack میتواند نسخهٔ بدتری بسازد.
- Explainability = حقیقت: Attribution جای Validation و تحلیل علّی نیست.
- Fairness score واحد: Trade-off، Stakeholder و Sample size پنهان میشوند.
- فقط Notebook: Registry، Serving، Policy و Rollback تست ندارند.
- Shadow = بیخطر: هنوز Compute، داده و Privacy درگیرند.
- Judge مدل = Oracle قطعی: Bias و Version drift ارزیاب فراموش میشود.
- Rerun تا Pass: عدمقطعیت بهجای اندازهگیری پنهان میشود.
چکلیست نهایی تست سیستم AI/ML
- Purpose، Non-goal، کاربران متأثر و پیامد خطا مستند است.
- Risk statementها به Test، Gate، Owner و Mitigation وصلاند.
- Data lineage، Window، مجوز، نسخه و Retention معلوم است.
- Schema، Null، Range، Duplicate، freshness و distribution تست میشوند.
- Label policy، توافق، بلوغ و اختلاف برچسب بررسی شده است.
- Temporal/target/entity/preprocessing leakage کنترل شدهاند.
- Train/validation/test جدا و Test نهایی قفل است.
- Baseline، Metric، Threshold و هزینهٔ FP/FN ثبت شدهاند.
- Calibration، uncertainty، rare case و Sliceهای پرریسک گزارش میشوند.
- Metamorphic، robustness و threat-based security test وجود دارد.
- Fairness/Privacy/Explainability با محدودیت و Context بررسی شدهاند.
- Code/data/feature/config/seed/runtime/artifact نسخهدارند.
- Training-serving parity، Contract، fallback و load پاس شدهاند.
- Shadow/Canary، guardrail، stop و rollback تمرین شدهاند.
- Drift ورودی، Concept drift و افت Outcome جدا پایش میشوند.
- Label delay، Human override، Appeal و Alert owner تعریف شدهاند.
- Release card به Evidence و Approval قابلردیابی است.
سوالات متداول تست AI و یادگیری ماشین
آیا برای تست مدل ML باید خروجی هر ورودی دقیقاً معلوم باشد؟
نه همیشه. Transform و Contract قطعی میتوانند Expected دقیق داشته باشند؛ کیفیت مدل معمولاً با Dataset قفلشده، Metric، Slice، Tolerance و عدمقطعیت سنجیده میشود. برای موارد فاقد Oracle کامل از رابطهٔ Metamorphic، Baseline و ارزیابی انسانی کنترلشده استفاده کنید.
Accuracy، Precision یا Recall؛ کدام معیار بهتر است؟
هیچکدام جهانی نیست. اگر کلاس نامتوازن باشد Accuracy گمراهکننده است. Precision هزینهٔ False Positive و Recall هزینهٔ False Negative را بهتر نمایان میکنند، اما انتخاب نهایی باید با Threshold، Prevalence، ظرفیت عملیات و پیامد کسبوکار انجام شود.
Data drift چه تفاوتی با Concept drift دارد؟
Data drift تغییر توزیع ورودی P(X) است؛ Concept drift تغییر رابطهٔ P(Y|X). ورودی را اغلب بدون Label میتوان پایش کرد، اما اثبات افت رابطه معمولاً Outcome/Label لازم دارد. Alert توزیع بهتنهایی دلیل کافی برای Retrain خودکار نیست.
چطور مدل غیرقطعی یا LLM را Regression test کنیم؟
نسخهٔ Model/Prompt/Config/Seed را ثابت کنید، Golden set وظیفهمحور را چند بار اجرا و توزیع نتیجه را با Tolerance ازپیشتعریفشده مقایسه کنید. Schema و Fact قطعی را Exact بسنجید؛ Judge مدل را با Rubric و نمونهٔ انسانی Calibration کنید و فقط بهترین Run را گزارش نکنید.
آیا Model card برای Release کافی است؟
خیر. Model card محدودیت و ویژگی مدل را مستند میکند، اما Release به Evidence داده، Serving، Security، Privacy، SLO، Shadow/Canary، Stop condition و Rollback نیز نیاز دارد. Release card باید این شواهد را به Owner و تصمیم قابلردیابی وصل کند.
منابع و یادداشت بازبینی
ساختار Risk-based این مقاله با ISO/IEC TS ۴۲۱۱۹-۲:۲۰۲۵ و NIST AI RMF ۱.۰؛ آمادگی Production با پژوهش ML Test Score؛ امنیت با NIST AI ۱۰۰-2e2025؛ و بخش مولد با NIST AI ۶۰۰-۱ تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. معیار و Threshold نمونه را بدون Dataset، پیامد، مقررات و Review تخصصی حوزهٔ خود وارد Production نکنید.
جمعبندی: واحد تست در AI فقط «مدل» نیست؛ سیستم اجتماعی-فنی از داده تا تصمیم و بازخورد است. از Risk و Oracle شروع کنید، Leakage را پیش از Training بگیرید، Average را با Slice و عدمقطعیت بشکنید، Threshold را به هزینه وصل کنید، Serving و Human workflow را بیازمایید و انتشار را با Shadow، Canary و Rollback کنترل کنید. آنگاه Metric به Evidence تصمیم تبدیل میشود، نه عددی تزئینی در Dashboard.
