TATECHATLAS
◎ हिन्दी
कृत्रिम बुद्धिमत्ता / सुझाव

मॉडलों की तुलना करने से पहले मूल्यांकन सेट और तुलना के नियमों को ठीक करें

प्रयोग चलाने से पहले मूल्यांकन सेट, मेट्रिक्स, एकत्रीकरण (aggregation) और तुलना के नियमों को निश्चित करें ताकि परिणाम तुलनीय रहें और एक एकल संख्या द्वारा उपसमुच्चय (subset) की विफलता न छिपे।

इस पृष्ठ पर

एक एकल अंतिम मीट्रिक प्रयोग को एक संख्या में समेट देता है और यह छिपा देता है कि मॉडल कहाँ जीतता है या हारता है। प्रयोग चलाने से पहले मूल्यांकन सेट, मीट्रिक्स, एकत्रीकरण क्रम और तुलना के नियमों को निर्धारित कर लें। सेट में स्प्लिट्स, उपसमुच्चय (subsets), वेट्स, मीट्रिक दिशाएं और एकत्रीकरण विधि का उल्लेख होना चाहिए। नियमों में यह स्पष्ट होना चाहिए कि मॉडलों की तुलना समान स्प्लिट्स पर की जाएगी, प्रत्येक उपसमुच्चय को अलग से रिपोर्ट किया जाएगा, और कुल योग (aggregate) एक भारित औसत (weighted average) होगा। यह परिणामों को विभिन्न रन और लेखकों के बीच पुनरुत्पादनीय (reproducible) बनाता है। Hugging Face Evaluate लाइब्रेरी और scikit-learn स्कोरिंग API दोनों इस वर्कफ़्लो का समर्थन करते हैं। Evaluate आपको मीट्रिक्स लोड करने और उन्हें लगातार गणना करने की अनुमति देता है, जबकि scikit-learn का स्कोरिंग पैरामीटर मॉडल चयन के लिए मूल्यांकन नियम परिभाषित करता है। मुख्य बात यह है कि इन विनिर्देशों (spec) को किसी फ़ाइल या कॉन्फ़िगरेशन में रिकॉर्ड करें ताकि समान इनपुट हमेशा समान आउटपुट दे सकें। इसके बिना, एक मॉडल बेहतर दिखाई दे सकता है क्योंकि कुल योग एक महत्वपूर्ण उपसमुच्चय पर विफलता को छिपा देता है। उदाहरण में दो क्लासिफायर हैं जिनकी सटीकता (accuracy) 0.91 बनाम 0.89 है, लेकिन उपसमुच्चय B पर रिकॉल (recall) 0.78 से गिरकर 0.62 हो जाता है। यदि केवल कुल योग की रिपोर्ट दी जाती है, तो यह नुकसान अदृश्य रहता है। विनिर्देश तय होने पर, रिपोर्ट कुल योग और प्रति-उपसमुच्चय विवरण दोनों दिखाती है, जिससे तुलना पारदर्शी और बचाव योग्य हो जाती है।

संदर्भ और सिफारिश

किसी भी मॉडल की तुलना करने से पहले मूल्यांकन सेट को निश्चित किया जाना चाहिए। इसका अर्थ है स्प्लिट्स, उपसमुच्चय, वेट्स, मेट्रिक्स और उनकी दिशाओं को किसी फ़ाइल या कॉन्फ़िगरेशन में रिकॉर्ड करना। Hugging Face Evaluate लाइब्रेरी मीट्रिक्स लोड करने और उन्हें लगातार गणना करने के लिए उपकरण प्रदान करती है, जबकि scikit-learn का स्कोरिंग पैरामीटर मॉडल चयन के लिए मूल्यांकन नियम परिभाषित करता है। जब नियम लिखित रूप में होते हैं, तो दोनों पुनरुत्पादनीय मूल्यांकन का समर्थन करते हैं। सिफारिश यह है कि एक मूल्यांकन विनिर्देश (evaluation specification) बनाएं जो सटीक रूप से बताए कि किन उदाहरणों का उपयोग किया जाता है, किन मेट्रिक्स की गणना की जाती है, और परिणामों को कैसे एकत्रित किया जाता है। इसके बिना, दो रन या दो लेखक अलग-अलग संख्याएँ उत्पन्न कर सकते हैं जो तुलनीय नहीं होती हैं। विनिर्देश में एकत्रीकरण का क्रम शामिल होना चाहिए, जैसे कि उपसमुच्चयों पर भारित औसत, और यह नियम कि मॉडलों की तुलना समान स्प्लिट्स पर की जाएगी। यह प्रीप्रोसेसिंग या डेटा क्रम में अनजाने बदलावों से निष्कर्ष बदलने से रोकता है। लक्ष्य प्रयोग को पुनरुत्पादनीय और तुलना को पारदर्शी बनाना है।

मूल्यांकन विनिर्देश को YAML या JSON जैसी फ़ाइल में संग्रहीत किया जाना चाहिए ताकि इसे संस्करणित और पुन: उपयोग किया जा सके। फ़ाइल में स्प्लिट्स, उपसमुच्चय, वेट्स, मेट्रिक्स और तुलना के नियम सूचीबद्ध होने चाहिए। उदाहरण के लिए, एक वर्गीकरण प्रयोग में दो उपसमुच्चय, A और B, 0.6 और 0.4 वेट के साथ, और दो मेट्रिक्स, सटीकता और रिकॉल, दोनों को अधिकतम करने वाले उपयोग किए जा सकते हैं। तुलना का नियम बताता है कि समान स्प्लिट्स का उपयोग किया जाता है, प्रत्येक उपसमुच्चय को अलग से रिपोर्ट किया जाता है, और कुल योग एक भारित औसत है। यह फ़ाइल प्रयोग के लिए सत्य का एकल स्रोत बन जाती है। जब दो मॉडलों को चलाया जाता है, तो दोनों एक ही विनिर्देश को पढ़ते हैं, इसलिए परिणाम सीधे तुलनीय होते हैं। रिपोर्ट में प्रति-उपसमुच्चय स्कोर और कुल योग दोनों शामिल होने चाहिए, न कि केवल कुल योग। इस तरह, औसत पर जीतने वाले मॉडल को एक महत्वपूर्ण उपसमुच्चय पर हारते हुए देखा जा सकता है। विनिर्देश मेट्रिक दिशाओं को भी रिकॉर्ड करता है, जैसे कि सटीकता और रिकॉल को अधिकतम करना, ताकि एकत्रीकरण सार्थक हो।

Hugging Face Evaluate लाइब्रेरी और scikit-learn स्कोरिंग API इस वर्कफ़्लो के लिए व्यावहारिक उपकरण हैं। Evaluate डेटासेट पर लगातार तरीके से मेट्रिक्स लोड करने और गणना करने की अनुमति देता है। scikit-learn का स्कोरिंग पैरामीटर क्रॉस-वैलिडेशन और पैरामीटर सर्च के लिए मॉडल मूल्यांकन नियम परिभाषित करता है। दोनों लाइब्रेरी इस विचार का समर्थन करती हैं कि मूल्यांकन नियमों का एक सेट है, न कि केवल एक एकल संख्या। मुख्य बात नियमों को एक फ़ाइल या कॉन्फ़िगरेशन में रिकॉर्ड करना है ताकि समान इनपुट हमेशा समान आउटपुट दे सकें। यह विशेष रूप से तब महत्वपूर्ण होता है जब कई लेखक या कई रन शामिल होते हैं। विनिर्देश को टीम के साथ साझा किया जाना चाहिए और अंतिम रिपोर्ट के आधार के रूप में उपयोग किया जाना चाहिए। रिपोर्ट में कच्चे प्रति-उपसमुच्चय नंबर, कुल योग, और तुलना के नियम दिखाए जाने चाहिए। यह प्रयोग को ऑडिट करने योग्य और निष्कर्षों को बचाव योग्य बनाता है।

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

तर्क और ट्रेड-ऑफ

एक एकल अंतिम मीट्रिक रैंकिंग को सरल बनाता है लेकिन उपसमूहों, क्षितिज और त्रुटि प्रकारों में त्रुटियों के वितरण को छिपा देता है।

ट्रेड-ऑफ स्पष्ट है: नियमों को रिकॉर्ड करने के लिए शुरुआत में अतिरिक्त प्रयास की आवश्यकता होती है, लेकिन एक एकल कुल योग रैंकिंग को उलट सकता है जब एक महत्वपूर्ण उपसमुच्चय पर विचार किया जाता है। एक विनिर्देश फ़ाइल लिखने में मिनट लगते हैं; तैनाती के बाद यह पता लगाना कि एक मॉडल अल्पसंख्यक उपसमूह पर विफल हो जाता है, हफ्तों लेता है। लागत विषमता विनिर्देश के पक्ष में है।

उदाहरण में, मॉडल X की सटीकता 0.91 है और मॉडल Y की सटीकता 0.89 है। उपसमुच्चय B पर, रिकॉल मॉडल Y के लिए 0.78 से गिरकर मॉडल X के लिए 0.62 हो जाता है। यदि कुल योग उपसमुच्चयों A और B पर 0.6 और 0.4 के भार के साथ सटीकता का भारित औसत है, तो मॉडल X कुल मिलाकर 0.91 स्कोर करता है जबकि मॉडल Y 0.89 स्कोर करता है। कुल योग का अंतर केवल 0.02 है, फिर भी उपसमुच्चय B पर रिकॉल का अंतर 0.16 है, एक ऐसा उलटफेर जिसे एकल संख्या छिपा देती है।

निश्चित विनिर्देश रिपोर्ट को कुल योग और प्रति-उपसमुच्चय विवरण दोनों को सामने लाने के लिए मजबूर करता है। विनिर्देश के बिना, एक विश्लेषक उच्च कुल योग के आधार पर मॉडल X को चुन सकता है और उपसमुच्चय B पर रिकॉल की विफलता को मिस कर सकता है। विनिर्देश के साथ, तुलना पारदर्शी है और विफलता तैनाती से पहले दिखाई देती है।

# Evaluation spec used for model comparison
spec = {
    "splits": ["train", "validation", "test"],
    "subsets": {"A": 0.6, "B": 0.4},
    "metrics": {"accuracy": "maximize", "recall": "maximize"},
    "aggregate": "weighted_average"
}

# Example: compare two models on the same splits with per-subset reporting
# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# The aggregate alone hides the subset B failure for Model X

# The same spec is used for both models so the comparison is fair
# Report per-subset scores and the weighted aggregate
# This prevents a high aggregate from hiding a low score on a critical subset

ठोस उदाहरण

दो क्लासिफायर पर विचार करें जिन्हें दो उपसमुच्चय (subsets) में विभाजित डेटासेट पर मूल्यांकित किया गया है: उपसमुच्चय A (60 प्रतिशत उदाहरण) और उपसमुच्चय B (40 प्रतिशत उदाहरण)। मॉडल X, A पर 0.91 और B पर 0.90 की सटीकता (accuracy) प्राप्त करता है। मॉडल Y, A पर 0.88 और B पर 0.90 की सटीकता प्राप्त करता है। मॉडल X के लिए भारित कुल सटीकता (weighted aggregate accuracy) 0.6 * 0.91 + 0.4 * 0.90 = 0.906 है, और मॉडल Y के लिए 0.6 * 0.88 + 0.4 * 0.90 = 0.888 है। कुल योग (aggregate) पर मॉडल X 0.018 से आगे है।

अब विशेष रूप से उपसमुच्चय B पर रिकॉल (recall) का परीक्षण करें। मॉडल X का B पर रिकॉल 0.62 है जबकि मॉडल Y का B पर रिकॉल 0.78 है। यह अंतर 0.16 है, जो कुल सटीकता के 0.018 के अंतर से कहीं अधिक बड़ा है। यदि उपसमुच्चय B एक महत्वपूर्ण अल्पसंख्यक समूह का प्रतिनिधित्व करता है जहाँ मिस किए गए पॉजिटिव्स की लागत बहुत अधिक है, तो मॉडल X का स्पष्ट लाभ भ्रामक है।

निश्चित विनिर्देश (spec) यह बताता है कि उपसमुच्चय B पर रिकॉल को अलग से रिपोर्ट किया जाना चाहिए और तुलना नियम के लिए प्रति-उपसमुच्चय दृश्यता (per-subset visibility) आवश्यक है। जब विनिर्देश से रिपोर्ट तैयार की जाती है, तो कुल योग और प्रति-उपसमुच्चय रिकॉल दोनों अगल-बगल दिखाई देते हैं। पाठक देख सकता है कि मॉडल X कुल सटीकता में जीतता है लेकिन उपसमुच्चय B के रिकॉल में बुरी तरह हार जाता है, और वह केवल एक संख्या पर भरोसा करने के बजाय एक सूचित निर्णय ले सकता है।

यह उदाहरण दिखाता है कि परिचालन रूप से विनिर्देश क्यों महत्वपूर्ण है। इसके बिना, विश्लेषक केवल एक सटीकता संख्या की गणना करता है, 0.91 बनाम 0.89 देखता है, और मॉडल X को चुन लेता है। इसके साथ, उसी विश्लेषक को विवरण दिखाना आवश्यक होता है, और उपसमुच्चय B पर रिकॉल की विफलता को अनदेखा करना असंभव हो जाता है।

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# Aggregate alone hides the subset B failure for Model X
# The report must show per-subset scores and the weighted aggregate

अनुप्रयोग की सीमाएं

यह दृष्टिकोण हाइपरपैरामीटर ट्यून करते समय अलग से अंतिम टेस्ट सेट की जगह नहीं लेता है। यह अपने आप में सांख्यिकीय महत्व (statistical significance) प्रदान नहीं करता है; छोटे या शोर वाले अंतरों के लिए औपचारिक परीक्षण की आवश्यकता होती है। परिणाम केवल तभी तुलनीय रहते हैं जब मूल्यांकन सेट और नियम अपरिवर्तित रहें, क्योंकि स्प्लिट्स या वेट्स बदलने के लिए नए तुलना की आवश्यकता होती है। यह डेटा प्रकार के आधार पर क्रॉस-वैलिडेशन या क्रोनोलॉजिकल स्प्लिट्स जैसी वैलिडेशन रणनीति चुनने की आवश्यकता को भी समाप्त नहीं करता है। यह विधि मानती है कि कई उपसमुच्चय या मेट्रिक्स मौजूद हैं और निर्णय मॉडल तुलना पर आधारित है। यह गारंटी नहीं दे सकता कि एक भारित कुल योग सही व्यावसायिक उद्देश्य है, और यह युग्मित एनकोडर और स्वतंत्र संदर्भ लेबल के बिना एम्बेडिंग स्पेस को संरेखित नहीं करता है या प्रासंगिकता का आधार सत्य (ground truth) स्थापित नहीं करता है।

यह दृष्टिकोण तब सबसे उपयोगी होता है जब मूल्यांकन सेट में अलग-अलग परिचालन लागत वाले विशिष्ट उपसमूह शामिल होते हैं, जब कई लेखक या टीमों को परिणामों को दोहराना होता है, और जब निर्णय सीमा (decision threshold) इतनी करीब होती है कि एक एकल संख्या रैंकिंग को बदल सकती है।

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

उपयोग की शर्तें

  • क्या मूल्यांकन विनिर्देश किसी भी मॉडल को चलाने से पहले प्रत्येक स्प्लिट, उपसमुच्चय, वेट और मीट्रिक दिशा को सूचीबद्ध करता है?
  • क्या मॉडलों की तुलना करते समय दोनों के लिए समान स्प्लिट और प्रीप्रोसेसिंग का उपयोग किया जाता है?
  • क्या कुल योग (aggregate) उपसमुच्चय स्कोर के भारित औसत के रूप में गणना किया जाता है, न कि एक एकल पोल्ड मीट्रिक के रूप में?
  • क्या रिपोर्ट में प्रति-उपसमुच्चय परिणाम शामिल हैं ताकि उच्च कुल योग किसी महत्वपूर्ण उपसमुच्चय पर कम स्कोर को न छिपा सके?
  • क्या मीट्रिक दिशाएं दर्ज की गई हैं, जैसे कि सटीकता और रिकॉल को अधिकतम करना बनाम त्रुटि मीट्रिक्स को न्यूनतम करना?
  • क्या मूल्यांकन सेट का संस्करण (versioned) है या उसका वर्णन किया गया है ताकि परिणाम रन के दौरान तुलनीय रहें?
  • क्या तुलना में सांख्यिकीय जांच शामिल है यदि अंतर छोटा या शोर वाला (noisy) है?
  • क्या अंतिम टेस्ट सेट को मॉडल चयन के लिए उपयोग किए जाने वाले मूल्यांकन सेट से अलग रखा गया है?
  • क्या स्कोरिंग नियम किसी फ़ाइल या कॉन्फ़िगरेशन में प्रलेखित हैं जिसे अन्य लोग पुन: उपयोग कर सकें?
  • क्या रिपोर्ट में केवल कुल योग के बजाय कच्चे प्रति-उपसमुच्चय नंबर दिखाए जाते हैं?

यह दृष्टिकोण हाइपरपैरामीटर ट्यून करते समय एक अलग अंतिम टेस्ट सेट की जगह नहीं लेता है। यह अपने आप सांख्यिकीय महत्व प्रदान नहीं करता है; छोटे या शोर वाले अंतरों के लिए औपचारिक परीक्षण की आवश्यकता होती है। परिणाम तभी तुलनीय रहते हैं जब मूल्यांकन सेट और नियम अपरिवर्तित रहें, क्योंकि स्प्लिट्स या वेट्स बदलने के लिए एक नई तुलना की आवश्यकता होती है। यह डेटा प्रकार के आधार पर क्रॉस-वैलिडेशन या क्रोनोलॉजिकल स्प्लिट्स जैसे सत्यापन रणनीति को चुनने की आवश्यकता को भी समाप्त नहीं करता है। यह विधि मानती है कि कई उपसमुच्चय या मीट्रिक्स मौजूद हैं और निर्णय मॉडल तुलना पर आधारित है। यह गारंटी नहीं दे सकता कि भारित औसत सही व्यावसायिक उद्देश्य है, और यह युग्मित एनकोडर और स्वतंत्र संदर्भ लेबल के बिना एम्बेडिंग स्पेस को संरेखित नहीं करता है या प्रासंगिकता ग्राउंड ट्रुथ स्थापित नहीं करता है।

स्रोत

  1. Hugging Face: evaluation ↗
  2. scikit-learn: model evaluation ↗
ऊपर जाएँ ↑