मैंने एक बार एक prompt बदलाव ship किया जिसने मेरे support एजेंट को उस metric पर 4% बेहतर बनाया जिसे मैं देख रहा था, लेकिन टिकट असल में बंद करने की क्षमता 30% कम हो गई। Eval हरा था। यूज़र्स गुस्से में थे। तभी मुझे समझ आया कि ज़्यादातर एजेंट evals गलत चीज़ नापते हैं — वे यह नापते हैं कि आउटपुट सुनने में सही लगता है या नहीं, न कि एजेंट ने सही काम किया या नहीं।
अगर आप एजेंट बना रहे हैं और आपके evals बस कुछ "क्या response अच्छा दिखता है" जाँचें हैं जो किसी दूसरे मॉडल से score की जाती हैं, तो आपके पास evals नहीं हैं। आपके पास एक संख्या के साथ जुड़ा हुआ अनुमान है। यहाँ बताया गया है कि मैं AI एजेंट्स के लिए ऐसे evals कैसे लिखता हूँ जो वास्तव में regressions पकड़ते हैं।
व्यवहार पर assert करें, prose पर नहीं
सबसे बड़ा सुधार: अंतिम टेक्स्ट को grade करना बंद करें और एजेंट ने क्या किया उसे grade करना शुरू करें। क्या उसने सही tools को सही क्रम में, सही arguments के साथ call किया? क्या उसने उन files को modify किया जो करनी चाहिए थीं और बाकी को छोड़ दिया? ये जाँचे जा सकने वाले तथ्य हैं, राय नहीं।
एक coding एजेंट के लिए, मेरा eval summary नहीं पढ़ता। यह जाँचता है: क्या run के बाद test suite pass होता है, क्या एजेंट ने केवल scope की files को छुआ, क्या उसने lockfile edit करने से बचा। तीन boolean assertions। कहीं कोई LLM judge नहीं। ये कभी flake नहीं होते और जो failures मायने रखते हैं उन्हें पकड़ते हैं।
assert run_tests() == 0, "tests fail after agent run"
assert touched_files <= allowed_files, f"out of scope: {touched_files - allowed_files}"
assert "package-lock.json" not in touched_files
आखिरी वाला एक असली घटना से आया। एक एजेंट बार-बार "मददगार बनते हुए" lockfile regenerate करता था और CI तोड़ता था। एक assertion, फिर कभी नहीं हुआ।
सिर्फ endpoint नहीं, trajectory भी test करें
एजेंट बीच में fail होते हैं। अंतिम उत्तर किसी आपदा भरे रास्ते के बाद भाग्य से सही हो सकता है — छह redundant searches, garbage arguments वाला एक tool call जो संयोग से gracefully error हुआ, एक गलत मोड़ से वापसी। अगर आप केवल endpoint चेक करते हैं, तो आप उस trajectory के प्रति अंधे हैं जो एक छोटे से बदलाव से पूरी तरह fail हो सकती है।
इसलिए मैं हर event log करता हूँ और path पर assert करता हूँ। क्या उसने किसी ऐसे सवाल का जवाब देने से पहले search call किया जिसके लिए ताज़ी जानकारी चाहिए थी? क्या उसने दो से ज़्यादा redundant tool calls किए? क्या उसने किसी tool result पर is_error: true hit किया? आप बिना judge के trajectory score कर सकते हैं — ज़्यादातर यह event stream पर counting और pattern-matching है।
वैसे, यहाँ model behavior हाल ही में बदला है। नए Opus मॉडल tools को अधिक conservatively इस्तेमाल करते हैं। एक पुराने मॉडल पर pass होने वाला search-first assertion fail होना शुरू हो सकता है, एजेंट के worse होने की वजह से नहीं, बल्कि इसलिए कि वह अब context से जवाब देता है जहाँ उसे नहीं देना चाहिए। यही वह regression है जो trajectory eval पकड़ता है और output eval चूक जाता है।
जब आपको LLM judge की ज़रूरत हो, तो उसे pin करें
कुछ चीज़ों को वास्तव में judgment की ज़रूरत होती है — क्या tone सही था, क्या summary ने मुख्य बात पकड़ी, क्या explanation वाकई सही था। ठीक है। LLM judge इस्तेमाल करें। लेकिन judge को production code की तरह treat करें, क्योंकि वह है।
तीन नियम जो मैं कभी नहीं तोड़ता। एक: judge model और version pin करें। अगर आपका judge चुपचाप upgrade हो जाता है, तो आपके scores shift हो जाएंगे और आप एक ऐसे regression का पीछा करेंगे जो वास्तव में judge change था। दो: judge को एक concrete rubric दें, न कि "इसे 1-10 rate करें।" "क्या response एक specific file और line number cite करता है? हाँ/नहीं" हर बार vibe score को मात देता है। तीन: एक sample पर human labels के against judge को spot-check करें। जिस judge को आपने कभी audit नहीं किया वह अच्छे PR के साथ एक random number generator है।
यहाँ current models के लिए एक खास trap है। अगर आप judge को बताते हैं "केवल high-severity issues flag करें" या "conservative रहें," तो नए models इसे literally follow करते हैं — वे bugs ढूंढते हैं, फिर आपकी threshold से नीचे वाले report करने से मना कर देते हैं। आपका measured recall गिर जाता है और लगता है कि एजेंट regress हो गया जबकि असल में judge बस ज़्यादा आज्ञाकारी हो गया। Judge को confidence और severity के साथ सब कुछ report करने के लिए कहें, और downstream filter करें। Filtering को judging step से बाहर ले जाएं।
अपनी failures से eval set बनाएं
बैठकर test cases brainstorm न करें। आप वही लिखेंगे जो पहले से handle होते हैं। इसके बजाय, हर बार जब एजेंट production में गड़बड़ करे, वह exact scenario एक eval case बन जाती है। Lockfile incident, flip-flop loop, जब उसने stale context से जवाब दिया — हर एक अब एक permanent regression test है।
यह वह हिस्सा है जिसे लोग skip करते हैं क्योंकि यह glamorous नहीं है। लेकिन असली incidents से उगा eval set, दस brainstormed ones से बेहतर है। यह उस तरह से load-bearing है जो synthetic cases कभी नहीं होते, क्योंकि हर case एक ऐसा bug है जिसने वास्तव में आपको काटा।
हर prompt बदलाव पर उन्हें चलाएं
पूरा मतलब loop में है। आप prompt बदलते हैं, evals चलाते हैं, ship करने से पहले trajectory assertions देखते हैं। मेरी support-agent आपदा इसलिए हुई क्योंकि मैंने कुछ outputs देखे और अनुमान पर ship किया। अगर मेरे पास trajectory evals होते — "क्या यह वास्तव में resolve हुआ या बस resolved लगा" — तो वह 30% गिरावट किसी एक user तक पहुँचने से पहले ही लाल हो जाती।
Evals कोई quality gate नहीं हैं जो आप अंत में जोड़ते हैं। ये "मुझे लगता है यह prompt बेहतर है" और "यह prompt बेहतर है" के बीच एकमात्र चीज़ हैं। एक engineering है। दूसरा lab coat पहना हुआ अनुमान।
अपने घावों से उगाएं। एजेंट ने क्या किया उस पर assert करें। अपने judge को pin करें। और कभी भी, कभी भी prompt बदलाव को अनुमान पर ship न करें।