Claude Opus 5-ன் “max effort” அமைப்பு, ஒரு வழக்கமான கோரிக்கையின் விலையை $0.76-லிருந்து $19.21 ஆக உயர்த்துகிறது, ஆனால் அதன் செயல்பாட்டுத் திறன் (functional output) அடிப்படையில் பெரிய மாற்றமின்றி உள்ளது. இந்த கூடுதல் செலவு ஒரு சிறந்த தீர்வைத் தருவதற்குப் பதிலாக, ஒரு உள் தணிக்கை (internal audit) முறையை மட்டுமே வழங்குகிறது; மேலும், குறைந்த சோதனைத் தாக்கம் (low test coverage) கொண்ட பணிகளில் மட்டுமே இது அளவிடக்கூடிய முன்னேற்றங்களைக் காட்டுகிறது.
சோதனை எதைக் காட்டியது
இந்தச் சோதனை, இரண்டு வகையான ப்ராம்ப்ட்களில் (prompts) Claude Opus 5-ன் இயல்புநிலை முயற்சி மட்டத்தையும் (default effort level), “max effort” அமைப்பையும் ஒப்பிட்டுப் பார்த்தது: அன்றாட கோடிங் வேலைகள் மற்றும் திட்டமிட்டு கடினமாக்கப்பட்ட சிக்கல்கள்.
- ஒரு சாதாரணப் பணிக்கு, குறைந்த முயற்சி கொண்ட இயக்கம் (low-effort run) இரண்டு நிமிடங்களில் முடிந்தது மற்றும் $0.76 செலவானது. அமைப்பை "max" நிலைக்கு உயர்த்தியபோது, கட்டணம் $19.21 ஆக உயர்ந்தது, இருப்பினும் requirement-coverage score—அதாவது மாதிரி (model) எவ்வளவு சிறப்பாகச் செயல்பட்டது என்பதைக் குறிக்கும் அளவீடு—அதே அளவில் இருந்தது.
- இந்தத் தரவுப் பதிவு, உருவாக்கம் (creation) என்பதிலிருந்து திருத்தத்திற்கு (revision) மாறியதைக் காட்டுகிறது. மாதிரி புதிய குறியீடுகளை (code) உருவாக்குவதை நிறுத்திவிட்டு, ஏற்கனவே எழுதியவற்றைச் செம்மைப்படுத்தத் தொடங்கியது. புதிய எழுத்துக்களை விட திருத்தங்கள் 2.4 மடங்கு அதிகமாக இருந்தன. “read” கருவியைப் பயன்படுத்தும் முறை 18 மடங்கு அதிகரித்தது, மேலும் “bash” கருவியைப் பயன்படுத்தும் முறை 6 மடங்கு உயர்ந்தது. நடைமுறையில், மாதிரி தொகுதிகளை (modules) மீண்டும் வாசித்தது, தனது சொந்த சோதனைகளை மீண்டும் நடத்தியது, linting மற்றும் கேட்கப்படாமலேயே mutation testing கூடச் செய்தது.
“max effort” அமைப்பு ஒரு புதிய அல்காரிதத்தை அறிமுகப்படுத்துவதில்லை; அது மாதிரி செலவிடக்கூடிய பட்ஜெட்டை மட்டுமே அதிகரிக்கிறது. பட்ஜெட் போதுமான அளவு அதிகமாக இருக்கும்போது, மாதிரி ஒரு சுய-தணிக்கை முறைக்கு (self-audit mode) மாறுகிறது, மேலும் தான் செலவிடத் தகுதியுள்ள எந்தச் சிறு மாற்றத்தையும் தேடுகிறது.
செலவு ஏன் திடீரென அதிகரிக்கிறது
மாதிரி தணிக்கை செய்யத் தீர்மானிக்கும்போது, ஒவ்வொரு கூடுதல் read அல்லது bash அழைப்பும் கட்டணத்தைச் சேர்க்கிறது, மேலும் அதன் பெருக்க விளைவுகள் (multiplier effects) மொத்தச் செலவை விரைவாக உயர்த்துகின்றன.
தணிக்கை முறை (audit mode) என்பது ஒரு தெளிவான வடிவமைப்புத் தெரிவாகும். மாதிரி பெரிய பட்ஜெட்டை, “சரிசெய்யத் தகுதியான ஒன்றைத் தேடுவதற்கு” ஒரு அனுமதியாகக் கருதுகிறது. மேம்படுத்த ஏதுமில்லை என்றால், கூடுதல் செலவு எந்தச் செயல்பாட்டுப் பயனையும் தராது.
எப்போது அதிக முயற்சி அர்த்தமுள்ளதாக இருக்கும்
ஆரம்பத் தயாரிப்பு (initial output) மேம்படுத்துவதற்கு இடமளிக்கும் போது மட்டுமே தணிக்கை முறை சிறப்பாகச் செயல்படும். 0.73 சோதனை கவரேஜ் (test coverage) கொண்ட ஒரு Go திட்டத்தில், முயற்சியை "max" நிலைக்கு உயர்த்தியபோது கவரேஜ் 0.88 ஆக உயர்ந்தது.
மாறாக, ஏற்கனவே 0.98 கவரேஜ் எட்டியிருந்த ஒரு Python பணிக்கு, பட்ஜெட்டை உயர்த்தியபோது எந்த மாற்றமும் தெரியவில்லை. மாதிரி ஏற்கனவே உள்ள உயர்தரக் குறியீட்டை மீண்டும் சரிபார்த்ததுடன் நின்றுவிட்டது, இதனால் மதிப்பு சேர்க்கப்படாமல் செலவு மட்டுமே அதிகரித்தது.
ஏற்படக்கூடிய பாதகங்கள்
- பட்ஜெட் மீறல் (Budget blowout) – குறைந்த முயற்சி விலையில் பழகிய பயனர்கள், அதே முடிவிற்காக விலையில் இருபத்தைந்து மடங்கு அதிகரிப்பைக் கண்டு அதிர்ச்சியடையலாம்.
டெவலப்பர்களுக்கான நடைமுறை வழிகாட்டுதல்கள்
- வழக்கமான ப்ராம்ப்ட்களை இயல்புநிலை முயற்சி மட்டத்திலேயே வைத்திருங்கள். மிகக் குறைந்த விலையில் அதே செயல்பாட்டு முடிவைப் பெறலாம்.
- தெளிவான தரத் தகுதியை அடையத் தவறும் குறியீடுகளுக்கு—குறைந்த சோதனை கவரேஜ், விடுபட்ட lint எச்சரிக்கைகள் அல்லது பிற அளவிடக்கூடிய இடைவெளிகள்—மட்டும் “max effort”-ஐப் பயன்படுத்துங்கள்.
- இந்த அமைப்பை ஒரு தனித் தேர்வாகக் கருதுங்கள்: சிறந்த பதில்களுக்கான வேகக் கருவியாகக் கருதாமல், ஒரு விருப்பத்தேர்வு சார்ந்த சுய-மதிப்பாய்வு (self-review) முறையாகக் கருதுங்கள்.
சுருக்கம்
Claude Opus 5-ன் max-effort சுவிட்ச் சிறந்த குறியீட்டிற்காக அல்லாமல், ஒரு உள் தரச் சரிபார்ப்பிற்காகப் பணத்தைப் பயன்படுத்துகிறது. உங்கள் அடிப்படை முடிவுகளில் நிரப்பப்பட வேண்டிய அளவிடக்கூடிய இடைவெளிகள் இருக்கும்போது மட்டுமே இதைப் பயன்படுத்துங்கள்; இல்லையெனில், குறைந்த விலையிலான இயல்புநிலை அமைப்பு தணிக்கை முறை விலையின்றி அதே முடிவைத் தரும்.
Community discussion: https://t.me/GyaanSetuAi