ailiteracynepal 🇳🇵
पाठ आकार

अध्याय ४ · खण्ड II · 22 मिनेट

Prompts र models को A/B testing

सुधारहरू ship गर्ने standard discipline: traffic को एक अंशलाई पुरानो संस्करण र candidate परिवर्तन बीच split गर्नुहोस्, महत्त्वपूर्ण metrics मा difference मापन गर्नुहोस्, र प्रमाणले समर्थन गर्दा मात्र परिवर्तन ship गर्नुहोस्। Prompts, models, र retrieval settings मा लागू।

तपाईंसँग एउटा नयाँ prompt छ जुन “राम्रो लाग्दछ।” तपाईंसँग एउटा सस्तो मोडेल छ जुन “पर्याप्त हुनुपर्दछ।” तपाईंसँग नयाँ retrieval strategy छ जुन “परीक्षणमा चीजहरू सुधार गर्दछ।” ती हरेक confident intuitions real टिमहरूको लागि गलत भइरहेका छन्। जान्ने तरिका यसको बारेमा तर्क गर्ने होइन — यो वास्तविक प्रयोगकर्ताहरूमा वर्तमान संस्करण विरुद्ध परिवर्तन चलाउने, मापन गर्ने, र संख्याहरूलाई निर्णय गर्न दिने हो। यो खण्ड AI उत्पादहरूमा A/B testing को सानो, boring, शक्तिशाली discipline हो।

Setup

एक A/B test ले तपाईंको प्रणालीको दुई संस्करणहरू तुलना गर्दछ, प्रत्येकले प्रयोगकर्ताहरूको एक अंश सर्भ गर्दछ:

  • Variant A — current संस्करण (control)।
  • Variant B — तपाईं परीक्षण गर्न चाहनुहुने परिवर्तन।

एक अवधि (एक दिन, एक हप्ता) को लागि, हरेक incoming request A वा B मा randomly assigned हुन्छ, र प्रत्येकको लागि परिणामहरू अलग रूपमा track गरिन्छन्। अन्त्यमा, तपाईंले metrics तुलना गर्नुहुन्छ र निर्णय गर्नुहुन्छ।

बाँकी सबै कुरा उही रहन्छ: उही eval set, उही logging, उही infrastructure। दुई समूह बीचको एउटै फरक भनेको परीक्षण भइरहेको specific परिवर्तन हो।

A/B के test गर्ने

LLM प्रणालीको हरेक गैर-तुच्छ परिवर्तनले A/B test को हकदार छ:

  • Prompts। एक पुनर्लिखित system prompt, एक नयाँ instruction, राम्रो few-shot उदाहरण।
  • Models। Sonnet बाट Haiku मा switch गर्ने (cheaper), वा Sonnet बाट Opus (अधिक शक्तिशाली), वा फरक provider।
  • Retrieval। नयाँ chunk size, नयाँ embedding model, re-ranker थप्ने।
  • Temperature / max_tokens। Behavioural parameters।
  • Feature additions। Conversation memory थप्ने, tool use थप्ने।

यीमध्ये हरेक कतै पनि जान सक्दछ। A/B test ले तपाईंलाई regressions ship बाट सुरक्षित गर्दछ।

एक न्यूनतम implementation

Simple hash-based assignment:

import hashlib

def variant_for_user(user_id: str, test_name: str) -> str:
    """Return 'A' or 'B' deterministically for this user."""
    payload = f"{test_name}::{user_id}"
    h = hashlib.sha256(payload.encode()).hexdigest()
    return "B" if int(h, 16) % 100 < 50 else "A"


@app.post("/summarise")
def summarise(req, user_id: str = Depends(get_current_user)):
    variant = variant_for_user(user_id, "prompt-v2-test")

    if variant == "A":
        prompt = build_prompt_v1(req)
    else:
        prompt = build_prompt_v2(req)

    response = call_model(prompt)

    log_event("ab_test",
              test="prompt-v2-test",
              variant=variant,
              user_id=user_id,
              request_id=request_id,
              latency_ms=...,
              tokens_out=...,
              cost=...,
              output=response)

    return response

दुई महत्त्वपूर्ण गुणहरू:

  1. Deterministic। एउटै प्रयोगकर्ताले सधैँ उही variant देख्दछ। Mid-session flipping रोक्दछ।
  2. Logged। हरेक request को variant log हुन्छ ताकि तपाईं पछि metrics slice गर्न सक्नुहुन्छ।

Sample size छनोट गर्ने

Jal: test एक दिनको लागि चलाउनुहोस्, A > B देख्नुहोस्, A ship गर्नुहोस्। तर 50 users प्रति दिन को साथ, एक दिन डाटा मा real differences लाई random variance बाट अलग गर्न धेरै noise छ।

LLM A/B tests को लागि rule of thumb:

  • Behavioural metrics (thumbs, refusal rate): confidence को लागि प्रति variant ~500-1000 samples चाहिन्छ।
  • Latency र cost: प्रति variant ~100-200 samples चाहिन्छ।
  • Quality (LLM-judged): प्रति variant ~50-100 samples चाहिन्छ।

100 daily active users मा, 50/50 split ले प्रति variant प्रति दिन 50 samples दिन्छ। Behavioural metrics को लागि अर्थपूर्ण test लाई 10-20 दिन चाहिन्छ।

Low-traffic products को लागि, यो ईमानदार बाधा हो। प्रति variant 20 samples मा आधारित परिवर्तनहरू ship नगर्नुहोस्। यसले काम गर्दैन।

के मापन गर्ने

A र B बीच तपाईंले तुलना गर्ने metrics:

Direct quality (eval set मार्फत)।

  • A र B विरुद्ध उही eval set चलाउनुहोस्। प्रति dimension mean scores तुलना गर्नुहोस् (correctness, completeness, faithfulness)।
  • Statistical test: per-question scores मा paired t-test।

Real traffic मा user व्यवहार।

  • Thumbs-up rate।
  • Thumbs-down rate।
  • Session length।
  • Refusal rate।
  • User retry-rate (के तिनीहरूले rephrase गरे किनकि जवाफ खराब थियो?)।

Operational metrics।

  • Latency (p50, p95)।
  • Cost per call।
  • Error rate।

अधिकांश परिवर्तनहरूको लागि, quality (#1) र cost (#3) निर्णायक कारकहरू हुन्। यदि B 30% cheaper हो र quality A को 3% भित्र छ भने, B ship गर्नुहोस्। यदि B 5% राम्रो quality तर 2× cost हो भने, प्रयोगकर्ताहरूले difference बारे हेरचाह गर्दछन् कि विचार गर्नुहोस्।

एउटा ईमानदार उदाहरण

तपाईं नेपाली नीति bot को लागि छोटो system prompt (1200 tokens को सट्टा 400 tokens) परीक्षण गर्न चाहनुहुन्छ।

Setup: 2 हप्ता को लागि 50/50 split, 500 daily users। त्यो प्रति variant ~7,000 samples हो।

Results:

Metric              Variant A (1200-token prompt)   Variant B (400-token prompt)   Difference
Correctness (0-2)               1.84                          1.79                    -3%
Completeness (0-2)              1.72                          1.65                    -4%
Faithfulness (0-2)              1.91                          1.90                    -1%
Thumbs-up rate                  67%                           64%                     -3%
Latency p50 (ms)                1420                          1120                    -21%
Latency p95 (ms)                2400                          1950                    -19%
Cost per call ($)              $0.010                        $0.006                   -40%

Interpretation: B अर्थपूर्ण रूपमा तेज र सस्तो छ (-40% cost, -20% latency)। Quality अलिकति नराम्रो छ (correctness/completeness मा ~3-4% drop)।

निर्णय तपाईंको उत्पाद प्राथमिकताहरूमा भर पर्दछ। यदि तपाईं cost-constrained हुनुहुन्छ र प्रयोगकर्ताहरूले bot लाई सामान्यतया 4/5 rate गर्दछन्, 3-4% quality drop 40% cost saving को लायकको हुन सक्दछ। यदि तपाईं एक premium उत्पाद हुनुहुन्छ जहाँ हरेक जवाफ महत्त्वपूर्ण छ भने, A राख्नुहोस्।

Point हो कि निर्णय अब numeric र ईमानदार छ, vibes-based होइन।

Multi-arm tests

तपाईंले एक पटकमा दुई भन्दा बढी variants test गर्न सक्नुहुन्छ — A/B/C को लागि 50/25/25 split, वा तीन variants को लागि 33/33/33। समान सिद्धान्तहरू, हरेक arm लाई confidence मा पुग्न बढी traffic चाहिन्छ।

10 समवर्ती tests नचलाउनुहोस्। हरेक अतिरिक्त test ले हरेकको statistical confidence घटाउँछ र परिणामहरू interpret गर्न गाह्रो बनाउँछ। नियम: प्रति endpoint स्पष्ट प्राथमिकताहरूसँग सबैभन्दा बढी 1-2 समवर्ती A/B tests।

Guardrails

एक A/B test ले हारेको variant मा प्रयोगकर्ताहरूलाई चुपचाप damage गर्न सक्दछ। Guardrails:

  • Kill switch। एक config flag जसले तपाईंलाई B लाई तुरुन्तै 0% मा drop गर्न दिन्छ यदि यसले गम्भीर मुद्दाहरू (safety, cost, errors) कारण देखियो भने।
  • Auto-abort thresholds। यदि B को error rate ले A को 2× भन्दा 15 मिनेटको लागि पार गर्दछ भने, स्वचालित रूपमा सबै traffic लाई A मा route गर्नुहोस्।
  • Bounded blast radius। परिवर्तन बारे unsure हुनुहुन्छ भने 50% traffic मा test नचलाउनुहोस्। 5% बाट सुरु गर्नुहोस् र metrics स्वस्थ देखिएमा मात्र बढाउनुहोस्।

Test अन्त्य गर्ने

एक A/B test अन्त्य हुन्छ जब तीन कुराहरू मध्ये एक सत्य हुन्छ:

  1. Statistical significance पुगेको छ। Primary metric मा A र B बीचको difference noise floor भन्दा माथि छ।
  2. Test पर्याप्त लामो चलेको छ कि “कुनै significant difference छैन” वैध निष्कर्ष हो। सस्तो / सरल variant ship गर्नुहोस्।
  3. Guardrail fire भयो। Abort।

एकपटक निर्णय भएपछि, विजेतालाई नयाँ baseline को रूपमा ship गर्नुहोस्। कोडबाट हार्ने variant मेटाउनुहोस्। पुराना test variants लाई नरहन दिनुहोस् — तिनीहरूले जटिलता थप्दछन् र अर्को test लाई भ्रमित गर्दछन्।

A/B mindset

A/B testing मा नयाँ टिमहरूको लागि, shift पहिले uncomfortable छ। तपाईंले स्वीकार गर्नुपर्दछ:

  • “कुन राम्रो छ” बारे तपाईंको intuition प्राय: गलत हुन्छ।
  • साना परिवर्तनहरूले विरलै dramatic differences उत्पादन गर्दछन् (र dramatic differences सामान्यतया bugs हुन्)।
  • सही जवाफ प्राय: संख्याहरूद्वारा प्रकट हुन्छ, टिम बहस द्वारा होइन।
  • केही tests inconclusive हुन्छन् — त्यो real परिणाम हो, failure होइन।

Discipline महिनौंमा payoff हुन्छ। आफ्नो सुधारहरू A/B test गर्ने उत्पादहरूले नगर्ने उत्पादहरू भन्दा राम्रा उत्पादहरू ship गर्दछन् — तिनीहरू smart भएकाले होइन, तर तिनीहरूले evidence लाई confidence माथि जित्न दिन्छन्।

अब के आउँछ

तपाईंलाई थाहा छ व्यक्तिगत परिवर्तनहरू कसरी परीक्षण गर्ने। Chapter 4 को अन्तिम खण्ड real user interactions को flood लाई feedback loop मा बदल्ने बारे हो — real users ले वास्तवमै के गर्दछन्, चाहन्छन्, र complain गर्दछन् त्यसबाट तपाईंको service को निरन्तर सुधार।