AI सिस्टम्स का मूल्यांकन (Evaluation)मध्यमपाठ 2236 मिनट का पाठ

प्रॉम्प्ट्स और मॉडल्स के लिए रिग्रेशन टेस्ट

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

पाठ वीडियो में

60 सेकंड में

प्रॉम्प्ट्स और मॉडल्स के लिए रिग्रेशन टेस्ट

प्रॉम्प्ट में एक छोटा सा बदलाव या मॉडल अपग्रेड उन चीज़ों को चुपके से बिगाड़ सकता है जो पहले ठीक काम करती थीं। हर बदलाव पर अपना eval सुइट अपने-आप (ऑटोमैटिकली) चलाएं, वो भी…

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

eval सुइट में क्या शामिल होता है

जांच का प्रकारउदाहरणस्कोरिंग
डिटर्मिनिस्टिकआउटपुट ज़रूरी फ़ील्ड्स के साथ सही JSON है; जवाब में कोई फ़ोन नंबर नहीं हैपास या फ़ेल, बिल्कुल पक्के नियम
रेफ़रेंस-आधारितजवाब में रेफ़रेंस से सही डेडलाइन शामिल हैmust_include / must_not लिस्ट्स से मिलान करें
जज-आधारितरूब्रिक के अनुसार जवाब साफ़ और पूरा हैकैलिब्रेटेड LLM जज (पाठ 5)
सुरक्षारेड-टीम प्रॉम्प्ट्स को ख़ारिज किया जाता है; सामान्य रिक्वेस्ट्स को नहींदो सेट्स पर दरें (पाठ 9)
लागत और लेटेंसीप्रति केस औसत टोकन और समयबजट के भीतर रहना चाहिए

थ्रेशोल्ड जो समझ में आएं

  • हार्ड गेट्स: ज़रूर-पास-होने वाले मामले बिल्ड को तुरंत फ़ेल कर देते हैं, उदाहरण के लिए डेटा लीक या टूटा हुआ आउटपुट फ़ॉर्मैट।
  • फ्लोर्स: हर अहम स्कोर एक न्यूनतम स्तर से ऊपर रहना चाहिए, हर स्लाइस के हिसाब से (उदाहरण के लिए, प्रति भाषा)।
  • बड़ी गिरावट नहीं: पिछले मंज़ूर किए गए रन से तुलना करें; सामान्य रन-टू-रन शोर (noise) से बड़ी गिरावट पर किसी इंसान की नज़र ज़रूरी है।
नोट
एक ही इनपुट होने पर भी, अलग-अलग रन में मॉडल के आउटपुट बदल सकते हैं। पहले अपने शोर (noise) को मापें: बिना किसी बदलाव के सुइट को कुछ बार चलाएं और देखें कि स्कोर कितना बदलता है। थ्रेशोल्ड को उस दायरे से बाहर रखें, वरना आप झूठे अलार्म (फ़ाल्स अलार्म) के पीछे भागते रह जाएंगे।
Python: a tiny eval runner that fails the build on a regressionpython
import json
import sys

def call_model(prompt: str) -> str:
    ...  # plug in your provider

def check(case, output):
    text = (output or "").lower()
    ok_in = all(p.lower() in text for p in case.get("must_include", []))
    ok_out = not any(p.lower() in text for p in case.get("must_not", []))
    return ok_in and ok_out

def run(cases_path, baseline_path, max_drop=0.03):
    with open(cases_path, encoding="utf-8") as f:
        cases = [json.loads(line) for line in f if line.strip()]
    results = {c["id"]: check(c, call_model(c["input"])) for c in cases}
    score = sum(results.values()) / len(results)
    must_fail = [c["id"] for c in cases if c.get("must_pass") and not results[c["id"]]]
    with open(baseline_path, encoding="utf-8") as f:
        baseline = json.load(f)["score"]
    print(f"score {score:.1%} (baseline {baseline:.1%}), must-pass failures: {must_fail}")
    if must_fail or score < baseline - max_drop:
        sys.exit(1)  # non-zero exit fails the CI job

if __name__ == "__main__":
    run("evals/cases.jsonl", "evals/baseline.json")
असली सुइट हर स्लाइस के अनुसार नतीजे भी दिखाते हैं, बाद में पढ़ने के लिए हर आउटपुट को सेव करते हैं, और लागत पर नज़र रखते हैं। लेकिन मूल विचार इतना सा ही है: केस चलाएं, उन्हें स्कोर दें, बेसलाइन से तुलना करें, और गड़बड़ी होने पर साफ़-साफ़ फ़ेल करें।

मॉडल अपग्रेड

  1. 1

    वर्शन को पिन करें

    जहां आपका प्रोवाइडर सुविधा दे, वहां एक निश्चित मॉडल वर्शन का इस्तेमाल करें, ताकि मॉडल आपके जाने बिना न बदले। वर्शन और रिटायरमेंट की तारीखें कैसे काम करती हैं, इसके लिए अपने प्रोवाइडर के दस्तावेज़ (docs) देखें।
  2. 2

    नए मॉडल पर पूरा सुइट चलाएं

    वही केस, वही जज, वही थ्रेशोल्ड।
  3. 3

    टुकड़ा-दर-टुकड़ा (स्लाइस बाय स्लाइस) तुलना करें

    सिर्फ़ औसत में ही नहीं, बल्कि किसी भी भाषा, टास्क के प्रकार या सुरक्षा सेट में गिरावट देखें।
  4. 4

    बदले हुए जवाबों को पढ़ें

    स्कोर से कई चीज़ें छूट जाती हैं। उन केसों का एक सैंपल पढ़ें जहां आउटपुट बदल गए थे।
  5. 5

    वापसी का रास्ता रखते हुए बदलें

    धीरे-धीरे रोल आउट करें, लाइव मेट्रिक्स पर नज़र रखें, और पुराने वर्शन को तैयार रखें।
सावधान रहें
प्रॉम्प्ट्स भी कोड हैं। उन्हें वर्शन कंट्रोल में रखें, कोड की तरह बदलावों का रिव्यू करें, और सुइट चलाए बिना डैशबोर्ड में सीधे किसी प्रोडक्शन प्रॉम्प्ट को कभी एडिट न करें।
यह करके देखें। ऐसा एक प्रॉम्प्ट लें जिसे आप अक्सर इस्तेमाल करते हैं। एक शब्द बदलें। इसे पहले और बाद के पांच इनपुट्स पर चलाएं। क्या कुछ ऐसा बदला जिसकी आपको उम्मीद नहीं थी?

और देखें और पढ़ें

लैब

एक चालू eval रनर जो बेसलाइन और थ्रेशोल्ड के साथ काम करता है, जिसे प्रॉम्प्ट बदलाव से पहले और बाद में चलाया गया हो।

~45 min

समस्या

  1. स्टार्टर स्क्रिप्ट सेव करें। इसमें एक फ़ेक मॉडल शामिल है ताकि यह बिना किसी API key के चले।
  2. इसे चलाएं और स्कोर नोट करें। इसे अपनी बेसलाइन के रूप में सेव करें।
  3. फ़ेक मॉडल के जवाबों को एडिट करके "प्रॉम्प्ट बदलें" ताकि एक ज़रूर-पास-होने वाला केस फ़ेल हो जाए। फिर से चलाएं और पक्का करें कि स्क्रिप्ट एरर के साथ बंद होती है।
  4. उस केस को पहले जैसा कर दें, लेकिन दो सामान्य केसों को फ़ेल कर दें। क्या स्क्रिप्ट max_drop=0.03 के साथ फ़ेल होती है? max_drop=0.25 के साथ क्या होता है?
  5. तीन वाक्यों में लिखें कि आप एक असली सिस्टम के लिए max_drop कैसे चुनेंगे।

प्रैक्टिस लैब

कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।

आउटपुट

कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q15 केसों के साथ, हर केस 20 पॉइंट का होता है। यह आपको छोटे सुइट्स पर थ्रेशोल्ड के बारे में क्या बताता है?दिखाएं

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

Q2एक प्रोवाइडर आपके द्वारा पिन किए गए मॉडल वर्शन को बंद (रिटायर) कर देता है। आपका क्या प्लान है?दिखाएं

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

जारी रखने के लिए कृपया साइन इन करें।

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

हर बदलाव पर पूरा सुइट चलाना धीमा है और इसमें पैसे लगते हैं। मैं क्या कर सकता हूँ?

इसे बांट लें। हर बदलाव पर डिटर्मिनिस्टिक और ज़रूर-पास-होने वाले केसों का एक छोटा, तेज़ सेट चलाएं, और रिलीज़ से पहले या हर रात पूरा सुइट (LLM जज के साथ) चलाएं। उन केसों के नतीजे कैश (cache) कर लें जिनके इनपुट, प्रॉम्प्ट और मॉडल में कोई बदलाव नहीं हुआ था।

जब कोई केस फ़ेल हो जाए लेकिन नया जवाब असल में ठीक हो, तो मुझे क्या करना चाहिए?

इसे ध्यान से पढ़ें। अगर नया जवाब वाकई सही है, तो टेस्ट बहुत ज़्यादा सख़्त था: रेफ़रेंस या जांच को अपडेट करें, और वजह दर्ज करें। बिल्ड को हरा (सफल) दिखाने के लिए फ़ेल हो रहे केसों को चुपके से न हटाएं।

यह पाइपलाइन में सुरक्षा टेस्टिंग से कैसे अलग है?

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

क्या मुझे इसके लिए किसी खास टूल की ज़रूरत है?

नहीं। शुरुआत करने के लिए एक स्क्रिप्ट, केसों की एक JSONL फ़ाइल और आपका सामान्य CI सिस्टम काफ़ी है। ओपन-सोर्स eval फ़्रेमवर्क बाद में डैशबोर्ड और मददगार टूल्स जोड़ सकते हैं। अपनी ज़रूरतों के आधार पर चुनें, और हर टूल के मौजूदा दस्तावेज़ देखें।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें