टेस्टर्स के लिए मशीन लर्निंग बेसिक्स

यह क्यों ज़रूरी है

ML के कई defects code में दिखते ही नहीं। Model गलत label वाले या unrepresentative data से सीख सकता है, पहले देखे हुए data पर evaluate हो सकता है, या ऐसे metric से आँका जा सकता है जो ज़रूरी errors छिपा दे। तब evaluation report शानदार दिखती है, जबकि असली users को छूटा हुआ fraud, बेवजह block हुए customers, या बाकियों से कहीं बुरी service पाने वाला कोई group मिलता है।

इन basics से tester evaluation का number चुपचाप मानने की बजाय उस पर सवाल उठा सकता है: test data कहाँ से आया, क्या वह training data से overlap करता है, कौन-से errors महँगे हैं, और users के हर group के लिए model कैसा perform करता है?

Learning के तीन प्रकार, एक workflow

ML का काम एक workflow में चलता है, जिसे ISTQB AI Testing (CT-AI) syllabus ज़्यादा बारीक steps में बताता है: objective और acceptance criteria तय करना, data इकट्ठा और label करना, उसे prepare और split करना, model train करना, validation data पर evaluate और tune करना, final model को test data पर एक बार test करना, फिर deploy, monitor और data बदलने पर retrain करना। हर step tester को review के लिए कुछ देता है: objective एक test basis है, dataset एक work product, और evaluation एक test result।

Learning के प्रकार इस बात में अलग हैं कि model किससे सीखता है, और यही तय करता है कि test उसके output की तुलना किससे कर सकता है:

• Supervised learning: model labelled examples से सीखता है, यानी ऐसे inputs जिनके साथ सही जवाब (label) जुड़ा हो। Classification एक category predict करता है (fraud या legitimate), ML regression एक number (delivery time); इस statistical regression का regression testing से कोई संबंध नहीं। Labelled test data ही test oracle का काम करता है। इस lesson के metrics classification के लिए हैं; regression model को उसके errors के आकार से आँका जाता है, जैसे prediction असली delivery time से कितने मिनट दूर है।
• Unsupervised learning: labels नहीं होते; model structure ढूँढता है, जैसे मिलते-जुलते customers के clusters या असामान्य transactions। Answer key न होने से evaluation samples के expert review, stability checks या बाद में किसी sample को label करने पर टिका होता है।
• Reinforcement learning: एक agent किसी environment में actions लेकर और rewards या penalties पाकर सीखता है, जैसे warehouse में रास्ते सीखता robot। Tests जाँचते हैं कि reward चाहे गए behaviour को ही बताता है, क्योंकि agent उसे कमाने के अनचाहे तरीके ढूँढ सकता है, और training में कभी न मिली स्थितियों में agent कैसा व्यवहार करता है।

Training, validation और test sets

Labelled data तीन sets में बाँटा जाता है। Model training set से सीखता है। Validation set development के दौरान models की तुलना करने, settings tune करने और threshold चुनने में इस्तेमाल होता है। Test set (hold-out set) अलग रखा जाता है और सारे फ़ैसलों के बाद सिर्फ़ एक बार इस्तेमाल होता है, ताकि अनदेखे data पर performance का अनुमान लगे। कुछ teams "validation" और "test" नाम उलट देती हैं, इसलिए पूछें कि reported number किस set से आया।

अलग sets इसलिए ज़रूरी हैं क्योंकि model अपने training data पर ज़रूरत से ज़्यादा fit हो सकता है। Overfitting का मतलब है कि model ने अपने sample का noise और संयोग भी सीख लिया, जैसे कि कुछ merchant IDs संयोग से fraud cases में आ गए थे: तब training data पर score ऊँचा और validation data पर साफ़ तौर पर कम आता है। Underfitting इसका उल्टा है: model बहुत सरल है या उसके inputs में बहुत कम जानकारी है, और वह दोनों पर कमज़ोर रहता है।

Test score तभी ईमानदार है जब test data ने न training पर असर डाला हो, न development के किसी फ़ैसले पर। वरना यह data leakage है, और score users को मिलने वाले नतीजे से ज़्यादा दिखाता है। इसके आम रूप:

• Sets के बीच duplicates और near-duplicates: वही email दो बार forward हुआ, वही photo अलग size में।
• दोनों तरफ़ एक ही customer, जिससे model fraud सीखने की बजाय customer को पहचानने लगता है।
• Time-ordered data का random split, जो model को भविष्य से सीखने देता है; पुराने records पर train करें, नए records पर test।
• ऐसा feature (input field जिससे model सीखता है) जिसमें जवाब छिपा हो, जैसे chargeback date जो fraud confirm होने के बाद ही भरी जाती है।
• Test set की मदद से लिए गए फ़ैसले: split से पहले सभी records पर की गई preparation, जैसे missing values को सभी records के average से भरना, या test score अच्छा दिखने तक tuning।

Representative, साफ़ और सही label वाला data

Model अपने data में मौजूद हर चीज़ सीखता है, इसलिए data review करना requirements review जैसी test activity है। पहले पूछें: क्या data operating environment, यानी production में model को मिलने वाले हालात, को represent करता है? एक region, device type, season या भाषा का data, या किसी product बदलाव से पहले का data, users के भेजे data से अलग हो सकता है: यह distribution shift है। Release के बाद यह data drift के रूप में चलता है, जब inputs बदलते हैं (नया payment method), और concept drift के रूप में, जब inputs और सही जवाब का रिश्ता बदलता है (fraudsters अपने तरीके बदलते हैं)। पूछें कि test sample कैसे और कब लिया गया, उसे production data से मिलाएँ, और पक्का करें कि release के बाद model की monitoring होगी।

फिर records का एक random sample ख़ुद पढ़ें, सिर्फ़ summary statistics नहीं, और तीन तरह के defects ढूँढें:

• Data quality: missing values, duplicates, गलत units या formats, range से बाहर की values, और एक ही column में "KSA", "Saudi Arabia" और "SA" जैसी inconsistent categories। CSV sample को CSV to JSON से type inference चालू रखकर convert करें, ताकि numbers, numbers ही रहें, फिर result को API Response Analyzer में paste करें: वह empty और null fields, records के बीच type बदलने वाले fields और duplicate records दिखाता है।
• Labelling errors: गलत labels, आपस में असहमत labellers, अस्पष्ट guidelines। Training में गलत label गलत behaviour सिखाता है; test में गलत label metric को ही गलत कर देता है। पूछें कि असहमतियाँ कैसे सुलझाई गईं, और एक sample दोबारा जाँचें।
• Data bias: कम represent हुए groups (review classifier में Arabic भाषा के कम reviews) या पुराने इंसानी फ़ैसले दोहराते labels (पुराने loan approvals)। तब model उन groups के लिए बुरा या अनुचित काम करता है; एक आगे का lesson bias को गहराई से कवर करता है।

आज़माएँ: CSV से JSON आज़माएँ: API रिस्पॉन्स एनालाइज़र

Confusion matrix और उसके metrics

Classifier evaluate करने के लिए held-out data पर हर prediction की तुलना उसके label से करें। दो classes हों तो जिस class को आप ढूँढते हैं वह positive (fraud) और दूसरी negative (legitimate) कहलाती है। तब हर prediction true positive (TP, fraud flag हुआ), false negative (FN, fraud छूट गया), false positive (FP, legitimate payment flag हुआ) या true negative (TN, legitimate payment पास हुआ) होता है। इन चार counts की table confusion matrix है।

Accuracy सभी predictions में सही predictions का हिस्सा है। Precision flag हुए cases में सचमुच positive cases का हिस्सा है: model alarm देता है तो कितनी बार सही होता है? Recall असली positives में से पकड़े गए cases का हिस्सा है: problem का कितना हिस्सा वह ढूँढ पाता है? F1, दोनों का harmonic mean, तभी ऊँचा होता है जब दोनों ऊँचे हों।

Accuracy में एक जाल है। जब एक class दुर्लभ हो, तो हमेशा "legitimate" कहने वाला model कुछ भी पकड़े बिना ऊँची accuracy पाता है। नीचे 95% payments legitimate हैं, इसलिए वह बेकार model 95% पाता है, और असली model की 96.5% उससे सिर्फ़ 1.5 percentage points बेहतर है। Imbalanced data पर class balance, confusion matrix और तुलना के लिए एक baseline माँगें।

Validation set: 2,000 card payments, 100 of them fraud (5%). Threshold 0.5.

                            Predicted: fraud   Predicted: legitimate
Actual: fraud (100)              TP = 60             FN = 40
Actual: legitimate (1,900)       FP = 30             TN = 1,870

Accuracy  = (TP + TN) / all     = 1,930 / 2,000 = 96.5%
Precision = TP / (TP + FP)      =    60 / 90    = 66.7%
Recall    = TP / (TP + FN)      =    60 / 100   = 60.0%
F1        = 2 x P x R / (P + R)                 = 63.2%

Baseline that always answers "legitimate": accuracy 95.0%, recall 0.0%

आज़माएँ: प्रतिशत कैलकुलेटर

Worked example: cost से threshold चुनें, हर segment जाँचें

Fraud model हर payment को 0 से 1 तक score देता है और score threshold के बराबर या ऊपर होने पर उसे flag करता है। Threshold घटाने से ज़्यादा payments flag होते हैं: recall बढ़ता है या वैसा ही रहता है, और precision आम तौर पर घटता है। सही threshold हर error type की cost पर आधारित business फ़ैसला है। यहाँ product owner का अनुमान है कि छूटा हुआ fraud औसतन 400 SAR का पड़ता है और false alarm review के समय और customer की परेशानी में 25 SAR का।

0.3 पर model 0.5 की तुलना में चार गुना false alarms देता है, फिर भी errors की cost 16,750 से घटकर 9,000 SAR रह जाती है, इसलिए इन costs पर 0.3 बेहतर है, बशर्ते review team हर 2,000 में 90 की जगह 205 flagged payments सँभाल सके। अगर false alarm payment को सीधे block कर देता, तो उसकी cost बढ़ती और जवाब बदल सकता था। Costs और तर्क दर्ज करें, फिर चुने गए threshold को test set पर एक बार मापें।

फिर जिन thresholds की आप तुलना करते हैं, हर एक पर नतीजे को तोड़कर देखें। 0.5 पर कुल recall 60% है, लेकिन 30 दिन से कम पुराने accounts के लिए 40% (25 में से 10 fraud cases), जबकि पुराने accounts के लिए 66.7%: एक number ने सबसे कमज़ोर group छिपा दिया। हर अहम segment, जैसे भाषा, region, device या नए users, के metrics sample size के साथ निकालें: 25 cases छोटा sample है, इसलिए 40% जाँच का संकेत है, सटीक value नहीं।

Validation set: 2,000 payments, 100 fraud. Cost: FN = 400 SAR, FP = 25 SAR.

Threshold  TP  FN   FP     TN  Precision  Recall  Cost of errors (SAR)
0.5        60  40   30  1,870      66.7%   60.0%  40 x 400 +  30 x 25 = 16,750
0.3        85  15  120  1,780      41.5%   85.0%  15 x 400 + 120 x 25 =  9,000

Recall by segment at 0.5   Fraud cases  TP  FN  Recall
Accounts < 30 days old              25  10  15   40.0%
Accounts >= 30 days old             75  50  25   66.7%

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026AI-आधारित सिस्टम की टेस्टिंग पर ISTQB का specialist पाठ्यक्रम, machine learning और generative AI सिस्टम सहित।
• ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsISO/IEC · 2020AI-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।
• AI Risk Management Framework (AI RMF 1.0)NIST · 2023पूरे जीवनचक्र में AI जोखिम प्रबंधन के लिए NIST का स्वैच्छिक फ़्रेमवर्क, Govern, Map, Measure और Manage फ़ंक्शन में व्यवस्थित।