व्यापक लीडरबोर्डवर मॉडेलचे बेंचमार्किंग केल्यामुळे ते सामान्य ज्ञान (trivia) आणि प्रमाणित परीक्षा (standardized tests) किती चांगल्या प्रकारे हाताळते हे समजते. परंतु, तुमच्या प्रोडक्शन सिस्टम्सना प्रत्यक्षात ज्या गुंतागुंतीच्या आणि मर्यादित समस्यांना सामोरे जावे लागते, त्यातून ते कसे तर्क (reasoning) करेल याबद्दल ते तुम्हाला जवळजवळ काहीच सांगत नाही. कोणतेही लार्ज लँग्वेज मॉडेल वापरकर्त्यांपर्यंत पोहोचवण्यापूर्वी, तुमच्या ॲप्लिकेशनला आवश्यक असलेल्या विशिष्ट संज्ञानात्मक पॅटर्नची (cognitive patterns) चाचणी घेणारे एक साधन (harness) तुमच्याकडे असणे आवश्यक आहे. रिझनिंग बेंचमार्क्स हे असे क्षेत्र आहे जिथे मॉडेल्स स्वतःला चॅटबॉट्सपासून वेगळे सिद्ध करतात.

हे मार्गदर्शक तुम्हाला शून्यापासून एक केंद्रित रिझनिंग बेंचमार्क तयार करण्यास मदत करेल. तुम्ही तीन भिन्न आर्किटेक्चरची तुलना कराल: DeepSeek R1 671B MoE, Llama 3.3 70B, आणि Qwen 3 32B. GPU क्लस्टर्स एकत्र करण्याऐवजी, तुम्ही हे तिन्ही मॉडेल्स Oxlo.ai द्वारे चालवाल. मूल्यमापनासाठी, तुम्ही Kimi K2.6 चा 'जज' म्हणून वापर कराल, जो रिझनिंगची स्पष्टता, अचूकता आणि कोडची गुणवत्ता यावर आधारित आउटपुटला स्कोअर देईल.

रिझनिंग सर्वात आधी का कोलमडते?

प्रोडक्शनमधील त्रुटी सहसा व्याकरणाच्या चुका किंवा नकार (refusals) स्वरूपात नसतात. त्या सूक्ष्म तार्किक चुकांच्या स्वरूपात असतात. एखादे मॉडेल एखादी अट (constraint) न समजून घेताना, एखादी पायरी वगळताना किंवा प्रक्रियेच्या दरम्यान एखादे व्हेरिएबल (variable) न सांगता बदलताना आत्मविश्वासाने मजकूर तयार करू शकते. सार्वजनिक बेंचमार्क्समध्ये अनेकदा खोलीपेक्षा (depth) व्याप्तीला (breadth) जास्त महत्त्व दिले जाते, त्यामुळे एखादे मॉडेल कठीण कॉम्बिनेटोरियल समस्या (combinatorial problem) न सोडवताही चांगले स्कोअर मिळवू शकते.

एक लक्ष्यित (targeted) बेंचमार्क या समस्येला तोंड देते. ते प्रत्येक मॉडेलला एकच मर्यादित ऑप्टिमायझेशन टास्क देते, ट्रॅसेबल 'चेन ऑफ थॉट' (chain of thought) ची मागणी करते आणि तयार केलेले उत्तर खरोखर नियमांचे पालन करते का, हे मोजते. जर एखादे मॉडेल डिस्क्रीट मॅथमधील (discrete math) समस्यांवर सातत्याने तर्क करू शकत नसेल, तर ते तुमच्या इन्व्हेंटरी अलोकेशन, शेड्युलिंग इंजिन किंवा रिसोर्स राउटरला देखील विश्वासार्हतेने हाताळू शकणार नाही.

मॉडेल्स आणि प्लॅटफॉर्म

DeepSeek R1 671B MoE मध्ये 'मिक्सचर-ऑफ-एक्सपर्ट्स' (mixture-of-experts) डिझाइन वापरले जाते. कोणत्याही दिलेल्या टोकनसाठी त्याच्या ६७१ अब्ज पॅरामीटर्सपैकी केवळ काही भाग सक्रिय होतो, ज्यामुळे खर्च-परफॉर्मन्स कर्व्ह (cost-to-performance curve) आणि कधीकधी त्याच्या रिझनिंगची पद्धत बदलते. Llama 3.3 70B हे एक 'डेन्स' (dense) मॉडेल आहे, तर Qwen 3 32B हे लहान स्केलवर असून त्यात प्रबळ बहुभाषिक आणि कोडिंग क्षमता आहेत. या तिची तुलना केल्यामुळे तुम्हाला समजेल की रिझनिंगची गुणवत्ता एकूण पॅरामीटर संख्या, सक्रिय पॅरामीटर संख्या किंवा ट्रेनिंग पद्धतीवर अवलंबून आहे की नाही.

Oxlo.ai या मॉडेल्सना एका युनिफाइड API द्वारे होस्ट करते. तुम्हाला इन्फरन्स इन्फ्रास्ट्रक्चर व्यवस्थापित करण्याची किंवा वेगवेगळ्या प्रदात्यांच्या (providers) करारांशी जुळवून घेण्याची गरज नाही. हे प्लॅटफॉर्म प्रति-टोकन (per-token) किमतीऐवजी प्रति-रिक्वेस्ट (per-request) किंमत वापरते. दोन हजार शब्दांचा सिस्टम प्रॉम्प्ट आणि एक ओळीचा संक्षिप्त प्रॉम्प्ट, या दोघांची किंमत अगदी सारखीच असते. हा तपशील ऐकायला जितका साधा वाटतो, त्यापेक्षा तो जास्त महत्त्वाचा आहे. याचा अर्थ असा की, तुम्ही इनपुट टोकनचा खर्च वाढण्याची चिंता न करता सविस्तर सूचना लिहू शकता, तपशीलवार फॉरमॅटिंग आवश्यकता समाविष्ट करू शकता आणि 'फ्यू-शॉट' (few-shot) उदाहरणे जोडू शकता. तुम्ही कॉलसाठी पैसे देता, शब्दांच्या संख्येसाठी नाही.

तुम्हाला Python 3.10 किंवा त्यापेक्षा नवीन आवृत्ती, OpenAI Python लायब्ररी आणि Oxlo.ai API की आवश्यक असेल.

स्टेप १: एंडपॉइंटशी कनेक्ट करा

Oxlo.ai हे OpenAI-सुसंगत (compatible) API प्रदान करत असल्यामुळे, इंटिग्रेशन करणे सोपे आहे. OpenAI SDK ला Oxlo च्या बेस URL वर पॉइंट करा, तुमची API की वापरा आणि DeepSeek R1 ला एका हलक्या (lightweight) रिक्वेस्टद्वारे कनेक्शन तपासा. 'सॅनिटी चेक' (sanity check) वगळू नका. लॅटन्सी (latency) तपासा, मॉडेल आयडेंटिफायर ओळखला जात आहे याची खात्री करा आणि तुमचे एन्व्हायर्नमेंट तुम्ही साठवण्यास इच्छित असलेल्या रिस्पॉन्स फॉरमॅटला स्ट्रीम किंवा बफर करू शकते याची खात्री करा. एकदा हँडशेक यशस्वी झाले की, तुम्ही एक स्ट्रिंग बदलून तिन्ही मॉडेल्सना संबोधित करू शकणारे एक सिंगल क्लायंट तयार करता.

स्टेप २: टास्क डिझाइन करा

अशी समस्या निवडा ज्यामध्ये पायरी-पायरीने तर्क (step-by-step logic) आवश्यक असेल आणि ज्याचे उत्तर वस्तुनिष्ठपणे मोजता येईल. 'बिन-पॅकिंग' (Bin-packing) यासाठी अत्यंत प्रभावी ठरते. हे NP-hard आहे, ज्याचा अर्थ असा की 'ग्रीडी ह्युरिस्टिक्स' (greedy heuristics) ठराविक पद्धतीने अपयशी ठरतात आणि यामुळे मॉडेलला एकाच वेळी अनेक मर्यादांचा (constraints) मागोवा घेण्यास भाग पाडले जाते. विविध आकाराच्या वस्तू ठराविक क्षमता असलेल्या बिन्समध्ये (bins) मर्यादा न ओलांडता बसवणे आवश्यक असते.

प्रॉम्प्ट अशा प्रकारे तयार करा की मॉडेलला दोन गोष्टी कराव्या लागतील: प्रथम त्याची तर्क प्रक्रिया (reasoning process) स्पष्ट करणे आणि नंतर ती समस्या सोडवणारा कार्यरत Python कोड प्रदान करणे. असा सिस्टम प्रॉम्प्ट वापरा जो मॉडेलला कोणताही कोड लिहिण्यापूर्वी त्याची 'चेन ऑफ थॉट' (chain-of-thought) दाखवण्याची स्पष्ट मागणी करेल. हे विशेषतः DeepSeek R1 साठी महत्त्वाचे आहे, जे विस्तारित रिझनिंग ट्रेससाठी (reasoning traces) ऑप्टिमाइझ केलेले आहे. मॉडेल क्षमतेच्या तपासणीद्वारे (capacity checks) विचार करत आहे की केवळ ट्रेनिंग डेटाच्या आधारे पॅटर्न-मॅचिंग करत आहे, हे तुम्हाला पाहायचे आहे. एक चांगला टास्क इतका आव्हानात्मक (adversarial) असावा की टेंप्लेट आधारित उत्तरे अपयशी ठरतील.

स्टेप ३: बेंचमार्क चालवा

DeepSeek R1, Llama 3.3 70B, आणि Qwen 3 32B ला एकसारखाच प्रॉम्प्ट द्या. केवळ शेवटचे कोड ब्लॉक्स न घेता, संपूर्ण मजकूर प्रतिसाद (text responses) कॅप्चर करा. ते टाइमस्टॅम्प आणि मॉडेल आयडेंटिफायरसह साठवा. Oxlo.ai प्रति विनंती (request) शुल्क आकारत असल्याने, पैसे वाचवण्यासाठी तुम्हाला तुमचा प्रॉम्प्ट संक्षिप्त (truncate) करण्याची किंवा स्पष्टीकरण देणाऱ्या सूचना काढून टाकण्याची गरज नाही. तुम्ही अचूक राहू शकता. ही स्थिरता तुम्हाला खर्चाची चिंता न करता प्रॉम्प्ट डिझाइनमध्ये सुधारणा करण्यास अनुमती देते, ज्यामुळे अधिक स्वच्छ प्रयोग आणि पुनरुत्पादनीय (reproducible) निकाल मिळतात.

जर तुमचे बजेट परवानगी देत असेल, तर प्रत्येक मॉडेल अनेक वेळा चालवा. रिझनिंग मॉडेल्स (Reasoning models) स्टोकॅस्टिक जनरेशनमध्ये (stochastic generations) भिन्न असू शकतात, आणि तुम्हाला हे जाणून घ्यायचे आहे की उच्च स्कोअर ही सातत्यपूर्ण क्षमता आहे की केवळ एक नशीबवान नमुना (lucky sample).

पायरी ४: LLM जजद्वारे ग्रेडिंग करा

मॅन्युअल स्कोअरिंग मोठ्या प्रमाणावर करता येत नाही, परंतु केवळ संख्यात्मक रुब्रिक्समुळे (numeric rubrics) बारकावे सुटतात. यावरचा सुवर्णमध्य म्हणजे LLM जज. येथे, तुम्ही Kimi K2.6 वापरणार आहात. त्याला मूळ समस्या, रुब्रिक आणि प्रत्येक संभाव्य प्रतिसाद द्या. त्याला तीन विशिष्ट आयामांचे (dimensions) मूल्यमापन करण्यास सांगा:

  • Reasoning clarity (तर्क स्पष्टता): स्पष्टीकरण खरोखर तर्गाचा मागोवा घेते की केवळ वरवरचे भाष्य करते?
  • Correctness (अचूकता): प्रस्तावित उपाय सर्व नमूद केलेल्या अटी (constraints) पूर्ण करतो का?
  • Code quality (कोडची गुणवत्ता): Python कोड स्वच्छ, रन करण्यायोग्य आणि स्पष्ट त्रुटींपासून (bugs) मुक्त आहे का?

जजला JSON फॉरमॅटमध्ये स्कोअर परत करण्यास सांगा. स्ट्रक्चर्ड आउटपुटमुळे निकालांची तुलना करणे (diff), ट्रेंड्स प्लॉट करणे आणि डाउनस्ट्रीम ऑटोमेशनमध्ये वापरणे सोपे होते. जज प्रॉम्प्ट कडक ठेवा. जर तुम्ही "उत्तराला रेटिंग द्या" सारखी अस्पष्ट सूचना दिली, तर तुम्हाला अस्पष्ट निकाल मिळतील. त्याऐवजी, एक योग्य bin-packing उपाय म्हणजे काय, हे स्पष्टपणे परिभाषित करा. क्षमता (Capacities) ओलांडली जाऊ नये. प्रत्येक वस्तू नियुक्त (assigned) केलेली असावी. कोड सिंटॅक्टिकली वैध (syntactically valid) असावा. तुमचे निकष जितके ठोस असतील, तितके तुमचे ग्रेड अधिक विश्वसनीय होतील.

नेहमी जजची तपासणी (spot-check) करा. जर Kimi K2.6 केवळ वरवरच्या चकाकीमुळे एखाद्या मॉडेलला सातत्याने जास्त रेटिंग देत असेल, तर तुमचा बेंचमार्क चुकीचा आहे. मानवी ऑडिटचा एक छोटा स्तर 'garbage-in-garbage-out' मूल्यमापन टाळतो.

पायरी ५: रिपोर्ट तयार करा

JSON स्कोअर एकत्रित करा आणि त्यांना मॉडेलच्या मूळ आउटपुटमधील उतार्‍यांशी (excerpts) जोडा. हे सर्व तुमच्या रिपॉझिटरीमधील एकाच फाईलमध्ये ठेवा. जेव्हा तुम्ही मॉडेलची आवृत्ती अपडेट करता किंवा प्रॉम्प्टमध्ये बदल करता, तेव्हा तुमच्या pull request मधील फरक नेमका कसा बदलला हे दिसून येते. एक चांगल्या प्रकारे राखलेला बेंचमार्क हा जिवंत दस्तऐवज (living documentation) बनतो. तुमचा प्रोडक्शन पाईपलाईन दुसऱ्या मॉडेलऐवजी एक विशिष्ट मॉडेल का वापरते याचे ते समर्थन करते आणि वापरकर्त्यांपर्यंत पोहोचण्यापूर्वीच 'silent regressions' शोधून काढते.

रिपोर्टची रचना अशी करा की तुमचा सहकारी कोड न चालवता तो वाचू शकेल. यामध्ये समस्या विधान (problem statement), प्रॉम्प्ट टेम्पलेट, स्कोअर आणि प्रत्येक मॉडेलच्या reasoning trace मधील प्रतिनिधीत्व करणारे उतारे समाविष्ट करा. पारदर्शकता महत्त्वाची आहे. जर DeepSeek R1 चा स्कोअर जास्त असेल पण त्याने एखादी अट चुकीची सांगितली (hallucinates a constraint), तर ते मजकूर उतार्‍यात स्पष्टपणे दिसले पाहिजे, केवळ सरासरीमध्ये दबलेले नसावे.

पाईपलाईनचे ऑटोमेशन (Automating the Pipeline)

जो बेंचमार्क फक्त तुमच्या लॅपटॉपवर असतो, तो एका आठवड्यात विसरला जातो. त्याला 'nightly CI job' मध्ये हलवा. दर रात्री, harness सुरू होतो, Oxlo.ai वरील सध्याच्या मॉडेल आवृत्त्यांना क्वेरी करतो, bin-packing टास्क चालवतो, आउटपुटला ग्रेड देतो आणि निकाल commit करतो. जर मॉडेल अपडेटमुळे अचूकतेमध्ये दहा अंकांची घट झाली, तर तुमच्या वापरकर्त्यांना कळण्यापूर्वीच तुम्हाला ते समजेल.

एकदा का मुख्य harness स्थिर झाला की, त्याचा विस्तार करा. प्रॉम्प्टमध्ये अनावश्यक कागदपत्रे भरून आणि शेवटी bin-packing प्रश्न ठेवून long-context व्हेरिएंट्स तपासा. जर गोंधळामुळे (noise) तर्कसंगतता कोलमडली, तर मोठ्या context windows चा काहीही उपयोग नाही. जेव्हा सिग्नल दहा हजार टोकन्सच्या विचलित करणाऱ्या गोष्टींमध्ये दडलेला असतो, तेव्हा कोणती मॉडेल्स तार्किक शिस्त (logical discipline) राखतात ते पहा.

मुख्य निष्कर्ष (The Real Takeaway)

सार्वजनिक लीडरबोर्ड सामान्य ज्ञानाचे मोजमाप करतात. तुमचे ॲप्लिकेशन काहीतरी अधिक मर्यादित आणि कठीण गोष्टीचे मोजमाप करते. एक साधा, पुन्हा पुन्हा वापरता येण्याजोगा harness, जो मॉडेल्सना constrained optimization द्वारे तर्क करण्यास भाग पाडतो, त्यांना सुसंगत निकषांसह ग्रेड देतो आणि निकालांचे git मध्ये व्हर्जनिंग करतो, तो तुम्हाला कोणत्याही एकत्रित स्कोअरपेक्षा अधिक उपयुक्त माहिती देईल. तुमच्या समस्येला साजेसा बेंचमार्क तयार करा, तुमच्यासाठी महत्त्वाच्या आर्किटेक्चरवर तो चालवा आणि निकालांना तुमचा प्रोडक्शन निर्णय घेू द्या.

Source: DeepSeek R1 Model Architecture and Benchmarks

Community: GyaanSetu AI on Telegram