निरन्तर मूल्यांकन

समस्या

AI प्रणालीको quality fixed number होइन। यो धेरै कारणहरूको लागि सर्दछ:

• Provider updates। Anthropic वा OpenAI ले underlying मोडेल चुपचाप update गर्दछन्। व्यवहार परिवर्तन हुन्छ।
• Prompt edits। कसैले एउटा case को लागि system prompt समायोजन गर्दछ; फरक case regresses।
• Data updates। RAG index मा नयाँ documents ले के retrieved हुन्छ त्यो बदल्दछन्।
• Query drift। प्रयोगकर्ताहरूले फरक कुराहरू सोध्न थाल्दछन्; corpus ले तिनीहरूलाई कभर गर्दैन।

यीमध्ये कुनै एकले पनि quality लाई ढिलो degraded गर्न सक्दछ। एउटा fixed benchmark बिना, कुनै दृश्यमान छैन — प्रयोगकर्ताहरू complain गर्दा सम्म, त्यसबेला सम्म क्षति पहिले नै भइसकेको छ।

निरन्तर मूल्यांकन fix हो: एउटा benchmark जुन तपाईंले schedule मा चलाउनुहुन्छ, जुन उही परिस्थितिहरूमा उही number उत्पादन गर्दछ, ताकि त्यो number मा परिवर्तनहरू जाँच गर्ने signal हो।

Eval set

राम्रो eval set का तीन गुणहरू छन्:

1. Fixed। उही प्रश्नहरू, उही अपेक्षित जवाफहरू, सधैँ। तपाईं जानाजानी benchmark update नगरेसम्म थप्नुहोस् वा edit नगर्नुहोस्।
2. Representative। प्रयोगकर्ता queries को वास्तविक वितरण कभर गर्दछ — edge cases र Nepal-specific patterns सहित।
3. Right-sized। 50-200 items। statistical stability को लागि पर्याप्त, सस्तो र प्राय: चलाउनको लागि पर्याप्त सानो।

नेपाली policy bot को लागि, एउटा शुरुवात eval set यस्तो देखिन सक्दछ:

30 policy questions in Nepali
30 policy questions in English
10 mixed-language queries
10 out-of-scope queries (should be refused)
5 ambiguous queries (should ask for clarification)
5 adversarial / prompt-injection attempts

कुल: 90 items। हरेक item मा:

• Input query।
• अपेक्षित व्यवहार (सही जवाफ, वा “refuse”, वा “clarify”)।
• 2-3 criteria (correctness, source citation, format) सँग एक grading rubric।

Grading — गाह्रो भाग

Human grading gold standard हो तर scale गर्दैन। LLM-आधारित grading — जहाँ तपाईंले जवाफ ग्रेड गर्न अर्को LLM प्रयोग गर्नुहुन्छ — practical compromise हो।

एक LLM-as-judge prompt:

JUDGE_PROMPT = """You are grading an AI assistant's answer.

Question:
{question}

Reference answer (from the source document):
{reference_answer}

Model's answer:
{model_answer}

Grade the model's answer on three dimensions, each 0-2:

1. Correctness: does the answer say the right thing?
   0 = wrong, 1 = partially correct, 2 = correct
2. Completeness: does it cover the key facts?
   0 = misses key facts, 1 = missing some, 2 = complete
3. Faithfulness: are the facts supported by the reference?
   0 = hallucinated facts, 1 = some drift, 2 = fully supported

Return a JSON object with keys 'correctness', 'completeness', 'faithfulness', and 'comment'.
"""

def grade(question, reference, model_answer):
    prompt = JUDGE_PROMPT.format(
        question=question,
        reference_answer=reference,
        model_answer=model_answer,
    )
    response = anthropic_client.messages.create(
        model="claude-3-5-sonnet-latest",
        max_tokens=300,
        messages=[{"role": "user", "content": prompt}],
    )
    return json.loads(response.content[0].text)

Graded भइरहेको मोडेल भन्दा grading को लागि फरक मोडेल प्रयोग गर्नुहोस्। यसले grader आफ्नो outputs को पक्षमा biased हुने जोखिम घटाउँछ।

Eval चलाउने

दिनमा एकपटक (वा हरेक deploy मा), आफ्नो service मार्फत पूर्ण eval set चलाउनुहोस्:

def run_eval(eval_set, service_url):
    results = []
    for item in eval_set:
        answer = call_service(service_url, item["query"])
        grade = grade_answer(item["query"], item["reference"], answer)
        results.append({
            "id": item["id"],
            "query": item["query"],
            "answer": answer,
            **grade,
        })

    scores = {
        "correctness": sum(r["correctness"] for r in results) / len(results),
        "completeness": sum(r["completeness"] for r in results) / len(results),
        "faithfulness": sum(r["faithfulness"] for r in results) / len(results),
    }
    return scores, results

Scores लाई timestamp सँग table मा save गर्नुहोस्। समयको साथ trend chart गर्नुहोस्:

Date       Correctness  Completeness  Faithfulness
2026-05-01     1.83         1.71         1.92
2026-05-08     1.81         1.68         1.91
2026-05-15     1.85         1.72         1.93
2026-05-22     1.72         1.65         1.85   ← drop
2026-05-29     1.68         1.60         1.82   ← keeps dropping

2026-05-15 र 2026-05-22 बीचको drop signal हो। त्यो हप्ता केही परिवर्तन भयो — एउटा deploy, एउटा provider update, एउटा data change। प्रयोगकर्ताहरूले report गर्नुभन्दा पहिले जाँच गर्नुहोस्।

Per-slice tracking

समग्र score ले specific slice मा regression लुकाउन सक्दछ। यसद्वारा तोड्नुहोस्:

• Language — नेपाली vs. अंग्रेजी अलग। Regressions प्राय: एक भाषा हिट गर्दछन् र अर्को होइन।
• Query type — factoids vs. reasoning vs. summarisation।
• Topic — तपाईंको कागजातहरूको फरक sections / फरक policy areas।

Date        Overall  Nepali  English  Refusals
2026-05-22   1.72     1.55    1.89     1.30    ← Nepali dropped
2026-05-29   1.68     1.48    1.88     1.30    ← Nepali still worse

समग्र score stable-ish छ; नेपाली खस्दैछ। समग्र metric ले यो छुटाएको हुनेथ्यो। Slice-by-slice tracking ले छुटाउँदैनथ्यो।

Regression को जाँच गर्ने

जब eval score खस्छ:

1. असफल items हेर्नुहोस्। कुन specific प्रश्नहरू regressed भए? मोडेलको नयाँ जवाफहरू vs. यसको पुरानो जवाफहरू पढ्नुहोस्।
2. भर्खरका परिवर्तनहरू हेर्नुहोस्। अन्तिम दुई evals बीच के deploy भयो? कुनै provider announcements? कुनै data updates?
3. Reproduce गर्नुहोस्। के तपाईं एक failing query मा regression reproduce गर्न सक्नुहुन्छ?
4. Bisect गर्नुहोस्। आफ्नो prompt / model / retrieval को पुराना संस्करणहरू प्रयोग गर्नुहोस् यसले कुन परिवर्तन कारण हो पत्ता लगाउन।
5. Fix वा स्वीकार गर्नुहोस्। या त regression fix गर्नुहोस् (परिवर्तन rollback गर्नुहोस्, prompt सुधार गर्नुहोस्) वा नयाँ baseline स्वीकार गर्नुहोस् (केही quality trade-offs अन्य फाइदाहरूको लायकको हुन्छन्)।

Eval set तपाईंको instrument हो। जाँच जहाँ वास्तविक काम हुन्छ।

Eval set बनाउने

प्रश्नहरू कहाँबाट आउँछन्?

• Real user queries। सबैभन्दा राम्रो स्रोत। आफ्नो logs बाट random sample लिनुहोस्, hand-write reference जवाफहरू, अपेक्षित behaviours mark गर्नुहोस्।
• Synthetic queries। LLM लाई तपाईंको कागजातहरू बारे 30 प्रश्नहरू generate गर्न भन्नुहोस्। कडा रूपमा curate गर्नुहोस्।
• Adversarial queries। Hand-craft edge cases: prompt injection, ambiguous, out-of-scope।
• Regression cases। जब प्रयोगकर्ताले bug report गर्दछ र तपाईंले यसलाई fix गर्नुहुन्छ, त्यो query eval set मा थप्नुहोस्। अब fix future regression विरुद्ध सुरक्षित छ।

30-50 items सँग सुरु गर्नुहोस् र मासिक बढाउनुहोस्। ambiguous, poorly graded, वा जुन discriminate गर्दैनन् त्यस्ता items अस्वीकार गर्नुहोस् (सबैले सधैँ सही पाउँछन्)।

Eval discipline

तीन बानीहरू:

• Run automate गर्नुहोस्। हरेक रात, एउटा scheduled job ले eval चलाउँछ र scores Slack मा post गर्दछ। कसैले सम्झिन आवश्यक छैन।
• Trend chart गर्नुहोस्। समयसँग score सबैभन्दा उपयोगी view हो। Sudden drops ले जाँच trigger गर्दछन्।
• Set बढाउनुहोस्। जहिले तपाईंले user-reported bug fix गर्नुहुन्छ, एक corresponding eval item थप्नुहोस्। Set तपाईंको regression suite बन्दछ।

एकपटक तपाईंसँग यो छ, तपाईंलाई थाहा हुन्छ जब quality परिवर्तन हुन्छ। त्यो ज्ञान Chapter 4 मा हरेक अर्को सुधारको substrate हो।

आफ्नो बुझाइ जाँच्नुहोस्

Quick check

—

एक टिमले launch मा मात्र eval चलाउँछ, निरन्तर होइन। तीन महिना पछि, प्रयोगकर्ताहरूले गलत जवाफहरू बारे complain गर्न थाल्दछन्। यसलाई पहिले catch गर्न कुन operational tool ले सक्थ्यो?

1. Aराम्रो pre-launch परीक्षण।
2. BFixed benchmark मा daily (वा per-deploy) automated eval, scores समयको साथ chart गरिएको। Production मा Quality drift का धेरै कारणहरू छन् — provider updates, prompt edits, data updates, query drift — logs एक्लै बाट कुनै दृश्यमान छैन। निरन्तर eval ले 'quality परिवर्तन भयो' लाई रहस्यबाट scheduled measurement मा बदल्दछ। जब score खस्छ, timestamp ले तपाईंलाई कहिले हेर्ने भन्दछ, र drop लाई तपाईंको deploy history सँग तुलना गर्नुले सामान्यतया fix गर्न के हो पहिचान गर्दछ। निरन्तर evals बिना, quality regressions प्रयोगकर्ताहरू complain गर्दा सम्म अदृश्य छन् — तर सम्म trust पहिले नै erode भइसकेको छ।
3. Cठूलो vector database।
4. Dअझ शक्तिशाली मोडेल।

Check answer→

Quick check

—

Eval ग्रेड गर्न प्रयोग गरिने LLM ले ग्रेड भइरहेको LLM भन्दा फरक हुनुपर्दछ किन?

1. Aयसको cost कम छ।
2. BSelf-preference bias घटाउन: LLMs ले आफ्नै style / patterns / phrasing लाई मानिस भन्दा बढी अनुकूल ग्रेड गर्ने प्रवृत्ति राख्दछन्। फरक provider प्रयोग गर्नु (जस्तै Claude लाई GPT सँग ग्रेड गर्ने, वा उल्टो) ले अझ स्वतन्त्र judgments उत्पादन गर्दछ र regressions catch गर्दछ जुन same-model grader ले छुटाउँथ्यो। यो perfect independence होइन — दुबै models ले training-data patterns share गर्दछन् — तर यो bias विरुद्ध अर्थपूर्ण safeguard हो, र यो implement गर्न सस्तो छ। High-stakes contexts मा, periodic human grading सँगै थप्नुहोस्।
3. CGrader model अझ smart छ।
4. Dयो तेज चल्दछ।

Check answer→

अब के आउँछ

निरन्तर मूल्यांकनले तपाईंलाई quality परिवर्तन कहिले भयो भन्दछ। अर्को खण्ड उद्देश्यपूर्वक quality कसरी परिवर्तन गर्ने बारे हो: prompt र model variants को A/B testing। नयाँ prompt लाई पुरानो सँग real traffic मा testing, difference मापन गर्दै, र परिवर्तन राख्ने वा नराख्ने निर्णय गर्दै — सुरक्षित रूपमा improvements ship गर्न standard discipline।