மூன்று Claude மாடல்களைக் கொண்டு ஒரு தனிநபர் மென்பொருள் உருவாக்குநர் மேற்கொண்ட சோதனை, மாதாந்திர API செலவுகளை 35% குறைத்ததுடன், சராசரி பணி தாமதத்தையும் (median task latency) 42 வினாடிகளிலிருந்து 27 வினாடிகளாகக் குறைத்தது. தெளிவற்ற தன்மை குறைந்த எளிய பணிகளை மலிவான Haiku மாடலுக்கும், வழக்கமான பணிகளை Sonnet மாடலுக்கும், மற்றும் அதிக முக்கியத்துவம் வாய்ந்த சிக்கலான பிரச்சனைகளுக்கு வலிமையான Opus மாடலுக்கும் ஒதுக்குவதன் மூலம், "எல்லாவற்றிற்கும் சிறந்த மாடல்" (best-model-for-everything) என்ற அணுகுமுறை ஒரு செலவு மிகுந்த பழக்கம் என்பதை அந்த ஆசிரியர் நிரூபித்தார்.
வழிநடத்துதல் (routing) ஏன் முக்கியமானது
அந்த ஆசிரியர் ஒரு தன்னாட்சி குறியீட்டு முகவரை (autonomous coding agent) இயக்குகிறார். அது lint திருத்தங்கள், புதிய அம்சங்களைச் சேர்த்தல், பாதுகாப்பு ஆய்வுகள் மற்றும் ஆழமான பிழைத்திருத்த அமர்வுகள் (debugging sessions) போன்ற தொடர்ச்சியான மேம்பாட்டுப் பணிகளைப் பெறுகிறது. பல மாதங்களாக, அதிக தரம் எப்போதும் விலையை விட முக்கியமானது என்று கருதி, அந்த முகவர் ஒவ்வொரு கோரிக்கையையும் மிகவும் திறமையான Claude மாடலான Opus-க்கு அனுப்பியது. Opus ஒவ்வொரு டோக்கனுக்கும் அதிக விலையைக் கோருவதால், அதற்கான செலவு கட்டுப்பாடின்றி அதிகரித்தது.
ஆசிரியர் ஒரு படிநிலை வழிநடத்தும் முறையை (tiered routing scheme) அறிமுகப்படுத்தியபோது, செலவு அதன் ஆரம்ப அளவின் 65% ஆகக் குறைந்தது மற்றும் மொத்தப் பணிகளில் Opus-ன் பயன்பாடு 11% ஆகக் குறைந்தது.
மூன்று அடுக்கு முறை எவ்வாறு செயல்படுகிறது
இந்த வழிநடத்தும் தர்க்கம் (routing logic) ஒரு பணி எத்தனை வரிகள் குறியீட்டைத் தொடுகிறது என்பதன் அடிப்படையில் அல்லாமல், அதன் தெளிவற்ற தன்மை (ambiguity) அடிப்படையிலானது. ஆசிரியர் மூன்று பிரிவுகளை வரையறுத்தார்:
- Haiku – தெளிவற்ற தன்மை குறைந்த, தீர்மானிக்கப்பட்ட (deterministic) பணிகள். உதாரணங்கள்: lint எச்சரிக்கைகளைச் சரிசெய்தல், மாறிகளின் பெயர்களை மாற்றுதல், log கோப்புகளைச் சுருக்குதல். சரியான விடை பொதுவாக ஒரு வரி குறியீடு அல்லது உரையாக இருக்கும்.
- Sonnet – இயல்பான முதன்மைப் பணிப்பாளர் (default workhorse). அம்சம் செயலாக்கம் (feature implementation), வழக்கமான பிழைத் திருத்தங்கள் மற்றும் தரப்படுத்தப்பட்ட மறுசீரமைப்புகள் (refactors) போன்ற பணிகளைக் கையாளும்; இதில் சிக்கல் தெளிவாக இருக்கும் ஆனால் தீர்வு பல படிகளைக் கொண்டிருக்கலாம்.
- Opus – அதிக முக்கியத்துவம் வாய்ந்த, அதிக தெளிவற்ற தன்மை கொண்ட பணிகள். கட்டமைப்பு முடிவுகள் (architecture decisions), பாதுகாப்பு ஆய்வுகள், சிக்கலான பிழைத்திருத்த அமர்வுகள் அல்லது சரியான வழிமுறை தெளிவற்ற நிலையில் இருந்து, ஒரு தவறான முடிவு முழு கட்டமைப்பையும் (pipeline) பாதிக்கும் வாய்ப்புள்ள எந்தவொரு பணியும் இதில் அடங்கும்.
இந்த விதிகளின் அடிப்படையில் ஒவ்வொரு வரும் கோரிக்கையையும் பொருத்தமான மாடலுக்கு ஒரு நிலையான தேடல் அட்டவணை (static lookup table) ஒதுக்குகிறது. ஆசிரியர், ஒவ்வொரு முறையும் எந்தப் படிநிலையைத் தேர்ந்தெடுக்க வேண்டும் என்று முடிவு செய்யும் ஒரு "புத்திசாலித்தனமான" (smart) மாடலை முயற்சித்தார், ஆனால் கூடுதல் டோக்கன் பயன்பாடு அந்தச் சேமிப்பையே அழித்துவிட்டது. எளிய நிலையான விதிகள் மொத்தப் பணியில் சுமார் 80% பகுதியைச் சரிசெய்து, அமைப்பை மலிவாகவும் கணிக்கக்கூடியதாகவும் வைத்திருந்தன.
அடுத்த நிலைக்கு உயர்த்தும் பாதுகாப்பு வலை (The escalation safety net)
மலிவான மாடல்களும் தவறுகளைச் செய்யலாம். ஒரு தவறான Haiku அல்லது Sonnet பதிலால் முழு கட்டமைப்பும் (build) சீர்குலைவதைத் தடுக்க, இரண்டு தோல்விகளுக்குப் பிறகு அந்தப் பணி அடுத்த நிலைக்கு உயர்த்தப்படுகிறது. இந்த பாதுகாப்பு வலை பிழைகளை முன்கூட்டியே கண்டறிந்து, மனிதத் தலையீடு இன்றி கட்டமைப்பைத் தடையின்றி இயங்க வைக்கிறது.
எண்கள் உண்மையைச் சொல்கின்றன
மூன்று அடுக்கு வழிநடத்துபவரை (tiered router) நான்கு வாரங்கள் இயக்கிய பிறகு, ஆசிரியர் கண்டறிந்த மாற்றங்கள் இவை:
- API செலவு ஆரம்பச் செலவில் 65% ஆகக் குறைந்தது (35% குறைப்பு).
- சராசரி பதில் அளிக்கும் நேரம் (Median turnaround time) 42 வினாடிகளிலிருந்து 27 வினாடிகளாகக் குறைந்தது.
- Opus பயன்பாடு ஒவ்வொரு கோரிக்கையையும் கையாளுவதிலிருந்து குறைந்து, மொத்தப் பணிகளில் 11% ஆகக் குறைந்தது.
தரத்தில் பெரிய சரிவு ஏற்படாமல், பெரும்பாலான மேம்பாட்டுப் பணிகளை மலிவான மாடல்களிடம் ஒப்படைக்க முடியும் என்பதையும், அதே சமயம் கடினமான பிரச்சனைகளுக்கு Opus-ன் பெரிய சூழல் சாளரம் (context window) இன்னும் பயனளிக்கிறது என்பதையும் இந்தத் தரவுகள் காட்டுகின்றன.
பிற மென்பொருள் உருவாக்குநர்களுக்கான பாடங்கள்
- உயர் மட்டத்திலிருந்து தொடங்காமல், குறைந்த மட்டத்திலிருந்து தொடங்குங்கள். அன்றாட குறியீட்டுப் பணிகளுக்கு மிகவும் சக்திவாய்ந்த மாடல் தேவையில்லை. தெளிவற்ற பணிகளுக்கு Sonnet-ஐ இயல்பானதாக மாற்றுவது, அனைத்தையும் Haiku மூலம் செய்ய முயற்சிப்பதை விட அதிகப் பணத்தைச் சேமித்தது.
- அளவை அல்ல, கடினத்தன்மையைக் கணக்கிடுங்கள். ஒரு முழு கோப்பையும் மறுசீரமைப்பதை விட, ஒரு வரி race-condition திருத்தம் கடினமாக இருக்கலாம். தீர்வு எவ்வளவு தெளிவற்றதாக இருக்கிறது என்பதைப் பொறுத்து பணிகளைப் பிரியுங்கள், மாற்றப்படும் வரிகளின் எண்ணிக்கையை வைத்து அல்ல.
- அடுத்த நிலைக்கு உயர்த்தப்படும் விகிதத்தைக் (escalation rate) கவனியுங்கள். அடுத்த நிலைக்கு உயர்த்தப்படும் பணிகளின் எண்ணிக்கை அதிகரிப்பது, நிலையான விதிகள் இனி பணிச்சுமையுடன் ஒத்துப்போகவில்லை என்பதைக் குறிக்கிறது. மலிவான மாடல்கள் கட்டமைப்பில் தோல்விகளை ஏற்படுத்தத் தொடங்குவதற்கு முன்பே பிரிவுகளைச் சரிசெய்யுங்கள்.
மிகவும் விலையுயர்ந்த மாடலை கடினமான பிரச்சனைகளுக்கு மட்டும் ஒதுக்கி வைத்துக்கொண்டு, மற்றவற்றை மலிவான மாடல்களிடம் ஒப்படைப்பது, AI-உதவி பெறும் மேம்பாட்டுப் பணிகளை வேகமாகவும் மலிவாகவும் வைத்திருக்கும். சரியான கருவியை சரியான வேலைக்கு இணையும் ஒரு ஒழுக்கமான வழிநடத்தும் உத்தியில்தான் (routing strategy) உண்மையான நன்மை உள்ளது.