पाठ 17 / 25

A/B Tests और Regression जाँचें

Live traffic पर versions की सावधानी से तुलना करें और हर बदलाव पर CI में offline evals चलाएँ।

पहले offline, फिर online

जब भी prompt, model, tool या retrieval setting बदले, अपना evaluation set अपने आप चलाएँ (regression जाँच) और मुख्य scores गिरें तो बदलाव रोकें। User-facing नतीजों के लिए A/B test चलाएँ: traffic का एक हिस्सा नए version को भेजें और thumbs-up दर या काम पूरा होने जैसे metric की तुलना करें। Random शोर को सुधार न समझ लें, इसके लिए significance test उपयोग करें। दो अनुपातों के लिए लगभग 1.96 या उससे ऊपर का z-score ऐसे अंतर का संकेत है जिसके संयोग होने की संभावना कम है (सामान्य 5% स्तर पर)।

दो-अनुपात z-score, चलाकर

मैंने यह चलाया। 120/1000 बनाम 150/1000 से z = 1.96 आता है, जो महत्व की सीमा पर है। वही दरें हर तरफ़ सिर्फ़ 100 users पर (12 बनाम 15) z = 0.62 देती हैं, जो विश्वसनीय नहीं।

import math

def z2(a, na, b, nb):
    p1, p2 = a / na, b / nb
    p = (a + b) / (na + nb)
    se = math.sqrt(p * (1 - p) * (1 / na + 1 / nb))
    return round((p2 - p1) / se, 2)

print(z2(120, 1000, 150, 1000), z2(12, 100, 15, 100))

Output:

1.96 0.62

पहले metric और रुकने का नियम तय करें

नतीजे देखने के बाद metric चुनना, या अच्छा दिखते ही test रोक देना, झूठी जीत बढ़ाता है। शुरू करने से पहले लिख लें कि आप क्या मापेंगे और कितनी देर चलाएँगे।

त्वरित जाँच: Regression-जाँच के scores गिरें तो बदलाव क्यों रोकें?

  • गिरते scores हमेशा शोर होते हैं
  • Scores कभी मायने नहीं रखते
  • बदलाव ने system को उन तरीक़ों से बदतर किया हो सकता है जो आपने नहीं चाहे
  • इससे deployment तेज़ होता है
Answer

बदलाव ने system को उन तरीक़ों से बदतर किया हो सकता है जो आपने नहीं चाहे — स्वचालित जाँचें users से पहले चुपचाप गुणवत्ता गिरना पकड़ती हैं।