लेबलिंग इंजन कॉन्ट्रैक्ट

कॉन्ट्रैक्ट तैयार लेबलों के बारे में एक दावा है, जिसे लेबलिंग इंजन एक यादृच्छिक नमूने के मानव लेबलों पर परखता है। हर कॉन्ट्रैक्ट एक एनोटेशन स्कीमा (schema) का नाम लेता है और उसका एक confidence होता है, डिफ़ॉल्ट रूप से 0.9, जो इस बात की प्रायिकता है कि दावा सही है। इसलिए 0.9 का confidence इस बात की 10% संभावना छोड़ता है कि पूरा हुआ कॉन्ट्रैक्ट गलत हो।

छह प्रकार अलग-अलग दावे करते हैं और अलग-अलग अध्ययनों के लिए सही हैं:

इनमें से कोई भी कॉन्ट्रैक्ट यह नहीं कहता कि लेबलों में कोई त्रुटि नहीं है। selective_risk स्वीकार किए गए लेबलों में त्रुटि दर की सीमा बाँधता है, और मशीनों को परखने वाला हर कॉन्ट्रैक्ट उन्हें उन लोगों के मुकाबले मापता है जिन्होंने नमूने पर लेबल लगाए।

कॉन्ट्रैक्ट की स्थिति

हर कॉन्ट्रैक्ट की पाँच में से एक स्थिति होती है, जो एडमिन पेज पर, potato label status में और प्रमाणपत्र में दिखती है:

कोई मशीन लेबल तभी स्वीकार किया जाता है जब उसकी स्कीमा पर हर selective_risk और threshold_legacy कॉन्ट्रैक्ट पूरा हो और उसे स्वीकार करे। कॉन्ट्रैक्ट बताते हैं कि लेबलों को क्या शर्त पूरी करनी है, इसलिए पूरा न हुआ कॉन्ट्रैक्ट छोड़ा नहीं जाता, बल्कि स्वीकृति को रोकता है, और स्थिति, एडमिन पेज और प्रमाणपत्र उस कॉन्ट्रैक्ट का नाम बताते हैं जो पूरा नहीं हुआ। जब कोई नियम लागू नहीं हो सकता और आगे कोई नमूना नहीं लिया जा रहा (कोई कॉन्ट्रैक्ट infeasible है, कैलिब्रेशन नमूना पूरा हो चुका है, या कोई अनुमान नहीं लगाया जा सका), तो जिन आइटमों का अभी भी कोई लेबल नहीं है, वे budgets.human_labels के भीतर लोगों के पास जाते हैं।

dev और cert स्प्लिट

इंजन नियम चुनने वाले लेबलों को उसे परखने वाले लेबलों से अलग रखता है। कैलिब्रेशन अनुरोध यादृच्छिक रूप से चुने जाते हैं और उनके चुने जाने की प्रायिकता दर्ज होती है, वे हमेशा ब्लाइंड होते हैं, और हर एक यादृच्छिक रूप से दो में से एक स्प्लिट में जाता है:

• dev (humans.dev_fraction, डिफ़ॉल्ट रूप से आधा) कैलिब्रेटर फ़िट करता है और थ्रेशोल्ड चुनता है;
• cert चुने गए नियम को परखता है, और उसे और कुछ नहीं पढ़ता।

परीक्षण-दौर (looks)

किसी कॉन्ट्रैक्ट का हर नया परीक्षण ज़्यादा सख्त स्तर पर चलता है, इसलिए लेबल आने के साथ बार-बार परखने से विश्वास बढ़ा-चढ़ा नहीं दिखता। परीक्षण-दौर k को त्रुटि बजट का (1 - confidence) * 6 / (pi^2 k^2) हिस्सा मिलता है, जो सभी संभव दौरों पर जोड़ने से पूरा बजट बनता है, और पहले दौर को उसका 61% मिलता है।

• परीक्षण-दौर हर कॉन्ट्रैक्ट के लिए अलग गिने जाते हैं, उन सभी कैस्केड पर जिनके तहत उसे परखा गया है, और नया नाम दिया गया कॉन्ट्रैक्ट अपनी पुरानी id के दौर अपने साथ रखता है। किसी के पास होने तक प्रॉम्प्ट या मॉडल आज़माने पर हर बार एक दौर खर्च होता है। किसी पुराने कैस्केड पर लौटना भी एक नया दौर है, और उसका पहले वाला परिणाम बहाल नहीं होता।
• उसी डेटा को दोबारा परखना नया दौर नहीं है। वही cert लेबल, वही भविष्यवाणियाँ और dev पर चुना गया वही नियम, संग्रहीत परिणाम लौटा देते हैं। जो परीक्षण चलाया ही नहीं जा सका, उदाहरण के लिए किसी वर्ग में कोई cert लेबल न होने पर, उस पर कुछ खर्च नहीं होता।
• potato label certify नए cert लेबलों और नई भविष्यवाणियों को एक साथ परखता है, और यही इसके REST, MCP और SDK समकक्ष करते हैं। जब केवल dev लेबल बदले हों, तो यह संग्रहीत परिणाम लौटाता है, साथ में यह टिप्पणी कि dev अब कोई दूसरा नियम चुनता है, और --retest उस नियम को अगले दौर पर परखता है।
• लेबल आने के साथ प्लानर अपने आप प्रमाणित करता है। पूरा हुआ selective_risk कॉन्ट्रैक्ट अपने कैस्केड के लिए पूरा ही रहता है, और ऑडिट उस पर नज़र रखते हैं। जो कॉन्ट्रैक्ट पूरा नहीं हुआ, उसे तब दोबारा परखा जाता है जब उसके लेबल एक चौथाई, और कम से कम 10, बढ़ जाएँ। ppi, distributional और no_worse_than_human के परिणाम पास/फ़ेल परीक्षण नहीं, अनुमान हैं, इसलिए प्लानर उन्हीं पड़ावों पर उनका दोबारा अनुमान लगाता है, और एक बार तब जब कैलिब्रेशन नमूना पूरा हो जाता है।
• संपादित cert लेबल नया डेटा है। जब कोई एनोटेटर अपना उत्तर बदलता है, तो उस संपादन पर किसी नए लेबल से ज़्यादा खर्च नहीं होता। संपादन से कोई ऐसी स्थिति लौट आए जो पहले परखी जा चुकी है, तो उस परीक्षण का परिणाम लौट आता है। अगर संपादन के बाद संग्रहीत परिणाम का कोई भी परीक्षण ज़्यादा त्रुटियाँ नहीं देखता, तो परिणाम और उसका दौर बने रहते हैं। वरना प्लानर तब तक प्रतीक्षा करता है जब तक लेबल पहले संपादन से एक चौथाई न बढ़ जाएँ, ताकि सुधारों की झड़ी एक ही परीक्षण बने, और इस बीच स्वीकार किए गए लेबल स्वीकार ही रहते हैं, कॉन्ट्रैक्ट पर एक टिप्पणी के साथ। जब और लेबल नहीं आने वाले होते, तो वह तुरंत परखता है, और स्पष्ट रूप से किया गया certify अगले दौर पर परखता है।

लोगों ने मशीन का उत्तर देखने के बाद जो लेबल दिए (सत्यापन अनुरोध), और जो लेबल इंजन के अनुरोधों के बाहर दिए गए, वे कभी कुछ प्रमाणित नहीं करते और न ही किसी अनुमान में जाते हैं। उनसे एक डिस्टिल्ड मॉडल प्रशिक्षित किया जा सकता है।

selective_risk

selective_risk स्वीकार किए गए मशीन लेबलों में गलत लेबलों के अनुपात की सीमा बाँधता है। error कुंजी स्वीकार किए गए लेबलों में सहन की जाने वाली सबसे बड़ी त्रुटि दर है और अनिवार्य है:

- id: accuracy
  kind: selective_risk
  schema: sentiment
  error: 0.05          # required: largest tolerated error among accepted labels
  confidence: 0.9
  per_class: true      # test each predicted class separately
  tolerance: 0.5       # graded families only: loss at or below this counts as correct

नियम हर कैस्केड स्तर के लिए, और per_class के साथ हर भविष्यवाणी किए गए वर्ग के लिए, एक विश्वास थ्रेशोल्ड है। आखिरी को छोड़कर हर स्तर के लिए थ्रेशोल्ड dev पर चुना जाता है और cert पर एक बार परखा जाता है। आखिरी स्तर dev के चुने थ्रेशोल्ड से शुरू करके ज़्यादा उदार थ्रेशोल्ड आज़माता है, हर एक को बारी-बारी परखता है और पहले विफल होने वाले पर रुक जाता है। यह प्रक्रिया fixed-sequence Learn-then-Test (Angelopoulos et al., 2025) है। हर परीक्षण एक एक-तरफ़ा द्विपद परीक्षण है कि स्वीकार किए गए लेबलों में त्रुटि error से ऊपर है, और स्तर को कैस्केड स्तरों और वर्गों में बाँटा जाता है। जो स्तर विफल होता है, वह कुछ भी स्वीकार नहीं करता, और उसके आइटम लोगों के पास जाते हैं।

"सही" किसे गिना जाएगा, यह स्कीमा परिवार पर निर्भर करता है। हर परिवार का लॉस तालिका में है, और कोई लेबल तब सही गिना जाता है जब उसका लॉस tolerance के बराबर या उससे कम हो:

क्षेत्रों, सेगमेंट, 3D ऑब्जेक्ट और ट्रेस के लॉस वही हैं जिनका उपयोग /admin/iaa पर सहमति रिपोर्ट करती है, इसलिए किसी मशीन को किसी व्यक्ति के मुकाबले उसी तरह आँका जाता है जैसे दो लोगों को एक-दूसरे के मुकाबले। फ़्री टेक्स्ट और पेयरवाइज़ स्कीमा का अभी कोई परिवार नहीं है, और प्रमाणपत्र उन्हें असमर्थित के रूप में सूचीबद्ध करता है।

परीक्षण के लिए ज़रूरी है कि cert आइटमों का हर परखा गया समूह एक समान नमूना हो। जिस समूह के आइटम असमान प्रायिकताओं से चुने गए, उसे परखा नहीं जाता, और परिणाम उसका नाम बताता है।

आखिरी स्तर पर, dev पर थ्रेशोल्ड तभी चुना जाता है जब dev की त्रुटि लक्ष्य के आधे से अधिक न हो और उम्मीद हो कि पहले परीक्षण को पास करने लायक cert लेबल मिल जाएँगे। और कितने लेबल चाहिए, इसका अनुमान केवल उन्हीं थ्रेशोल्ड को गिनता है जो इस तरह चुने जा सकते हों। जब cert के पास पहले से उतने लेबल हों जितने अनुमान ने माँगे थे और परीक्षण फिर भी विफल हो, तो अगला अनुमान उस त्रुटि दर का उपयोग करता है जो dev और cert मिलकर दिखाते हैं, न कि केवल dev की। जब dev की सबसे कम त्रुटि लक्ष्य से कम लेकिन उसके आधे से ऊपर हो, तो न कुछ परखा जाता है, न कोई अनुमान लगाया जाता है। परिणाम यह बताता है और त्रुटि का मान देता है, क्योंकि और लेबल तभी मदद करते हैं जब त्रुटि कम निकले।

metrics.accepted_by_tier पूरी आबादी पर नियम का कवरेज है, कैलिब्रेशन आइटमों सहित, और यह दिए गए मशीन लेबलों की गिनती नहीं है। उनकी गिनती प्रमाणपत्र की "Machine labels accepted, by source" पंक्ति करती है।

ट्रेस लॉस केवल उन चरणों की तुलना करता है जिन पर दोनों पक्षों ने लेबल लगाए, इसलिए जिस व्यक्ति ने कुछ चरण चिह्नित किए, उसकी तुलना उन्हीं चरणों पर होती है। जिन चरणों पर किसी ने लेबल नहीं लगाया, उनकी जाँच नहीं होती, और जो व्यक्ति केवल चरण 0 पर लेबल लगाता है और वहाँ जज से सहमत होता है, उसे पूरे ट्रेस लेबल से सहमत गिना जाता है। जहाँ हर चरण की जाँच ज़रूरी हो, वहाँ लोगों से हर चरण पर लेबल लगाने को कहें।

ppi

ppi हर लेबल के प्रचलन, या किसी माध्य स्कोर, का एक अंतराल रिपोर्ट करता है, जिसे मशीन की त्रुटियों के लिए सुधारा गया हो:

- id: prevalence
  kind: ppi
  schema: sentiment
  estimand: prevalence   # or mean, for numeric scores
  by: language           # optional: an interval per value of this item field
  confidence: 0.95
  max_width: 0.05        # optional: met once every interval is at most this wide

Prediction-powered inference (Angelopoulos et al., 2023) मशीन के अनुमान को मानव-लेबल वाले नमूने पर उसकी त्रुटि से सुधारता है। मशीन की गुणवत्ता चाहे जैसी हो, अंतराल मान्य रहता है। अच्छी मशीन उसे उससे संकरा बना देती है जितना केवल लोगों से बनता, और खराब मशीन उसे चौड़ा नहीं करती। चुने जाने की प्रायिकताएँ बराबर हों तो इंजन एक ट्यून किए गए भार के साथ PPI++ का उपयोग करता है, और असमान हों (स्तरीकृत या अनिश्चितता-आधारित नमूना चयन) तो Horvitz-Thompson difference estimator का। वह जिस मशीन लेबल का उपयोग करता है, वह वही है जो कैस्केड देता। by फ़ील्ड आइटमों के पंजीकरण के समय उनसे कॉपी किया जाता है। max_width के बिना, कॉन्ट्रैक्ट रिपोर्ट करने लायक लेबल मिलते ही पूरा हो जाता है।

no_worse_than_human

no_worse_than_human पूछता है कि क्या मशीन लोगों से कम से कम उतनी बार सहमत होती है जितनी बार कोई व्यक्ति:

- id: replaces-a-person
  kind: no_worse_than_human
  schema: verdict
  epsilon: 0.1

कॉन्ट्रैक्ट alternative annotator test (Calderon et al., 2025) चलाता है। बारी-बारी से हर व्यक्ति को अलग रखकर, यह परखता है कि क्या मशीन बाकी लोगों से कम से कम उतनी बार सहमत होती है जितनी बार अलग रखा गया व्यक्ति, epsilon तक की छूट के साथ। मशीन तब पास होती है जब वह कम से कम आधे लोगों के मुकाबले जीतती है, जबकि लोगों के बीच false discovery rate नियंत्रित रहती है।

परीक्षण के लिए ऐसे आइटम चाहिए जिन पर कई लोगों ने लेबल लगाए हों। humans.overlap (नमूने का वह हिस्सा जिस पर एक से ज़्यादा बार लेबल लगे) और humans.overlap_k (प्रति आइटम लोग, कम से कम 3) सेट करें, और परीक्षण के लिए कम से कम 3 एनोटेटर चाहिए जिनमें से हर एक के 30 आइटम हों। जब तक ये नहीं मिलते, कॉन्ट्रैक्ट insufficient रहता है। इस कॉन्ट्रैक्ट का उपयोग तब करें जब कोई तय सटीकता लक्ष्य ज़्यादातर एनोटेटरों का शोर ही मापेगा। अगर दो सावधान लोग 85% बार सहमत होते हैं, तो किसी भी लेबल लगाने वाले को 95% "सही" साबित नहीं किया जा सकता।

budget_first

budget_first खर्च करने से पहले अनुमान लगाता है कि मानव लेबलों के एक बजट से क्या मिलेगा:

- id: plan
  kind: budget_first
  schema: sentiment
  human_labels: 500      # or human_usd, priced at the crowd reward

अनुमान अब तक जुटाए गए dev लेबलों से आता है। एक ग्रिड पर हर त्रुटि लक्ष्य के लिए, यह बताता है कि इस बजट से कॉर्पस के कितने हिस्से पर मशीनों को लेबल लगाने के लिए प्रमाणित किया जा सकता है, और हर प्रचलन अंतराल कितना चौड़ा होगा। अनुमान लगाने लायक dev लेबल मिलते ही कॉन्ट्रैक्ट met हो जाता है। यह लेबलों के बारे में कोई वादा नहीं करता, जो काम लेबल आ जाने के बाद selective_risk और ppi करते हैं।

distributional

distributional मशीन के लेबलों के वितरण की तुलना इससे करता है कि लोगों की राय कैसे बँटती है, उन व्यक्तिपरक टास्क के लिए जहाँ लोग ऐसे कारणों से असहमत होते हैं जो डेटा का हिस्सा होने चाहिए:

- id: disagreement
  kind: distributional
  schema: offensiveness
  max_distance: 0.15     # optional
  groups_by: age_band    # optional: a prestudy question whose answer groups the annotators

जिस आइटम पर कई लोगों ने लेबल लगाए (humans.distribution_k, डिफ़ॉल्ट रूप से 5), उसका एक मानव लेबल वितरण होता है। कॉन्ट्रैक्ट मशीन के वितरण और लोगों के वितरण के बीच औसत Jensen-Shannon distance रिपोर्ट करता है, एक बूटस्ट्रैप अंतराल के साथ। यह एक शोर सीमा भी रिपोर्ट करता है, यानी हर आइटम पर लोगों के दो यादृच्छिक आधे हिस्सों के बीच वही दूरी। जो मशीन लोगों के उतने करीब है जितने लोग एक-दूसरे के, वह उतनी करीब है जितना डेटा अनुमति देता है।

जहाँ स्रोत प्रायिकताएँ देता है (निर्णय मॉडल, k_sample, logprob), वहाँ मशीन का वितरण उसकी प्रायिकताएँ होती हैं, वरना एक one-hot वेक्टर के रूप में उसका लेबल। कॉन्ट्रैक्ट तब पूरा होता है जब अंतराल का ऊपरी सिरा max_distance से अधिक न हो, या, max_distance के बिना, जब ऐसे 20 आइटम हो जाएँ जिन पर 3 या अधिक लोगों ने लेबल लगाए हों। जब अंतराल का निचला सिरा max_distance से ऊपर होता है, तो वह infeasible होता है, क्योंकि और आइटम केवल एक बहुत बड़ी दूरी के आसपास अंतराल को संकरा करेंगे।

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

threshold_legacy

threshold_legacy एक तय विश्वास से ऊपर के मशीन लेबल स्वीकार करता है और कोई सांख्यिकीय परीक्षण नहीं चलाता:

- id: old-rule
  kind: threshold_legacy
  schema: sentiment
  threshold: 0.8

potato label migrate-config यह कॉन्ट्रैक्ट icl_labeling के लिए पुराने confidence_threshold पर लिखता है, ताकि अनुवादित कॉन्फ़िग पहले जैसा व्यवहार करे, और आप इसे हाथ से भी लिख सकते हैं। प्रमाणपत्र इन लेबलों को अप्रमाणित चिह्नित करता है और कैलिब्रेशन लेबलों पर उनकी मापी गई त्रुटि रिपोर्ट करता है, और एक्सपोर्ट उन्हें accepted_uncertified स्थिति देता है।

उदाहरण अध्ययनों के परिणाम

examples/labeling-engine/ के अंतर्गत तीनों उदाहरण अध्ययन इस तरह चलाए गए कि LLM, जज और विज़न स्रोत, कमिट किए गए कॉन्फ़िग वाले Ollama मॉडलों के बजाय, एक vLLM सर्वर पर Gemma 12B की ओर इशारा करते थे। हर उदाहरण का README बदला गया स्रोत ब्लॉक दिखाता है, और Ollama के डिफ़ॉल्ट के साथ आँकड़े अलग आएँगे।

• टेक्स्ट सेंटिमेंट (481 समीक्षाएँ, आखिरी स्तर के रूप में logprob विश्वास वाला Gemma 12B)। 10% और 0.9 पर selective_risk 165 मानव लेबलों पर पूरा हुआ, और 316 मशीन लेबल स्वीकार किए गए। सच्चे लेबलों के मुकाबले उनकी मापी गई त्रुटि 7.6% थी, और PPI अंतरालों ने तीनों लेबलों के सच्चे प्रचलन को कवर किया।
• इमेज (128 COCO इमेज, YOLOv8n और विज़न मॉडल के रूप में Gemma 12B)। एक has-person लेबल 10% पर प्रमाणित हुआ। बॉक्स कॉन्ट्रैक्ट insufficient रहा, क्योंकि IoU 0.5 पर YOLOv8n के बॉक्स 32% dev इमेज पर गलत थे।
• एजेंट ट्रेस (288 ट्रेस, जज के रूप में Gemma 12B)। जज 80% ट्रेस पर सही था, लेकिन उसका विश्वास हर जगह 1.0 था, इसलिए selective_risk infeasible रहा। alternative annotator test insufficient रहा, जिसमें मशीन 0.82 पर थी और लोग 0.93 पर। PPI ने टास्क सफलता का अनुमान 0.66 [0.57, 0.76] लगाया, जबकि सच्चा मान 0.60 था और अकेले जज ने 0.76 कहा था, यानी 16 अंक ज़्यादा।

आगे पढ़ें

• लेबलिंग इंजन
• लेबलिंग इंजन कॉन्फ़िगरेशन, जिसमें वे humans कुंजियाँ भी हैं जिन्हें ये कॉन्ट्रैक्ट पढ़ते हैं
• इंटर-एनोटेटर सहमति, और ज्यामिति पर सहमति, जो क्षेत्रों, सेगमेंट और 3D ऑब्जेक्ट के लिए वही लॉस उपयोग करती है

कार्यान्वयन विवरण के लिए, स्रोत दस्तावेज़ देखें।

संदर्भ

1. Angelopoulos, A. N., Bates, S., Candès, E. J., et al. (2025). Learn then test: Calibrating predictive algorithms to achieve risk control. The Annals of Applied Statistics. https://doi.org/10.1214/24-AOAS1998
2. Angelopoulos, A. N., Bates, S., Fannjiang, C., et al. (2023). Prediction-powered inference. Science, 382(6671). https://doi.org/10.1126/science.adi6000
3. Angelopoulos, A. N., Duchi, J. C., and Zrnic, T. (2023). PPI++: Efficient prediction-powered inference. arXiv. https://arxiv.org/abs/2311.01453
4. Calderon, N., Reichart, R., and Dror, R. (2025). The alternative annotator test for LLM-as-a-judge: How to statistically justify replacing human annotators with LLMs. Proceedings of ACL 2025. https://aclanthology.org/2025.acl-long.782/