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

स्कोरिंग एक benchmark को “JSON को आँख से देखने” से एक वस्तुनिष्ठ संख्या में बदल देती है। हर model के परिणाम को एक गोल्ड संदर्भ — अपेक्षित आउटपुट — के विरुद्ध आँका जाता है, जिससे पूर्णता, शुद्धता और एक समग्र गुणवत्ता स्कोर बनता है जिस पर आप छाँट सकते हैं।

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

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

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

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

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

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

सटीक और सामान्यीकृत

समान मान मेल खाते हैं। ऐसे मान भी जो केवल केस, आस-पास की whitespace, या संख्यात्मक परिशुद्धता में भिन्न होते हैं ("Acme" = "ACME", 4.0 = 4)। मुफ़्त और पूरी तरह नियतात्मक।

Embedding समानता

टेक्स्ट के लिए, कैंडिडेट और संदर्भ को एम्बेड किया जाता है और कोसाइन समानता द्वारा तुलना की जाती है। थ्रेशोल्ड से ऊपर वे समान गिने जाते हैं — इसलिए एक वैध वैकल्पिक वर्तनी जैसे "R. Downey Jr." बनाम "Robert Downey Jr." एक मैच है, त्रुटि नहीं। तिथियाँ अपवाद हैं: उनकी तुलना कैलेंडर मानों के रूप में की जाती है, कभी समानता के आधार पर नहीं, इसलिए एक निकट-लेकिन-गलत तिथि ("1972-03-14" बनाम "1972-03-24") एक स्पष्ट बेमेल है, न कि भ्रामक रूप से उच्च कोसाइन। बूलियन भी इसी तरह पूर्ण-या-कुछ-नहीं होते हैं।

LLM जज

जिन वैल्यू का फ़ैसला similarity से नहीं हो पाता — सारांश और विवरण जैसे सभी free-text फ़ील्ड, हर वह संख्या जो बिल्कुल एक जैसी नहीं है, और ऐसी स्पष्ट रूप से भिन्न वैल्यू जिसका समर्थन आपके दस्तावेज़ या अधिकतर दूसरे मॉडल करते हैं — उन्हें judge मॉडल के पास भेजा जाता है। judge ब्लाइंड होता है: वह दोनों वैल्यू को A और B के रूप में देखता है, साथ में schema में उस फ़ील्ड की जगह (उसके पैरेंट और उनके विवरण, उसका टाइप, वह किस लिस्ट आइटम से संबंधित है) और, जब scenario में मौजूद हों, आपके स्रोत दस्तावेज़ — और बताता है कि कौन-सी वैल्यू फ़ील्ड के लिए बेहतर है, या दोनों सही हैं, या एक ग़लत है। जिस candidate को reference के बराबर या उससे बेहतर आँका जाता है — या जिस reference को ग़लत ठहराया जाता है — उसे पूरा क्रेडिट मिलता है; कमज़ोर उत्तर को आंशिक क्रेडिट, और ग़लत उत्तर को बहुत कम या कुछ भी नहीं। किसी संख्या को आंशिक क्रेडिट तब मिलता है जब फ़ील्ड इसकी गुंजाइश देता हो (आणविक भार 273.37 बनाम 273.35, अर्ध-आयु 12 बनाम 15), और वहाँ वह विफल होती है जहाँ सटीकता मायने रखती है (रिलीज़ वर्ष 2020 बनाम 2023)। जिस वैल्यू को reference ने खाली छोड़ा है, उसके बारे में अलग से पूछा जाता है: सही पुष्टि होने पर उसे ऐसी वैल्यू माना जाता है जो reference में होनी चाहिए थी और मॉडल ने खोज ली — स्कोर बढ़ता है, केवल दंड से बचाव नहीं होता — और reference उसे अपना लेता है।

एक 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 से बेहतर है।
Precision गढ़े गए आइटम पर दंड लगाता है — एक hallucinated अतिरिक्त अभिनेता स्कोर घटा देता है। जिस अतिरिक्त आइटम की पुष्टि judge कर देता है, वह गढ़ा हुआ नहीं माना जाता: उसे ऐसे आइटम के रूप में गिना जाता है जो reference में छूट गया था — दोनों पक्षों में।
F1 दोनों को जोड़ता है, और हर मिलान वाली जोड़ी को फ़ील्ड-दर-फ़ील्ड स्कोर किया जाता है, इसलिए “सही अभिनेता, ग़लत भूमिका” भी आपके विरुद्ध ही गिना जाता है। ऑब्जेक्ट आइटम अपनी पहचान वाली properties के आधार पर जोड़े जाते हैं — वे चाहे कहीं भी हों, यहाँ तक कि किसी nested ऑब्जेक्ट पर भी, जैसे “top products” एंट्री के भीतर का product — और किसी आइटम के भीतर nested सूची उसी आइटम के ग्रेड में गिनी जाती है। ऑब्जेक्ट्स की सूची का भार उसके आइटम के फ़ील्ड्स जितना ही होता है: सूची के किसी आइटम का फ़ील्ड बिल्कुल top-level फ़ील्ड की तरह गिना जाता है, चाहे सूची में कितने भी आइटम हों।

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

स्कोर पढ़ना

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

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

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

विस्तारित बेंचमार्क परिणाम, जिसमें सब-स्कोर और रेफ़रेंस के मुकाबले फ़ील्ड-दर-फ़ील्ड तुलना दिखती है — हर फ़ील्ड बताता है कि उसे किस स्तर ने तय किया: *exact* की कोई लागत नहीं, *embedding* समानता मापता है, *judge* एक मॉडल कॉल खर्च करता है, और *miss* वह फ़ील्ड है जो रेफरेंस में है पर कैंडिडेट में नहीं।

क्वालिटी पूरी कहानी का सिर्फ़ एक तिहाई है। जहाँ कोई बेंचमार्क मॉडल चयन को फ़ीड करता है — एक स्कोरिंग सोर्स के रूप में — वहाँ मॉडल की स्थिति क्वालिटी, स्पीड और कॉस्ट के मिश्रण से बनती है, और यह अनुपात आपका है: इसे सेटिंग्स → ऑर्गनाइज़ेशन → डिफ़ॉल्ट्स में हर सिनेरियो प्रकार के लिए सेट करें; इनका योग 100 होता है और डिफ़ॉल्ट रूप से बराबर बँटा रहता है। कॉस्ट को भारी वेट दें तो एक सस्ता, ठीक-ठाक मॉडल किसी उत्कृष्ट महंगे मॉडल से ऊपर आ जाएगा — जो कुछ वर्कलोड के लिए सही जवाब है और कुछ के लिए ग़लत, इसलिए प्लेटफ़ॉर्म यह फ़ैसला आपके लिए नहीं करता। स्पीड और कॉस्ट इस सिनेरियो के अन्य परिणामों के सापेक्ष लॉग स्केल पर पढ़े जाते हैं: सबसे तेज़ या सबसे सस्ता मॉडल 100 पाता है और दस गुना धीमा या महंगा मॉडल 0, लेकिन पास-पास के परिणामों को पूरी रेंज भरने के लिए कभी खींचा नहीं जाता — $10 और $12 वाले दो मॉडल 100 और 92 पर आते हैं, 100 और 0 पर नहीं।

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

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

बेंचमार्क केवल संवर्धन तक सीमित नहीं हैं: एक परिदृश्य नमूना जनरेशन (हर मॉडल एक ही फ्री-टेक्स्ट अनुरोध के लिए एक उदाहरण JSON गढ़ता है) या स्कीमा जनरेशन (हर मॉडल एक निश्चित नमूने को स्कीमा में बदलता है) का भी परीक्षण कर सकता है। हर एक के अपने स्कोरिंग नियम हैं:

सैंपल जनरेशन में किसी गढ़े गए इंस्टेंस के लिए कोई एक सही उत्तर नहीं होता, इसलिए क्वालिटी कवरनेस और एक रूब्रिक का 50/50 मिश्रण है। कवरनेस सैंपल की अलग-अलग प्रॉपर्टीज़ गिनती है (ऐरे आइटम्स में दोहराई गई प्रॉपर्टी एक ही बार गिनी जाती है), उनमें से केवल वही हिस्सा रखती है जिसे जज ने विषय-संगत माना (असंबंधित एंटिटी एम्बेड करने जैसी पैडिंग नहीं गिनी जाती), जज की गई शुद्धता के अनुसार वेटिंग करती है, और उसकी तुलना सर्वश्रेष्ठ मॉडल के प्रति-रन औसत से करती है — वर्गमूल से डैम्प किया हुआ, ताकि न कोरी मात्रा हावी हो सके और न ही कोई एक अति-वाचाल आउटलायर। रूब्रिक, फ़्रोज़न जज द्वारा दिए गए ग्रेड हैं: नामकरण एवं संरचना की गुणवत्ता, वैल्यू की यथार्थता — जिसमें अटैचमेंट मौजूद होने पर आपके सोर्स डॉक्युमेंट तक ट्रेसेबिलिटी शामिल है — और जनरेट किए गए प्रॉपर्टी डिज़ाइन की डिटरमिनिज़्म सुरक्षा। चूँकि कवरनेस इस सिनेरियो के अन्य परिणामों के सापेक्ष है — और वैसे ही स्पीड तथा कॉस्ट स्कोर भी, जो हर रन के जनरेट करने में बीते हिस्से को मीडियन सैंपल साइज़ पर रीस्केल करते हैं, ताकि कोई वाचाल मॉडल न तो अपनी समृद्धि की दोहरी कीमत चुकाए और न ही उसके पीछे अपनी निश्चित प्रॉम्प्ट लागत छिपाए — इसलिए कोई मॉडल जोड़ने या दोबारा चलाने पर हर पंक्ति का बेसलाइन फिर से तय होता है। चलाने के लिए किसी रेफ़रेंस की ज़रूरत नहीं।
स्कीमा जनरेशन की तुलना हाथ से सत्यापित गोल्ड रेफ़रेंस स्कीमा से की जाती है, जिसमें परिदृश्य के इनपुट सैंपल प्रमाण का काम करते हैं। प्रॉपर्टीज़ का मिलान पहले नाम से, फिर एम्बेडिंग समानता से, और फिर जज से होता है। जो कुछ सैंपल साबित कर देते हैं, वह बिना जज के तय हो जाता है: किसी प्रॉपर्टी का टाइप और आकार, किसी एक सैंपल में गायब मान (nullable), लोकलाइज़्ड मान (बहुभाषी), या ऐसा की-सेट जो दो अलग सैंपल इंस्टेंस को मर्ज कर देता। बाकी सब कुछ — विवरण, बची हुई एट्रिब्यूट असहमतियाँ, कौन-सी कीज़ किसी ऑब्जेक्ट को सबसे अच्छी तरह पहचानती हैं, सिमेंटिक पहचान कैसे बनती है — पर चार-तरफ़ा फ़ैसला आता है: कैंडिडेट ग़लत हो सकता है, स्वीकार्य पर कमज़ोर, समकक्ष, या रेफ़रेंस से बेहतर — क्योंकि रेफ़रेंस सत्य नहीं, बल्कि हाथ से सुधारा गया ड्राफ़्ट है। प्रॉपर्टीज़ के अलावा, एंटिटी रीजन की तुलना पार्टिशन के रूप में होती है (बिना समकक्ष के अलग किया गया रीजन उस स्प्लिट से ज़्यादा महँगा पड़ता है जो कैंडिडेट से छूट गया, और लंबित यूनिफ़ाई प्रस्ताव तब मर्ज माना जाता है जब दूसरी ओर मर्ज हुआ हो), और हर ऑब्जेक्ट की आइडेंटिटी कीज़ को प्रति ऑब्जेक्ट आँका जाता है; रेफ़रेंस की गायब प्रॉपर्टीज़ कवरेज को नुकसान पहुँचाती हैं, गढ़ी गई अतिरिक्त प्रॉपर्टीज़ हैलुसिनेशन में गिनी जाती हैं, और विशेषज्ञता ग्रुपिंग की तुलना सदस्यता के आधार पर होती है (डोमेन नामों से फ़र्क नहीं पड़ता)। यहाँ भी जज ब्लाइंड रहता है (दोनों डिज़ाइन A और B के रूप में, स्कीमा में प्रॉपर्टी की जगह पर), और जहाँ भी कैंडिडेट रेफ़रेंस से बेहतर निकला — या सैंपल ने उसे ग़लत साबित किया — वहाँ परिणाम उस फ़ाइंडिंग को दर्ज करता है, साथ में वह एडिट भी जो उसे ठीक करता है: एक फ़्लैग, एक टाइप, एक विवरण, एक क्लोज़्ड सेट, एक की-सेट, या सैंपल में मौजूद पर छूटा हुआ फ़ील्ड। स्कोरिंग पास इन्हें सभी मॉडलों में समेटकर रेफ़रेंस स्कीमा पर लागू करता है — एनरिचमेंट फ़ाइंडिंग्स की तरह लॉग किया हुआ और रिवर्ट करने योग्य।

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

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

स्कोरिंग पहले से सेव किए गए परिणामों पर एक अलग पास है — यह दोबारा एनरिचमेंट नहीं करती, इसलिए जाँचे जा रहे मॉडलों के लिए दोबारा भुगतान नहीं होता। मानों की तुलना के लिए यह टेक्स्ट को एम्बेड ज़रूर करती है (और अगर परिदृश्य में जज है तो उसे चलाती है), जिससे उपयोग के अनुसार क्रेडिट कटते हैं। यह हर रन के दौरान अपने आप होता है — हर मॉडल के रन पूरे होते ही उसे स्कोर कर दिया जाता है — और हर बार जब आप दोबारा स्कोर करते हैं, तब भी। अगर आपके संगठन में कोई एम्बेडिंग मॉडल कॉन्फ़िगर नहीं है (और परिदृश्य कोई ओवरराइड तय नहीं करता), तो स्कोरिंग फिर भी चलती है पर सिर्फ़ सटीक मिलान पर लौट आती है (तब वैकल्पिक वर्तनियाँ बेमेल गिनी जाती हैं), और यह बात बता भी देती है। ख़राब जज की बात अलग है: अगर जज कॉल विफल होती है, तो स्कोरिंग स्पष्ट त्रुटि के साथ रुक जाती है और प्रभावित मॉडल के कोई आंशिक स्कोर नहीं बचते — कोई परिणाम या तो पूरी तरह स्कोर होता है या बिल्कुल नहीं, और बाद में दोबारा स्कोर करने योग्य बना रहता है। जज के उत्तर उनकी सामग्री के आधार पर प्रति परिदृश्य कैश किए जाते हैं: वही सवाल किसी दूसरे मॉडल ने उठाया हो, दोहराव हो या कोई और पास — भुगतान दो बार कभी नहीं होता, और रेफ़रेंस के ख़ुद अपडेट होने के बाद दोबारा स्कोर करने पर सिर्फ़ बदले हुए फ़ील्ड्स के सवाल दोबारा पूछे जाते हैं। जज जो कुछ करता है, उसमें कुछ भी छिपा नहीं है: किसी मॉडल पर हर स्कोरिंग पास इतिहास में एक स्कोरिंग रिकॉर्ड छोड़ता है — हर जज कॉल के लिए एक पंक्ति, उसके प्रॉम्प्ट, उत्तर, टोकन और लागत के साथ, विफल कॉल सहित, साथ ही कैश ने कितने प्रश्नों का उत्तर मुफ़्त में दिया — और परिणाम तालिका में हर मॉडल की जज लागत, कॉल संख्या और स्कोरिंग समय उसके लिंक के साथ दिखते हैं। judge चुनते समय ध्यान दें कि LLM judges अपने ही मॉडल परिवार का पक्ष ले सकते हैं — ऐसे प्रोवाइडर से judge चुनें जिसका आप बेंचमार्क नहीं कर रहे हैं।

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

मॉडल प्रबंधन → बेंचमार्क में, परिदृश्य एडिटर में रेफ़रेंस सेट करके सत्यापित करें (और वहीं उसका जज मॉडल, एम्बेडिंग मॉडल और सख़्ती चुनें)। उसके बाद हर रन अपने सफल परिणामों को अपने आप स्कोर करता है — बिना किसी अतिरिक्त कदम के सॉर्ट करने योग्य गुणवत्ता कॉलम भर जाता है। रेफ़रेंस या स्कोरिंग कॉन्फ़िग बदलने के बाद दोबारा आँकने के लिए परिणाम दोबारा स्कोर करें (हेडर बटन या ··· मेन्यू) का उपयोग करें। रेफ़रेंस स्टेटस के बगल वाला रेफ़रेंस अपडेट बैज वह लॉग खोलता है जिसमें दिखता है कि स्कोरिंग पास ने क्या बदला, और हर एंट्री के लिए रिवर्ट भी मिलता है।

मॉडल बेंचमार्क

सेव किए गए सिनारियो, रन, और साथ-साथ आउटपुट व लागत।

सिमैंटिक ID

एम्बेडिंग रिज़ॉल्यूशन जो समानता मिलान को भी सशक्त बनाता है।