AI सिस्टम की टेस्ट तकनीकें

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

एक बार labelled set पर evaluate किया गया AI feature उन inputs पर फिर भी fail हो सकता है जो उस set में नहीं थे: नई phrasing, कम प्रतिनिधित्व वाले group का नाम, जान-बूझकर बनाया गया input, training के बाद launch हुआ product। Labels महँगे होते हैं, इसलिए ज़्यादातर असली inputs कभी जाँचे नहीं जाते, और नतीजा होता है गलत फ़ैसले, असमान व्यवहार और update के बाद चुपचाप गिरती quality।

ये techniques "कोई expected result नहीं है" को pass या fail verdict वाले test cases में बदल देती हैं। ये उन fundamentals पर बनती हैं जो आपके पास पहले से हैं — oracles, regression testing, monitoring — और उनकी जगह नहीं लेतीं: model के आसपास के system को अब भी अपने functional, security और performance tests चाहिए।

Metamorphic relations: बिना expected output के oracle

Metamorphic testing में आप एक source test case चलाते हैं, उसके input को नियंत्रित तरीके से बदलकर follow-up test case बनाते हैं, और एक metamorphic relation (MR) जाँचते हैं: follow-up output का source output से क्या संबंध होना चाहिए। आपको दोनों में से किसी भी test का सही output जानने की ज़रूरत नहीं।

MRs requirement और domain से निकालें: input के कौन-से बदलाव result नहीं बदलने चाहिए (invariance), और कौन-से उसे किसी तय दिशा में ले जाने चाहिए? AI सिस्टम्स में सबसे ज़्यादा ये relations इस्तेमाल होते हैं:

• Paraphrase: input को उसी अर्थ के साथ दूसरे शब्दों में लिखें; फ़ैसला नहीं बदलना चाहिए। फ़ैसलों की तुलना करें — labels, fields, amounts — शब्दों की नहीं।
• Counterfactual attribute swap: सिर्फ़ वह attribute बदलें जिसका असर नहीं होना चाहिए, जैसे नाम, gender या nationality; output बराबर होना चाहिए। यह safety, bias और robustness testing वाले lesson का counterfactual pair ही है; MR के रूप में लिखने पर यह check किसी भी input पर चलता है, labelled हो या नहीं।
• Order invariance: ऐसा क्रम बदलें जिसका कोई अर्थ नहीं, जैसे message के अंदर शिकायतें या context के रूप में दिए गए documents; set के रूप में तुलना करने पर result वही रहना चाहिए।
• Directional (ISTQB का AI Testing syllabus इसे monotonicity कहता है): कुछ बदलाव result को सिर्फ़ एक ही दिशा में ले जा सकते हैं। "इस बारे में यह मेरा तीसरा message है" जोड़ने से urgency कम नहीं होनी चाहिए।
• Transformation को खुद जाँचें: जो paraphrase कोई तथ्य छोड़ दे, या ऐसे attribute का swap जो सच में मायने रखता है, false violations पैदा करता है। Generated follow-ups, कम से कम उनका एक sample, review करें।

Worked example: support triage model के metamorphic tests

एक online store का model support messages का triage करता है: वह संबंधित categories (refund, delivery, payment, account, other) और एक urgency (low, normal, high) लौटाता है। Requirement कहती है कि urgency समस्या पर और वह कितने समय से चल रही है उस पर निर्भर है, customer कौन है उस पर कभी नहीं। लगभग किसी message का label नहीं है।

Tester 200 हाल के messages को sources के रूप में लेता है, नीचे दिए record के चार MRs निकालता है, और generated follow-ups के एक sample का review एक साथी से करवाता है। Model deterministic नहीं है, इसलिए हर pair तीन बार चलता है और नतीजा हर MR का violation rate होता है।

• S-017 के लिए MR-2 fail हुआ: सिर्फ़ signature - Ahmed से - Priya करने पर urgency low हो गई। अगर दोबारा चलाने पर भी ऐसा हो, तो दोनों inputs, दोनों outputs, टूटा हुआ relation और यह कितनी बार reproduce हुआ, report करें। नया नाम gender और origin दोनों में एक साथ अलग है, इसलिए कारण को सीमित करने के लिए ऐसे pairs जोड़ें जो सिर्फ़ एक signal बदलें, जैसे - Fatima।
• Rates हर MR और हर segment के लिए report करें, जैसे message की भाषा: एक overall rate उस group को छिपा सकता है जिसके साथ model अलग व्यवहार करता है।
• MRs का pass होना correctness साबित नहीं करता: जो model हर message पर other और low दे, वह चारों MRs पूरे करता है। Correctness के लिए एक छोटा labelled set रखें, और बिना label वाले बड़े हिस्से के लिए MRs इस्तेमाल करें।

Model under test: support-triage v3 (output: categories, urgency)

S-017  source
  input:   I was charged twice for order 5521 and the parcel is a week late. - Ahmed
  output:  {payment, delivery}, normal

MR-1   paraphrase: categories and urgency must be equal
  input:   Order 5521 was billed two times, and the parcel is 7 days late. - Ahmed
  output:  {payment, delivery}, normal                                   pass

MR-2   attribute swap, name only: categories and urgency must be equal
  input:   I was charged twice for order 5521 and the parcel is a week late. - Priya
  output:  {payment, delivery}, low                                      FAIL

MR-3   order invariance: same set of categories, same urgency
  input:   The parcel for order 5521 is a week late and I was charged twice. - Ahmed
  output:  {delivery, payment}, normal                                   pass

MR-4   directional: urgency must not be lower than the source
  input:   S-017 + "This is my third message about it."
  output:  {payment, delivery}, high                                     pass

Run: 200 sources x 4 MRs x 3 runs; violation rate per MR, reported by language

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

Versions की तुलना: back-to-back, shadow mode और A/B tests

Back-to-back testing किसी system के दो या ज़्यादा variants को एक ही inputs पर चलाती है और उनके outputs के हर अंतर का analysis करती है। AI सिस्टम्स में ये आम तौर पर current version (A) और candidate (B) होते हैं: नया model, बदला हुआ prompt, या fresh data पर दोबारा train किया गया model। Labelled regression set के साथ हाल के असली inputs लें, और settings एक जैसी रखें।

पहले A को खुद के against चलाएँ: non-deterministic model अपने ही पिछले outputs से असहमत हो सकता है, और सिर्फ़ उस baseline से ज़्यादा के अंतर B के बारे में कुछ बताते हैं। सहमति correctness नहीं है, क्योंकि दोनों versions में एक ही defect हो सकता है, और कोई अंतर अपने-आप regression भी नहीं है: हर अंतर को improvement, regression या neutral change में बाँटें। फिर production दो steps जोड़ता है:

• Shadow mode (ISTQB के AI Testing syllabus में shadow testing): B को live inputs की copy मिलती है और उसके outputs log होते हैं, कभी दिखाए नहीं जाते और उन पर कोई action नहीं होता, जबकि A users को serve करता रहता है। जाँचें कि shadow path का कोई side effect नहीं (न messages भेजे जाएँ, न tools call हों, न records लिखे जाएँ) और उसके logs privacy rules मानते हैं।
• A/B testing: यह पता करने का statistical तरीका कि दो variants में कौन बेहतर perform करता है। Traffic को random तरीके से बाँटा जाता है ताकि users या tickets के एक हिस्से को B मिले, और पहले से तय metric की तुलना होती है, जैसे agents कितनी बार triaged ticket को re-route करते हैं, साथ में complaints जैसे guardrail metrics। Decision rule भी शुरू होने से पहले तय करें: कितना अंतर, कितने tickets पर, काफ़ी माना जाएगा। यह users पर असर मापता है, अलग-अलग outputs की correctness नहीं।
• क्रम बनाए रखें: offline तुलना, shadow mode, छोटे हिस्से पर A/B test, फिर full rollout। हर step users को B के सामने तभी लाता है जब पिछले step ने सबूत दे दिया हो।

आज़माएँ: JSON डिफ़ आज़माएँ: टेक्स्ट डिफ़

जब inputs बदलें: adversarial inputs, poisoning और drift

Robustness testing के सामान्य input variations से अलग, adversarial inputs जान-बूझकर बनाए जाते हैं, अक्सर ऐसे बदलावों के साथ जिन्हें इंसान मुश्किल से देख पाए, ताकि model गलती करे: मिलते-जुलते Unicode अक्षर या invisible characters जो filter से निकल जाएँ, जान-बूझकर की गई spelling गलतियाँ, image models के लिए pixels में बहुत छोटे बदलाव। इन्हें invariance MR की तरह टेस्ट करें: ऐसे inputs से शुरू करें जिन्हें system सही handle करता है, हर crafted बदलाव लागू करें, जाँचें कि फ़ैसला वही रहता है, और जो भी input उसे तोड़े उसे regression set में जोड़ें। LLM applications में ये मुख्यतः prompt injection हैं, जिसे LLM security testing वाली गाइड समझाती है, और jailbreaks, यानी मना की गई request को role-play में लपेटना या कई messages में बाँटना ताकि model उसे मान ले, जैसा safety, bias और robustness testing वाले lesson में था। सिर्फ़ वही systems टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है।

Data poisoning उस data से छेड़छाड़ है जिससे model सीखता है या जिस पर वह निर्भर है — pre-training और fine-tuning data (fine-tuning यानी किसी मौजूदा model को अतिरिक्त examples पर आगे train करना), training में वापस जाने वाला user feedback, और RAG system के retrieve किए documents — ताकि model गलत या biased व्यवहार करे, या उसमें backdoor रह जाए: एक छिपा trigger जो किसी ख़ास input के आने पर ही व्यवहार बदलता है। OWASP Top 10 for LLM Applications 2025 इसे LLM04:2025 Data and Model Poisoning के रूप में सूचीबद्ध करता है। Process टेस्ट करें: data कौन बदल सकता है, क्या हर record का source रखा जाता है, क्या training से पहले changes review होते हैं। हर data update के बाद पिछले model के against back-to-back run अनपेक्षित बदलाव दिखा सकता है, पर backdoor तब तक चुप रहता है जब तक उसका trigger न आए, इसीलिए process checks ज़रूरी हैं। Shared या production model को poison करने की कोशिश कभी न करें।

Drift, जिसे machine learning basics वाले lesson ने समझाया, कल के evaluation को आज के system का वर्णन करने लायक नहीं छोड़ता। Data drift में inputs बदलते हैं; concept drift में input और सही जवाब के बीच का संबंध बदलता है, इसलिए inputs वैसे ही दिख सकते हैं जबकि जवाब गलत होने लगते हैं। ISTQB का AI Testing syllabus input और output distributions की पहले वालों से तुलना को static drift testing कहता है, और outputs की fresh ground truth (जैसे user feedback) से तुलना को dynamic drift testing। इन signals से re-evaluation शुरू होना चाहिए:

• Inputs (data drift): evaluation set की तुलना में भाषाओं का नया mix, पहले न देखे गए product names, missing fields।
• Outputs: हर label के हिस्से में बदलाव, गिरता confidence, ज़्यादा refusals या catch-all जवाब।
• लोग और बदलाव, जहाँ concept drift अक्सर सबसे पहले दिखता है: tickets re-route करते agents, complaints, model या prompt का नया version, provider का ऐसा model update करना जिसका version आपने pin नहीं किया, या policy change, जैसे नया delivery promise जो बदल दे कि urgent किसे माना जाए।
• फिर हाल के inputs के fresh labelled sample के साथ evaluation set दोबारा चलाएँ। Signal दिखाता है कि कुछ बदला है, यह नहीं कि quality गिरी; वह सिर्फ़ evaluation दिखाता है।

आज़माएँ: Unicode डेटासेट जनरेटर

Transparency और explainability के दावों की testing

NIST AI Risk Management Framework तीन characteristics को अलग मानता है: transparency, यानी system और उसके outputs के बारे में कितनी जानकारी उससे interact करने वाले लोगों को उपलब्ध है ("क्या हुआ"); explainability, यानी system जिन mechanisms से काम करता है उनका representation (फ़ैसला "कैसे" हुआ); और interpretability, यानी system के उद्देश्य के संदर्भ में output का अर्थ (फ़ैसला "क्यों" हुआ)। Product में ये दावों के रूप में दिखते हैं, और हर दावा टेस्ट करने लायक requirement है।

• Transparency: जाँचें कि वादा किया गया notice ("आप एक AI assistant से बात कर रहे हैं") हर भाषा और हर channel में दिखता है, और model documentation, जैसे model card, की release records से तुलना करें: model version, training data, known limitations। ISTQB का AI Testing syllabus इस review को एक test activity मानता है।
• Faithfulness: explanation को MRs में बदलें। जिस factor का वह ज़िक्र करता है उसे हटाएँ, तो result या explanation बदलना चाहिए; जिसका ज़िक्र नहीं करता उसे बदलें, तो कुछ नहीं बदलना चाहिए। जो explanation अपना ही कारण हटने के बाद भी वैसा ही रहे, वह फ़ैसले का वर्णन नहीं करता।
• Consistency और समझ: एक ही input एक ही explanation दे, और representative users उसे समझ सकें, जिसे आप usability testing की तरह जाँचते हैं।
• Generated कारण: जब कोई LLM बताता है कि उसने ऐसा जवाब क्यों दिया, इसकी कोई गारंटी नहीं कि वह text दिखाता है कि जवाब कैसे बना। उसे किसी भी दूसरे दावे की तरह टेस्ट करें और कभी सबूत न मानें।

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

संदर्भ

• 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-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।
• OWASP Top 10 for LLM Applications 2025OWASP Gen AI Security Project · 2025LLM एप्लिकेशन के दस सबसे गंभीर सुरक्षा जोखिम (LLM01:2025–LLM10:2025), prompt injection और संवेदनशील जानकारी के खुलासे से शुरू।
• AI Risk Management Framework (AI RMF 1.0)NIST · 2023पूरे जीवनचक्र में AI जोखिम प्रबंधन के लिए NIST का स्वैच्छिक फ़्रेमवर्क, Govern, Map, Measure और Manage फ़ंक्शन में व्यवस्थित।