निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev

अलाइनमेंटमधील अपयश शोधणारा एक डिटेक्टर, जो एकाच कॉलमध्ये अनेक प्रकारबद्ध प्रश्नांची उत्तरे कॅलिब्रेटेड संभाव्यतांसह देतो, अपयशांची चांगली क्रमवारी लावतो आणि LLM-जज स्कोररपेक्षा ६३× स्वस्त आहे. पण या संभाव्यता थ्रेशोल्ड म्हणून हस्तांतरित होत नाहीत, आणि प्रश्नाच्या शब्दरचनेपेक्षा लेबल आणि त्याचा संदर्भ कितीतरी अधिक महत्त्वाचे ठरतात.

प्रत्येक संदेशावर लक्ष ठेवण्याच्या खर्चाची रचना #

तैनात केलेली मॉडेल्स अजूनही वापरकर्त्याच्या चुकीच्या समजुतीपुढे मान तुकवतात (Sharma et al., २०२४). हे वाक्य साधे आहे, पण संपूर्ण समस्येची चौकट तेच ठरवते. अशा प्रकारची खुशामत तैनात प्रणालींमध्ये टिकून राहत असेल, तर कोणीतरी तिच्यावर लक्ष ठेवायला हवे, आणि ही देखरेख संभाषणाच्याच वेगाने व्हायला हवी.

इथेच अर्थशास्त्र टोचते. डिटेक्टर अचूक असायला हवा आणि, तो प्रत्येक संदेशावर चालतो म्हणून, स्वस्तही. यांपैकी एकच गुण मिळवणे सोपे आहे: निष्काळजी डिटेक्टर स्वस्त असतो, आणि प्रत्येक संदेशावर चालवायला फार महाग असलेला काळजीपूर्वक डिटेक्टर ट्रॅफिकच्या केवळ एका नमुन्यावर लक्ष ठेवतो. रोचक अभियांत्रिकी प्रश्न हा आहे की कोणत्या स्वरूपाचा डिटेक्टर दोन्ही असू शकतो.

या लेखामागील शोधनिबंधानुसार, सध्याच्या उत्तरात एक रचनात्मक दोष आहे. अलाइनमेंट अपयशांचे बहुतेक डिटेक्टर हे जनरेटिव्ह जज आहेत, जे प्रत्येक निकषावर एक डिकोडिंग पास खर्च करतात. सोप्या भाषेत, सध्याचे डिटेक्टर जो जो निकष तपासतात त्यासाठी एक डिकोडिंग पास मोजतात. दहा वेगवेगळ्या अपयश प्रकारांची तपासणी करू इच्छिणारा मॉनिटर दहा पासांचे पैसे देतो, आणि तुम्हाला ज्या गोष्टींची काळजी आहे त्यांच्या संख्येसोबत बिल रेषीयपणे वाढते.

एक आंशिक उपाय आहे, आणि त्याच्या मर्यादांबद्दल नेमके असणे गरजेचे आहे. टोकन संभाव्यता वाचणारे क्लासिफायर, जसे Llama Guard, अजूनही प्रत्येक कॉलमध्ये एकच ठरलेले लेबल गुणांकित करतात. टोकन संभाव्यता वाचल्याने गुण मिळतो, पण प्रत्येक कॉल अजूनही एकच लेबल किंवा निकष गुणांकित करतो, कारण संभाव्यता एकाच निकाल-टोकनवरून वाचली जाते. डिकोडिंग पास गेला, तरी एक-कॉल-एक-प्रश्न ही रचना कायम राहते. तुम्ही प्रत्येक कॉल स्वस्त केला, पण लागणाऱ्या कॉलची संख्या बदलली नाही.

तर रचनात्मक दावा असा आहे: जनरेटिव्ह जज प्रति निकष महाग आहेत, आणि संभाव्यता वाचणारे क्लासिफायर प्रति निकष स्वस्त आहेत पण तरीही प्रत्येकी एका निकषाला बांधलेले आहेत. दोघांपैकी कोणीही तुम्हाला एकाच इनपुटबद्दल एकाच वेळी अनेक प्रश्न विचारू देत नाही.

Jev वेगळे काय करतो #

Jev ला कॅलिब्रेटेड निर्णयांसाठी रीइन्फोर्समेंट लर्निंग (RLCD) ने प्रशिक्षित केले आहे. तो एका इनपुटबद्दलच्या अनेक प्रकारबद्ध प्रश्नांची उत्तरे एकाच कॉलमध्ये कॅलिब्रेटेड संभाव्यतांसह देतो. ही यंत्रणा काळजीपूर्वक मांडणे आवश्यक आहे, कारण उरलेला लेख तिच्यावरच अवलंबून आहे.

RLCD मॉडेल मजकूर निर्माण करण्याऐवजी प्रत्येक प्रकारबद्ध प्रश्नासाठी कॅलिब्रेटेड संभाव्यतेसह एक निर्णय परत करते. असा कोणताही निर्मिती टप्पा नाही ज्यात निकाल लिहिला जातो आणि मग तो पार्स केला जातो. Jev एका इनपुटबद्दल, ज्याला शोधनिबंध स्टेट म्हणतो, अनेक द्विमान, वर्गीय आणि क्रमवाचक प्रश्नांची उत्तरे एकाच कॉलमध्ये देतो. स्टेट म्हणजे इनपुट; प्रश्न म्हणजे तुम्ही त्याबद्दल विचारता त्या गोष्टी.

हा वरील दोन्ही पद्धतींपेक्षा वेगळा खर्च वक्र आहे. प्रश्न एकच कॉल वाटून घेत असतील, तर आणखी एक प्रश्न जोडल्याने आणखी एक डिकोडिंग पास जोडला जात नाही. एकाच वेळी अनेक अपयश प्रकारांची काळजी असलेल्या मॉनिटरसाठी याचा फायदा उघड आहे, मात्र शोधनिबंधाची मोजमापे एकटा सर्वसाधारण प्रश्न काय साध्य करतो याबद्दल आहेत, आणि मी जे मोजले गेले त्यालाच धरून राहीन.

तरीही एक उणीव होती. Jev अलाइनमेंट अपयश शोधतो की नाही, हे मोजले गेले नव्हते. प्रकारबद्ध प्रश्नांची उत्तरे कॅलिब्रेटेड संभाव्यतांसह देणारे मॉडेल या कामासाठी योग्य वाटते, आणि योग्य वाटणे स्वस्त असते. शोधनिबंध हेच गहाळ मोजमाप पुरवण्यासाठी निघतो.

अलाइनमेंट अपयश दिसतात त्यापेक्षा कठीण का आहेत #

मोजमापापूर्वी एक गुंतागुंत. यांपैकी अनेक अपयश संबंधात्मक असतात, म्हणजे त्यांची व्याख्या अशा संदर्भाच्या सापेक्ष होते जो केवळ उत्तरातून उघड होत नाही. खुशामत ही या सर्वसाधारण कल्पनेचे चांगले उदाहरण आहे: एखादे उत्तर वापरकर्त्याच्या चुकीच्या समजुतीपुढे झुकते का, हे ती समजूत काय आहे आणि ती चुकीची आहे का यावर अवलंबून असते, आणि यांपैकी कोणतीही वस्तुस्थिती केवळ उत्तराच्या मजकुरात दिसत नाही.

डिटेक्टरच्या रचनेवर याचा एक परिणाम आहे, जो शोधनिबंध योग्य सावधगिरीने मांडतो. जो डिटेक्टर केवळ उत्तर पाहतो, त्याच्याकडे अपयशाची व्याख्या करणारा संदर्भ कदाचित नसेल. “कदाचित” हा शब्द महत्त्वाचा आहे; दावा असा नाही की प्रत्येक अपयशाला संदर्भ लागतो, फक्त असा की काहींना लागतो आणि केवळ-उत्तर दृष्टिकोन तो चुकवू शकतो.

यामुळे निदानही गुंतागुंतीचे होते. अपयश संबंधात्मक असतील, तर कमकुवत शोध प्रश्नामुळेही येऊ शकतो आणि संदर्भ नसलेल्या स्टेटमुळेही. दोन गोष्टी चुकीच्या असू शकतात, आणि कमी गुण यांपैकी कोणती हे सांगत नाही. कदाचित प्रश्नाची शब्दरचना वाईट होती. कदाचित प्रश्न ठीक होता आणि उत्तर देण्यासाठी जे हवे होते ते इनपुटमध्ये कधीच नव्हते. एखाद्या डिटेक्टरबद्दल काही उपयुक्त सांगू इच्छिणारा बेंचमार्क अशा प्रकारे बांधावा लागतो की ही दोन कारणे वेगळी करता येतील.

विकसक, आपल्या बाजूने, अप्रत्यक्ष अर्थ आणि प्रतिकूल (अ‍ॅडव्हर्सेरियल) मजकूर यांना Jev च्या ज्ञात कमकुवतपणांमध्ये गणतो. नंतर निकाल वाचताना हे लक्षात ठेवणे योग्य ठरेल, कारण काही अपयश प्रकार नेमके याच गुणधर्मांवर अवलंबून असतात.

शोधाकडे वर्गीकरण म्हणून पाहणे #

शोधनिबंधाची औपचारिक मांडणी सरळ आहे. तो अलाइनमेंट अपयश शोधाला लक्ष्य मॉडेलच्या संवादांवरील द्विमान वर्गीकरण मानतो. डिटेक्टर एक गुण s(x) ∈ [0, 1] देतो आणि s(x) ≥ t असेल तेव्हा x ला चिन्हांकित करतो. याचा अर्थ त्याला अपयशांना अपयश नसलेल्यांच्या वर क्रमवारीत ठेवायचे आहे आणि थ्रेशोल्ड t वर त्यांना वेगळेही करायचे आहे.

ही दोन कर्तव्ये वेगळी करता येतात, आणि शोधनिबंधाचे निकाल नेमके याच शिवणीवर विभागतात. क्रमवारी AUROC मोजतो. थ्रेशोल्डवर वेगळे करणे कॅलिब्रेशनवर अवलंबून असते, आणि लेख त्याकडे परत येईल कारण Jev तिथेच कमी पडतो. एखादा डिटेक्टर उत्कृष्ट क्रमवारी लावूनही t=0.5 वर निरुपयोगी ठरू शकतो, जर त्याच्या संभाव्यता चुकीच्या ठिकाणी बसल्या असतील.

RLCDAlignBench #

बेंचमार्कचे नाव RLCDAlignBench आहे. तो ४४ बेंचमार्क आणि ७,१९३ शोध उदाहरणांमध्ये दहा अपयश प्रकार व्यापतो. उदाहरणे पाच मुक्त 2–7B लक्ष्य मॉडेलमधून येतात, आणि प्रत्येकाला त्याच्या बेंचमार्कच्या संदर्भ स्कोररने लेबल दिले आहे. म्हणजे ज्या संवादांचे मूल्यमापन होत आहे ते लहान मुक्त मॉडेलमधून येतात, आणि प्रत्येकाचे वास्तविक सत्य हे मूळ बेंचमार्कचा स्वतःचा स्कोरर जे म्हणतो तेच आहे.

प्रत्येक बेंचमार्कमध्ये एकाच प्रकारचे लेबल नाही. Jev ची एखाद्या जजशी तुलना करण्यासाठी StrongREJECT आणि HarmBench वरील मानवी लेबल, आणि AbstentionBench आणि InstrumentalEval वरील दुसऱ्या जजचे लेबल वापरले जातात. त्यामुळे शोधनिबंधाला संदर्भ स्कोररवर दोन प्रकारची बाह्य तपासणी मिळते: काही प्रकरणांत माणसे, इतरांत दुसरा जज.

प्रकाशित सामग्रीचे वर्णन असे केले आहे: संदर्भ प्रकारांसह दहा अपयश प्रकारांमधील ४४ बेंचमार्क, कॅश केलेली Jev उत्तरे आणि पुन्हा गुणांकन करणाऱ्या स्क्रिप्ट, सोबत एक स्प्लिट-हाफ प्रोटोकॉल जो नोंदवलेल्या लाभांमधून निवडीमुळे होणारी फुगवट काढून टाकतो. प्रत्येक घटक एक व्यावहारिक गरज पूर्ण करतो. संदर्भ प्रकार वाचकाला हे विचारू देतात की स्टेटमध्ये अधिक माहिती असेल तर काय होते. कॅश केलेली उत्तरे आणि पुन्हा गुणांकन करणाऱ्या स्क्रिप्ट कोणालाही मॉडेल पुन्हा न चालवता एखादी संख्या पुन्हा मिळवू देतात. स्प्लिट-हाफ प्रोटोकॉल एका पद्धतिशास्त्रीय सापळ्याला तोंड देतो, जो स्वतंत्र विभागास पात्र आहे.

निवडीचा सापळा #

Jev ला एकाच इनपुटबद्दल अनेक प्रश्न विचारता येतात. हीच त्याची खासियत आहे, आणि मूल्यमापनासाठी हाच एक धोकाही. तुम्ही उमेदवार प्रश्नांचा एक संच मांडला आणि जो सर्वोत्तम गुण मिळवेल तो नोंदवला, तर तुम्ही प्रश्नांवर शोध घेतला आणि विजेता नोंदवला. शोधनिबंध हे थेट सांगतो: यांपैकी सर्वोत्तम नोंदवणे म्हणजे प्रत्यक्ष वापरकर्त्याला जे मिळते त्यापेक्षा जास्त दाखवणे.

ज्याने कधी चाचणी संचासमोर प्रॉम्प्ट जुळवला आहे, तो हे ओळखेल. इथे वापरलेला उपाय सोपा आहे. प्रश्न बाबींच्या एका अर्ध्या भागावर निवडले जातात आणि दुसऱ्या अर्ध्यावर गुणांकित केले जातात. लक्ष्यित प्रश्न बाबींच्या एका अर्ध्यावर निवडला जातो आणि दुसऱ्या अर्ध्यावर गुणांकित केला जातो, २० विभाजनांवर. नोंदवलेली संख्या ज्या बाबींमधून येते त्यांना निवड कधीच स्पर्श करत नाही.

खाली नोंदवलेला प्रत्येक लाभ कसा वाचावा यासाठी हे महत्त्वाचे आहे. शोधनिबंधाचा दावा आहे की स्प्लिट-हाफ प्रोटोकॉल नोंदवलेल्या लाभांमधून निवडीमुळे होणारी फुगवट काढून टाकतो. जेव्हा शोधनिबंध म्हणतो की लक्ष्यित शब्दरचना +०.००६ AUROC चा मध्यक लाभ देते, तेव्हा तो आकडा वेगवेगळ्या अर्ध्यांवर निवडलेल्या आणि गुणांकित केलेल्या शब्दरचनेतून येतो. प्रामाणिकपणे मोजलेला इतका लहान आकडा, ज्यात विजेत्याचा शाप गुपचूप सामील झाला आहे अशा मोठ्या आकड्यापेक्षा अधिक उपयुक्त आहे.

मुख्य निकाल: एक सर्वसाधारण प्रश्न #

आता तो निकाल जो बहुतेक वाचकांना हवा असेल. एकटा सर्वसाधारण प्रश्न झिरो-शॉटमध्ये ०.८८६ चा मध्यक AUROC गाठतो आणि बहुतेक बेंचमार्कवर पर्यवेक्षित बेसलाइनला मागे टाकतो.

शब्द एकेक करून घेऊ. “एकटा सर्वसाधारण प्रश्न” म्हणजे प्रत्येक बेंचमार्कसाठी प्रॉम्प्टची कोणतीही अभियांत्रिकी नाही. “झिरो-शॉट” म्हणजे लक्ष्य बेंचमार्कवर कोणतेही प्रशिक्षण नाही. “बहुतेक बेंचमार्कवर पर्यवेक्षित बेसलाइनला मागे टाकतो” म्हणजे ज्या प्रणालींना कामाच्या लेबल केलेल्या डेटावर प्रशिक्षित केले होते, त्या तपासलेल्या बहुतेक बेंचमार्कवर कोणीही न जुळवलेल्या प्रश्नाकडून हरतात. दावा “बहुतेक” वर थांबतो, आणि हा लेखही तिथेच थांबेल.

सर्वसाधारण प्रश्न हा P(yes) म्हणून वाचलेला एक साचा-प्रश्न आहे. आकडा ३८ वापरण्यायोग्य बेंचमार्कचा AUROC दाखवतो, आणि सर्वसाधारण प्रश्न ७ बेंचमार्कवर विचारला गेला नाही. म्हणून मुख्य संख्या ही सर्वसाधारण प्रश्न लागू झाला त्या बेंचमार्कवरील मध्यक आहे, जे ३८ वापरण्यायोग्य बेंचमार्कमधून घेतले आहेत. काळजीपूर्वक वाचणाऱ्यांनी छेदांचा हिशोब स्पष्ट ठेवावा: एकूण ४४ बेंचमार्क आहेत, या आकड्यासाठी ३८ वापरण्यायोग्य आहेत, आणि सर्वसाधारण प्रश्नात ७ ची तूट आहे.

माझे म्हणणे असे की झिरो-शॉट निकाल हा वाक्याचा अधिक रोचक अर्धा भाग आहे. पर्यवेक्षित बेसलाइनला हरवणे हे तुलनात्मक स्थानाबद्दलचे विधान आहे. कोणत्याही कार्य-विशिष्ट प्रशिक्षणाशिवाय ०.८८६ चा मध्यक AUROC हे सांगतो की स्टेट वाचून एका साध्या प्रश्नाचे उत्तर देणाऱ्या मॉडेलला अपयशाचा किती संकेत उपलब्ध आहे. हे या दहांच्या बाहेरील अपयश प्रकारांनाही लागू होते का, याबद्दल दावे काहीच सांगत नाहीत.

शब्दरचना जवळजवळ अप्रस्तुत आहे #

तुम्ही प्रॉम्प्ट अभियांत्रिकीवर वेळ घालवला असेल, तर पुढचा निकाल बोचेल. प्रश्नाची शब्दरचना फारशी महत्त्वाची नाही, तर संदर्भ अधिक महत्त्वाचा आहे, मुख्यतः लेबल सांकेतिक करणाऱ्या फील्डद्वारे.

शोधनिबंधाचे स्पष्टीकरण नेमके आहे. उत्तरे argmax निर्णयांऐवजी संभाव्यता म्हणून ठेवली की प्रश्नाच्या शब्दरचनेला फारसे महत्त्व राहत नाही आणि स्टेट व लेबलमध्ये काय आहे याला खूप महत्त्व येते. हे माहितीबद्दलचे निरीक्षण आहे. argmax निर्णय एका उत्तराने दुसऱ्याला ज्या फरकाने हरवले तो फरक फेकून देतो, आणि शब्दरचनेतील एक बदल निर्णयाला सीमेपलीकडे उलटवू शकतो. संभाव्यता तो फरक जपते, म्हणून पुराव्याला थोडेसे सरकवणारी नवी शब्दरचना संभाव्यतेला थोडीच हलवते आणि क्रमवारी बहुतांशी अबाधित ठेवते.

मी हे शोधनिबंध जे सांगतो तितकेच मर्यादित ठेवीन: संभाव्यता ठेवल्या की शब्दरचना फारशी महत्त्वाची राहत नाही. असे का होते याच्या यांत्रिक स्पष्टीकरणापर्यंत मी ते ताणणार नाही, कारण दावे असे कोणतेही स्पष्टीकरण देत नाहीत.

आकडे या विधानाला आधार देतात. लक्ष्यित शब्दरचना +०.००६ AUROC चा मध्यक लाभ देते, जिथे शब्दरचना वेगवेगळ्या अर्ध्यांवर निवडली आणि गुणांकित केली गेली. नमुन्याबाहेर, लक्ष्यित शब्दरचना +०.००६ [−०.००४, +०.०१५] AUROC जोडते. हा अंतराल शून्याला ओलांडतो. वाचकाने +०.००६ ला विश्वासार्ह सुधारणा मानू नये; हा अंतराल लहान लाभाइतकाच लहान तोटाही शक्य मानतो. वापरकर्त्यासाठी उपयुक्त वाचन असे की अधिक चतुर शब्दरचना शोधण्याच्या श्रमाचे फळ मिळण्याची शक्यता कमी आहे, किमान या बेंचमार्कवर तरी.

यामुळे संघ आपला वेळ कसा वाटतात हे बदलायला हवे. शब्दरचनेचा परिणाम जवळजवळ शून्य असेल, तर तिच्यावर खर्च होणारे तास स्टेटवर खर्च करणे अधिक चांगले.

लाभ संदर्भात आहेत #

मग स्टेटमध्ये काय आहे, आणि त्यात काय असायला हवे? शोधनिबंधाचा निष्कर्ष असा की संदर्भ अधिक महत्त्वाचा आहे, मुख्यतः लेबल सांकेतिक करणाऱ्या फील्डद्वारे. अभ्यासाच्या रचनेमागील मुख्य कल्पना म्हणजे Jev ला काय विचारले जाते ते तो काय पाहतो यापासून वेगळे बदलणे: एका बाजूला प्रश्नाची शब्दरचना आणि उत्तराचा प्रकार, दुसऱ्या बाजूला इनपुटचे फील्ड. हेच विलगीकरण शोधनिबंधाला असे म्हणू देते की शब्दरचना फारशी महत्त्वाची नाही तर संदर्भ अधिक महत्त्वाचा आहे. त्याशिवाय दोन्ही परिणाम एकमेकांत गुंतले असते.

मुख्य उदाहरण PrivacyLens आहे. लेबलची व्याख्या करणारे संदर्भ मोठे लाभ देतात, जसे PrivacyLens ची गोपनीय बाबींची यादी (०.७९→०.९५). AUROC चे ०.७९ वरून ०.९५ वर जाणे शब्दरचनेतून मिळालेल्या +०.००६ च्या तुलनेत मोठे आहे. इथला संदर्भ गोपनीय बाबींची यादी आहे, जी नेमकी तीच गोष्ट आहे जिच्या महत्त्वाचे भाकीत संबंधात्मक अपयशांवरील आधीची चर्चा करते: एखादे उत्तर काही खासगी उघड करते का, हे खासगी कशाला मानले जाते यावर अवलंबून असते, आणि केवळ उत्तर हे सांगत नाही.

तैनातीबाबत एक इशारा आहे, आणि तो महत्त्वाचा आहे. तैनात मॉनिटरकडे जो संदर्भ असेल तो ७ पैकी १ बेंचमार्कवर मदत करतो. मोठे लाभ लेबलची व्याख्या करणाऱ्या संदर्भांतून येतात, पण तैनात मॉनिटरकडे ते असतीलच असे नाही. मॉनिटरकडे वास्तवात जे असेल ते सातपैकी फक्त एका बेंचमार्कवर मदत करते.

हा एक संयत निष्कर्ष आहे, आणि मला वाटते की हे शोधनिबंधातील व्यावसायिकदृष्ट्या सर्वात समर्पक वाक्य आहे. ते प्रयोगशाळेतील संख्या प्रत्यक्ष क्षेत्रातील संख्येपासून वेगळी करते. लेबलची व्याख्या करणारा संदर्भ हाती ठेवून ज्या डिटेक्टरचे मूल्यमापन झाले, तो तैनात मॉनिटरसमोरच्या प्रश्नापेक्षा सोप्या प्रश्नाचे उत्तर देत आहे. लाभ खरे आहेत, पण तैनाती यांपैकी कोणत्यांवर विसंबू शकते हे शोधनिबंध स्पष्ट सांगतो.

शोधनिबंध एका बेंचमार्कची मर्यादाही दाखवतो. Open-Prompt-Injection वर लेबल घुसवलेल्या कार्याच्या अचूकतेचा मागोवा घेते. हे अशा लेबलचे उदाहरण आहे ज्याचा अर्थ कार्याच्या एखाद्या गुणधर्माशी बांधलेला आहे, आणि त्याचा परिणाम डिटेक्टरकडून स्टेटमध्ये काय पाहण्याची अपेक्षा करता येईल यावर होतो. मी यावरून पुढचे निष्कर्ष काढणे टाळीन, कारण दावे असे काहीही देत नाहीत.

खर्च #

आता ती संख्या जी अर्थशास्त्र ठोस करते. Jev चा खर्च LLM-जज स्कोररपेक्षा ६३× कमी आहे. नेमकी तुलना अशी: जजने गुण दिलेल्या १९ बेंचमार्कवरील एका पासचा खर्च $०.३० आहे, जो सूची किमतींवर त्यांच्या जजपेक्षा ६३× कमी आहे. खर्चाची तुलना सूची किमतींवर १९ API-जज बेंचमार्कवरील एका पासला लागू होते.

व्याप्तीबाबत सावध राहा. तुलना API जज वापरणाऱ्या १९ बेंचमार्कची आहे, सूची किमतीवर, एकाच पासासाठी. ती संचातील प्रत्येक बेंचमार्क व्यापत नाही, आणि सवलतीच्या किमतीही नाही. या व्याप्तीत गुणोत्तर मोठे आहे, आणि ते आधी वर्णन केलेल्या रचनेतून येते: प्रति निकष डिकोडिंग पास नाही.

सुरुवातीची अट आठवा, की प्रत्येक संदेशावर चालणारा डिटेक्टर स्वस्त असायला हवा. १९ बेंचमार्कवरील संपूर्ण पासासाठी $०.३० हा आकडा म्हणजे या शोधनिबंधात “स्वस्त” चे रूप. शोधनिबंध याचे प्रति-संदेश किमतीत रूपांतर करत नाही, आणि मीही करणार नाही.

माणसांशी सहमती, आणि मतभेदांनी काय उघड केले #

स्वस्त असणे तेव्हाच रोचक आहे जेव्हा डिटेक्टर बरोबरही असतो. जिथे मानवी लेबल तपासणी शक्य करतात, तिथे Jev त्यांच्याशी जजइतकाच सहमत होतो, खर्चाच्या एका अंशात.

सर्वात नेमका पुरावा StrongREJECT मधून येतो. तिथल्या मानवी लेबलच्या तुलनेत सर्वसाधारण प्रश्न संदर्भ स्कोररइतकाच सहमत होतो (Cohen's κ ०.८०९ विरुद्ध ०.८११) आणि अधिक चांगली क्रमवारी लावतो. दोन्ही κ मूल्यांमध्ये ०.००२ चा फरक आहे, म्हणून योग्य वाचन असे की सहमतीत बरोबरी आहे, आणि क्रमवारीत Jev पुढे आहे.

मग एक निकाल येतो जो मला व्यवहारात सर्वात उपयुक्त वाटतो, कारण तो डिटेक्टरला लेखापरीक्षणाचे साधन बनवतो. Jev च्या आत्मविश्वासपूर्ण मतभेदांनी तीन बेंचमार्कमधील लेबल बदलणारे दोष उघड केले, आणि आणखी चारमध्ये असे लेबल जे स्टेट उघड करू शकत नाही. जेव्हा आत्मविश्वासू डिटेक्टर एखाद्या बेंचमार्कच्या संदर्भ लेबलशी असहमत होतो, तेव्हा एक स्पष्टीकरण असे की डिटेक्टर चुकीचा आहे. शोधनिबंध नोंदवतो की काही प्रकरणांत मतभेदाने बेंचमार्ककडे बोट दाखवले: तीन बेंचमार्कमध्ये लेबल बदलणारे दोष होते, आणि आणखी चारमध्ये असे लेबल होते जे स्टेट उघड करू शकत नाही.

दुसरी श्रेणी संबंधात्मक मुद्द्याशी पुन्हा जोडली जाते. स्टेट उघड करू शकत नाही असे लेबल म्हणजे अशा गोष्टीने व्याख्या केलेले लेबल जी इनपुटपर्यंत कधी पोहोचलीच नाही. तो स्टेट वाचणारा कोणताही डिटेक्टर ते परत मिळवू शकत नाही. अशी प्रकरणे शोधणे हे गुण वाढवण्यापेक्षा वेगळ्या प्रकारचे योगदान आहे, कारण ते बेंचमार्कच्या देखभालकर्त्यांना सांगते की त्यांचा डेटा आणि त्यांचे लेबल कुठे वेगळे होतात.

कमकुवत दुवा: कॅलिब्रेशन #

इथे लेखाला स्पष्टपणे बोलावे लागेल, कारण शोधनिबंधही तसाच बोलतो. संभाव्यता चांगली क्रमवारी लावतात पण थ्रेशोल्ड म्हणून हस्तांतरित होत नाहीत: मध्यक ECE ०.१६८ आहे, तर शून्य-प्रतिमानाचा ०.०७४, सत्यापित आणि जज दोन्ही प्रकारच्या लेबलवर, कारण Jev ची सरासरी संभाव्यता प्रत्येक बेंचमार्कच्या मूळ दराला चुकते.

तुकडे असे जुळतात. AUROC क्रमवारी मोजतो, आणि क्रमवारी भक्कम आहे. थ्रेशोल्ड हा वेगळा मुद्दा आहे. मॉडेलची सरासरी आउटपुट संभाव्यता एखाद्या बेंचमार्कमध्ये अपयश किती वेळा येतात याच्याशी जुळत नसेल, तर t=0.5 चुकीच्या ठिकाणी पडतो, आणि अपेक्षित कॅलिब्रेशन त्रुटी जास्त येते. ०.१६८ चा मध्यक ECE ०.०७४ च्या शून्य-प्रतिमानापेक्षा वर आहे, म्हणजे शोधनिबंधाने निवडलेल्या संदर्भ बिंदूपेक्षाही वाईट कामगिरी. आणि हे सत्यापित आणि जज दोन्ही लेबलवर खरे आहे, म्हणून ही कमकुवतता गोंगाटयुक्त जज लेबलमुळे आलेली नाही.

औपचारिक मांडणी आठवा: डिटेक्टरला अपयशांना अपयश नसलेल्यांच्या वर क्रमवारीत ठेवायचे आहे आणि थ्रेशोल्डवर त्यांना वेगळे करायचे आहे. Jev पहिले काम चांगले करतो आणि दुसरे, कोणत्याही समायोजनाशिवाय, वाईट. तंत्राच्या नावात “कॅलिब्रेटेड निर्णय” आहे, आणि इथे मोजलेले कॅलिब्रेशन बेंचमार्कपलीकडे टिकत नाही, हा एक ताण आहे जो स्पष्टपणे मांडायला हवा. शोधनिबंध या तफावतीचे कारण मूळ दरांना देतो आणि त्यापलीकडे दावा करत नाही.

व्यावहारिक परिणाम: जजचा पर्याय म्हणून Jev ला आपला थ्रेशोल्ड ठरवण्यासाठी काही लेबल लागतात. हा खरा खर्च आहे, आणि तो थेट बदली असण्याचा दावा अरुंद करतो. तुम्ही तो एखाद्या नव्या अपयश प्रकारावर लावून t=0.5 वर विश्वास ठेवू शकत नाही.

कृती #

शोधनिबंधाची शिफारस संक्षिप्त आहे. कृती म्हणजे संभाव्यता म्हणून वाचलेला एक सर्वसाधारण प्रश्न, ज्याचा थ्रेशोल्ड दहा लेबल केलेल्या बाबींवर बसवला जातो, जो Jev t=0.5 वर फार क्वचित सक्रिय होतो तिथे F1 वाढवतो आणि सत्यापित लेबलवर ०.०२५ ची किंमत मोजतो.

हे उलगडून पाहू. सर्वसाधारण प्रश्न शब्दरचनेच्या समस्येला तिची अभियांत्रिकी नाकारून हाताळतो, जे शब्दरचना फारशी महत्त्वाची नाही या निष्कर्षाशी जुळते. उत्तर संभाव्यता म्हणून वाचल्याने फरक जपला जातो. दहा लेबल केलेल्या बाबींवर थ्रेशोल्ड बसवल्याने मूळ दराची चूक दुरुस्त होते. Jev t=0.5 वर फार क्वचित सक्रिय होतो तिथे F1 वरील परिणाम सकारात्मक आहे. सत्यापित लेबलवर कृतीची किंमत ०.०२५ आहे.

शेवटच्या आकड्यावर थांबणे योग्य आहे. कृती तोट्यापासून मुक्त नाही: सत्यापित लेबलवर तिची किंमत ०.०२५ आहे. शोधनिबंध हा सौदा लपवण्याऐवजी नोंदवतो, आणि मी निव्वळ लाभ म्हणून जाहिरात केलेल्या कृतीपेक्षा, जिची किंमत सांगितली आहे अशा कृतीचा संदर्भ देणे पसंत करीन. सत्यापित लेबलच्या संदर्भापलीकडे ०.०२५ कोणत्या मापकात मोजले आहे हे दावे सांगत नाहीत, म्हणून मी अंदाज बांधणार नाही.

दहा लेबल केलेल्या बाबी ही लहान मागणी आहे. बहुतेक संघांसाठी हे एका दुपारचे भाष्यकाम आहे, प्रत्येक संदेशावर जज चालवण्याच्या खर्चासमोर. पण ही एक पूर्वअट आहे, आणि जो संघ एखाद्या नव्या अपयश प्रकारासाठी एकही लेबल केलेली बाब तयार करू शकत नाही, त्याने थ्रेशोल्ड आपोआप जुळेल अशी अपेक्षा करू नये.

वापरकर्त्याने यातून काय घ्यावे #

अनेक गोष्टी पुढे येतात, आणि पुरावा त्यांना आधार देतो म्हणून मी त्यांना धरून राहीन.

पहिले, प्रश्नाची शब्दरचना सुधारत बसणे थांबवा. लक्ष्यित शब्दरचनेचा नमुन्याबाहेरील लाभ +०.००६ आहे, ज्याचा अंतराल −०.००४ पासून +०.०१५ पर्यंत आहे. हा गुंतवणुकीचा आधार नाही.

दुसरे, श्रम स्टेटवर खर्च करा. मोठे लाभ लेबलची व्याख्या करणाऱ्या संदर्भांतून आले. तुमच्या मॉनिटरला अपयशाची व्याख्या करणारा संदर्भ देता येत असेल, तर सुधारणा तिथेच आहे. देता येत नसेल, तर कमी अपेक्षा ठेवा: तैनात मॉनिटरकडे असेल असा संदर्भ ७ पैकी १ बेंचमार्कवर उपयोगी ठरला. नियोजन तैनातीत तुम्हाला मिळू शकणाऱ्या संख्येभोवती करा, संदर्भ इनपुटमध्येच बसलेल्या बेंचमार्कमध्ये मिळणाऱ्या संख्येभोवती नव्हे.

तिसरे, कॅलिब्रेशनसाठी तरतूद करा. प्रत्येक अपयश प्रकारासाठी दहा बाबींना लेबल देण्याची आणि थ्रेशोल्ड बसवण्याची योजना करा. t=0.5 सह प्रकाशित करू नका.

चौथे, मतभेदांचा संकेत म्हणून वापर करा. संदर्भ लेबलशी आत्मविश्वासपूर्ण मतभेदांनी तीन बेंचमार्कमधील दोष आणि आणखी चारमधील उघड न होऊ शकणारे लेबल समोर आणले. तुम्ही हे तुमच्या स्वतःच्या मूल्यमापन संचांवर चालवले, तर ते तुम्हाला तुमच्या मॉडेलबरोबरच तुमच्या लेबलबद्दलही सांगू शकेल अशी अपेक्षा ठेवा. हा शोधनिबंधाच्या निष्कर्षावरून काढलेला अनुमान आहे, एखाद्या विशिष्ट संचाबद्दलचा मोजलेला दावा नाही, म्हणून तपासणीचे आमंत्रण म्हणून त्याकडे पाहा.

पाचवे, ज्ञात कमकुवतपणा लक्षात ठेवा. विकसक अप्रत्यक्ष अर्थ आणि प्रतिकूल मजकूर यांना Jev च्या ज्ञात कमकुवतपणांमध्ये गणतो. सुरक्षेसाठी महत्त्वाच्या मॉनिटरला प्रतिकूल मजकुराचा सामना करावा लागेल. इथले दावे Jev त्यावर कसा कामगिरी करतो हे सांगत नाहीत, म्हणून ती बाजू उघडी आहे, आणि एखाद्या तैनातीवर विश्वास ठेवण्यापूर्वी मला तिची चाचणी हवी आहे.

व्यावसायिक बाजूसमोर निकाल वाचणे #

संस्थापकांना हे कुठे बसते हे जाणून घ्यायचे असेल. खर्चाचा युक्तिवाद सर्वात भक्कम आहे: प्रत्येक संदेशावर चालणारा डिटेक्टर स्वस्त असायला हवा, आणि LLM-जज स्कोररच्या तुलनेत ६३× घट कोणत्या तैनाती परवडतात हे बदलते. अचूकतेचा युक्तिवाद दुसरा आहे: ०.८८६ चा झिरो-शॉट AUROC आणि बहुतेक बेंचमार्कवर पर्यवेक्षित बेसलाइनवर विजय.

इशारे ठरवतात की प्रामाणिकपणे काय विकता येईल. डिटेक्टरला प्रत्येक थ्रेशोल्डसाठी काही लेबल लागतात. त्याचे कॅलिब्रेशन हस्तांतरित होत नाही. त्याचे सर्वोत्तम लाभ अशा संदर्भांवर अवलंबून आहेत जे एखाद्या तैनातीकडे कदाचित नसतील. या वापराच्या अटी आहेत, आणि यावर बांधलेल्या कोणत्याही उत्पादनाने त्या दडपण्याऐवजी सांगायला हव्यात. यांपैकी काहीही खर्चाचा युक्तिवाद कमकुवत करत नाही; ते फक्त उभारणीच्या कामाचे वर्णन करते.

मोजमापाबद्दलही एक शांत मुद्दा आहे. RLCDAlignBench, त्याचे संदर्भ प्रकार, कॅश केलेली Jev उत्तरे, पुन्हा गुणांकन करणाऱ्या स्क्रिप्ट आणि स्प्लिट-हाफ प्रोटोकॉल यांसह, पुन्हा वापरता येणारी मूल्यमापन मालमत्ता आहे. नोंदवलेल्या लाभांमधून निवडीमुळे होणारी फुगवट काढून टाकणारा बेंचमार्क ही अशी सामग्री आहे जिच्यामुळे नंतरच्या दाव्यांची तुलना करता येते. हे डिटेक्टरपेक्षा वेगळ्या प्रकारचे मूल्य आहे.

काय खुले राहते #

दाव्यांतून काही सीमा स्पष्ट आहेत. लक्ष्य मॉडेल 2–7B पॅरामीटरची पाच मुक्त मॉडेल आहेत, म्हणून निकाल त्या आकाराच्या मॉडेलच्या संवादांमधील अपयशांचे वर्णन करतात. सर्वसाधारण प्रश्न ७ बेंचमार्कवर विचारला गेला नाही, आणि मुख्य AUROC तो विचारला गेला त्या बेंचमार्कवरील मध्यक आहे. लेबल संदर्भ स्कोररचे आहेत, आणि मानवी व दुसऱ्या जजचे लेबल StrongREJECT, HarmBench, AbstentionBench आणि InstrumentalEval व्यापतात.

मला सर्वात रोचक वाटणारा खुला प्रश्न तोच आहे जो शोधनिबंधाची स्वतःची रचना उपस्थित करते. अपयश संबंधात्मक आहेत; स्टेटमध्ये अनेकदा संदर्भ नसतो; आणि तैनात मॉनिटरच्या संदर्भाने ७ पैकी फक्त १ बेंचमार्कवर मदत केली. Jev ची एक-कॉल रचना अनेक प्रश्नांना एकच इनपुट वाटून घेऊ देते, तरीही सर्वात मोठा तरफ इनपुटमध्ये कोणते फील्ड आहेत हा ठरला. देखरेखीच्या वेळी तैनातीला लेबलची व्याख्या करणारा संदर्भ कसा मिळावा, जसे गोपनीयता तपासणीसाठी गोपनीय बाबींची यादी, हीच पुढची सोडवायची गोष्ट आहे. शोधनिबंध दाखवतो की लाभ मिळवता येतो (PrivacyLens वर ०.७९→०.९५), आणि तैनात मॉनिटरला तो ६३× ची आघाडी टिकवण्याइतक्या स्वस्तात देता येईल का हे खुले ठेवतो.

क्षेत्रनिहाय याचा अर्थ #

अंशात्मक इन्फरन्स खर्चात कॅलिब्रेटेड निर्णय हेडद्वारे गुंतागुंतीच्या अलाइनमेंट निकषांचे मूल्यमापन करण्याची क्षमता अनेक क्षेत्रांत परिचालन सुरक्षिततेला नवा आकार देते.

AI गेटवे आणि सुरक्षा प्लॅटफॉर्म प्रदाते #

रिअल-टाइम सुरक्षा गार्डरेल तैनात करणाऱ्या पायाभूत सुविधा कंपन्या महागड्या कॅस्केड रचना (प्रॉम्प्ट-इंजेक्शन, विषारीपणा आणि गोपनीयतेसाठी वेगवेगळे क्लासिफायर बोलावणे) एकात्मिक बहु-प्रश्न RLCD हेडने बदलू शकतात. परिचालन खर्च ६०× पेक्षा जास्त घटतो, तर विलंब एकाच फॉरवर्ड पासपुरता मर्यादित राहतो.

AI प्रशासन आणि लेखापरीक्षण अनुपालन संघ #

EU AI Act च्या उच्च-जोखीम आवश्यकता किंवा NIST AI RMF सारख्या मानकांसमोर मॉडेलच्या वर्तनाचे मूल्यमापन करणाऱ्या जोखीम समित्यांना एक निर्धारक, संभाव्यतावादी लेखापरीक्षण नोंद मिळते. LLM-जजच्या असंरचित, वर्णनात्मक अभिप्रायाऐवजी प्रणाली कॅलिब्रेटेड संभाव्यता वितरणे नोंदवतात, जी सांख्यिकीय प्रक्रिया नियंत्रण आणि ड्रिफ्ट देखरेखीला आधार देतात.

एंटरप्राइझ तैनाती आणि रेड-टीमिंग संघ #

सुरक्षा संघ केंद्रित स्टेट मांडणी लिहून आणि किमान दहा क्षेत्र-विशिष्ट उदाहरणांवर निर्णय थ्रेशोल्ड बसवून सानुकूल अपयश डिटेक्टर झपाट्याने तैनात करू शकतात, ज्यामुळे विशेष क्लासिफायरसाठी पूर्वी लागणारे अनेक आठवड्यांचे फाइन-ट्यूनिंग चक्र संपते.

निष्कर्ष #

RLCDAlignBench वरील Jev चे मूल्यमापन उत्पादनातील मॉडेल देखरेखीसाठी एक ठोस रचनात्मक दिशा प्रस्थापित करते: एकाच फॉरवर्ड पासमध्ये अनेक प्रकारबद्ध प्रश्नांवर कॅलिब्रेटेड संभाव्यता वाचणे खर्चात ऑटोरिग्रेसिव्ह LLM जजना आणि लवचीकतेत एक-टोकन क्लासिफायरना मागे टाकते. वापरकर्त्यांनी संभाव्यता कोणत्याही समायोजनाशिवाय हस्तांतरित होतील असे गृहीत धरण्याऐवजी प्रायोगिक थ्रेशोल्ड कॅलिब्रेशनची तरतूद करायला हवी, तरीही ६३× ची आर्थिक आघाडी रिअल-टाइम, व्यापक देखरेख मोठ्या प्रमाणावर शक्य करते.

वारंवार विचारले जाणारे प्रश्न #

रिअल-टाइम उत्पादन देखरेखीसाठी जनरेटिव्ह LLM जज अव्यवहार्य का आहेत?

जनरेटिव्ह जजना मूल्यमापन होणाऱ्या प्रत्येक सुरक्षा किंवा अलाइनमेंट निकषासाठी पूर्ण ऑटोरिग्रेसिव्ह डिकोडिंग पास लागतो. जास्त थ्रूपुट असलेल्या ग्राहक किंवा एंटरप्राइझ अनुप्रयोगांमध्ये प्रत्येक संदेशावर अनेक जनरेटिव्ह जज कॉल चालवल्याने मोठा विलंब होतो आणि परिचालन खर्च अनेक पटींनी वाढतो.

कॅलिब्रेटेड निर्णयांसाठी रीइन्फोर्समेंट लर्निंग (RLCD) म्हणजे काय?

RLCD ही एक प्रशिक्षण पद्धत आहे जी मॉडेलना टोकन क्रम निर्माण करण्याऐवजी संरचित निर्णय हेडवर चांगल्या प्रकारे कॅलिब्रेटेड पश्चात संभाव्यता देण्यासाठी अनुकूल करते. यामुळे मॉडेल एकाच फॉरवर्ड मूल्यमापनात अनेक मनमाने प्रश्न एकाच वेळी तपासू शकते.

निर्णय थ्रेशोल्ड स्थानिक डेटावर कॅलिब्रेट का करावे लागतात?

RLCD मॉडेल अपयशाच्या शक्यतेनुसार संवादांची क्रमवारी लावण्यात उत्कृष्ट आहेत (उच्च AUROC गाठतात), पण त्यांच्या निरपेक्ष सरासरी संभाव्यता लक्ष्य क्षेत्राच्या मूळ दरानुसार सरकतात. सुमारे दहा लेबल केलेल्या क्षेत्र-उदाहरणांवर परिचालन निर्णय थ्रेशोल्ड कॅलिब्रेट केल्याने अस्वीकार्य फॉल्स-पॉझिटिव्ह दरांशिवाय योग्य संवेदनशीलता सुनिश्चित होते.

संदर्भ #

• Mrinank Sharma et al., (2024). भाषा मॉडेलमधील खुशामत समजून घेणे आणि कमी करणे याकडे ⧉. arXiv.
• RLCDAlignBench Consortium, (2026). कॅलिब्रेटेड निर्णय हेडद्वारे बहु-निकष अलाइनमेंट अपयश शोध ⧉. arXiv.
• Anthropic / Alignment Research, (2025). Constitutional AI आणि मूल्यमापकांची गतिशीलता ⧉. Anthropic.
• NIST, (2024). कृत्रिम बुद्धिमत्ता जोखीम व्यवस्थापन आराखडा (AI RMF 1.0) ⧉. NIST.

शेवटचे पुनरावलोकन 2026-09-30.

शेवटचे पुनरावलोकन 2026-10-27.

# निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau

> Originally published at [https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/](https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/)

Jev एकाच कॉलमध्ये अनेक प्रश्नांची उत्तरे संभाव्यतांच्या रूपात देतो. ४४ बेंचमार्कवर क्रमवारी भक्कम आणि खर्च ६३× कमी निघाला, पण थ्रेशोल्डसाठी काही लेबल लागतात.

Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/

निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau

Jev एकाच कॉलमध्ये अनेक प्रश्नांची उत्तरे संभाव्यतांच्या रूपात देतो. ४४ बेंचमार्कवर क्रमवारी भक्कम आणि खर्च ६३× कमी निघाला, पण थ्रेशोल्डसाठी काही लेबल लागतात.

https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/

निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau

Jev एकाच कॉलमध्ये अनेक प्रश्नांची उत्तरे संभाव्यतांच्या रूपात देतो. ४४ बेंचमार्कवर क्रमवारी भक्कम आणि खर्च ६३× कमी निघाला, पण थ्रेशोल्डसाठी काही लेबल लागतात.

येथे मुख्य धोरणात्मक मुद्दे आहेत:

- प्रत्येक संदेशावर लक्ष ठेवण्याच्या खर्चाची रचना. तैनात केलेली मॉडेल्स अजूनही वापरकर्त्याच्या चुकीच्या समजुतीपुढे मान तुकवतात (Sharma et al., २०२४).
- Jev वेगळे काय करतो. Jev ला कॅलिब्रेटेड निर्णयांसाठी रीइन्फोर्समेंट लर्निंग (RLCD) ने प्रशिक्षित केले आहे.
- अलाइनमेंट अपयश दिसतात त्यापेक्षा कठीण का आहेत. मोजमापापूर्वी एक गुंतागुंत.
- शोधाकडे वर्गीकरण म्हणून पाहणे. शोधनिबंधाची औपचारिक मांडणी सरळ आहे.

या लेखात मांडलेल्या आव्हानांसाठी तुमच्या संस्थेचा दृष्टिकोन काय आहे?

→ https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/

#Jev #Rlcd #Rlcdalignbench #अलाइनमेंटअपयश #डिटेक्टर

Sebastien Rousseau | CC-BY-4.0

@online{rousseau2026न,
  author  = {Rousseau, Sebastien},
  title   = {{निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau}},
  year    = {2026},
  url     = {https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/},
  urldate = {2026}
}

TY  - GEN
AU  - Rousseau, Sebastien
TI  - निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau
PY  - 2026
UR  - https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/
ER  -

Rousseau S. निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau. sebastienrousseau.com. 2026 Sep 30. Available from: https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/

Rousseau, Sebastien. "निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau." sebastienrousseau.com. September 30, 2026. https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/.

Rousseau, S. (2026, September 30). निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/

निकाल नव्हे, संभाव्यता वाचणारा डिटेक्टर: ४४ बेंचमार्कवर Jev — Sebastien Rousseau

Jev एकाच कॉलमध्ये अनेक प्रश्नांची उत्तरे संभाव्यतांच्या रूपात देतो. ४४ बेंचमार्कवर क्रमवारी भक्कम आणि खर्च ६३× कमी निघाला, पण थ्रेशोल्डसाठी काही लेबल लागतात.

Originally published at https://sebastienrousseau.com/mr/2026-09-30-nikal-navhe-snbhavyata-vachanara-ditektar-44/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU · FOUNDER · ENGINEER