# Evaluation Set बनाना — AI Safety, Evaluation और Cost Control

Source: https://www.geekswithgeeks.com/hi/ai-safety/eval-datasets

> यथार्थपूर्ण, labelled मामले इकट्ठे करें जो सामान्य उपयोग, किनारे के मामलों और ज्ञात विफलताओं को ढकें।

## असली उपयोग जैसा डेटा

**Evaluation set** inputs का संग्रह है जिनके साथ अपेक्षित उत्तर या output परखने का तरीक़ा होता है। इसे **असली या यथार्थपूर्ण traffic** से बनाएँ (व्यक्तिगत डेटा हटाकर), सामान्य अनुरोध, पेचीदा किनारे के मामले, adversarial inputs और हर वह विफलता शामिल करें जिसे आपने कभी ठीक किया। 50 से 200 मामलों से शुरू करें, उन्हें सावधानी से label करें, उन्हें **prompts ट्यून करने वाले उदाहरणों से अलग** रखें (ताकि ख़ुद को धोखा न दें), और समय के साथ set बढ़ाएँ।

## भरोसे से पहले मापें

Evaluation "ठीक लग रहा है" को ऐसे अंकों में बदलता है जिनकी आप तुलना, ट्रैकिंग और बचाव कर सकें।

![चार चरण: dataset, metric, अनिश्चितता, तुलना।](assets/figures/ai-safety/section-5-map.svg) — चित्र 5.1 — Dataset, metric, अनिश्चितता और तुलना।

## डेटा के रूप में evaluation मामला

मामलों को डेटा के रूप में रखने से उनकी समीक्षा, versioning और दोबारा चलाना आसान होता है। Tags से आप slice के अनुसार नतीजे बता सकते हैं।

```json
{
  "id": "warranty-001",
  "input": "How long is the warranty on the X200?",
  "expected": "12 months",
  "check": "contains",
  "tags": ["en", "factual", "policy"]
}
```

## Held-out set रखें

यदि आप उन्हीं मामलों के पास होने तक prompt बदलते रहें, तो आपका score असली गुणवत्ता नहीं दिखाता। कुछ मामले अलग रखें जिन पर आप कभी ट्यून न करें और उन्हें सिर्फ़ अंतिम जाँच में उपयोग करें।

**Quiz:** कुछ evaluation मामले ट्यूनिंग से अलग क्यों रखें?

- [ ] Disk जगह बचाने के लिए
- [x] ताकि उन्हीं मामलों पर ट्यूनिंग से अंतिम score फूला हुआ न हो
- [ ] क्योंकि वे गुप्त हैं
- [ ] इससे tests धीमे होते हैं

*Answer:* ताकि उन्हीं मामलों पर ट्यूनिंग से अंतिम score फूला हुआ न हो. Test मामलों पर ट्यूनिंग आशावादी score देती है जो production में नहीं टिकता।