Playground में prompts और model settings

prompt वह text है जो आप model को भेजते हैं ताकि user के message के साथ क्या करना है यह साफ हो। model settings—जैसे temperature, top_p, और max_tokens—तय करती हैं कि जवाब कितना लंबा होगा और हर बार कितना बदलेगा। दोनों मिलकर एक सवाल का जवाब देते हैं: क्या यह assistant उस तरह चलेगा जैसा आपके product को code जोड़ने से पहले चाहिए?

अवधारणा 4 में model deploy कर endpoint से कॉल करना दिखाया गया। यह अवधारणा Microsoft Foundry portal में रहती है और model playground (और जब ज़रूरत पड़े तब agents playground) में व्यवहार ठीक करने पर केंद्रित है। prompt के शब्द और settings यहीं सुधारें ताकि token इस्तेमाल और जवाब की गुणवत्ता app या agent में deployment चलाने पर करीब रहे।

Microsoft Foundry playgrounds तुरंत चलने वाले chat वातावरण हैं—तेज़ prototyping, API देखने और तकनीकी जाँच के लिए। आपको Azure subscription, Foundry resource, और कम से कम एक deployed model चाहिए। Microsoft Foundry portal में model deploy करते ही आप उसके playground पर पहुँच जाते हैं, इसलिए अलग project या SDK के बिना भी prompt परीक्षण शुरू हो सकता है।

• एक deployment सेट करते समय, multilingual samples export करते समय, या latency और tokens मापते समय model playground लें।
• जब idea को memory, knowledge, या कई tool calls चाहिए तो agents playground लें।
• Foundry model के हिसाब से modality चुनता है—उदाहरण: gpt-image-1 के लिए images playground, Sora-2 के लिए video playground (preview)।
• Chat pane के Code tab से Open in VS Code for the Web आपका sample, endpoint, और key browser workspace में ले जाता है।

Compare models mode एक ही prompt को एक साथ तीन deployments पर चलाता है। हर model को वही prompt context, system message, और parameter configuration मिलती है; जवाब एक साथ stream होते हैं ताकि latency, token throughput, और गुणवत्ता देख सकें। गहरे integration से पहले कौन सा model कीमत और प्रदर्शन के लिए ठीक है, यह जल्दी पता चलता है।

• Deployed model का playground खोलें और upper-right corner में Compare models चुनें।
• मौजूदा या नए deployments से दो models और चुनें; जुड़े prompt bars के साथ chat panes खुलते हैं।
• किसी भी bar में prompt लिखें; sync चालू हो तो दूसरों में भी दिखेगा। अलग settings चाहिए तो Setup pane से उस model का sync बंद करें।
• Prompt भेजें और हर model का जवाब एक साथ पढ़ें।
• पसंदीदा model पर Code tab से multilingual samples देखें, या Save as agent से agents playground में आगे बढ़ें।
• Tools section चाहिए तो पहले compare mode बंद करें—comparison panes खुले रहने पर tools single-model view में ही मिलते हैं।

Compare चलाने को नियंत्रित परीक्षण समझें: system message स्थिर रखें, एक समय में एक setting या एक model बदलें, और token इस्तेमाल नोट करें क्योंकि अवधारणा 4 का deployment type पहले से token की लागत तय कर चुका होता है।

Chat-based calls में messages के roles होते हैं—system, user, assistant। system message सबसे ऊपर की instruction है: assistant की भूमिका और सीमा, लहजा, output format, और जानकारी न हो तो क्या करना है। system message model को प्रभावित करता है, पर हर नियम मानने की गारंटी नहीं; realistic और कठिन inputs से परीक्षण ज़रूरी है।

• पहले सादी भाषा में काम बताएँ—एक सामान्य सफल request से क्या निकलना चाहिए।
• वे विषय या actions लिखें जिन्हें assistant को मना करना है या जिनसे बचना है।
• App को fixed shape चाहिए तो output contract साफ लिखें (जैसे JSON keys) और छोटा व स्थिर रखें।
• अनिश्चितता की policy जोड़ें: स्पष्ट सवाल पूछें, न पता हो तो कहें, या दायरे से बाहर मना करें।
• निर्देश स्पष्ट रखें; परस्पर विरोधी नियम न दें—जैसे छोटा जवाब और पूरा विवरण—बिना यह बताए कि कौन जीतता है।

User messages में task और primary content होता है। Few-shot examples—system message के बाद sample user और assistant turns—बिना model बदले pattern दिखाते हैं। क्रम महत्वपूर्ण है क्योंकि model हाल का text ज़्यादा महत्व दे सकता है; लंबे content के बाद ज़रूरी निर्देश दोहराना कभी मदद करता है। Prompt में साफ separators और headings parsing आसान बनाते हैं।

Microsoft की prompt engineering techniques article में कुछ patterns reasoning models जैसे gpt-5 और o-series models के लिए सलाह नहीं हैं। उन models पर उनकी अपनी reasoning पर भरोसा करें और जवाब जाँचें; साधारण chat models वाली step-by-step युक्तियों पर निर्भर न रहें।

Model playground वे parameters दिखाता है जो हर जवाब को आकार देते हैं। Temperature 0 से 2 के बीच सेट हो सकता है। ऊँचा मान (जैसे 0.7) शब्दों को ज़्यादा बदलता और अलग बनाता है; नीचा (जैसे 0.2) जवाब केंद्रित और ठोस रखता है—जब रचनात्मक बदलाव नहीं, एक जैसी भाषा चाहिए। Top_p (top probability) randomness को दूसरे तरीके से नियंत्रित करता है। Microsoft की सलाह: temperature या top_p में से एक समय में एक बदलें, दोनों एक साथ नहीं, फिर नतीजे compare करें।

• लंबा system message context window भरता है—max tokens बढ़ाने से पहले अतिरिक्त वाक्य काटें।
• एक model view में Tools खोलें, Add चुनें, फिर Code interpreter; model समर्थन करे तो code files जोड़कर sandbox में code चलता है।

जब app को model का जवाब code से पढ़ना हो, सादा text parsing मुश्किल बनाता है। Structured outputs model को आपके JSON Schema पर चलाते हैं जो inference call का हिस्सा होता है। पुराने JSON mode में valid JSON मिलता था, पर schema पर सख्त पालन guaranteed नहीं था। Structured outputs field निकालने, strict function calling, और multi-step workflows के लिए उपयोगी हैं जहाँ हर step को ज्ञात keys चाहिए।

• Chat Completions में schema response_format में; Responses API में text.format में define करें।
• Playground में पहले system message में output contract लिखें; व्यवहार स्थिर हो तो वही shape code में ले जाएँ।
• Function calling में structured outputs के साथ strict mode चालू करें; parallel_tool_calls false रखें क्योंकि parallel function calls के साथ structured outputs supported नहीं।
• SDK response में refusal देखें—model गलत JSON की बजाय request अस्वीकार कर सकता है।

Schema छोटा रखें: सिर्फ़ required keys, स्थिर नाम, और वे extra fields न जो code न पढ़े। Production parsing से पहले playground में edge cases (खाली input, ambiguous नाम) परीक्षण करें।

उदाहरण: एक online shop returns assistant बनाता है, मौजूदा gpt-5-mini deployment पर। टीम छोटा system message लिखती है—दायरा (returns और shipping), लहजा (विनम्र, संक्षिप्त), अनिश्चितता पर नियम (order number माँगें)। दो few-shot user और assistant pairs स्वीकृत refund wording दिखाते हैं, policy भाषा के लिए temperature नीची रखते हैं, और order_id, issue, next_step fields के साथ structured output चालू करते हैं। Code tab से export से पहले compare mode में दूसरे deployment के मुकाबले दस real chat transcripts चलाते हैं।

• सोचना कि system message अकेले सुरक्षा लागू कर देगा—playground में guardrails और बाद में evaluation (अवधारणा 8) जोड़ें।
• Temperature और top_p एक साथ बदलना ताकि पता न चले किस बदलाव से फायदा हुआ।
• Compare mode खुला छोड़कर Tools न मिलने पर हैरान होना—पहले extra model panes बंद करें।
• gpt-5 या o-series models पर वे elaborate prompt patterns जिनके लिए Microsoft सरल prompting सलाह देता है।
• Agents playground evaluations के लिए भुगतान जब ज़रूरत न हो—ये default चालू हैं और consumption-based billing में शामिल; upper-right में metrics खोलकर evaluators unselect करें।

अवधारणा 6 knowledge जोड़ती है—files और Azure AI Search—ताकि जवाब catalog cite करें, अनुमान न लगाएँ। Playground में prompts और settings ठीक हो जाएँ तो agents playground में grounded knowledge और tools जोड़ें।

• Playground types, compare mode, tools, और troubleshooting: Microsoft Foundry playgrounds
• System message की भूमिका, सीमाएँ, और design checklist: System message design
• Few-shot learning, temperature, top_p, और ordering tips: Prompt engineering techniques
• Chat Completions और Responses API में JSON Schema: Structured outputs