تست مدل یادگیری ماشین با گزارش یک Accuracy یا F1 تمام نمیشود. پیش از هر عدد باید بدانیم Model artifact برای کدام Intended Use، روی چه Population و Operating condition، با کدام Label و Split، در چه Threshold و با چه هزینهٔ خطایی ارزیابی میشود. بعد هم باید نشان دهیم Test set به آموزش و انتخاب مدل نشت نکرده، Metric با تصمیم واقعی سازگار است، Sliceهای پرریسک پنهان نشدهاند و Evidence به نسخهٔ دقیق داده، کد و مدل متصل است.
این راهنما یک Evaluation Protocol قابلنسخهبندی میسازد: Intended Use → Claim → Dataset/Split → Label/Oracle → Metric/Threshold → Uncertainty → Slice/Metamorphic/Robustness → Reproducibility → Model Release Gate. هدف «تضمین هوش مصنوعی قابلاعتماد» نیست؛ هدف تولید شواهد محدود و صادقانه برای یک تصمیم مشخص دربارهٔ یک Model candidate است.
خلاصهٔ اجرایی پروتکل ارزیابی مدل
- Intended Use، Out-of-scope Use و Consequence خطا را تعریف کنید.
- Task، Unit of analysis، Population، Label و Prediction horizon را قفل کنید.
- Split را پیش از preprocessing/feature selection/tuning و بر اساس زمان/گروه/Dependency طراحی کنید.
- Baseline و Candidate، Metric، Averaging، Threshold و Gate را پیش از Test نهایی ثبت کنید.
- Confusion matrix، Calibration، Uncertainty و Sliceهای ازپیشتعریفشده را کنار Metric کل گزارش دهید.
- Metamorphic relation، Boundary، Missingness، Perturbation و Shift scenario را با Claim محدود بیازمایید.
- Test set نهایی را برای انتخاب مکرر مصرف نکنید؛ Selection و Confirmation را جدا نگه دارید.
- Model artifact، Data snapshots، Code/Config/Seed/Environment و Evaluation output را هویتگذاری کنید.
- PASS را فقط برای شرایط آزمودهشده بنویسید و Unknown/INCONCLUSIVE را پنهان نکنید.
- برای کل AI system، Fairness/Harm، XAI، Privacy و Production Monitoring به مالکان تخصصی متصل شوید.
مرز این مقاله با تست کل سیستم AI/ML
این صفحه فقط Model artifact و پروتکل ارزیابی پیش از Release را مالک است. برای Data/Feature pipeline، Serving API، latency، fallback، Shadow، Drift و Incident به راهنمای تست سیستمهای AI/ML مراجعه کنید. برای قرارداد خط داده و Replay، تست Data Pipeline مالک محتواست.
| Intent | مالک | مرز با این صفحه |
|---|---|---|
| Harm، Fairness، Contestability و Remedy | تست اخلاقی AI | اینجا فقط Metric/slice contract را مرزبندی میکنیم |
| Explanation fidelity و فهم کاربر | تست XAI | Feature importance را اثبات علیت نمینامیم |
| Label/Leakage در Defect-risk product | پیشبینی ریسک نقص | یک Domain case تخصصی است |
| PII، Purpose، Retention و Data subject rights | تست حریم خصوصی داده | Evaluation data مجوز مصرف مستقل میخواهد |
| ارزیابی ابزار/Agent تست AI | ارزیابی ابزار AI Testing | محصول مورد ارزیابی متفاوت است |
| Expected result و Comparator عمومی | Test Oracle | Label/Metric Oracle را اینجا تخصصی میکنیم |
Model artifact با ML system یکی نیست
| سطح | نمونه Claim | شاهد مناسب |
|---|---|---|
| Dataset | Population/label/split مناسب است | datasheet، audit، sampling evidence |
| Feature transform | فقط اطلاعات prediction-time را مصرف میکند | lineage، unit/property tests |
| Model artifact | روی locked test و threshold مشخص معیارها را دارد | evaluation report |
| Serving | همان feature/schema/model را اجرا میکند | contract/differential test |
| Human workflow | Operator خروجی را درست میبیند/استفاده میکند | usability/human factors |
| Outcome | سیستم در Context سود/ضرر مشخص دارد | field study/monitoring/impact evidence |
مدلی با Recall خوب ممکن است در Serving بهعلت Feature skew بد عمل کند؛ سیستم با پیشبینی درست ممکن است UI گمراهکننده یا Automation bias داشته باشد؛ و Metric فنی بهتر ممکن است Outcome انسانی بهتر نسازد. پس نتیجهٔ Model evaluation را به کل سامانه یا جامعه تعمیم ندهید.
Evaluation، Testing، Verification و Validation
| فعالیت | پرسش | خروجی |
|---|---|---|
| Verification | Artifact طبق Specification ساخته شده؟ | implementation evidence |
| Evaluation | روی Dataset/Metric مشخص چه عددی دارد؟ | measurement + uncertainty |
| Testing | Claimها زیر Example/Boundary/Relation/Fault چه میشوند؟ | verdict + counterexample |
| Validation | برای Intended Use و Context مناسب است؟ | fitness/limit decision |
| Monitoring | شرایط و رفتار پس از Release تغییر کرده؟ | signal → investigation/response |
این اصطلاحها در سازمانها ممکن است متفاوت تعریف شوند؛ قرارداد داخلی را ثبت کنید. بخش Measure در NIST AI RMF Playbook مستندسازی Test set، Metric، ابزار TEVV، شرایط کاربرد، حدود تعمیم و عدمقطعیت را توصیه میکند. این Playbook داوطلبانه است، checklist اجباری یا گواهی انطباق نیست و خود NIST اعلام کرده AI RMF ۱.۰ در حال بازنگری است.
Intended Use Contract؛ نقطهٔ شروع Metric
model_use_contract: use_case: route fictional payment-support cases to human review decision: prioritize review queue; never auto-settle or deny operator/user: trained support analyst subject/unit: one synthetic PaymentAttempt case population: declared marketplace support cases prediction_target: needs reconciliation within defined horizon prediction_time: before analyst review available_features: only fields available at prediction_time output: score + model/version + limitations action/threshold: queue priority under capacity C high-cost error: missed timeout-after-commit case fallback: ordinary review path out_of_scope: credit, fraud accusation, employment, health, identity owner/approver: named review/expiry: dated
«تشخیص تقلب»، «ریسک مشتری» یا «مدل خوب» Intended Use نیست. Unit، زمان تصمیم، Actor، Action، ظرفیت، Benefit/Harm، fallback و ممنوعیتها باید قابلمشاهده باشند. اگر خروجی فقط Queue priority است، Evaluation نباید آن را حکم جرم یا حقیقت دربارهٔ شخص بنامد.
Model Claim Contract
claim_id: M-C1 claim: detect use-critical reconciliation cases for human routing model_candidate: artifact digest population/split: locked_test_v2 operating_point: threshold=0.50 metrics: overall_recall >= predeclared limit critical_slice_recall >= predeclared limit false_positive workload <= review capacity comparators: baseline + prior approved model uncertainty: method and interval declared known_unknowns: low support / label delay / excluded cases required_tests: leakage audit, slice, metamorphic, robustness verdict_owner: evaluation owner release_decision_owner: product/risk owner
Claim با Goal فرق دارد. Goal ممکن است «کاهش زمان بررسی» باشد؛ Claim باید قابلردشدن باشد. Threshold و Gate نیز واقعیت علمی جهانی نیستند؛ از Cost، capacity، risk tolerance و Domain review میآیند و باید پیش از نگاهکردن به Test نهایی تثبیت شوند.
هویت و Lineage ارزیابی مدل
| هویت | نمونه | هدف |
|---|---|---|
| Experiment/Run | evaluation_run_id | تفکیک attemptها |
| Model artifact | digest + registry version | همان Candidate دقیق |
| Training data | snapshot/manifest/query hash | بازتولید fit |
| Validation data | snapshot + split IDs | selection/tuning |
| Locked test | sealed snapshot + access log | confirmation مستقلتر |
| Label | definition/version/horizon | تعریف Target |
| Feature pipeline | code/config/schema | Leakage/skew trace |
| Environment | image/dependencies/hardware | reproducibility |
| Randomness | seed + algorithm controls | variation analysis |
| Protocol | metric/threshold/slice version | prevent outcome-driven edits |
Population، Sample و Unit of Analysis
هر Report باید Target population، Sampling frame، Inclusion/Exclusion، observation window، missing/unknown و Unit را بنویسد. اگر چند ردیف متعلق به یک User/Device/Order/Patient هستند، محاسبهٔ interval با فرض استقلال ردیفها میتواند بیشازحد مطمئن باشد. Group، cluster و repeated measures را در Split و uncertainty لحاظ کنید.
evaluation_population: intended_population: declared cases during operating condition O sampling_frame: immutable query/snapshot unit_of_analysis: PaymentAttempt, not event row grouping: tenant_id + order_id inclusion/exclusion: explicit with counts observation/label_horizon: fixed known_missingness: reasoned categories sample_size_by_class_slice: reported representativeness_limits: documented, not assumed
Label Contract؛ Ground Truth همیشه ساده نیست
| فیلد | پرسش | ریسک |
|---|---|---|
| Construct | واقعاً چه مفهوم مشاهدهناپذیری را Proxy میکنیم؟ | construct invalidity |
| Operational rule | positive دقیقاً با چه Evidence تعریف میشود؟ | ambiguity |
| Source | Label از کدام system/human/process میآید؟ | source bias |
| Horizon | تا چه زمانی outcome را صبر میکنیم؟ | censoring |
| Adjudication | اختلاف Annotator چگونه حل میشود؟ | hidden disagreement |
| Unknown | unresolved را negative میکنیم؟ | silent mislabel |
| Version | Rule در طول زمان تغییر کرده؟ | label drift |
| Leakage | Label یا proxy بعد از prediction time وارد Feature شده؟ | optimistic result |
NIST در بحث Validation روی Construct validity تأکید میکند: Proxyهایی مثل «hireability» یا صفات پیچیده لزوماً همان مفهومی را که نام میبرند اندازه نمیگیرند. توافق Annotator نیز بهتنهایی حقیقت را ثابت نمیکند؛ disagreement، uncertainty و unresolved cases را نگه دارید.
Split Strategy بر اساس ساختار Dependency
| Split | مناسب برای | Failure پنهان |
|---|---|---|
| Random row | IID-like rows با dependency کم | همان Subject در Train/Test |
| Stratified | حفظ نسبت Class | group/time leakage را حل نمیکند |
| Group | User/Device/Order/Site clusters | تعمیم زمانی را ثابت نمیکند |
| Temporal | پیشبینی آینده | season/site shift جدا میماند |
| Geographic/Site | تعمیم به location جدید | داخل همان site temporal leak |
| Nested CV | selection + performance estimation | locked external test را جایگزین نمیکند |
| Challenge set | Failure mode هدفمند | Population estimate نیست |
Split تصادفی Default بیخطر نیست. اگر آینده را پیشبینی میکنید، Train باید از نظر زمانی پیش از Validation/Test باشد؛ اگر چند رکورد از یک موجودیت دارید، Group باید یکجا بماند. Test set برای سؤال تعمیم طراحی میشود، نه فقط برای رسیدن به نسبت ۸۰/۲۰.
Data Leakage؛ نشت فقط تکرار ردیف نیست
راهنمای رسمی scikit-learn دربارهٔ Data Leakage توضیح میدهد که اطلاعات Test نباید برای ساخت مدل یا preprocessing استفاده شود و Split باید پیش از fit کردن Transformer انجام شود. Pipeline میتواند اجرای صحیح fit/transform را آسانتر کند، اما Leakage معنایی، زمانی، گروهی یا ناشی از انتخاب feature/threshold را خودکار حل نمیکند.
| نوع Leakage | نمونه | کنترل |
|---|---|---|
| Direct target | Label یا derivative در Feature | feature provenance/audit |
| Post-outcome | فیلدی که بعد از prediction time ساخته میشود | as-of dataset |
| Preprocessing | Scaler/Imputer روی کل داده fit | fit فقط در Train fold |
| Group | یک Order/User در دو Split | group-aware split |
| Duplicate/near-duplicate | همان متن/تصویر با تغییر کوچک | content identity/dedup |
| Temporal | Feature آینده یا revised history | point-in-time reconstruction |
| Selection | بارها انتخاب Candidate با Test | Validation vs locked test |
| Human | Annotator Test نتیجهٔ Model را میبیند | blinding/adjudication design |
leakage_audit: prediction_time: fixed label_available_at: timestamp/source feature_available_at: timestamp/source per feature train/validation/test entity overlap: measured exact/near-duplicate policy: versioned preprocessing_fit_scope: train folds only feature_selection/tuning_scope: training/validation only test_accesses: logged point_in_time_rebuild: evidenced verdict: PASS / FAIL / UNKNOWN
Train، Validation، Test و Challenge Set را جدا کنید
| Dataset | مصرف مجاز | مصرف نامعتبر |
|---|---|---|
| Train | fit parameters/representation | گزارش unbiased نهایی |
| Validation | hyperparameter/model/threshold selection | confirmation مستقل پس از انتخابهای زیاد |
| Locked test | یک پروتکل confirmation ازپیشثبتشده | iterate until pass |
| Challenge set | Failure mode و Counterexample | برآورد شیوع در Population |
| Production field data | context/monitoring/impact با مجوز | برچسبزدن خودکار و retrain بیبررسی |
هر بار که بر اساس نتیجهٔ Test مدل، Feature یا Threshold را تغییر میدهید، Test عملاً بخشی از Selection میشود. راهحل همیشه «یک Test دیگر» نیست؛ Budget دسترسی، audit log، Holdout خارجی یا دورهای، Nested design و گزارش صادقانهٔ adaptivity را متناسب با ریسک انتخاب کنید.
Metric از Error Cost و Action میآید
| Metric | میپرسد | Blind spot |
|---|---|---|
| Accuracy | چند پیشبینی label برابر دارد؟ | Class imbalance/error cost |
| Precision | از Positiveهای اعلامی چند درستاند؟ | Missed positive |
| Recall/Sensitivity | از Positiveها چند پیدا شدند؟ | False-positive workload |
| Specificity | از Negativeها چند درست رد شدند؟ | Missed positive |
| F1 | میانگین هارمونیک P/R | TN، calibration و cost |
| ROC-AUC | ranking across thresholds | operating point/prevalence/action |
| PR-AUC | precision-recall tradeoff | یک Threshold عملی را انتخاب نمیکند |
| Log loss/Brier | کیفیت score احتمالی | use-specific decision cost |
| MAE/quantile loss | regression error | tail/slice/domain cost |
| Recall@K | با ظرفیت K چند مورد مثبت میآید؟ | quality beyond K/queue dynamics |
مستندات Model Evaluation در scikit-learn مجموعهای از Metricها و شیوههای averaging ارائه میدهد؛ وجود API به معنی مناسببودن Metric برای Domain شما نیست. Positive class، label order، averaging (micro/macro/weighted)، sample weight، zero-division و واحد Report باید ثبت شوند.
Confusion Matrix را با Support منتشر کنید
evaluation_cell: population/slice: timeout_after_commit threshold: 0.50 support: N positive_support: P negative_support: N-P TP / FP / TN / FN: counts precision / recall / specificity: values + undefined policy interval/uncertainty: declared method exclusions/unknown labels: counts consequence: human-review routing impact
در Slice کوچک، ۱۰۰٪ میتواند حاصل یک نمونه باشد. Percent بدون numerator/denominator، Support و missing/unknown فریبنده است. اگر denominator صفر است، Metric را صفرسازی خام نکنید؛ `undefined`/`NA` و علت آن را در Gate لحاظ کنید.
Threshold بخشی از Model decision است
Classifier score بدون Threshold Action نمیسازد. Threshold میتواند بر اساس capacity، هزینهٔ FP/FN، risk tolerance و fallback تعیین شود. آن را روی Locked test optimize نکنید و بعد همان Test را «تأیید مستقل» ننامید. اگر شرایط یا prevalence تغییر کرد، operating point ممکن است نیاز به بازبینی داشته باشد.
| Threshold کمتر | Threshold بیشتر | پرسش تصمیم |
|---|---|---|
| معمولاً Recall بالاتر | معمولاً Precision بالاتر | کدام خطا پرهزینهتر است؟ |
| Review workload بیشتر | Miss بیشتر | ظرفیت واقعی چند مورد است؟ |
| False alarm بیشتر | Automation silence بیشتر | fallback/appeal چیست؟ |
| ممکن است Sliceها متفاوت تغییر کنند | ممکن است Sliceها متفاوت تغییر کنند | Gate slice-specific لازم است؟ |
Calibration با Discrimination فرق دارد
مدل ممکن است Ranking خوبی داشته باشد ولی Score ۰.۸ واقعاً با نرخ رخداد حدود ۸۰٪ متناظر نباشد. راهنمای Calibration در scikit-learn Reliability diagram و proper scoring ruleهایی مانند Log loss/Brier را توضیح میدهد. Calibration را روی دادهٔ جدا یا روش درست fit کنید؛ calibrator نیز یک مدل است و میتواند overfit یا drift کند.
| Claim | Test | محدودیت |
|---|---|---|
| Ranking | AUC/PR curve | احتمال معتبر نیست |
| Operating point | P/R/confusion at threshold | فقط همان condition |
| Probability quality | calibration curve/Brier/log loss | binning/sample/prevalence |
| Decision utility | cost/capacity analysis | cost assumptions contextual |
عدمقطعیت و Variation را گزارش کنید
- Sampling uncertainty: Test sample محدود است.
- Label uncertainty: Ground truth ناقص/متأخر/مورد اختلاف است.
- Training variation: Seed، initialization و data order میتوانند Artifact را تغییر دهند.
- Measurement variation: preprocessing/library/hardware/numerical settings اثر دارند.
- Distribution uncertainty: Deployment با Test population دقیقاً یکسان نیست.
- Threshold uncertainty: هزینه/ظرفیت و prevalence ممکن است تغییر کند.
Interval را با روشی متناسب با Unit/Dependency بسازید؛ bootstrap ردیفمحور برای دادهٔ clustered همیشه مناسب نیست. چند Seed میتواند sensitivity به stochastic training را نشان دهد، اما انتخاب «بهترین Seed» و گزارش تنها آن، uncertainty را پنهان میکند. تعداد Run، aggregation و selection rule را از پیش مشخص کنید.
Baseline و Comparator را جدی بگیرید
| Comparator | سؤال | هشدار |
|---|---|---|
| Constant/majority | آیا Model از حد ساده بهتر است؟ | Metric نامناسب میتواند گمراه کند |
| Rule-based | پیچیدگی ML ارزش افزوده دارد؟ | Rule نیز version لازم دارد |
| Prior approved model | Regression/Tradeoff چیست؟ | قدیمی بودن مساوی حقیقت نیست |
| Human workflow | کمک/آسیب در Task چیست؟ | human study/ethics/learning effects |
| Oracle upper/lower bound | حد تفسیر چیست؟ | ممکن است دستنیافتنی/biased باشد |
Slice Testing؛ Aggregate میتواند Failure را پنهان کند
Slice را بر اساس Failure mode، Operating condition، Product/version، geography، time، input quality و stakeholder harm از پیش تعریف کنید. Sliceهای مربوط به صفات انسانی/حساس نیازمند مبنای مشروع، privacy، governance، متخصص Domain و مشارکت ذینفعاناند؛ صرفاً شکستن داده بر اساس demographic و بهینهسازی یک parity metric «عدالت» را تضمین نمیکند.
slice_contract: slice_id / rationale / owner definition_version / query_hash relation_to_intended_use_or_failure_mode support / positive_support / unknown_count metric / threshold / interval method minimum_evidence rule privacy/ethical authorization if sensitive verdict: PASS / FAIL / INCONCLUSIVE action: hold / collect evidence / mitigate / restrict use
آزمایش قطعی: Accuracy ۹۰٪ و Failure حیاتی
یک Fixture مستقل Node.js ۲۴.۱۸.۰ با ۲۰ نمونه و Scoreهای کاملاً ساختگی ساختیم. Intended Use فقط اولویتدهی پروندههای پرداخت فرضی برای بازبینی انسانی بود. Threshold=۰.۵۰ و دو Gate پیش از همین ارزیابی قفل شدند. Candidate چهار True Positive، چهارده True Negative، صفر False Positive و دو False Negative تولید کرد.
LOCKED FIXTURE RESULT support=20; positiveSupport=6 TP=4; TN=14; FP=0; FN=2 accuracy=0.90 recall=0.667 precision=1.00 critical slice: timeout_after_commit support=2; positiveSupport=2 recall=0.00; missed=T19,T20 NAIVE GATE: accuracy >= 0.90 → PASS CLAIM GATE: accuracy >= 0.85 AND recall >= 0.75 AND critical-slice recall >= 0.80 → HOLD
هر دو Verdict از همان Prediction ثابت آمدهاند؛ تفاوت در Claim است، نه دستکاری مدل. بااینحال این Fixture عمداً کوچک و هماهنگ با Demonstration است و هیچ Population را نمایندگی نمیکند. هیچ Model train/inference یا interval محاسبه نشده؛ تمام نمونهها، Labelها، Scoreها، Slice، Threshold و Gate ساختهٔ نویسندهاند. هیچ شخص، ویژگی محافظتشده، Fairness، Outcome کاربر، پرداخت یا تصمیم Production ارزیابی نشده و Calibration، Robustness، Drift، Leakage، Causality، Security، latency، کیفیت Human review یا ارزش کسبوکار پوشش ندارد. نتیجه Benchmark، Threshold جهانی، Release algorithm، ارزیابی مقرراتی یا اثبات کفایت Slice metric نیست.
Metamorphic Testing؛ وقتی Expected label کافی نیست
| Relation | مثال | احتیاط |
|---|---|---|
| Invariance | تغییر Format بیمعنا خروجی را تغییر ندهد | واقعاً معنای Domain ثابت باشد |
| Equivariance | تغییر ورودی، خروجی را طبق Rule تغییر دهد | relation باید اثبات/تأیید شود |
| Monotonicity | Feature با فرض ceteris paribus جهت مشخص | interaction/causality را ساده نکنید |
| Permutation | ترتیب مجموعهٔ unordered بیاثر باشد | Sequence task مستثناست |
| Round-trip | encode/decode feature حفظ شود | lossy transform ممکن است مجاز باشد |
| Duplicate | تکرار مورد نباید score فرد را تغییر دهد | batch normalization/context effects |
metamorphic_test: relation_id: MR-UNICODE-01 source_cases: versioned transformation: normalize equivalent Persian text form precondition: meaning independently judged equivalent expected_relation: class unchanged; score delta within declared bound exceptions: listed comparator/tolerance: versioned counterexample evidence: original + transformed + model digest
Robustness با Adversarial Security یکی نیست
| آزمون | سؤال | مرز |
|---|---|---|
| Natural corruption | noise/missing/blur/typo رایج چه اثری دارد؟ | distribution واقعی لازم است |
| Boundary/OOD | خارج از operating envelope چه میشود؟ | OOD detector کامل نیست |
| Stress/challenge | known failure mode چگونه رخ میدهد؟ | prevalence estimate نیست |
| Adversarial example | مهاجم با knowledge/budget معین چه میکند؟ | authorization/threat model لازم است |
| Poisoning/backdoor | training/supply chain دستکاری شده؟ | AppSec/Data governance مالکیت مشترک |
| Extraction/inversion | Model/data افشا میشود؟ | privacy/security تخصصی |
یک نویز تصادفی را «تست متخاصمانه جامع» ننامید. Threat actor، Knowledge، Access، Query budget، Constraint، Success criterion و مجوز باید تعریف شوند. High-stakes safety/security به Domain expert، red team مجاز و کنترلهای مستقل نیاز دارد؛ Model metric جای safety case یا security assessment را نمیگیرد.
Determinism و Reproducibility را تفکیک کنید
ML inference لزوماً «ذاتاً غیرقطعی» نیست. یک Artifact ثابت با preprocessing و runtime ثابت میتواند خروجی تکرارپذیر داشته باشد؛ stochastic sampling، dropout فعال، hardware/kernel، parallel reduction، nondeterministic operator یا unpinned dependency ممکن است Variation بسازد. رفتار probabilistic Model نیز با nondeterministic execution یکی نیست.
| ویژگی | پرسش | Test |
|---|---|---|
| Repeatability | همان setup/run چه میدهد؟ | repeated inference/training |
| Reproducibility | setup مستقلِ مستند چه میدهد؟ | rebuild from manifests |
| Determinism | input/state یکسان output یکسان؟ | byte/semantic comparison |
| Stability | perturbation مجاز چه variation دارد؟ | sensitivity distribution |
| Replicability of conclusion | نتیجهٔ Claim با sample/run دیگر میماند؟ | external/temporal replication |
reproducibility_record: model_artifact_digest training/eval data manifests feature/label/split/protocol versions source code commit + dirty state config + seed(s) + dependency lock container/runtime/hardware/driver deterministic flags/known nondeterminism command + environment variables without secrets output metrics/predictions/errors digest acceptable semantic tolerance + rationale
Train–Serve Skew و Artifact Contract
Model evaluation فقط وقتی به Serving مربوط است که Feature name/type/default/unit/order/normalization، vocabulary، missing policy، threshold و postprocessing همان Contract را اجرا کنند. Candidate را از raw request تا serving response در برابر offline evaluator مقایسه کنید و Model digest را در Response/Trace قابلردیابی نگه دارید؛ اختلاف مجاز عددی باید از پیش تعریف شود.
| مرز | Failure | Evidence |
|---|---|---|
| Raw→Feature | timezone/unit/category mismatch | feature vector diff |
| Feature→Model | column order/type/default | schema/model signature |
| Score→Decision | threshold/postprocess mismatch | decision trace |
| Artifact loading | wrong/stale model version | digest/registry/deployment ID |
| Batch vs online | different library/logic | golden request-response corpus |
Drift یک Signal است، نه Verdict
| Signal | توضیح | اقدام نامعتبر خودکار |
|---|---|---|
| Data/covariate shift | P(X) تغییر کرده | فرض افت عملکرد بدون Label |
| Prior shift | P(Y) تغییر کرده | retrain فوری بدون علت |
| Concept shift | P(Y|X) تغییر کرده | تشخیص صرفاً از Feature histogram |
| Label shift/delay | Outcome mix/availability تغییر کرده | negative کردن unresolved |
| Performance change | Metric با Label بالغ تغییر کرده | نسبتدادن قطعی به Model |
| Operational shift | latency/error/fallback/context تغییر کرده | حل با retraining تنها |
Drift detector میتواند Investigation را شروع کند: مشکل upstream، seasonality، policy، product mix، attack، label pipeline یا مدل؟ Retraining یک تغییر پرریسک تازه است و باید Data/Label/Split/Protocol/Comparison/Gate جدید داشته باشد. Drift metric یا A/B بهتنهایی علت، harm یا بهترشدن را ثابت نمیکند.
Shadow و A/B خارج از Model-only Evaluation
Shadow میتواند Candidate را روی traffic واقعی بدون اثر مستقیم اجرا کند، اما Label delay، selection bias، privacy، logging و resource contention باقیاند. A/B یک Experiment روی انسان/سیستم است، نه «بهترین راه» جهانی؛ randomization unit، interference، novelty، sample size/power، stopping rule، guardrail، informed governance، harm containment و rollback لازماند. High-stakes تصمیم را برای یادگیری محصول بیمحافظ روی کاربر واقعی آزمایش نکنید.
Model Release Gate
| Gate | PASS | HOLD/INCONCLUSIVE |
|---|---|---|
| Use/Claim | use/out-of-scope/action/error cost approved | ambiguous construct/owner |
| Dataset/Label | population/split/label version and limits | unknown leakage/horizon |
| Protocol | metric/threshold/slices fixed pre-test | test-driven tuning |
| Aggregate | required metrics/intervals supported | single score/no support |
| Critical slices | predeclared evidence supported | fail or insufficient support |
| Behavior | metamorphic/boundary/robustness claims pass | counterexample unresolved |
| Reproducibility | artifact/data/code/config/environment linked | unversioned dependency |
| Serving contract | offline/online parity within tolerance | feature/threshold skew |
| System dependencies | owners attest required system evidence | model-only proof used as system proof |
Gate باید PASS، FAIL، ERROR و INCONCLUSIVE را جدا کند. نبود Label بالغ یا Support کافی، «Pass با ریسک» نیست؛ ممکن است Evidence ناکافی باشد. Exception باید Claim، affected population، uncertainty، compensating control، owner، monitoring، expiry و re-evaluation داشته باشد. QA یا Data scientist بهتنهایی Business/Risk acceptance را امضا نمیکند.
Model Evaluation Evidence Pack
evaluation_evidence_pack: intended-use + out-of-scope-use contract claims + consequences + owners model card/artifact digest/signature training/validation/locked-test manifests population/sample/unit/label/split documentation leakage and overlap audit baseline/candidate/protocol/threshold/slice versions confusion/support/metrics/calibration/uncertainty counterexamples/metamorphic/robustness results seed/environment/reproducibility record offline-serving parity evidence fairness/XAI/privacy/security/system evidence links limitations/unknowns/exceptions/expiry evaluation verdict + separate release decision
سناریوی ایرانی ساختگی: مدل اولویتدهی پروندهٔ پرداخت
یک Model کاملاً فرضی فقط پروندههای پشتیبانی Marketplace را برای بازبینی انسانی مرتب میکند. نه پرداخت را تأیید/رد میکند، نه فرد را متقلب مینامد و نه دسترسی/قیمت/اعتبار را تغییر میدهد. Dataset مصنوعی شامل Order، PaymentAttempt، Callback از PSP جعلی، Ledger و Reconciliation result است؛ هیچ بانک، PSP، کاربر، فروشنده، پول یا تراکنش واقعی وجود ندارد.
| ریسک/Contract | Fixture | Oracle/Gate |
|---|---|---|
| Identity | tenant/order/attempt/event/model/run | no cross-tenant/group leakage |
| Prediction time | before analyst reconciliation | no future ledger/result feature |
| Money | canonical IRR + explicit displayed toman | no 10× unit leakage |
| Digits/Text | Persian/Arabic/Latin + Unicode/RTL | declared normalization relation |
| Time | UTC event + Asia/Tehran/Jalali view | temporal split/as-of features |
| Critical slice | timeout_after_commit | predeclared recall/support |
| Action | human queue priority | capacity/false-negative guardrail |
| Fallback | ordinary review | no silent automatic denial |
تمام Caseها Synthetic هستند و نام، موبایل، نشانی، PAN، CVV2، OTP، Token، Cookie، IP یا Secret واقعی ندارند. Featureهای مربوط به هویت/صفات حساس ساخته یا استنباط نمیشوند. Artifact/dependencyها با checksum و lockfile Pin میشوند و برای محدودیت دسترسی Cloud/Registry/Package در ایران، Cache/Mirror/Offline restore آزموده میشود. این سناریو مشاورهٔ بانکی، مالی، حقوقی، حریم خصوصی، تبعیض یا تحریم نیست.
Privacy، Security و Human Review
- Evaluation data باید Purpose، lawful/authorized use، minimization، access و retention مستقل داشته باشد.
- Test/Challenge set و Model artifact میتوانند دارایی حساس یا attack target باشند.
- Prompt/Notebook/Log/Artifact نباید Secret یا دادهٔ شخصی را نشت دهد.
- Human review «حفاظ کامل» نیست؛ training، workload، UI، authority، automation bias و appeal باید آزموده شوند.
- Reviewer label میتواند تحت تأثیر Model score آلوده شود؛ blinding/ordering را در Protocol بسنجید.
- حذف/اصلاح داده باید اثرش بر Dataset lineage، Artifact و Evidence روشن باشد.
نقشها و جدایی تصمیمها
| نقش | مسئولیت | تصمیم |
|---|---|---|
| Domain/Product owner | use/action/error consequence/capacity | intended use and release value |
| Data owner | population/source/quality/access | dataset readiness |
| Label owner/domain expert | construct/rule/horizon/adjudication | label validity limits |
| ML engineer/scientist | training/artifact/method/limitations | technical remediation |
| Evaluation/QA | protocol/oracle/leakage/tests/evidence | evaluation verdict |
| Risk/Ethics/Privacy/Security | specialized claims/authorization | domain-specific acceptance |
| Release decision owner | tradeoff/exception/fallback | deploy/restrict/hold/retire |
| Independent reviewer | challenge evidence/conflict reduction | review opinion، نه automatic veto unless chartered |
متریکهای فرایند ارزیابی و Countermetric
| Metric | تعریف | Countermetric |
|---|---|---|
| Claim evidence completeness | required evidence present/current | quality/validity of evidence |
| Test access count | selection exposure to locked test | legitimate confirmation need |
| Unknown/insufficient slices | predeclared slices without evidence | privacy/minimum-size constraints |
| Leakage defect | confirmed lineage/split violations | audit coverage |
| Counterexample resolution | fixed/restricted/accepted with expiry | severity/recurrence |
| Reproducibility variance | semantic result across declared runs | expected stochasticity |
| Offline-serving skew | feature/score/decision mismatch | allowed numeric tolerance |
| Exception age | days past review/expiry | risk and containment |
Accuracy، AUC، تعداد Experiment و سرعت Train را برای رتبهبندی فردی Data scientist/QA به کار نبرید. بهینهسازی پاداش روی یک Metric، leakage، test-set overfitting و پنهانکردن Slice/Unknown را تشویق میکند. ارزیابی باید دربارهٔ Claim و System learning باشد، نه مسابقهٔ Leaderboard داخلی.
برنامهٔ ۳۰روزهٔ Model Evaluation Pilot
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | یک use/action/error-cost و یک Candidate انتخاب کنید | Use + Claim Contract |
| روز ۶–۱۰ | Population/label/split/leakage map | Dataset protocol |
| روز ۱۱–۱۵ | Baseline/metric/threshold/slice/gates پیشثبت شوند | locked evaluation plan |
| روز ۱۶–۲۰ | aggregate/slice/calibration/uncertainty اجرا شود | measurement report |
| روز ۲۱–۲۵ | metamorphic/boundary/robustness/reproducibility | counterexamples + limits |
| روز ۲۶–۳۰ | offline-serving parity، Evidence Pack و review | verdict + separate release decision |
ضدالگوهای رایج تست مدل ML
- یکیگرفتن Model با AI system.
- Accuracy-only Gate.
- انتخاب Metric بدون Action/Error cost.
- Random split بدون Group/Time analysis.
- fit کردن preprocessing پیش از Split.
- استفاده از Feature بعد از prediction time.
- تبدیل unknown Label به negative.
- تکرار انتخاب Candidate روی Test نهایی.
- گزارش Percent بدون Support و interval.
- Macro/weighted/micro بدون اعلام.
- Threshold optimization روی Test.
- یکیگرفتن AUC با operating performance.
- یکیگرفتن score با probability calibrated.
- گزارش بهترین Seed.
- Slice mining پس از مشاهدهٔ Failure و ادعای confirmation.
- Parity metric بهعنوان تضمین Fairness.
- Feature importance بهعنوان علیت.
- نویز ساده بهعنوان Adversarial assessment.
- Drift alert بهعنوان دستور Retrain.
- A/B روی کاربر واقعی بهعنوان راه پیشفرض.
چکلیست Release مدل
- ☐ Intended Use، Action، Actor و Out-of-scope ثبت شدهاند.
- ☐ Consequence و fallback هر خطای مهم روشن است.
- ☐ Population، Sampling frame، Unit و horizon نسخه دارند.
- ☐ Construct/Label/Adjudication/Unknown policy مستند است.
- ☐ Split متناسب با Time/Group/Site/Dependency است.
- ☐ Leakage زمانی، گروهی، preprocessing و selection audit شده است.
- ☐ Train/Validation/Locked test/Challenge set جدا هستند.
- ☐ Baseline، Metric، averaging و Threshold پیشثبت شدهاند.
- ☐ Confusion count، Support و undefined policy گزارش میشود.
- ☐ Calibration و uncertainty متناسب با Claim بررسی شدهاند.
- ☐ Sliceهای پرریسک پیش از Test تعریف شدهاند.
- ☐ Metamorphic relation و precondition تأیید شدهاند.
- ☐ Robustness/Adversarial scope و authorization روشن است.
- ☐ Artifact/Data/Code/Config/Seed/Environment هویت دارند.
- ☐ Variation و known nondeterminism ثبت شدهاند.
- ☐ Offline/Serving feature-score-decision parity آزموده شده است.
- ☐ Fairness/XAI/Privacy/Security/System evidence جداست.
- ☐ PASS/FAIL/ERROR/INCONCLUSIVE تفکیک دارند.
- ☐ Exception owner/monitor/expiry/retest دارد.
- ☐ Evaluation verdict از Release decision جداست.
جمعبندی
تست مدل یادگیری ماشین یک مسابقهٔ Metric نیست؛ قرارداد شواهد برای Intended Use است. Model artifact، Dataset و Split قفلشده، Label معتبر، نبود Leakage شناختهشده، operating threshold، Support/uncertainty، Slice و رفتار تحت تحول، Reproducibility و Serving parity کنار هم Verdict میسازند. حتی آن Verdict نیز فقط شرایط آزمودهشده را پشتیبانی میکند و جای قضاوت Domain، ارزیابی کل سیستم یا پاسخگویی به افراد متأثر را نمیگیرد.
پرسشهای متداول تست مدل یادگیری ماشین
۱. تفاوت Model Evaluation و تست مدل چیست؟
Evaluation معمولاً Measurement روی Dataset و Metric مشخص است. Testing علاوه بر آن Claim را با Leakage audit، Boundary، Slice، Metamorphic relation، Robustness، Reproducibility و Serving parity به چالش میکشد؛ Validation نیز تناسب با Intended Use و Context را میپرسد.
۲. آیا Accuracy بالا برای انتشار مدل کافی است؟
خیر. Accuracy هزینهٔ متفاوت FP/FN، Class imbalance، Threshold، Calibration، Support، uncertainty و Failure در Slice حیاتی را پنهان میکند. Metric/Gate باید از Action و Risk بیاید و با Confusion counts و Slice evidence همراه شود.
۳. بهترین روش تقسیم Train و Test چیست؟
یک روش جهانی وجود ندارد. Split باید سؤال تعمیم را بازتاب دهد: Temporal برای آینده، Group برای موجودیتهای تکراری، Site/geography برای مکان جدید و روشهای ترکیبی برای Dependencyهای چندگانه. Random stratified فقط نسبت Class را حفظ میکند و Leakage زمانی/گروهی را حل نمیکند.
۴. آیا Drift یعنی باید مدل را فوراً Retrain کنیم؟
نه. Drift یک Signal برای Investigation است و میتواند از upstream، فصل، محصول، policy، attack، Label یا Context بیاید. Retraining خودش تغییر جدیدی است که Dataset، Label، Split، Evaluation، comparison و Release Gate تازه میخواهد.
۵. تیم کوچک ارزیابی مدل را از کجا شروع کند؟
یک Intended Use باریک انتخاب کند؛ Use/Claim/Label/Split را بنویسد، یک Baseline و Metric/Threshold را پیش از Test قفل کند، overlap/leakage را بسنجد، Confusion/Support و یک Slice پرریسک را گزارش دهد و Artifact/Data/Code/Protocol را در Evidence Pack پیوند بزند.
