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

A/B टेस्ट और ऑनलाइन मेट्रिक्स

Offline evals आपको बताते हैं कि क्या हो सकता है। असली यूज़र्स के साथ A/B टेस्ट आपको बताते हैं कि असल में क्या होता है। Guardrail मेट्रिक्स, सैंपल साइज़ का अंदाज़ा और novelty effects के बारे में जानें।

✦ ट्यूटर से पूछें🧪 लैब · 35 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

A/B टेस्ट और ऑनलाइन मेट्रिक्स

Offline evals आपको बताते हैं कि क्या हो सकता है। असली यूज़र्स के साथ A/B टेस्ट आपको बताते हैं कि असल में क्या होता है। Guardrail मेट्रिक्स, सैंपल साइज़ का अंदाज़ा और novelty effects…

1/4
आसान शब्दों में
एक चाय की दुकान का मालिक यह जानना चाहता है कि क्या उसकी नई रेसिपी बेहतर है। वह अपने दो दोस्तों से इसे चखने के लिए कह सकता है। या फिर, एक हफ़्ते के लिए, वह अपने आधे ग्राहकों को पुरानी रेसिपी और बाकी आधों को नई रेसिपी दे सकता है, और देख सकता है कि कौन सा ग्रुप दोबारा ज़्यादा आता है। यह दूसरा तरीका ही A/B टेस्ट है।
Offline evaluation रिलीज़ से पहले एक तय टेस्ट सेट का इस्तेमाल करता है। Online evaluation यह मापता है कि रिलीज़ के बाद असली यूज़र्स क्या करते हैं। दोनों की ज़रूरत होती है। Offline evals तेज़, सुरक्षित और दोहराए जा सकने वाले (repeatable) होते हैं। ऑनलाइन मेट्रिक्स असली असर दिखाते हैं: क्या यूज़र्स की समस्या सच में हल हो रही है, क्या वे बने रहते हैं, या शिकायत करते हैं?
Offline evalsऑनलाइन (A/B) टेस्ट
डेटाआपका तय किया गया टेस्ट सेटअसली यूज़र्स, असली ट्रैफ़िक
स्पीडमिनटों से लेकर घंटों मेंदिनों से लेकर हफ़्तों में
जोखिमकोई भी यूज़र खराब वर्शन नहीं देखताकुछ यूज़र्स नया वर्शन देखते हैं
क्या मापता हैजाने-पहचाने मामलों पर सही होना, फ़ॉर्मैट, और सुरक्षायूज़र का बर्ताव: समस्या सुलझना, यूज़र का टिके रहना, शिकायतें, लागत
मुख्य कमज़ोरीहो सकता है असली इस्तेमाल से मेल न खाएधीमा और शोरगुल वाला (noisy); इसके लिए काफ़ी यूज़र्स की ज़रूरत होती है

A/B टेस्ट कैसे काम करता है

  1. 1

    पहले offline evals पास करें

    ऐसे किसी भी वर्शन का A/B टेस्ट कभी न करें जो आपके ज़रूरी (must-pass) टेस्ट में फ़ेल हो जाए।
  2. 2

    एक मुख्य मेट्रिक चुनें

    पहले से तय करें, जैसे "इंसान की मदद के बिना सुलझाई गई चैट्स का हिस्सा"।
  3. 3

    Guardrail मेट्रिक्स चुनें

    ऐसी चीज़ें जो बिल्कुल खराब नहीं होनी चाहिए: शिकायतें, सुरक्षा से जुड़े फ़्लैग, लेटेंसी (देरी), हर चैट की लागत।
  4. 4

    यूज़र्स को बिना किसी क्रम के (randomly) बांटें

    हर यूज़र को बिना किसी तय नियम के A (मौजूदा) या B (नया) ग्रुप दिया जाता है, और वह उसी ग्रुप में रहता है।
  5. 5

    एक तय समय के लिए चलाएं

    शुरू करने से पहले अवधि और सैंपल साइज़ तय कर लें। जैसे ही B अच्छा दिखने लगे, उसी पल टेस्ट बीच में ही न रोकें।
  6. 6

    फ़ैसला लें

    B को तभी रिलीज़ करें जब मुख्य मेट्रिक बेहतर हो और कोई भी guardrail खराब न हो।

Guardrail मेट्रिक्स

हो सकता है कि एक नया प्रॉम्प्ट ज़्यादा जवाब देने की कोशिश करके ज़्यादा चैट्स सुलझा दे, जिसमें गलत जवाब भी शामिल हों। एक guardrail metric इसे पकड़ लेता है: उदाहरण के लिए, उन यूज़र्स की दर जो उसी समस्या के साथ वापस आते हैं, सुरक्षा रिपोर्ट, या रिफ़ंड की मांग। अगर कोई guardrail खराब होता है, तो टेस्ट रोकें और जांच करें, भले ही मुख्य मेट्रिक कितना भी बढ़िया क्यों न दिख रहा हो।

सैंपल साइज़ का अंदाज़ा

छोटे अंतरों का पता लगाने के लिए बहुत सारे यूज़र्स की ज़रूरत होती है। सामान्य सेटिंग्स पर (असली असर का पता लगाने का लगभग 80% मौका, 5% गलत अलार्म दर), दो ग्रुप्स की तुलना करने का एक आम नियम है: हर ग्रुप में यूज़र्स ≈ 16 × p × (1 − p) ÷ d², जहां p मौजूदा दर है और d वह सबसे छोटा बदलाव है जो आपके लिए मायने रखता है।
Python: rough users needed per grouppython
def users_per_group(p, d):
    """Rule of thumb: about 80% power, 5% significance, two groups."""
    return round(16 * p * (1 - p) / d ** 2)

print(users_per_group(0.20, 0.02))  # detect 20% -> 22%: 6400 per group
print(users_per_group(0.20, 0.05))  # detect 20% -> 25%: 1024 per group
इस पैटर्न पर ध्यान दें: अगर आपको आधे आकार का बदलाव पकड़ना है, तो आपको लगभग चार गुना ज़्यादा यूज़र्स की ज़रूरत होगी। अगर आपके प्रोडक्ट पर कम यूज़र्स हैं, तो बड़े सुधारों पर ध्यान दें, टेस्ट ज़्यादा दिन चलाएं, या फिर ध्यान से किए गए offline evals और इंसानी समीक्षा (human review) पर ज़्यादा भरोसा करें।
नोट
यह सिर्फ़ एक बुनियादी अंदाज़ा है, कोई पूरा स्टैटिस्टिकल प्लान नहीं। ज़रूरी फ़ैसलों के लिए, सही सैंपल साइज़ कैलकुलेटर का इस्तेमाल करें या किसी स्टैटिस्टिक्स के जानकार से पूछें।

किन गलतियों से बचें

गलतीक्या होता हैबचाव
बार-बार झांकना (Peeking)हर दिन नतीजे देखना और जैसे ही B बेहतर दिखे टेस्ट रोक देना — इससे ऐसी "जीत" मिलती है जो सिर्फ़ संयोग (noise) होती है।समय और सैंपल साइज़ पहले से तय कर लें।
Novelty effect (नया होने का असर)यूज़र्स किसी नए फ़ीचर को सिर्फ़ इसलिए आज़माते हैं क्योंकि वह नया है; बाद में इस्तेमाल कम हो जाता है।टेस्ट काफ़ी समय तक चलाएं; समय के साथ आते बदलावों और दोबारा आने वाले यूज़र्स पर ध्यान दें।
Change aversion (बदलाव नापसंद होना)शुरुआत में यूज़र्स को कोई भी बदलाव पसंद नहीं आता, भले ही वह अच्छा हो।वही तरीका: इसे तब तक चलाएं जब तक यूज़र्स का बर्ताव सामान्य न हो जाए।
बहुत सारे मेट्रिक्सअगर आप 30 मेट्रिक्स देखेंगे, तो उनमें से कुछ तो सिर्फ़ तुक्के से ही "बेहतर" दिखने लगेंगे।पहले से एक मुख्य मेट्रिक तय करें; बाकी को सिर्फ़ संकेतों की तरह देखें।
असमान ग्रुप्सएक ग्रुप में ज़्यादा हिंदी यूज़र्स आ जाते हैं, या वीकेंड का ट्रैफ़िक ज़्यादा आ जाता है।यूज़र के हिसाब से रैंडम ग्रुप बनाएं, और जांचें कि दोनों ग्रुप्स एक जैसे दिखें।
सावधान रहें
यूज़र्स को बताएं कि वे AI से बात कर रहे हैं, आप जो डेटा लॉग करते हैं उसके लिए अपनी प्राइवेसी पॉलिसी का पालन करें, और ऐसे बदलावों का A/B टेस्ट न करें जिनसे कुछ यूज़र्स को सच में नुकसान हो सकता है (उदाहरण के लिए, कोई सुरक्षा जांच हटा देना)। ऑफ़लाइन सुरक्षा evals सबसे पहले आते हैं।
इसे आज़माएं। आपका बॉट 30% चैट्स सुलझाता है। आपको उम्मीद है कि एक नया प्रॉम्प्ट इसे 33% तक बढ़ा देगा। हर ग्रुप के लिए कितने यूज़र्स की ज़रूरत होगी, इसका अंदाज़ा लगाने के लिए फ़ॉर्मूले का इस्तेमाल करें। क्या हर दिन 500 चैट्स वाले प्रोडक्ट के लिए यह मुमकिन है?

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

लैब

मेट्रिक्स, guardrails और सैंपल साइज़ के अंदाज़े के साथ एक पेज का A/B टेस्ट प्लान।

~35 min

समस्या

स्थिति: एक रेलवे पूछताछ बॉट बिना किसी इंसान की मदद के लगभग 25% चैट्स सुलझाता है। आपके पास एक नया प्रॉम्प्ट है जिससे आपको इसे बढ़ाने की उम्मीद है।

  1. मुख्य मेट्रिक को बिल्कुल साफ़-साफ़ लिखें ("सुलझाई गई" किसे माना जाएगा?)।
  2. तीन guardrail मेट्रिक्स की सूची बनाएं और बताएं कि हर एक क्यों मायने रखता है।
  3. नियम (rule of thumb) का इस्तेमाल करके, 27% और 30% तक की बढ़त का पता लगाने के लिए हर ग्रुप में ज़रूरी यूज़र्स की संख्या निकालें। अपना कैलकुलेशन भी दिखाएं।
  4. हर दिन लगभग 2,000 चैट्स को देखते हुए, अंदाज़ा लगाएं कि हर टेस्ट में कितने दिन लगेंगे। क्या इनमें से कोई भी प्रैक्टिकल है?
  5. लिखें कि novelty effects से निपटने के लिए आप टेस्ट को कितने समय तक चलाएंगे, और टेस्ट रोकने का आपका नियम क्या होगा।

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

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

आउटपुट

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

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

कठिन सवाल

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

Q1आपके A/B test से पता चलता है कि नए प्रॉम्प्ट ने रेजोल्यूशन (समस्या सुलझाने की दर) बढ़ा दिया, लेकिन शिकायतें भी थोड़ी बढ़ गईं, हालांकि आंकड़ों के हिसाब से यह अंतर पूरी तरह साफ नहीं है। आप क्या करेंगे?दिखाएं

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

Q2ऑफलाइन eval में हुआ सुधार A/B test में गायब क्यों हो सकता है?दिखाएं

हो सकता है कि टेस्ट सेट असली ट्रैफ़िक से मेल न खाता हो: असली यूज़र्स अलग-अलग भाषाओं, छोटे सवालों और अलग विषयों का इस्तेमाल करते हैं। हो सकता है कि सुधार ऐसे मामलों में हुआ हो जो असल में बहुत कम आते हैं। यूज़र्स ऐसी चीज़ों पर प्रतिक्रिया दे सकते हैं जिन्हें टेस्ट सेट नहीं मापता, जैसे स्पीड, लंबाई या बात करने का तरीका (tone)। और ऑफलाइन बढ़त शायद छोटे टेस्ट सेट पर सिर्फ एक तुक्का (noise) रही हो। A/B test असली माहौल को मापता है।

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

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

अगर offline evals अच्छे हैं, तो फिर A/B टेस्ट चलाने की क्या ज़रूरत है?

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

क्या मुझे हर मैसेज के हिसाब से ग्रुप बांटना चाहिए या हर यूज़र के हिसाब से?

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

अगर मेरे पास A/B टेस्ट के लिए काफ़ी यूज़र्स न हों तो क्या करें?

तो फिर offline evals, असली बातचीत की इंसानों द्वारा ध्यान से की गई समीक्षा, और धीरे-धीरे रोलआउट करने पर ज़्यादा भरोसा करें जहां आप guardrail मेट्रिक्स पर करीब से नज़र रखें। इस बात को लेकर ईमानदार रहें कि आप छोटे बदलावों का पता नहीं लगा सकते।

क्या मैं thumbs up और thumbs down को अपना मुख्य मेट्रिक बना सकता हूँ?

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

पाठ का टेस्ट

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

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