ஏஜென்ட் டூல் அழைப்புகளுக்கான வரையறுக்கப்பட்ட மறுமுயற்சிகள்
எங்கள் ஏஜென்ட் ஏற்படுத்திய மிக மோசமான சம்பவம் தவறான பதிலல்ல. அது ஒரு லூப் (loop).
ஒரு டூல் அழைப்பு தோல்வியடைந்தது. ஏஜென்ட் அதை மீண்டும் முயற்சித்தது. அந்த மறுமுயற்சியும் தோல்வியடைந்தது. ஏஜென்ட் தொடர்ந்து கொண்டே இருந்தது. இது டோக்கன்களை (tokens) வீணடித்ததுடன், ஒரு நிமிடத்தில் நூற்றுக்கணக்கான முறை எங்கள் API-ஐ அணுகியது.
நாங்கள் சொன்னபடியே ஏஜென்ட் செய்தது. ஒரு டூல் தோல்வியடைந்தால் மீண்டும் முயற்சி செய்யுமாறு நாங்கள் சொன்னோம். ஆனால் எப்போது நிறுத்த வேண்டும் என்று சொல்ல மறந்துவிட்டோம்.
தற்காலிக பிழைகளுக்கு மறுமுயற்சிகள் (retries) நல்லது. ஆனால் பிரச்சனை என்னவென்றால், ஏஜென்ட்களால் ஒரு தற்காலிக பிழையையும் நிரந்தர பிழையையும் வேறுபடுத்திப் பார்க்க முடியாது. வரம்புகள் இல்லையென்றால், ஏஜென்ட் ஒரு தோல்வியடைந்த அழைப்பை ஏதோ ஒன்று அதை நிறுத்தும் வரை மீண்டும் மீண்டும் முயற்சித்துக் கொண்டே இருக்கும்.
பாரம்பரியக் குறியீடுகள் (traditional code) மறுமுயற்சி வரம்புகளைப் பயன்படுத்துகின்றன. ஆனால் ஏஜென்ட் டூல் அழைப்புகள் இந்த முடிவெடுக்கும் திறனை மாடலின் பகுத்தறிவுக்குள் (model reasoning) கொண்டு சென்றன. இது அந்த லூப்பைத் தெரியாததாகவும், வரம்பற்றதாகவும் மாற்றியது.
மாடலுக்கு வெளியே இரண்டு பட்ஜெட்களை (budgets) சேர்ப்பதன் மூலம் நாங்கள் இதைச் சரிசெய்தோம்:
• அழைப்புக்கான வரம்பு (Per-call cap): ஒரு குறிப்பிட்ட டூலுக்கு ஒரு குறிப்பிட்ட எண்ணிக்கையிலான முயற்சிகள் மட்டுமே அனுமதிக்கப்படும். அது தோல்வியடைந்தால், ஏஜென்ட் வேறு ஒரு வழியை முயற்சிக்க வேண்டும். • அமர்வுக்கான பட்ஜெட் (Per-session budget): ஒட்டுமொத்தப் பணிக்கும் மொத்த டூல் அழைப்புகளுக்கு ஒரு வரம்பு உண்டு. ஏஜென்ட் இந்த வரம்பை எட்டினால், அது நின்று உதவி கேட்கும்.
வரம்பு என்பதே தீர்வாகாது. வரம்பிற்குப் பிறகு என்ன நடக்கிறது என்பதே முக்கியம்.
நீங்கள் அப்படியே நிறுத்திவிட்டால், ஏஜென்ட் சிக்கிக்கொள்ளும். அதற்குப் பதிலாக, நாங்கள் ஏஜென்ட்டிற்கு ஒரு தெளிவான செய்தியை வழங்குகிறோம். அழைப்பு தோல்வியடைந்துவிட்டது என்றும், அதை மீண்டும் முயற்சிக்கக் கூடாது என்றும் நாங்கள் கூறுகிறோம். இது ஒரு லூப்பை ஒரு முடிவாக மாற்றுகிறது. பொதுவாக, ஏஜென்ட் அதன் பிறகு ஒரு புதிய அணுகுமுறையைத் தேர்ந்தெடுக்கும்.
இதைச் சேர்த்ததிலிருந்து, டூல் தவறாகப் பயன்படுத்தப்படுவதால் ஏற்படும் லூப்கள் கிட்டத்தட்ட மறைந்துவிட்டன. அவை நடக்கும்போது கூட, பெரிய API கட்டணங்களை உருவாக்குவதற்குப் பதிலாக, முறையாகக் கையாளப்படுகின்றன.
சரியான வரம்பைக் கண்டறிவது கடினம். மிகக் குறுகிய வரம்பு நீண்ட பணிகளைத் தடுத்துவிடும். தளர்வான வரம்பு அதிகச் செலவுமிக்க லூப்களை அனுமதிக்கும். நாங்கள் எங்கள் வரம்புகளை 95-வது சதவீதப் பணி நீளங்களின் (95th percentile task lengths) அடிப்படையில் அமைத்துள்ளோம்.
இந்த பட்ஜெட்களை அமைக்க உங்களிடம் சிறந்த வழி ஏதேனும் உள்ளதா? கருத்துப் பகுதியில் எனக்குத் தெரியப்படுத்துங்கள்.
Optional learning community: https://t.me/GyaanSetuAi