பரந்த அளவிலான லீடர்போர்டுகளில் (leaderboards) ஒரு மாடலை பெஞ்ச்மார்க்கிங் செய்வது, அது பொது அறிவுத் தகவல்கள் (trivia) மற்றும் தரப்படுத்தப்பட்ட தேர்வுகளை எவ்வளவு சிறப்பாகக் கையாள்கிறது என்பதைக் கூறுகிறது. உங்கள் உற்பத்தி அமைப்புகள் (production systems) உண்மையில் எதிர்கொள்ளும் சிக்கலான, கட்டுப்பாடுகள் நிறைந்த பிரச்சனைகளை அது எவ்வாறு தர்க்கரீதியாக அணுகும் (reason) என்பது பற்றி இது கிட்டத்தட்ட எதுவும் சொல்லாது. எந்தவொரு பெரிய மொழி மாதிரியையும் (large language model) பயனர்களுக்கு வழங்குவதற்கு முன், உங்கள் பயன்பாட்டிற்குத் தேவையான குறிப்பிட்ட அறிவாற்றல் முறைகளை (cognitive patterns) சோதிக்கும் ஒரு கட்டமைப்பிற்கு (harness) உங்களுக்குத் தேவை. தர்க்கரீதியான பெஞ்ச்மார்க்குகள் (Reasoning benchmarks) தான் மாடல்களை சாதாரண சாட்பாட்களிலிருந்து (chatbots) வேறுபடுத்திக் காட்டுகின்றன.

இந்த வழிகாட்டி, ஒரு குறிப்பிட்ட தர்க்கரீதியான பெஞ்ச்மார்க்கை ஆரம்பத்திலிருந்து உருவாக்குவது எப்படி என்பதை விளக்குகிறது. நீங்கள் மூன்று வெவ்வேறு கட்டமைப்புகளை ஒப்பிடுவீர்கள்: DeepSeek R1 671B MoE, Llama 3.3 70B, மற்றும் Qwen 3 32B. GPU கிளஸ்டர்களைத் தயார் செய்வதற்குப் பதிலாக, நீங்கள் மூன்றையும் Oxlo.ai மூலம் இயக்குவீர்கள். மதிப்பீட்டிற்காக, தர்க்கத் தெளிவு (reasoning clarity), துல்லியம் (correctness) மற்றும் குறியீட்டுத் தரம் (code quality) ஆகியவற்றின் அடிப்படையில் வெளியீடுகளுக்கு மதிப்பெண் வழங்க Kimi K2.6-ஐ ஒரு நடுவராகப் பயன்படுத்துவீர்கள்.

ஏன் தர்க்கரீதியான திறன் முதலில் முறியடிக்கிறது

உற்பத்தித் தோல்விகள் (Production failures) அரிதாகவே இலக்கணப் பிழைகளாகவோ அல்லது மறுப்புகளாகவோ இருக்கும். அவை நுணுக்கமான தர்க்கப் பிழைகளாகத் தோன்றும். ஒரு மாடல் ஒரு கட்டுப்பாட்டைத் தவறாகப் புரிந்துகொண்டாலோ, ஒரு படிநிலையைத் தவிர்த்தாலோ அல்லது இடையில் ஒரு மாறியை (variable) அமைதியாக மாற்றினாலோ, அது மிகவும் நம்பிக்கையான உரையையே உருவாக்கலாம். பொதுவான பெஞ்ச்மார்க்குகள் பெரும்பாலும் ஆழத்தை விட பரப்பிற்கு முக்கியத்துவம் அளிக்கின்றன, எனவே ஒரு மாடல் கடினமான ஒரு சேர்க்கை சிக்கலைத் (combinatorial problem) தீர்க்காமலேயே அதிக மதிப்பெண்களைப் பெற முடியும்.

ஒரு இலக்கு வைக்கப்பட்ட பெஞ்ச்மார்க் இந்தப் பிரச்சனையைத் தீர்க்கத் தூண்டுகிறது. இது ஒவ்வொரு மாடலுக்கும் ஒரே மாதிரியான கட்டுப்பாடுகள் கொண்ட உகப்பாக்கப் பணியை (constrained optimization task) வழங்குகிறது, ஒரு தொடர்ச்சியான சிந்தனைச் சங்கிலியை (traceable chain of thought) கோருகிறது, மேலும் உருவாக்கப்பட்ட தீர்வு உண்மையில் விதிகளைப் பூர்த்தி செய்கிறதா என்பதை அளவிடுகிறது. ஒரு மாடலால் டிஸ்க்ரீட் கணிதத்தில் (discrete math) சீராகத் தர்க்கரீதியாகச் செயல்பட முடியாவிட்டால், அது உங்கள் சரக்கு ஒதுக்கீடு (inventory allocation), திட்டமிடல் இயந்திரம் (scheduling engine) அல்லது வள வழிகாட்டி (resource router) ஆகியவற்றையும் நம்பகமான முறையில் கையாளாது.

மாடல்களும் தளமும்

DeepSeek R1 671B MoE என்பது mixture-of-experts வடிவமைப்பைப் பயன்படுத்துகிறது. அதன் 671 பில்லியன் அளவுருக்களில் (parameters) ஒரு சிறு பகுதி மட்டுமே ஒவ்வொரு டோக்கனுக்கும் (token) செயல்படுகிறது, இது செலவு-செயல்திறன் விகிதத்தையும் (cost-to-performance curve) சில நேரங்களில் அதன் தர்க்கத்தின் தன்மையையும் மாற்றுகிறது. Llama 3.3 70B ஒரு டென்ஸ் (dense) மாடல், மேலும் Qwen 3 32B சிறிய அளவில் வலுவான பன்மொழி மற்றும் குறியீட்டுத் திறன்களைக் கொண்டுள்ளது. இந்த மூன்றையும் ஒப்பிடுவது, தர்க்கத் தரம் என்பது மொத்த அளவுருக்களின் எண்ணிக்கையைச் சார்ந்ததா, செயல்படும் அளவுருக்களின் எண்ணிக்கையைச் சார்ந்ததா அல்லது பயிற்சி முறையைச் சார்ந்ததா என்பதைக் கூறும்.

Oxlo.ai இந்த மாடல்களை ஒரு ஒருங்கிணைந்த API மூலம் வழங்குகிறது. நீங்கள் இன்ஃபரன்ஸ் உள்கட்டமைப்பை (inference infrastructure) நிர்வகிக்க வேண்டியதில்லை அல்லது தனித்தனி சேவை வழங்குநர் ஒப்பந்தங்களுடன் போராட வேண்டியதில்லை. இந்தத் தளம் டோக்கன் அடிப்படையிலான விலைக்குப் பதிலாக, கோரிக்கை (per-request) அடிப்படையிலான விலையைப் பயன்படுத்துகிறது. இரண்டாயிரம் வார்த்தைகள் கொண்ட சிஸ்டம் பிராம்ப்ட் (system prompt), ஒரு வரியில் உள்ள பிராம்ப்ட்டிற்குச் சமமான விலையையே கொண்டது. அந்த விவரம் நீங்கள் நினைப்பதை விட முக்கியமானது. இதன் பொருள், உள்ளீட்டு டோக்கன் செலவுகள் அதிகரிப்பதைப் பற்றி கவலைப்படாமல், நீங்கள் விரிவான அறிவுறுத்தல்களை எழுதலாம், விரிவான வடிவமைப்புக் தேவைகளைச் சேர்க்கலாம் மற்றும் few-shot உதாரணங்களை இணைக்கலாம். நீங்கள் அழைப்பிற்கு (call) மட்டுமே பணம் செலுத்துகிறீர்கள், வார்த்தை வளத்திற்கு அல்ல.

உங்களுக்கு Python 3.10 அல்லது அதற்குப் பிந்தைய பதிப்பு, OpenAI Python லைப்ரரி மற்றும் ஒரு Oxlo.ai API கீ தேவைப்படும்.

படி 1: எண்ட்ஸ்பாயிண்ட்டுடன் (Endpoint) இணைக்கவும்

Oxlo.ai ஒரு OpenAI-இணக்கமான API-ஐ வழங்குவதால், ஒருங்கிணைப்பு மிகவும் எளிதானது. OpenAI SDK-ஐ Oxlo அடிப்படை URL-க்குத் திருப்புங்கள், உங்கள் API கீயைப் பயன்படுத்துங்கள், மேலும் DeepSeek R1-க்கு ஒரு சிறிய கோரிக்கையை அனுப்பி இணைப்பைச் சரிபார்க்கவும். இந்தச் சரிபார்ப்பைத் (sanity check) தவிர்க்க வேண்டாம். லேட்டன்சியை (latency) உறுதிப்படுத்தவும், மாடல் ஐடென்டிஃபையர் (model identifier) அங்கீகரிக்கப்படுவதை உறுதிப்படுத்தவும், மேலும் நீங்கள் சேமிக்க விரும்பும் பதில் வடிவத்தை (response format) உங்கள் சூழல் ஸ்ட்ரீம் (stream) அல்லது பஃபர் (buffer) செய்ய முடியுமா என்பதை உறுதிப்படுத்தவும். ஒருமுறை இணைப்பு (handshake) வெற்றிகரமாகிவிட்டால், ஒரே ஒரு சரத்தை (string) மாற்றுவதன் மூலம் மூன்று மாடல்களையும் அணுகக்கூடிய ஒரு கிளையன்ட் உங்களிடம் இருக்கும்.

படி 2: பணியைத் திட்டமிடுங்கள்

படி-படியாகத் தர்க்கம் தேவைப்படும் மற்றும் புறநிலையாக அளவிடக்கூடிய (objectively measurable) விடையைக் கொண்ட ஒரு சிக்கலைத் தேர்ந்தெடுக்கவும். பின்-பேக்கிங் (Bin-packing) இதற்கு மிகச் சிறப்பாகச் செயல்படும். இது NP-hard வகையைச் சார்ந்தது, அதாவது க்ரீடி ஹியூரிஸ்டிக்ஸ் (greedy heuristics) கணிக்கக்கூடிய வழிகளில் தோல்வியடையும், மேலும் இது மாடல் பல கட்டுப்பாடுகளை ஒரே நேரத்தில் கண்காணிக்கத் தூண்டுகிறது. வெவ்வேறு அளவிலான பொருட்கள், குறிப்பிட்ட கொள்ளளவு கொண்ட பெட்டிகளுக்குள் (bins) வரம்புகளைத் தாண்டாமல் பொருந்த வேண்டும்.

மாடல் இரண்டு விஷயங்களைச் செய்யுமாறு பிராம்ப்ட்டை வடிவமைக்கவும்: அதன் தர்க்கச் செயல்முறையை விவரிக்க வேண்டும், பின்னர் அந்தச் சிக்கலைத் தீர்க்கும் இயங்கக்கூடிய Python குறியீட்டை வழங்க வேண்டும். எந்தவொரு குறியீட்டை எழுதுவதற்கு முன்பும் மாடல் தனது சிந்தனைச் சங்கிலியை (chain-of-thought) காண்பிக்க வேண்டும் என்று வெளிப்படையாகக் கோரும் ஒரு சிஸ்டம் பிராம்ப்ட்டைப் பயன்படுத்தவும். இது குறிப்பாக DeepSeek R1-க்கு முக்கியமானது, ஏனெனில் இது விரிவான தர்க்கத் தடயங்களுக்காக (reasoning traces) மேம்படுத்தப்பட்டுள்ளது. மாடல் கொள்ளளவு சோதனைகளைத் தர்க்கரீதியாகச் சிந்திக்கிறதா அல்லது பயிற்சித் தரவுகளுடன் வெறும் பேட்டர்ன்-மேட்சிங் (pattern-matching) செய்கிறதா என்பதை நீங்கள் பார்க்க விரும்புகிறீர்கள். ஒரு நல்ல பணி என்பது டெம்ப்ளேட் பதில்கள் தோல்வியடையும் அளவுக்கு சவாலானதாக இருக்க வேண்டும்.

படி 3: பெஞ்ச்மார்க்கை இயக்கவும்

DeepSeek R1, Llama 3.3 70B, மற்றும் Qwen 3 32B ஆகியவற்றுக்கு ஒரே மாதிரியான prompt-ஐ வழங்கவும். இறுதி code block-களை மட்டும் எடுக்காமல், முழுமையான உரை பதில்களையும் (text responses) சேகரிக்கவும். அவற்றை நேர முத்திரைகள் (timestamps) மற்றும் மாடல் அடையாளங்களுடன் (model identifiers) சேமிக்கவும். Oxlo.ai ஒவ்வொரு கோரிக்கைக்கும் (request) கட்டணம் வசூலிப்பதால், பணத்தைச் சேமிக்க உங்கள் prompt-ஐக் குறைக்கவோ அல்லது தெளிவுபடுத்தும் வழிமுறைகளை நீக்கவோ தேவையில்லை. நீங்கள் துல்லியமாக இருக்க முடியும். அந்த நிலைத்தன்மை, செலவு குறித்த கவலை இன்றி prompt வடிவமைப்பைத் திரும்பத் திரும்பச் செய்ய அனுமதிக்கிறது, இது தூய்மையான சோதனைகளுக்கும் மற்றும் மீண்டும் பெறக்கூடிய முடிவுகளுக்கும் வழிவகுக்கிறது.

உங்கள் பட்ஜெட் அனுமதித்தால் ஒவ்வொரு மாடலையும் பலமுறை இயக்கவும். Reasoning மாடல்கள் தற்செயலான உருவாக்கங்களின் (stochastic generations) போது மாறுபடலாம், எனவே ஒரு அதிக மதிப்பெண் நிலையான திறனைக் குறிக்கிறதா அல்லது ஒரு அதிர்ஷ்டமான மாதிரியா என்பதை நீங்கள் அறிய விரும்புகிறீர்கள்.

படி 4: LLM Judge மூலம் மதிப்பிடுதல்

கைமுறை மதிப்பெண் முறை (Manual scoring) பெரிய அளவில் செயல்படாது, ஆனால் எண்கள் சார்ந்த அளவுகோல்கள் (numeric rubrics) நுணுக்கங்களை 놓விடும். இதற்கான இடைக்காலத் தீர்வு ஒரு LLM judge ஆகும். இங்கே, நீங்கள் Kimi K2.6-ஐப் பயன்படுத்துவீர்கள். அசல் சிக்கல் (original problem), அளவுகோல் (rubric) மற்றும் ஒவ்வொரு வேட்பாளர் பதிலையும் அதற்கு வழங்கவும். பின்வரும் மூன்று குறிப்பிட்ட பரிமாணங்களை மதிப்பிடச் சொல்லுங்கள்:

  • Reasoning clarity: விளக்கம் உண்மையில் தர்க்கத்தைப் பின்பற்றுகிறதா அல்லது மேலோட்டமாக மட்டும் இருக்கிறதா?
  • Correctness: முன்மொழியப்பட்ட தீர்வு கூறப்பட்ட அனைத்து கட்டுப்பாடுகளையும் (constraints) பூர்த்தி செய்கிறதா?
  • Code quality: Python குறியீடு சுத்தமாகவும், இயங்கக்கூடியதாகவும் மற்றும் தெளிவான பிழைகள் இல்லாமலும் உள்ளதா?

மதிப்பெண்களை JSON வடிவில் வழங்க judge-க்கு அறிவுறுத்துங்கள். கட்டமைக்கப்பட்ட வெளியீடு (Structured output), முடிவுகளை ஒப்பிடவும் (diff), போக்குகளை வரைபடமாக்கவும் (plot trends) மற்றும் அடுத்தகட்ட தானியங்கி செயல்பாடுகளுக்கு (downstream automation) வழங்கவும் எளிதாக்குகிறது. Judge prompt-ஐத் தீவிரமாக வைத்திருங்கள். "பதிலுக்கு மதிப்பெண் கொடு" என்பது போன்ற தெளிவற்ற அறிவுறுத்தல்களை வழங்கினால், உங்களுக்குத் தெளிவற்ற முடிவுகளே கிடைக்கும். அதற்குப் பதிலாக, ஒரு சரியான bin-packing தீர்வாக எதைக் கருத வேண்டும் என்பதை வரையறுக்கவும். கொள்ளளவைத் (Capacities) தாண்டக்கூடாது. ஒவ்வொரு பொருளும் ஒதுக்கப்பட வேண்டும். குறியீடு syntactically செல்லுபடியாகும் வகையில் இருக்க வேண்டும். உங்கள் அளவுகோல்கள் எவ்வளவு உறுதியாக இருக்கிறதோ, அவ்வளவு நம்பகமான மதிப்பெண்கள் கிடைக்கும்.

எப்போதும் judge-ஐ அவ்வப்போது சரிபார்க்கவும் (spot-check). Kimi K2.6 மேலோட்டமான சிறப்பம்சங்களுக்காக (surface-level polish) ஒரு மாடலுக்குத் தொடர்ந்து அதிக மதிப்பெண் வழங்கினால், உங்கள் benchmark தவறானது என்று அர்த்தம். ஒரு சிறிய மனிதத் தணிக்கை அடுக்கு (human audit layer), தவறான தரவுகள் உள்ளே சென்று தவறான முடிவுகள் வெளியே வருவதைத் (garbage-in-garbage-out) தடுக்கும்.

படி 5: அறிக்கையை உருவாக்குதல்

JSON மதிப்பெண்களைத் தொகுத்து, அவற்றை மாடல் வெளியீடுகளின் (raw model outputs) பகுதிகளுடன் இணைக்கவும். அனைத்தையும் உங்கள் repository-யில் உள்ள ஒரு தனி கோப்பில் சேமிக்கவும். நீங்கள் ஒரு மாடல் பதிப்பைப் புதுப்பிக்கும்போதோ அல்லது prompt-ஐ மாற்றியமைக்கும்போதோ, உங்கள் pull request-ல் உள்ள வேறுபாடு (diff) நடத்தை எவ்வாறு மாறியது என்பதைத் துல்லியமாகக் காட்டும். நன்கு பராமரிக்கப்படும் benchmark ஒரு நேரடி ஆவணமாக (living documentation) மாறும். உங்கள் production pipeline ஏன் ஒரு மாடலை மற்றொன்றை விடப் பயன்படுத்துகிறது என்பதை இது நியாயப்படுத்துகிறது, மேலும் பயனர்களைச் சென்றடைவதற்கு முன்பே அமைதியான பின்னடைவுகளை (silent regressions) இது கண்டறிகிறது.

உங்கள் குழு உறுப்பினர் குறியீட்டை இயக்காமலேயே படிக்கும் வகையில் அறிக்கையை வடிவமைக்கவும். சிக்கல் அறிக்கை (problem statement), prompt template, மதிப்பெண்கள் மற்றும் ஒவ்வொரு மாடலின் reasoning trace-லிருந்து முக்கியமான மேற்கோள்களைச் சேர்க்கவும். வெளிப்படைத்தன்மை முக்கியமானது. DeepSeek R1 அதிக மதிப்பெண் பெற்றாலும், ஒரு கட்டுப்பாட்டைத் தவறாகக் கற்பனை செய்தால் (hallucinates a constraint), அது சராசரியில் மறைந்துவிடாமல் உரைப் பகுதியில் தெளிவாகத் தெரிய வேண்டும்.

பைப்லைனைத் தானியக்கமாக்குதல் (Automating the Pipeline)

உங்கள் லேப்டாப்பில் மட்டும் இருக்கும் ஒரு benchmark ஒரு வாரத்திற்குள் மறக்கப்பட்டுவிடும். அதை ஒரு nightly CI job-க்கு மாற்றவும். ஒவ்வொரு இரவும், harness இயங்கும், Oxlo.ai-ல் உள்ள தற்போதைய மாடல் பதிவgetகளைக் கேட்கும், bin-packing பணியைச் செய்யும், வெளியீடுகளை மதிப்பிடும் மற்றும் முடிவுகளை commit செய்யும். ஒரு மாடல் புதுப்பிப்பு காரணமாகத் துல்லியத்தன்மை பத்து புள்ளிகள் குறைந்தால், பயனர்களை விட நீங்கள் அதை முன்கூட்டியே அறிந்து கொள்வீர்கள்.

முக்கிய harness நிலையானதும், அதை விரிவுபடுத்தவும். prompt-ல் தேவையற்ற ஆவணங்களைச் சேர்த்து, இறுதியில் bin-packing கேள்வியைக் கொடுத்து long-context வகைகளைச் சோதிக்கவும். இரைச்சலுக்கு (noise) மத்தியில் reasoning செயலிழந்தால், பெரிய context windows பயனற்றவை. பல்லாயிரக்கணக்கான tokens இடையூறுகளுக்குள் சிக்னல் மறைந்து இருக்கும்போது, எந்த மாடல்கள் தர்க்கரீதியான ஒழுக்கத்தைப் (logical discipline) பராமரிக்கின்றன என்பதைக் காணவும்.

உண்மையான முடிவு (The Real Takeaway)

பொதுவான லீடர்போர்டுகள் (Public leaderboards) பொது அறிவை அளவிடுகின்றன. உங்கள் பயன்பாடு மிகவும் குறுகிய மற்றும் கடினமான ஒன்றைக் அளவிடுகிறது. மாடல்களைக் கட்டுப்படுத்தப்பட்ட உகப்பாக்கம் (constrained optimization) மூலம் சிந்திக்கத் தூண்டும், நிலையான அளவுகோல்களுடன் மதிப்பிடும் மற்றும் git-ல் முடிவுகளைப் பதிவேற்றும் ஒரு எளிய, மீண்டும் செய்யக்கூடிய harness, எந்தவொரு மொத்த மதிப்பெண்ணையும் விட உங்களுக்குச் சிறந்த நுண்ணறிவைத் தரும். உங்கள் சிக்கலுக்குப் பொருந்தும் benchmark-ஐ உருவாக்குங்கள், உங்களுக்குத் தேவையான கட்டமைப்புகளில் (architectures) அதை இயக்கவும், முடிவுகள் உங்கள் production தேர்வைத் தீர்மானிக்கட்டும்.

Source: DeepSeek R1 Model Architecture and Benchmarks

Community: GyaanSetu AI on Telegram