AI ஏஜென்ட்களை மதிப்பிடுவது எப்படி: சோதனைத் தொகுப்புகள், மதிப்பீட்டாளர்கள், பின்னடைவுச் சரிபார்ப்புகள்

ஒவ்வொரு சிறந்த AI தயாரிப்பின் பின்னணியிலும், பிழைகளை முன்கூட்டியே கண்டறிந்து, ஏஜென்ட் சரியாகச் செயல்படுவதை உறுதிசெய்யும் evals எனப்படும் வலுவான AI ஏஜென்ட் மதிப்பீட்டுச் செயல்முறை உள்ளது. ஒருவரின் சார்பாகப் பணத்தைத் திருப்பியளிப்பது போன்ற அதிக அபாயமுள்ள செயல்களைச் செய்யும் AI ஏஜென்ட்களுக்கு evals மிகவும் முக்கியமானவை.

அந்தச் செயல்முறையை உருவாக்குவதற்குச் சிறிது தொழில்நுட்ப அறிவும் தரவுப் பகுப்பாய்வுத் திறன்களும் தேவை. ஆனால், அது கேட்பதற்குத் தோன்றுவது போல் அச்சமூட்டுவதோ அணுக முடியாததோ அல்ல. நீங்கள் தொடங்க உதவும் வகையில், AI ஏஜென்ட்களை மதிப்பிடுவதற்கான ஆறு நடைமுறைப் படிகளையும், இந்தச் செயல்முறையைச் சீர்குலைக்கும் பொதுவான தவறான கருத்துகளையும் தொகுத்துள்ளோம்.

AI ஏஜென்ட்டை மதிப்பிடுவது என்றால் என்ன?

AI ஏஜென்ட்டை மதிப்பிடுவது என்பது, பணிகளைச் சரியாக நிறைவுசெய்வதில் அதன் செயல்திறனையும், அதன் முடிவுகள் நிறுவனத்தின் தேவைகளைப் பூர்த்திசெய்கின்றனவா என்பதையும் ஆராய்வதாகும். நடைமுறையில் சொன்னால், AI ஏஜென்ட் மதிப்பீடுகள் அல்லது evals என்பவை, ஏஜென்ட் அதற்கென உத்தேசிக்கப்பட்ட பணிக்குப் போதுமான நம்பகத்தன்மையுடன் செயல்படுகிறதா என்பதை நிறுவனங்கள் தீர்மானிக்க உதவும் குறிப்பிட்ட அளவீடுகள் ஆகும்.

ஓர் உற்பத்தி ஆலையில் உதிரிபாகங்களின் இருப்பைச் சரிபார்த்து, மறுநிரப்புக் கோரிக்கைகளைத் தயாரிக்கும் ஒரு AI கொள்முதல் ஏஜென்ட்டை எடுத்துக்கொள்ளுங்கள். அங்கீகரிக்கப்பட்ட ஒரு பாகம் கிடைக்காவிட்டால் அல்லது சப்ளையர் தகவல் காலாவதியாகியிருந்தால், ஏஜென்ட் அந்தச் சிக்கலைச் சுட்டிக்காட்டுமா, அல்லது அங்கீகரிக்கப்படாத மாற்றுப் பாகத்தைப் பரிந்துரைக்குமா?

அந்தச் சிக்கலைச் சரிசெய்ய அதன் சிஸ்டம் ப்ராம்ப்ட்டை மாற்றினால், புதிதாக வேறொரு சிக்கலை உருவாக்கவில்லை என்பதை எப்படி அறிவீர்கள்?

மதிப்பீடு இல்லாவிட்டால், தயாரிப்பு மேலாளர்கள் அடிப்படையில் ஊகங்களையே நம்பியிருக்க வேண்டியிருக்கும். எனவே, செயல்திறனை அளவிடவும், மீண்டும் மீண்டும் வரும் சிக்கல்களைக் கண்டறியவும், மாற்றங்களை அதிக நம்பிக்கையுடன் சோதிக்கவும் evals ஒரு பின்னூட்டச் சமிக்ஞையை வழங்குகின்றன.

இருப்பினும், ஒரு ஏஜென்ட் மதிப்பீடு ஓர் இயக்கத்தின் பல அம்சங்களை ஆராயலாம்:

• இறுதி முடிவின் தரம்
• ஏஜென்ட் பயன்படுத்திய தகவல்கள்
• அது அழைத்த கருவிகள்
• அதன் நடத்தையை நிர்வகிக்கும் விதிகளை அது பின்பற்றியதா

பொதுவான AI ஏஜென்ட் மதிப்பீட்டு அளவீடுகள்

Evals பண்புசார் மற்றும் அளவுசார் தரவுகளைக் கொண்டு செயல்படுகின்றன. பண்புசார் மதிப்பீடு, ஏஜென்ட்டின் முடிவுகளைக் கைமுறையாக மதிப்பாய்வு செய்வது உட்பட, என்ன நடக்கிறது, ஏன் நடக்கிறது என்பதைப் புரிந்துகொள்ள உதவுகிறது. அளவுசார் மதிப்பீடு அந்த அவதானிப்புகளை அளவிடக்கூடிய சமிக்ஞைகளாக மாற்றுகிறது; எடுத்துக்காட்டாக, குறிப்பிட்ட தோல்வி முறைகள் எத்தனை முறை நிகழ்கின்றன என்பதைக் கணக்கிடுவது அல்லது பணி வெற்றி விகிதங்களைக் கணக்கிடுவது.

அடிப்படையான AI ஏஜென்ட் மதிப்பீட்டு அளவீடுகளின் பட்டியல் இதோ:

• பணி வெற்றி, ஏஜென்ட் உத்தேசிக்கப்பட்ட விளைவை அடைந்ததா என்பதை அளவிடுகிறது; இது பொதுவாகச் சரியான முடிவுகளைத் தரும் இயக்கங்களின் சதவீதமாக அளவிடப்படுகிறது.
• செயல் துல்லியம், ஏஜென்ட் கருவிகளைப் பொருத்தமாகப் பயன்படுத்தியதா, சரியான ஆர்குமென்ட்களைத் தேர்ந்தெடுத்ததா, அனுமதிகளை மதித்ததா என்பதை அளவிடுகிறது.
• பதில் தரம், இறுதி வெளியீடு துல்லியமானதா, முழுமையானதா, பயனுள்ளதா என்பதை மதிப்பிடுகிறது. உண்மைத் துல்லியம், அறிவுறுத்தல்களைப் பின்பற்றுதல், கிடைக்கும் தகவல்களைக் கொண்டு ஏஜென்ட் தனது முடிவுகளை நியாயப்படுத்துகிறதா என்பவை இதில் அடங்கலாம்.
• நம்பகத்தன்மை, மீண்டும் மீண்டும் செய்யப்படும் சோதனைகள், மாறுபடும் உள்ளீடுகள், விளிம்பு நிலைகள் (edge cases) ஆகியவற்றில் நிலைத்தன்மையை அளவிடுகிறது.
• செலவும் தாமதமும், செயல்படுத்தும் நேரம், டோக்கன் நுகர்வு, கருவி அழைப்புகள் உட்பட, வெற்றிகரமான முடிவை அடையத் தேவையான வளங்களை அளவிடுகின்றன.

நீங்கள் எதை அளவிடுகிறீர்கள் என்பதைப் பொறுத்து, evals ஒரு ஏஜென்ட்டின் தொடக்கம் முதல் இறுதி வரையிலான செயல்திறனையோ, அதன் செயல்படுத்தல் பாதையையோ (trajectory), அல்லது கருவி அழைப்புகள், தகவல் மீட்டெடுப்புப் படிகள் போன்ற தனிப்பட்ட கூறுகளையோ மதிப்பிடலாம்.

படி 1: வெற்றிகரமான ஏஜென்ட் இயக்கம் எப்படி இருக்கும் என்பதைத் தீர்மானியுங்கள்

முதலில், ஏஜென்ட் எதைச் சாதிக்க வேண்டும் என்பதை — அதாவது தயாரிப்புத் தேவைகளை — தெளிவாக விவரியுங்கள். இது வெளிப்படையானதாகத் தோன்றலாம், ஆனால் வியக்கத்தக்க அளவுக்குக் கடினமாக இருக்கலாம். இதற்கு ஒரு பெயரே உண்டு: விவரக்குறிப்பு இடைவெளி (specification gap).

எங்கள் மூத்த தரவு விஞ்ஞானி Andrey Khomutov அவர்களின் கூற்றுப்படி, இதை அணுக வேண்டிய விதம் இதோ:

“இரண்டு கேள்விகளுடன் தொடங்குங்கள்: “எதைச் செய்தால் பணியைச் செய்ததாகக் கருதலாம்?” மற்றும் “வெற்றிகரமானதாகத் தோன்றும் ஓர் இயக்கத்தை எது ஏற்றுக்கொள்ள முடியாததாக்கும்?”

ஏஜென்ட்களைப் பொறுத்தவரை, தொழில்நுட்பக் கண்ணோட்டத்தில், முடிவையும், ஏஜென்ட்கள் அந்த முடிவை எப்படி அடைந்தன என்பதையும் சரிபார்க்க வேண்டும் என்பதே இதன் பொருள்.”

கசிந்த விடைக்குறிப்பை அணுகுவதன் மூலம் ஒரு ஏஜென்ட் சரியான பதிலைத் தரக்கூடும், அல்லது தனது பணியை நிறைவுசெய்யும்போது அங்கீகரிக்கப்படாத செயல்களை மேற்கொள்ளக்கூடும். பதில் கசிவு மற்றும் மதிப்பீடுகளின்போது நிகழும் பாதுகாப்பற்ற செயல்கள் ஆகியவை, இறுதிப் பதிலை மட்டும் வைத்து மதிப்பிடக்கூடாது என்பதற்கான உறுதியான காரணங்கள் என்று Khomutov சுட்டிக்காட்டுகிறார்.

“ஒரு முடிவு சந்தேகத்திற்குரியதாகத் தோன்றும்போது மட்டும் செய்யும் ஒன்றாக இல்லாமல், பாதை ஆய்வு (trajectory inspection) ஏஜென்ட் eval தொகுப்புகளின் வழக்கமான பகுதியாக மாறும் என்று எதிர்பார்க்கிறேன்,” என்று அவர் கூறுகிறார்.

பின்னர், உங்கள் வெற்றி அளவுகோல்களைச் சரிபார்க்க ஒரு துறை நிபுணரை ஈடுபடுத்துங்கள். அந்தத் துறையில் நேரடி அனுபவ அறிவுள்ளவர்களால், AI ஏஜென்ட்டுக்கு நாம் நிர்ணயிக்கும் நிபந்தனைகள் வெற்றிகரமான விளைவைப் பிரதிபலிக்கின்றனவா என்பதைச் சொல்ல முடியும்.

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

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

Parlance Lab-இன் ML பொறியாளர் Hamel Husain, ML அமைப்புகள் மற்றும் பயன்பாட்டு AI evals ஆய்வாளர் Shreya Shankar ஆகியோர் பரிந்துரைப்பது, இயந்திரக் கற்றல் மற்றும் தரவு அறிவியலிலிருந்து பெறப்பட்ட உத்தியான பிழைப் பகுப்பாய்வுடன் (error analysis) தொடங்குவதையே. இந்தச் செயல்முறை, ஏஜென்ட்டின் செயல்படுத்தல் தடயங்கள் (execution traces) — அதாவது பயனரின் உள்ளீடு, கருவி அழைப்புகள், மீட்டெடுக்கப்பட்ட தகவல்கள், ஏஜென்ட்டின் வெளியீடு ஆகியவற்றைக் காட்டும் பதிவுகள் — பற்றிய பண்புசார் பகுப்பாய்வுடன் தொடங்குகிறது.

1. தனிப்பட்ட தடயங்களை மதிப்பாய்வு செய்து பிழைகளைக் குறித்துவையுங்கள் (திறந்த குறியீட்டு முறை — open coding). ஒரு துறை நிபுணரைக் கொண்டு ஏஜென்ட் இயக்கங்களை ஆய்வுசெய்து, என்ன தவறு நடந்தது என்பது குறித்துச் சுருக்கமான அவதானிப்புகளை எழுதச் செய்யுங்கள். முதல் அர்த்தமுள்ள பிழையில் கவனம் செலுத்துங்கள்.
2. அவதானிப்புகளைத் தோல்வி முறைகளாகக் குழுவாக்குங்கள் (அச்சுக் குறியீட்டு முறை — axial coding). போதுமான குறிப்புகள் கிடைத்ததும், ஒரே மாதிரியான பிழைகளுக்கு வகைகளைப் பரிந்துரைக்க ஒரு LLM-ஐப் பயன்படுத்துங்கள். பொருந்தாத பாகப் பரிந்துரைகள், துல்லியமற்ற இருப்புத் தகவல் மீட்டெடுப்பு, தோல்வியடைந்த மனிதக் கைமாற்றங்கள் ஆகியவை இவற்றில் அடங்கலாம்.
3. நிகழ்வுகளை எண்ணுங்கள். ஒவ்வொரு அவதானிப்பையும் ஒரு வகைக்கு ஒதுக்கி, பின்னர் ஒவ்வொரு தோல்வி முறையும் எத்தனை முறை தோன்றுகிறது என்பதைக் கணக்கிட ஸ்ப்ரெட்ஷீட் அல்லது பிவட் டேபிளைப் பயன்படுத்துங்கள்.
4. எதைச் சரிசெய்வது என்பதற்கு முன்னுரிமை அளியுங்கள்; அடிக்கடி நிகழ்வது, தீவிரம் ஆகிய இரண்டையும் கருத்தில் கொள்ளுங்கள்.
5. முக்கியமான தோல்விகளைச் சோதனை நிகழ்வுகளாக மாற்றுங்கள். அதே சூழ்நிலையில் ஏஜென்ட்டை மீண்டும் சோதிக்க ஏதுவாக, தொடர்புடைய உள்ளீடு, தொடக்க நிலைமைகள், எதிர்பார்க்கப்படும் விளைவு, மதிப்பெண் அளவுகோல்கள் ஆகியவற்றைச் சேமியுங்கள்.

எத்தனை தடயங்களை ஆராய வேண்டும்? தோராயமாக 100, ஆனால் மாய எண் என்று எதுவும் இல்லை. கோட்பாட்டு நிறைவுநிலையை (theoretical saturation) அடைந்தவுடன் முன்கூட்டியே நிறுத்துங்கள்: அதாவது, கூடுதல் தடயங்களை மதிப்பாய்வு செய்வதால் அர்த்தமுள்ள புதிய தோல்வி வடிவங்கள் எதுவும் வெளிப்படாத நிலை.

இன்னும் பயன்பாட்டை வெளியிடவில்லையா? ஆரம்பச் சோதனைத் தொகுப்பை உருவாக்க செயற்கை எடுத்துக்காட்டுகள் உதவலாம்; இருப்பினும், உண்மையான பயனர் தரவு கிடைத்தவுடனேயே அதைக் கொண்டு சோதனைத் தொகுப்பை வடிவமைக்க வேண்டும்.

AI ஏஜென்ட் மதிப்பீட்டில் பெஞ்ச்மார்க்குகளின் பயன்பாடு

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

ஆனால் பெஞ்ச்மார்க்குகள் பிழையற்றவை அல்ல. SWE-bench தணிக்கைகள், Epoch AI-இன் பெஞ்ச்மார்க் மதிப்பாய்வுகள், TheoPhysEval-இல் ஆரம்பத்தில் நிராகரிக்கப்பட்ட சரியான பதில்கள் ஆகியவை, குறைபாடுள்ள பணிகள் அல்லது எதிர்பார்க்கப்படும் பதில்கள் மதிப்பீட்டு முடிவுகளை எவ்வாறு திரிக்கக்கூடும் என்பதை விளக்குகின்றன.

Khomutov அறிவுறுத்துவது போல, உங்கள் துறைக்குத் தொடர்புடைய சமீபத்திய பெஞ்ச்மார்க்குகளைத் தேர்ந்தெடுங்கள்; மதிப்பெண்களை ஏஜென்ட் செயல்திறனுக்கான நம்பகமான சான்றாகக் கருதுவதற்கு முன், எதிர்பாராத வெற்றிகளையோ தோல்விகளையோ ஆராயுங்கள்.

படி 3. மீண்டும் செய்யக்கூடிய சோதனைச் சூழலில் ஏஜென்ட்டை இயக்குங்கள்

மீண்டும் செய்யக்கூடிய சோதனைச் சூழல் என்பது, ஒரே தொடக்க நிலைமைகளின் கீழ் ஒரே சோதனை நிகழ்வுகளைக் கொண்டு ஒரு AI ஏஜென்ட்டை இயக்கி, முடிவுகளை ஒப்பிடக்கூடிய கட்டுப்படுத்தப்பட்ட அமைப்பாகும். சோதனை நிகழ்வுகள் அடங்கிய ஒரு கோப்புறை, ஏஜென்ட்டை இயக்கும் ஒரு Python ஸ்கிரிப்ட், அல்லது முடிவுகளை மதிப்பிடும் சரிபார்ப்புகளின் தொகுப்பு ஆகியவை இதில் அடங்கும்.

பிரதிநிதித்துவ உள்ளீடுகளை JSON கோப்புகளாகச் சேமித்து, உங்கள் ஏஜென்ட்டின் பணிப்பாய்வைச் செயல்படுத்தவும், assertions மூலம் அதன் வெளியீடுகளைச் சரிபார்க்கவும் ஒரு Python ஸ்கிரிப்டைப் பயன்படுத்துவதன் மூலம் நீங்கள் தொடங்கலாம். நமது உற்பத்தி ஆலையின் இருப்பு ஏஜென்ட்டுக்கு, மீண்டும் செய்யக்கூடிய சோதனைச் சூழல் இப்படி இருக்கலாம்:

விரிவாக்கு

மீண்டும் செய்யக்கூடிய சோதனைச் சூழலை அமைக்க, இந்தப் படிகளைப் பின்பற்றுங்கள்:

1. பிரதிநிதித்துவ உள்ளீடுகளைச் சேமியுங்கள். உண்மையான நிகழ்வுகளையோ சோதனை நிகழ்வுகளையோ, உங்கள் பயன்பாடு புரொடக்‌ஷனில் பெறும் அதே கட்டமைப்பில் சேமியுங்கள். நமது சூழ்நிலையில், இயந்திர ID, தேவையான உதிரிபாகம், பராமரிப்புத் தேதி ஆகியவற்றைக் கொண்ட பராமரிப்புக் கோரிக்கையை, இருப்பு மற்றும் அங்கீகரிக்கப்பட்ட பாகங்கள் தரவின் ஸ்னாப்ஷாட்டுடன் சேர்த்து ஒரு JSON கோப்பாகச் சேமிப்பீர்கள்.
2. பணிப்பாய்வைச் செயல்படுத்துங்கள். ஒவ்வொரு உள்ளீட்டையும், அதன் தகவல் மீட்டெடுப்புப் படிகள், கருவி அழைப்புகள், பதில் உருவாக்கம் உட்பட, ஏஜென்ட் வழியாக இயக்குங்கள்.
3. முடிவையும் தடயத்தையும் பதிவுசெய்யுங்கள். ஏஜென்ட் தோல்வியடைந்ததா என்பதை மட்டுமின்றி, எங்கே தோல்வியடைந்தது என்பதையும் காண, இறுதி வெளியீட்டையும் தொடர்புடைய இடைநிலைச் செயல்களையும் (இருப்புத் தேடல்கள் போன்றவை) பதிவுசெய்யுங்கள்.
4. தோல்வியின் தீவிரம், அது அடிக்கடி நிகழ்வது, சிக்கலைச் சரிசெய்வதில் உள்ள சிரமம் ஆகியவற்றின் அடிப்படையில் நிகழ்வுகளை மீண்டும் இயக்குங்கள். LLM பயன்பாடுகள் நிர்ணயமற்றவை (ஒரே மாதிரியான உள்ளீடுகளிலிருந்து வெவ்வேறு முடிவுகளைத் தரக்கூடியவை); எனவே, ஓர் இயக்கம் வெற்றிகரமாக அமைந்தாலும், அடுத்ததும் வெற்றிபெறும் என்பதற்கு உத்தரவாதம் இல்லை. வெற்றிகரமான சோதனை முயற்சிகளின் விகிதத்தைப் பதிவுசெய்து, தோல்விகளை ஆய்வுசெய்யுங்கள்.

பிந்தையதற்கு, pass@1 (ஒரே முயற்சியில் ஏஜென்ட் எவ்வளவு அடிக்கடி வெற்றிபெறுகிறது) மற்றும் pass@k (குறிப்பிட்ட எண்ணிக்கையிலான முயற்சிகளில் குறைந்தது ஒரு முறையாவது வெற்றிபெறுவதற்கான நிகழ்தகவு) ஆகியவற்றை அளவிடுமாறு Khomutov அறிவுறுத்துகிறார். pass@k பதிவுசெய்யும்போது, முயற்சிகளின் எண்ணிக்கையைக் குறிப்பிடுங்கள்; ஏனெனில், பல பதில்களில் ஒன்று சரியாக இருப்பதால், அவற்றில் எதைத் தேர்ந்தெடுக்க வேண்டும் என்பது ஏஜென்ட்டுக்குத் தெரியும் என்று அர்த்தமில்லை.

உங்கள் பயன்பாடு வளரும்போது, சோதனைகளை ஒழுங்கமைத்து இயக்க pytest போன்ற சோதனைக் கட்டமைப்பைப் பயன்படுத்துங்கள்; பெரிய சோதனைத் தரவுத்தொகுப்புகளையும் முடிவுகளையும் ஒரு தரவுத்தளத்தில் சேமிப்பதையும் கருத்தில் கொள்ளுங்கள்.

படி 4. ஒவ்வொரு சரிபார்ப்புக்கும் சரியான கிரேடரைத் தேர்ந்தெடுங்கள்

கிரேடர் (பெரும்பாலும் மதிப்பீட்டாளர் (evaluator) என்றும் அழைக்கப்படுகிறது) என்பது, ஒரு ஏஜென்ட்டின் வெளியீட்டையோ செயலையோ வரையறுக்கப்பட்ட அளவுகோலுடன் ஒப்பிட்டுச் சரிபார்க்கும் ஒரு வழிமுறை; இது ஒரு குறியீட்டுப் பகுதியாகவோ, மதிப்பெண் வழிகாட்டியால் (grading rubric) வழிநடத்தப்படும் LLM ஆகவோ, அல்லது ஒரு மனித மதிப்பாய்வாளராகவோ இருக்கலாம். கிரேடர் ஒரு தேர்ச்சி/தோல்வித் தீர்ப்பையும், தொடர்புடைய சான்றுகளை அடையாளம் காட்டும் விளக்கத்தையும் வழங்குகிறது.

தகவல்: மதிப்பெண் வழிகாட்டி (grading rubric) என்பது, சரியான அல்லது ஏற்கத்தக்க முடிவாக எது கருதப்படும் என்பதை வரையறுக்கும் அளவுகோல்கள் மற்றும் அறிவுறுத்தல்களின் தொகுப்பாகும்.

சரியான கிரேடர் வகை, நீங்கள் எதைச் சரிபார்க்க முயல்கிறீர்கள் என்பதைப் பொறுத்தது. இந்த மூன்று அணுகுமுறைகளும் ஒன்றோடொன்று எவ்வாறு ஒப்பிடப்படுகின்றன என்பது இதோ:

சில நேரங்களில், ஒரே இயக்கத்தின் வெவ்வேறு அம்சங்களுக்கு வெவ்வேறு மதிப்பீட்டு முறைகள் தேவைப்படலாம்; எனவே, நீங்கள் கிரேடர்களை இணைத்துப் பயன்படுத்த வேண்டியிருக்கலாம்.

கிரேடர்களை எவ்வாறு இணைப்பது?

நீங்கள் கேட்க வேண்டியது: “அறியப்பட்ட ஒரு விதி அல்லது எதிர்பார்க்கப்படும் மதிப்புடன் ஒப்பிட்டு முடிவைச் சரிபார்க்க முடியுமா, அல்லது அதற்கு மனிதனைப் போன்ற தீர்ப்புத்திறன் தேவையா?”

• முடிவைத் துல்லியமாகச் சரிபார்க்க முடிந்தால், குறியீடு அடிப்படையிலான கிரேடருடன் தொடங்குங்கள். குறியீடு அடிப்படையிலான கிரேடர்கள், கட்டமைக்கப்பட்ட வெளியீடுகள், சரியான புல மதிப்புகள், கருவி ஆர்குமென்ட்கள், அல்லது ஒரு தரவுத்தளத்தின் இறுதி நிலை ஆகியவற்றையும் சரிபார்க்க முடியும்.
• சரிபார்ப்புக்குச் சூழலைப் புரிந்து விளக்குவது தேவைப்பட்டால், LLM-as-a-judge முறையைப் பயன்படுத்துங்கள்.
• துறை சார்ந்த அல்லது சர்ச்சைக்குரிய முடிவுகளுக்கு மனித மதிப்பாய்வாளர்களைப் பயன்படுத்துங்கள்.

முக்கியம்! ஒரு LLM கிரேடர் சான்றுகளைத் தவறாகப் புரிந்துகொள்ளலாம் அல்லது மதிப்பெண் வழிகாட்டியைத் தவறாகப் பயன்படுத்தலாம். எனவே, அதற்குக் கூடுதல் மதிப்பீட்டுப் படி ஒன்று தேவை: மனிதத் தீர்ப்புகளுடன் ஒப்பிட்டு அளவுத்திருத்தம் (calibration) செய்தல்.

மனிதத் தீர்ப்புகளுடன் ஒப்பிட்டு LLM கிரேடரை அளவுத்திருத்தம் செய்யுங்கள்.

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

ஐந்து படிகளைக் கொண்ட கிரேடர் அளவுத்திருத்தச் செயல்முறை இதோ:

1. ஏஜென்ட் உள்ளீடுகள், வெளியீடுகள், தொடர்புடைய தடயங்கள் ஆகியவற்றின் எடுத்துக்காட்டுகளைச் சேகரியுங்கள்.
2. ஒவ்வொரு எடுத்துக்காட்டும் மதிப்பீட்டு அளவுகோலைப் பூர்த்திசெய்கிறதா என்பதை ஒரு துறை நிபுணரைக் கொண்டு தனித்தனியாக மதிப்பிடச் செய்யுங்கள்.
3. அந்த எடுத்துக்காட்டுகளில் LLM கிரேடரை இயக்குங்கள்.
4. மனிதத் தீர்ப்புகளையும் மாடலின் தீர்ப்புகளையும் ஒப்பிடுங்கள்.
5. கருத்து வேறுபாடுகளை ஆராய்ந்து, புதிய எடுத்துக்காட்டுகளில் சோதிப்பதற்கு முன் கிரேடரின் மதிப்பெண் வழிகாட்டியைச் செம்மைப்படுத்துங்கள்.

LLM கிரேடரின் நிலைத்தன்மையைத் தனியாகச் சோதிப்பதன் முக்கியத்துவத்தையும் Khomutov வலியுறுத்துகிறார்:

“ஏஜென்ட்டை மீண்டும் இயக்காமல், சேமிக்கப்பட்ட அதே இயக்கத்தையும் கோப்புகளையும் பல முறை அதற்கு வழங்குங்கள். இதன் மூலம், ஏஜென்ட்டின் பணியில் உள்ள மாறுபாட்டையும் மதிப்பெண் வழங்குதலில் உள்ள மாறுபாட்டையும் தனித்தனியாகப் பிரித்தறியலாம்.”

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

குறிப்புத் தீர்ப்புகளை நிறுவுவதற்கும், சர்ச்சைக்குரிய நிகழ்வுகளைத் தீர்ப்பதற்கும், தற்போதைய கிரேடர்கள் கண்டறியும் வகையில் வடிவமைக்கப்படாத புதிய தோல்வி முறைகளைக் கண்டுபிடிப்பதற்கும் மனித மதிப்பாய்வு இன்றியமையாததாகவே உள்ளது.

படி 5. பதிப்புகளை ஒப்பிட்டு, ரிக்ரெஷன் சரிபார்ப்புகளை இயக்குங்கள்

உங்கள் இருப்பு ஏஜென்ட் அடிக்கடி அங்கீகரிக்கப்படாத மாற்றுப் பாகங்களைப் பரிந்துரைப்பதாகப் பிழைப் பகுப்பாய்வு வெளிப்படுத்துகிறது என்று வைத்துக்கொள்வோம். வெளிப்படையான இணக்கத்தன்மைச் சரிபார்ப்பைக் கட்டாயமாக்கும் வகையில் அதன் சிஸ்டம் ப்ராம்ப்ட்டை மாற்றுகிறீர்கள். முன்பு தோல்வியடைந்த நிகழ்வு இப்போது தேர்ச்சி பெறுகிறது. ஆனால், அந்த மாற்றம் பிற பணிகளைப் பாதிக்கவில்லை என்பதை எப்படி அறிவீர்கள்?

இங்குதான் ரிக்ரெஷன் சோதனை கைகொடுக்கிறது.

ரிக்ரெஷன் சோதனை என்பது, ஒரு ஏஜென்ட்டின் ப்ராம்ப்ட், மாடல் அல்லது பணிப்பாய்வை மாற்றிய பிறகு, அந்த மாற்றம் புதிய தோல்விகளை உருவாக்கவில்லை என்பதை உறுதிசெய்ய, முன்பு வெற்றிகரமாக இருந்த சோதனை நிகழ்வுகளை மீண்டும் இயக்குவதாகும்.

1. சோதனைத் தொகுப்பிலிருந்து சேமிக்கப்பட்ட உள்ளீட்டைப் பயன்படுத்தி அசல் தோல்வியை மீண்டும் உருவாக்குங்கள்.
2. ப்ராம்ப்ட், மாடல் அல்லது பணிப்பாய்வில் இலக்கு சார்ந்த மாற்றத்தைச் செய்யுங்கள்.
3. சிக்கல் தீர்ந்துவிட்டதா என்பதைச் சரிபார்க்க தோல்வியடைந்த சோதனையை மீண்டும் இயக்குங்கள்.
4. மாற்றம், முன்பு வெற்றிகரமாக இயங்கிய நடத்தையைச் சீர்குலைக்கவில்லை என்பதை உறுதிப்படுத்த, மற்ற சோதனைகளை இயக்கவும்.
5. முடிவுகளை ஆய்வு செய்யவும், புதிய தோல்விகள் ஏதேனும் இருந்தால் அவற்றை ஆராயவும்.

துல்லியமான முடிவுகளுக்கு, அடிப்படை ஏஜென்டையும் புதுப்பிக்கப்பட்ட ஏஜென்டையும் ஒரே சோதனை நிகழ்வுகள் மற்றும் மதிப்பீட்டு அளவுகோல்களைக் கொண்டு ஒப்பிடவும்.

படி 6: உற்பத்திச் சூழலில் AI ஏஜென்டின் செயல்திறனைக் கண்காணிக்கவும்

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

இது ஆன்லைன் மதிப்பீடு என அழைக்கப்படுகிறது; மீண்டும் மீண்டும் நிகழும் தோல்விகளையும் இதுவரை அறியப்படாத தோல்விகளையும் கண்டறிய உதவும் விரிவான உற்பத்திக் கண்காணிப்புச் செயல்முறையின் ஒரு பகுதி இது.

இது மீண்டும் மீண்டும் செம்மைப்படுத்தப்படும் (iterative) ஒரு செயல்முறை; ஒன்றுக்கொன்று துணைபுரியும் நான்கு செயல்பாடுகளை இது உள்ளடக்கியது:

• உற்பத்தி ட்ரேஸ்களில் அளவுத்திருத்தம் செய்யப்பட்ட LLM நடுவர்களை இயக்கவும். உண்மையான ஏஜென்ட் தொடர்புகளை மாதிரியாக எடுத்து, மனிதத் தீர்ப்புகளுடன் நீங்கள் ஏற்கனவே சரிபார்த்த மதிப்பீட்டாளர்களைப் பயன்படுத்தவும்.
• காலப்போக்கில் தோல்வி விகிதங்களைக் கண்காணிக்கவும். மீண்டும் மீண்டும் நிகழும் சிக்கல்களை அளவிட, பிழை பகுப்பாய்வின்போது வரையறுக்கப்பட்ட தோல்வி வகைகளைப் பயன்படுத்தவும்.
• ட்ரேஸ்களைத் தொடர்ந்து கைமுறையாக மதிப்பாய்வு செய்யவும். தானியங்கு மதிப்பீட்டாளர்கள், எந்தச் சிக்கல்களைக் கண்டறிய வடிவமைக்கப்பட்டுள்ளனவோ அவற்றை மட்டுமே கண்டறியும். புதிய பிழைகளையோ வழக்கத்துக்கு மாறான பயனர் கோரிக்கைகளையோ கண்டறிய, உண்மையான ஏஜென்ட் தொடர்புகளின் மாதிரிகளைக் கைமுறையாக ஆய்வு செய்யவும்.
• வணிக விளைவுகளை அளவிட A/B சோதனையைப் பயன்படுத்தவும் (பொருத்தமான சூழல்களில் மட்டும்). பணி நிறைவு, பயனர் திருப்தி, தீர்வுக்கான நேரம் போன்ற அளவீடுகளைக் கொண்டு வெவ்வேறு ப்ராம்ப்ட்கள், மாடல்கள் அல்லது பணிப்பாய்வுகளை ஒப்பிடவும். தனிப்பட்ட சோதனைகளில் தேர்ச்சி பெறுவதைத் தாண்டி, ஒரு மாற்றம் உண்மையான தயாரிப்பு அனுபவத்தை மேம்படுத்துகிறதா என்பதைத் தீர்மானிக்க இந்தச் செயல்முறை உதவுகிறது.

ஒரு முக்கியக் குறிப்பு: மதிப்பீடுகள் கச்சிதமாகச் செம்மைப்படுத்தப்பட்டிருக்க வேண்டியதில்லை. உங்கள் தயாரிப்பை மேம்படுத்தும் அளவுக்குப் போதுமான தரத்தில் இருந்தாலே போதும்.

AI ஏஜென்ட் மதிப்பீட்டில் உள்ள பொதுவான தவறான கருத்துகள்

• மதிப்பீடுகள் வெறும் யூனிட் சோதனைகள் மட்டுமே. அப்படியல்ல; யூனிட் சோதனைகள் சிறிய, தானியங்கு சரிபார்ப்புகள், அவை மதிப்பீட்டின் ஒரு பகுதி மட்டுமே. பயன்பாட்டின் தரத்தை அளவிட, பண்புசார் பிழை பகுப்பாய்வு, மனிதத் தீர்ப்புகள், உற்பத்திக் கண்காணிப்பு, பரிசோதனைகள் ஆகியவையும் மதிப்பீடுகளில் அடங்கும்.
• ஒரு மதிப்பீட்டுத் தளம் உங்களுக்காக எல்லாவற்றையும் செய்துவிடும். ஆயத்தக் கருவிகள் சில சரிபார்ப்புகளைத் தானியக்கமாக்கலாம், ஆனால் உங்கள் தயாரிப்புக்கு எந்தத் தோல்வி முறைகள் (பிழை வகைகள் அல்லது விரும்பத்தகாத ஏஜென்ட் நடத்தைகள்) முக்கியம் என்பதை அவற்றால் தீர்மானிக்க முடியாது.
• எல்லாவற்றையும் ஒரு LLM மதிப்பிட அனுமதிக்கலாம். இது ஒரு பெரிய தவறான நம்பிக்கை. ஒவ்வொரு சிக்கலையும் கண்டறியத் தேவையான வணிகச் சூழல் LLM-களிடம் இல்லாததால், மனிதர் தலைமையிலான பிழை பகுப்பாய்வும் மதிப்பீட்டாளர் அளவுத்திருத்தமும் இன்றியமையாதவையாகவே உள்ளன.
• A/B சோதனையோ ஏஜென்டை வெறுமனே பயன்படுத்துவதோ மதிப்பீடுகளுக்கு மாற்றாகும். இது தவறு. தேர்ந்தெடுக்கப்பட்ட அளவீடுகளின் அடிப்படையில் எந்தப் பதிப்பு சிறப்பாகச் செயல்படுகிறது என்பதை A/B சோதனைகள் காட்டலாம், ஆனால் அடிப்படைச் சிக்கல்களை அவற்றால் மட்டும் விளக்க முடியாது.

AI ஏஜென்ட் மதிப்பீடு: அடிக்கடி கேட்கப்படும் கேள்விகள்

1. AI ஏஜென்ட் மதிப்பீட்டுக்கும் LLM மதிப்பீட்டுக்கும் உள்ள வேறுபாடு என்ன?

LLM மதிப்பீடு, கேள்விக்குப் பதிலளித்தல், ஆவணத்தைச் சுருக்குதல் அல்லது தகவலைப் பிரித்தெடுத்தல் போன்ற ஒரு குறிப்பிட்ட பணியை ஒரு மொழி மாடல் எவ்வளவு சிறப்பாகச் செய்கிறது என்பதை அளவிடுகிறது. AI ஏஜென்ட் மதிப்பீடு, ஒரு பணியை முடிக்கப் பல படிகளைத் தானாகவே செயல்படுத்தும் ஓர் அமைப்பை மதிப்பிடுகிறது.

வழக்கமான LLM மதிப்பீட்டைப் போலன்றி, ஏஜென்ட் மதிப்பீடு இறுதி விளைவையும், அதை அடைய மேற்கொள்ளப்பட்ட செயல்களின் வரிசையையும் ஆராய்கிறது; இதில் கருவி அழைப்புகள், எடுக்கப்பட்ட தீர்மானங்கள், முன்வரையறுக்கப்பட்ட விதிகளுக்கு இணங்குதல் ஆகியவை அடங்கும்.

2. AI ஏஜென்ட் மதிப்பீட்டுக்கான முக்கிய அளவீடுகள்

AI ஏஜென்ட் மதிப்பீட்டு அளவீடுகள் இரண்டு பரந்த வகைகளில் அடங்கும்:

• தொழில்நுட்பச் செயல்திறன் அளவீடுகள்: பணி வெற்றி விகிதம், செயல்களின் சரியான தன்மை, பதிலின் தரம், நம்பகத்தன்மை (pass@1 மற்றும் pass@k), தாமதம் (latency), டோக்கன் பயன்பாடு, வெற்றிகரமான ஒவ்வொரு பணிக்குமான செலவு.
• வணிக மற்றும் பயனர் அனுபவ அளவீடுகள்: வாடிக்கையாளர் திருப்தி (CSAT), சிக்கல் தீர்வு விகிதம், உயர்நிலைக்கு அனுப்பும் விகிதம் (escalation rate), மாற்று விகிதம் (conversion rate), பணி நிறைவு நேரம், ஏஜென்டின் பங்குக்கே உரிய பிற விளைவுகள்.

எடுத்துக்காட்டாக, ஒரு வாடிக்கையாளர் ஆதரவு ஏஜென்ட், சிக்கல்களை வெற்றிகரமாகத் தீர்த்தல் மற்றும் வாடிக்கையாளர் திருப்தி அடிப்படையில் மதிப்பிடப்படலாம்; அதே நேரத்தில் ஒரு AI கொள்முதல் ஏஜென்ட், மறுநிரப்புக் கோரிக்கைகளின் துல்லியம், ஒப்புதல் விகிதங்கள், கொள்முதல் சுழற்சி நேரம் ஆகியவற்றின் அடிப்படையில் அளவிடப்படலாம்.

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

3. AI ஏஜென்ட்களை மதிப்பிடுவதற்கான சிறந்த கருவிகள் யாவை?

பொதுவான தேர்வுகள் பின்வருமாறு:

• சோதனைக் கட்டமைப்புகள்: Python assertion-களும் pytest-உம், மீண்டும் இயக்கக்கூடிய சோதனை நிகழ்வுகளை இயக்கவும், ஏஜென்ட் சரியான கருவியைத் தேர்ந்தெடுத்ததா அல்லது செல்லுபடியான பாக ID-ஐ வழங்கியதா போன்ற துல்லியமான நிபந்தனைகளைச் சரிபார்க்கவும் பயனுள்ளவை.
• AI ஏஜென்ட் மதிப்பீட்டுக் கட்டமைப்புகள்: DeepEval மற்றும் Google-இன் agent-eval கருவித்தொகுப்பு ஆகியவை செயலாக்க ட்ரேஸ்கள், LLM அடிப்படையிலான மதிப்பீட்டாளர்கள், தானியங்கு பின்னடைவுச் சோதனை உள்ளிட்ட மேலும் சிக்கலான மதிப்பீடுகளை ஆதரிக்கின்றன.
• மதிப்பீடு மற்றும் கண்காணிப்புத்திறன் (observability) தளங்கள்: LangSmith, Arize Phoenix, MLflow ஆகியவை ஏஜென்ட் நடத்தையை ஆய்வு செய்யவும், மதிப்பீட்டுத் தரவுத்தொகுப்புகளை நிர்வகிக்கவும், ஏஜென்ட் பதிப்புகளை ஒப்பிடவும், உற்பத்திச் சூழலில் செயல்திறனைக் கண்காணிக்கவும் குழுக்களுக்கு உதவுகின்றன.

4. AI ஏஜென்ட் மதிப்பீடுகளை எவ்வாறு தானியக்கமாக்குவது?

மீண்டும் இயக்கக்கூடிய சோதனைகளை உருவாக்கி, தானியங்கு மதிப்பீட்டாளர்களைப் பயன்படுத்தி, அந்தச் சரிபார்ப்புகளை மேம்பாட்டு மற்றும் உற்பத்திப் பணிப்பாய்வுகளில் ஒருங்கிணைப்பதன் மூலம் AI ஏஜென்ட் மதிப்பீடுகளைத் தானியக்கமாக்கலாம்:

1. மதிப்பீட்டுத் தரவுத்தொகுப்பை உருவாக்கவும்: பிரதிநிதித்துவமான பயனர் பணிகள், எதிர்பார்க்கப்படும் விளைவுகள், அறியப்பட்ட தோல்விகள், ஏஜென்ட் செயலாக்க ட்ரேஸ்கள் ஆகியவற்றைச் சேகரிக்கவும். தோல்வியடைந்த கருவி அழைப்புகள், விடுபட்ட தகவல்கள், அங்கீகரிக்கப்படாத செயல்கள் போன்ற விளிம்பு நிலைகளையும் (edge cases) சேர்க்கவும்.
2. சோதனைச் செயலாக்கத்தையும் மதிப்பீட்டையும் தானியக்கமாக்கவும்: சோதனை நிகழ்வுகளை இயக்கி, குறியீடு அடிப்படையிலான சரிபார்ப்புகளையோ LLM மதிப்பீட்டாளர்களையோ செயல்படுத்த, pytest அல்லது DeepEval போன்ற கட்டமைப்புகளைப் பயன்படுத்தவும். LLM மதிப்பீட்டாளர்களின் மதிப்பெண்களை நம்புவதற்கு முன், அவற்றை மனிதத் தீர்ப்புகளுடன் ஒப்பிட்டுச் சரிபார்க்கவும்.
3. CI/CD-இல் மதிப்பீடுகளை ஒருங்கிணைக்கவும்: டெவலப்பர்கள் ஒரு ஏஜென்டின் ப்ராம்ப்ட்கள், மாடல்கள், கருவிகள் அல்லது பணிப்பாய்வைப் புதுப்பிக்கும்போது, பின்னடைவுச் சோதனைகளைத் தானாகவே மீண்டும் இயக்கவும். முடிவுகளை அடிப்படை முடிவுகளுடன் (baseline) ஒப்பிட்டு, முக்கியமான சரிபார்ப்புகள் தோல்வியடையும்போது வெளியீடுகளைத் தடுக்கும் தர வரம்புகளை நிறுவவும்.
4. மாதிரியாக எடுக்கப்பட்ட உற்பத்தி ட்ரேஸ்களுக்கு அளவுத்திருத்தம் செய்யப்பட்ட மதிப்பீட்டாளர்களைப் பயன்படுத்தவும், தோல்வி விகிதங்களையும் பிற செயல்திறன் அளவீடுகளையும் கண்காணிக்கவும், கைமுறை மதிப்பாய்வு மூலம் புதிய பிழைகளை ஆராயவும்.