பெரும்பாலான பொறியியல் குழுக்கள் இன்னும் AI ஏஜென்ட்களை (agents) கணித வீட்டுப்பாடங்களை மதிப்பிடுவது போலவே மதிப்பிடுகின்றன. அவை இறுதி வெளியீட்டை மட்டுமே பார்க்கின்றன. பதில் சரியாக இருந்தால், அவை வெளியீட்டிற்கு அனுமதி அளித்துவிட்டு அடுத்த வேலையைப் பார்க்கின்றன. இது ஒரு ஆபத்தான குறுக்குவழி. ஒரு சரியான பதில், ஆழமாகப் பழுதான ஒரு அமைப்பை மறைக்கக்கூடும்.
உண்மையான கதை அந்த ஏஜென்ட் அங்கு சென்றடைந்த பாதையில் உள்ளது. அந்தப் பாதை 'ஏஜென்ட் டிரஜெக்டரி' (agent trajectory) என்று அழைக்கப்படுகிறது. இதில் ஒவ்வொரு டூல் கால் (tool call), ஒவ்வொரு ரூட்டிங் முடிவு (routing decision), ஏஜென்ட் மறுபரிசீலனை செய்யத் தயங்கும் ஒவ்வொரு இடைவெளியும் அடங்கும். இதை ஏஜென்ட்டின் வழித்தடக் குறிப்புகள் (trail of breadcrumbs) என்று நீங்கள் நினைக்கலாம். நீங்கள் இலக்கை மட்டும் ஆய்வு செய்தால், வழியெங்கும் சிதறிக் கிடக்கும் எச்சரிக்கை அறிகுறிகள் அனைத்தையும் நீங்கள் தவறவிடுவீர்கள்.
குழப்பமான பாதைகளில் உள்ள சிக்கல்
ஒரு ஏஜென்ட் ஒரு போதையாளி ஓட்டுநரைப் போலச் செயல்பட்டாலும் சரியான பதிலைக் கண்டடையலாம். அது தவறான டூல்களைப் பயன்படுத்தித் திசைமாறி, மீண்டும் ரூட்டருக்குத் திரும்பி, தேவையற்ற காரணங்களைச் சுழற்சி முறையில் சிந்தித்து, இறுதியில் ஏதோ ஒரு சரியான விஷயத்தைச் சுதறிப் பிடிக்கலாம். பயனர் ஒரு தெளிவான முடிவைப் பார்க்கிறார். ஆனால் திரைமறைவில், சிஸ்டம் வளங்களை வீணாக்குவதோடு அபாயங்களையும் சேர்த்துக்கொண்டே இருக்கிறது.
நடைமுறையில் இந்த குழப்பம் உண்மையில் எப்படி இருக்கும்?
முதலாவதாக, தேவையற்ற டூல் கால் (redundant tool call) உள்ளது. ஏஜென்ட் உங்கள் வாடிக்கையாளர் தரவுத்தளத்தைக் (customer database) கேட்கிறது, முடிவைப் பெறுகிறது, ஐந்து வினாடிகளுக்குப் பிறகு அதை மறந்துவிடுகிறது, மேலும் அதே அளவுருக்களுடன் (parameters) அதே பதிவை மீண்டும் கேட்கிறது. இது தரவு சார்ந்த சிக்கல் அல்ல. இது ஒரு டிரஜெக்டரி சிக்கல். ஏஜென்ட் தனது நிலையை (state) தக்கவைக்கத் தவறிவிட்டது, அதனால் அது வேலையைத் திரும்பத் திரும்பச் செய்கிறது.
அடுத்து, தவறான டூலை முதலில் பயன்படுத்தும் முறை (wrong-tool-first pattern) உள்ளது. ஒரு கோடிங் ஏஜென்ட் (coding agent), ஏற்கனவே உள்ளூர் களஞ்சியத்தில் (local repository) இருக்கும் ஒரு ஃபங்ஷன் வரையறையைத் (function definition) தேட இணையத்தில் முயற்சி செய்யலாம். அல்லது ஒரு சப்போர்ட் ஏஜென்ட் (support agent), பயனரின் கேள்விக்குத் தெளிவாக அக்கவுண்ட் செட்டிங்ஸ் டூல் (account settings tool) தேவைப்படும்போது, பில்லிங் API-ஐத் தேடலாம். ஒவ்வொரு தவறான தேர்வும் டோக்கன்களை (tokens) வீணாக்குகிறது, தாமதத்தை (latency) அதிகரிக்கிறது மற்றும் உண்மையான வேலை தொடங்குவதற்கு முன்பே கான்டெக்ஸ்ட் லிமிட்கள் (context limits) முறியடிக்கப்படுவதற்கான வாய்ப்பை அதிகரிக்கிறது.
ரூட்டர் லூப்கள் (Router loops) மற்றொரு எச்சரிக்கை அறிகுறியாகும். முடிவு எடுக்கும் முனை (decision node) ஒரு முடிவுக்கு வர முடியாமல் போகிறது. அது பணியை கிளை A-க்கு அனுப்புகிறது, பிறகு தன் முடிவை மாற்றிக்கொண்டு, அதைத் திரும்பப் பெறுகிறது, கிளை B-க்கு அனுப்புகிறது, பின்னர் எந்த காரணமும் இன்றி ஒரு பொதுவான ஃபால்பேக் நோடுக்கு (fallback node) வழிநடத்துகிறது. ஒவ்வொரு லூப்பும் ஒரு நெட்வொர்க் ஹாப் (network hop) மற்றும் இறுதி டீபக் லாக்-இல் (debug log) குழப்பத்தின் மற்றொரு அடுக்கைச் சேர்க்கிறது.
இறுதியாக, மீண்டும் மீண்டும் செய்யப்படும் பகுப்பாய்வு (repeated analysis) உள்ளது. ஏஜென்ட் ஒரு முடிவை உறுதிப்படுத்தப்பட்டதாகக் கருதாமல், ஒவ்வொரு நிலையிலும் அதே முடிவை மீண்டும் மீண்டும் எடுக்க முயல்கிறது. இது ஒவ்வொரு வெட்டுக்கும் முன்னால் பலகையை பத்து முறை அளவிடும் ஒரு தச்சரைப் போன்றது. முதல் அளவீடு சரியாக இருந்திருக்கலாம், ஆனால் அடுத்த ஒன்பது அளவீடுகளும் வீணான உழைப்பு மட்டுமே.
இந்த கூடுதல் படிகள் உண்மையான விளைவுகளை ஏற்படுத்துகின்றன. தாமதம் (Latency) குவிகிறது. ஒரு சின்க்ரோனஸ் சாட் இன்டர்ஃபேஸில் (synchronous chat interface), கூடுதல் மூன்று வினாடிகள் ஒரு யுகம் போலத் தோன்றும். பெரிய அளவில் பார்க்கும்போது, அந்த வினாடிகள் கணினிச் செலவில் (compute) ஆயிரக்கணக்கான டாலர்களாக மாறுகின்றன. தோல்வி அபாயமும் அதிகரிக்கிறது. ஒவ்வொரு தேவையற்ற ஹாப்-உம் (hop), ஒரு வெளிப்புற API டைம் அவுட் (time out) ஆகவோ, கான்டெக்ஸ்ட் விண்டோ (context window) நிரம்பவோ அல்லது ரேஸ் கண்டிஷன் (race condition) உருவாகவோ வாய்ப்பளிக்கிறது. ஏதேனும் ஒன்று முறிந்துவிட்டால், ஸ்பாகெட்டி போலத் தோற்றமளிக்கும் ஒரு டிரேஸை (trace) டீபக் செய்வது கடினம். ஏஜென்ட் ஏன் ஏழாவது படியை எடுத்தது என்பதை மீண்டும் மீண்டும் ஆராய்ந்து நேரத்தை வீணடிப்பீர்கள், இறுதியில் அந்த ஏழாவது படி வரவே தேவையில்லை என்பதை உணர்வீர்கள்.
கன்வர்ஜென்ஸ் (Convergence) என்பது உண்மையில் என்ன?
டிரஜெக்டரி என்பது பாதை என்றால், கன்வர்ஜென்ஸ் என்பது அதன் செயல்திறனின் அளவீடு ஆகும். பயனரின் கோரிக்கைக்கும் சரியான தீர்வுக்குமான மிகக் குறுகிய மற்றும் சாத்தியமான பாதையை ஏஜென்ட் எவ்வளவு நெருக்கமாகப் பின்பற்றுகிறது என்பதை கன்வர்ஜென்ஸ் உங்களுக்குச் சொல்கிறது.
இது துல்லியத்திற்கு (accuracy) சமமானது அல்ல. துல்லியம் என்பது ஒரு மேலோட்டமான கருவி. இறுதி நிலை சரியாக இருக்கிறதா என்று அது கேட்கிறது. கன்வர்ஜென்ஸ் அந்தப் பயணம் அறிவுப்பூர்வமாக இருந்ததா என்று கேட்கிறது. அதிக துல்லியமும் குறைந்த கன்வர்ஜென்ஸும் கொண்ட ஒரு ஏஜென்ட், வெற்றியைப் போர்த்திய ஒரு சுமை (liability) போன்றது. அதிக கன்வர்ஜென்ஸும் நடுத்தரமான துல்லியமும் கொண்ட ஒரு ஏஜென்ட்டைச் சரிசெய்வது பொதுவாக எளிது, ஏனெனில் அதன் தர்க்கம் (reasoning) தெளிவாக இருக்கும் மற்றும் அதன் தவறுகள் குறிப்பிட்ட இடங்களிலேயே இருக்கும்.
அந்தப் பணி வகைக்கு (task class) நீங்கள் வரையறுத்துள்ள மிகக் குறுகிய பாதையோடு, ஏஜென்ட் உண்மையில் எடுக்கும் படைகளை ஒப்பிடுவதன் மூலம் ஒரு தோராயமான கன்வர்ஜென்ஸ் ஸ்கோரை (convergence score) நீங்கள் கணக்கிடலாம். ஒரு சாதாரண ரீஃபண்ட் கோரிக்கை (refund query) சரியாக மூன்று டூல் கால்களைக் கொண்டிருக்க வேண்டும், ஆனால் ஏஜென்ட் ஒன்பது முறைகளைப் பயன்படுத்தினால், உங்கள் கன்வர்ஜென்ஸ் விகிதம் குறைகிறது என்று அர்த்தம். பல்வேறு வகையான வீணடிப்புகளுக்குத் தனித்தனி முக்கியத்துவம் (weighting) அளிப்பதன் மூலம் இதை நீங்கள் மேம்படுத்தலாம். ஒரு டூலின் தாமதம் மற்றும் விலையைப் பொறுத்து, ஒரு தவறான டூல் கால், ஒரு தேவையற்ற கால் செய்வதை விட அதிகச் செலவை ஏற்படுத்தலாம். எந்த மதிப்பையும் சேர்க்காத ஒரு ரூட்டர் லூப் (router loop), மிகக் கடுமையானத் தண்டனையை (penalty) சந்திக்கலாம், ஏனெனில் அது கட்டமைப்பு ரீதியான