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

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

Large language model (LLM) को बहुत बड़ी मात्रा में text पर अगला token predict करने के लिए train किया जाता है, और फिर instructions मानने के लिए आगे train किया जाता है। Application उसे एक request भेजता है जिसमें instructions, अब तक की बातचीत और अक्सर उन tools का विवरण होता है जिन्हें वह इस्तेमाल कर सकता है। Model जवाब एक-एक token करके लिखता है, हर token संभावित continuations में से चुना जाता है, जब तक वह रुक न जाए या किसी length limit तक न पहुँचे।

उदाहरण: एक online store के support assistant को message मिलता है "मेरा order 5521 कहाँ है?"। Application system prompt, message और get_order_status tool की definition भेजता है। Model ख़ुद कुछ नहीं ढूँढता: वह order number के साथ tool call करने की request लौटाता है। Application lookup चलाता है, result जोड़कर दूसरी request भेजता है, और तभी model वह जवाब लिखता है जो customer देखता है।

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

हर mechanism defects का स्रोत है। Sampling से एक ही input अलग-अलग जवाब देता है; context window तय करती है कि model क्या देखेगा; output limits जवाब काट देती हैं; system prompt text है, लागू किया गया नियम नहीं; और tool call generated text को action में बदल देता है। जो tester यह नहीं जानता, वह या तो exact-match tests लिखता है जो बेतरतीब fail होते हैं, या "AI ऐसा ही है" मानकर असली defects निकल जाने देता है।

ये बुनियादी बातें जानकर आप अंदाज़ा लगा सकते हैं कि LLM feature कहाँ टूटेगा, वहाँ के लिए tests design कर सकते हैं और ऐसी bug reports लिख सकते हैं जिन्हें developer reproduce कर सके। Model अब भी test के अधीन एक component है, और QA की हर बुनियादी बात लागू रहती है।

Tokens और context window

Tokenizer पूरे text को tokens में बाँटता है: आम words, लंबे words के हिस्से, numbers के टुकड़े, punctuation। अलग-अलग model families के tokenizers अलग होते हैं, इसलिए एक ही text अलग models पर अलग count दे सकता है, और Arabic या Hindi वाक्य English से ज़्यादा tokens ले सकता है। Limits और cost tokens में गिने जाते हैं, और generate होने वाले tokens के साथ response time भी बढ़ता है, इसलिए characters से अंदाज़ा लगाने की बजाय provider का token counter या API की बताई usage इस्तेमाल करें।

Context window tokens की वह अधिकतम संख्या है जिसे model एक request में संभाल सकता है, आम तौर पर input और output मिलाकर। Model स्थिति के बारे में जो कुछ जानता है, सब इसमें समाना चाहिए: system prompt, tool definitions, बातचीत, retrieve किए गए documents, tool results और जवाब की जगह। Model requests के बीच कुछ याद नहीं रखता; chat सिर्फ़ इसलिए याद रखती लगती है क्योंकि पिछले messages हर request के साथ दोबारा भेजे जाते हैं, आम तौर पर application द्वारा।

बातचीत window से बड़ी होने पर application उसे trim या summarise करता है, वरना request fail होती है, और शुरुआत का कोई instruction या order number खो सकता है। Maximum output tokens एक अलग limit है: उस तक पहुँचा जवाब कट जाता है, अक्सर वाक्य के बीच में, और response का stop reason यह बताता है। दोनों limits boundaries हैं, इसलिए उन पर boundary value analysis लगाएँ, लंबे Arabic और Hindi inputs के साथ भी; generate किया गया filler text और String Length Counter से उसका माप input को क़दम-दर-क़दम बढ़ाने में मदद करते हैं।

Illustrative split (every tokenizer differs):
  "Where is my order 5521?"  ->  Where| is| my| order| 55|21|?   (7 tokens)

Context budget for one request (example model with a 16,000-token window)
  System prompt                            1,200
  Tool definitions (3 tools)                 900
  Conversation so far (18 messages)       11,500
  New customer message                       400
  Reserved for the answer (max output)     2,000
  Total                                   16,000   <- window full

आज़माएँ: स्ट्रिंग लेंथ काउंटर आज़माएँ: Lorem Ipsum जनरेटर

अगला token कैसे चुना जाता है: temperature और sampling

हर step पर model अपनी vocabulary के हर token को अगला होने की probability देता है। हमेशा सबसे probable token लेना greedy decoding है; कई applications sample करते हैं, यानी probabilities के अनुपात में random चुनते हैं, इसलिए जवाब हर run में बदलते हैं।

Temperature इन probabilities को rescale करता है: 1 से कम पर सबसे संभावित token को बढ़त मिलती है, 1 से ज़्यादा पर कम संभावित tokens को ज़्यादा मौक़े मिलते हैं। Top-p (nucleus sampling) सबसे संभावित tokens का वह सबसे छोटा समूह रखता है जिनकी probabilities का जोड़ कम से कम p हो; top-k सिर्फ़ k सबसे संभावित tokens रखता है। हर model हर parameter स्वीकार नहीं करता, इसलिए असल में भेजी गई values record करें।

नीचे के उदाहरण में store की policy 30 दिन है, फिर भी temperature 1.0 पर लगभग चार में से एक run में और 2.0 पर दस में से चार runs में गलत number चुना जाता है, और लंबे जवाब में ऐसे सैकड़ों चुनाव होते हैं। कम temperature variation घटाता है, पर व्यवहार में एक जैसा output गारंटी नहीं करता। Production settings पर टेस्ट करें, अहम cases कई बार चलाएँ और runs की तुलना करें, जैसे Text Diff से।

Context: "... unused items can be returned within"   (illustrative probabilities;
assume these four candidates hold all the probability)

Next token       temperature 0.5   temperature 1.0   temperature 2.0
" 30"                      91.5%             70.0%             48.6%
" 14"                       7.5%             20.0%             26.0%
" 7"                        0.9%              7.0%             15.4%
" thirty"                   0.2%              3.0%             10.1%

Wrong number (14 or 7)      8.4%             27.0%             41.3%

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

System prompts और tool use

Request roles वाले messages की एक list है। System prompt (कुछ providers इसे system या developer message कहते हैं) application के instructions रखता है: role, नियम, scope, भाषा और format। Models इसे प्राथमिकता देने के लिए train किए जाते हैं, पर यह लागू किया गया नियम नहीं है: यह user के input के साथ उसी context में मौजूद text है। Model इसे मानने में चूक सकता है, user का text या कोई document इसे override करने की कोशिश कर सकता है (prompt injection, OWASP Top 10 for LLM Applications में LLM01:2025), और यह leak हो सकता है (System Prompt Leakage, LLM07:2025)। Secrets इससे बाहर रखें, और permissions, prices व limits code में लागू करें।

Tool use, यानी function calling, में application हर tool को नाम, description और arguments के JSON Schema से describe करता है: यह एक document है जो बताता है कि arguments में कौन-से fields, types और values हो सकते हैं, और ख़ुद JSON में लिखा होता है, यानी named fields और values वाला वह plain-text format, जैसे {"order_id": "5521"}, जिसे ज़्यादातर web APIs आपस में भेजते-लेते हैं। Model कभी कुछ नहीं चलाता: वह अपने generate किए arguments के साथ tool call की structured request लौटाता है, और application उन्हें validate करके tool चलाता है और result नई request में वापस भेजता है। Generated arguments को untrusted input मानें; वे malformed हो सकते हैं, या valid होकर भी गलत, जैसे ऐसा order number जो customer ने कभी दिया ही नहीं। JSON Schema Validator logged arguments को schema से जाँचता है। जो tools कुछ बदलते हैं, वहीं excessive agency (LLM06:2025) गलत जवाब को गलत action में बदल देती है।

एक LLM request शुरू से आख़िर तक: application context तैयार करता है, model जवाब एक-एक sampled token करके लिखता है, और tool call के बाद application tool चलाकर उसका result नई request में वापस भेजता है। वैचारिक मॉडल

1Request तैयार करेंSystem prompt, tool definitions, अब तक की बातचीत, नया message, parameters
2Tokens में बाँटेंLimits और cost tokens में गिने जाते हैं
शाखा: बहुत लंबा: application trim या summarise करता है या request fail होती है; टेस्ट करें कि क्या खोयासावधानी
गेट: Context window में समाता है
3हर संभावित अगले token को probability देंModel की training और context के tokens के आधार पर
4एक token चुनेंTemperature और top-p तय करते हैं कि चुनाव सबसे संभावित token से कितना दूर जा सकता है
दोहराता है: Model के रुकने या output limit तक token-दर-token दोहराएँ
5Output लौटाएँText या tool call, stop reason और token usage के साथ
शाखा: Output limit पर रुका: जवाब कटा हुआ हैसावधानी
6Application action लेता हैजवाब दिखाता है, या tool arguments validate करके tool चलाता है

चरण 1 पर वापस Tool result बातचीत में जुड़ता है: नई request

सरलीकृत: providers field names, limits और tokens गिनने के तरीक़े में अलग होते हैं।

Request 1 (simplified and provider-neutral; field names differ by provider)
  model: example-model-v3    temperature: 0.7    max output tokens: 500
  system: "You are the support assistant of an online store. Answer in the
           customer's language. Hand every refund request to a human agent."
  tools: get_order_status(order_id: a string of 4 to 10 digits)
  messages: user: "Where is my order 5521?"

Response 1   stop reason: tool call
             get_order_status({"order_id": "5521"})
Application  validates the argument, runs the lookup, adds the result:
             {"order_id": "5521", "status": "shipped", "eta": "2026-10-08"}
Request 2    the same context plus the tool call and its result
Response 2   stop reason: end of turn
             "Your order 5521 has shipped and should arrive on 8 October."

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

आम failure modes

ज़्यादातर LLM defects कुछ ही families में आते हैं, और हर एक ऊपर के किसी mechanism से जुड़ा है; mechanism का नाम लेने से fix और regression test दोनों का पता चलता है।

Hallucination: fluent, आत्मविश्वास भरा पर गलत या बिना आधार का content, जैसे गढ़ी हुई policy या order status (NIST AI 600-1 इसे confabulation कहता है)। Model संभावित text बनाता है, जाँचे हुए तथ्य नहीं, इसलिए ऐसे सवाल टेस्ट करें जिनका जवाब उपलब्ध नहीं, और "मुझे नहीं पता" या hand-off की अपेक्षा रखें।
Instruction drift: गलत भाषा, गलत format या scope से बाहर की सलाह, अक्सर लंबी बातचीत के आख़िर में। जायज़ request ठुकराना भी failure है।
Inconsistency: एक ही input एक run में approve और दूसरे में refuse होता है; जिस फ़ैसले को स्थिर रहना चाहिए, उसमें यह पलटना ही defect है।
Truncation और lost context: output limit पर कटा जवाब और अधूरा JSON, या history trim होने के बाद ग़ायब हुई जानकारी।
Malformed structured output: invalid JSON, ग़ायब या extra fields, या JSON के आसपास prose, जो parser को तोड़ देता है।
Tool-use errors: गलत या छूटा हुआ tool call, गढ़े हुए arguments, tool error को गढ़े हुए result से ढकना, loops, या ज़रूरी confirmation के बिना action।
Injection और leakage: user, किसी page या document का text instructions को override करता है या system prompt निकाल लेता है; LLM security testing guide इनके सुरक्षित tests बताती है।

Worked example: एक गलत जवाब को उसके कारण तक ट्रेस करना

एक customer शिकायत करता है कि support assistant ने उसके दूसरे order के "कल" पहुँचने का वादा किया, जबकि वह ship ही नहीं हुआ था। "Bot तारीख़ें गढ़ता है" report करने की बजाय tester उस turn की logged request वैसे पढ़ता है जैसे वह असल में भेजी गई थी।

यह message 31 है, "और दूसरा order?", और response में कोई tool call नहीं है। Order number message 3 में दिया गया था, पर application सिर्फ़ आख़िरी 20 messages रखता है, इसलिए model के पास ज़रूरी order_id argument की value नहीं थी, और पूछने की बजाय उसने भरोसेमंद लगने वाला जवाब लिख दिया। Temperature 0.7 पर logged request पाँच बार भेजने से चार बार गढ़ी हुई तारीख़ आई और एक बार order number पूछा गया।

Bug report: model और prompt version, parameters, trim के बाद की request, stop reason, "5 में से 4 runs में गढ़ी हुई तारीख़", और cause: trimming ने order number हटा दिया और prompt में उसके न होने का कोई नियम नहीं है।
नए tests: 30 messages की बातचीत जिसमें order number सिर्फ़ message 3 में है, और बिना किसी order number वाला सवाल। हर run में expected: assistant order lookup करता है या number पूछता है, और tool result के बिना कभी तारीख़ नहीं बताता।
Team के लिए सवाल: क्या order numbers जैसी अहम जानकारी history trimming के बाद भी context में रहनी चाहिए?

आम गलतियाँ

यह मान लेना कि temperature 0 एक जैसा output गारंटी करता है, या production से अलग sampling settings पर टेस्ट करना।
एक run से case को परखना; जो case 5 में से 3 runs में pass होता है, वह स्थिर रहने वाले फ़ैसले के लिए defect है।
System prompt को security control या secrets और permission rules की सुरक्षित जगह मानना।
सिर्फ़ छोटी बातचीत और छोटे inputs टेस्ट करना, जिससे context window, history trimming और output limit तक कभी नहीं पहुँचा जाता, ख़ासकर Arabic या Hindi में।
Tool arguments और structured output पर इसलिए भरोसा करना कि model ने उन्हें बनाया, बजाय उन्हें untrusted input की तरह validate करने के।
हर गलत जवाब को "hallucination" कह देना और mechanism न ढूँढना, जिससे fix और regression test दोनों अस्पष्ट रह जाते हैं।

QA का नज़रिया

किसी LLM feature के tests design करने से पहले उसकी request anatomy माँगें: model और क्या उसका version pinned है, sampling parameters और output limit, system prompt version, tools और उनमें से किनके side effects हैं, और history trimming का नियम। हर item को test के अधीन configuration मानें: उसका कोई भी बदलाव regression risk है। Product owner के साथ तय करें कि कौन-से व्यवहार हर run में स्थिर रहने चाहिए, जैसे medical advice से इनकार, और किनकी wording बदल सकती है।

Developers से कहें कि हर response model और prompt version, parameters, भेजी गई request, stop reason और token usage के साथ log हो, बिना ऐसे personal data के जिसकी logs को ज़रूरत नहीं, ताकि आपकी bug reports बता सकें कि क्या दोबारा भेजना है और वह कितनी बार fail होता है। ये बुनियादी बातें आपके QA toolkit में जुड़ती हैं; requirements review, risk analysis, boundary values और regression testing अब भी ज़्यादातर काम करते हैं।

अभ्यास

Booking assistant के चार logged failures का निदान करें

आपका काम

एक clinic का appointment assistant दो tools से visits book करता है; उसका configuration और चार logged समस्याएँ नीचे हैं। हर log के लिए failure mode और सबसे संभावित mechanism बताएँ, और एक test case लिखें जिसका expected result हर स्वीकार्य जवाब को पूरा करना हो।

फिर लिखें कि bug reports में क्या-क्या होना चाहिए। काग़ज़ और पेन काफ़ी हैं।

सामग्री

Assistant: clinic appointments      Model: example-model-v3 (pinned)
Parameters: temperature 0.9, max output tokens 150
System prompt v5: "Reply in the patient's language. Offer free slots with
  find_slots(date). Book with book_appointment(slot_id) only after the patient
  confirms a slot. Never give medical advice."

Log 1  user: "Is 10:30 tomorrow free?"
       tool call: find_slots(date: "2026-11-12")
       tool result: [{"slot_id": "S-1201", "time": "09:00"},
                     {"slot_id": "S-1202", "time": "11:15"}]
       reply: "Yes, 10:30 tomorrow is free."
Log 2  user: "Book me with Dr Salem on Sunday."
       tool call: book_appointment(slot_id: "S-0912")  (no find_slots, no confirmation)
Log 3  "Can I eat before my blood test?" sent 5 times:
       3 replies refer the patient to the clinic, 2 replies give advice
Log 4  user writes in Arabic     stop reason: max output tokens (150 of 150 used)
       reply: {"message": "...a long confirmation in Arabic...", "slot": "11:15",
               "status": "confir

चरण

हर वह setting नोट करें जो मायने रख सकती है: parameters, limits और tool rules।
हर log के लिए failure mode और mechanism बताएँ।
हर log के लिए एक test case लिखें: input, runs की संख्या, expected result।
हर bug report के लिए ज़रूरी तथ्य लिखें।

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

मॉडल उत्तर

Log 1, hallucination: जवाब tool result के उलट है, जिसमें 10:30 है ही नहीं। Test: ऐसा समय पूछें जो result में नहीं है, 5 runs। हर run में expected: "ख़ाली नहीं", और सिर्फ़ tool result वाले समय (09:00, 11:15)।

Log 2, excessive agency के साथ tool-use error: find_slots call नहीं, confirmation नहीं, और S-0912 किसी tool result से नहीं आया। Test: "मुझे रविवार को book करें", 5 runs। हर run में expected: find_slots से मिले slots सुझाए जाते हैं और patient के confirm करने से पहले कुछ book नहीं होता। Application test भी जोड़ें: code ऐसे slot के लिए book_appointment reject करता है जो किसी find_slots call ने नहीं लौटाया, क्योंकि अकेला prompt rule कुछ लागू नहीं करता।

Log 3, policy वाले फ़ैसले में inconsistency, जिसकी संभावना temperature 0.9 ने बढ़ाई; सलाह देने वाला हर जवाब "Never give medical advice" नियम भी तोड़ता है (instruction drift)। यह defect है, flakiness नहीं। Test: production settings पर सवाल 10 बार। Expected: 10 में से 10 जवाब patient को clinic की ओर भेजते हैं। पूछें कि booking assistant को इतना ऊँचा temperature क्यों चाहिए।

Log 4, truncation: लंबे Arabic message ने पूरे 150 output tokens ले लिए, इसलिए parser को अधूरा JSON मिलता है; इस जवाब के लिए 150 कम हैं। Tests: सबसे लंबा अपेक्षित जवाब, Arabic में भी, 5 runs: हर run सामान्य stop reason के साथ ख़त्म होता है और अपना JSON Schema pass करता है; और stop reason output limit होने पर application parse करने की बजाय error दिखाता है या retry करता है।

हर bug report में चाहिए: model और prompt version (v5), parameters, भेजी गई पूरी request, tool calls और results, stop reason, token usage, और कितने runs में से कितने fail हुए।

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

क्या token और word एक ही हैं?

नहीं। Token model के tokenizer की एक इकाई है: कोई आम word, लंबे word का हिस्सा, punctuation mark या word से जुड़ा space। किसी text के कितने tokens बनेंगे, यह tokenizer और भाषा पर निर्भर है। सटीक गिनती के लिए provider का token counter या हर response के साथ API की लौटाई token usage इस्तेमाल करें।

अगर मैं temperature 0 कर दूँ, तो क्या outputs की हूबहू तुलना कर सकता हूँ?

सुरक्षित रूप से नहीं। कम temperature variation घटाता है, पर व्यवहार में calls के बीच एक जैसा output गारंटी नहीं करता, और production में अलग setting हो सकती है। हूबहू तुलना सिर्फ़ उसकी करें जो output format तय करता है, जैसे कोई label या JSON field, और बाक़ी के लिए properties जाँचें, जैसा LLM testing guide समझाती है।

क्या model मेरी test बातचीत से सीखता है?

Request के दौरान नहीं: जवाब देते समय model के weights, यानी training में सीखी गई संख्याएँ, नहीं बदलते, और वह सिर्फ़ context में मौजूद चीज़ें इस्तेमाल करता है। Provider भेजे गए data को बाद की training में इस्तेमाल कर सकता है या नहीं, यह उसकी terms और आपके contract पर निर्भर है, इसलिए उन्हें जाँचें और test prompts में कभी असली personal data न डालें।

क्या मुझे समझना होगा कि model अंदर से कैसे काम करता है?

नहीं। Tester को interface पर व्यवहार समझना होता है: context में क्या जाता है, output कैसे generate और सीमित होता है, और tools कैसे call होते हैं। Internal architecture जानना मदद कर सकता है, पर LLM application को अच्छी तरह टेस्ट करने के लिए ज़रूरी नहीं।

संदर्भ

Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026AI-आधारित सिस्टम की टेस्टिंग पर ISTQB का specialist पाठ्यक्रम, machine learning और generative AI सिस्टम सहित।
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 और संवेदनशील जानकारी के खुलासे से शुरू।
Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI)ISTQBपूरी टेस्ट प्रक्रिया में बड़े भाषा मॉडल के उपयोग पर ISTQB का पाठ्यक्रम — AI सिस्टम को टेस्ट करने की उलटी दिशा।

टूल्स

और गहराई से

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

इस topic से पहले

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

अगले topics

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

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

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

Tokens और context window

अगला token कैसे चुना जाता है: temperature और sampling

System prompts और tool use

आम failure modes

Worked example: एक गलत जवाब को उसके कारण तक ट्रेस करना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Booking assistant के चार logged failures का निदान करें

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

संदर्भ

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

स्ट्रिंग लेंथ काउंटर

Lorem Ipsum जनरेटर

टेक्स्ट डिफ़

JSON Schema वैलिडेटर

और गहराई से

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

इस topic से पहले

अगले topics

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

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

Tokens और context window

अगला token कैसे चुना जाता है: temperature और sampling

System prompts और tool use

आम failure modes

Worked example: एक गलत जवाब को उसके कारण तक ट्रेस करना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Booking assistant के चार logged failures का निदान करें

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

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