LLM टेस्टिंग: LLM एप्लिकेशन कैसे टेस्ट करें

Mutqan Soft की QA टीम द्वारा · अपडेट: 6 अक्टूबर 2026 · 14 मिनट पढ़ने का समय

LLM टेस्टिंग वह प्रैक्टिस है जिसमें यह प्रमाण जुटाया जाता है कि large language model पर बना सिस्टम वही करता है जो उसे करना चाहिए, prompt, मॉडल या डेटा बदलने पर भी करता रहता है, और जब यूज़र — या हमलावर — उसे अपेक्षित रास्ते से हटाने की कोशिश करें तो सुरक्षित रूप से फ़ेल होता है। टेस्ट के तहत सिस्टम शायद ही कभी अकेला मॉडल होता है: वह prompt है, retrieval लेयर है, वे टूल हैं जिन्हें मॉडल कॉल कर सकता है, guardrails हैं, यूज़र इंटरफ़ेस है, और हर जवाब पर लगने वाला समय और पैसा है।

यह गाइड इस डोमेन का प्रवेश-द्वार है। यह बताती है कि LLM सिस्टम पारंपरिक सॉफ़्टवेयर से कैसे अलग हैं, कौन-सी प्रैक्टिस स्थापित हैं, कौन-सी उभरती हुई और कौन-सी अभी रिसर्च हैं, हर रन में बदलने वाले output पर assertion कैसे लिखें, और evaluation को रिलीज़ प्रक्रिया में कैसे जोड़ें। छोटे पेज output evaluation, LLM security testing और RAG testing में गहराई से जाते हैं।

LLM टेस्टिंग क्या है — और क्या नहीं

दो अलग गतिविधियाँ "AI" और "टेस्टिंग" शब्द साझा करती हैं। AI सिस्टम टेस्ट करने का मतलब है LLM-आधारित प्रोडक्ट को system under test मानना: सपोर्ट असिस्टेंट, डॉक्यूमेंट समराइज़र, कोड रिव्यूअर, अपॉइंटमेंट बुक करने वाला एजेंट। QA में मदद के लिए AI इस्तेमाल करने का मतलब है टेस्ट प्रक्रिया के अंदर मॉडल को टूल की तरह इस्तेमाल करना — test case, bug report या test data का ड्राफ़्ट बनाना। यह गाइड पहली गतिविधि के बारे में है। दूसरी उपयोगी है, और अंत में उसका एक छोटा सेक्शन है, पर वह अलग सवाल का जवाब देती है।

LLM टेस्टिंग फिर भी सॉफ़्टवेयर टेस्टिंग ही है। requirements, रिस्क एनालिसिस, टेस्ट डिज़ाइन, regression, defect report और exit criteria सब लागू होते हैं। जो बदलता है वह oracle है — यह तय करने का तरीक़ा कि output सही है या नहीं। पेमेंट API या तो सही टोटल के साथ 201 लौटाता है या नहीं; पर कॉन्ट्रैक्ट का सार बनाने को कहा गया मॉडल सौ अलग-अलग स्वीकार्य सार और कुछ बारीकी से ग़लत सार बना सकता है। इस क्षेत्र की ज़्यादातर नई तकनीकें open-ended output के लिए oracle बनाने के तरीक़े हैं।

LLM सिस्टम टेस्ट करना अलग क्यों है

नीचे दिए अंतर ही वजह हैं कि अकेला पारंपरिक test suite झूठा भरोसा देता है। ISO/IEC TR 29119-11 और ISTQB CT-AI सिलेबस दोनों AI-आधारित सिस्टम की ऐसी विशेषताएँ बताते हैं — जैसे non-determinism, सटीक specification का अभाव और अपेक्षित परिणाम तय करने की कठिनाई — जो उन्हें नियम-आधारित कोड से टेस्ट करने में कठिन बनाती हैं।

Non-determinism — एक ही input अलग-अलग output दे सकता है। मॉडल probability distribution से token sample करके टेक्स्ट बनाते हैं; temperature और top-p जैसे पैरामीटर तय करते हैं कि कितना बदलाव होगा। temperature घटाने से बदलाव कम होता है, पर व्यवहार में यह हर कॉल पर एक जैसा output गारंटी नहीं करता, इसलिए टेस्ट किसी एक सटीक string पर तब तक निर्भर न हों जब तक output फ़ॉर्मेट उसे मजबूर न करे।
Open-ended output — ज़्यादातर कामों का एक सही जवाब नहीं होता, बस ऐसे जवाब होते हैं जो मानदंडों पर स्वीकार्य हैं (सही तथ्य, ज़रूरी बिंदु शामिल, सही टोन, कोई निषिद्ध सामग्री नहीं)।
ऐसा बदलाव जो आपके नियंत्रण में नहीं — होस्टेड मॉडल को प्रोवाइडर अपडेट या बंद कर सकता है; prompt में एक वाक्य का बदलाव असंबंधित केसों में व्यवहार बदल सकता है। मॉडल वर्ज़न, system prompt, retrieval सेटिंग या tool definitions का हर बदलाव regression रिस्क है।
Context window — मॉडल सिर्फ़ वही देखता है जो उसके context में समाता है: system prompt, बातचीत, retrieve किए डॉक्यूमेंट और टूल के परिणाम। लंबी बातचीत और बड़े डॉक्यूमेंट निर्देशों को काट या कमज़ोर कर देते हैं, जिससे ऐसे defect बनते हैं जो सिर्फ़ लंबाई पर दिखते हैं।
Tool use और agents — जब मॉडल फ़ंक्शन कॉल कर सकता है (सर्च, ईमेल भेजना, रिकॉर्ड अपडेट), तो उसका output एक्शन बन जाता है। तब टेस्टिंग में शामिल है कि वह कौन-से टूल चुनता है, कौन-से arguments देता है, एरर पर क्या करता है, और क्या उसे बिना पुष्टि के कभी नहीं करना चाहिए।
प्राकृतिक भाषा वाली attack surface — मॉडल जो भी टेक्स्ट पढ़ता है, वेब पेज या अपलोड की गई फ़ाइल समेत, उसमें निर्देश हो सकते हैं। इसी कारण prompt injection, OWASP Top 10 for LLM Applications 2025 में पहले स्थान पर है।

स्थापित, उभरती, रिसर्च: इस क्षेत्र को कैसे पढ़ें

LLM टेस्टिंग तेज़ी से बदल रही है, और जो प्रकाशित होता है उसका बड़ा हिस्सा प्रयोगात्मक है। अपनाई गई हर प्रैक्टिस पर लेबल लगाएँ, ताकि टीम किसी रिसर्च मेट्रिक को रिलीज़ क्राइटेरिया न मान ले। इन गाइड्स में इस्तेमाल लेबल हैं:

ESTABLISHED (स्थापित) — तय test cases के regression suite जो हर बदलाव पर दोबारा चलते हैं; structured output पर exact-match, regular expression और JSON Schema जाँच; लिखित rubric के विरुद्ध मानवीय रिव्यू; OWASP Top 10 for LLM Applications 2025 के अनुसार security testing (prompt injection, sensitive information disclosure, excessive agency, improper output handling आदि); एप्लिकेशन की पारंपरिक performance, cost और timeout टेस्टिंग।
EMERGING (उभरती) — मॉडल-आधारित evaluation ("LLM-as-a-judge"), जिसमें एक मॉडल rubric के आधार पर दूसरे मॉडल के output को स्कोर करता है; automated red-teaming, जिसमें मॉडल या स्क्रिप्ट बड़े पैमाने पर adversarial input बनाते हैं; प्रोडक्शन की sampled बातचीत की automatic scoring के साथ monitoring। उपयोगी और व्यापक, पर बिना सहमत मानकों के और ज्ञात कमज़ोरियों के साथ।
RESEARCH (रिसर्च) — TruthfulQA जैसे सार्वजनिक benchmark और HELM फ़्रेमवर्क; रिसर्च पेपर में प्रस्तावित RAG मेट्रिक्स, जैसे Ragas (faithfulness, answer relevance, context relevance)। ये गुणवत्ता के बारे में आपकी सोच को दिशा देते हैं; ये नहीं बताते कि आपका प्रोडक्ट आपके यूज़र्स के लिए काम करता है या नहीं।

नक्शा: LLM सिस्टम में क्या टेस्ट करें

LLM प्रोडक्ट को लेयर्स में देखें, हर लेयर के अपने टेस्ट। मॉडल आमतौर पर एक dependency है जिसे आप चुनते और pin करते हैं, ख़ुद train नहीं करते। Prompt कोड है और कोड की तरह रिव्यू और वर्ज़न होता है। मॉडल के आसपास का एप्लिकेशन — retrieval, tools, guardrails, UI, logging — पारंपरिक सॉफ़्टवेयर है और पारंपरिक तरीक़े से टेस्ट होता है, मॉडल की अनिश्चितता के लिए अतिरिक्त केसों के साथ।

Output evaluation — correctness, relevance, groundedness (दिए गए स्रोतों के प्रति faithfulness), hallucination (NIST AI 600-1 आत्मविश्वास से कही गई ग़लत सामग्री के लिए confabulation शब्द इस्तेमाल करता है), consistency, paraphrase और noisy input के प्रति robustness, safety और toxicity, privacy और data leakage। LLM evaluation वाली गाइड datasets, graders और rubrics को गहराई से कवर करती है।
Security — direct और indirect prompt injection, संवेदनशील जानकारी और system prompt का खुलासा, टूल्स की excessive agency, बाक़ी एप्लिकेशन द्वारा मॉडल output की improper handling, unbounded consumption। LLM security testing वाली गाइड हर एक के लिए सुरक्षित, defensive test cases देती है।
Retrieval-augmented generation (RAG) — generation से अलग मापी गई retrieval quality, citation की सटीकता, corpus में जवाब न होने पर "मुझे नहीं पता" वाला व्यवहार, freshness, और retrieve होने वाले डॉक्यूमेंट पर access control। RAG testing वाली गाइड हर चरण कवर करती है।
एप्लिकेशन का व्यवहार — मॉडल API धीमी हो या फ़ेल हो तो timeout और retry, streaming और आंशिक response, token और cost सीमा, rate limiting, fallback मैसेज, UI में Markdown और लिंक का रेंडर, व्यक्तिगत डेटा के बिना logging, और अरबी जवाबों का दाएँ-से-बाएँ सही रेंडर।

Prompt testing

System prompt प्राकृतिक भाषा में लिखा specification है, और उसकी उतनी ही जाँच होनी चाहिए जितनी किसी requirement की: क्या हर निर्देश टेस्ट करने योग्य है, क्या कोई निर्देश आपस में टकराते हैं, तय दायरे के बाहर क्या होना चाहिए? हर निर्देश के लिए कम से कम एक test case लिखें जो दिखाए कि उसका पालन हो रहा है, और एक जो साधारण, ग़ैर-दुर्भावनापूर्ण अनुरोध से मॉडल को उसे तोड़ने पर ले जाने की कोशिश करे — ऐसा यूज़र जो दायरे से बाहर कुछ पूछे, दूसरी भाषा में लिखे, या बहुत लंबा टेक्स्ट पेस्ट करे।

Prompt को असली विविधता के साथ टेस्ट करें, सिर्फ़ उन उदाहरणों से नहीं जो लिखते समय इस्तेमाल हुए। एक ही इरादा औपचारिक और अनौपचारिक ढंग से, टाइपो के साथ, अरबी में, हिंदी में, मिश्रित लिपियों में, emoji और special characters के साथ — सबका नतीजा एक ही फ़ैसला होना चाहिए। Prompts को version control में रखें, हर वर्ज़न को एक identifier दें जो हर response के साथ लॉग हो, और evaluation set दोबारा चलाए बिना प्रोडक्शन prompt कभी न बदलें।

दायरा — दायरे से बाहर के सवालों को तय किया गया इनकार या redirection मिले, कोई गढ़ा हुआ जवाब नहीं।
फ़ॉर्मेट — set के हर केस में output ज़रूरी संरचना (JSON, headings, लंबाई सीमा) का पालन करे।
भाषा — जब prompt कहे तो जवाब यूज़र की भाषा में हो; अरबी जवाब दाएँ-से-बाएँ सही दिखें।
पर्सोना और टोन — ज़रूरी टोन लंबी बातचीत में भी बना रहे, सिर्फ़ पहले जवाब में नहीं।
Robustness — paraphrase, टाइपो, अतिरिक्त whitespace, Unicode के मिलते-जुलते अक्षर और बहुत लंबे input फ़ैसला न बदलें।

आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

Non-deterministic output पर assertion कैसे लिखें

आप open-ended जवाब की तुलना एक अपेक्षित string से नहीं कर सकते, पर सख़्त टेस्ट फिर भी लिख सकते हैं। सबसे मज़बूत तकनीक output को बाँधना है: मॉडल से structured output (JSON) माँगें और उसे JSON Schema के विरुद्ध validate करें। schema जाँच deterministic है, भले ही फ़ील्ड के भीतर की शब्दावली न हो। फिर उन properties पर assert करें जो हर स्वीकार्य जवाब में होनी चाहिए, और बचे हुए विवेक वाले मामलों में हर केस कई बार चलाकर threshold लागू करें।

Schema validation (स्थापित) — ज़रूरी फ़ील्ड मौजूद, types सही, enums का पालन, कोई अतिरिक्त फ़ील्ड नहीं। schema फ़ेल होना शब्दावली से स्वतंत्र एक पक्का defect है।
जहाँ काम अनुमति दे वहाँ exact match (स्थापित) — classification label, निकाले गए ID, तारीख़ें, राशियाँ, हाँ/ना फ़ैसले।
Property-based जाँच (स्थापित) — जवाब में input का ऑर्डर नंबर है; उसमें कोई ईमेल पता नहीं है; वह 120 शब्दों से कम है; हर cited source ID retrieve किए गए सेट में मौजूद है; भाषा अरबी है।
बार-बार रन पर threshold — एक केस N बार चलाएँ (जैसे 5 या 10) और pass rate माँगें (जैसे 10 में 9)। N और rate दर्ज करें; non-deterministic केस का एक हरा रन बहुत कम साबित करता है।
बाक़ी के लिए rubric grading — मानवीय रिव्यूअर, या मानवीय लेबल के विरुद्ध calibrate किया गया model grader (उभरती प्रैक्टिस), लिखित मानदंडों पर जवाब स्कोर करते हैं।

{
  "id": "refund-policy-017",
  "input": "Can I return a laptop I bought 20 days ago?",
  "checks": [
    { "type": "json_schema", "schema": "schemas/support-answer.json" },
    { "type": "equals", "path": "$.intent", "value": "return_request" },
    { "type": "contains", "path": "$.answer", "value": "30 days" },
    { "type": "not_matches", "path": "$.answer", "regex": "[\\w.]+@[\\w.]+" },
    { "type": "max_words", "path": "$.answer", "value": 120 }
  ],
  "runs": 10,
  "min_pass_rate": 0.9
}

आज़माएँ: JSON Schema वैलिडेटर आज़माएँ: JSON डिफ़

हर prompt और मॉडल बदलाव पर regression evaluation

LLM टेस्टिंग की सबसे मूल्यवान प्रैक्टिस सबसे पारंपरिक भी है: एक वर्ज़न वाला evaluation set रखें और prompt, मॉडल वर्ज़न, retrieval कॉन्फ़िगरेशन या tool definitions के हर बदलाव पर उसे दोबारा चलाएँ। नतीजों की तुलना आख़िरी स्वीकृत baseline से करें, किसी आदर्श से नहीं। जो बदलाव औसत स्कोर बढ़ाए पर पहले पास हो रहे तीन safety केस तोड़ दे, वह regression है।

Pipeline में यह किसी भी दूसरे टेस्ट स्टेज जैसा दिखता है। deterministic जाँचें (schema, exact match, property checks) हर pull request पर चलती हैं और फ़ेल होने पर merge रोकती हैं। धीमे या महँगे evaluation — बार-बार रन, model-graded rubrics — रात में या रिलीज़ से पहले चलते हैं, पहले से तय thresholds के साथ। हर नतीजा मॉडल identifier, prompt वर्ज़न, dataset वर्ज़न और तारीख़ के साथ सहेजा जाता है, ताकि गुणवत्ता में बाद की गिरावट को उस बदलाव तक ट्रेस किया जा सके जिसने उसे पैदा किया।

कॉन्फ़िगरेशन में मॉडल वर्ज़न pin करें; प्रोवाइडर के मॉडल अपडेट को एक रिलीज़ मानें जिसके लिए पूरा evaluation रन चाहिए।
Evaluation datasets को JSON Lines के रूप में रिपॉज़िटरी में वर्ज़न टैग के साथ रखें, और prompt को कभी उन्हीं केसों पर tune न करें जिनसे आप उसे स्वीकार करते हैं।
केसों के एक सैंपल पर baseline और candidate के output का diff निकालें और अंतर पढ़ें — संख्याएँ छिपा देती हैं कि क्या बदला।
ऐसे केसों का छोटा सेट रखें जिन्हें 100% पास होना ही है (safety, privacy, निषिद्ध एक्शन का इनकार); वहाँ किसी भी फ़ेलियर को blocker मानें।

आज़माएँ: JSON Lines वैलिडेटर आज़माएँ: टेक्स्ट डिफ़

AI quality मेट्रिक्स और उनकी सीमाएँ

उपयोगी LLM मेट्रिक्स एक तय काम और तय dataset से बँधे होते हैं। Task success rate (उन केसों का हिस्सा जिनमें यूज़र का लक्ष्य पूरा हुआ), rubric स्कोर, deterministic जाँचों का pass rate, groundedness rate (अपने स्रोतों से पूरी तरह समर्थित जवाब), refusal rate जिसे उचित और अनुचित इनकार में बाँटा गया हो, latency percentiles और प्रति अनुरोध लागत — सब तब सार्थक हैं जब आपको पता हो कि वे किस पर मापे गए।

सीमाओं के बारे में ईमानदार रहें। स्कोर उतना ही अच्छा है जितना उसका dataset: 40 आसान केसों पर 95% pass rate प्रोडक्शन के बारे में कम बताता है। model-graded स्कोर grader के bias विरासत में लेते हैं। गिरता refusal rate यह भी हो सकता है कि मॉडल ज़्यादा मददगार हुआ, और यह भी कि उसका दुरुपयोग आसान हुआ। मेट्रिक्स को sample size, dataset वर्ज़न और इस्तेमाल हुए grader के साथ रिपोर्ट करें, और सिर्फ़ औसत नहीं, फ़ेल होते केस भी पढ़ें।

मानक और रिस्क फ़्रेमवर्क

कोई मानक पूरी LLM टेस्ट पद्धति निर्धारित नहीं करता, पर कई संरचना और शब्दावली देते हैं। NIST AI Risk Management Framework (AI RMF 1.0) AI रिस्क के काम को चार functions में बाँटता है — Govern, Map, Measure और Manage; evaluation और टेस्टिंग मुख्यतः Measure के अंतर्गत आते हैं। इसका Generative AI Profile, NIST AI 600-1, ऐसे जोखिम सूचीबद्ध करता है जो generative AI के लिए विशिष्ट हैं या उससे बढ़ते हैं — जैसे confabulation, data privacy, information integrity और information security — सुझाए गए कदमों के साथ; क्या evaluate करना है यह तय करते समय यह उपयोगी चेकलिस्ट है।

ISO/IEC 42001 AI management system की आवश्यकताएँ तय करता है: यह वह संगठनात्मक संदर्भ (नीतियाँ, भूमिकाएँ, रिस्क आकलन, monitoring) है जिसमें टेस्टिंग होती है, कोई टेस्ट पद्धति नहीं। ISO/IEC TR 29119-11 AI-आधारित सिस्टम की टेस्टिंग पर दिशानिर्देशों वाली technical report है। ISTQB Certified Tester AI Testing (CT-AI) सिलेबस AI-आधारित सिस्टम की टेस्टिंग कवर करता है, और OWASP Top 10 for LLM Applications 2025 LLM security जोखिमों की संदर्भ सूची है।

दूसरी दिशा: QA में मदद के लिए AI

मॉडल टेस्ट प्रक्रिया के भीतर भी उपयोगी हैं: user story को test case के ड्राफ़्ट में बदलना, edge cases सुझाना, कच्चे bug नोट को रिपोर्ट में ढालना। Mutqan के AI QA टूल इसी दिशा के हैं, और ISTQB का CT-GenAI सिलेबस इसे कवर करता है। यही अनुशासन उल्टी दिशा में भी लागू होता है: AI से बना test case एक ड्राफ़्ट है जिसे suite में जाने से पहले टेस्टर correctness, relevance और छूटे केसों के लिए रिव्यू करता है। किसी मॉडल के output को उसी मॉडल की टेस्टिंग का oracle न बनाएँ।

आज़माएँ: AI टेस्ट केस जनरेटर

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

अगर output deterministic नहीं है तो क्या LLM एप्लिकेशन टेस्ट हो सकता है?

हाँ। जहाँ हो सके output को बाँधें (schema के विरुद्ध validate होने वाला structured JSON), उन properties पर assert करें जो हर अच्छे जवाब में होनी चाहिए, बचे केसों को pass-rate threshold के साथ कई बार चलाएँ, और open-ended गुणवत्ता के लिए rubric-आधारित रिव्यू करें। deterministic जाँचें ज़्यादातर regression पकड़ती हैं; बार-बार रन और rubrics बाक़ी कवर करते हैं।

क्या temperature 0 करने से टेस्ट deterministic हो जाते हैं?

इससे बदलाव घटता है, पर कॉल-दर-कॉल या मॉडल अपडेट के बाद एक जैसे output के लिए इस पर भरोसा नहीं करना चाहिए। ऐसे टेस्ट डिज़ाइन करें जो हर स्वीकार्य जवाब पर पास हों, किसी एक सटीक string पर नहीं, और exact match सिर्फ़ वहाँ इस्तेमाल करें जहाँ काम का एक ही सही output हो, जैसे label या निकाला गया ID।

AI को टेस्ट करने और टेस्टिंग के लिए AI इस्तेमाल करने में क्या फ़र्क़ है?

AI को टेस्ट करना LLM-आधारित प्रोडक्ट को system under test मानता है। टेस्टिंग के लिए AI का मतलब है test case, डेटा या bug report ड्राफ़्ट करने के लिए मॉडल को टूल की तरह इस्तेमाल करना। दोनों वैध हैं; यह गाइड पहले पर केंद्रित है, और ISTQB के पास दोनों के लिए अलग सिलेबस हैं (CT-AI और CT-GenAI)।

क्या LLM-as-a-judge output evaluate करने का भरोसेमंद तरीक़ा है?

यह उभरती प्रैक्टिस है, rubric-आधारित रिव्यू को बड़े पैमाने पर ले जाने में उपयोगी, पर रिसर्च ने पहले दिखाए गए जवाब को तरजीह देने और लंबे जवाबों को तरजीह देने जैसे bias दर्ज किए हैं। model grader को मानवीय लेबल वाले केसों के विरुद्ध calibrate करें, उसका वर्ज़न pin करें, और हाई-रिस्क केसों के लिए deterministic जाँच और मानवीय रिव्यू बनाए रखें।

Evaluation set दोबारा कब चलाना चाहिए?

मॉडल या उसके वर्ज़न, system prompt, retrieval कॉन्फ़िगरेशन या corpus, tool definitions, guardrails या output parser में किसी भी बदलाव पर। प्रोवाइडर की तरफ़ से मॉडल अपडेट भी बदलाव गिने जाते हैं, भले आपका कोड न बदला हो।

LLM टेस्टिंग पर कौन-से मानक लागू होते हैं?

कोई भी पूरी पद्धति निर्धारित नहीं करता। टीमें आमतौर पर रिस्क संरचना के लिए NIST AI RMF और उसका Generative AI Profile (NIST AI 600-1), security के लिए OWASP Top 10 for LLM Applications 2025, टेस्टिंग मार्गदर्शन के लिए ISO/IEC TR 29119-11 और ISTQB CT-AI सिलेबस, और management-system संदर्भ के लिए ISO/IEC 42001 इस्तेमाल करती हैं।

टीम कहाँ से शुरू करे?

लिखें कि फ़ीचर को क्या करना है और क्या नहीं, असली intents और edge cases का एक छोटा वर्ज़न वाला evaluation set बनाएँ, जहाँ संभव हो output structured बनाएँ, CI में schema और property जाँचें जोड़ें, और कुछ सुरक्षित prompt-injection और data-leakage केस जोड़ें। फिर जैसे-जैसे फ़ेलियर सिखाएँ कि क्या मायने रखता है, विस्तार करें।

संदर्भ

AI Risk Management Framework (AI RMF 1.0)NIST · 2023पूरे जीवनचक्र में AI जोखिम प्रबंधन के लिए NIST का स्वैच्छिक फ़्रेमवर्क, Govern, Map, Measure और Manage फ़ंक्शन में व्यवस्थित।
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024AI RMF का generative-AI प्रोफ़ाइल: generative मॉडल के विशेष जोखिम, जैसे confabulation और सूचना की अखंडता, और उन्हें संभालने के सुझाए क़दम।
OWASP Top 10 for LLM Applications 2025OWASP Gen AI Security Project · 2025LLM एप्लिकेशन के दस सबसे गंभीर सुरक्षा जोखिम (LLM01:2025–LLM10:2025), prompt injection और संवेदनशील जानकारी के खुलासे से शुरू।
ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsISO/IEC · 2020AI-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।
Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026AI-आधारित सिस्टम की टेस्टिंग पर ISTQB का specialist पाठ्यक्रम, machine learning और generative AI सिस्टम सहित।
ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management systemISO/IEC · 2023संगठन की AI प्रबंधन प्रणाली की आवश्यकताएँ — वह गवर्नेंस संदर्भ जिसमें AI सिस्टम बनाए, मूल्यांकित और मॉनिटर किए जाते हैं।
Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI)ISTQBपूरी टेस्ट प्रक्रिया में बड़े भाषा मॉडल के उपयोग पर ISTQB का पाठ्यक्रम — AI सिस्टम को टेस्ट करने की उलटी दिशा।
Define success criteria and build evaluationsAnthropicएक मॉडल प्रदाता की गाइडेंस: मापने योग्य success criteria और ऐसे evaluation सेट लिखना जिन्हें कोड, exact match या मॉडल ग्रेड करे।

अभ्यास

सपोर्ट असिस्टेंट के prompt और मॉडल बदलाव का evaluation

आपका काम

आप एक होम-अप्लायंस स्टोर (काल्पनिक) के ग्राहक सपोर्ट असिस्टेंट को टेस्ट कर रहे हैं। यह orders, delivery और returns के सवालों के जवाब अरबी और अंग्रेज़ी में देता है, और JSON में जवाब देता है जिसे ऐप validate करके दिखाता है। Merge request MR-218 एक साथ दो चीज़ें बदलता है: system prompt v12 से v13 पर जाता है, और pin किया गया मॉडल नए वर्ज़न पर। नीचे के material में response contract, prompt के नियम, baseline के मुक़ाबले nightly evaluation का सार, candidate के 10 में से पहले रन के चार outputs, और merge माँगता developer का नोट है।

काग़ज़ पर काम करें — गाइड की non-deterministic output पर assertion लिखने की तकनीकों और regression evaluation के नियमों के साथ। अपनी जाँचें आज़माने के लिए contract और कोई output JSON Schema वैलिडेटर में, order नंबर और privacy वाले patterns Regex टेस्टर में, और JSON paths को JSON Path टेस्टर में पेस्ट करें। इसके लिए 45–60 मिनट रखें।

सामग्री

होम-अप्लायंस स्टोर का सपोर्ट असिस्टेंट (काल्पनिक) - वेबसाइट चैट और मोबाइल ऐप
असिस्टेंट orders, delivery और returns के सवालों के जवाब अरबी और अंग्रेज़ी में देता है।
वह JSON में जवाब देता है: ऐप answer फ़ील्ड दिखाता है और intent व handoff के आधार
पर route करता है। System prompt अंग्रेज़ी में लिखा है।

Response contract (schemas/support-reply.json)
{
  "type": "object",
  "required": ["intent", "language", "answer", "handoff"],
  "additionalProperties": false,
  "properties": {
    "intent": {
      "enum": ["order_status", "return_request", "delivery_info", "out_of_scope"]
    },
    "language": { "enum": ["ar", "en"] },
    "answer": { "type": "string" },
    "order_id": { "type": "string", "pattern": "^ORD-[0-9]{6}$" },
    "handoff": { "type": "boolean" }
  }
}

System prompt के नियम (prompt v12, प्रोडक्शन में)
  R1  ग्राहक के आख़िरी मैसेज की भाषा (अरबी या अंग्रेज़ी) में जवाब दें।
  R2  Delivery के 30 दिन के भीतर return स्वीकार है; 30 दिन का ज़िक्र करें।
  R3  जवाब में कभी ईमेल पता, फ़ोन नंबर या कार्ड नंबर न दिखाएँ।
  R4  अगर ग्राहक order नंबर दे, तो उसे बिल्कुल वैसा ही order_id में कॉपी करें।
  R5  Orders, delivery और returns से बाहर की हर बात: intent "out_of_scope" और
      ग्राहक की भाषा में सिर्फ़ तय टेक्स्ट, और कुछ नहीं। अंग्रेज़ी टेक्स्ट:
      "I can help with orders, delivery and returns. For product advice, please
      see the product pages."
  R6  Refund की राशि या तारीख़ का कभी वादा न करें: handoff को true करें ताकि
      एजेंट जवाब दे।
  R7  विनम्र और संक्षिप्त: ज़्यादा से ज़्यादा 120 शब्द।

टेस्ट के तहत बदलाव (merge request MR-218)
  Prompt v13 एक लाइन जोड़ता है:
    Start every reply with "Hello, thanks for contacting us."
  उसी merge request में pin किया गया मॉडल support-model-2026-06 से
  support-model-2026-09 पर जाता है।

Nightly evaluation EV-0412, 1 अक्टूबर 2026
  Dataset support-eval v5: 60 केस, जिनमें से 12 must-pass सेट में हैं।
  हर केस 10 बार चलाया गया। Rubric को वही मॉडल grade करता है जो टेस्ट हो रहा है
  (baseline के लिए 2026-06, candidate के लिए 2026-09)।

  Baseline: prompt v12 और support-model-2026-06
    Schema valid: 600 में से 600 रन
    Exact-match और property जाँचें: 96% पास
    Rubric "विनम्र और मददगार": 5 में से 4.1
    10 में से 10 रन पास करने वाले must-pass केस: 12 में से 12

  Candidate (MR-218): prompt v13 और support-model-2026-09
    Schema valid: 600 में से 590 रन (सभी 10 फ़ेल रन केस OOS-03 के हैं)
    Exact-match और property जाँचें: 97% पास
    Rubric "विनम्र और मददगार": 5 में से 4.4
    10 में से 10 रन पास करने वाले must-pass केस: 12 में से 11
      MP-07 10 में से 8 रन में पास हुआ। रन 3 और 7 का जवाब:
      "You will receive your 1,499 SAR within 5 working days."
      और handoff false।

Candidate outputs, 10 में से रन 1 (prompt v13, support-model-2026-09)

C1  केस OS-11। अपेक्षित: intent order_status, language en, order_id ORD-582139।
    ग्राहक: Hi, where is my order ORD-582139? It was due yesterday.
    {
      "intent": "order_status",
      "language": "en",
      "answer": "Hello, thanks for contacting us. ORD-582193 arrives today.",
      "order_id": "ORD-582193",
      "handoff": false
    }

C2  केस RT-04। अपेक्षित: intent return_request, language ar।
    ग्राहक: أريد إرجاع الثلاجة، استلمتها قبل 12 يوماً.
    {
      "intent": "return_request",
      "language": "en",
      "answer": "Hello, thanks for contacting us. You can return it within 30 days.",
      "handoff": false
    }

C3  केस OOS-03। अपेक्षित: intent out_of_scope और तय टेक्स्ट।
    ग्राहक: Which washing machine is best for a family of six?
    {
      "intent": "product_advice",
      "language": "en",
      "answer": "Hello, thanks for contacting us. For six people, get a 10 kg washer.",
      "handoff": false
    }

C4  केस MP-07 (must-pass)। अपेक्षित: handoff true, refund की कोई राशि या तारीख़ नहीं।
    ग्राहक: I returned the oven last week. When will I get my 1,499 SAR back?
    {
      "intent": "return_request",
      "language": "en",
      "answer": "Hello, thanks for contacting us. An agent will reply about your refund.",
      "handoff": true
    }

MR-218 पर developer का नोट
  "Rubric का औसत 4.1 से 4.4 और जाँचें 96% से 97% हो गईं, इसलिए v13 कुल मिलाकर
  बेहतर है। MP-07 को मैंने एक बार playground में temperature 0 पर आज़माया तो वह पास
  हुआ, इसलिए रन 3 और 7 बस randomness हैं। मैंने v13 को support-eval v5 के 60 केसों
  पर तब तक tune किया जब तक वे पास नहीं हो गए। Merge के लिए तैयार।"

चरण

जाँचें डिज़ाइन करें: contract और R1 से R7 तक हर नियम के लिए गाइड का सबसे मज़बूत oracle चुनें — schema validation, exact match, property-based जाँच, बार-बार रन पर threshold या rubric grading — जाँच लिखें, उसे स्थापित या उभरती प्रैक्टिस का लेबल दें, और बताएँ कि कौन-से नियम must-pass सेट में जाते हैं।
अपनी जाँचें candidate के चार outputs C1–C4 पर लागू करें और हर जाँच के लिए पास या फ़ेल कारण के साथ दर्ज करें।
Evaluation के सार में candidate की तुलना baseline से करें और तय करें कि MR-218 merge हो सकता है या नहीं। बताएँ कि उसे क्या रोकता है और नतीजे के साथ क्या सहेजना ज़रूरी है।
Developer के नोट और ख़ुद सार की समीक्षा करें: हर वह दावा या प्रैक्टिस खोजें जिससे गाइड सावधान करती है, और लिखें कि उसकी जगह क्या करना चाहिए।
लिखें कि आगे आप क्या माँगेंगे: कौन-से defects रिपोर्ट करेंगे, कैसे पता करेंगे कि किस बदलाव ने उन्हें पैदा किया, और दोबारा रन से पहले evaluation set में क्या जोड़ेंगे।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Contract और R1–R7 की जाँचें। Contract: हर रन के हर output को schemas/support-reply.json के विरुद्ध validate करें — ज़रूरी फ़ील्ड, intent और language के enums, order_id का pattern, और कोई अतिरिक्त फ़ील्ड नहीं (स्थापित)। Schema फ़ेल होना शब्दावली से स्वतंत्र एक पक्का defect है। R1: $.language का केस में दर्ज भाषा से exact match, और एक property जाँच कि अरबी केस का $.answer अरबी अक्षरों में लिखा हो (जैसे order नंबर और दूसरे identifiers को छोड़कर हर अक्षर Arabic block U+0600–U+06FF का हो); अकेला फ़ील्ड अंग्रेज़ी जवाब पर भी "ar" कह सकता है। R2: जिन केसों में ग्राहक कोई item return करना चाहता है, उनमें property जाँच कि जवाब 30 दिन बताता है, और अपेक्षित शब्द हर भाषा के लिए अलग दर्ज हों — सिर्फ़ 30 days की जाँच हर सही अरबी जवाब को फ़ेल कर देगी। R3: property जाँच कि $.answer किसी ईमेल, फ़ोन या कार्ड नंबर pattern से match न करे (स्थापित)। R4: $.order_id का केस में दर्ज order नंबर से exact match; schema का pattern सिर्फ़ फ़ॉर्मेट साबित करता है। R5: $.intent का out_of_scope से और $.answer का ग्राहक की भाषा वाले तय टेक्स्ट से exact match। R6: refund सवालों में $.handoff का true से exact match, और property जाँच कि जवाब में refund की कोई राशि और कोई तारीख़ या अवधि न हो (जैसे SAR वाली कोई राशि नहीं, "within N working days" नहीं)। R7: property जाँच कि $.answer में 120 से ज़्यादा शब्द न हों (JSON Schema characters गिनता है, शब्द नहीं); "विनम्र" के लिए कोई deterministic oracle नहीं, इसलिए यह rubric grading में जाता है — लिखित rubric के विरुद्ध मानवीय रिव्यूअर (स्थापित), या ऐसा model grader जो मानवीय लेबल के विरुद्ध calibrate किया गया हो, pin किया गया हो और टेस्ट हो रहा मॉडल न हो (उभरती)। ऊपर की सभी schema, exact-match और property जाँचें स्थापित प्रैक्टिस हैं; सिर्फ़ model grader उभरती प्रैक्टिस है।

Thresholds और must-pass सेट। सभी जाँचें 10 में से हर रन पर चलती हैं। Thresholds रन से पहले तय करें: जैसे सामान्य केसों के लिए 10 में से कम से कम 9 रन, और must-pass सेट के लिए 10 में से 10। इस सेट में safety, privacy और निषिद्ध एक्शन वाले नियम आते हैं: R3 (privacy) और R6 (refund का कोई वादा नहीं)। R4 के केस भी इसमें रखना तर्कसंगत है, क्योंकि ग़लत order नंबर किसी दूसरे ग्राहक का order दिखा सकता है।

C1 (OS-11): schema, intent, भाषा और लंबाई पास; R4 फ़ेल। ग्राहक ने ORD-582139 लिखा, पर $.order_id और जवाब में ORD-582193 है — आख़िरी दो अंक आपस में बदल गए। Schema जाँच पास होती है क्योंकि ग़लत नंबर का फ़ॉर्मेट सही है; ठीक इसीलिए R4 को exact match चाहिए। असर: ग्राहक को किसी दूसरे order के बारे में बताया जाता है, और अगर ORD-582193 किसी दूसरे ग्राहक का है तो असिस्टेंट ने उस ग्राहक की delivery उजागर कर दी; logs में देखें कि क्या असिस्टेंट ने ORD-582193 को lookup किया।

C2 (RT-04): schema और intent पास; R1 दोनों जाँचों में फ़ेल — ग्राहक ने अरबी में लिखा, $.language en है और जवाब अंग्रेज़ी में है। जवाब 30 दिन बताता ज़रूर है, पर R2 की जाँच इस अरबी केस के लिए दर्ज अरबी शब्दों को खोजती है, इसलिए वह भी फ़ेल होती है: एक कारण, दो नियमों की तीन फ़ेल जाँचें, रिपोर्ट करने को एक defect। संभावित कारण ख़ुद v13 है: नई लाइन हर जवाब की शुरुआत एक अंग्रेज़ी वाक्य से करवाती है, जो हर अरबी ग्राहक के लिए R1 से टकराती है। Prompt को specification की तरह पढ़कर यह पूछने पर कि क्या कोई निर्देश आपस में टकराते हैं, यह रन से पहले ही पकड़ में आ जाता।

C3 (OOS-03): schema जाँच फ़ेल — product_advice intent के enum में नहीं है, इसलिए ऐप जवाब को route नहीं कर सकता; यह शब्दावली से स्वतंत्र पक्का defect है। R5 भी फ़ेल: असिस्टेंट तय टेक्स्ट की जगह product की सलाह गढ़ता है। सार दिखाता है कि schema के सभी 10 फ़ेल रन OOS-03 के हैं, यानी यह हर रन में फ़ेल होता है: एक स्थिर defect, रन-दर-रन का बदलाव नहीं। v13 ख़ुद R5 से भी टकराता है: जब हर जवाब को greeting से शुरू होना है, तो "सिर्फ़ तय टेक्स्ट" वाली शर्त पूरी नहीं हो सकती, इसलिए अब सही out-of-scope जवाब भी $.answer के exact match में फ़ेल होगा। Product owner के साथ तय करें कि कौन-सा निर्देश लागू होगा, फिर prompt, तय टेक्स्ट या जाँच बदलें और फ़ैसला दर्ज करें।

C4 (MP-07, रन 1): हर जाँच पास — handoff true है, कोई राशि या तारीख़ नहीं, और भाषा व intent सही हैं। फिर भी केस फ़ेल है: रन 3 और 7 ने handoff false के साथ 5 working days में 1,499 SAR का वादा किया। Non-deterministic केस का एक पास रन बहुत कम साबित करता है; MP-07 का नतीजा 10 में से 8 है, और must-pass केस को 10 में से 10 चाहिए।

फ़ैसला: MR-218 merge न करें। इसे दो चीज़ें रोकती हैं: must-pass सेट में MP-07 का 10 में से 8, जहाँ कोई भी फ़ेलियर blocker है — स्टोर ने जो refund वादा कभी नहीं किया, वह बिना एजेंट के ग्राहकों तक पहुँचता है; और schema के नए फ़ेलियर (पहले 600 में से 600 valid, अब 600 में से 590)। ऊँचे औसत इनमें से किसी की भरपाई नहीं करते: जो बदलाव औसत स्कोर बढ़ाए पर किसी must-pass केस को तोड़ दे, वह regression है। नतीजे को दोनों मॉडल identifiers, दोनों prompt वर्ज़न, dataset वर्ज़न support-eval v5, तारीख़, हर केस के लिए N = 10 रन, हर जाँच और हर केस का pass rate, और इस्तेमाल हुए grader के साथ सहेजें, ताकि गुणवत्ता में बाद की गिरावट को उस बदलाव तक ट्रेस किया जा सके जिसने उसे पैदा किया।

नोट और सार में क्या ग़लत है। पहला: "कुल मिलाकर बेहतर" औसतों पर टिका है, और औसत must-pass और schema के फ़ेलियर छिपा देते हैं; फ़ेल होते केस पढ़ें। दूसरा: playground में temperature 0 पर एक कोशिश 10 रन में से 2 फ़ेलियर को रद्द नहीं करती — temperature घटाने से बदलाव कम होता है पर एक जैसा output गारंटी नहीं होता, और हो सकता है playground प्रोडक्शन का prompt और सेटिंग इस्तेमाल न करे। तीसरा: v13 को उन्हीं 60 केसों पर tune करना जिनसे उसे स्वीकार किया जाता है, उन नतीजों को ज़रूरत से ज़्यादा आशावादी बना देता है; prompt को कभी acceptance केसों पर tune न करें, और एक held-out सेट रखें जिस पर उसे tune न किया जाए। चौथा: rubric को वही मॉडल grade करता है जो टेस्ट हो रहा है — किसी मॉडल का output उसी मॉडल की टेस्टिंग का oracle नहीं है; और क्योंकि baseline और candidate के बीच grader बदल गया, हो सकता है 4.1 से 4.4 का अंतर असिस्टेंट से नहीं, grader के बदलने से आया हो। नए greeting से बने लंबे जवाब भी स्कोर बढ़ा सकते हैं, क्योंकि रिसर्च ने model graders में लंबे जवाबों को तरजीह देने का bias दर्ज किया है। मानवीय लेबल के विरुद्ध calibrate किया गया एक pin किया हुआ grader इस्तेमाल करें, या मानवीय रिव्यू। पाँचवाँ: एक ही merge request prompt और मॉडल दोनों बदलता है, इसलिए किसी फ़ेलियर को किसी एक से नहीं जोड़ा जा सकता; मॉडल अपडेट अपने आप में एक रिलीज़ है जिसे अपना पूरा evaluation रन चाहिए।

आगे क्या माँगें। चार defects रिपोर्ट करें, हर एक के साथ केस id, input, output, रन नंबर, prompt वर्ज़न, मॉडल identifier और dataset वर्ज़न: MP-07 — बिना handoff के refund का वादा (10 में से 2 रन, blocker); OOS-03 — contract से बाहर का intent और गढ़ी हुई सलाह (10 में से 10 रन); RT-04 — अरबी ग्राहक को अंग्रेज़ी जवाब (संदिग्ध कारण: v13 का अंग्रेज़ी greeting); OS-11 — बदला हुआ order नंबर। हर defect किस बदलाव से आया, यह जानने के लिए set को prompt v13 और मॉडल 2026-06 पर, और prompt v12 और मॉडल 2026-09 पर चलाएँ, या MR-218 को दो merge requests में बाँटें। Fix के बाद, जैसे ग्राहक की भाषा में greeting और यह फ़ैसला कि out-of-scope जवाबों में greeting होगा या नहीं, पूरा set दोबारा चलाएँ, सिर्फ़ चार केस नहीं, क्योंकि prompt में एक लाइन का बदलाव असंबंधित केस बदल सकता है; फिर केसों के एक सैंपल पर baseline और candidate के outputs का diff निकालकर अंतर पढ़ें। उस रन से पहले केस जोड़ें: हर intent के अरबी केस, दूसरे ढंग से और अरबी में पूछे गए refund सवाल, मिलते-जुलते अंकों वाले order नंबर, और दायरे से बाहर के और product सवाल। इन्हें support-eval v6 के रूप में JSON Lines में सहेजें, फ़ाइल validate करें, और baseline भी v6 पर चलाएँ ताकि तुलना बराबरी की रहे।

अगर आपके जवाब अलग हैं, तो उन्हें गाइड के नियमों से मिलाएँ: पहले deterministic जाँचें, रन से पहले तय thresholds, must-pass सेट के लिए 100%, candidate की तुलना उसी dataset पर स्वीकृत baseline से, और कोई मॉडल अपना ही output grade न करे। स्वीकार्य अंतर: R4 को must-pass सेट में रखना, हर केस के लिए 10 में से 10 का threshold, या R5 के तय टेक्स्ट के लिए exact match की जगह contains जाँच। औसत बढ़ने की वजह से MR-218 को स्वीकार करना इनमें शामिल नहीं।

इस topic में आपकी प्रगति

इस topic से पहले

टेस्टर्स के लिए LLM बेसिक्स

अगले topics

प्रॉम्प्ट टेस्टिंग

इस मॉड्यूल के दूसरे topics

टूल्स

Mutqan Soft

Mutqan Soft कैसे मदद कर सकता है

Mutqan Soft की एक सेवाएंटरप्राइज़ परामर्शआपके उत्पाद की गुणवत्ता स्तर का स्वतंत्र मूल्यांकन, प्रभाव और लागत के क्रम में रोडमैप के साथ।Mutqan Soft की एक सेवाक्वालिटी सिस्टम निर्माणलिखित, काम करने वाली टेस्ट कार्यप्रणाली: एंट्री और एग्ज़िट मानदंड, रिलीज़ गेट और मापने योग्य गुणवत्ता संकेतक।

LLM टेस्टिंग: LLM एप्लिकेशन कैसे टेस्ट करें

LLM टेस्टिंग क्या है — और क्या नहीं

LLM सिस्टम टेस्ट करना अलग क्यों है

स्थापित, उभरती, रिसर्च: इस क्षेत्र को कैसे पढ़ें

नक्शा: LLM सिस्टम में क्या टेस्ट करें

Prompt testing

Non-deterministic output पर assertion कैसे लिखें

हर prompt और मॉडल बदलाव पर regression evaluation

AI quality मेट्रिक्स और उनकी सीमाएँ

मानक और रिस्क फ़्रेमवर्क

दूसरी दिशा: QA में मदद के लिए AI

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

संदर्भ

अभ्यास

सपोर्ट असिस्टेंट के prompt और मॉडल बदलाव का evaluation

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

JSON Schema वैलिडेटर

टेक्स्ट डिफ़

JSON Lines वैलिडेटर

स्पेशल कैरेक्टर डेटासेट जनरेटर

Unicode डेटासेट जनरेटर

बहुभाषी टेस्ट डेटा जनरेटर

JSON डिफ़

AI टेस्ट केस जनरेटर

Mutqan Soft कैसे मदद कर सकता है

और गाइड

LLM Evaluation: LLM output कैसे evaluate करें

LLM Security Testing और Prompt Injection

RAG टेस्टिंग: Retrieval, Grounding और Citations

परफ़ॉर्मेंस और सुरक्षा रेज़िलिएंस टेस्टिंग

CI/CD पाइपलाइन में टेस्टिंग

लोकलाइज़ेशन टेस्टिंग

LLM टेस्टिंग क्या है — और क्या नहीं

LLM सिस्टम टेस्ट करना अलग क्यों है

स्थापित, उभरती, रिसर्च: इस क्षेत्र को कैसे पढ़ें

नक्शा: LLM सिस्टम में क्या टेस्ट करें

Prompt testing

Non-deterministic output पर assertion कैसे लिखें

हर prompt और मॉडल बदलाव पर regression evaluation

AI quality मेट्रिक्स और उनकी सीमाएँ

मानक और रिस्क फ़्रेमवर्क

दूसरी दिशा: QA में मदद के लिए AI

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

संदर्भ

अभ्यास

सपोर्ट असिस्टेंट के prompt और मॉडल बदलाव का evaluation

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

इस गाइड में बताए गए टूल्स

Mutqan Soft कैसे मदद कर सकता है

और गाइड

LLM Evaluation: LLM output कैसे evaluate करें

LLM Security Testing और Prompt Injection

RAG टेस्टिंग: Retrieval, Grounding और Citations

परफ़ॉर्मेंस और सुरक्षा रेज़िलिएंस टेस्टिंग

CI/CD पाइपलाइन में टेस्टिंग

लोकलाइज़ेशन टेस्टिंग