ईवल्स (Evals) के साथ बुराइयों से लड़ें!

बेंचमार्क्स सिर्फ बेंचमार्क्स को मापते हैं। आपके सिस्टम को अपने मापदंडों की जरूरत है।

हर नया मॉडल बेंचमार्क्स का टक्सीडो (tuxedo) पहनकर आता है।

MMLU: 92.4%। HumanEval: 87.2%। LLeMU: 88.7%। MATH: 73.6%। AGI: 127%!

फिर भी, AI के साथ प्रोसेस और प्रोडक्ट बनाने वाले 99% व्यवसायों के लिए, इनमें से कुछ भी मायने नहीं रखता।

क्या मायने रखता है? आपके वर्कलोड (workloads) कैसा प्रदर्शन कर रहे हैं? वे बेहतर हो रहे हैं या बदतर? यह जानने का एकमात्र समझदारी भरा तरीका ईवल्स (Evals - LLMs के लिए टेस्ट) लिखना है जो आपके सिस्टम के विशिष्ट कार्यों, डेटा और विफलता के तरीकों को दर्शाते हैं।

बेंचमार्क्स झूठ नहीं बोल रहे हैं। वे किसी और के सवाल का जवाब दे रहे हैं।

“वाइब्स-आधारित मूल्यांकन” (Vibes-Based Evaluation) की असली कीमत

मानक दृष्टिकोण: मॉडल में बदलाव लाएं, शिकायत चैनलों पर नज़र रखें और अगर हंगामा ज़्यादा हो जाए तो उसे वापस रोलबैक कर दें।

यह लगभग हर दिलचस्प चीज़ को छोड़ देता है:

आप केवल शोर मचाने वाली विफलताओं को पकड़ पाते हैं। वे उपयोगकर्ता जिन्हें विश्वास के साथ गलत उत्तर मिलता है और उन्हें इसका एहसास नहीं होता? वे शांत रहते हैं। वे उपयोगकर्ता जिन्हें खराब उत्तर मिलता है और वे फीचर का उपयोग बंद कर देते हैं? वे भी शांत रहते हैं। सपोर्ट टिकट और एरर रेट्स क्वालिटी में आने वाली गिरावट का केवल एक छोटा सा हिस्सा ही पकड़ पाते हैं।

आप सुधार और गिरावट के बीच अंतर नहीं कर सकते। यदि नया मॉडल टास्क A में बेहतर है और टास्क B में खराब, तो B के बारे में शिकायतें सामान्य “AI खराब हो गया है” फीडबैक जैसी ही दिखती हैं। आपको पता ही नहीं चलता कि क्या ठीक करना है।

आप अपने उपयोगकर्ताओं को टेस्ट इंफ्रास्ट्रक्चर के रूप में उपयोग कर रहे हैं। उन्होंने इसके लिए साइन अप नहीं किया था।

ईवल स्पेक्ट्रम (और जहाँ अधिकांश टीमें गलती करती हैं)

मूल्यांकन के तरीके “तेज़ लेकिन कमज़ोर” से लेकर “महंगे लेकिन मान्य” तक के स्पेक्ट्रम पर होते हैं।

LLM-एज़-जज (LLM-as-judge) वर्तमान में सबका पसंदीदा है: एक शक्तिशाली मॉडल से दूसरे मॉडल के आउटपुट को ग्रेड देने के लिए कहें। तेज़, स्केलेबल, सस्ता। समस्या: यह ग्रेडर मॉडल के पूर्वाग्रहों (biases) को शामिल करता है, इसे चकमा दिया जा सकता है, और यह एक चक्रीय निर्भरता (circular dependency) बनाता है। यदि आप GPT-5 के आउटपुट को ग्रेड देने के लिए GPT-5 का उपयोग करते हैं, तो आप “GPT-5, GPT-5 के साथ कितना सहमत है” जैसा कुछ माप रहे हैं। यह कुछ तो है, लेकिन वह नहीं जो आप सोच रहे हैं।

मानव ईवल (Human eval) गोल्ड स्टैंडर्ड है जिसे हर कोई छोड़ना चाहता है। मनुष्यों से आउटपुट का मूल्यांकन करवाना महंगा, धीमा, मूल्यांकनकर्ताओं के बीच असंगत और शेड्यूल करने में कष्टदायक होता है। लेकिन यह एकमात्र चीज़ है जो यह पुष्टि करती है कि क्या आपका सिस्टम वास्तविक मनुष्यों के लिए उपयोगी है।

टास्क-विशिष्ट ऑटोमेटेड चेक वे हैं जहाँ अधिकांश टीमों को अधिक समय बिताना चाहिए। वे ग्लैमरस नहीं हैं, लेकिन वे तेज़, नियतात्मक (deterministic) हैं, और आपके सिस्टम में जो मायने रखता है उससे जुड़े हैं।

वास्तव में क्या काम करता है

1. शिप करने से पहले विफलता को परिभाषित करें

मॉडल या प्रॉम्प्ट बदलने से पहले, लिखें कि “खराब” कैसा दिखता है। विशेष रूप से।

यह नहीं कि “आउटपुट सटीक होना चाहिए।” यह कोई टेस्ट नहीं है। बल्कि ऐसा कुछ:

• स्ट्रक्चर्ड JSON आउटपुट बिना एरर के पार्स होना चाहिए
• रिस्पॉन्स के सभी उद्धरण (citations) प्राप्त संदर्भ (context) में शब्दशः दिखने चाहिए
• रिस्पॉन्स में प्रतिस्पर्धी प्रोडक्ट के नामों का उल्लेख नहीं होना चाहिए
• SQL क्वेरी सिंटैक्टिक रूप से मान्य होनी चाहिए और केवल उन टेबल को संदर्भित करनी चाहिए जो स्कीमा में मौजूद हैं
• सेंटिमेंट क्लासिफिकेशन मौजूदा टेस्ट सेट पर 3% से अधिक बार पॉजिटिव से नेगेटिव में नहीं बदलना चाहिए

आप इन्हें प्रोग्रामेटिक रूप से चेक कर सकते हैं। किसी जज मॉडल की आवश्यकता नहीं है।

ईवल हार्नेस: नियतात्मक जांच (deterministic checks)

type EvalResult = { passed: boolean; reason?: string };

const evals: Record<string, (output: string, context: EvalContext) => EvalResult> = {
  // JSON पार्स होना चाहिए
  validJson: (output) => {
    try {
      JSON.parse(output);
      return { passed: true };
    } catch (e) {
      return { passed: false, reason: `Invalid JSON: ${e.message}` };
    }
  },

  // कोई काल्पनिक उद्धरण नहीं — हर दावे को संदर्भ में दिखना चाहिए
  groundedCitations: (output, { retrievedChunks }) => {
    const claims = extractCitations(output);
    const ungrounded = claims.filter(
      (claim) => !retrievedChunks.some((chunk) => chunk.includes(claim))
    );
    return ungrounded.length === 0
      ? { passed: true }
      : { passed: false, reason: `Ungrounded claims: ${ungrounded.join(', ')}` };
  },

  // रिस्पॉन्स की लंबाई की जांच — ट्रंकेशन या अनावश्यक रूप से लंबी जनरेशन को पकड़ें
  reasonableLength: (output) => {
    const words = output.split(/\s+/).length;
    return words >= 10 && words <= 2000
      ? { passed: true }
      : { passed: false, reason: `Word count ${words} out of bounds` };
  },
};

2. अपने सबसे बुरे दिनों से एक ‘गोल्डन सेट’ (Golden Set) बनाएं

आपका सबसे अच्छा मूल्यांकन डेटा वह शर्मनाक चीज़ें हैं: वे आउटपुट जिनके कारण किसी ने टिकट फाइल किया, मतिभ्रम (hallucination) का स्क्रीनशॉट लिया, या चुपचाप फीचर का उपयोग करना बंद कर दिया।

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

यह पहली बार में मैन्युअल लगता है। छह महीने बाद, आपके पास एक ऐसा टेस्ट सूट होगा जिसे कोई भी सार्वजनिक बेंचमार्क चकमा नहीं दे सकता, क्योंकि हर केस आपके अपने विफलता इतिहास से आया है।

गोल्डन केस का आकार

interface GoldenCase {
  id: string;
  input: string;
  context: Record<string, unknown>;
  expectedBehavior: {
    mustContain?: string[];
    mustNotContain?: string[];
    structureCheck?: (output: string) => boolean;
    minSimilarityToReference?: number; // रेफरेंस उत्तर के साथ कोसाइन समानता (cosine similarity)
  };
  sourceIncident?: string; // बग रिपोर्ट या टिकट का लिंक
}

3. रिग्रेशन टेस्टिंग, केवल एक्सेप्टेंस टेस्टिंग नहीं

अधिकांश टीमें ईवल्स केवल तभी चलाती हैं जब वे मॉडल बदलने पर विचार कर रही होती हैं। यह एक्सेप्टेंस टेस्टिंग है: “क्या यह नई चीज़ काफी अच्छी है?”

आपको रिग्रेशन टेस्टिंग की भी आवश्यकता है: “क्या इसने कुछ ऐसा तोड़ दिया जो पहले काम कर रहा था?”

अपने गोल्डन सेट को हर प्रॉम्प्ट परिवर्तन पर चलाएं, न कि केवल मॉडल परिवर्तन पर। एक प्रॉम्प्ट जो ठीक काम कर रहा था, वह तब चुपचाप खराब हो सकता है जब आप एक नया टूल जोड़ते हैं, RAG रिट्रीवल रणनीति बदलते हैं, या अपने संदर्भ टेम्पलेट को अपडेट करते हैं। आपको बेसलाइन के बिना पता नहीं चलेगा। Langfuse जैसे टूल ईवल स्कोर को प्रोडक्शन ट्रेसेस से जोड़ते हैं ताकि गिरावट डैशबोर्ड में दिखाई दे, न कि केवल इंसिडेंट रिपोर्ट में।

async function compareModelVersions(
  goldenCases: GoldenCase[],
  baselinePipeline: Pipeline,
  candidatePipeline: Pipeline
) {
  const results = await Promise.all(
    goldenCases.map(async (tc) => {
      const [baseline, candidate] = await Promise.all([
        baselinePipeline.run(tc.input, tc.context),
        candidatePipeline.run(tc.input, tc.context),
      ]);

      return {
        id: tc.id,
        baselinePassed: runEvals(baseline, tc.expectedBehavior),
        candidatePassed: runEvals(candidate, tc.expectedBehavior),
        regression: /* baseline passed */ && /* candidate failed */,
        improvement: /* baseline failed */ && /* candidate passed */,
      };
    })
  );

  const regressions = results.filter((r) => r.regression);
  const improvements = results.filter((r) => r.improvement);

  console.log(`Regressions: ${regressions.length} / ${goldenCases.length}`);
  console.log(`Improvements: ${improvements.length} / ${goldenCases.length}`);

  if (regressions.length > 0) {
    console.error('Blocking regressions found:');
    regressions.forEach((r) => console.error(` - ${r.id}`));
  }

  return { regressions, improvements };
}

यदि कोई कैंडिडेट ज्ञात विफलताओं पर पीछे हटता है, तो अपग्रेड की बातचीत बहुत विशिष्ट हो जाती है: कौन से केस बेहतर हुए, कौन से टूटे, और क्या यह समझौता करने लायक है।

4. LLM-एज़-जज का उपयोग बिल्कुल एक चीज़ के लिए करें

LLM-एज़-जज ओपन-एंडेड आउटपुट के लिए उपयोगी है जहाँ कोई नियतात्मक सही उत्तर नहीं है: “क्या यह रिस्पॉन्स मददगार है?”, “क्या यह सारांश मुख्य बिंदुओं को सुरक्षित रखता है?”, “क्या यह स्पष्टीकरण शुरुआती व्यक्ति के लिए सही है?”

वहाँ इसका उपयोग करें। नियतात्मक उत्तरों के लिए इसका उपयोग न करें। जब आप इसका उपयोग करते हैं, तो ग्रेडिंग रूब्रिक (grading rubric) को स्पष्ट करें:

ईवल हार्नेस: रूब्रिक-आधारित जज

async function judgeHelpfulness(
  userQuery: string,
  modelResponse: string
): Promise<{ score: number; reasoning: string }> {
  const judgePrompt = `
आप एक ग्राहक सहायता रिस्पॉन्स का मूल्यांकन कर रहे हैं।

उपयोगकर्ता का प्रश्न: ${userQuery}
रिस्पॉन्स: ${modelResponse}

रिस्पॉन्स को 1-5 के पैमाने पर रेट करें:
5 = सटीक, कार्रवाई योग्य जानकारी के साथ सीधे प्रश्न का उत्तर देता है
4 = प्रश्न का उत्तर देता है लेकिन अधिक विशिष्ट या कार्रवाई योग्य हो सकता है
3 = प्रश्न को आंशिक रूप से संबोधित करता है; मुख्य जानकारी गायब है
2 = स्पर्शोन्मुख रूप से संबंधित (Tangentially related) है लेकिन प्रश्न का उत्तर नहीं देता
1 = विषय से हटकर, तथ्यात्मक रूप से गलत, या हानिकारक

JSON के साथ उत्तर दें: {"score": <number>, "reasoning": "<one sentence>"}
`;

  const result = await judgeModel.generate(judgePrompt);
  return JSON.parse(result);
}

एक स्पष्ट रूब्रिक मूल्यांकनकर्ता के विचरण (variance) को कम करता है, आपको व्याख्या योग्य आउटपुट देता है, और जज के गलत होने पर ऑडिट करना आसान बनाता है। Autoevals और Braintrust जैसी लाइब्रेरी सामान्य कार्यों के लिए पहले से बने रूब्रिक्स शिप करती हैं — खरोंच से अपना लिखने से पहले इन्हें देखना सार्थक है।

जानने लायक उपकरण

आपको यह सब खरोंच से बनाने की ज़रूरत नहीं है। कई उपकरणों ने ईवल इंफ्रास्ट्रक्चर की समस्या पर गंभीर प्रगति की है:

Braintrust — प्रयोग ट्रैकिंग, डेटासेट प्रबंधन और स्कोरिंग कार्यों के साथ पूर्ण ईवल प्लेटफॉर्म। ईवल रन को प्रॉम्प्ट, मॉडल और परिनियोजन (deployment) द्वारा व्यवस्थित करता है ताकि आप समय के साथ गुणवत्ता में अंतर देख सकें, न कि केवल रिलीज़ के दौरान। यह उनकी ओपन-सोर्स Autoevals लाइब्रेरी के साथ अच्छी तरह से जुड़ता है, जो सामान्य कार्यों (तथ्यात्मक सटीकता, उपयोगिता, विषाक्तता, शब्दार्थ समानता) के लिए पूर्व-निर्मित मॉडल-ग्रेडेड स्कोरिंग कार्य शिप करती है।

Langfuse — ओपन-सोर्स LLM ऑब्ज़र्वैबिलिटी जो आपके ऐप और आपके मॉडल के बीच बैठती है। हर कॉल को ट्रेस करती है, व्यक्तिगत स्पैन में ईवल स्कोर (मानव या स्वचालित) जोड़ती है, और प्रोडक्शन ट्रैफ़िक पर गुणवत्ता के रुझान को सतह पर लाती है। यदि आप एक अलग ईवल हार्नेस के बजाय ऑब्ज़र्वैबिलिटी और ईवल्स को एक ही टूल में चाहते हैं तो यह एक अच्छा विकल्प है।

Evalite — मैट पोकॉक द्वारा टाइपस्क्रिप्ट-नेटिव ईवल फ्रेमवर्क। लो सेरेमनी: एक कार्य को परिभाषित करें, एक स्कोरर को परिभाषित करें, इसे अपने मौजूदा टेस्ट सेटअप में चलाएं। उन टीमों को लक्षित करता है जो ईवल्स चाहते हैं जो एक अलग ML प्रयोग प्लेटफॉर्म के बजाय यूनिट टेस्ट की तरह महसूस हों।

promptfoo — प्रॉम्प्ट तुलना और रेड-टीमिंग पर केंद्रित CLI-फर्स्ट ईवल रनर। YAML के माध्यम से कॉन्फ़िगर करना आसान है, अधिकांश मॉडल प्रदाताओं के साथ एकीकृत होता है, और इसमें प्रॉम्प्ट इंजेक्शन और अन्य प्रतिकूल इनपुट का पता लगाने के लिए अंतर्निहित समर्थन है।

deepeval — बिल्ट-इन मेट्रिक्स (G-Eval, RAG फेथफुलनेस, आंसर रेलेवंसी, हैलुसिनेशन डिटेक्शन) की एक बड़ी लाइब्रेरी के साथ पायथन ईवल फ्रेमवर्क। RAG पाइपलाइनों के लिए उपयोगी जहाँ आप रिट्रीवल क्वालिटी के लिए विशिष्ट ग्रेडिंग चाहते हैं, न कि केवल जनरेशन क्वालिटी के लिए।

सही टूल आपके स्टैक पर निर्भर करता है और आप कहाँ से शुरू कर रहे हैं। फ्रेमवर्क के चुनाव से अधिक महत्वपूर्ण ईवल्स चलाने का अनुशासन है — लगातार, हर महत्वपूर्ण बदलाव पर।

असहज करने वाला हिस्सा

अधिकांश टीमें इसे छोड़ देती हैं क्योंकि यह शुरुआत में ही एक परेशान करने वाला सवाल पूछता है: यहाँ “अच्छा” कैसा दिखेगा?

एक नए AI फीचर के लिए यह वास्तव में कठिन है। यदि आप विश्वसनीयता की परवाह करते हैं तो यह गैर-वैकल्पिक भी है। जो टीमें भरोसेमंद AI शिप करती हैं, वे वही कर रही हैं जो वे किसी भी महत्वपूर्ण कोड पाथ के लिए करतीं: अपेक्षित व्यवहार को परिभाषित करना, उसका परीक्षण करना और उन परीक्षणों को निरंतर चलाना।

बेंचमार्क्स झूठ नहीं बोल रहे हैं। वे किसी और के सवाल का जवाब दे रहे हैं। उन्हें प्रोडक्ट रोडमैप के रूप में पढ़ना बंद करें और ऐसे टेस्ट लिखना शुरू करें जो आपके सिस्टम से मेल खाते हों।

आपके उपयोगकर्ता आपके डैशबोर्ड से पहले ध्यान देंगे। पहले टेस्ट सूट बनाएं।