Skip to content

डेटासेट और मॉडल का दस्तावेज़ीकरण: Datasheets, Data Statements और Model Cards

एनोटेटेड डेटा और उस पर बने मॉडल के लिए तीन मानक दस्तावेज़ीकरण ढाँचों का संदर्भ, हर एक किन बातों को समेटता है, कब किसे चुनें, और reproducibility की रिपोर्टिंग इन्हें आपस में कैसे जोड़ती है।

मशीन-लर्निंग डेटा के लिए तीन दस्तावेज़ीकरण मानक चलन में आ चुके हैं: डेटासेट के लिए data statement और datasheet, और उस पर प्रशिक्षित चीज़ के लिए model card। इनमें काफ़ी ओवरलैप है, और अगर आप चाहते हैं कि आपके डेटा पर लोग भरोसा करें और उसे दोबारा इस्तेमाल करें तो इनमें से कोई भी वैकल्पिक नहीं है। यह गाइड इसका संदर्भ है कि हर मानक क्या समेटता है और कब किसकी ज़रूरत पड़ती है। इनमें से कोई एक लिखने की विस्तृत कहानी के लिए साथी पोस्ट अपने एनोटेशन डेटासेट का दस्तावेज़ीकरण देखें; यह पृष्ठ मानकों की तुलना है।

README नहीं, संरचित दस्तावेज़ीकरण क्यों

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

तीन मानक

हर ढाँचा एक अलग कलाकृति और अलग पाठक-वर्ग को ध्यान में रखता है, पर इन्हें आपस में जुड़ने के लिए ही बनाया गया था।

Data statements (Bender और Friedman, 2018) NLP-विशिष्ट स्कीमा हैं। ये किसी भाषा डेटासेट का ब्योरा देते हैं, यानी curation का कारण, भाषा-भेद और उसके बोलने वाले, एनोटेटर की जनसांख्यिकी, दिशानिर्देश, और इच्छित उपयोग, ताकि पढ़ने वाला आँक सके कि नतीजे कहाँ तक सामान्य होंगे और डेटा में कौन-सी आबादी कम दर्ज है। जब डेटा पाठ हो और भाषा-भेद मायने रखता हो, तब data statement चुनें।

Datasheets for datasets (Gebru आदि, 2021) इसका सामान्य-प्रयोजन रूप हैं, जो इलेक्ट्रॉनिक्स से लिया गया है, जहाँ हर कल-पुर्ज़े के साथ एक datasheet आती है। ये motivation, संरचना, संग्रह प्रक्रिया, प्रीप्रोसेसिंग, अनुशंसित उपयोग और रखरखाव, इन सब पर एक तयशुदा प्रश्न-सूची पूछती हैं। किसी भी ML डेटासेट के लिए datasheet इस्तेमाल करें, चाहे वह पाठ हो या न हो; data statement से इसका ओवरलैप बहुत ज़्यादा है, इसलिए भाषा डेटासेट पर असल में आप यही चुन रहे होते हैं कि किस प्रश्न-सूची के इर्द-गिर्द चीज़ें व्यवस्थित करनी हैं, दोनों शून्य से लिखनी नहीं होतीं।

Model cards (Mitchell आदि, 2019) डेटा नहीं, मॉडल का दस्तावेज़ीकरण करते हैं: उसका इच्छित उपयोग, और सबसे अहम, उसका प्रदर्शन एक कुल आँकड़े के रूप में नहीं बल्कि जनसांख्यिकीय और अन्य समूहों के हिसाब से बाँटकर। निष्पक्षता की कोई समस्या दिखती ही model card में है।

तीनों मिलकर एक chain बनाते हैं। Datasheet या data statement डेटा का दस्तावेज़ीकरण करता है; model card बताता है कि उस पर क्या बनाया गया; और पहले वाले का एनोटेटर-जनसांख्यिकी खंड ही आख़िरी वाले के समूह-वार मूल्यांकन को समझने लायक बनाता है। एनोटेशन का दस्तावेज़ीकरण ठीक से कर लें तो एक टिकाऊ model card का ज़्यादातर हिस्सा वैसे ही तैयार हो जाता है।

ढाँचाकिसका दस्तावेज़किसके लिए सबसे उपयुक्तमुख्य खंड
Data statementकोई भाषा डेटासेटNLP / पाठ डेटाCuration का कारण, भाषा-भेद, वक्ता + एनोटेटर जनसांख्यिकी, दिशानिर्देश
Datasheetकोई भी ML डेटासेटसामान्य ML डेटाMotivation, संरचना, संग्रह, उपयोग, रखरखाव
Model cardप्रशिक्षित मॉडलकोई भी जारी मॉडलइच्छित उपयोग, समूह-वार मूल्यांकन, सीमाएँ

Reproducibility चौथा पाया है

दस्तावेज़ीकरण और reproducibility एक ही लक्ष्य के दो पहलू हैं। Pineau आदि (2021) ने NeurIPS के reproducibility कार्यक्रम पर रिपोर्ट दी और उसे एक reproducibility चेकलिस्ट में समेटा: ठीक-ठीक डेटा बताएँ, संग्रह और प्रीप्रोसेसिंग के चरण बताएँ, मूल्यांकन का सेटअप बताएँ, और इतना ब्योरा दें कि काम दोबारा चलाया जा सके। ख़ासकर किसी एनोटेशन परियोजना में reproducibility के लिए ज़रूरी तथ्य वही हैं जो datasheet पहले से पूछती है, यानी आइटम कैसे सैंपल हुए, दिशानिर्देश का कौन-सा संस्करण चला, एनोटेट किसने किया, और असहमति को कैसे निपटाया गया। इन सवालों के जवाब हैं तो डेटासेट दस्तावेज़ीकृत भी है और पुनरुत्पाद्य भी; नहीं हैं तो यह जारी करने के बाद नहीं, पहले पाटने वाली खाई है।

जारी करने से पहले की चेकलिस्ट

प्रकाशित करने से पहले पक्का कर लें कि इनके जवाब आपके पास हैं:

  • आइटम कैसे सैंपल किए गए, और कहाँ से?
  • यह कौन-सा भाषा-भेद है, और स्रोत पाठ किसने लिखा?
  • एनोटेट किसने किया, कितने लोगों ने, और पूल की जनसांख्यिकीय बनावट क्या है?
  • उन्होंने कौन-से दिशानिर्देश माने, और कौन-सा संस्करण?
  • असहमति को मिलाकर एक gold लेबल बनाया गया या उसे वितरण के रूप में रखा गया? दोनों ही सूरत में सहमति दर्ज करें।
  • यह डेटासेट किस काम के लिए है, और किस काम के लिए इसे इस्तेमाल नहीं करना चाहिए?

Potato में यह कैसे करें

किसी डेटासेट का ज़्यादातर दस्तावेज़ीकरण परियोजना की कलाकृतियों के रूप में पहले से मौजूद होता है, इसलिए आप ख़ाली पन्ने से शुरू नहीं कर रहे। Config ख़ुद दस्तावेज़ीकरण है: YAML में स्कीमा, लेबल सेट और कार्य की संरचना दर्ज रहती है, डेटा के साथ ही संस्करण-नियंत्रित, और आपने जो निर्देश लिखे थे वही ज्यों-के-त्यों दिशानिर्देश खंड बन जाते हैं। अगर आपने prestudy चरण चलाया था, तो एनोटेटर जनसांख्यिकी हर एनोटेटर के लिए पहले से सहेजी हुई है, उन्हें वितरण में जोड़कर एनोटेटर-जनसांख्यिकी खंड बना लें। और export हर लेबल के साथ एनोटेटर और टाइमस्टैम्प रखता है, इसलिए provenance छिनने के बजाय डेटा के साथ चलता है:

json
{
  "id": "doc_001",
  "annotations": { "sentiment": "positive" },
  "annotator": "user_1",
  "timestamp": "2024-01-15T10:30:00Z"
}

Hub पर प्रकाशित करते समय dataset card को export के आख़िरी चरण के तौर पर बनाएँ और उसके खंड config, दिशानिर्देशों और prestudy की जनसांख्यिकी से भर दें, जो आपके पास पहले से हैं।

आगे पढ़ें