बेंचमार्क स्कोरिंग

गोल्ड रेफ़रेंस

स्कोरिंग को स्कोर करने के लिए कुछ चाहिए जिसके विरुद्ध स्कोर किया जा सके। हर scenario एक संदर्भ आउटपुट रखता है: उसके एक निश्चित entity का सही उत्तर। इसे मज़बूत model के साथ जनरेट करके (वेब खोज + एक source-of-truth दस्तावेज़), किसी ज्ञात-सही परिणाम को पेस्ट करके, फिर उसे हाथ से संपादित करके बनाएँ — और जब आप उस पर भरोसा कर लें तो उसे सत्यापित के रूप में चिह्नित करें। scenario को बिलकुल benchmark करने के लिए एक सत्यापित संदर्भ आवश्यक है, इसलिए आँकने के लिए हमेशा कुछ न कुछ रहता है। यदि आप बाद में संदर्भ को संपादित करते हैं — या scenario की स्कोरिंग कॉन्फ़िग बदलते हैं — तो मौजूदा स्कोर तब तक पुराने के रूप में चिह्नित रहते हैं जब तक आप फिर से स्कोर नहीं करते।

मानों की तुलना कैसे की जाती है

मूल समस्या: दो सही उत्तर अलग-अलग तरीके से लिखे जा सकते हैं। एक मॉडल जो किसी अभिनेता को “Robert Downey Jr.” के बजाय “R. Downey Jr.” नाम देता है, वह गलत नहीं है। इसलिए हर फ़ील्ड की तुलना एक स्तरीय सीढ़ी से की जाती है — पहले सबसे सस्ता और सबसे निश्चित, और आवश्यकता होने पर ही आगे बढ़ते हुए:

एक strictness सेटिंग embedding सीमा को नियंत्रित करती है: उच्च का अर्थ है कि दो अलग-अलग तरीके से लिखे गए मान समान गिने जाने के लिए अधिक समान होने चाहिए। strictness, वैकल्पिक judge model, और embedding model सभी scenario पर सेट होते हैं — हर बार score करते समय नहीं चुने जाते — ताकि हर model को समान रूप से आंका जाए और score तुलनीय बने रहें।

arrays (आइटम्स की सूचियाँ) की स्कोरिंग

सूचियाँ — किसी फ़िल्म की कास्ट, किसी दवा के दुष्प्रभाव — वहीं मॉडल सबसे अधिक भिन्न होते हैं: एक छोटा मॉडल 4 अभिनेता ढूँढ सकता है जबकि एक मज़बूत मॉडल 15। क्रम मायने नहीं रखता, और अधिक सही आइटम ढूँढना जीतना चाहिए। इसलिए ऐरे को स्थिति-दर-स्थिति नहीं, बल्कि एक सेट के रूप में स्कोर किया जाता है:

• हर candidate आइटम को एक reference आइटम से मिलाया जाता है, फ़ील्ड की तरह उसी क्रम में, सबसे सस्ता पहले: उसके key फ़ील्ड से, फिर समान टेक्स्ट से, फिर embedding समानता से, और आख़िर में — पैराफ़्रेज़ किए गए बचे हुए हिस्से के लिए — एक single LLM set-alignment कॉल से जो बचे हुए आइटम को एक ही बार में पंक्तिबद्ध कर देती है (केवल तब जब scenario में judge हो)।
• रिकॉल कवरेज को पुरस्कृत करता है — 15 में से 15 खोजना 15 में से 4 से बेहतर है।
• परिशुद्धता गढ़े गए आइटम्स को दंडित करती है — एक हैलुसिनेट किया गया अतिरिक्त अभिनेता स्कोर घटा देता है।
• F1 दोनों को जोड़ता है, और प्रत्येक मिलान जोड़ी को फ़ील्ड-दर-फ़ील्ड स्कोर किया जाता है, इसलिए “सही अभिनेता, गलत भूमिका” अब भी आपके विरुद्ध गिना जाता है।

यह देखने के लिए कि कौन-सी आइटम मैच हुईं, छूट गईं, या हैलुसिनेट हुईं, किसी रिज़ल्ट पंक्ति का विस्तार करें।

स्कोर पढ़ना

एक अकेला नंबर बहुत कुछ छिपा देता है, इसलिए हर परिणाम उप-स्कोर लेकर आता है:

• पूर्णता — क्या मॉडल ने वह भरा जो संदर्भ ने भरा? (गायब डेटा इसे नुकसान पहुँचाता है)
• शुद्धता — जो उसने भरा, उसमें से कितना सही है?
• हैलुसिनेशन — इसने कितना ऐसा गढ़ा जिसका संदर्भ समर्थन नहीं करता?
• समग्र — एक भारित मिश्रण, जिसमें पहचानकर्ता (की) फ़ील्ड्स को अधिक भारित किया जाता है।

एक्सपैंडेबल रो प्रति-फ़ील्ड ब्रेकडाउन दिखाती है: कैंडिडेट बनाम रेफ़रेंस, सीढ़ी के किस पायदान ने इसे तय किया, और जहाँ प्रासंगिक हो वहाँ समानता।

क्वालिटी पूरी कहानी का सिर्फ़ एक तिहाई है। जहाँ कोई बेंचमार्क मॉडल चयन को फ़ीड करता है — एक स्कोरिंग स्रोत के रूप में — वहाँ मॉडल की स्थिति क्वालिटी, स्पीड और लागत के मिश्रण से बनती है, और यह अनुपात आपका है: इसे प्रत्येक सिनैरियो प्रकार के लिए Settings → Organization → Defaults में सेट करें; हर सेट का योग 100 होता है और डिफ़ॉल्ट रूप से बराबर बँटा होता है। लागत को ज़्यादा वज़न दें तो एक सस्ता, ठीक-ठाक मॉडल किसी उत्कृष्ट महँगे मॉडल से आगे निकल जाएगा — जो कुछ वर्कलोड के लिए सही जवाब है और कुछ के लिए ग़लत, इसीलिए प्लेटफ़ॉर्म यह फ़ैसला आपके लिए नहीं करता।

जब कोई परिदृश्य किसी मॉडल को एक से अधिक बार चलाता है (रिपीटिशन), तो हर रन को अलग से स्कोर किया जाता है और पंक्ति औसत गुणवत्ता के साथ-साथ एक कंसिस्टेंसी स्प्रेड (रन में सबसे कम–सबसे अधिक) दिखाती है — ताकि ऐसा मॉडल जो औसतन सही है लेकिन अस्थिर है, आसानी से पहचाना जा सके। दिखाई देने वाला आउटपुट गुणवत्ता-के-अनुसार मध्यमान रन है।

जनरेशन बेंचमार्क का स्कोरिंग

Benchmarks सिर्फ enrichment तक सीमित नहीं हैं: एक scenario sample generation (हर model किसी entity type के लिए एक example JSON बनाता है) या schema generation (हर model एक fixed sample को एक schema में बदलता है) को भी test कर सकता है। हर एक के अपने scoring नियम होते हैं:

• सैंपल जनरेशन के लिए किसी आविष्कृत इंस्टेंस का कोई एकल गोल्ड उत्तर नहीं होता, इसलिए क्वालिटी coverness और एक रूब्रिक का 50/50 मिश्रण है। Coverness सैंपल में विशिष्ट properties की गिनती करता है (array items में दोहराई गई property एक बार गिनी जाती है), उनमें से केवल judged on-topic हिस्से को रखता है (embedded असंबंधित एंटिटीज़ जैसी padding नहीं गिनी जाती), judged correctness के अनुसार weight देता है, और उसकी तुलना सर्वश्रेष्ठ मॉडल के per-run mean से करता है — square-root dampened, ताकि न तो केवल raw मात्रा और न ही कोई एक अति-verbose outlier हावी हो सके। रूब्रिक frozen judge के grades हैं जो naming व structure क्वालिटी, value realism — जिसमें अटैचमेंट होने पर आपके source document तक traceability शामिल है — और जनरेट किए गए property design की determinism safety के लिए होते हैं। चूँकि coverness परिदृश्य के अन्य परिणामों के सापेक्ष होता है — जैसा कि speed और cost scores भी होते हैं, जो प्रति जनरेट की गई property समय और लागत की तुलना करते हैं — किसी मॉडल को जोड़ने या दोबारा चलाने पर हर row फिर से बेसलाइन हो जाती है। चलाने के लिए किसी reference की ज़रूरत नहीं है।
• Schema generation की तुलना एक hand-verified gold reference schema से की जाती है: properties को पहले name से, फिर embedding similarity से, फिर judge से मैच किया जाता है; हर मैच को type/shape, behavioral flags (key, nullable, multilingual, preserve), और description quality पर ग्रेड किया जाता है; reference की गायब properties coverage को नुकसान पहुँचाती हैं, invented extras को hallucination गिना जाता है, और expertise grouping की तुलना membership से की जाती है (domain names मायने नहीं रखते)।

किसी भी तरह से परिचित columns अपना अर्थ बनाए रखते हैं — type-specific परिभाषा के लिए किसी column header पर hover करें, और पूरे breakdown के लिए किसी row को expand करें।

लागत और क्या चलता है

स्कोरिंग पहले से सेव किए गए परिणामों पर एक अलग पास है — यह कभी दोबारा enrichment नहीं करता, इसलिए परीक्षण किए जा रहे models के लिए दोबारा भुगतान नहीं करता। यह values की तुलना करने के लिए टेक्स्ट को embed जरूर करता है (और यदि scenario में judge हो तो उसे चलाता है), जो उपयोग के आधार पर credits काटता है। यह हर run के दौरान अपने आप होता है — हर model को उसके runs पूरे होते ही स्कोर किया जाता है — और जब भी आप दोबारा स्कोर करते हैं तब भी। यदि आपके organization में कोई embedding model कॉन्फ़िगर नहीं है (और scenario कोई override सेट नहीं करता), तो स्कोरिंग फिर भी चलती है लेकिन केवल exact matching पर वापस आ जाती है (वैकल्पिक वर्तनियाँ तब mismatch मानी जाती हैं), और ऐसा बताती है। एक टूटा हुआ judge अलग बात है: यदि कोई judge कॉल विफल होती है, तो स्कोरिंग एक स्पष्ट त्रुटि के साथ रुक जाती है और प्रभावित model कोई आंशिक स्कोर नहीं रखता — कोई result या तो पूरी तरह स्कोर होता है या बिल्कुल स्कोर नहीं होता, और बाद में दोबारा स्कोर करने योग्य बना रहता है। judge चुनते समय ध्यान दें कि LLM judges अपने ही मॉडल परिवार का पक्ष ले सकते हैं — ऐसे प्रोवाइडर से judge चुनें जिसका आप बेंचमार्क नहीं कर रहे हैं।

इसे कहां खोजें

Model Management → Benchmarks में, scenario editor में एक reference सेट करें और सत्यापित करें (और वहाँ इसका judge model, embedding model, और strictness चुनें)। इसके बाद से, प्रत्येक run स्वचालित रूप से अपने सफल परिणामों को score करता है — एक क्रमबद्ध होने योग्य Quality कॉलम बिना किसी अतिरिक्त कदम के भर जाता है। Reference या scoring config संपादित करने के बाद फिर से grade करने के लिए Re-score results (header बटन या ··· मेनू) का उपयोग करें।