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

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · उन्नत

Prompt testing यह जाँचती है कि prompt — यानी वे instructions, examples और variables जो application language model को भेजता है — test inputs के एक तय set पर स्वीकार्य output देता है, और हर नया version वह सब बनाए रखता है जो पिछला अच्छा करता था। आप इसे system के किसी भी दूसरे हिस्से की तरह टेस्ट करते हैं: test basis के विरुद्ध, design किए गए test cases और दर्ज नतीजों के साथ।

उदाहरण: एक store के support assistant का prompt कहता है: "ग्राहक की भाषा में जवाब दें" और "टूटे सामान की हर शिकायत किसी human agent को सौंपें"। Test set में delivery पर अरबी में एक सवाल, टूटी केतली पर हिंदी में एक शिकायत, और अंग्रेज़ी में ऐसी service की एक request है जो store देता ही नहीं। हर case बताता है कि हर स्वीकार्य जवाब को क्या करना है, ताकि वही checks आज prompt के version 3 पर और कल version 4 पर चलें।

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

LLM application में prompts लगभग किसी भी दूसरे हिस्से से ज़्यादा बार बदलते हैं, और एक वाक्य का edit असंबंधित लगने वाले cases में व्यवहार बदल सकता है। Natural language के निर्देशों को न कोई compiler जाँचता है, न type check: बेहतर पढ़ा जाने वाला prompt भी policy की कोई शर्त छोड़ सकता है, जवाब की भाषा बदल सकता है या शिकायतें escalate करना बंद कर सकता है। Test set और दर्ज baseline के बिना ऐसे regressions चुपचाप users तक पहुँचते हैं।

Tester के लिए prompt testing "नया prompt बेहतर लगता है" को सबूत में बदल देती है: कौन-से cases सुधरे, कौन-से टूटे, किस model और prompt version पर। यह LLM defects को reproduce करना आसान भी बनाती है, क्योंकि prompt version, model और input बताने वाली report दोबारा चलाई जा सकती है।

असल में टेस्ट क्या हो रहा है

LLM testing वाली guide में आपने देखा कि system prompt natural language में लिखा specification है। जिसे आप version और टेस्ट करते हैं वह थोड़ा बड़ा है: आपकी team के नियंत्रण वाली हर चीज़ जो जवाब को आकार देती है, एक identifier वाली एक configuration के रूप में, ताकि हर नतीजा उसे पैदा करने वाली चीज़ तक trace हो सके।

हर निर्देश एक test condition है: एक case लिखें जिसमें उसका पालन ज़रूरी हो, और एक जिसमें कोई आम user उसका पालन मुश्किल बना दे। Test design के partitions, boundaries और decision rules यहाँ भी लागू होते हैं।

System prompt: role, scope, नियम, tone और output format।
Template और उसके variables, जैसे {customer_name}, जो run time पर भरे जाते हैं — उन्हें खाली, बहुत लंबा और दूसरी लिपियों में भी टेस्ट करें।
Few-shot examples, यानी prompt में लिखे गए sample inputs और उनके आदर्श जवाब, जो दिखाते हैं कि क्या अपेक्षित है: उन्हें बदलना या उनका क्रम बदलना भी prompt change है।
Model identifier और temperature जैसे parameters: वही text दूसरे model version या दूसरी settings के साथ अलग व्यवहार कर सकता है।

Inputs का test set बनाना

Prompt test set test cases की एक versioned file है; हर case में एक input, variables की values और वे checks होते हैं जिन्हें हर स्वीकार्य जवाब को पास करना है। यह testware है: review होता है, repository में रहता है और सोच-समझकर बदला जाता है। एक held-out हिस्सा रखें जो सिर्फ़ version accept करने में इस्तेमाल हो; जो prompt अपने ही acceptance cases पास होने तक tune हुआ हो, वह कागज़ पर असल से बेहतर दिखता है।

Cases कई स्रोतों से लें। नीचे का अंश पढ़ने में आसानी के लिए YAML में है; teams अक्सर यही structure JSON Lines में रखती हैं।

Instructions: हर निर्देश का पालन करने वाला एक case और उस पर दबाव डालने वाला एक case।
असली requests: logs या support tickets से बार-बार आने वाले intents, personal data हटाकर।
Variation: औपचारिक और अनौपचारिक शब्द, typos, अरबी, हिंदी और मिश्रित लिपियाँ, बहुत छोटे और बहुत लंबे inputs।
Out of scope: ऐसे सवाल जिन्हें assistant को मना करना या कहीं और भेजना है।
Critical cases: safety, privacy और hand-off के नियम जो हर बार पास होने ही चाहिए।
पिछली failures: आप जो भी prompt defect ठीक करें, वह एक case बन जाता है।

# support-set v7: 3 of its 40 cases
- id: DEL-004
  input: "متى يصل طلبي رقم 5521؟"
  vars: { order_status: shipped }
  checks: [valid_json, language_is_ar, mentions_order_5521]
- id: CMP-002
  input: "मेरी केतली टूटी हुई आई है"
  checks: [valid_json, language_is_hi, handoff_is_true]
  critical: true
- id: OOS-001
  input: "Can you book me a flight to Riyadh?"
  checks: [valid_json, declines_politely, no_invented_service]

आज़माएँ: JSON Lines वैलिडेटर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर आज़माएँ: Unicode डेटासेट जनरेटर

Prompts का versioning

जो prompt बिना किसी record के अपनी जगह पर edit हो सकता है, जैसे किसी admin screen में, उसे भरोसे से टेस्ट नहीं किया जा सकता: कोई नहीं बता सकता कि किस text ने कौन-सा जवाब दिया। हर prompt को version control में file के रूप में रखें, review से बदलें, और हर released version को एक identifier दें जिसे application हर response के साथ log करे।

हर accepted version को उन हालात के साथ दर्ज करें जिनमें वह टेस्ट हुआ: model identifier, parameters, test set version, तारीख़ और नतीजे। Provider का model update या नया temperature नई configuration है जिसे नया run चाहिए, भले ही prompt का text न बदला हो।

हर version में एक बदलाव, वजह के साथ: "v4: जवाब 60 शब्दों से कम रखें; ग्राहकों को जवाब लंबे लगे"।
Accepted version को उसी जगह edit न करें; अगला version बनाएँ, ताकि rollback बस पिछले identifier पर लौटना हो।
टेस्ट से पहले दोनों versions का diff देखें, ताकि पता हो कि कौन-से निर्देश बदले और किन cases पर असर पड़ना चाहिए।

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

Prompt regression: baseline से case-by-case तुलना

Prompt regression वह case है जो accepted version के साथ pass होता था और नए version के साथ fail होता है। इसे पकड़ने के लिए candidate की तुलना baseline से करें — यानी उसी test set, model और parameters पर आख़िरी accepted version के सहेजे गए नतीजे। सिर्फ़ accepted version के नतीजे ही नई baseline बनते हैं। सिर्फ़ prompt बदलें; अगर model भी बदला, तो आप नहीं बता पाएँगे कि फ़र्क़ किस बदलाव से आया।

हर case चलाएँ। जिस समस्या को ठीक करने के लिए बदलाव किया गया है, उसकी वजह से fail हुए cases दोबारा चलाना confirmation testing है; बाक़ी सभी cases दोबारा चलाना regression testing है, और आपको दोनों चाहिए। हर case को पहले से तय pass rule के साथ कई बार चलाएँ, फिर उसे चार में से एक group में रखें:

Fixed: baseline के साथ fail, अब pass — यही इच्छित सुधार है।
Regressed: पहले pass, अब fail। Critical case का regression बदलाव को रोक देता है; बाक़ी हर regression की जाँच और team की साफ़ स्वीकृति ज़रूरी है।
Still failing: दोनों में fail — जानी-पहचानी समस्या जो इस बदलाव से नहीं आई।
Unchanged pass: दोनों में pass। फिर भी कुछ outputs साथ-साथ पढ़ें; checks पास होते हुए भी tone या content खिसक सकता है।

Prompt का बदलाव तभी accept होता है जब पूरा test set उसी model पर चले और हर case की baseline से तुलना हो; critical case का fail होना या team द्वारा अस्वीकार किया गया regression prompt को सुधार के लिए वापस भेजता है।

1Prompt बदलेंएक बदलाव, नया version identifier और उसकी वजहsupport-reply v4
2बाक़ी सब स्थिर रखेंवही test set version, pinned model, वही parameters
3पूरा test set चलाएँहर case, हर एक के कई runs, पहले से तय pass rulesupport-set v7
4Baseline से तुलना करेंCase-by-case: fixed, regressed, still failing, unchanged pass
शाखा: Critical case fail या कोई regression स्वीकार नहीं: prompt सुधारें और पूरा set दोबारा चलाएँफ़ेल
गेट: कोई critical failure नहीं; हर regression समझा और स्वीकार किया गया
5Version accept करें और tag करेंउसके नतीजे नई baseline बनते हैं; हर response के साथ version log होता हैपास

इसके बाद:अगले बदलाव की तुलना इसी baseline से होती है

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

Worked example: छोटा जवाब जिसने दो cases तोड़ दिए

Support assistant के prompt का version v3 baseline है। ग्राहकों को उसके जवाब लंबे लगे, इसलिए v4 जोड़ता है: "हर जवाब 60 शब्दों से कम रखें।" दोनों versions support-set v7 (40 cases) पर उसी pinned model के साथ चलते हैं, हर case के 5 runs; case तब pass होता है जब उसके सारे checks कम से कम 4 runs में पास हों, और critical cases पाँचों runs में।

Pass होने वाले cases 34 से बढ़कर 37 हो जाते हैं — सुधार जैसा दिखता है। Case-by-case देखें तो verbosity के पाँच cases ठीक हुए, लेकिन RET-012 अब 30 दिन में return की शर्त छोड़ देता है, और critical case CMP-002 5 में से 2 runs में टूटे सामान की शिकायत किसी इंसान को नहीं सौंपता; RET-012 के दोनों जवाबों का text diff गायब वाक्य दिखाता है। Critical case का regression v4 को रोक देता है। Team v5 लिखती है — "हर जवाब 60 शब्दों से कम रखें, लेकिन policy की शर्तें हमेशा बताएँ और hand-off कभी न छोड़ें" — और पूरा set दोबारा चलाती है।

Prompt: support-reply   Baseline: v3   Candidate: v4   Model: pinned, unchanged
Test set: support-set v7 (40 cases), 5 runs per case
Pass rule: all checks pass in >= 4 of 5 runs; critical cases need 5 of 5
n/5 = number of runs in which all checks passed

Case      Group       v3 (baseline)   v4 (candidate)   Result
LEN-002   verbosity   fail 1/5        pass 5/5         fixed
LEN-005   verbosity   fail 2/5        pass 5/5         fixed
          (3 more verbosity cases fixed the same way)
RET-012   returns     pass 5/5        fail 2/5         regressed
CMP-002   critical    pass 5/5        fail 3/5         regressed: blocks v4
LNG-004   language    fail 3/5        fail 3/5         still failing (known)
          (32 other cases pass with both versions)

Passing cases         34 / 40         37 / 40

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

आम गलतियाँ

Production prompt को सीधे edit करना, बिना नए version और बिना test run के।
सिर्फ़ उन examples से टेस्ट करना जो prompt लिखते समय इस्तेमाल हुए, या उसे उन्हीं cases पर accept करना जिन पर वह tune हुआ।
कुल pass rate बढ़ने पर बदलाव accept कर लेना, यह देखे बिना कि कौन-से cases अब fail होते हैं।
Prompt और model या उसके parameters एक साथ बदलना, जिससे फ़र्क़ की वजह trace न हो सके।
सिर्फ़ वे cases दोबारा चलाना जिन्हें बदलाव ठीक करने वाला था: regression testing के बिना confirmation testing।
Non-deterministic case को एक run से परखना, या prompt version, model और input के बिना defect दर्ज करना।

QA का नज़रिया

Prompt ship होने से पहले जुड़ें: उसे requirement की तरह review करें (क्या हर निर्देश testable है, क्या कोई निर्देश टकराते हैं, scope के बाहर क्या होता है?), और नतीजे देखने से पहले developer और product owner के साथ pass rule और critical cases तय कर लें, ताकि कोई numbers के हिसाब से goalposts न खिसकाए।

Test set domain जानने वालों के साथ बनाएँ; support staff जानता है कि ग्राहक असल में क्या पूछते हैं। हर बदलाव के लिए दर्ज करें: baseline और candidate versions, model, parameters, test set version, हर case के runs, case-by-case नतीजे और फ़ैसला। Defect report में prompt version, model identifier, exact input और output, और failure कितनी बार होता है ("5 में से 3 runs"), ये सब होने चाहिए।

अभ्यास

तय करें कि prompt का बदलाव release हो सकता है या नहीं

आपका काम

एक meeting-notes assistant meetings के transcripts का summary बनाता है। उसके prompt का version v3 action items समझना आसान बनाने के लिए नीचे दिखाया गया निर्देश जोड़ता है। Table उसी pinned model पर baseline v2 और candidate v3 के test set नतीजे दिखाती है।

हर case को classify करें, तय करें कि v3 accept हो सकता है या नहीं, और बताएँ कि आगे क्या होगा।

सामग्री

Prompt: meeting-summary   Baseline: v2   Candidate: v3   Model: pinned, unchanged
Change in v3: "List every action item as: owner - task - due date."
Test set: meetings v2 (12 cases), 5 runs per case
Pass rule: all checks pass in >= 4 of 5 runs; critical cases need 5 of 5
n/5 = number of runs in which all checks passed

Case    Critical  Check                                         v2    v3
MS-01   no        summary is at most 120 words                  5/5   5/5
MS-02   no        every action item names an owner              2/5   5/5
MS-03   no        every action item has a due date              1/5   4/5
MS-04   yes       no salary figure from the HR transcript       5/5   4/5
MS-05   no        an Arabic meeting is summarised in Arabic     5/5   3/5
MS-06   no        no action items invented when none agreed     5/5   2/5
MS-07 to MS-12    all checks                                    5/5   5/5

चरण

दोनों versions में हर case पर pass rule लागू करें और pass होने वाले cases गिनें।
हर case को एक group में रखें: fixed, regressed, still failing या unchanged pass।
तय करें कि v3 accept होगा या नहीं, और क्यों।
एक fix सुझाएँ, और एक test case जो set में नहीं है।

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

मॉडल उत्तर

v2 12 में से 10 पास करता है (MS-02 और MS-03 fail); v3 12 में से 9 पास करता है (MS-04, MS-05 और MS-06 fail)।

Fixed: MS-02 और MS-03 (दूसरा सिर्फ़ threshold पर, 5 में से 4, इसलिए उस पर नज़र रखें)। Regressed: MS-04, MS-05 और MS-06। Unchanged pass: MS-01 और MS-07 से MS-12 तक। कोई case still failing नहीं है।

v3 reject करें। MS-04 critical है और उसे 5 में से 5 चाहिए, इसलिए salary का आँकड़ा दोहराने वाला एक run अकेले ही release रोक देता है — यह privacy defect है, जिसे उस run के output के साथ report करें। MS-05 और MS-06 format निर्देश का आम side effect दिखाते हैं: model template तब भी भरता है जब नहीं भरना चाहिए और action items गढ़ देता है, और template के अंग्रेज़ी labels शायद अरबी summary को अंग्रेज़ी की ओर खींचते हैं — यह वजह outputs पढ़कर पक्की करें।

साफ़ exceptions के साथ v4 लिखें ("अगर किसी action item पर सहमति नहीं हुई, तो लिखें: कोई action item नहीं। Meeting की भाषा इस्तेमाल करें।") और एक साफ़ नियम जोड़ें कि salary के आँकड़े या HR की दूसरी निजी जानकारी किसी summary में न आए, फिर पूरा set दोबारा चलाएँ; v4 तभी accept हो सकता है जब MS-04 5 में से 5 runs में pass हो। एक missing case: बिना due date के तय हुआ action item, जिसका expected result "due date: तय नहीं" है, कोई गढ़ी हुई तारीख़ नहीं।

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

क्या prompt testing और prompt engineering एक ही हैं?

नहीं। Prompt engineering prompt लिखना और सुधारना है; prompt testing यह सबूत जुटाना है कि कोई ख़ास version तय मानदंड पूरे करता है और जो पहले काम करता था उसे नहीं तोड़ता। एक ही व्यक्ति दोनों कर सकता है, लेकिन prompt को उन cases पर accept नहीं करना चाहिए जिन पर उसे tune किया गया।

Prompt test set में कितने cases चाहिए?

कोई तय संख्या नहीं है। ऐसे cases से शुरू करें जो हर निर्देश, सबसे ज़्यादा आने वाले असली requests, critical नियमों और पहले देखी गई failures को cover करें, फिर हर नई failure मिलने पर एक case जोड़ें। व्यावहारिक सीमा हर बदलाव पर हर case को कई बार चलाने का समय और खर्च है।

अगर सिर्फ़ model बदला है तो क्या test set दोबारा चलाना होगा?

हाँ। Model, उसका version और parameters टेस्ट हो रही configuration का हिस्सा हैं, इसलिए वही prompt text model update के बाद अलग व्यवहार कर सकता है। Model version pin करें, और provider के update को ऐसा बदलाव मानें जिसके लिए baseline के विरुद्ध पूरा run चाहिए।

क्या कोई language model मेरे test inputs लिख सकता है?

वह variations का draft बना सकता है — paraphrases, typos, दूसरी भाषाएँ — और इससे समय बचता है। लेकिन हर generated input को set में जाने से पहले review करें और checks ख़ुद लिखें। अगर कोई model जवाबों को grade भी करता है, तो टेस्ट हो रहे model से अलग model इस्तेमाल करें और एक sample पर उसके grades की तुलना human review से करें।

संदर्भ

Define success criteria and build evaluationsAnthropicएक मॉडल प्रदाता की गाइडेंस: मापने योग्य success criteria और ऐसे evaluation सेट लिखना जिन्हें कोड, exact match या मॉडल ग्रेड करे।
Working with evalsOpenAIएक मॉडल प्रदाता की गाइडेंस: मॉडल आउटपुट को तय मानदंड और डेटासेट से टेस्ट करना, और prompt व मॉडल बदलने पर evals दोबारा चलाना।
ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।

टूल्स

और गहराई से

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

इस topic से पहले

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

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

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

असल में टेस्ट क्या हो रहा है

Inputs का test set बनाना

Prompts का versioning

Prompt regression: baseline से case-by-case तुलना

Worked example: छोटा जवाब जिसने दो cases तोड़ दिए

आम गलतियाँ

QA का नज़रिया

अभ्यास

तय करें कि prompt का बदलाव release हो सकता है या नहीं

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

संदर्भ

Mutqan tools से अभ्यास करें

टेक्स्ट डिफ़

JSON Lines वैलिडेटर

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

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

JSON डिफ़

JSON Schema वैलिडेटर

और गहराई से

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

इस topic से पहले

अगले topics

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

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

असल में टेस्ट क्या हो रहा है

Inputs का test set बनाना

Prompts का versioning

Prompt regression: baseline से case-by-case तुलना

Worked example: छोटा जवाब जिसने दो cases तोड़ दिए

आम गलतियाँ

QA का नज़रिया

अभ्यास

तय करें कि prompt का बदलाव release हो सकता है या नहीं

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

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

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

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

इस topic से पहले

अगले topics

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