GitHub Actions மெர்ஜ் கியூவில் (merge queue) எட்டு மாதங்கள் செலவிடுவது, அம்ச ஒப்பீட்டு மேட்ரிக்ஸ்களால் (feature comparison matrices) ஒருபோதும் கற்பிக்க முடியாத ஒன்றை உங்களுக்குக் கற்றுக்கொடுக்கும். ஒரு பிரேம்வொர்க் ஐம்பது அளவீடுகள் (metrics), அழகான டேஷ்போர்டுகள் மற்றும் புகழ்பெற்ற ஆராய்ச்சி ஆய்வகங்களின் மேற்கோள்களை வழங்கலாம். ஆனால், ஒரே மாதிரியான குறியீட்டிற்கு (code) ஒரு "vibe check" மதிப்பெண் 0.72 இலிருந்து 0.68 ஆகக் குறைந்த காரணத்திற்காக அது உங்கள் டெப்ளாய்மென்ட்டை (deploy) தடுத்தால், அது பயனற்றது மட்டுமல்ல, உங்கள் மென்பொருள் வெளியீட்டு வேகத்திற்கு (shipping velocity) ஒரு அச்சுறுத்தலாகவும் மாறிவிடும்.

பெரும்பாலான LLM மதிப்பீட்டுத் தொகுப்புகள் (LLM evaluation roundups) தவறவிடுபடும் வடிகட்டி இதுதான். அவை திறன்களை (capabilities) மட்டுமே கணக்கிடுகின்றன. ஒரு மெர்ஜ் கியூவில் மிக முக்கியமான கேள்வி இதுதான்: "இந்தச் சரிபார்ப்பு ஒவ்வொரு முறையும் இயங்கும்போது துல்லியமாக ஒரே மாதிரியான முடிவைத் தருகிறதா?" என்பதை அவை அரிதாகவே கேட்கின்றன.

சவாலான வேலையைச் செய்வதன் மூலம் நான் இதைக் கற்றுக்கொண்டேன். நான் ஆறு ஓப்பன் சோர்ஸ் LLM மதிப்பீட்டு கட்டமைப்புகளை (open-source LLM eval frameworks) ஒரு உண்மையான CI பைப்லைனுடன் (CI pipeline) இணைத்தேன். அவை எட்டு மாதங்களுக்கு நேரடி புரொடக்ஷன் புல் ரிக்வெஸ்ட்களில் (production pull requests) இயங்கின. அவற்றில் இரண்டு மட்டுமே காவலர்களாக (gatekeepers) தொடர தகுதி பெற்றன. மற்றவை ஆலோசனை டேஷ்போர்டுகளாக (advisory dashboards) மாற்றப்பட்டன, நைட்லி வேலைகளுக்கு (nightly jobs) மாற்றப்பட்டன அல்லது முற்றிலும் நீக்கப்பட்டன. இதிலிருந்து நான் கற்றுக்கொண்ட பாடம் மிகக் கடுமையானது மற்றும் செலவு மிகுந்தது: நீங்கள் மெயின் பிரான்ச்சை (main branch) பாதுகாக்கும்போது, நிகழ்தகவு சார்ந்த தரத்தை விட (probabilistic quality), தீர்மானிக்கப்பட்ட கட்டமைப்பு (deterministic structure) தான் சிறந்தது.

ஒரு மெர்ஜ் கேட்டின் (Merge Gate) உண்மையான வேலை

ஒரு CI கேட் (gate) என்பது ஒரு ஆராய்ச்சி சூழல் அல்ல. அது ஒரு பவுன்சர் (bouncer) போன்றது. ஒரு குறிப்பிட்ட மாற்றத்தைப் பார்த்து 'ஆம்' அல்லது 'இல்லை' என்று பதிலளிப்பதே அதன் முழு நோக்கமாகும். "ஆம், இந்த PR மெயின் பிரான்ச்சில் இணையலாம். இல்லை, இணைய முடியாது." அந்தப் பதில் சில நொடிகளில் கிடைக்க வேண்டும், மிகக் குறைந்த செலவில் இருக்க வேண்டும், மற்றும் ஒருபோதும் பின்னோக்கி மாறக்கூடாது. அமைதியான ஒரு செவ்வாய்க்கிழமையிலும், பரபரப்பான ஒரு வெள்ளிக்கிழமையிலும் ஒரே கமிட்டிற்கு (commit) அதே பைப்லைனை நீங்கள் இயக்கினால், அதன் முடிவு ஒரே மாதிரியாக இருக்க வேண்டும்.

இங்குதான் பெரும்பாலான LLM மதிப்பீட்டு கட்டமைப்புகள் தடுமாறுகின்றன. அவை தரவு விஞ்ஞானிகளால் (data scientists), தரவு விஞ்ஞானிகளுக்காகவே உருவாக்கப்படுகின்றன. அவை நுண்ணறிவு (insight), ஆய்வு (exploration) மற்றும் நுணுக்கமான மதிப்பெண்களுக்காக (nuanced scoring) மேம்படுத்தப்பட்டுள்ளன. ஆனால் ஒரு மெர்ஜ் கியூ என்பது பைனரி முடிவுகள் (binary decisions), வேகம் மற்றும் நிலையற்ற தன்மை இல்லாத தன்மைக்காக (zero flakiness) மேம்படுத்தப்பட வேண்டும். இந்த இரண்டு இலக்குகளும் ஒரு பகுதி மட்டுமே ஒன்றிணைகின்றன.

ஏன் LLM-as-Judge மெர்ஜ் கியூவைச் சிதைக்கிறது

எனது சோதனையில் தோல்வியடைந்த கருவிகள் அனைத்தும் ஒரே மாதிரியான வடிவமைப்புக் குறைவைக் கொண்டிருந்தன: அவை முதன்மை கேட் மெக்கானிசமாக LLM-as-judge அழைப்புகளை (calls) அதிகமாகச் சார்ந்திருந்தன.

ஒரு LLM-as-judge பிராம்ட் (prompt), ஒரு வெளியீட்டை ஒன்று முதல் பத்து வரையிலான அளவில் மதிப்பிடவோ, அல்லது இரண்டு பதில்களில் சிறந்ததைத் தேர்ந்தெடுக்கவோ, அல்லது உண்மைத் தன்மையை மதிப்பிடவோ ஒரு மாடலைத் தூண்டுகிறது. தரமான மாற்றங்களைப் புரிந்துகொள்ள இந்த அணுகுமுறை சக்தி வாய்ந்தது. ஆனால், ஒரு பிளாக்கிங் CI சரிபார்ப்பிற்கு (blocking CI check) இது விஷம் போன்றது. டெம்பரேச்சர் (temperature), மாடல் வெர்ஷனிங் (model versioning) மற்றும் பிராம்ட் பார்மேட்டிங் (prompt formatting) ஆகிய அனைத்தும் இரைச்சலை (noise) ஏற்படுத்துவதால், ஒரே உள்ளீடு வெவ்வேறு நாட்களில் வெவ்வேறு மதிப்பெண்களைத் தரக்கூடும். அந்த மதிப்பெண் ஒரு கடுமையான வரம்புடனும் (hard threshold) மற்றும் எக்சிட் கோட் (exit code) உடன் இணைக்கப்பட்டிருக்கும் போது, உங்கள் மெர்ஜ் கியூ தேவையற்ற காரணங்களால் முடங்கிக் கிடக்கும்.

இந்தத் தோல்விகள் மிக வேகமாகப் பரவும். ஒரு தீர்மானிக்க முடியாத சரிபார்ப்பு (nondeterministic check) மெர்ஜ் கியூவில் தேக்கத்தை ஏற்படுத்தும். பொறியாளர்கள் சாதகமான எண் வரும் வரை மீண்டும் மீண்டும் முயற்சி செய்யப் பழகிக்கொள்வார்கள், இது சிவப்பு நிற பில்டுகளை (red builds) புறக்கணிக்கக் குழுவிற்குப் பழக்கமடையச் செய்யும். ஒவ்வொரு மறுமுயற்சியும் அதிக API கிரெடிட்களைச் செலவிடுவதால் டோக்கன் செலவுகள் (token costs) அதிகரிக்கின்றன. எல்லாவற்றிற்கும் மேலாக, அந்தச் சிக்னல் அர்த்தமற்றதாகிவிடும். ஒரு சிவப்பு நிற பில்டு என்பது "நீங்கள் ஒரு பிழையைச் செய்துள்ளீர்கள்" என்பதைக் குறிக்க வேண்டும். அது "மதிப்பீட்டு மாடல் இன்று சற்றுத் துல்லியமாகச் செயல்படுகிறது" என்பதைக் குறித்தால், அந்தச் சரிபார்ப்பின் மீதான நம்பிக்கை சிதைந்துவிடும்.

உயிர் பிழைத்தவை எதை வித்தியாசமாகச் செய்கின்றன

Promptfoo மற்றும் DeepEval ஆகியவை உயிர் பிழைத்தன, ஏனெனில் அவை தீர்மானிக்கப்பட்ட சரிபார்ப்புகளை (deterministic checks) முதன்மையான அங்கங்களாகவும், LLM judge மதிப்பெண்களைத் தடையற்ற (non-blocking) சிக்னல்களாகவும் கருதுகின்றன. ஒரு கேட்டிற்கு ஒரு எக்சிட் கோட் (exit code) தேவை என்பதை அவை புரிந்துகொள்கின்றன, ஒரு கருத்தைப் பகிரும் மிதப்புப் புள்ளி எண் (floating-point number) அல்ல.

Promptfoo, MIT உரிமத்தின் கீழ் வெளியிடப்பட்டது, இது கமாண்ட் லைனுக்காக (command line) உருவாக்கப்பட்டது. இது regex பொருத்தங்கள், JSON schema சரிபார்ப்பு, contains சரிபார்ப்புகள் மற்றும் துல்லியமான ஸ்ட்ரிங் ஒப்பீடுகள் போன்ற அஸர்ஷன்களை (assertions) இயக்குகிறது. இவை மிகவும் சிக்கலானவை அல்ல; இவை மேம்படுத்தப்பட்ட grep மற்றும் jq கட்டளைகள் போன்றதுதான். அதனால்தான் அவை CI-இல் சிறப்பாகச் செயல்படுகின்றன. ஒரு regex பொருந்துமா இல்லையா என்பது தெளிவானது. ஒரு JSON schema சரியாக இருந்தால் மட்டுமே அது அங்கீகரிக்கும். Promptfoo நிலையான Unix எக்சிட் கோடுகளைத் தருகிறது, எனவே எப்போது மெர்ஜை நிறுத்த வேண்டும் என்பதை GitHub Actions இயல்பாகவே புரிந்துகொள்ளும். இது ஒரு CLI கருவியாகச் செயல்படுவதால், எந்த மொழியுடனும் பொருந்தும் (language-agnostic). வெளியீடுகளைச் சரிபார்க்க மட்டும் ஒரு Node.js சேவையின் உள்ளே Python சூழலை நீங்கள் நிறுவ வேண்டிய அவசியமில்லை.

DeepEval, Apache 2.0 உரிமத்தின் கீழ் உள்ளது, இது Python குழுக்களுக்கான சிறந்த தேர்வாகும். இது pytest போல ஒருங்கிணைந்து செயல்படுகிறது. நீங்கள் தெரிந்த அதே முறையிலேயே டெஸ்ட்களை எழுதலாம், மேலும் ஒரு தோல்வி இயல்பாகவே அந்தத் தொகுதியைத் தடுக்கும். DeepEval பல அளவீடுகளை வழங்குகிறது, ஆனால் முக்கியமான விஷயம் என்னவென்றால், நீங்கள் அவற்றை மிகவும் கவனமாகப் பயன்படுத்த வேண்டும். கேட்டுகளுக்கு (gates) தீர்மானிக்கப்பட்ட அல்லது ஹியூரிஸ்டிக் (heuristic) அளவீடுகளைப் பயன்படுத்துங்கள். நீங்கள் G-Eval அல்லது பிற judge சார்ந்த அளவீடுகளைப் பயன்படுத்தினால், அவற்றை நேரடியாகப் பயன்படுத்தாமல், தடையற்ற ரிப்போர்ட் ஜெனரேட்டர்களாக (non-blocking report generators) மாற்றிப் பயன்படுத்துங்கள். இவ்வாறு பயன்படுத்தும்போது, DeepEval ஒரு ஆராய்ச்சி நோட்டுப் புத்தகத்தின் நிலையற்ற தன்மை இல்லாமல், ஒரு டெஸ்டிங் பிரேம்வொர்க்கின் வசதிகளை உங்களுக்கு வழங்குகிறது.

மற்ற நான்கு எங்கே பொருந்தும்

கேட்டுகளாகத் தொடர முடியாத அந்த நான்கு கட்டமைப்புகளும் இன்னும் மதிப்புமிக்கவைதான். அவை உங்கள் டூல்செயினில் (toolchain) வேறு இடங்களில் பயன்பட வேண்டியவை.

Future AGI (Apache 2.0) ஐம்பதுக்கும் மேற்பட்ட அளவீடுகளை (metrics) வழங்குகிறது மற்றும் தனிப்பயன் SDK-களை உருவாக்கும் குழுக்களை இலக்காகக் கொண்டுள்ளது. இந்த அளவீடுகள் மிகத் துல்லியமானவை. ஆனால், ஒரு CI வரிசையில் (queue) இதை இயக்குவதற்கு நீங்களே ஒரு தனிப்பயன் ஹார்னஸை (harness) எழுத வேண்டும் என்பதுதான் இதில் உள்ள சிக்கல். ஒரு ஆராய்ச்சி சூழலில், இது ஏற்றுக்கொள்ளத்தக்கது. ஆனால் ஒரு மெர்ஜ் வரிசையில் (merge queue), ஒவ்வொரு தனிப்பயன் இணைப்பும் (custom wiring) ஒரு புதிய நிலையற்ற தன்மைக்கு (instability) வழிவகுக்கும். இது ஒரு திறமையான மதிப்பீட்டு இயந்திரம் (evaluation engine), ஆனால் உடனடியாகப் பயன்படுத்தக்கூடிய ஒரு வாயிற்காவலன் (gatekeeper) அல்ல.

RAGAS (Apache 2.0) retrieval-augmented generation தரத்தை அளவிடுவதில் சிறந்து விளங்குகிறது. ஒரு அறிவுத் தளம் (knowledge base) காலப்போக்கில் எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்ள அதன் faithfulness மற்றும் answer relevance அளவீடுகள் உண்மையிலேயே பயனுள்ளதாக இருக்கும். துரதிர்ஷ்டவசமாக, அந்த அளவீடுகள் LLM நீதிபதிகளை (judges) பெரிதும் சார்ந்துள்ளன. Slack-இல் போக்குகளைப் பதிவிடும் ஒரு இரவுநேரத் தரக் கட்டுப்பாட்டுப் பணிகளுக்கு (nightly quality job) இவை சிறந்தவை. ஆனால், ஒரு pull request-ஐத் தடுக்கும் பாதுகாவலர்களாக (bouncers) இவை சரியாக இருக்காது. RAGAS-ஐ உங்கள் மெர்ஜ் தடுப்பான்களில் (merge blockers) வைக்காமல், உங்கள் திட்டமிடப்பட்ட பகுப்பாய்வுப் பாதையில் (scheduled analysis pipeline) பயன்படுத்துங்கள்.

Arize Phoenix Elastic License 2.0-ஐக் கொண்டுள்ளது மற்றும் முற்றிலும் மாறுபட்ட ஒரு நிலையில் உள்ளது. இது distributed tracing-ஐ மதிப்பீட்டுடன் இணைக்கிறது, இதன் மூலம் ஒரு மாடல் ஏன் ஒரு குறிப்பிட்ட முறையில் செயல்பட்டது என்பதை நீங்கள் உற்றுநோக்க (observability) முடிகிறது. ஒரு production சிக்கலைத் தீர்க்கும்போதோ (debugging) அல்லது ஒரு hallucination-ஐத் தவறான retrieval chunk-உடன் தொடர்புபடுத்தும்போதோ உங்களுக்கு இது தேவைப்படும். ஆனால், ஒரு ஜூனியர் டெவலப்பரின் feature branch-ஐ அனுப்பலாமா வேண்டாமா என்பதைத் தீர்மானிக்க ஒரு tracing கருவியைப் பயன்படுத்த நீங்கள் விரும்ப மாட்டீர்கள். இதன் கட்டமைப்பு நுண்ணறிவிற்காக (insight) உருவாக்கப்பட்டது, binary gates-க்காக அல்ல.

MLflow Evaluate (Apache 2.0) அதன் பாரம்பரியத்தை experiment tracking-லிருந்து பெறுகிறது. இது மிகவும் கனமானது (heavy). ஒரு லீன் CI இமேஜிற்குள் (lean CI image) இதைச் சேர்ப்பது தொடக்க நேரத்தையும் (startup time) சார்புகளையும் (dependencies) அதிகரித்து, ஒவ்வொரு வேலையையும் மெதுவாக்கும். ஒருவேளை நீங்கள் கண்டிப்பாக ஒரு pipeline-க்குள் இதைப் பயன்படுத்த வேண்டும் என்றால், கட்டமைப்புச் சரிபார்ப்புகளுக்கு (structural checks) அதன் heuristic metrics-களை மட்டும் பயன்படுத்துங்கள். அப்போதும் கூட, நீங்கள் அந்த கட்டமைப்பின் அடிப்படை வடிவமைப்பிற்கு எதிராகப் போராடிக்கொண்டிருப்பீர்கள். MLflow வாரக்கணக்கில் இயக்கங்களைப் பதிவு செய்யவும் (log runs) மற்றும் சோதனைகளை ஒப்பிடவும் விரும்புகிறது. ஆனால் ஒரு மெர்ஜ் வரிசை ஒரு நிமிடத்திற்குள் ஒரு தீர்ப்பை எதிர்பார்க்கிறது.

தடுப்பிற்கான நடைமுறை விதிகள் (Practical Rules for Gating)

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

முதலாவதாக, உணர்வுகளை (vibe) அல்ல, கட்டமைப்பை (structure) மட்டும் கட்டுப்படுத்துங்கள். ஒரு வெளியீடு (output) சரியான JSON தானா என்பதை நீங்கள் உறுதி செய்யலாம். அதில் தேவையான சாவிகள் (keys) உள்ளனவா என்பதை உறுதி செய்யலாம். ஒரு வகைப்பாட்டு லேபிள் (classification label) அனுமதிக்கப்பட்ட enum-இல் உள்ளதா என்பதை உறுதி செய்யலாம். இந்தச் சரிபார்ப்புகள் வேகமானவை, மலிவானவை மற்றும் தீர்மானிக்கத்தக்கவை (deterministic). ஒரு சுருக்கம் "நட்பாக" (friendly) இருக்கிறதா அல்லது ஒரு மறுபதிப்பு "படைப்பாற்றலுடன்" (creative) இருக்கிறதா என்பதை நீங்கள் நம்பகமான முறையில் உறுதி செய்ய முடியாது. அந்தத் தகுதிகள் மனித மதிப்பாய்விலோ அல்லது அவ்வப்போது செய்யப்படும் தொகுப்பு மதிப்பீட்டிலோ (periodic batch evaluation) இருக்க வேண்டுமே தவிர, தானியங்கி வாயிற்காவலர்களில் (automated gates) இருக்கக்கூடாது.

இரண்டாவதாக, மாறாத உள்ளீட்டிற்கு (unchanged input) ஒரு மதிப்பெண் மாறினால், அதை உடனடியாகக் குறைத்துவிடுங்கள். அதே artifact-க்கு எதிராக உங்கள் மதிப்பீட்டுத் தொகுப்பை (evaluation suite) இரண்டு முறை இயக்கவும். ஏதேனும் ஒரு அளவீடு pass என்பதிலிருந்து fail என மாறினால், அது ஒரு மெர்ஜைத் தடுக்கும் உரிமையை இழந்துவிட்டது என்று அர்த்தம். அதை ஒரு அறிவுரை வழங்கும் டேஷ்போர்டிற்கு (advisory dashboard) மாற்றுங்கள், அங்கு மாறுபாடுகள் (variance) எதிர்பார்க்கப்படலாம் மற்றும் ஏற்றுக்கொள்ளத்தக்கது.

மூன்றாவதாக, exit code-ஐ மதியுங்கள். சிவப்பு பேனருடன் கூடிய அழகான HTML அறிக்கை ஒரு மெர்ஜைத் தடுக்காது. பூஜ்ஜியமற்ற (nonzero) exit code மட்டுமே அதைத் தடுக்கும். உங்கள் மதிப்பீட்டுக் கருவி உங்கள் CI தளத்தின் இயல்பான மொழியில் பேச வேண்டும். Standard out என்பது மனிதர்களுக்கானது. Exit codes என்பவை இயந்திரங்களுக்கானது.

முடிவுரை (The Takeaway)

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

எட்டு மாத காலத் தயாரிப்புப் போக்குவரத்திற்குப் (production traffic) பிறகு, எனது pipeline இப்போது சேவைகளுக்கிடையிலான கட்டமைப்பு மற்றும் schema உறுதிப்படுத்தல்களுக்கு Promptfoo-வையும், pass-fail நிபந்தனைகளுக்குத் தெளிவாகப் பொருந்தக்கூடிய Python-பக்கச் செயல்பாட்டுச் சரிபார்ப்புகளுக்கு (behavioral checks) DeepEval-வையும் இயக்குகிறது. மற்ற அனைத்தும் இரவுநேர டேஷ்போர்டுகளுக்குத் தெரிவிக்கப்படுகின்றன. வரிசை நிலையானது. சிக்னல் துல்லியமானது. குழுவினர் மீண்டும் ஒரு 'red build'-ஐ நம்புகிறார்கள்.

உங்கள் வாயிற்காவலனுக்கு (gate) அதிக அளவீடுகள் தேவையில்லை. ஒவ்வொரு முறையும் உண்மையைச் சொல்லும் குறைவான அளவீடுகளே உங்களுக்குத் தேவை.

Based on original testing and write-up shared on Dev.to. For more discussions on building reliable AI systems, join the GyaanSetu community on Telegram.