अवधारणा 8 / 16 · 9 मिनट पढ़ने का समय

गुणवत्ता नापें और सुधारें

स्पष्ट evaluators के साथ basic evaluation चलाएँ, Prompt Optimizer से instructions सुधारें, और हर बदलाव नापने के लिए baseline रखें।

नमस्ते, मैं एलेक्स हूँ, आपका लेख-वाचक। मैं इस लेख में आपका मार्गदर्शन कर सकता हूँ, ताकि आप मेरे साथ सुनते हुए इसे समझ सकें।

अनुमान से बेहतर है नाप

Evaluation से आप model या agent की गुणवत्ता, सुरक्षा और भरोसेमंदता को बनाते समय और live होने के बाद नाप सकते हैं। Microsoft Foundry में आप test dataset में पड़े जवाब score कर सकते हैं, test input पर model या agent से नए जवाब चला कर score कर सकते हैं, या production traces से पकड़ी गई बातचीत score कर सकते हैं। एक evaluation उस data पर एक या ज़्यादा evaluators लगाता है। Evaluators metrics देते हैं और जहाँ समर्थित हो, छोटी व्याख्या भी, ताकि आप versions की तुलना कर सकें, कमज़ोर जगहें देख सकें और तय कर सकें कि agent deploy के लिए तैयार है या नहीं।

Concept 7 में prompt agent में tool और knowledge जोड़ना देखा। यह अवधारणा अगला सवाल उत्तर देती है: agent सच में ग्राहकों की मदद करता है या सिर्फ अच्छा लगता है? Playground की बातचीत छोटा नमूना होती है। Evaluation "ठीक लग रहा है" को ऐसे अंकों में बदलती है जिन्हें हर बदलाव पर दोहराया जा सकता है।

  • सेव किए query–response जोड़े score करें, model को दोबारा कॉल किए बिना।
  • Test input से नए response बनाएँ, फिर score करें।
  • Production traces खींचकर असली बातचीत या turn score करें।
  • Deploy से पहले multi-turn व्यवहार simulate करें जब लिखित scenarios चाहिए हों।

चार चरणों वाला evaluation workflow

Foundry में ज़्यादातर evaluation workflows एक ही तरह चलते हैं। पहले तय करें कि व्यवहार का कौन सा हिस्सा मायने रखता है, फिर उस लक्ष्य से मेल खाने वाले metrics चुनें, job चलाएँ, फिर नतीजों पर काम करें। आप development में एक बार चला सकते हैं, deployment pipeline में जोड़ सकते हैं, या production traffic पर बार-बार evaluation तब सेट कर सकते हैं जब monitoring का स्तर तैयार हो।

  • तय करें क्या evaluate करना है: एक turn, पूरी बातचीत, मौजूदा dataset, generate किए response, simulated बातचीत, या production traces।
  • Evaluators चुनें: task completion, relevance, groundedness, similarity, content safety जैसे quality और safety metrics।
  • Evaluation चलाएँ: development में माँग पर, continuous integration में, या live agent पर schedule पर।
  • देखें और सुधारें: कुल metrics और अलग-अलग failures पढ़ें, versions की तुलना करें, बार-बार fail होने वाले patterns ठीक करें।

पहली run से पहले evaluation workflows की अनुमति, कौन से region और rate limit लागू हैं, और virtual network की ज़रूरतें documentation में देख लें। इनमें कमी अक्सर खराब score नहीं, बल्कि बटन बंद या job fail के रूप में दिखती है।

Evaluation unit और evaluators चुनें

Evaluators चुनने से पहले evaluation unit चुनें। Turn-level evaluation एक समय पर एक response score करता है। यह एक जवाब, एक step पर tool choice, या query–response dataset की एक row ठीक करने के लिए सही है। Conversation-level evaluation पूरी multi-turn बातचीत score करता है और कई steps में फैले नतीजे नाप सकता है, जैसे booking पूरी होना। हर evaluator कुछ levels पर ही चलता है, इसलिए एक turn पर काम करने वाला metric पूरी thread पर लागू नहीं हो सकता।

Turn-level बनाम conversation-level evaluation
सवालTurn-levelConversation-level
क्या score होता हैएक agent response (या एक model completion)शुरू से अंत तक पूरी बातचीत
कब उपयोगीशब्द, grounding, या एक tool call ठीक कर रहे होंकाम्यता के लिए कई steps, hand-off, या follow-up चाहिए
Metric उदाहरणएक जवाब पर relevance या groundednessपूरे thread पर task completion या customer satisfaction
किस data की ज़रूरतQuery और response columns (RAG test में context के साथ)Multi-turn dataset के लिए chat format में message history

Built-in evaluators से शुरू करें, या अपना rubric चाहिए तो custom evaluator बनाएँ। अक्सर दिखने वाले quality नामों में task completion, relevance, groundedness, similarity शामिल हैं, और जहाँ individual-turn scope लागू हो content safety checks भी। वही set चुनें जो आपके app में "अच्छा" का मतलब बताता है, सूची के हर checkbox को नहीं।

Prompt Optimizer से instructions जल्दी सुधारें

Microsoft Foundry portal का Prompt Optimizer agent की system instructions को prompt-engineering practices से फिर लिखता है। यह text को साफ और व्यवस्थित करता है, हर बदले paragraph के लिए reasoning दिखाता है, और सुझाव जोड़कर दोबारा optimize करने देता है जब तक आप संतुष्ट न हों। स्वीकार करने पर एक क्लिक से परिणाम लागू हो सकता है।

  • Microsoft Foundry में साइन इन करें और New Foundry toggle चालू रखें।
  • Build > Agents पर जाएँ और जिस agent को सुधारना है उसे खोलें।
  • Agent configuration panel में Instructions section खोलें।
  • Instructions header के बगल वाले pencil with sparkle icon से Prompt Optimizer dialog खोलें।
  • उद्देश्य या वैकल्पिक suggestion लिखें, Optimize चुनें, बैंगनी highlight वाले बदलाव देखें, फिर Use prompt से text Instructions में कॉपी करें।

Prompt Optimizer सिर्फ text instructions पर काम करता है। Tool definitions या knowledge sources नहीं बदलता। Use prompt चुने बिना dialog बंद करने पर परिणाम सेव नहीं होते, और optimizer version history नहीं रखता—पलटना हो तो पुरानी instructions पहले कॉपी कर लें। Feature तभी मिलता है जब Foundry project supported region में host हो; दूसरे region में Optimize control दिखता ही नहीं। बदलाव लागू करने के बाद playground में test करें, फिर अपने dataset पर पूरी evaluation चलाएँ कि rewrite आपके cases में मदद करता है, सिर्फ generic best practices में नहीं।

Dataset के साथ optimization wizard से सुधार

असली tasks पर सबूत चाहिए तो prompt agent के Optimize tab पर optimization wizard इस्तेमाल करें। Agent optimizer चुने agent version को evaluate करता है, candidates नाम के वैकल्पिक configuration बनाता है, उन्हें उसी dataset और evaluators से score करता है, और baseline से rank करता है। Prompt agent के लिए यह instructions, function-calling tool descriptions, और model selection सुधार सकता है। Tool-description optimization में दूसरे tool types समर्थित नहीं। Function-calling tools client side चलते हैं, इसलिए optimizer call guide करने वाले descriptions refine कर सकता है लेकिन tool-description optimization के दौरान tools execute नहीं कर सकता।

  • Project खोलें, Agents चुनें, prompt agent चुनें, Optimize tab पर Create optimization run चुनें।
  • Target step: baseline agent version, optimization model, maximum candidates, evaluation model चुनें; चाहें तो Compare across models चालू करें।
  • Dataset step: agent traces से बनाएँ, registered dataset चुनें, या JSONL upload करें; columns evaluators की ज़रूरत से मेल खाते हैं यह पुष्टि करें क्योंकि wizard columns map नहीं करता।
  • Criteria step: built-in evaluators, मौजूदा custom evaluator, या नया custom rubric evaluator चुनें।
  • Review step: settings जाँचें, estimated cost range (modeled, spending cap नहीं) पढ़ें, Submit चुनें, run पूरा होने पर scores की तुलना करें।
Prompt Optimizer बनाम optimization wizard
Prompt Optimizer (playground)Optimization wizard (Optimize tab)
सबसे अच्छा कबAgent edit करते समय instructions जल्दी rewriteDataset पर scored candidates के साथ नापा हुआ फायदा
आप क्या देते हैंउद्देश्य text और वैकल्पिक suggestionsBaseline version, dataset, evaluators, models
OutputDialog में revised instructionsRanked candidates; एक को नए agent version में promote
सबूतParagraph-wise reasoning; आप manually testउसी data पर composite scores और per-evaluator breakdown

उदाहरण: ऑनलाइन दुकान का support assistant

कल्पना करें एक prompt agent जो छोटी ऑनलाइन दुकान के order status और return policy सवालों का जवाब देता है। Concept 6 में policy PDF से file search और Concept 7 में order ID से lookup करने वाला function-calling tool जोड़ चुके हैं। आप चाहते हैं return policy सही बताए और valid ID मिलने पर ही order lookup हो।

  • JSONL dataset बनाएँ: सामान्य status check, missing order ID, गुस्सैला tone, और off-topic बात जिसे refuse करवाना है।
  • Policy जवाबों पर relevance और groundedness, order rows पर tool selection और tool call success जैसे agent evaluators के साथ turn-level evaluation चलाएँ।
  • Baseline scores नोट करें, फिर Prompt Optimizer में "off-topic refuse करो और lookup से पहले order ID माँगो" जैसा suggestion दें।
  • Playground में test करें, फिर उसी dataset पर task completion और groundedness criteria के साथ optimization wizard run शुरू करें।
  • अगर candidate ज़रूरी metrics पर baseline से आगे है और token usage स्वीकार्य है तो Promote candidate से नया agent version बनाएँ; नहीं तो baseline रखें और dataset या evaluators ठीक करें।

अगर हर candidate baseline से कम score करे तो docs कहते हैं मौजूदा agent रखें और दोबारा run से पहले dataset, evaluators, या optimization settings बदलें। Playground में सुंदर prompt तब तक जीत नहीं जब तक आपके काम के tasks पर अंक न बढ़ें।

Baseline, scores, और बचने योग्य गलतियाँ

जिस version से शुरू किया उसे baseline मानें। हर महत्वपूर्ण बदलाव के बाद वही evaluation चलाएँ और कुल aggregates plus fail rows की तुलना करें। Agent optimizer composite score 0.0 से 1.0 के बीच निकालता है: हर evaluator का raw score rescale, lower-is-better metric flip, फिर evaluators और tasks पर average। सबसे ऊँचा score वाले candidate पर star लगता है, फिर भी promote करना आप तय करते हैं।

Composite score बदलाव कैसे पढ़ें (agent optimizer)
Baseline से बदलावकैसे मानें
0.03 से कमशोर, मायने का फायदा नहीं
0.03 से 0.10मध्यम सुधार; व्यवहार ठीक लगे तो deploy पर विचार
0.10 से 0.20काफी सुधार
0.20 से ज़्यादाबड़ी छलांग; अक्सर कमज़ोर baseline का संकेत
  • लक्ष्य से मेल न खाने वाले evaluators छोड़कर सिर्फ fluency ऊँचा लाना जब task completion स्थिर रहे।
  • छोटा या unrealistic dataset पर भरोसा करना जो live shoppers को न दिखाए।
  • Use prompt चुने बिना Prompt Optimizer बंद करना और rewrite खो देना।
  • Scores बेहतर लेकिन token usage बहुत ज़्यादा candidate promote करना, completed run की Token usage view देखे बिना।
  • ऐसे dataset पर optimization चलाना जो असली external API calls trigger करे; charge या production data बदले तो test endpoint या mock इस्तेमाल करें।

आगे क्या करें

अब आपके पास loop है: अच्छा परिभाषित करें, evaluators से नापें, Prompt Optimizer या optimization wizard से instructions सुधारें, और scores साबित करने तक baseline रखें। Concept 9 architecture और rollout पर है—projects, deployments, environments कैसे जुड़ते हैं ताकि validate किया version playground में न रहकर ship हो सके।

मध्यम स्तर की क्विज़ दें

मध्यम स्तर की अवधारणाओं में आपने क्या सीखा, यह जाँचें। पास होने के लिए 80% अंक चाहिए।

हर पाठ के स्रोत इसके अंत में दिए गए हैं: Microsoft Foundry के साथ Up-Skill।