மதிப்பீடு சார்ந்த ஏஜென்ட் மேம்பாடு: உள்ளுணர்வு அடிப்படையில் ப்ராம்ப்ட்களைச் சரிசெய்வதை நான் எப்படி நிறுத்தினேன்

நான் ஒரு ப்ராம்ப்டை மாற்றினேன். அடுத்த முறை அது சிறப்பாகத் தெரிந்தது. அந்த மாற்றம் உதவியதா அல்லது நான் அதிர்ஷ்டவசமாகச் செய்தேனா?

நீண்ட காலமாக, எனது பதில் "அப்படித்தான் நினைக்கிறேன்" என்பதாகவே இருந்தது. ஒரு கட்டளையைச் சற்று மாற்றியமைப்பேன், பைப்லைனை இயக்கி, அது வெற்றியடைவதைப் பார்த்துவிட்டு, அதை வெளியிடுவேன். இது உள்ளுணர்வு அடிப்படையிலான பொறியியல் (vibes-based engineering). ஏஜென்ட்களை உருவாக்கும் கிட்டத்தட்ட அனைவரும் இதைத்தான் செய்கிறார்கள், ஏனெனில் இதற்கு மாற்றாக இருக்கும் வழி கடினமாகத் தோன்றுகிறது.

ஆனால் கோடிங் ஏஜென்ட்கள் 'non-deterministic' (நிச்சயமற்றவை). ஒரே பணியை நீங்கள் இரண்டு முறை செய்தாலும் வெவ்வேறு முடிவுகள் கிடைக்கலாம். ஒருமுறை சிறப்பாகச் செயல்படுவது உங்களுக்கு எதையும் சொல்லாது. உங்கள் மாற்றம் வேலை செய்ததா அல்லது வெறும் அதிர்ஷ்டம் தானா என்பதை உங்களால் சொல்ல முடியாது.

இயந்திரக் கற்றல் (machine learning) ஒழுக்கத்தைப் பயன்படுத்தி நான் இதைத் தீர்த்தேன். எனது முழு அமைப்பையும் உள்ளடக்கிய ஒரு மதிப்பீட்டு கட்டமைப்பை (evaluation framework) நான் உருவாக்கினேன்.

அந்தக் கட்டமைப்பு எவ்வாறு செயல்படுகிறது என்பது இங்கே:

• இலக்கு (Target): மாற்றப்படாத ஒரு கோட்பேஸ் (frozen codebase). மதிப்பெண்கள் ஒப்பிடத்தக்கதாக இருக்க இது மாறாமல் இருக்கும். • பணி (Task): ஒரு ப்ராம்ப்ட் மற்றும் ஓர் Oracle கொண்ட ஒரு குறிப்பிட்ட பெஞ்ச்மார்க் உருப்படி. • Oracle: ஒரு நிச்சயமான சரிபார்ப்பு (deterministic check). இவை கண்டிப்பாகத் தேர்ச்சி பெற வேண்டிய ஷெல் கட்டளைகள் (shell commands). • மாறுபாடு (Variant): நீங்கள் சோதிக்கும் குறிப்பிட்ட மாற்றம், உதாரணமாக ஒரு புதிய பிளானர் (planner). • சோதனை (Trial): ஒருமுறை இயக்குதல். சீரற்ற தன்மையைக் கணக்கில் கொள்ள ஒவ்வொரு பணியையும் நான் பலமுறை இயக்குகிறேன்.

வெவ்வேறு தோல்விகளைக் கண்டறிய நான் இரண்டு வகையான ஸ்கோரிங் முறைகளைப் பயன்படுத்துகிறேன்:

  • கோட் கிரேடர்கள் (Code Graders - Deterministic): இவை டெஸ்ட் தேர்ச்சி விகிதம், செலவு, நேரம் மற்றும் கோப்பு மாற்றங்களைச் சரிபார்க்கின்றன.
  • LLM ஜட்ஜ் (LLM Judge - Probabilistic): ஒரு தனித்த, நிலையான மாடல் விவரக்குறிப்பின் தரம் (spec quality) மற்றும் செயலாக்கத் துல்லியத்தை (implementation fidelity) மதிப்பிடுகிறது.

கோட் கிரேடர்கள் கோட் இயங்குகிறதா என்பதைச் சொல்கின்றன. ஜட்ஜ் கோட் நன்றாக இருக்கிறதா என்பதைச் சொல்கிறது. உங்களுக்கு இவை இரண்டும் தேவை.

நான் சராசரியைப் பயன்படுத்துவதையும் நிறுத்திவிட்டேன். சராசரிகள் (Means) ஏஜென்ட்களின் உண்மைத் தன்மையை மறைக்கின்றன. ஒரு பணி 3 முறைக்கு 2 முறை வெற்றியடைந்தால், அது சரியாகத் தோன்றலாம். ஆனால் அது நம்பகமானது அல்ல. அதற்குப் பதிலாக, நான் இரண்டு அளவீடுகளைப் பயன்படுத்துகிறேன்:

  • pass@k: ஏஜென்ட் குறைந்தது ஒரு முறையாவது வெற்றி பெற்றதா? (திறன் - Capability)
  • pass^k: ஏஜென்ட் ஒவ்வொரு முறையும் வெற்றி பெற்றதா? (நம்பகத்தன்மை - Reliability)

pass^k-இல் ஏற்படும் முன்னேற்றமே உண்மையான வெற்றி. அதாவது நீங்கள் ஏஜென்ட்டை அதிர்ஷ்டவசமாகச் செயல்பட வைக்காமல், சீராகச் செயல்பட வைத்துள்ளீர்கள் என்று அர்த்தம்.

அமைப்பைத் துல்லியமாக வைத்திருக்க, ஆழமான புரிதல் தேவைப்படும் கடினமான பணிகளை நான் சேர்க்கிறேன். ஒரு ஏஜென்ட் ஒரு உண்மையான பிழையில் (bug) தோல்வியடையும் போது, அந்தத் தோல்வியைத் தற்காலிகமானதாக வைக்காமல் ஒரு நிரந்தரப் பணியாக மாற்றுகிறேன். இது ஒரு மூடிய சுழற்சியை (closed loop) உருவாக்குகிறது. ஏஜென்ட் மேம்பட மேம்பட, பெஞ்ச்மார்க் கடினமாகிவிடும்.

இந்தக் கட்டமைப்பு அதிக வேலைப்பளுவைக் கொண்டது, ஆனால் நான் உருவாக்கியவற்றிலேயே இது அதிக பலன் தரக்கூடியது. இது "இது சிறப்பாக இருக்கும் என்று நினைக்கிறேன்" என்பதை "இது குறைந்த செலவில் 20% அதிக நம்பகமானது" என மாற்றியது.

கோடிங் ஏஜென்ட்களைக் காட்சிப்படுத்துவது (demo) எளிது, ஆனால் அவற்றை நம்புவது கடினம். நீங்கள் வெறும் டெமோக்களைத் தாண்டிச் செல்ல விரும்பினால், அளவிடுவதற்கு (measure) நீங்கள் முடிவு செய்ய வேண்டும்.

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi