മൂന്ന് Claude മോഡലുകൾ ഉപയോഗിച്ചുകൊണ്ടുള്ള ഒരു ഡെവലപ്പറുടെ പരീക്ഷണം പ്രതിമാസ API ചിലവ് 35% കുറയ്ക്കുകയും ശരാശരി ടാസ്ക് സമയവ്യയം (latency) 42 സെക്കൻഡിൽ നിന്ന് 27 സെക്കൻഡിലേക്ക് കുറയ്ക്കുകയും ചെയ്തു. ലളിതവും അവ്യക്തത കുറഞ്ഞതുമായ ജോലികൾ വില കുറഞ്ഞ Haiku മോഡലിലേക്കും, പതിവ് ജോലികൾ Sonnet-ലേക്കും, സങ്കീർണ്ണമായ പ്രശ്നങ്ങൾക്ക് ഏറ്റവും കരുത്തുറ്റ Opus-ലേക്കും റൂട്ട് ചെയ്യുന്നതിലൂടെ, "എല്ലാത്തിനും മികച്ച മോഡൽ" എന്ന ശീലം വലിയ ചിലവുകൾ ഉണ്ടാക്കുമെന്ന് ലേഖകൻ തെളിയിച്ചു.
എന്തുകൊണ്ടാണ് റൂട്ടിംഗ് പ്രധാനപ്പെട്ടത്
ഡെവലപ്മെന്റ് ടാസ്ക്കുകൾ—ലിന്റ് ഫിക്സുകൾ (lint fixes), ഫീച്ചർ കൂട്ടിച്ചേർക്കലുകൾ, സെക്യൂരിറ്റി റിവ്യൂകൾ, ഡീപ്പ് ഡിബഗ്ഗിംഗ് സെഷനുകൾ എന്നിവ—തുടർച്ചയായി ലഭിക്കുന്ന ഒരു ഓട്ടോണമസ് കോഡിംഗ് ഏജന്റ് ലേഖകൻ പ്രവർത്തിപ്പിക്കുന്നുണ്ട്. ഉയർന്ന ഗുണനിലവാരം എപ്പോഴും വിലയേക്കാൾ പ്രധാനമാണെന്ന് കരുതി, മാസങ്ങളോളം ഏജന്റ് എല്ലാ റിക്വസ്റ്റുകളും ഏറ്റവും മികച്ച Claude മോഡലായ Opus-ലേക്ക് അയച്ചു. Opus-ന് ടോക്കണുകൾക്ക് ഉയർന്ന വിലയുള്ളതിനാൽ ബില്ല് നിയന്ത്രണമില്ലാതെ വർദ്ധിച്ചു.
ലേഖകൻ ഒരു ടയേർഡ് റൂട്ടിംഗ് സ്കീം (tiered routing scheme) അവതരിപ്പിച്ചപ്പോൾ, ചിലവ് പഴയതിന്റെ 65% ആയി കുറയുകയും ആകെ ടാസ്ക്കുകളിൽ Opus-ന്റെ ഉപയോഗം 11% ആയി താഴുകയും ചെയ്തു.
മൂന്ന് തട്ടുകളുള്ള ഈ സംവിധാനം എങ്ങനെ പ്രവർത്തിക്കുന്നു
റൂട്ടിംഗ് ലോജിക് അധിഷ്ഠിതമായിരിക്കുന്നത് ഒരു ടാസ്ക് എത്ര വരി കോഡ് ബാധിക്കുന്നു എന്നതിലല്ല, മറിച്ച് അതിന്റെ അവ്യക്തതയിൽ (ambiguity) ആണ്. ലേഖകൻ മൂന്ന് വിഭാഗങ്ങൾ നിശ്ചയിച്ചു:
- Haiku – കുറഞ്ഞ അവ്യക്തതയുള്ള, നിശ്ചിത രീതിയിലുള്ള ജോലികൾ. ഉദാഹരണങ്ങൾ: ലിന്റ് വാർണിംഗുകൾ പരിഹരിക്കുക, വേരിയബിളുകൾ മാറ്റം വരുത്തുക, ലോഗ് ഫയലുകൾ സംഗ്രഹിക്കുക. ശരിയായ ഉത്തരം സാധാരണയായി ഒരു വരി കോഡോ ടെക്സ്റ്റോ ആയിരിക്കും.
- Sonnet – ഡിഫോൾട്ട് വർക്ക്ഹോഴ്സ്. ഫീച്ചർ ഇംപ്ലിമെന്റേഷൻ, പതിവ് ബഗ് ഫിക്സുകൾ, സ്റ്റാൻഡേർഡ് റീഫാക്ടറുകൾ എന്നിവ കൈകാര്യം ചെയ്യുന്നു. ഇവിടെ പ്രശ്നം വ്യക്തമാണെങ്കിലും പരിഹാരത്തിന് പല ഘട്ടങ്ങൾ ആവശ്യമായി വന്നേക്കാം.
- Opus – ഉയർന്ന ഉത്തരവാദിത്തമുള്ള, ഉയർന്ന അവ്യക്തതയുള്ള ജോലികൾ. ആർക്കിടെക്ചർ തീരുമാനങ്ങൾ, സെക്യൂരിറ്റി ഓഡിറ്റുകൾ, സങ്കീർണ്ണമായ ഡിബഗ്ഗിംഗ് സെഷനുകൾ, അല്ലെങ്കിൽ ശരിയായ വഴി വ്യക്തമല്ലാത്തതും ഒരു തെറ്റ് പോലും വലിയ പ്രശ്നങ്ങൾക്ക് കാരണമാകുന്നതുമായ ജോലികൾ.
ഈ നിയമങ്ങൾ അടിസ്ഥാനമാക്കി ഓരോ റിക്വസ്റ്റിനെയും അനുയോജ്യമായ മോഡലിലേക്ക് ഒരു സ്റ്റാറ്റിക് ലുക്കപ്പ് ടേബിൾ (static lookup table) മാപ്പ് ചെയ്യുന്നു. ഓരോ ഘട്ടത്തിലും തനിയെ തീരുമാനമെടുക്കുന്ന ഒരു "സ്മാർട്ട്" മോഡൽ ലേഖകൻ പരീക്ഷിച്ചു നോക്കിയെങ്കിലും, അധികമായി ഉപയോഗിച്ച ടോക്കണുകൾ ലാഭത്തെ ഇല്ലാതാക്കി. ലളിതമായ സ്റ്റാറ്റിക് നിയമങ്ങൾ ഏകദേശം 80% ജോലിഭാരം കൈകാര്യം ചെയ്യുകയും സിസ്റ്റത്തെ ചിലവ് കുറഞ്ഞതും പ്രവചിക്കാവുന്നതുമാക്കുകയും ചെയ്തു.
എസ്കലേഷൻ സേഫ്റ്റി നെറ്റ്
വില കുറഞ്ഞ മോഡലുകൾ തെറ്റുകൾ വരുത്തിയേക്കാം. ഒരു തെറ്റായ Haiku അല്ലെങ്കിൽ Sonnet മറുപടി പ്രോജക്റ്റിനെ തടസ്സപ്പെടുത്താതിരിക്കാൻ, രണ്ട് തവണ പരാജയപ്പെട്ടാൽ സിസ്റ്റം ആ റിക്വസ്റ്റിനെ അടുത്ത ടയറിലേക്ക് മാറ്റുന്നു (escalates). ഈ സേഫ്റ്റി നെറ്റ് പിശകുകൾ നേരത്തെ കണ്ടെത്തുകയും മാനുവൽ ഇടപെടലുകൾ ഇല്ലാതെ തന്നെ പ്രക്രിയ സുഗമമായി മുന്നോട്ട് കൊണ്ടുപോവുകയും ചെയ്യുന്നു.
കണക്കുകൾ വ്യക്തമാക്കുന്നത്
നാല് ആഴ്ചത്തെ ഉപയോഗത്തിന് ശേഷം ലേഖകൻ രേഖപ്പെടുത്തിയ മാറ്റങ്ങൾ ഇവയാണ്:
- API ചിലവ് പഴയതിന്റെ 65% ആയി കുറഞ്ഞു (35% കുറവ്).
- ശരാശരി സമയവ്യയം (Median turnaround time) 42 സെക്കൻഡിൽ നിന്ന് 27 സെക്കൻഡിലേക്ക് കുറഞ്ഞു.
- Opus ഉപയോഗം എല്ലാ റിക്വസ്റ്റുകളും കൈകാര്യം ചെയ്യുന്നതിൽ നിന്ന് ആകെ ടാസ്ക്കുകളുടെ 11% ആയി കുറഞ്ഞു.
ഗുണനിലവാരത്തിൽ വലിയ കുറവില്ലാതെ തന്നെ ഭൂരിഭാഗം ഡെവലപ്മെന്റ് ജോലികളും കുറഞ്ഞ ചിലവുള്ള മോഡലുകൾക്ക് നൽകാൻ കഴിയുമെന്ന് ഈ കണക്കുകൾ കാണിക്കുന്നു. അതേസമയം, ഏറ്റവും കഠിനമായ പ്രശ്നങ്ങൾക്ക് Opus-ന്റെ വലിയ കോൺടെക്സ്റ്റ് വിൻഡോ (context window) ഇപ്പോഴും പ്രയോജനപ്പെടുന്നു.
മറ്റ് ഡെവലപ്പർമാർക്കുള്ള പാഠങ്ങൾ
- തുടക്കം കുറഞ്ഞ ചിലവിൽ ആയിരിക്കട്ടെ, ഉയർന്ന ചിലവിലല്ല. ദൈനംദിന കോഡിംഗ് ജോലികൾക്ക് ഏറ്റവും ശക്തമായ മോഡൽ ആവശ്യമില്ല. അവ്യക്തതയുള്ള ജോലികൾക്ക് Sonnet ഡിഫോൾട്ട് ആയി ഉപയോഗിച്ചത് Haiku വഴി എല്ലാം ചെയ്യാൻ ശ്രമിക്കുന്നതിനേക്കാൾ കൂടുതൽ പണം ലാഭിച്ചു.
- ജോലിയുടെ വലുപ്പമല്ല, പ്രയാസമാണ് അളക്കേണ്ടത്. ഒരു ഫയൽ മുഴുവൻ റീഫാക്ടർ ചെയ്യുന്നതിനേക്കാൾ പ്രയാസകരമായിരിക്കാം ഒരു വരിയിലെ റേസ് കണ്ടീഷൻ (race-condition) പരിഹരിക്കുന്നത്. പരിഹാരം എത്രത്തോളം അവ്യക്തമാണ് എന്നതിനെ അടിസ്ഥാനമാക്കി റൂട്ട് ചെയ്യുക, മാറ്റം വരുത്തുന്ന കോഡിന്റെ വരികളുടെ എണ്ണത്തിനല്ല.
- എസ്കലേഷൻ നിരക്ക് ശ്രദ്ധിക്കുക. എസ്കലേഷനുകളുടെ എണ്ണം കൂടുന്നത് സ്റ്റാറ്റിക് നിയമങ്ങൾ ജോലിഭാരത്തിന് അനുയോജ്യമല്ല എന്നതിന്റെ സൂചനയാണ്. കുറഞ്ഞ ചിലവുള്ള മോഡലുകൾ പരാജയങ്ങൾ ഉണ്ടാക്കുന്നതിന് മുമ്പ് തന്നെ വിഭാഗങ്ങൾ (buckets) ക്രമീകരിക്കുക.
ഏറ്റവും ചിലവേറിയ മോഡലിനെ ഏറ്റവും കഠിനമായ പ്രശ്നങ്ങൾക്ക് മാറ്റിവെക്കുകയും ബാക്കിയുള്ളവ കുറഞ്ഞ ചിലവുള്ള മോഡലുകളെ ഏൽപ്പിക്കുകയും ചെയ്യുന്നത് AI അസിസ്റ്റഡ് ഡെവലപ്മെന്റ് വേഗതയുള്ളതും ലാഭകരവുമാക്കുന്നു. ശരിയായ ജോലിക്കായി ശരിയായ ഉപകരണം തിരഞ്ഞെടുക്കുന്ന കൃത്യമായ റൂട്ടിംഗ് സ്ട്രാറ്റജിയിലാണ് യഥാർത്ഥ നേട്ടം അടങ്ങിയിരിക്കുന്നത്.