GitHub Actions മെർജ് ക്യൂവിൽ (merge queue) എട്ട് മാസം ചെലവഴിക്കുന്നത് ഫീച്ചർ താരതമ്യ മാട്രിക്സുകൾ (feature comparison matrices) ഒരിക്കലും പഠിപ്പിക്കാത്ത ചില കാര്യങ്ങൾ നിങ്ങളെ പഠിപ്പിക്കും. ഒരു ഫ്രെയിംവർക്കിന് അമ്പതോളം മെട്രിക്സുകളും, മനോഹരമായ ഡാഷ്‌ബോർഡുകളും, പ്രശസ്തമായ ഗവേഷണ ലാബുകളിൽ നിന്നുള്ള ഉദ്ധരണികളും നൽകാൻ കഴിഞ്ഞേക്കാം. എന്നാൽ ഒരേ കോഡിന് തന്നെ ഒരു "vibe check" സ്കോർ 0.72-ൽ നിന്ന് 0.68 ആയി മാറിയതിന്റെ പേരിൽ അത് നിങ്ങളുടെ ഡിപ്ലോയ്മെന്റ് (deploy) തടഞ്ഞാൽ, അത് ഉപയോഗശൂന്യതയേക്കാൾ മോശമാണ്. അത് നിങ്ങളുടെ ഷിപ്പിംഗ് വേഗതയ്ക്ക് (shipping velocity) ഒരു ഭീഷണിയായി മാറുന്നു.

മിക്ക LLM ഇവാലുവേഷൻ (evaluation) അവലോകനങ്ങളും വിട്ടുപോകുന്ന ഒരു ഘടകമാണിത്. അവ കഴിവുകളെ (capabilities) മാത്രം കണക്കിലെടുക്കുന്നു. എന്നാൽ ഒരു മെർജ് ക്യൂവിൽ ഏറ്റവും പ്രധാനപ്പെട്ട ഒരു ചോദ്യം അവ ചോദിക്കാറില്ല: "ഈ ചെക്ക് ഓരോ തവണ റൺ ചെയ്യുമ്പോഴും കൃത്യമായും ഒരേ രീതിയിൽ തന്നെ പാസ്സാകുന്നുണ്ടോ അതോ ഫെയിൽ ആകുന്നുണ്ടോ?"

അസ്വസ്ഥതയുണ്ടാക്കുന്ന ചില പരീക്ഷണങ്ങളിലൂടെയാണ് ഞാൻ ഇത് പഠിച്ചത്. ഞാൻ ആറ് ഓപ്പൺ സോഴ്സ് LLM ഇവാലുവേഷൻ ഫ്രെയിംവർക്കുകളെ ഒരു യഥാർത്ഥ CI പൈപ്പ്‌ലൈനിൽ (pipeline) ഘടിപ്പിച്ചു. എട്ട് മാസത്തോളം അവ ലൈവ് പ്രൊഡക്ഷൻ പുൾ റിക്വസ്റ്റുകളിൽ (pull requests) പ്രവർത്തിച്ചു. അതിൽ രണ്ടെണ്ണം ഗേറ്റ്‌കീപ്പർമാരായി (gatekeepers) തുടരാൻ യോഗ്യത നേടി. ബാക്കിയുള്ളവയെ ഉപദേശക ഡാഷ്‌ബോർഡുകളാക്കി (advisory dashboards) മാറ്റി, നൈറ്റ്ലി ജോബ്സിലേക്ക് (nightly jobs) മാറ്റുകയോ അല്ലെങ്കിൽ പൂർണ്ണമായും ഒഴിവാക്കുകയോ ചെയ്തു. പാഠം കഠിനവും ചിലവേറിയതുമായിരുന്നു: മെയിൻ ബ്രാഞ്ച് (main branch) സംരക്ഷിക്കുമ്പോൾ പ്രോബബിലിസ്റ്റിക് ക്വാളിറ്റിയേക്കാൾ (probabilistic quality) ഡെറ്റർമിനിസ്റ്റിക് സ്ട്രക്ചർ (deterministic structure) ആണ് പ്രധാനം.

ഒരു മെർജ് ഗേറ്റിന്റെ (Merge Gate) യഥാർത്ഥ ജോലി

ഒരു CI ഗേറ്റ് എന്നത് ഒരു ഗവേഷണ അന്തരീക്ഷമല്ല. അതൊരു ബൗൺസർ (bouncer) ആണ്. ഒരു പ്രത്യേക മാറ്റം പരിശോധിച്ച ശേഷം 'അതെ' അല്ലെങ്കിൽ 'അല്ല' എന്ന് ഉത്തരം നൽകുക എന്നതാണ് അതിന്റെ ഏക ലക്ഷ്യം. "അതെ, ഈ PR മെയിൻ ബ്രാഞ്ചിൽ ചേരാം. അല്ല, ഇതിന് കഴിയില്ല." ആ ഉത്തരം സെക്കൻഡുകൾക്കുള്ളിൽ ലഭിക്കണം, ചിലവ് വളരെ കുറവായിരിക്കണം, കൂടാതെ മുൻകാല തീരുമാനങ്ങളെ മാറ്റുന്ന രീതിയിൽ മാറാൻ പാടില്ലാത്തതുമാണ്. ശാന്തമായ ഒരു ചൊവ്വാഴ്ചയോ തിരക്കേറിയ ഒരു വെള്ളിയാഴ്ചയോ ഒരേ കമ്മിറ്റിന് (commit) നേരെ ഒരേ പൈപ്പ്‌ലൈൻ വീണ്ടും റൺ ചെയ്താൽ, ഫലം ഒന്നുതന്നെയായിരിക്കണം.

ഇവിടുന്നാണ് മിക്ക LLM ഇവാലുവേഷൻ ഫ്രെയിംവർക്കുകളും പതറുന്നത്. അവ ഡാറ്റാ സയന്റിസ്റ്റുകൾക്കായി ഡാറ്റാ സയന്റിസ്റ്റുകൾ നിർമ്മിച്ചവയാണ്. അവ ഇൻസൈറ്റുകൾക്കും (insights), പര്യവേക്ഷണത്തിനും (exploration), സൂക്ഷ്മമായ സ്കോറിംഗിനും (nuanced scoring) മുൻഗണന നൽകുന്നു. എന്നാൽ ഒരു മെർജ് ക്യൂ ബൈനറി തീരുമാനങ്ങൾക്കും (binary decisions), വേഗതയ്ക്കും, യാതൊരുവിധ അസ്ഥിരതയുമില്ലാത്ത (zero flakiness) പ്രവർത്തനത്തിനും മുൻഗണന നൽകുന്നു. ഈ രണ്ട് ലക്ഷ്യങ്ങളും ഭാഗികമായി മാത്രമേ പരസ്പരം യോജിക്കുന്നുള്ളൂ.

എന്തുകൊണ്ടാണ് LLM-as-Judge മെർജ് ക്യൂ തകരാൻ കാരണമാകുന്നത്

എന്റെ പരീക്ഷണത്തിൽ പരാജയപ്പെട്ട ടൂളുകൾക്കെല്ലാം ഒരു പൊതുവായ പിഴവുണ്ടായിരുന്നു: അവ പ്രധാന ഗേറ്റ് മെക്കാനിസമായി LLM-as-judge കോളുകളെ അമിതമായി ആശ്രയിച്ചു.

ഒരു LLM-as-judge പ്രോംപ്റ്റ് ഒരു ഔട്ട്‌പുട്ടിന് ഒന്ന് മുതൽ പത്ത് വരെയുള്ള സ്കോർ നൽകാനോ, രണ്ട് മറുപടികളിൽ മികച്ചത് തിരഞ്ഞെടുക്കാനോ, അല്ലെങ്കിൽ വസ്തുതാപരമായ കൃത്യത വിലയിരുത്താനോ ഒരു മോഡലിനോട് ആവശ്യപ്പെടുന്നു. ഗുണനിലവാരത്തിലെ മാറ്റങ്ങൾ മനസ്സിലാക്കാൻ ഈ രീതി മികച്ചതാണ്. എന്നാൽ ഒരു ബ്ലോക്കിംഗ് CI ചെക്കിന് ഇത് വിഷമാണ്. ടെമ്പറേച്ചർ (temperature), മോഡൽ വേർഷനിംഗ് (model versioning), പ്രോംപ്റ്റ് ഫോർമാറ്റിംഗ് (prompt formatting) എന്നിവയിലെ വ്യത്യാസങ്ങൾ കാരണം ഒരേ ഇൻപുട്ടിന് തന്നെ വ്യത്യസ്ത ദിവസങ്ങളിൽ വ്യത്യസ്ത സ്കോറുകൾ ലഭിച്ചേക്കാം. ആ സ്കോർ ഒരു നിശ്ചിത പരിധിയുമായും (hard threshold) എക്സിറ്റ് കോഡുമായും (exit code) ബന്ധിപ്പിക്കുമ്പോൾ, നിങ്ങളുടെ ക്യൂ അപ്രതീക്ഷിതമായ കാരണങ്ങളാൽ തടസ്സപ്പെടുന്നു.

പരാജയങ്ങൾ വേഗത്തിൽ പടരുന്നു. ഒരു നോൺ-ഡെറ്റർമിനിസ്റ്റിക് ചെക്ക് (nondeterministic check) ക്യൂയിൽ കുരുക്കുകൾ ഉണ്ടാക്കുന്നു. സ്കോർ അനുകൂലമാകുന്നതുവരെ വീണ്ടും വീണ്ടും ശ്രമിക്കാൻ എൻജിനീയർമാർ പഠിക്കുന്നു, ഇത് റെഡ് ബിൽഡുകൾ (red builds) അവഗണിക്കാനുള്ള ശീലം ടീമിന് ഉണ്ടാക്കുന്നു. ഓരോ തവണ വീണ്ടും ശ്രമിക്കുമ്പോഴും കൂടുതൽ API ക്രെഡിറ്റുകൾ ചിലവാകുന്നത് കൊണ്ട് ടോക്കൺ ചിലവുകൾ വർദ്ധിക്കുന്നു. എല്ലാറ്റിനേക്കാളും മോശമായ കാര്യം, ലഭിക്കുന്ന സിഗ്നലുകൾ അർത്ഥശൂന്യമായി മാറുന്നു എന്നതാണ്. ഒരു റെഡ് ബിൽഡ് എന്നാൽ "നിങ്ങൾ ഒരു ബഗ് (bug) വരുത്തിയിരിക്കുന്നു" എന്നാണ് അർത്ഥമാക്കേണ്ടത്. എന്നാൽ അത് "ജഡ്ജ് മോഡൽ ഇന്ന് അല്പം깐깐മായിരിക്കുന്നു" എന്നാണെങ്കിൽ, വിശ്വാസം നഷ്ടപ്പെടും.

അതിജീവിച്ചവ വ്യത്യസ്തമായി ചെയ്യുന്നത് എന്താണ്?

Promptfoo, DeepEval എന്നിവ അതിജീവിച്ചത് അവ ഡെറ്റർമിനിസ്റ്റിക് ചെക്കുകളെ (deterministic checks) പ്രധാനമായും കാണുകയും LLM ജഡ്ജ് സ്കോറുകളെ സെക്കൻഡറി, നോൺ-ബ്ലോക്കിംഗ് സിഗ്നലുകളായി മാത്രം കണക്കാക്കുകയും ചെയ്തതുകൊണ്ടാണ്. ഒരു ഗേറ്റിന് ഒരു അഭിപ്രായമുള്ള ഫ്ലോട്ടിംഗ് പോയിന്റ് നമ്പറല്ല, മറിച്ച് ഒരു എക്സിറ്റ് കോഡ് (exit code) ആണ് വേണ്ടതെന്ന് അവ മനസ്സിലാക്കുന്നു.

Promptfoo, MIT ലൈസൻസിന് കീഴിൽ പുറത്തിറങ്ങിയത്, കമാൻഡ് ലൈനിന് (command line) വേണ്ടി നിർമ്മിച്ചതാണ്. ഇത് regex matches, JSON schema validation, contains checks, exact string comparisons തുടങ്ങിയ അസർഷനുകൾ (assertions) പ്രവർത്തിപ്പിക്കുന്നു. ഇവ വലിയ അത്ഭുതങ്ങളൊന്നുമല്ല; ഇവ മികച്ച രീതിയിൽ ഉപയോഗിക്കാവുന്ന grep, jq കമാൻഡുകൾ മാത്രമാണ്. അതുകൊണ്ടാണ് അവ CI-യിൽ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നത്. ഒരു regex ഒന്നുകിൽ മാച്ച് ആകുന്നു, അല്ലെങ്കിൽ ആകില്ല. ഒരു JSON schema ഒന്നുകിൽ വാലിഡേറ്റ് ആകുന്നു, അല്ലെങ്കിൽ എറർ കാണിക്കുന്നു. Promptfoo സ്റ്റാൻഡേർഡ് യുണിക്സ് എക്സിറ്റ് കോഡുകൾ (Unix exit codes) നൽകുന്നു, അതിനാൽ മെർജ് എപ്പോൾ നിർത്തണമെന്ന് GitHub Actions-ന് എളുപ്പത്തിൽ മനസ്സിലാക്കാൻ സാധിക്കും. ഇതൊരു CLI ടൂൾ ആയതുകൊണ്ട് ഏത് പ്രോഗ്രാമിംഗ് ഭാഷയിലും ഉപയോഗിക്കാം. ഔട്ട്‌പുട്ടുകൾ വാലിഡേറ്റ് ചെയ്യാൻ വേണ്ടി മാത്രം ഒരു Node.js സർവീസ് റെപ്പോസിറ്ററിനുള്ളിൽ പൈത്തൺ ഇക്കോസിസ്റ്റം ഇൻസ്റ്റാൾ ചെയ്യേണ്ട ആവശ്യമില്ല.

DeepEval, Apache 2.0 ലൈസൻസുള്ളത്, പൈത്തൺ ടീമുകൾക്കുള്ള മികച്ച തിരഞ്ഞെടുപ്പാണ്. ഇത് pytest പോലെ തന്നെ പ്രവർത്തിക്കുന്നു. നിങ്ങൾക്ക് പരിചിതമായ സിന്റാക്സിൽ (syntax) ടെസ്റ്റുകൾ എഴുതാം, പരാജയപ്പെട്ടാൽ അത് സ്വാഭാവികമായും സ്യൂട്ടിനെ (suite) ബ്ലോക്ക് ചെയ്യും. DeepEval ധാരാളം മെട്രിക്സുകൾ വാഗ്ദാനം ചെയ്യുന്നു

Future AGI (Apache 2.0) അമ്പതിലധികം മെട്രിക്സുകൾ (metrics) നൽകുന്നുണ്ടെങ്കിലും, കസ്റ്റം SDK-കൾ നിർമ്മിക്കുന്ന ടീമുകളെയാണ് ഇത് ലക്ഷ്യമിടുന്നത്. ഈ മെട്രിക്സുകൾ വളരെ വിശദമാണ്. എന്നാൽ പ്രശ്നം എന്തെന്നാൽ, ഒരു CI ക്യൂവിൽ (queue) ഇത് പ്രവർത്തിപ്പിക്കാൻ സ്വന്തമായി ഒരു ഹാർനെസ്സ് (harness) എഴുതണമെന്ന് ഈ ടൂൾ നിങ്ങളിൽ നിന്ന് പ്രതീക്ഷിക്കുന്നു. ഒരു ഗവേഷണ സാഹചര്യത്തിൽ (research context), ഇത് ന്യായമായ ഒരു വിട്ടുവീഴ്ചയാണ്. എന്നാൽ ഒരു മെർജ് ക്യൂവിൽ (merge queue), ഓരോ കസ്റ്റം വയറിംഗും അസ്ഥിരതയുടെ (instability) പുതിയൊരു ഉറവിടമാണ്. ഇതൊരു മികച്ച ഇവാലുവേഷൻ എഞ്ചിൻ ആണ്, എന്നാൽ ഒരു റെഡിമേഡ് ഗേറ്റ്കീപ്പർ (gatekeeper) അല്ല.

RAGAS (Apache 2.0) retrieval-augmented generation-ന്റെ ഗുണനിലവാരം അളക്കുന്നതിൽ മികച്ചുനിൽക്കുന്നു. ഒരു നോളജ് ബേസ് (knowledge base) കാലക്രമേണ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കാൻ ഇതിലെ faithfulness, answer relevance മെട്രിക്സുകൾ ശരിക്കും ഉപകരിക്കും. നിർഭാഗ്യവശാൽ, ഈ മെട്രിക്സുകൾ LLM ജഡ്ജിമാരെ (judges) വളരെയധികം ആശ്രയിച്ചാണ് പ്രവർത്തിക്കുന്നത്. Slack-ലേക്ക് ട്രെൻഡുകൾ പോസ്റ്റ് ചെയ്യുന്ന ഒരു നൈറ്റ്ലി ക്വാളിറ്റി ജോബിന് (nightly quality job) ഇവ മികച്ചതാണ്. എന്നാൽ ഒരു പുൾ റിക്വസ്റ്റിന് (pull request) ഇവ അത്ര അനുയോജ്യമായ 'ബൗൺസറുകൾ' അല്ല. RAGAS-നെ നിങ്ങളുടെ മെർജ് ബ്ലോക്കറുകളിലല്ല, മറിച്ച് ഷെഡ്യൂൾ ചെയ്ത അനാലിസിസ് പൈപ്പ്‌ലൈനുകളിലാണ് (scheduled analysis pipeline) ഉൾപ്പെടുത്തേണ്ടത്.

Arize Phoenix Elastic License 2.0 ഉപയോഗിക്കുന്നു, ഇത് തികച്ചും വ്യത്യസ്തമായ ഒരു മേഖലയിലാണ് പ്രവർത്തിക്കുന്നത്. ഇത് ഡിസ്ട്രിബ്യൂട്ടഡ് ട്രേസിംഗിനെ (distributed tracing) ഇവാലുവേഷനുമായി ബന്ധിപ്പിക്കുന്നു, അതുവഴി ഒരു മോഡൽ എന്തുകൊണ്ട് ഒരു പ്രത്യേക രീതിയിൽ പെരുമാറി എന്ന് നിരീക്ഷിക്കാൻ (observability) സാധിക്കുന്നു. ഒരു പ്രൊഡക്ഷൻ ഇൻസിഡന്റ് (production incident) ഡീബഗ് ചെയ്യുമ്പോഴോ അല്ലെങ്കിൽ ഒരു ഹാലൂസിനേഷൻ (hallucination) മോശം റിട്രീവൽ ചങ്ക് (retrieval chunk) മൂലമാണോ എന്ന് പരിശോധിക്കുമ്പോഴോ നിങ്ങൾക്ക് ഇത് ആവശ്യമാണ്. എന്നാൽ ഒരു ജൂനിയർ ഡെവലപ്പറുടെ ഫീച്ചർ ബ്രാഞ്ച് ഷിപ്പ് ചെയ്യാമോ എന്ന് തീരുമാനിക്കാൻ ഒരു ട്രേസിംഗ് ടൂളിനെ നിങ്ങൾ ആഗ്രഹിക്കില്ല. ഇതിന്റെ ആർക്കിടെക്ചർ ഇൻസൈറ്റുകൾ (insights) നൽകാനാണ് നിർമ്മിച്ചിട്ടുള്ളത്, അല്ലാതെ ബൈനറി ഗേറ്റുകൾ (binary gates) ഉണ്ടാക്കാനല്ല.

MLflow Evaluate (Apache 2.0) എക്സ്പിരിമെന്റ് ട്രാക്കിംഗിൽ (experiment tracking) നിന്നാണ് അതിന്റെ പാരമ്പര്യം വരുന്നത്. ഇത് ഭാരമേറിയതാണ് (heavy). ഒരു ലീൻ CI ഇമേജിലേക്ക് (lean CI image) ഇതിനെ ഉൾപ്പെടുത്തുന്നത് സ്റ്റാർട്ടപ്പ് സമയവും ഡിപെൻഡൻസികളും (dependencies) വർദ്ധിപ്പിക്കുകയും ഓരോ ജോബിനെയും സാവധാനത്തിലാക്കുകയും ചെയ്യുന്നു. ഒരു പൈപ്പ്‌ലൈനിനുള്ളിൽ ഇത് നിർബന്ധമായും ഉപയോഗിക്കേണ്ടി വന്നാൽ, സ്ട്രക്ചറൽ ചെക്കുകൾക്കായി (structural checks) ഇതിലെ ഹ്യൂറിസ്റ്റിക് മെട്രിക്സുകൾ (heuristic metrics) മാത്രം ഉപയോഗിക്കുക. എങ്കിലും, നിങ്ങൾ ഫ്രെയിംവർക്കിന്റെ അടിസ്ഥാന രൂപകൽപ്പനയ്‌ക്കെതിരെയാണ് പോരാടുന്നത്. ആഴ്ചകളോളം നീണ്ടുനിൽക്കുന്ന എക്സ്പിരിമെന്റുകൾ ലോഗ് ചെയ്യാനും താരതമ്യം ചെയ്യാനുമാണ് MLflow ആഗ്രഹിക്കുന്നത്. എന്നാൽ ഒരു മെർജ് ക്യൂവിന് ഒരു മിനിറ്റിൽ താഴെ സമയം കൊണ്ട് ഒരു തീരുമാനം വേണം.

ഗേറ്റിംഗിനായുള്ള പ്രായോഗിക നിയമങ്ങൾ

ഈ പരീക്ഷണത്തിൽ നിന്ന് മറ്റൊന്നും ലഭിച്ചില്ലെങ്കിൽ പോലും, ഈ മൂന്ന് നിയമങ്ങൾ മാത്രം ഓർത്തുവെക്കുക.

ഒന്നാമതായി, വൈബ് (vibe) അല്ല, സ്ട്രക്ചർ (structure) ആണ് ഗേറ്റ് ചെയ്യേണ്ടത്. ഒരു ഔട്ട്പുട്ട് സാധുവായ JSON ആണെന്ന് നിങ്ങൾക്ക് ഉറപ്പാക്കാം. അതിൽ ആവശ്യമായ കീകൾ (keys) ഉണ്ടെന്ന് ഉറപ്പാക്കാം. ഒരു ക്ലാസിഫിക്കേഷൻ ലേബൽ അനുവദനീയമായ ഒരു എനത്തിൽ (enum) ഉൾപ്പെടുന്നുണ്ടെന്ന് ഉറപ്പാക്കാം. ഈ പരിശോധനകൾ വേഗതയുള്ളതും ചിലവ് കുറഞ്ഞതും നിശ്ചിതവുമായവയാണ് (deterministic). ഒരു സമ്മറി 'സൗഹൃദപരമാണോ' എന്നോ അല്ലെങ്കിൽ ഒരു റീറൈറ്റിംഗ് 'സർഗ്ഗാത്മകമാണോ' എന്നോ നിങ്ങൾക്ക് വിശ്വസനീയമായി ഉറപ്പാക്കാൻ കഴിയില്ല. അത്തരം ഗുണങ്ങൾ മനുഷ്യന്റെ പരിശോധനയ്ക്കോ (human review) അല്ലെങ്കിൽ കാലാകാലങ്ങളിൽ നടത്തുന്ന ബാച്ച് ഇവാലുവേഷനോ (batch evaluation) വേണ്ടതാണ്, ഓട്ടോമേറ്റഡ് ഗേറ്റുകൾക്കല്ല.

രണ്ടാമതായി, മാറ്റമില്ലാത്ത ഇൻപുട്ടിന് ഒരു സ്കോറിൽ വ്യത്യാസം വന്നാൽ, ഉടൻ തന്നെ അതിന്റെ പദവി കുറയ്ക്കുക. ഒരേ ആർട്ടിഫാക്റ്റിന് (artifact) തന്നെ രണ്ട് തവണ നിങ്ങളുടെ ഇവാലുവേഷൻ സ്യൂട്ട് പ്രവർത്തിപ്പിക്കുക. ഏതെങ്കിലും മെട്രിക് 'പാസ്' (pass) എന്നതിൽ നിന്ന് 'ഫെയിൽ' (fail) ആയി മാറിയാൽ, മെർജ് തടയാനുള്ള അവകാശം അതിന് നഷ്ടമായി എന്ന് കരുതുക. വ്യതിയാനങ്ങൾ (variance) പ്രതീക്ഷിക്കാവുന്നതും സഹിക്കാവുന്നതുമായ ഒരു അഡ്വൈസറി ഡാഷ്‌ബോർഡിലേക്ക് (advisory dashboard) അതിനെ മാറ്റുക.

മൂന്നാമതായി, എക്സിറ്റ് കോഡിനെ (exit code) ബഹുമാനിക്കുക. ചുവന്ന ബാനറുള്ള മനോഹരമായ ഒരു HTML റിപ്പോർട്ട് മെർജ് തടയില്ല. എന്നാൽ നോൺ-സീറോ എക്സിറ്റ് കോഡ് (nonzero exit code) അത് തടയും. നിങ്ങളുടെ ഇവാലുവേഷൻ ടൂൾ നിങ്ങളുടെ CI പ്ലാറ്റ്‌ഫോമിന്റെ സ്വാഭാവിക ഭാഷ സംസാരിക്കുന്നതായിരിക്കണം. സ്റ്റാൻഡേർഡ് ഔട്ട് (Standard out) മനുഷ്യർക്ക് വേണ്ടിയുള്ളതാണ്. എക്സിറ്റ് കോഡുകൾ യന്ത്രങ്ങൾക്കുള്ളതാണ്.

സംഗ്രഹം

LLM അധിഷ്ഠിത ആപ്ലിക്കേഷനുകൾ എങ്ങനെ പരിശോധിക്കണം എന്ന് കണ്ടെത്താനുള്ള പ്രാരംഭ ഘട്ടത്തിലാണ് നമ്മൾ. ഇവാലുവേഷനെ ഒരു മനുഷ്യന്റെ ഗ്രേഡിംഗ് രീതി പോലെ (nuanced, contextual, and slightly subjective) കാണാനുള്ള പ്രലോഭനം നമുക്കുണ്ടാകാം. അത് ഒരു റിസർച്ച് പേപ്പറിൽ പ്രവർത്തിക്കും, എന്നാൽ ഒരു മെർജ് ക്യൂവിൽ അത് പരാജയപ്പെടും.

എട്ട് മാസത്തെ പ്രൊഡക്ഷൻ ട്രാഫിക്കിന് ശേഷം, എന്റെ പൈപ്പ്‌ലൈൻ ഇപ്പോൾ സർവീസുകൾക്കിടയിലുള്ള സ്ട്രക്ചറൽ, സ്കീമ അസർഷനുകൾക്കായി (structural and schema assertions) Promptfoo-ഉം, പാസ്-ഫെയിൽ കണ്ടീഷനുകളുമായി കൃത്യമായി പൊരുത്തപ്പെടുന്ന പൈത്തൺ സൈഡ് ബിഹേവിയറൽ ചെക്കുകൾക്കായി (Python-side behavioral checks) DeepEval-ഉം ഉപയോഗിക്കുന്നു. മറ്റുള്ളവയെല്ലാം നൈറ്റ്ലി ഡാഷ്‌ബോർഡുകളിലേക്ക് റിപ്പോർട്ട് ചെയ്യുന്നു. ക്യൂ ഇപ്പോൾ സ്ഥിരതയുള്ളതാണ്. സിഗ്നൽ വ്യക്തമാണ്. ഒരു 'റെഡ് ബിൽഡ്' (red build) ടീമിന് വീണ്ടും വിശ്വാസ്യത നൽകുന്നു.

നിങ്ങളുടെ ഗേറ്റിൽ കൂടുതൽ മെട്രിക്സുകൾ ആവശ്യമില്ല. ഓരോ തവണയും സത്യം പറയുന്ന കുറഞ്ഞ മെട്രിക്സുകൾ മതി.

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.