Claude Opus 5-ന്റെ “max effort” സെറ്റിംഗ്, ഒരു സാധാരണ റിക്വസ്റ്റിന്റെ വില $0.76-ൽ നിന്ന് $19.21 ആയി വർദ്ധിപ്പിക്കുന്നു, എന്നാൽ ഇത് നൽകുന്ന പ്രവർത്തനപരമായ ഔട്ട്പുട്ട് (functional output) ഏതാണ്ട് ഒരുപോലെ തന്നെയാണ്. ഈ അധിക ചിലവ് ഒരു മികച്ച പരിഹാരത്തിന് പകരം ഒരു ആന്തരിക ഓഡിറ്റ് പരിശോധനയ്ക്കാണ് (internal audit pass) ഉപയോഗിക്കുന്നത്. കുറഞ്ഞ ടെസ്റ്റ് കവറേജ് (test coverage) ഉള്ള ജോലികളിൽ മാത്രമേ ഇതിലൂടെ അളക്കാവുന്ന നേട്ടങ്ങൾ കാണാൻ സാധിക്കൂ.
പരിശോധന എന്ത് കാണിച്ചു
ഈ പരീക്ഷണം Claude Opus 5-ന്റെ ഡിഫോൾട്ട് എഫർട്ട് ലെവലിനെയും (default effort level) “max effort” നോബിനെയും രണ്ട് തരം പ്രോംപ്റ്റുകളിൽ പരീക്ഷിച്ചു: ദൈനംദിന കോഡിംഗ് ജോലികളും മനഃപൂർവ്വം കഠിനമാക്കിയ പ്രശ്നങ്ങളും.
- ഒരു സാധാരണ ടാസ്കിനായി, കുറഞ്ഞ എഫർട്ട് ഉപയോഗിച്ചുള്ള റൺ രണ്ട് മിനിറ്റിനുള്ളിൽ പൂർത്തിയായി കൂടാതെ $0.76 ചിലവായി. എന്നാൽ സെറ്റിംഗ് 'max' ലേക്ക് മാറ്റിയപ്പോൾ ബില്ല് $19.21 ആയി ഉയർന്നു, എന്നിരുന്നാലും റിക്വയർമെന്റ് കവറേജ് സ്കോർ (requirement-coverage score)—അതായത് മോഡൽ നൽകിയ ഔട്ട്പുട്ട് നിർദ്ദേശങ്ങൾ എത്രത്തോളം പാലിക്കുന്നു എന്ന അളവ്—മാറ്റമില്ലാതെ തുടർന്നു.
- നിർമ്മാണത്തിൽ (creation) നിന്ന് തിരുത്തലിലേക്കുള്ള (revision) ഒരു മാറ്റം ട്രാൻസ്ക്രിപ്റ്റ് കാണിക്കുന്നു. മോഡൽ പുതിയ കോഡ് നിർമ്മിക്കുന്നത് നിർത്തി, നേരത്തെ എഴുതിയത് മിനുക്കിയെടുക്കാൻ തുടങ്ങി. പുതിയ എഴുത്തുകളേക്കാൾ 2.4 മടങ്ങ് കൂടുതൽ തിരുത്തലുകൾ (edits) ഉണ്ടായിരുന്നു. “read” ടൂളിനായുള്ള കോളുകൾ പതിനെട്ട് മടങ്ങ് വർദ്ധിച്ചു, “bash” ടൂളിനായുള്ള ഉപയോഗം ആറ് മടങ്ങ് കൂടി. പ്രായോഗികമായി പറഞ്ഞാൽ, ആവശ്യപ്പെടാതെ തന്നെ മോഡൽ മൊഡ്യൂളുകൾ വീണ്ടും വായിക്കുകയും, സ്വന്തം ടെസ്റ്റുകൾ വീണ്ടും റൺ ചെയ്യുകയും, ലിന്റിംഗ് (linting), മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ് (mutation testing) എന്നിവ പോലും നിർവ്വഹിക്കുകയും ചെയ്തു.
“max effort” നോബ് ഒരു പുതിയ അൽഗോരിതം കൊണ്ടുവരുന്നില്ല; അത് മോഡലിന് ചിലവഴിക്കാൻ കഴിയുന്ന ബജറ്റ് വർദ്ധിപ്പിക്കുക മാത്രമാണ് ചെയ്യുന്നത്. ബജറ്റ് ആവശ്യത്തിന് വലുതാകുമ്പോൾ, മോഡൽ ഒരു സെൽഫ്-ഓഡിറ്റ് മോഡിലേക്ക് (self-audit mode) മാറുകയും, കൂടുതൽ ചിലവാക്കാൻ ന്യായീകരിക്കാൻ കഴിയുന്ന ചെറിയ മാറ്റങ്ങൾക്കായി തിരയുകയും ചെയ്യുന്നു.
എന്തുകൊണ്ടാണ് ചിലവ് വർദ്ധിക്കുന്നത്
മോഡൽ ഓഡിറ്റ് ചെയ്യാൻ തീരുമാനിക്കുമ്പോൾ, ഓരോ അധിക റീഡ് (read) അല്ലെങ്കിൽ ബാഷ് (bash) കോളും ബില്ലിൽ കൂട്ടിച്ചേർക്കപ്പെടുന്നു, ഇത് മൾട്ടിപ്ലയർ ഇഫക്റ്റുകളിലൂടെ ആകെ ചിലവിനെ പെട്ടെന്ന് കുതിച്ചുയർത്തുന്നു.
ഓഡിറ്റ് മോഡ് എന്നത് ഒരു വ്യക്തമായ ഡിസൈൻ ചോയിസാണ്. വലിയ ബജറ്റിനെ "തിരുത്താൻ യോഗ്യമായ എന്തെങ്കിലും കണ്ടെത്താനുള്ള" അനുമതിയായി മോഡൽ കണക്കാക്കുന്നു. മെച്ചപ്പെടുത്താൻ ഒന്നുമില്ലെന്ന് കണ്ടാൽ, അധിക ചിലവ് യാതൊരു പ്രവർത്തനപരമായ നേട്ടവും നൽകുന്നില്ല.
എപ്പോഴാണ് ഉയർന്ന എഫർട്ട് പ്രയോജനപ്പെടുന്നത്
ആദ്യത്തെ ഔട്ട്പുട്ടിൽ മെച്ചപ്പെടുത്തലുകൾക്ക് ഇടമുണ്ടെങ്കിൽ മാത്രമേ ഓഡിറ്റ് മോഡ് ഫലപ്രദമാകൂ. 0.73 ടെസ്റ്റ് കവറേജ് ഉള്ള ഒരു Go പ്രോജക്റ്റിൽ, എഫർട്ട് 'max' ലേക്ക് മാറ്റിയപ്പോൾ കവറേജ് 0.88 ആയി ഉയർന്നു.
നേരെമറിച്ച്, 0.98 കവറേജ് നേരത്തെ തന്നെ കൈവരിച്ചിരുന്ന ഒരു Python ടാസ്കിൽ ബജറ്റ് വർദ്ധിപ്പിച്ചപ്പോൾ മാറ്റമൊന്നും കണ്ടില്ല. മോഡൽ ഉയർന്ന നിലവാരമുള്ള അതേ കോഡ് വീണ്ടും പരിശോധിക്കുക മാത്രമാണ് ചെയ്തത്, ഇത് മൂല്യം വർദ്ധിപ്പിക്കാതെ തന്നെ ചിലവ് കൂട്ടുന്നു.
ഉണ്ടായേക്കാവുന്ന ദോഷങ്ങൾ
- ബജറ്റ് കുതിച്ചുയരുന്നത് – കുറഞ്ഞ എഫർട്ട് വിലയിൽ ശീലിച്ച ഉപയോക്താക്കൾക്ക്, ഒരേ ഫലത്തിനായി ഇരുപത്തിയഞ്ച് മടങ്ങ് വർദ്ധനവ് കാണുന്നത് അത്ഭുതകരമായി തോന്നാം.
ഡെവലപ്പർമാർക്കുള്ള പ്രായോഗിക നിർദ്ദേശങ്ങൾ
- സാധാരണ പ്രോംപ്റ്റുകൾ ഡിഫോൾട്ട് എഫർട്ട് ലെവലിൽ തന്നെ വെക്കുക. വളരെ കുറഞ്ഞ ചിലവിൽ നിങ്ങൾക്ക് ഒരേ ഫലപ്രാപ്തി ലഭിക്കും.
- വ്യക്തമായ ഗുണനിലവാര പരിധിയിൽ (quality threshold) എത്താൻ കഴിയാത്ത കോഡുകൾക്കായി മാത്രം “max effort” ഉപയോഗിക്കുക—ഉദാഹരണത്തിന് കുറഞ്ഞ ടെസ്റ്റ് കവറേജ്, ലിന്റിംഗ് മുന്നറിയിപ്പുകൾ (lint warnings) എന്നിവ.
- ഈ സെറ്റിംഗിനെ ഒരു പ്രത്യേക മോഡായി കാണുക: മികച്ച ഉത്തരങ്ങൾക്കായി വേഗത കൂട്ടുന്നതിന് പകരം, ഇതൊരു ഓപ്ഷണൽ സെൽഫ്-റിവ്യൂ പാസ് ആയി പരിഗണിക്കുക.
ചുരുക്കത്തിൽ
Claude Opus 5-ന്റെ max-effort സ്വിച്ച് പണം നൽകുന്നത് മികച്ച കോഡിന് വേണ്ടിയല്ല, മറിച്ച് ഒരു ആന്തരിക ഗുണനിലവാര പരിശോധനയ്ക്കാണ്. നിങ്ങളുടെ അടിസ്ഥാന ഫലങ്ങളിൽ നികത്താൻ കഴിയുന്ന അളക്കാവുന്ന കുറവുകൾ ഉണ്ടെങ്കിൽ മാത്രം ഇത് മിതമായി ഉപയോഗിക്കുക; അല്ലാത്തപക്ഷം, ഓഡിറ്റ് മോഡിന്റെ ഉയർന്ന വിലയില്ലാതെ തന്നെ ഡിഫോൾട്ട് സെറ്റിംഗ് ഒരേ ഫലം നൽകുന്നു.
Community discussion: https://t.me/GyaanSetuAi
