Crowdsourced एनोटेशन के लिए गुणवत्ता नियंत्रण

कोई एक जाँच हर तरह के ख़राब एनोटेशन को नहीं पकड़ती, इसलिए चार जाँचें परतों में लगाएँ: पढ़ न रहे एनोटेटरों के लिए attention check, पढ़कर भी ग़लत जवाब देने वाले एनोटेटरों के लिए gold standard, अस्पष्ट आइटमों के लिए ओवरलैप, और इतनी तेज़ी से जमा हुए काम के लिए समय का डेटा कि वह असल में किया ही न गया हो। हर जाँच की अपनी Potato config key है, और हर एक admin dashboard में अलग से रिपोर्ट करती है।

गुणवत्ता नियंत्रण डेटा इकट्ठा करने से पहले सबसे सस्ता पड़ता है और बाद में सबसे महँगा। पाँचवीं बार विफल होने पर एनोटेटर को ब्लॉक करने वाला attention check कॉन्फ़िगर करने में कुछ ख़र्च नहीं होता और उन आइटमों को बचा लेता है जिन्हें वह एनोटेटर भरता; वही समस्या बाद में किसी स्क्रिप्ट से मिले तो आपको दोबारा डेटा इकट्ठा करना पड़ता है। नीचे के नियंत्रण इस क्रम में रखे गए हैं कि वे कब काम करते हैं।

समय के साथ गुणवत्ता नियंत्रण

हर नियंत्रण क्या पकड़ता है

चारों नियंत्रण अलग-अलग दिशाओं में चूकते हैं, और एक से ज़्यादा चलाने की वजह यही है।

सहमति ख़ास तौर पर सब कुछ नहीं पकड़ती। जब एनोटेटर किसी मॉडल के पहले से लगाए लेबल की समीक्षा करते हैं, तो सुझाव को बिना पढ़े स्वीकार करने से सहमति घटने के बजाय बढ़ती है, इसलिए बिना देखे मुहर लगाने वाला एनोटेटर इस माप पर सबसे अच्छा दिखता है। सहमति बिना देखे मुहर लगाने को नहीं पकड़ सकती बताता है कि इसके बजाय क्या दर्ज करना चाहिए।

Attention check

Attention check ऐसे आइटम हैं जिनका जवाब पहले से पता होता है। उन्हें एक तय अंतराल पर एनोटेशन के प्रवाह में डाला जाता है, और वे जाँचते हैं कि एनोटेटर जवाब देने से पहले पढ़ रहा है। Potato उन्हें डालता है, जाँचता है, एनोटेटर को चेतावनी देता है, और आपकी तय की हुई सीमा पर उसे ब्लॉक कर देता है, इसलिए पूरा चक्र बाद में चलने वाली किसी स्क्रिप्ट के बजाय सर्वर पर चलता है।

आवृत्ति इस हिसाब से तय करें कि आपके आइटमों में कितना समय लगता है। हर 10 आइटम पर एक जाँच इतनी बार होती है कि किसी सत्र के भीतर ही भटकते एनोटेटर को पकड़ ले, और बजट का बड़ा हिस्सा ग़ैर-डेटा आइटमों पर ख़र्च न हो। min_response_time की न्यूनतम सीमा वह चीज़ है जो पढ़ने के बजाय बस क्लिक करने को पकड़ती है, और उससे तेज़ आया जवाब, चाहे जो भी कहे, विफल माना जाता है:

attention_checks:
  enabled: true
  items_file: "data/attention_checks.json"
  frequency: 10              # one check every 10 items
  min_response_time: 3.0     # seconds; faster than this fails the check
 
  failure_handling:
    warn_threshold: 2
    warn_message: "Please read items carefully before answering."
    block_threshold: 5
    block_message: "You have been blocked due to too many incorrect responses."

आइटम फ़ाइल हर जाँच को एक id, एनोटेटर को दिखने वाला टेक्स्ट, और हर scheme के लिए अपेक्षित जवाब देती है:

[
  {
    "id": "attn_001",
    "text": "Please select 'Positive' for this item to verify you are reading carefully.",
    "expected_answer": {
      "sentiment": "positive"
    }
  }
]

नतीजे restart के बाद भी बने रहते हैं। Potato उन्हें दर्ज होते ही आउटपुट डायरेक्टरी में quality_control_results.json में लिखता है और शुरू होने पर वापस पढ़ लेता है, इसलिए कोई deploy किसी एनोटेटर के विफलता इतिहास को मिटाता नहीं और न ही किसी ब्लॉक किए गए व्यक्ति को अनब्लॉक करता है।

Gold standard

Gold standard विशेषज्ञों के लेबल किए हुए आइटम हैं, जिन्हें ध्यान के बजाय सटीकता मापने के लिए प्रवाह में मिलाया जाता है। डिफ़ॉल्ट रूप से वे चुपचाप चलते हैं, यानी नतीजे admin dashboard में जाते हैं और एनोटेटर को कोई फ़ीडबैक नहीं दिखता, जिससे गुणवत्ता उस व्यवहार को बदले बिना मापी जाती है जिसे आप माप रहे हैं। जब आप एनोटेटरों को छाँटने के बजाय प्रशिक्षित कर रहे हों, तब फ़ीडबैक चालू करें।

Gold आइटम हर frequency आइटम पर डाले जाते हैं, इसलिए यह सेटिंग माप की सटीकता और बजट के उस हिस्से के बीच संतुलन बनाती है जो उन आइटमों पर जाता है जिनके लेबल आपके पास पहले से हैं। 20 में से एक रखने पर 500 आइटम की एक शिफ़्ट में लगभग 25 जाँचे गए आइटम मिलते हैं:

gold_standards:
  enabled: true
  items_file: "data/gold_standards.json"
  mode: mixed                # mixed injects into the stream; this is the implemented mode
  frequency: 20
 
  accuracy:
    min_threshold: 0.7       # annotators below this are named in the dashboard
    evaluation_count: 10     # evaluate once an annotator has seen 10 gold items
 
  feedback:
    show_correct_answer: false
    show_explanation: false

आइटम फ़ाइल में हर scheme का सही एनोटेशन होता है, और फ़ीडबैक वाले मामले के लिए एक वैकल्पिक व्याख्या भी:

[
  {
    "id": "gold_001",
    "text": "The service was absolutely terrible and I will never return.",
    "gold_label": {
      "sentiment": "negative"
    },
    "explanation": "Strong negative language indicates negative sentiment.",
    "difficulty": "easy"
  }
]

ऐसे gold आइटम चुनें जो किसी विशेषज्ञ के लिए अस्पष्ट न हों। जिस आइटम पर आपकी अपनी टीम में बहस होती हो, वह एनोटेटर के बजाय दिशानिर्देशों को मापता है, और सक्षम एनोटेटरों को सीमा से नीचे धकेल देगा। जब एनोटेटर किसी आइटम पर एकमत हों, तो Potato gold_standards.auto_promote के ज़रिए उसे gold में भी बदल सकता है, जिससे विशेषज्ञों की अतिरिक्त लेबलिंग के बिना संग्रह बढ़ता है।

हर एनोटेटर की सटीकता /admin/api/quality_control पर दिखती है, जो कुल योग के साथ configured_correct और configured_total भी बताता है। एनोटेटरों की तुलना करते समय configured संख्याएँ लें, क्योंकि configured संग्रह सबके लिए एक जैसा है, जबकि अपने-आप promote हुआ संग्रह इस पर निर्भर करता है कि कौन एनोटेटर कब आया।

ओवरलैप और सहमति

हर आइटम पर कई एनोटेटर रखना वह नियंत्रण है जो ख़राब एनोटेटरों के बजाय अस्पष्ट आइटम ढूँढता है। हर आइटम पर तीन आम डिफ़ॉल्ट है, क्योंकि तीन से aggregation के लिए बहुमत मिल जाता है और गुणांक के लिए पर्याप्त ओवरलैप भी। लक्ष्य तय करें और रिपोर्टिंग चालू करें:

num_annotators_per_item: 3
 
agreement_metrics:
  enabled: true
  min_overlap: 2
  refresh_interval: 60

इसके बाद एनोटेशन आते ही Krippendorff's alpha हर scheme के लिए admin dashboard में दिखने लगता है। एनोटेटरों के बीच सहमति मापना बताता है कि कौन-सा गुणांक रिपोर्ट करें और सीमाओं का क्या मतलब है।

समय और टेलीमेट्री

Potato यह दर्ज करता है कि हर आइटम में कितना समय लगा, सिर्फ़ यह नहीं कि जवाब क्या दिया गया। हर instance में एक behavioral_data ऑब्जेक्ट होता है जिसका total_time_ms उस आइटम पर लगा समय है, और उसके साथ interaction events, एनोटेशन के बदलावों का इतिहास, और AI सुझावों का जीवनचक्र भी होता है। यही फ़ील्ड उस एनोटेटर को, जो corpus आसान होने से तेज़ है, उस एनोटेटर से अलग करने देता है जो इसलिए तेज़ है कि वह देख ही नहीं रहा:

def flag_fast_annotations(export, min_seconds=2.0):
    """Instances submitted faster than a floor, from an exported annotation file."""
    flagged = []
    for instance in export:
        bd = instance.get("behavioral_data") or {}
        seconds = bd.get("total_time_ms", 0) / 1000
        if seconds < min_seconds:
            flagged.append((instance["id"], seconds))
    return flagged

समय को किसी तय सेकंड संख्या के मुक़ाबले नहीं, बल्कि अपनी परियोजना के भीतर एक वितरण के रूप में पढ़ें, क्योंकि जो सीमा किसी कठिन corpus पर बिना देखे मुहर लगाने को पकड़ती है, वही आसान corpus पर दक्षता को पकड़ लेती है। बनाए गए (drawn) एनोटेशन के लिए annotation_telemetry यही विचार और बारीक स्तर पर दर्ज करता है। इसका सबसे मज़बूत संकेत AI सुझाव के दिखने और एनोटेटर के उसे स्वीकार करने के बीच की देरी है। Behavioral tracking और drawing telemetry उन फ़ील्ड और उनसे बनने वाले फ़्लैग के बारे में बताते हैं।

चारों नियंत्रणों वाला एक कॉन्फ़िगरेशन

चारों keys एक-दूसरे से स्वतंत्र हैं, इसलिए कोई परियोजना उन्हें एक-एक करके अपना सकती है। साथ में वे ऐसी दिखती हैं:

annotation_task_name: "Sentiment Annotation with Quality Control"
task_description: "Classify the sentiment of short texts."
 
data_files:
  - data/items.json
 
item_properties:
  id_key: id
  text_key: text
 
annotation_schemes:
  - annotation_type: radio
    name: sentiment
    description: "What is the sentiment of this text?"
    labels:
      - Positive
      - Negative
      - Neutral
 
num_annotators_per_item: 3
 
attention_checks:
  enabled: true
  items_file: data/attention_checks.json
  frequency: 15
  min_response_time: 3.0
  failure_handling:
    warn_threshold: 2
    block_threshold: 5
 
gold_standards:
  enabled: true
  items_file: data/gold_standards.json
  mode: mixed
  frequency: 25
  accuracy:
    min_threshold: 0.7
    evaluation_count: 10
 
agreement_metrics:
  enabled: true
  min_overlap: 2
  refresh_interval: 60
 
output_annotation_dir: annotation_output

शुरुआत में सीमाएँ नरम रखें। 5 की ब्लॉक सीमा और 0.7 की न्यूनतम सटीकता से आप यह तय करने से पहले अपने एनोटेटर समूह का असली वितरण देख पाते हैं कि किसे विफलता माना जाए, और बाद में उन्हें सख़्त करने में कुछ ख़र्च नहीं होता। पहले ही दिन उन्हें कड़ा रखने से एनोटेटर उन दिशानिर्देशों के आधार पर बाहर हो जाते हैं जिन्हें अभी pilot में परखा ही नहीं गया।

प्लेटफ़ॉर्म के स्तर के नियंत्रण

Crowdsourcing प्लेटफ़ॉर्म किसी के आपके कार्य तक पहुँचने से पहले ही समूह की छँटाई कर देते हैं। यह ऊपर की जाँचों से अलग काम है, और उनके साथ-साथ करने लायक़ है।

• पूर्व-छँटाई। Prolific approval rate और पहले पूरे किए गए काम के आधार पर छाँटता है, और साथ ही जनसांख्यिकी और भाषा के आधार पर भी।
• Qualification test। Potato के प्रशिक्षण चरण में एक छोटा टेस्ट किसी भी प्लेटफ़ॉर्म पर मुख्य कार्य तक पहुँच को नियंत्रित करता है।
• भुगतान से पहले समीक्षा। काम ठीक हो तो जल्दी approve करें, क्योंकि धीमी approval ही वह बात है जिसकी शिकायत एनोटेटर सबसे ज़्यादा करते हैं, और rejection का इस्तेमाल कम करें क्योंकि इससे प्लेटफ़ॉर्म पर worker की साख को नुक़सान पहुँचता है।

प्लेटफ़ॉर्म की पूर्व-छँटाई और Potato की अपनी जाँचें एक-दूसरे की पूरक हैं। पूर्व-छँटाई तय करती है कि कार्य तक कौन पहुँचेगा; attention check और gold standard मापते हैं कि वहाँ पहुँचकर उन्होंने क्या किया।

कुछ भी इकट्ठा करने से पहले

दो फ़ैसले ऐसे हैं जिन्हें डेटा इकट्ठा करना शुरू होने के बाद पलटना मुश्किल है, इसलिए उन्हें पहले लें। तय करें कि export में आपको कौन-से फ़ील्ड चाहिए, क्योंकि बाद में सोचा गया समय का विश्लेषण तभी हो सकता है जब run के दौरान behavioral_data दर्ज हुआ हो। और सारे नियंत्रण चालू रखकर कुछ दर्जन आइटमों का pilot चलाएँ, क्योंकि pilot में ही पता चलता है कि आपके attention check अस्पष्ट हैं या आपके gold आइटम विवादित हैं, और इसकी क़ीमत एक पूरा डेटासेट नहीं, बस एक दोपहर होती है।

आगे पढ़ें

• Gold standard और attention check
• गुणवत्ता नियंत्रण सुविधा का संदर्भ
• प्रशिक्षण चरण, असली कार्य से पहले एनोटेटरों को तैयार करने के लिए
• असरदार एनोटेशन दिशानिर्देश लिखना
• क्राउडसोर्स्ड स्टडी चलाना
• Potato का गुणवत्ता नियंत्रण स्रोत दस्तावेज़