वह इवैल हार्नेस जिससे मैं बिना डर के AI एजेंट शिप करता हूँ

विषय-सूची

जून 2026 में अपडेट किया गया।

संक्षेप: किसी लाइव एजेंट पर मैं प्रॉम्प्ट बदल सकता हूँ या मॉडल अदल-बदल सकता हूँ और साँस रोके बिना — इसकी वजह एक ही है: एक इवैल हार्नेस। ग्रेडेड टेस्ट केस का एक तय सेट, अपने आप स्कोर किया गया — जहाँ मैं लिख सकता हूँ वहाँ कठोर असर्शन्स, और जहाँ नहीं वहाँ एक LLM जज — हर बदलाव से पहले चलाया गया। स्कोर टिका रहे, मैं शिप करता हूँ। स्कोर गिरे, तो नहीं। टेस्ट सेट सिंथेटिक नहीं है; यह असली प्रोडक्शन विफलताओं से बनाया जाता है, इसलिए हर बग एक स्थायी रिग्रेशन टेस्ट बन जाता है।

ऑपरेटर का नज़रिया: 100 से ज़्यादा एजेंटों में, जिन्हें मैं भरोसे के साथ छूता हूँ और जिनसे मैं डरता हूँ — उनके बीच फ़र्क यही है कि उनमें इवैल हैं या नहीं। इवैल हार्नेस न होने का मतलब है हर प्रॉम्प्ट छेड़छाड़ एक जुआ है। एक इवैल हार्नेस “मुझे लगता है यह बेहतर है” को “यह नापने लायक 4 अंक बेहतर है और इसने कुछ नहीं तोड़ा” में बदल देता है। पूरा ताला यही खुलता है।

आप बिना टेस्ट के कोड शिप नहीं करेंगे। लोग बिना इवैल के लगातार एजेंट शिप करते हैं, और फिर हैरान होते हैं कि एक “नन्हीं प्रॉम्प्ट छेड़छाड़” ने प्रोडक्शन क्यों तोड़ दिया। इवैल हार्नेस ग़ैर-नियतात्मक सॉफ़्टवेयर के लिए टेस्ट सूट है। यह रही वह जिसे मैं सचमुच चलाता हूँ।

असली विफलताओं से बने टेस्ट सेट से शुरू करें

हार्नेस अपने टेस्ट केस जितना ही अच्छा होता है, और सबसे अच्छे टेस्ट केस प्रोडक्शन से आते हैं, आपकी कल्पना से नहीं। हर बार जब कोई एजेंट असल दुनिया में विफल होता है, मैं ठीक वही इनपुट पकड़ लेता हूँ (मैं हर रन को एक ट्रेस ID के साथ लॉग करता हूँ — देखें प्रोडक्शन में एजेंट को डीबग कैसे करें) और उसे एक इवैल केस में बदल देता हूँ:

interface EvalCase {
  id: string;
  input: AgentInput;        // ठीक वही प्रोडक्शन इनपुट
  expected?: string;        // ग्राउंड ट्रुथ, जब कोई हो
  assertions: Assertion[];  // कठोर जाँचें जो पास होनी ही चाहिए
  rubric?: string;          // LLM जज के लिए, जब आउटपुट खुला-छोर हो
}

यहाँ दो अभ्यास मायने रखते हैं। प्रोडक्शन से खींचें, ताकि आपके इवैल वही टेस्ट करें जो सचमुच टूटता है, न कि वह जो आपने अनुमान लगाया था। और पूरे दायरे को ढकें — सुखद रास्ता, किनारे के मामले, प्रतिकूल इनपुट, और वे खाली/विकृत इनपुट जो चुपचाप विफलताएँ पैदा करते हैं। अच्छी तरह चुने गए 30 से 50 केस का टेस्ट सेट 500 आलसी केसों से कहीं ज़्यादा पकड़ता है। मैं 40 ऐसे केस रखना पसंद करूँगा जो हर एक किसी असली विफलता-तरीके को दर्शाते हों, बजाय हज़ार ऐसे जो सब एक ही आसान रास्ता टेस्ट करते हों।

पहले असर्शन्स से स्कोर करें, फिर एक LLM जज से

हर आउटपुट को स्कोर करने के लिए मॉडल की ज़रूरत नहीं होती। मैं सबसे सस्ते स्कोरर की ओर बढ़ता हूँ जो काम कर जाए।

हर संरचित चीज़ के लिए कठोर असर्शन्स। क्या आउटपुट वैध JSON के रूप में पार्स होता है? क्या उसमें ज़रूरी फ़ील्ड है? क्या निकाली गई तारीख दायरे में है? क्या उसने सही आर्ग्युमेंट्स के साथ सही टूल बुलाया? ये नियतात्मक, मुफ़्त, और दो-टूक हैं — जितने लिख सकें, उतने लिखें।

const assertions: Assertion[] = [
  (out) => isValidJSON(out),
  (out) => parse(out).category in ALLOWED_CATEGORIES,
  (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1,
];

खुले-छोर बाक़ी हिस्से के लिए एक LLM जज — लहजा, उपयोगिता, “क्या इसने सचमुच सवाल का जवाब दिया”। यहाँ आप किसी मॉडल को इनपुट, आउटपुट और एक रुब्रिक देते हैं, और स्कोर करने को कहते हैं। दो नियम जज को ईमानदार रखते हैं: रुब्रिक को विशिष्ट बनाएँ (वर्णित एंकरों वाला 1–5 पैमाना “गुणवत्ता आँको” से बेहतर है), और जज के रूप में एक मज़बूत मॉडल इस्तेमाल करें — आँकना एक तर्क-कार्य है, इसलिए यह वह जगह है जहाँ मैं ख़ुशी से Sonnet का दाम चुकाता हूँ, भले ही एजेंट ख़ुद लागत के गणित के अनुसार Haiku पर चल रहा हो। धुँधली रुब्रिक या कमज़ोर जज आपको ऐसा शोर देता है जो संकेत जैसा दिखता है।

हर बदलाव से पहले हार्नेस चलाएँ

हार्नेस एक सवाल का जवाब देने के लिए मौजूद है: क्या इस बदलाव ने एजेंट को बेहतर बनाया या बदतर? इसलिए मैं इसे हर प्रॉम्प्ट संपादन, मॉडल अदला-बदली, या टूल बदलाव से पहले चलाता हूँ।

# main पर बेसलाइन
npm run eval -- --suite=booking-agent > baseline.json

# बदलाव करें, फिर दोबारा चलाएँ
npm run eval -- --suite=booking-agent > candidate.json

# तुलना करें
npm run eval:diff baseline.json candidate.json

डिफ़ कुल स्कोर, हर केस का पास/फेल, और — सबसे अहम — कौन-से ख़ास केस रिग्रेस हुए यह दिखाता है। एक कुल स्कोर जो तब ऊपर चढ़ता है जब तीन केस चुपचाप टूट रहे हों, सुधार नहीं है; यह एक सौदा है जिसे मैं देखना और मंज़ूर करना चाहता हूँ, ऐसा नहीं जो चुपके से निकल जाए। हर केस के डिफ़ पर नज़र रखना ही वह तरीका है जिससे आप “एक चीज़ ठीक की, दो और तोड़ दीं” से बचते हैं — वही विफलता-तरीका जो लोगों को अपने ही प्रॉम्प्ट से डरा देता है।

एक रिग्रेशन गेट लगाएँ और उसे रोकने दें

जब आप हार्नेस पर भरोसा कर लें, तो उसे एक गेट के रूप में प्रोडक्शन तक के रास्ते में जोड़ दें। मेरा नियम दो-टूक है: जो बदलाव स्कोर को बेसलाइन सीमा से नीचे गिरा दे, वह शिप नहीं होता। “बाद में देख लूँगा” नहीं — वह रोक दिया जाता है, ठीक एक विफल CI टेस्ट की तरह।

const PASS_THRESHOLD = 0.90; // 90% केस पास होने चाहिए
if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) {
  throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`);
}

यही वह चीज़ है जो इवैल को एक “अच्छा-हो-तो-सही” से उस चीज़ में बदल देती है जो आपको तेज़ चलने देती है। गेट ही “बिना डर के शिप करना” को शब्दशः सच बनाता है: किसी बुरे बदलाव का सबसे बुरा हाल एक लाल इवैल रन है, प्रोडक्शन घटना नहीं। और क्योंकि हर बार कुछ टूटने पर टेस्ट सेट बढ़ता है, गेट समय के साथ अपने-आप सख़्त और ज़्यादा सुरक्षात्मक होता जाता है।

स्कोरिंग में ग़ैर-नियतात्मकता का हिसाब रखें

एक बारीकी जो लोगों को गिरा देती है: एक ही इनपुट अलग-अलग रन में अलग स्कोर पा सकता है क्योंकि मॉडल अलग तरह से सैंपल करता है। अगर आप हर केस को एक बार चलाते हैं, तो आपको भूतिया रिग्रेशन दिखेंगे — एक केस जो “टूटा” वह असल में महज़ सैंपलिंग शोर है।

दो उपाय। विचलन घटाने के लिए इवैल को temperature: 0 पर चलाएँ (यह उसे पूरी तरह ख़त्म नहीं करेगा)। और जिन केसों को आपने टिमटिमाते देखा हो, उन्हें N बार चलाएँ और पास दर लें, एक अकेला पास/फेल नहीं। जो केस 10 में से 9 बार पास होता है वह उससे बेहतर हालत में है जो 10 में से 5 बार पास होता है, भले ही दोनों एक अकेला हरा रन दिखा सकें। यह वही “किस्से से ज़्यादा मात्रा” वाला सिद्धांत है जो मैं रुक-रुक कर होने वाली विफलताओं को डीबग करते समय इस्तेमाल करता हूँ — एक रन एक राय है, पचास रन डेटा हैं।

प्रोडक्शन मॉनिटरिंग से लूप बंद करें

इवैल हार्नेस ज्ञात केसों के विरुद्ध टेस्ट करता है। प्रोडक्शन नए केस फेंकता है। तो लूप यह है: लाइव व्यवहार पर नज़र रखें, एक नया विफलता-तरीका पकड़ें, उसे एक इवैल केस में बदलें, ठीक करें, और अब वह स्थायी रूप से सुरक्षित है। मॉनिटरिंग का पहलू — लाइव ट्रैफ़िक पर सफलता दर, आउटपुट वैधता, और प्रति रन लागत ट्रैक करना — वह है जिसे मैं मैं कैसे नापता हूँ कि कोई AI एजेंट सचमुच काम कर रहा है या नहीं में बताता हूँ। इवैल और मॉनिटरिंग एक ही तंत्र के दो हिस्से हैं: मॉनिटरिंग बग ढूँढती है, इवैल यह पक्का करती हैं कि वे मरे रहें।

वह फ़ीडबैक लूप ही असली उत्पाद है। कोई भी अकेला इवैल सेट बासी पड़ जाता है; पर एक प्रक्रिया जो हर प्रोडक्शन विफलता को एक स्थायी टेस्ट में बदल देती है, हर हफ़्ते मज़बूत होती जाती है। इसी तरह एक एजेंट “छूने में डरावना” से उस चीज़ में बदल जाता है जिसे मैं किसी शुक्रवार की दोपहर बिना झिझके रीफ़ैक्टर कर दूँ।

अक्सर पूछे जाने वाले सवाल

एक AI एजेंट इवैल सेट में क्या जाता है?

असली प्रोडक्शन इनपुट को ग्रेडेड केसों में बदला गया — सुखद रास्ता, किनारे के मामले, प्रतिकूल और विकृत इनपुट — हर एक के साथ कठोर असर्शन्स और, खुले-छोर आउटपुट के लिए, एक LLM-जज रुब्रिक। असल विफलताओं से लिए गए 30 से 50 केस सैकड़ों सिंथेटिक केसों को मात देते हैं जो सब आसान रास्ता टेस्ट करते हैं।

क्या मुझे एजेंट आउटपुट आँकने के लिए LLM इस्तेमाल करना चाहिए?

जहाँ भी आउटपुट संरचित हो (वैध JSON, सही फ़ील्ड, सही टूल कॉल) वहाँ कठोर असर्शन्स इस्तेमाल करें — वे मुफ़्त और नियतात्मक हैं। लहजे और उपयोगिता जैसी खुले-छोर ख़ूबियों के लिए एक LLM जज बचाकर रखें, एक विशिष्ट रुब्रिक और एक मज़बूत जज मॉडल के साथ, ताकि आपको संकेत मिले, शोर नहीं।

मैं किसी प्रॉम्प्ट बदलाव को प्रोडक्शन चुपचाप तोड़ने से कैसे रोकूँ?

हर बदलाव से पहले इवैल हार्नेस चलाएँ और एक बेसलाइन के विरुद्ध डिफ़ करें, सिर्फ़ कुल स्कोर नहीं, बल्कि हर केस के रिग्रेशन पर नज़र रखें। फिर परिणाम पर डिप्लॉय को गेट करें ताकि कोई भी बदलाव जो बेसलाइन सीमा से नीचे गिरे, एक विफल टेस्ट की तरह रोक दिया जाए।

इवैल में ग़ैर-नियतात्मकता को मैं कैसे संभालूँ?

विचलन घटाने के लिए तापमान 0 पर चलाएँ, और जो केस टिमटिमाते हैं उन्हें कई बार चलाएँ और एक अकेले रन के बजाय पास दर से स्कोर करें। जो केस 10 में से 9 बार पास होता है वह उससे ज़्यादा स्वस्थ है जो 10 में से 5 बार पास होता है, भले ही एक अकेला रन दोनों को हरा दिखाए।