LLM आउटपुट का मूल्यांकन

तयशुदा test set, धारणाओं से बेहतर

वास्तविक इनपुट का evaluation set बनाएँ, अपेक्षित उत्तरों या ग्रेडिंग नियमों के साथ, और prompt, मॉडल या retrieval बदलने पर उसे दोबारा चलाएँ। जहाँ संभव हो exact या नियम-आधारित जाँचें उपयोग करें (वैध JSON, सही label, आवश्यक fields मौजूद)। खुले-अंत पाठ के लिए rubrics और LLM-as-judge scoring उपयोग करें, पर judge को मानव रेटिंग से मिलाकर जाँचें क्योंकि judges में पूर्वाग्रह होते हैं (जैसे लंबे उत्तरों की ओर)। गुणवत्ता के साथ groundedness (क्या हर दावा स्रोतों से समर्थित है?), refusal दर, latency और लागत पर नज़र रखें। सार्वजनिक benchmark scores शुरुआत हैं; आपके कार्य का डेटा निर्णय करता है।

पहले मापें, फिर बचाएँ

जो नहीं मापते उसे सुधार नहीं सकते; और LLM app में नई हमले की सतहें हैं।

Exact बनाम उदार scoring, चलाकर

मैंने यह सादा-Python (सिर्फ़ standard library) उदाहरण चलाया। वही तीन उत्तर exact match में 1/3 पर पर case अनदेखा करने पर 2/3 पर हैं; "warm" वाक़ई ग़लत है। Metric का चुनाव कहानी बदलता है, इसलिए नतीजे देखने से पहले तय करें।

cases = [
    ("2+2", "4"), ("capital of France", "Paris"), ("opposite of hot", "cold"),
]
fake_model = {"2+2": "4", "capital of France": "paris", "opposite of hot": "warm"}
exact = sum(fake_model[q] == a for q, a in cases)
loose = sum(fake_model[q].lower() == a.lower() for q, a in cases)
print("exact match:", exact, "/", len(cases))
print("case-insensitive:", loose, "/", len(cases))

Output:

exact match: 1 / 3
case-insensitive: 2 / 3

कठिन और विरोधी मामले शामिल करें

Typos, अन्य भाषाएँ, ख़ाली इनपुट, चालाक सवाल और ऐसे मामले जोड़ें जहाँ सही उत्तर "मुझे नहीं पता" है।

त्वरित जाँच: तयशुदा evaluation set क्यों रखें?

• Base model प्रशिक्षित करने के लिए
• Prompts या मॉडलों के बदलावों की निष्पक्ष तुलना के लिए
• Token लागत घटाने के लिए
• परीक्षण से बचने के लिए