Eval एक स्थायी प्रणाली के रूप में, न कि launch checklist के रूप में

eval-at-launch trap

अधिकांश टीमें evals को launch checklist की तरह treat करती हैं। 20 test cases लिखो, run करो, model ship करो, आगे बढ़ो। छह महीने बाद model चुपचाप degraded हो जाता है, टीम को पता नहीं चलता, और customer escalation वह सामने लाता है जो हफ्तों पहले catch हो जाना चाहिए था।

सही mental model: evals एक permanent system हैं। आपके test suite की तुलना में monitoring stack के ज्यादा करीब।

व्यवहार में permanent का मतलब क्या है

Eval suites साप्ताहिक बढ़ते हैं। हर production failure जो हम catch करते हैं, suite में permanent case बन जाती है। Suite हर prompt change, हर model change के खिलाफ चलता है, और production output के खिलाफ साप्ताहिक regardless चलता है।

Eval fail होने पर merge block हो जाता है। समय के साथ drift model review trigger करता है। Suite के owner (हां, named owner) की reporting engineering org के बाकी हिस्सों के समान review cadence पर होती है।

20-case minimum, और 200-case ceiling

20 hand-picked cases 200 synthetic cases से बेहतर हैं। वे 20 happy path, common edge cases, refusal patterns, और वे patterns cover करते हैं जिन्हें आप break नहीं कर सकते। 20 से कम में आप वास्तव में testing नहीं कर रहे। ~200 से ऊपर आप agent पर खुद से ज्यादा cycles eval maintenance पर खर्च कर रहे हैं।

जो healthy distribution हम client projects में देखते हैं: 60% real anonymized production cases, 30% adversarial / edge cases जो हमने लिखे, 10% regression cases जो past bugs से निकाले गए।

LLM-as-judge — कहां काम करता है, कहां break होता है

LLM-as-judge scale पर evals score करने का एकमात्र तरीका है। अधिकांश criteria (faithfulness, refusal correctness, tone match) के लिए यह काफी अच्छा काम करता है।

यह तीन चीजों पर break होता है:

1. Subtle factual accuracy. जब ground truth को domain expertise चाहिए जो judge model के पास नहीं है, तो scores noisy हो जाते हैं।
2. Subjective quality. "क्या यह पर्याप्त tactful है?" — humans असहमत होते हैं, और judge model अक्सर उस पक्ष से सहमत होता है जिसने prompt phrase किया।
3. Multi-turn coherence. Judge models पूरी conversations की तुलना में individual turns को बेहतर score करते हैं।

Fix: close calls पर human review। LLM-as-judge से 80%+ cases automatically score करें, bottom decile को human के पास route करें। वहीं tuning judgment रहता है।

Eval suite के अंदर cost telemetry

हर eval run token cost log करता है। आप सीखते हैं कि हर test case की कितनी cost आती है और कौन से average को ऊपर खींच रहे हैं। समय के साथ आप "इस prompt change ने quality बेहतर की लेकिन cost तीन गुना कर दिया" को bill आने से पहले spot कर लेते हैं।

हम अब हर eval suite में जो ship करते हैं, इसे build कर देते हैं। यह defensive measure के रूप में शुरू हुआ और useful product-economics signal बन गया।

हमारे जाने के बाद इसका owner कौन है

यह वह सवाल है जो हम हर handoff में पूछते हैं। अगर जवाब है "हम figure out कर लेंगे", तो हमें पता है eval suite atrophy हो जाएगा। अगर एक named human है जिसके calendar पर eval review है, तो यह आमतौर पर survive करता है।

हमने SOW में named owner लिखना शुरू कर दिया है। हमारी तरफ से deliverable के रूप में नहीं — client की तरफ से commitment के रूप में। जो clients pushback करते हैं, वे वही हैं जिनके evals मर जाएंगे। हम यह signing से पहले लाते हैं, बाद में नहीं।