पथ 01पाठ 6 / 6

प्रमाण के आधार पर मॉडल चुनें

प्रतिनिधि कामों, acceptance criteria, लागत और team की संचालन संबंधी सीमाओं पर मॉडल की तुलना करें।

व्यावहारिक10 minसमीक्षा की गई 5 अक्टू॰ 2026

अपनी समझ जाँचेंModel A अधिक public benchmark tasks pass करता है। Model B आपकी repository के प्रतिनिधि कामों में बेहतर है। निर्णय किस परिणाम के आधार पर लेना चाहिए?अभ्यास करें

यह जाँचने के बाद repository evaluation के आधार पर कि उसके काम और quality criteria इच्छित उपयोग का प्रतिनिधित्व करते हैं।Public benchmark के आधार पर, क्योंकि अधिक score हमेशा बेहतर software बताता है।जो मॉडल सबसे छोटा उत्तर देता है।

उत्तर दिखाएँ

Evaluation निष्पक्ष और प्रतिनिधि हो तो स्थानीय प्रमाण उपयोगी है। Public benchmarks अतिरिक्त context देते हैं, इस आकलन की जगह नहीं लेते।

आप क्या सीखेंगे

वास्तविक प्रकार के कामों से छोटा evaluation set बनाएँ।
मॉडल की गुणवत्ता को tools और context के असर से अलग करें।
वे स्थितियाँ दर्ज करें जिनमें नया evaluation जरूरी होगा।

निर्णय का दायरा तय करें

मॉडल की तुलना के लिए स्पष्ट उपयोग चाहिए। छोटा function अच्छी तरह समझाने वाला मॉडल बड़ी repository में बदलाव उतनी अच्छी तरह नहीं कर पाए। कम लागत वाला मॉडल नियमित transformations के लिए जरूरी गुणवत्ता दे सकता है। कठिन जाँच के लिए अधिक reasoning क्षमता जरूरी हो सकती है।

पहले काम और सीमाएँ लिखें। स्वीकार्य डेटा, जरूरी tools, response time और अधिकतम स्वीकार्य लागत शामिल करें। कुछ सीमाएँ अनिवार्य हैं। किसी दूसरे score के अधिक होने पर डेटा के उपयोग की पाबंदी को औसत निकालकर अनदेखा न करें।

प्रतिनिधि काम इस्तेमाल करें

अपनी team के वास्तविक कामों से छोटा evaluation set बनाएँ। Evaluation environment संवेदनशील डेटा के लिए स्वीकृत न हो, तो वह डेटा हटा दें। सरल काम, कठिन काम और ऐसे काम शामिल करें जिनमें सही प्रतिक्रिया छूटी जानकारी माँगना हो।

काल्पनिक reporting service के लिए तारीख का ज्ञात दोष, छोटा filter feature और authorization rule की व्याख्या इस्तेमाल करें। तुलना शुरू करने से पहले अपेक्षित परिणाम तैयार करें। ज्ञात दोष को अस्वीकार करने वाला negative test शामिल करें।

कुछ काम prompt development से अलग रखें। हर उदाहरण पर prompt बार-बार सुधारेंगे, तो अंतिम score सामान्य performance को बढ़ा-चढ़ाकर दिखा सकता है। अलग set से पता चलता है कि बेहतर prompt, उसे बनाने में इस्तेमाल उदाहरणों के बाहर भी काम करता है या नहीं।

तुलना निष्पक्ष रखें

सटीक model version, prompt, दिया गया context, tools और permissions दर्ज करें। समान शुरुआती स्थितियाँ इस्तेमाल करें। एक मॉडल को पूरी repository और दूसरे को एक file मिले, तो परिणाम models के साथ workflows की भी तुलना करता है।

Workflow की तुलना उपयोगी हो सकती है। उसे सही नाम दें। Agent product में मॉडल के अलावा भी बहुत कुछ होता है: context का चयन, tools, execution limits और recovery का व्यवहार परिणाम पर असर डाल सकते हैं।

Output का बदलना मायने रखता हो तो कई runs करें। केवल सबसे अच्छा परिणाम बताने के बजाय असफल प्रयास भी दर्ज करें। व्यक्तिपरक criteria के लिए लिखित मूल्यांकन नियम और जहाँ संभव हो, एक से अधिक reviewer इस्तेमाल करें।

गति से पहले गुणवत्ता जाँचें

पहले अनिवार्य acceptance criteria जाँचें। क्या बदलाव requirement पूरी करता है? क्या access controls बने रहते हैं? क्या संबंधित tests pass होते हैं? क्या reviewer diff समझ सकता है?

फिर स्वीकार्य परिणामों के लिए प्रयास, कुल बीता समय और लागत की तुलना करें। Retries और human review शामिल करें। बार-बार सुधार माँगने वाला सस्ता उत्तर पूरे काम के स्तर पर महँगा हो सकता है।

Evaluation का पहलू	क्या दर्ज करें
काम का परिणाम	कौन-से acceptance criteria पूरे हुए और कौन-से नहीं
दायरा	बिना माँगे बदलाव या छूटी requirements
मानवीय प्रयास	तैयारी, review और सुधार का समय
Execution की लागत	Retries समेत model और tool की लागत
प्रमाण	Version, input, output, checks और reviewer के notes

Public benchmarks संभावित मॉडल पहचानने में मदद कर सकते हैं। वे खास task sets और scoring तरीकों का उपयोग करते हैं। Benchmark score को आपकी team की productivity का सीधा माप न मानें।

निर्णय और उसे दोबारा जाँचने की स्थितियाँ दर्ज करें

परिणाम सीमित सुझाव हो सकता है। उदाहरण: “मौजूदा review requirements के साथ इस repository में छोटे test additions के लिए यह मॉडल इस्तेमाल करें।” हर काम के लिए एक ही मॉडल जरूरी नहीं है।

बताएँ कि किन बदलावों पर नया evaluation होगा। उदाहरण हैं model version बदलना, tool configuration बदलना, डेटा की नई category या लगातार एक प्रकार की विफलता। चुने मॉडल की क्षमता से बाहर के कामों के लिए वैकल्पिक तरीका रखें।

Evaluation का उद्देश्य वास्तविक निर्णय की अनिश्चितता घटाना है। ऐसी स्थायी model competition से बचें जिसमें उस काम से अधिक प्रयास लगे जिसकी वह मदद करती है।

अभ्यास करें

तीन प्रकार के कामों के लिए evaluation sheet बनाएँ: ज्ञात दोष, छोटा feature और repository की व्याख्या। मॉडल की तुलना से पहले acceptance criteria तय करें। हर काम में एक failure case शामिल करें। Model version, context, tool permissions, प्रयास, लागत और review में लगा प्रयास दर्ज करें।

Worksheet डाउनलोड करें (Markdown)

अपनी समझ जाँचें ↑