स्कोरिंग एक benchmark को “JSON को आँख से देखने” से एक वस्तुनिष्ठ संख्या में बदल देती है। हर model के परिणाम को एक गोल्ड संदर्भ — अपेक्षित आउटपुट — के विरुद्ध आँका जाता है, जिससे पूर्णता, शुद्धता और एक समग्र गुणवत्ता स्कोर बनता है जिस पर आप छाँट सकते हैं।
स्कोरिंग को स्कोर करने के लिए कुछ चाहिए जिसके विरुद्ध स्कोर किया जा सके। हर scenario एक संदर्भ आउटपुट रखता है: उसके एक निश्चित entity का सही उत्तर। इसे मज़बूत model के साथ जनरेट करके (वेब खोज + एक source-of-truth दस्तावेज़), किसी ज्ञात-सही परिणाम को पेस्ट करके, फिर उसे हाथ से संपादित करके बनाएँ — और जब आप उस पर भरोसा कर लें तो उसे सत्यापित के रूप में चिह्नित करें। scenario को बिलकुल benchmark करने के लिए एक सत्यापित संदर्भ आवश्यक है, इसलिए आँकने के लिए हमेशा कुछ न कुछ रहता है। यदि आप बाद में संदर्भ को संपादित करते हैं — या scenario की स्कोरिंग कॉन्फ़िग बदलते हैं — तो मौजूदा स्कोर तब तक पुराने के रूप में चिह्नित रहते हैं जब तक आप फिर से स्कोर नहीं करते।
मूल समस्या: दो सही उत्तर अलग-अलग तरीके से लिखे जा सकते हैं। एक मॉडल जो किसी अभिनेता को “Robert Downey Jr.” के बजाय “R. Downey Jr.” नाम देता है, वह गलत नहीं है। इसलिए हर फ़ील्ड की तुलना एक स्तरीय सीढ़ी से की जाती है — पहले सबसे सस्ता और सबसे निश्चित, और आवश्यकता होने पर ही आगे बढ़ते हुए:
समान मान मेल खाते हैं। ऐसे मान भी जो केवल केस, आस-पास की whitespace, या संख्यात्मक परिशुद्धता में भिन्न होते हैं ("Acme" = "ACME", 4.0 = 4)। मुफ़्त और पूरी तरह नियतात्मक।
टेक्स्ट के लिए, कैंडिडेट और संदर्भ को एम्बेड किया जाता है और कोसाइन समानता द्वारा तुलना की जाती है। थ्रेशोल्ड से ऊपर वे समान गिने जाते हैं — इसलिए एक वैध वैकल्पिक वर्तनी जैसे "R. Downey Jr." बनाम "Robert Downey Jr." एक मैच है, त्रुटि नहीं। तिथियाँ अपवाद हैं: उनकी तुलना कैलेंडर मानों के रूप में की जाती है, कभी समानता के आधार पर नहीं, इसलिए एक निकट-लेकिन-गलत तिथि ("1972-03-14" बनाम "1972-03-24") एक स्पष्ट बेमेल है, न कि भ्रामक रूप से उच्च कोसाइन। बूलियन भी इसी तरह पूर्ण-या-कुछ-नहीं होते हैं।
ऐसे मान जिन्हें समानता के आधार पर तय करना बहुत कठिन है — सारांश और विवरण जैसे सभी free-text फ़ील्ड, और हर गैर-समान संख्या — एक judge मॉडल को भेजे जाते हैं, जो 0–100 में ग्रेड देता है कि उत्तर संदर्भ के अर्थ को कितनी अच्छी तरह पकड़ता है। यह अलग या अधिक संक्षिप्त शब्दों में लिखे गए सही उत्तर को पुरस्कृत करता है, और जहाँ फ़ील्ड इसकी अनुमति देता है वहाँ किसी संख्या को आंशिक अंक देता है (273.37 बनाम 273.35 का आणविक भार, 12 बनाम 15 की अर्ध-आयु) जबकि जहाँ सटीकता मायने रखती है वहाँ उसे विफल कर देता है (2020 बनाम 2023 का रिलीज़ वर्ष)। judge के बिना, free text एक निरंतर समानता स्कोर पर वापस चला जाता है, और एक गैर-समान संख्या बस एक mismatch होती है।
एक strictness सेटिंग embedding सीमा को नियंत्रित करती है: उच्च का अर्थ है कि दो अलग-अलग तरीके से लिखे गए मान समान गिने जाने के लिए अधिक समान होने चाहिए। strictness, वैकल्पिक judge model, और embedding model सभी scenario पर सेट होते हैं — हर बार score करते समय नहीं चुने जाते — ताकि हर model को समान रूप से आंका जाए और score तुलनीय बने रहें।
सूचियाँ — किसी फ़िल्म की कास्ट, किसी दवा के दुष्प्रभाव — वहीं मॉडल सबसे अधिक भिन्न होते हैं: एक छोटा मॉडल 4 अभिनेता ढूँढ सकता है जबकि एक मज़बूत मॉडल 15। क्रम मायने नहीं रखता, और अधिक सही आइटम ढूँढना जीतना चाहिए। इसलिए ऐरे को स्थिति-दर-स्थिति नहीं, बल्कि एक सेट के रूप में स्कोर किया जाता है:
यह देखने के लिए कि कौन-सी आइटम मैच हुईं, छूट गईं, या हैलुसिनेट हुईं, किसी रिज़ल्ट पंक्ति का विस्तार करें।
एक अकेला नंबर बहुत कुछ छिपा देता है, इसलिए हर परिणाम उप-स्कोर लेकर आता है:
एक्सपैंडेबल रो प्रति-फ़ील्ड ब्रेकडाउन दिखाती है: कैंडिडेट बनाम रेफ़रेंस, सीढ़ी के किस पायदान ने इसे तय किया, और जहाँ प्रासंगिक हो वहाँ समानता।
जब कोई परिदृश्य किसी मॉडल को एक से अधिक बार चलाता है (रिपीटिशन), तो हर रन को अलग से स्कोर किया जाता है और पंक्ति औसत गुणवत्ता के साथ-साथ एक कंसिस्टेंसी स्प्रेड (रन में सबसे कम–सबसे अधिक) दिखाती है — ताकि ऐसा मॉडल जो औसतन सही है लेकिन अस्थिर है, आसानी से पहचाना जा सके। दिखाई देने वाला आउटपुट गुणवत्ता-के-अनुसार मध्यमान रन है।
स्कोरिंग पहले से सहेजे गए परिणामों पर एक अलग पास है — यह कभी भी फिर से enrich नहीं करती, इसलिए परीक्षण किए जा रहे model के लिए फिर से भुगतान नहीं करती। यह मानों की तुलना करने के लिए टेक्स्ट को एम्बेड करती है (और यदि scenario में जज है तो उसे चलाती है), जो उपयोग के आधार पर credit घटाता है। यह हर run के अंत में स्वतः होता है, और जब भी आप फिर से स्कोर करते हैं तब दोबारा। यदि आपकी organization में कोई एम्बेडिंग model कॉन्फ़िगर नहीं है (और scenario कोई ओवरराइड सेट नहीं करता), तो स्कोरिंग फिर भी चलती है लेकिन केवल सटीक मिलान पर निर्भर करती है (वैकल्पिक वर्तनियाँ तब बेमेल गिनी जाती हैं), और यह बात बताती है।
Model Management → Benchmarks में, scenario editor में एक reference सेट करें और सत्यापित करें (और वहाँ इसका judge model, embedding model, और strictness चुनें)। इसके बाद से, प्रत्येक run स्वचालित रूप से अपने सफल परिणामों को score करता है — एक क्रमबद्ध होने योग्य Quality कॉलम बिना किसी अतिरिक्त कदम के भर जाता है। Reference या scoring config संपादित करने के बाद फिर से grade करने के लिए Re-score results (header बटन या ··· मेनू) का उपयोग करें।