रिपॉज़िटरी कोड में बदलावों पर Hugging Face मॉडल का पुनरुत्पादनीय मूल्यांकन कैसे करें

मूल्यांकन का सवाल: क्या मॉडल ने ऐसा रिपॉज़िटरी बदलाव किया जिसे टेस्ट किया गया?

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

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

यह बेंचमार्किंग पर Hugging Face समुदाय की चर्चा में दी गई मुख्य सलाह के अनुरूप है: लक्ष्य टास्क से शुरुआत करें, समान सेटिंग्स में मॉडल की तुलना करें, नमूना विफलताओं की जाँच करें और सार्वजनिक बेंचमार्क को टास्क-विशिष्ट सुधार का प्रमाण नहीं, बल्कि दूसरे स्तर के रूप में देखें। चर्चा में यह भी सलाह दी गई है कि सेटअप की जानकारी दर्ज करें ताकि दूसरे लोग मूल्यांकन दोहरा सकें। स्रोत: Hugging Face समुदाय चर्चा, “What’s your method for benchmarking?”

1. अप्रयुक्त रिपॉज़िटरी टास्क तैयार करें

हर टास्क में रिपॉज़िटरी commit, समस्या का संक्षिप्त विवरण और टेस्ट कमांड या कोई अन्य स्पष्ट स्वीकृति-जाँच शामिल होनी चाहिए। मूल्यांकन टास्क को मॉडल ट्रेनिंग और प्रॉम्प्ट पर काम करने की प्रक्रिया से अलग रखें। अगर आप उन्हीं टास्क के आधार पर बार-बार प्रॉम्प्ट बदलते हैं, तो वे साफ़-सुथरे अप्रयुक्त टेस्ट सेट के बजाय विकास के उदाहरण बन जाते हैं।

ऐसे टास्क चुनें जो उन बदलावों को दर्शाते हों जिनकी आपको परवाह है: सामान्य bug fixes, edge cases, कई फ़ाइलों में बदलाव और वे स्थितियाँ जहाँ सही कदम अपर्याप्त जानकारी की बात बताना हो। ऐसे टास्क को प्राथमिकता दें जिनके टेस्ट इच्छित व्यवहार और मौजूदा व्यवहार में अंतर पहचान सकें। ज्ञात कमियाँ दर्ज करें: टेस्ट सूट में सुरक्षा, प्रदर्शन, अनुकूलता या हर regression की जाँच न हो सकती है।

हर टास्क को दोबारा तैयार किया जा सके, इसके लिए manifest इस्तेमाल करें:

मॉडल के बीच रिपॉज़िटरी की स्थिति चुपचाप न बदलें। मूल्यांकन के नतीजों के साथ manifest और टास्क इनपुट सहेजें, और रिपॉज़िटरी के लाइसेंस या गोपनीयता संबंधी ज़रूरतों का ध्यान रखें।

2. Hugging Face मॉडल और जनरेशन सेटअप पिन करें

किसी अनिर्दिष्ट, बदलते रहने वाले reference के बजाय मॉडल का एक विशिष्ट revision इस्तेमाल करें। मॉडल ID, revision, Transformers version, tokenizer और chat template, hardware और यह दर्ज करें कि आपने adapter, merged weights या quantization इस्तेमाल की थी या नहीं। इन विकल्पों के आधार पर मॉडल का व्यवहार बदल सकता है।

नीचे Transformers के साथ एक patch प्रस्ताव जनरेट करने के लिए उदाहरण के तौर पर दिया गया, बिना टेस्ट किया गया configuration है। placeholders बदलें और इसे चलाने से पहले पुष्टि करें कि मॉडल का architecture और chat template समर्थित हैं। यह टेक्स्ट जनरेट करता है; इससे नतीजे वाला patch लागू या टेस्ट नहीं होता।

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "YOUR_HUGGING_FACE_MODEL_ID"
revision = "YOUR_PINNED_REVISION"

messages = [
    {
        "role": "user",
        "content": (
            "Given this repository context and issue, return a unified diff only. "
            "Do not claim tests passed.\n\n"
            "Repository context:\nYOUR_FIXED_REPOSITORY_CONTEXT\n\n"
            "Issue:\nYOUR_HELD_OUT_ISSUE"
        ),
    }
]

tokenizer = AutoTokenizer.from_pretrained(model_id, revision=revision)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    revision=revision,
    torch_dtype="auto",
    device_map="auto",
)

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    output = model.generate(
        inputs,
        do_sample=False,
        max_new_tokens=1200,
    )

new_tokens = output[0, inputs.shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

Greedy decoding (do_sample=False) से variation का एक स्रोत—sampling—हट जाता है, लेकिन इससे सभी hardware, libraries या kernels पर एक जैसे आउटपुट मिलने की गारंटी नहीं होती। सटीक वातावरण दर्ज करें। अगर इच्छित कार्यप्रवाह में sampling शामिल है, तो seed और sampling parameters तय करके दर्ज करें; आउटपुट में बदलाव समझना हो तो कई बार चलाएँ। यह न मानें कि उदाहरण की सेटिंग्स हर मॉडल के लिए उपयुक्त हैं।

3. Patch को अलग-थलग वातावरण में लागू करें और टेस्ट करें

हर task-model जोड़ी के लिए दर्ज किए गए commit से एक साफ़ checkout शुरू करें। parsing से पहले raw model output सहेजें। पुष्टि करें कि उसमें इस्तेमाल करने लायक diff है, उसे disposable worktree या container में लागू करें और पहले से तय test command चलाएँ। मॉडल जनरेशन को टेस्ट रन से अलग रखें, ताकि नाकाम patch को infrastructure या test-runner की विफलता न समझा जाए।

हर नतीजे को अलग से दर्ज करें:

Test command पास होना इस बात का सबूत है कि दर्ज किए गए वातावरण में चुने गए टेस्ट पास हुए। यह उन टेस्ट से आगे सही होने का प्रमाण नहीं है। टेस्ट सेटअप की विफलताओं को मॉडल की विफलताओं से अलग रिपोर्ट करें और जो टेस्ट चलाया ही नहीं गया, उसे पास न गिनें।

4. Regression छिपाए बिना मॉडल की तुलना करें

Baseline और candidate मॉडल के लिए समान टास्क, समान रिपॉज़िटरी snapshot और समान प्रॉम्प्ट इस्तेमाल करें। टास्क की संख्या, patch लागू होने की दर, टेस्ट पास होने की दर और जाँचे गए टास्क की संख्या बताएँ। केवल औसत नहीं, बल्कि टास्क-स्तर के नतीजे या विफलताओं का सार भी शामिल करें। कोई मॉडल सीमित तरह के fixes में बेहतर हो सकता है, लेकिन formatting, scope control या टास्क के किसी दूसरे हिस्से में पीछे जा सकता है।

छोटे मूल्यांकन सेट के नतीजे को उसी सेट का नतीजा कहें—सामान्य रैंकिंग नहीं। स्रोत चर्चा में बताया गया है कि छोटे सेट पर स्कोर बदल सकते हैं, इसलिए कई बार चलाना उपयोगी हो सकता है। अगर आउटपुट stochastic हैं, तो दर्ज किए गए seeds के साथ कई बार रन करें और बदलाव की सीमा बताएँ; अगर जनरेशन deterministic है, तब भी कुछ ही टास्क से व्यापक निष्कर्ष निकालने में सावधानी बरतें।

5. नतीजे के साथ सीमाएँ भी प्रकाशित करें

पुनरुत्पादनीय रिपोर्ट में मॉडल और revision, रिपॉज़िटरी commits, टास्क चुनने का तरीका, अपवर्जन, प्रॉम्प्ट, जनरेशन पैरामीटर, software और hardware वातावरण, patch parser, टेस्ट कमांड और scoring rules शामिल होने चाहिए। यह भी बताएँ कि मूल्यांकन किन बातों को नहीं मापता—उदाहरण के लिए, बिना टेस्ट किए गए regressions, code review की गुणवत्ता, सुरक्षा गुण, latency या प्रदर्शन, जब तक आपने इन्हें मापा न हो।

निष्कर्ष विशिष्ट होना चाहिए: इन अप्रयुक्त रिपॉज़िटरी टास्क पर, दर्ज किए गए इस सेटअप में, मॉडल ने ऐसे patch बनाए जिनके लागू होने और टेस्ट नतीजे ये रहे। जब असल सवाल यह हो कि मॉडल आपके codebase में सत्यापित बदलाव कर सकता है या नहीं, तो यह leaderboard स्कोर से अधिक जानकारी देता है।