நான் வெளியிட்ட AI ஏஜென்ட் 23 யூனிட் டெஸ்ட்களைத் தாண்டியது, ஆனால் நேரலையில் சென்ற ஒரு மணி நேரத்திற்குள் அது ஒரு புதிய தயாரிப்பு அம்சத்தைக் கற்பனை செய்து, உண்மையான விலையை விட மூன்று மடங்கு குறைவான விலையைக் குறிப்பிட்டது. பயனர் அதைச் சுட்டிக்காட்டியபோது, அந்த பாட் தனது கருத்தையே பிடிவாதமாகத் தொடர்ந்தது, அதன் விளைவாக உரையாடல் முடிவுக்கு வந்தது, நான் ஒரு வாடிக்கையாளரை இழந்தேன். இந்தத் தவறு, ஒரு தொகுப்பிலான தீர்மானிக்கப்பட்ட (deterministic) யூனிட் டெஸ்ட்கள் ஒரு ஏஜென்ட்டின் நம்பகத்தன்மையை உறுதிப்படுத்த முடியாது என்பதை நிரூபித்தது.
AI ஏஜென்ட்களுக்கு யூனிட் டெஸ்ட்கள் ஏன் போதுமானதாக இல்லை
பாரம்பரிய குறியீடுகளுக்கு (traditional code) யூனிட் டெஸ்ட்கள் வேலை செய்கின்றன, ஏனெனில் ஒரே உள்ளீடு எப்போதும் ஒரே வெளியீட்டையே தருகிறது. “2 + 2 = 4” என்பது ஒரு எளிய சமன்பாட்டுச் சரிபார்ப்பின் மூலம் நீங்கள் உறுதிப்படுத்தக்கூடிய ஒரு உத்தரவாதம். இருப்பினும், ஒரு LLM-ஆல் இயக்கப்படும் ஏஜென்ட், அதன் தூண்டுதல் (prompt), சூழல் மற்றும் அது பயன்படுத்தும் வெளிப்புறக் கருவிகளின் நிலையைப் பொறுத்து தனது வெளியீட்டை மாற்றிக்கொண்டே இருக்கும். ஒரு துல்லியமான சரச் சமநிலையை (string equality) மட்டும் சரிபார்க்கும் சோதனை, மாயத்தோற்றங்கள் (hallucinations), தொனி மாற்றங்கள் அல்லது பாதுகாப்பு விதிமீறல்களைக் கண்டறியத் தவறிவிடும். ஒரு வாடிக்கையாளரை இழக்கச் செய்த அந்த அமைதியான தோல்வி, நீங்கள் தனித்தனி செயல்பாடுகளை மட்டும் பார்க்காமல், முழுமையான உரையாடலையும் மதிப்பீடு செய்ய வேண்டும் என்பதைக் காட்டுகிறது.
எந்தவொரு அம்சக் குறியீட்டிற்கும் முன்னதாக ஒரு மதிப்பீட்டு கட்டமைப்பகத்தை (evaluation harness) உருவாக்குதல்
நான் மேம்பாட்டு வரிசையை மாற்றினேன்: முதலில் நான்கு அடுக்கு மதிப்பீட்டு கட்டமைப்பகத்தை வடிவமைக்கிறேன், பின்னர் ஏஜென்ட்டை எழுதுகிறேன். இந்த கட்டமைப்பகம் ஒரே முறையில் 131 சோதனைகளைச் செய்கிறது, ஒரு முறை இயங்குவதற்கு தோராயமாக மூன்று காசுகள் (three cents) மட்டுமே செலவாகிறது, மேலும் சுமார் பதினொரு நிமிடங்களில் முடிந்துவிடுகிறது. ஒவ்வொரு சோதனைக்கும் அதைச் கையாளக்கூடிய மிகச்சிறிய மாதிரியை (model) நான் ஒதுக்குகிறேன், பெரிய மற்றும் விலையுயர்ந்த மாதிரிகளை அவை உண்மையிலேயே மதிப்பு சேர்க்கும் தருணங்களுக்காக மட்டும் ஒதுக்குகிறேன்.
அடுக்கு 1 – கருவி செயல்பாடு (Tool functionality)
முதல் பாதுகாப்பு வரிசை, ஏஜென்ட் தனது கருவிகளைச் சரியாக அழைக்கிறதா என்பதைச் சரிபார்க்கிறது. வெற்றிகரமான தேடல்கள், வேண்டுமென்றே தவறாக வடிவமைக்கப்பட்ட வினவல்கள் மற்றும் உருவகப்படுத்தப்பட்ட API தோல்விகள் ஆகியவற்றைச் சோதனைகள் உள்ளடக்கியது. கருவி பயன்பாடு பெரும்பாலும் தீர்மானிக்கப்பட்ட ஒன்றாக இருப்பதால்—அதாவது கோரிக்கை சரியாக உருவாக்கப்பட்டிருக்க வேண்டும் அல்லது API ஒரு பிழையைத் தர வேண்டும்—எளிமையான Python assertions போதுமானதாக இருக்கும். இங்கே ஒரு தவறான கோரிக்கையைக் கண்டறிவது, அடுத்தடுத்த நிலைகளில் ஏற்படும் குழப்பங்களைத் தவிர்க்கிறது.
அடுக்கு 2 – அறிவுறுத்தல்களைப் பின்பற்றுதல் (Instruction following)
அடுத்ததாக, ஏஜென்ட் பாதுகாப்பு எல்லைகளை (guardrails) மதிக்கிறதா என்பதை கட்டமைப்பகம் சரிபார்க்கிறது. ஒரு சிறிய LLM மதிப்பீட்டாளராகச் செயல்பட்டு, ஏஜென்ட்டின் பதில்களைப் பரிசோதிக்கிறது: ஒரு குறிப்பிட்ட பாத்திரத்தில் (character) நீடிப்பது, தடைசெய்யப்பட்ட தலைப்புகளைத் தவிர்ப்பது மற்றும் தேவையான JSON schema-வை வெளியிடுவது போன்றவற்றை இது சரிபார்க்கிறது. யூனிட் டெஸ்ட்கள் கவனிக்கத் தவறும் 'semantic drift' போன்றவற்றை இந்த அடுக்கு கண்டறிகிறது, உதாரணமாகத் திட்டமிடப்படாத ஒரு பாத்திரத்திற்குள் மாறுவது அல்லது உள் தூண்டுதல்களை (internal prompts) கசியவிடுவது போன்றவற்றை இது கண்டறியும்.
அடுக்கு 3 – இலக்கு சார்ந்த நடத்தை (Goal-oriented behavior)
மூன்றாவது அடுக்கு மிகவும் முக்கியமானது. ஏஜென்ட் உண்மையில் அதன் நோக்கத்தை நிறைவேற்றுகிறதா என்பதை இது கேட்கிறது. ஒரு லீட்-ஜெனரேஷன் பாட் (lead-generation bot) என்றால், அது சரியான தகுதி வினாக்களைக் கேட்கிறதா மற்றும் தேவைப்படும்போது ஒரு மனிதரிடம் ஒப்படைக்கிறதா என்பதை உறுதிப்படுத்துவதாகும். நான் இங்கே ஒரு பகுப்பாய்வு சார்ந்த மாதிரியைப் (reasoning-oriented model) பயன்படுத்துகிறேன், ஏனெனில் இது செலவுகளை அதிகரிக்காமல் ஒட்டுமொத்த ஓட்டத்தையும் மதிப்பீடு செய்ய முடியும். முதல் இரண்டு அடுக்குகளைத் தாண்டிய பிறகும், பாட் தனது இலக்கை அடையத் தவறினால், அது மறுவடிவமைப்புக்காகக் குறிக்கப்படும்.
அடுக்கு 4 – செயல்திறன் (Performance)
இறுதியாக, கட்டமைப்பகம் தாமதம் (latency) மற்றும் டோக்கன் உருவாக்கும் வேகத்தைப் பதிவு செய்கிறது. மெதுவான பதில்கள் பயனர் அனுபவத்தைக் கெடுக்கும், குறிப்பாக நிகழ்நேர உரையாடல்களில் (real-time chat). செயல்பாட்டுத் துல்லியத்துடன் இத்தகைய அளவீடுகளைக் கண்காணிப்பதன் மூலம், ஏஜென்ட் துல்லியமாகவும் வேகமாகவும் இருப்பதை நான் உறுதி செய்கிறேன்.
செலவு சேமிப்புத் தெரிவுகள்
ஒரு முறை இயங்குவதற்கு $0.03 என்ற புள்ளி ஒரு சந்தைப்படுத்தல் தந்திரம் அல்ல; இது சோதனை சிக்கலை மாதிரியின் (model) அளவிற்கு ஏற்ப பொருத்துவதன் மூலம் கிடைக்கிறது. தீர்மானிக்கப்பட்ட கருவிச் சோதனைகள் மிகக் குறைந்த விலையுள்ள ரன்டைமில் (runtime) இயங்குகின்றன, அறிவுறுத்தல் இணக்கம் ஒரு இலகுரக மாதிரியைப் பயன்படுத்துகிறது, மேலும் இலக்கு சார்ந்த மதிப்பீடுகள் மட்டுமே அதிக திறன் கொண்ட, விலையுயர்ந்த மாதிரியைப் பயன்படுத்துகின்றன. இந்த அடுக்குமுறை அணுகுமுறை, ஒவ்வொரு குறியீடு மாற்றத்தின் போதும் முழுத் தொகுப்பையும் இயக்குவதற்குத் தேவையான செலவைக் குறைவாக வைத்திருக்க உதவுகிறது.
சமநிலை: வேகம் மற்றும் பாதுகாப்பு
ஒரு கட்டமைப்பகத்தை அறிமுகப்படுத்தியதன் மூலம் ஆரம்பக்கட்டத் தடைகள் ஏற்பட்டன. மேம்பாட்டுச் சுழற்சிகள் (development cycles) நீடித்தன, மற்றும் வெளியீட்டுத் திட்டம் (launch timeline) தாமதமானது.
அடுத்து கவனிக்க வேண்டியவை
- மாதிரி சார்ந்த மதிப்பீட்டாளர்கள் (Model-driven evaluators): LLM-கள் மேம்பட隨著, அடுக்கு 2-ல் உள்ள மதிப்பீட்டாளர் இன்னும் நுணுக்கமானதாக மாற முடியும், இது கொள்கை மீறல்களைத் துல்லியமாகக் கண்டறிவதோடு, தவறான எச்சரிக்கைகளையும் (false positives) குறைக்கும்.
முக்கியக் கருத்து
நீங்கள் தயாரிப்புப் பயன்பாட்டிற்காக (production) AI ஏஜென்ட்களை உருவாக்குகிறீர்கள் என்றால், அடுக்குமுறை மதிப்பீட்டு கட்டமைப்பகம் (layered evaluation harness) என்பது ஒரு விருப்பத்தேர்வு அல்ல; அது ஒரு அடிப்படைத் தேவையாகும். விரிவான சோதனைக்கான செலவை முன்கூட்டியே முதலீடு செய்வதன் மூலம்—ஒரு முறைக்கு $0.03, ஒரு தொகுப்பிற்கு பதினொரு நிமிடங்கள்—யூனிட் டெஸ்ட்களால் கண்டறிய முடியாத அமைதியான தோல்விகளிலிருந்து உங்களைப் பாதுகாத்துக் கொள்ளலாம்.