GitHub Actions merge queue లో ఎనిమిది నెలలు గడపడం వల్ల, ఫీచర్ కంపారిజన్ మ్యాట్రిక్స్ (feature comparison matrices) ద్వారా ఎప్పటికీ తెలియని విషయాలు తెలుస్తాయి. ఒక ఫ్రేమ్‌వర్క్ యాభై మెట్రిక్స్, అద్భుతమైన డాష్‌బోర్డ్‌లు మరియు గౌరవనీయమైన రీసెర్చ్ ల్యాబ్‌ల నుండి సైటేషన్లను అందించవచ్చు. కానీ, ఒకే విధమైన కోడ్‌కు "vibe check" స్కోరు 0.72 నుండి 0.68 కి మారినంత మాత్రాన అది మీ డిప్లాయ్‌మెంట్‌ను బ్లాక్ చేస్తే, అది ఉపయోగపడకపోవడమే కాదు, మీ షిప్పింగ్ వెలాసిటీకి (shipping velocity) ఒక క్రియాశీల ముప్పుగా మారుతుంది.

చాలా LLM evaluation roundups ఈ ఫిల్టర్‌ను మిస్ అవుతున్నాయి. అవి కేవలం సామర్థ్యాలను (capabilities) లెక్కిస్తాయి. కానీ మెర్జ్ క్యూలో అత్యంత ముఖ్యమైన ప్రశ్నను అవి అడగవు: "ఈ చెక్ ప్రతిసారీ రన్ అయినప్పుడు ఖచ్చితంగా ఒకేలా పాస్ మరియు ఫెయిల్ అవుతుందా?"

నేను ఈ కష్టమైన పనిని చేయడం ద్వారా ఇది నేర్చుకున్నాను. నేను ఆరు ఓపెన్-సోర్స్ LLM eval ఫ్రేమ్‌వర్క్‌లను ఒక నిజమైన CI పైప్‌లైన్‌లోకి అనుసంధానించాను. అవి ఎనిమిది నెలల పాటు లైవ్ ప్రొడక్షన్ pull requests పై రన్ అయ్యాయి. వాటిలో రెండు మాత్రమే గేట్‌కీపర్‌లుగా కొనసాగే అర్హతను పొందాయి. మిగిలినవి అడ్వైజరీ డాష్‌బోర్డ్‌లుగా మార్చబడ్డాయి, నైట్లీ జాబ్స్‌కు (nightly jobs) తరలించబడ్డాయి లేదా పూర్తిగా తొలగించబడ్డాయి. ఈ పాఠం చాలా స్పష్టంగా మరియు ఖరీదైనది: మీరు మెయిన్ బ్రాంచ్‌ను కాపాడుతున్నప్పుడు, probabilistic quality కంటే deterministic structure మెరుగైనది.

మెర్జ్ గేట్ (Merge Gate) యొక్క అసలు పని

CI గేట్ అనేది ఒక రీసెర్చ్ ఎన్విరాన్మెంట్ కాదు. అది ఒక బౌన్సర్ (bouncer) లాంటిది. ఒక నిర్దిష్ట మార్పును చూసి 'అవును' లేదా 'కాదు' అని చెప్పడమే దాని పూర్తి ఉద్దేశ్యం. అవును, ఈ PR మెయిన్ బ్రాంచ్‌లో చేరవచ్చు. లేదు, ఇది చేరకూడదు. ఆ సమాధానం సెకన్లలో రావాలి, ఖర్చు చాలా తక్కువగా ఉండాలి మరియు ఎప్పుడూ వెనక్కి వెళ్ళకూడదు (never flip retroactively). మీరు ఒక ప్రశాంతమైన మంగళవారం మరియు ఒక హడావిడి ఉన్న శుక్రవారం, ఒకే కమిట్‌పై అదే పైప్‌లైన్‌ను మళ్ళీ రన్ చేసినా, ఫలితం ఒకేలా ఉండాలి.

ఇక్కడే చాలా LLM eval ఫ్రేమ్‌వర్క్‌లు తడబడతాయి. అవి డేటా సైంటిస్టుల కోసం, డేటా సైంటిస్టుల ద్వారా నిర్మించబడ్డాయి. అవి ఇన్సైట్ (insight), ఎక్స్‌ప్లోరేషన్ మరియు సూక్ష్మమైన స్కోరింగ్ కోసం ఆప్టిమైజ్ చేయబడ్డాయి. కానీ ఒక మెర్జ్ క్యూ అనేది బైనరీ నిర్ణయాలు (binary decisions), వేగం మరియు సున్నా ఫ్లేకైనెస్ (zero flakiness) కోసం ఆప్టిమైజ్ చేయబడాలి. ఈ రెండు లక్ష్యాలు పాక్షికంగా మాత్రమే కలిసి ఉంటాయి.

LLM-as-Judge ఎందుకు క్యూను దెబ్బతీస్తుంది

నా టెస్ట్‌లో విఫలమైన టూల్స్ అన్నీ ఒకే రకమైన డిజైన్ లోపాన్ని కలిగి ఉన్నాయి: అవి ప్రాథమిక గేట్ మెకానిజంగా LLM-as-judge కాల్స్‌పై అతిగా ఆధారపడ్డాయి.

LLM-as-judge ప్రాంప్ట్ ఒక మోడల్‌ను అవుట్‌పుట్‌ను 1 నుండి 10 స్కేల్‌లో స్కోర్ చేయమని, లేదా రెండు ప్రతిస్పందనలలో మెరుగైనదాన్ని ఎంచుకోమని, లేదా వాస్తవిక ఖచ్చితత్వాన్ని రేట్ చేయమని అడుగుతుంది. క్వాలిటీ ట్రెండ్స్‌ను అర్థం చేసుకోవడానికి ఈ విధానం శక్తివంతమైనది. కానీ ఒక బ్లాకింగ్ CI చెక్‌కు ఇది విషం వంటిది. టెంపరేచర్ (temperature), మోడల్ వెర్షనింగ్ మరియు ప్రాంప్ట్ ఫార్మాటింగ్ వంటి అంశాల వల్ల నాయిస్ (noise) ఏర్పడుతుంది, దీనివల్ల ఒకే ఇన్‌పుట్‌కు వేర్వేరు రోజుల్లో వేర్వేరు స్కోర్లు రావచ్చు. ఆ స్కోరు ఒక కఠినమైన త్రెషోల్డ్ (threshold) మరియు ఎగ్జిట్ కోడ్‌తో ముడిపడి ఉన్నప్పుడు, మీ క్యూ అనవసరమైన కారణాల వల్ల బ్లాక్ అవుతుంది.

ఈ వైఫల్యాలు వేగంగా విస్తరిస్తాయి. ఒక నాన్-డిటర్మినిస్టిక్ (nondeterministic) చెక్ క్యూలో అంతరాయాలను కలిగిస్తుంది. ఇంజనీర్లు నచ్చిన స్కోరు వచ్చే వరకు మళ్ళీ మళ్ళీ రిట్రై చేయడం నేర్చుకుంటారు, ఇది టీమ్‌లో రెడ్ బిల్డ్స్‌ను (red builds) విస్మరించే అలవాటును పెంచుతుంది. ప్రతి రిట్రై వల్ల API క్రెడిట్స్ ఖర్చవుతాయి కాబట్టి టోకెన్ ఖర్చులు పెరుగుతాయి. అన్నిటికంటే దారుణమైన విషయం ఏమిటంటే, ఆ సిగ్నల్ అర్థం లేకుండా పోతుంది. ఒక రెడ్ బిల్డ్ అంటే "మీరు ఒక బగ్ introd्यूस చేశారు" అని అర్థం కావాలి. కానీ అది "జడ్జ్ మోడల్ ఈరోజు కొంచెం పక్కాగా ఉంది" అని అర్థం వస్తే, నమ్మకం దెబ్బతింటుంది.

విజయం సాధించినవి (Survivors) వేరుగా ఏమి చేస్తాయి

Promptfoo మరియు DeepEval విజయం సాధించాయి ఎందుకంటే అవి deterministic checks ను ప్రాధాన్యత కలిగిన అంశాలుగా (first-class citizens) పరిగణిస్తాయి మరియు LLM judge స్కోర్‌లను సెకండరీ, నాన్-బ్లాకింగ్ సిగ్నల్స్‌గా చూస్తాయి. ఒక గేట్‌కు ఒక ఎగ్జిట్ కోడ్ అవసరమని, అభిప్రాయాన్ని చెప్పే ఫ్లోటింగ్-పాయింట్ నంబర్ అవసరం లేదని అవి అర్థం చేసుకున్నాయి.

Promptfoo, MIT లైసెన్స్ కింద విడుదల చేయబడింది, ఇది కమాండ్ లైన్ కోసం రూపొందించబడింది. ఇది regex matches, JSON schema validation, contains checks మరియు exact string comparisons వంటి అసర్షన్స్‌ను (assertions) రన్ చేస్తుంది. ఇవి పెద్దగా ఫ్యాన్సీగా అనిపించకపోవచ్చు, ఇవి కేవలం మెరుగైన grep మరియు jq కమాండ్స్ లాంటివి మాత్రమే. కానీ CIలో ఇవి సరిగ్గా పనిచేయడానికి కారణం కూడా అదే. ఒక regex మ్యాచ్ అవ్వాలి లేదా అవ్వకూడదు, అంతే. ఒక JSON schema వాలిడేట్ అవ్వాలి లేదా ఎర్రర్ ఇవ్వాలి, అంతే. Promptfoo స్టాండర్డ్ Unix exit codesలను రిటర్న్ చేస్తుంది, కాబట్టి GitHub Actions మెర్జ్‌ను ఎప్పుడు ఆపాలో సహజంగానే అర్థం చేసుకుంటుంది. ఇది ఒక CLI టూల్‌గా పనిచేస్తుంది కాబట్టి ఇది లాంగ్వేజ్-అగ్నోస్టిక్ (language-agnostic). అవుట్‌పుట్‌లను వాలిడేట్ చేయడానికి మీరు Node.js సర్వీస్ రిపోలో Python ఎకోసిస్టమ్‌ను ఇన్‌స్టాల్ చేయాల్సిన అవసరం లేదు.

DeepEval, Apache 2.0 కింద లైసెన్స్ పొందింది, ఇది Python టీమ్స్ కోసం ఉత్తమ ఎంపిక. ఇది pytest లాగా ఇంటిగ్రేట్ అవుతుంది. మీరు తెలిసిన సింటాక్స్‌లోనే టెస్ట్‌లను రాస్తారు, మరియు ఫెయిల్యూర్ వస్తే అది నేచురల్‌గా సూట్‌ను బ్లాక్ చేస్తుంది. DeepEval అనేక మెట్రిక్స్‌ను అందిస్తుంది, కానీ వాటిని జాగ్రత్తగా ఉపయోగించాల్సి ఉంటుంది. గేట్‌ల కోసం deterministic లేదా heuristic మెట్రిక్స్‌పై ఆధారపడండి. మీరు G-Eval లేదా ఇతర judge-based స్కోరర్‌లను ఉపయోగిస్తుంటే, వాటిని హార్డ్ అసర్ట్స్ (hard asserts) లాగా కాకుండా, నాన్-బ్లాకింగ్ రిపోర్ట్ జనరేటర్లుగా వాడండి. ఈ విధంగా ఉపయోగించినప్పుడు, DeepEval మీకు రీసెర్చ్ నోట్‌బుక్ లాంటి ఫ్లేకైనెస్ లేకుండా, ఒక టెస్టింగ్ ఫ్రేమ్‌వర్క్ యొక్క సౌలభ్యాన్ని అందిస్తుంది.

మిగిలిన నాలుగు ఎక్కడ ఉపయోగపడతాయి

గేట్‌లుగా నిలవలేకపోయిన ఆ నాలుగు ఫ్రేమ్‌వర్క్‌లకు ఇంకా విలువ ఉంది. అవి కేవలం మీ టూల్‌చైన్‌లో (toolchain) వేరే చోట ఉపయోగపడతాయి.

Future AGI (Apache 2.0) యాభైకి పైగా మెట్రిక్స్‌ను అందిస్తుంది మరియు కస్టమ్ SDKలను నిర్మిస్తున్న టీమ్‌లను లక్ష్యంగా చేసుకుంటుంది. ఈ మెట్రిక్స్ చాలా సమగ్రంగా ఉంటాయి. సమస్య ఏమిటంటే, CI క్యూలో దీనిని నడపడానికి మీరు మీ స్వంత హార్నెస్ (harness) రాయాలని ఈ టూల్ ఆశిస్తుంది. పరిశోధనా సందర్భంలో (research context), ఇది ఒక సహేతుకమైన బదిలీ. కానీ మెర్జ్ క్యూలో (merge queue), ప్రతి కస్టమ్ వైరింగ్ పొర అస్థిరతకు కొత్త మూలమవుతుంది. ఇది సమర్థవంతమైన ఎవాల్యుయేషన్ ఇంజిన్, కానీ సిద్ధంగా ఉన్న గేట్‌కీపర్ కాదు.

RAGAS (Apache 2.0) రిట్రీవల్-ఆగ్మెంటెడ్ జనరేషన్ (retrieval-augmented generation) నాణ్యతను కొలవడంలో అద్భుతంగా పనిచేస్తుంది. దీని ఫెయిత్‌ఫుల్‌నెస్ (faithfulness) మరియు ఆన్సర్ రిలెవెన్స్ (answer relevance) మెట్రిక్స్, ఒక నాలెడ్జ్ బేస్ కాలక్రమేణా ఎలా పనిచేస్తుందో అర్థం చేసుకోవడానికి నిజంగా ఉపయోగపడతాయి. దురదృష్టవశాత్తూ, ఆ మెట్రిక్స్ LLM జడ్జీలపై ఎక్కువగా ఆధారపడి ఉంటాయి. Slackలో ట్రెండ్స్‌ను పోస్ట్ చేసే నైట్లీ క్వాలిటీ జాబ్ కోసం ఇవి అద్భుతంగా ఉంటాయి. కానీ పుల్ రిక్వెస్ట్ (pull request) విషయంలో ఇవి అంత సమర్థవంతమైన బౌన్సర్లు కావు. RAGASను మీ షెడ్యూల్డ్ అనాలిసిస్ పైప్‌లైన్‌లోకి మార్చండి, మీ మెర్జ్ బ్లాకర్స్‌లోకి కాదు.

Arize Phoenix Elastic License 2.0ను కలిగి ఉంటుంది మరియు ఇది పూర్తిగా భిన్నమైన విభాగంలో ఉంటుంది. ఇది డిస్ట్రిబ్యూటెడ్ ట్రేసింగ్‌ను ఎవాల్యుయేషన్‌తో అనుసంధానిస్తుంది, తద్వారా ఒక మోడల్ ఎందుకు ఒక నిర్దిష్ట రీతిలో ప్రవర్తించిందో మీకు అవలోకనం (observability) అందిస్తుంది. మీరు ప్రొడక్షన్ ఇన్సిడెంట్‌ను డీబగ్ చేస్తున్నప్పుడు లేదా హాలూసినేషన్‌ను (hallucination) తప్పుడు రిట్రీవల్ చంక్‌కు వెనక్కి ట్రాక్ చేస్తున్నప్పుడు ఇది మీకు అవసరం. జూనియర్ డెవలపర్ యొక్క ఫీచర్ బ్రాంచ్ షిప్ చేయవచ్చా లేదా అని నిర్ణయించడానికి మీరు ట్రేసింగ్ టూల్‌ను ఉపయోగించాలనుకోరు. దీని ఆర్కిటెక్చర్ ఇన్సైట్ (insight) కోసం నిర్మించబడింది, బైనరీ గేట్ల కోసం కాదు.

MLflow Evaluate (Apache 2.0) తన నేపథ్యాన్ని ఎక్స్‌పెరిమెంట్ ట్రాకింగ్ నుండి పొందింది. ఇది చాలా బరువుగా (heavy) ఉంటుంది. దీనిని ఒక లీన్ CI ఇమేజ్‌లోకి తీసుకురావడం వల్ల స్టార్టప్ సమయం మరియు డిపెండెన్సీలు పెరుగుతాయి, ఇది ప్రతి జాబ్‌ను నెమ్మదింపజేస్తుంది. మీరు ఖచ్చితంగా పైప్‌లైన్ లోపల దీనిని ఉపయోగించాల్సి వస్తే, స్ట్రక్చరల్ చెక్‌ల కోసం దాని హ్యూరిస్టిక్ మెట్రిక్స్‌కే పరిమితం అవ్వండి. అలా చేసినా, మీరు ఫ్రేమ్‌వర్క్ యొక్క ప్రాథమిక డిజైన్‌తో పోరాడుతున్నట్లే. MLflow రన్‌లను లాగ్ చేయాలని మరియు వారాల తరబడి ఎక్స్‌పెరిమెంట్లను పోల్చాలని కోరుకుంటుంది. కానీ మెర్జ్ క్యూ ఒక నిమిషం లోపు తీర్పును కోరుకుంటుంది.

గేటింగ్ కోసం ఆచరణాత్మక నియమాలు

ఈ ప్రయోగం నుండి మీరు మరేదీ తీసుకోకపోయినా, ఈ మూడు నియమాలను గుర్తుంచుకోండి.

మొదటిది, వైబ్ (vibe) కాదు, స్ట్రక్చర్‌ను గేట్ చేయండి. అవుట్‌పుట్ వాలిడ్ JSON అని మీరు అమలు చేయవచ్చు. అందులో అవసరమైన కీలు ఉన్నాయని మీరు నిర్ధారించవచ్చు. క్లాసిఫికేషన్ లేబుల్ అనుమతించబడిన enum కు చెందినదని మీరు అమలు చేయవచ్చు. ఈ చెక్‌లు వేగంగా, తక్కువ ఖర్చుతో మరియు డిటర్మినిస్టిక్‌గా (deterministic) ఉంటాయి. ఒక సమ్మరీ "ఫ్రెండ్లీ"గా ఉందో లేదో లేదా రీరైట్ "క్రియేటివ్"గా ఉందో లేదో మీరు నమ్మదగిన రీతిలో అమలు చేయలేరు. అటువంటి లక్షణాలు మానవ సమీక్షకు లేదా క్రమానుగత బ్యాచ్ ఎవాల్యుయేషన్‌కు చెందుతాయి, ఆటోమేటెడ్ గేట్‌లకు కాదు.

రెండవది, మారని ఇన్‌పుట్‌పై స్కోరు మారుతుంటే, దానిని వెంటనే తగ్గించండి (demote). ఖచ్చితంగా ఒకే ఆర్టిఫాక్ట్‌పై మీ ఎవాల్యుయేషన్ సూట్‌ను రెండుసార్లు రన్ చేయండి. ఏదైనా మెట్రిక్ పాస్ నుండి ఫెయిల్ కి మారితే, అది మెర్జ్‌ను బ్లాక్ చేసే హక్కును కోల్పోతుంది. దానిని వైవిధ్యం (variance) ఆశించదగినది మరియు సహించదగినదిగా ఉండే అడ్వైజరీ డాష్‌బోర్డ్‌కు మార్చండి.

మూడవది, ఎగ్జిట్ కోడ్‌ను గౌరవించండి. ఎరుపు బ్యానర్‌తో ఉన్న అందమైన HTML రిపోర్ట్ మెర్జ్‌ను ఆపదు. నాన్-జీరో (nonzero) ఎగ్జిట్ కోడ్ ఆపుతుంది. మీ ఎవాల్యుయేషన్ టూల్ మీ CI ప్లాట్‌ఫారమ్ యొక్క నేటివ్ లాంగ్వేజ్‌లో మాట్లాడాలి. స్టాండర్డ్ అవుట్ (Standard out) మనుషుల కోసం. ఎగ్జిట్ కోడ్‌లు యంత్రాల కోసం.

ముగింపు

LLM-ఆధారిత అప్లికేషన్‌లను ఎలా పరీక్షించాలో తెలుసుకోవడంలో మనం ఇంకా ప్రారంభ దశలోనే ఉన్నాము. ఎవాల్యుయేషన్‌ను మానవ గ్రేడింగ్ రూబ్రిక్ లాగా (nuanced, contextual, and slightly subjective) చూడాలనే ప్రలోభం ఉంటుంది. అది ఒక రీసెర్చ్ పేపర్‌లో పనిచేస్తుంది, కానీ మెర్జ్ క్యూలో విఫలమవుతుంది.

ఎనిమిది నెలల ప్రొడక్షన్ ట్రాఫిక్ తర్వాత, నా పైప్‌లైన్ ఇప్పుడు సర్వీసుల అంతటా స్ట్రక్చరల్ మరియు స్కీమా అసర్షన్ల కోసం Promptfooని, మరియు పాస్-ఫెయిల్ కండిషన్లకు సరిగ్గా సరిపోయే పైథాన్-సైడ్ బిహేవియరల్ చెక్‌ల కోసం DeepEvalని రన్ చేస్తుంది. మిగిలినవన్నీ నైట్లీ డాష్‌బోర్డ్‌లకు రిపోర్ట్ చేస్తాయి. క్యూ స్థిరంగా ఉంది. సిగ్నల్ స్పష్టంగా ఉంది. టీమ్ మళ్ళీ రెడ్ బిల్డ్‌ను నమ్ముతోంది.

మీ గేట్ వద్ద మీకు మరిన్ని మెట్రిక్స్ అవసరం లేదు. ప్రతిసారీ నిజం చెప్పే తక్కువ మెట్రిక్స్ అవసరం.

Dev.to లో షేర్ చేయబడిన అసలు టెస్టింగ్ మరియు రైట్‌అప్‌పై ఆధారపడి ఉంది. నమ్మదగిన AI సిస్టమ్‌లను నిర్మించడం గురించి మరిన్ని చర్చల కోసం, Telegramలో GyaanSetu కమ్యూనిటీలో చేరండి.