વ્યાપક લીડરબોર્ડ્સ પર મોડેલનું બેન્ચમાર્કિંગ તમને જણાવે છે કે તે ટ્રિવિયા અને પ્રમાણિત પરીક્ષાઓને કેટલી સારી રીતે હેન્ડલ કરે છે. તે તમારા પ્રોડક્શન સિસ્ટમ્સ ખરેખર જે અસ્તવ્યસ્ત અને મર્યાદિત સમસ્યાઓનો સામનો કરે છે, તેના દ્વારા તે કેવી રીતે તર્ક (reasoning) કરશે તે વિશે લગભગ કંઈ જ કહેતું નથી. કોઈપણ લાર્જ લેંગ્વેજ મોડેલ યુઝર્સ સુધી પહોંચાડતા પહેલા, તમારે એવા હાર્નેસ (harness) ની જરૂર છે જે તમારા એપ્લિકેશન દ્વારા માંગવામાં આવતા ચોક્કસ કોગ્નિટિવ પેટર્ન્સ પર દબાણ લાવે. રીઝનિંગ બેન્ચમાર્ક એ જગ્યા છે જ્યાં મોડેલ્સ ચેટબોટ્સથી અલગ પડે છે.

આ માર્ગદર્શિકા શૂન્યથી એક કેન્દ્રિત રીઝનિંગ બેન્ચમાર્ક બનાવવાની પ્રક્રિયા સમજાવે છે. તમે ત્રણ અલગ-અલગ આર્કિટેક્ચર્સની તુલના કરશો: DeepSeek R1 671B MoE, Llama 3.3 70B, અને Qwen 3 32B. GPU ક્લસ્ટર્સ ભેગા કરવાને બદલે, તમે આ ત્રણેયને Oxlo.ai દ્વારા ચલાવશો. મૂલ્યાંકન માટે, તમે રીઝનિંગની સ્પષ્ટતા, સચોટતા અને કોડની ગુણવત્તા પર આઉટપુટને સ્કોર કરવા માટે Kimi K2.6 નો જજ તરીકે ઉપયોગ કરશો.

શા માટે રીઝનિંગ સૌથી પહેલા નિષ્ફળ જાય છે

પ્રોડક્શન નિષ્ફળતાઓ ભાગ્યે જ વ્યાકરણની ભૂલો અથવા ઇનકાર જેવી દેખાય છે. તે સૂક્ષ્મ તાર્કિક ભૂલો જેવી લાગે છે. એક મોડેલ કોઈ મર્યાદાને ખોટી રીતે સમજતા, કોઈ સ્ટેપ સ્કીપ કરતા અથવા પ્રક્રિયાની વચ્ચે કોઈ વેરિએબલને શાંતિથી બદલી નાખતા આત્મવિશ્વાસપૂર્ણ લખાણ જનરેટ કરી શકે છે. પબ્લિક બેન્ચમાર્ક ઘણીવાર ઊંડાઈ કરતાં વ્યાપને વધુ મહત્વ આપે છે, તેથી મોડેલ કોઈપણ અઘરી કોમ્બિનેટોરિયલ સમસ્યા ઉકેલ્યા વિના પણ સારું સ્કોર કરી શકે છે.

એક ટાર્ગેટેડ બેન્ચમાર્ક આ મુદ્દાને સ્પષ્ટ કરે છે. તે દરેક મોડેલને સમાન મર્યાદિત ઓપ્ટિમાઇઝેશન ટાસ્ક આપે છે, ટ્રેસેબલ ચેઈન ઓફ થોટ (chain of thought) ની માંગ કરે છે, અને જનરેટ થયેલું સોલ્યુશન ખરેખર નિયમોનું પાલન કરે છે કે નહીં તે માપે છે. જો મોડેલ ડિસ્ક્રીટ મેથ્સ (discrete math) દ્વારા સતત તર્ક કરી શકતું નથી, તો તે તમારા ઇન્વેન્ટરી એલોકેશન, શેડ્યુલિંગ એન્જિન અથવા રિસોર્સ રાઉટરને પણ વિશ્વસનીય રીતે હેન્ડલ કરી શકશે નહીં.

મોડેલ્સ અને પ્લેટફોર્મ

DeepSeek R1 671B MoE 'mixture-of-experts' ડિઝાઇનનો ઉપયોગ કરે છે. કોઈપણ આપેલ ટોકન માટે તેના 671 બિલિયન પેરામીટર્સનો માત્ર એક ભાગ જ સક્રિય થાય છે, જે કોસ્ટ-ટુ-પરફોર્મન્સ કર્વ અને ક્યારેક તેના રીઝનિંગના સ્વરૂપને બદલી નાખે છે. Llama 3.3 70B એક ડેન્સ મોડેલ છે, અને Qwen 3 32B મજબૂત મલ્ટિલિંગ્વલ અને કોડિંગ ક્ષમતાઓ સાથે નાના સ્કેલ પર છે. આ ત્રણેયની તુલના કરવાથી તમને ખબર પડશે કે રીઝનિંગની ગુણવત્તા કુલ પેરામીટર કાઉન્ટ, એક્ટિવ પેરામીટર કાઉન્ટ અથવા ટ્રેનિંગ મેથડોલોજી સાથે જોડાયેલી છે કે નહીં.

Oxlo.ai આ મોડેલ્સને એક યુનિફાઇડ API દ્વારા હોસ્ટ કરે છે. તમારે ઇન્ફરન્સ ઇન્ફ્રાસ્ટ્રક્ચર મેનેજ કરવાની અથવા અલગ અલગ પ્રોવાઇડર એગ્રીમેન્ટ્સ સાથે ઝઘડવાની જરૂર નથી. પ્લેટફોર્મ પર્-ટોકન પ્રાઇસિંગને બદલે પર્-રિકવેસ્ટ પ્રાઇસિંગનો ઉપયોગ કરે છે. બે હજાર શબ્દોનો સિસ્ટમ પ્રોમ્પ્ટ એક ટૂંકા વન-લાઇનર જેટલો જ ખર્ચાળ છે. આ વિગત જેટલી સાંભળવામાં લાગે છે તેના કરતા વધુ મહત્વની છે. તેનો અર્થ એ છે કે તમે ઇનપુટ ટોકન ખર્ચ વધારાની ચિંતા કર્યા વિના વિસ્તૃત સૂચનાઓ લખી શકો છો, વિગતવાર ફોર્મેટિંગ જરૂરિયાતો સામેલ કરી શકો છો અને few-shot ઉદાહરણો ઉમેરી શકો છો. તમે કોલ માટે ચૂકવણી કરો છો, શબ્દભંડોળ (verbosity) માટે નહીં.

તમારે Python 3.10 અથવા નવું, OpenAI Python લાઇબ્રેરી અને Oxlo.ai API કીની જરૂર પડશે.

સ્ટેપ 1: એન્ડપોઇન્ટ સાથે કનેક્ટ કરો

Oxlo.ai એક OpenAI-સુસંગત API પ્રદાન કરતું હોવાથી, ઇન્ટિગ્રેશન સરળ છે. OpenAI SDK ને Oxlo બેઝ URL પર પોઇન્ટ કરો, તમારી API કી નાખો અને DeepSeek R1 ને હળવા વજનના રિકવેસ્ટ સાથે કનેક્શન ચકાસો. સેનિટી ચેક (sanity check) ને અવગણશો નહીં. લેટન્સી (latency) ની ખાતરી કરો, મોડેલ આઇડેન્ટિફાયર ઓળખાય છે તેની ખાતરી કરો, અને ખાતરી કરો કે તમારું એન્વાયરમેન્ટ તમે સ્ટોર કરવા માંગતા હોવ તે રિસ્પોન્સ ફોર્મેટને સ્ટ્રીમ અથવા બફર કરી શકે છે. એકવાર હેન્ડશેક કામ કરી જાય પછી, તમારી પાસે એક સિંગલ ક્લાયન્ટ હશે જે માત્ર એક સ્ટ્રિંગ બદલીને ત્રણેય મોડેલ્સને એડ્રેસ કરી શકશે.

સ્ટેપ 2: ટાસ્ક ડિઝાઇન કરો

એવી સમસ્યા પસંદ કરો જેમાં સ્ટેપ-બાય-સ્ટેપ લોજિકની જરૂર હોય અને જેનો ઉકેલ નિષ્પક્ષ રીતે માપી શકાય તેવો હોય. Bin-packing અસાધારણ રીતે સારું કામ કરે છે. તે NP-hard છે, જેનો અર્થ છે કે ગ્રીડી હ્યુરિસ્ટિક્સ (greedy heuristics) અનુમાનિત રીતે નિષ્ફળ જાય છે, અને તે મોડેલને એકસાથે અનેક મર્યાદાઓ પર નજર રાખવા માટે મજબૂર કરે છે. વિવિધ કદની વસ્તુઓ મર્યાદા ઓળંગ્યા વિના નિશ્ચિત ક્ષમતાવાળા બિન (bins) માં સમાવી જોઈએ.

પ્રોમ્પ્ટને એવી રીતે તૈયાર કરો કે મોડેલે બે વસ્તુઓ કરવી પડે: તેની રીઝનિંગ પ્રક્રિયાનું વર્ણન કરવું, અને પછી તે ઇન્સ્ટન્સને ઉકેલતો કાર્યરત Python કોડ આપવો. એવા સિસ્ટમ પ્રોમ્પ્ટનો ઉપયોગ કરો જે મોડેલને કોઈપણ કોડ લખતા પહેલા તેની ચેઈન-ઓફ-થોટ (chain-of-thought) બતાવવાની સ્પષ્ટ માંગ કરે છે. આ ખાસ કરીને DeepSeek R1 માટે મહત્વપૂર્ણ છે, જે લાંબા રીઝનિંગ ટ્રેસ માટે ઓપ્ટિમાઇઝ કરવામાં આવ્યું છે. તમે જોવા માંગો છો કે મોડેલ ક્ષમતા ચકાસણી (capacity checks) દ્વારા વિચારી રહ્યું છે કે ફક્ત ટ્રેનિંગ ડેટા સામે પેટર્ન-મેચિંગ કરી રહ્યું છે. એક સારો ટાસ્ક એટલો એડવર્સરીયલ (adversarial) હોવો જોઈએ કે ટેમ્પલેટ રિસ્પોન્સ નિષ્ફળ જાય.

સ્ટેપ 3: બેન્ચમાર્ક ચલાવો

DeepSeek R1, Llama 3.3 70B, અને Qwen 3 32B ને સમાન પ્રોમ્પ્ટ આપો. માત્ર અંતિમ કોડ બ્લોક્સ જ નહીં, પણ સંપૂર્ણ ટેક્સ્ટ પ્રતિસાદો (responses) મેળવો. તેને ટાઈમસ્ટેમ્પ અને મોડેલ આઈડેન્ટિફાયર સાથે સ્ટોર કરો. Oxlo.ai દરેક રિક્વેસ્ટ દીઠ ચાર્જ લે છે, તેથી પૈસા બચાવવા માટે તમારે તમારા પ્રોમ્પ્ટને ટૂંકો કરવાની કે સ્પષ્ટતા આપતી સૂચનાઓ કાઢી નાખવાની જરૂર નથી. તમે ચોકસાઈ રાખી શકો છો. આ સ્થિરતા તમને ખર્ચની ચિંતા વગર પ્રોમ્પ્ટ ડિઝાઇનમાં સુધારો કરવાની મંજૂરી આપે છે, જે વધુ સ્વચ્છ પ્રયોગો અને પુનરાવર્તિત કરી શકાય તેવા પરિણામો તરફ દોરી જાય છે.

જો તમારું બજેટ પરવાનગી આપે તો દરેક મોડેલને અનેક વખત ચલાવો. રીઝનિંગ મોડેલ્સ સ્ટોકેસ્ટિક જનરેશન (stochastic generations) દરમિયાન અલગ-અલગ હોઈ શકે છે, અને તમે જાણવા માંગો છો કે ઊંચો સ્કોર સતત ક્ષમતા દર્શાવે છે કે તે માત્ર નસીબજોગે મળેલું સેમ્પલ છે.

સ્ટેપ 4: LLM જજ દ્વારા ગ્રેડિંગ કરો

મેન્યુઅલ સ્કોરિંગ મોટા પાયે શક્ય નથી, પરંતુ માત્ર સંખ્યાત્મક રૂબ્રિક્સ (numeric rubrics) સૂક્ષ્મ તફાવતોને ચૂકી જાય છે. મધ્યમ માર્ગ LLM જજ છે. અહીં, તમે Kimi K2.6 નો ઉપયોગ કરશો. તેને મૂળ સમસ્યા, રૂબ્રિક અને દરેક ઉમેદવાર પ્રતિસાદ આપો. તેને ત્રણ ચોક્કસ પરિમાણોનું મૂલ્યાંકન કરવા કહો:

  • Reasoning clarity (તર્કની સ્પષ્ટતા): શું સમજૂતી ખરેખર તર્કને અનુસરે છે, કે પછી તે માત્ર ઉપરછલ્લી છે?
  • Correctness (ચોકસાઈ): શું સૂચવેલ ઉકેલ તમામ જણાવેલ મર્યાદાઓ (constraints) ને સંતોષે છે?
  • Code quality (કોડની ગુણવત્તા): શું Python કોડ સ્વચ્છ, રન કરી શકાય તેવો અને સ્પષ્ટ બગ્સ વગરનો છે?

જજને JSON ફોર્મેટમાં સ્કોર આપવા માટે સૂચના આપો. સ્ટ્રક્ચર્ડ આઉટપુટથી પરિણામોની તુલના કરવી (diff), ટ્રેન્ડ્સ જોવા અને ડાઉનસ્ટ્રીમ ઓટોમેશનમાં ફીડ કરવું સરળ બને છે. જજ પ્રોમ્પ્ટને કડક રાખો. જો તમે તેને "જવાબને રેટ કરો" જેવી અસ્પષ્ટ સૂચના આપશો, તો તમને અસ્પષ્ટ પરિણામો મળશે. તેના બદલે, bin-packing ના સાચા ઉકેલ તરીકે શેને ગણવું તે વ્યાખ્યાયિત કરો. ક્ષમતા (capacities) ઓળંગવી જોઈએ નહીં. દરેક આઇટમ અસાઇન કરવી જ જોઈએ. કોડ સિન્ટેક્ટિકલી (syntactically) માન્ય હોવો જોઈએ. તમારા માપદંડ જેટલા વધુ નક્કર હશે, તમારા ગ્રેડ્સ તેટલા જ વધુ વિશ્વસનીય બનશે.

હંમેશા જજનું સ્પોટ-ચેક કરો. જો Kimi K2.6 માત્ર ઉપરછલ્લી ચમકને કારણે સતત એક મોડેલને વધુ રેટિંગ આપે છે, તો તમારું બેન્ચમાર્ક ખોટું છે. માનવીય ઓડિટનું એક નાનું સ્તર 'ગાર્બેજ-ઇન-ગાર્બેજ-આઉટ' (garbage-in-garbage-out) મૂલ્યાંકનને અટકાવે છે.

સ્ટેપ 5: રિપોર્ટ બનાવો

JSON સ્કોર્સ એકત્રિત કરો અને તેને મોડેલના કાચા આઉટપુટના અંશો સાથે જોડો. બધું જ એક સિંગલ ફાઇલમાં મૂકો જે તમારા રિપોઝિટરીમાં રહે. જ્યારે તમે મોડેલનું વર્ઝન અપડેટ કરો અથવા પ્રોમ્પ્ટમાં ફેરફાર કરો, ત્યારે તમારા પુલ રિક્વેસ્ટ (pull request) માં રહેલો તફાવત (diff) બરાબર બતાવશે કે વર્તણૂકમાં કેવી રીતે ફેરફાર થયો છે. સારી રીતે જાળવવામાં આવેલું બેન્ચમાર્ક જીવંત દસ્તાવેજ બની જાય છે. તે ન્યાયી ઠેરવે છે કે તમારું પ્રોડક્શન પાઇપલાઇન બીજા મોડેલને બદલે એક ચોક્કસ મોડેલનો ઉપયોગ શા માટે કરે છે, અને તે યુઝર્સ સુધી પહોંચતા પહેલા જ સાયલન્ટ રિગ્રેસન્સ (silent regressions) ને પકડી લે છે.

રિપોર્ટને એવી રીતે તૈયાર કરો કે જેથી તમારો સાથીદાર કોડ ચલાવ્યા વગર તેને વાંચી શકે. તેમાં પ્રોબ્લેમ સ્ટેટમેન્ટ, પ્રોમ્પ્ટ ટેમ્પલેટ, સ્કોર્સ અને દરેક મોડેલના રીઝનિંગ ટ્રેસમાંથી પ્રતિનિધિ અવતરણો (quotes) સામેલ કરો. પારદર્શિતા મહત્વની છે. જો DeepSeek R1 ઊંચો સ્કોર મેળવે છે પરંતુ કોઈ મર્યાદા (constraint) ને ખોટી રીતે રજૂ કરે છે (hallucinates), તો તમે ઈચ્છો છો કે તે ટેક્સ્ટ અંશમાં દેખાય, સરેરાશમાં દબાઈ ન જાય.

પાઇપલાઇનને ઓટોમેટ કરવું

એવું બેન્ચમાર્ક જે ફક્ત તમારા લેપટોપ પર જ રહે છે તે એક અઠવાડિયામાં ભૂલાઈ જાય છે. તેને નાઈટલી CI જોબમાં ખસેડો. દર રાત્રે, હાર્નેસ (harness) શરૂ થાય છે, Oxlo.ai પર વર્તમાન મોડેલ વર્ઝન માટે ક્વેરી કરે છે, bin-packing કાર્ય ચલાવે છે, આઉટપુટને ગ્રેડ કરે છે અને પરિણામો કમિટ (commit) કરે છે. જો મોડેલ અપડેટને કારણે સાચા હોવામાં (correctness) દસ પોઈન્ટનો ઘટાડો થાય છે, તો તમારા યુઝર્સ જાણતા હોય તે પહેલાં તમે જાણી શકશો.

એકવાર મુખ્ય હાર્નેસ સ્થિર થઈ જાય પછી, તેને વિસ્તૃત કરો. પ્રોમ્પ્ટમાં બિનજરૂરી દસ્તાવેજો ભરીને અને પછી bin-packing પ્રશ્ન અંતમાં મૂકીને લોંગ-કોન્ટેક્સ્ટ વેરિઅન્ટ્સનું પરીક્ષણ કરો. જો અવાજ (noise) હેઠળ તર્ક તૂટી જાય તો મોટા કોન્ટેક્સ્ટ વિન્ડોઝ નકામા છે. જુઓ કે જ્યારે સિગ્નલ દસ હજાર ટોકન્સના વિક્ષેપમાં દબાયેલું હોય ત્યારે કયા મોડેલ્સ તાર્કિક શિસ્ત જાળવી રાખે છે.

સાચો નિષ્કર્ષ

પબ્લિક લીડરબોર્ડ્સ સામાન્ય જ્ઞાન માપે છે. તમારું એપ્લિકેશન કંઈક વધુ મર્યાદિત અને અઘરું માપે છે. એક સરળ, પુનરાવર્તિત કરી શકાય તેવું હાર્નેસ જે મોડેલ્સને કન્સ્ટ્રેઇન્ડ ઓપ્ટિમાઇઝેશન (constrained optimization) દ્વારા તર્ક કરવા માટે મજબૂર કરે છે, તેમને સુસંગત માપદંડો સાથે ગ્રેડ કરે છે, અને git માં પરિણામોના વર્ઝન બનાવે છે, તે તમને કોઈપણ એગ્રીગેટ સ્કોર કરતા વધુ ઉપયોગી માહિતી આપશે. તમારા પ્રોબ્લેમ માટે યોગ્ય બેન્ચમાર્ક બનાવો, તેને તમારા માટે મહત્વપૂર્ણ આર્કિટેક્ચર્સ પર ચલાવો, અને પરિણામોને તમારા પ્રોડક્શનના નિર્ણય માટે માર્ગદર્શક બનવા દો.

Source: DeepSeek R1 Model Architecture and Benchmarks

Community: GyaanSetu AI on Telegram