लेबलिंग इंजन

मॉडलों से किसी डेटासेट पर लेबल लगाइए, मशीन लेबलों को मानव लेबलों के एक ब्लाइंड यादृच्छिक नमूने पर परखिए, और डेटासेट को एक प्रमाणपत्र के साथ जारी कीजिए जिसमें दर्ज हो कि क्या परखा गया।

लेबलिंग इंजन मॉडलों से किसी डेटासेट पर लेबल लगाता है और लोगों की मदद से मापता है कि मॉडल कितनी बार गलत होते हैं। तैयार लेबलों को कौन-सी शर्त पूरी करनी है, यह आप एक कॉन्ट्रैक्ट में घोषित करते हैं, जैसे "स्वीकार किए गए मशीन लेबलों में से अधिकतम 5% गलत हों, 90% विश्वास के साथ"। उस दावे को परखने के लिए इंजन को जितने लेबल चाहिए, वह उतने लोगों से माँगता है, जिन मशीन लेबलों का समर्थन परीक्षण करता है उन्हें स्वीकार करता है, और बचे हुए आइटम लोगों के पास भेजता है। परिणाम में डेटासेट मिलता है, साथ में एक प्रमाणपत्र जिसमें दर्ज होता है कि क्या परखा गया और कितने मानव लेबलों पर।

इंजन Potato 2.11 से उपलब्ध है। एनोटेशन सर्वर, potato label कमांड लाइन, REST API, MCP सर्वर और एक Python SDK, सभी इसे टास्क डायरेक्टरी की उसी engine.sqlite फ़ाइल के ज़रिए चलाते हैं।

इंजन किस अध्ययन के लिए सही है

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

आपके पास इतने आइटम हैं जितनों पर लोग लेबल नहीं लगा सकते, और एक ऐसा मॉडल है जो ज़्यादातर सही होता है।
आपको यह बताना है कि लेबल कितने अच्छे हैं, न कि केवल यह कि उन्हें किसी मॉडल ने बनाया, चाहे किसी पेपर के लिए, किसी डेटासेट रिलीज़ के लिए, या किसी ऐसे ट्रेनिंग सेट के लिए जिसका उपयोग कोई और करेगा।
आप किसी मॉडल या एजेंट का मूल्यांकन LLM जज से कर रहे हैं और आपको जानना है कि क्या जज लोगों की जगह ले सकता है।

मॉडल की भविष्यवाणी से अंतिम लेबल तक

इंजन मशीन की भविष्यवाणियाँ, लोगों से किए गए अनुरोध और कॉन्ट्रैक्ट के परिणाम एक ही स्टोर में रखता है, और हर आइटम उन्हीं छह चरणों से गुज़रता है:

स्रोत मॉडल होते हैं। स्रोत कोई LLM, कोई विज़न-लैंग्वेज मॉडल, कोई निर्णय मॉडल (Laya, Jev या OpenJev), कोई ऑब्जेक्ट डिटेक्टर, कोई LLM जज, अध्ययन के अपने लेबलों पर प्रशिक्षित कोई मॉडल, दूसरे स्रोतों की एक ज्यूरी, या आपके पास पहले से मौजूद लेबल हो सकते हैं। हर स्रोत हर भविष्यवाणी के साथ एक विश्वास मान दर्ज करता है।
कैस्केड स्रोतों का क्रम तय करता है। आइटम पहले स्रोत के पास जाता है, और अगर कॉन्ट्रैक्ट उसका उत्तर स्वीकार नहीं करता, तो अगला स्रोत उसे आज़माता है। आखिरी स्रोत के बाद आइटम किसी व्यक्ति के पास जाता है।
अनुरोध वे काम हैं जो इंजन लोगों से करवाता है। हर अनुरोध दर्ज करता है कि वह क्यों किया गया (जैसे कैलिब्रेशन, प्रमाणन, सत्यापन, ऑडिट), उसके आइटम के नमूने में चुने जाने की प्रायिकता क्या थी, और क्या व्यक्ति कोई मशीन उत्तर देख सकता था। कैलिब्रेशन अनुरोध यादृच्छिक रूप से चुने जाते हैं और हमेशा ब्लाइंड होते हैं।
कॉन्ट्रैक्ट मशीन लेबलों को यादृच्छिक नमूने के मानव लेबलों पर परखते हैं। उस नमूने का आधा हिस्सा (dev स्प्लिट) स्वीकृति का नियम चुनता है, और दूसरा आधा (cert स्प्लिट) उसे परखता है। किसी कॉन्ट्रैक्ट की स्थिति met, insufficient (और लेबल चाहिए, साथ में अनुमान कि कितने), infeasible, violated या stale होती है।
समाधान हर आइटम को उसका अंतिम लेबल देता है। यह लेबल या तो किसी पूरे हुए कॉन्ट्रैक्ट के तहत स्वीकार किया गया मशीन लेबल होता है, या किसी व्यक्ति का लेबल, या फिर लंबित होता है।
प्रमाणपत्र हर कॉन्ट्रैक्ट का परिणाम दर्ज करता है, साथ में मॉडल और प्रॉम्प्ट संस्करणों सहित कैस्केड, किस उद्देश्य के लिए कितने मानव लेबल लगे, मॉडल पर हुआ खर्च, और कॉल लॉग का एक डाइजेस्ट।

गारंटियों के पीछे के नियम

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

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

इंजन यह नहीं जाँचता कि मानव लेबल सही हैं। हर कॉन्ट्रैक्ट मशीनों को उन लोगों के मुकाबले मापता है जिन्होंने नमूने पर लेबल लगाए, इसलिए अविश्वसनीय लोगों पर परखा गया कॉन्ट्रैक्ट अविश्वसनीय लोगों के साथ सहमति को प्रमाणित करता है। लोगों की भी जाँच करने के लिए गुणवत्ता नियंत्रण, ओवरलैप (humans.overlap) और no_worse_than_human कॉन्ट्रैक्ट का उपयोग करें।

पहला अध्ययन

Potato examples/labeling-engine/ के अंतर्गत तीन उदाहरण अध्ययन देता है, एक टेक्स्ट के लिए, एक इमेज के लिए और एक एजेंट ट्रेस के लिए। तालिका बताती है कि हर एक कौन-से स्रोत और कॉन्ट्रैक्ट उपयोग करता है:

उदाहरण	स्रोत	कॉन्ट्रैक्ट
`text-certified-sentiment/`	Laya (निर्णय मॉडल), एक Ollama LLM	10% पर selective risk, PPI प्रचलन
`image-objects-and-people/`	YOLOv8n डिटेक्टर, एक Ollama विज़न मॉडल	बॉक्स (IoU) पर और एक has-person लेबल पर selective risk
`agent-trace-judge/`	लेबलों का क्रम बदलकर जाँचने वाला एक LLM जज	selective risk, no-worse-than-human, PPI टास्क सफलता

टेक्स्ट उदाहरण चार कमांड में चलता है। पहली कमांड कैस्केड से हर आइटम पर लेबल लगाती है और पहला ब्लाइंड नमूना चुनती है, दूसरी वह नमूना लोगों को परोसती है, और आखिरी दो, लोगों के नमूने पर लेबल लगा देने के बाद, कॉन्ट्रैक्ट परखती हैं और प्रमाणपत्र प्रिंट करती हैं:

bash

potato label run examples/labeling-engine/text-certified-sentiment/config.yaml
potato start examples/labeling-engine/text-certified-sentiment/config.yaml -p 8000
potato label certify examples/labeling-engine/text-certified-sentiment/config.yaml
potato label certificate examples/labeling-engine/text-certified-sentiment/config.yaml --format md

अपने अध्ययन में इंजन जोड़ने के लिए, ये कुंजियाँ किसी ऐसे कॉन्फ़िग में जोड़ें जिसमें पहले से data_files और sentiment नाम की एक एनोटेशन स्कीमा हो। कॉन्ट्रैक्ट माँगता है कि स्वीकार किए गए मशीन लेबलों में से अधिकतम 10% गलत हों, 90% विश्वास के साथ, और budgets.human_labels सीमित करता है कि इंजन लोगों से अधिकतम कितने अनुरोध कर सकता है:

yaml

assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: gemma
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
  budgets:
    human_labels: 400

स्रोत अपना विश्वास टोकन लॉग प्रायिकताओं से बताता है (method: logprob), जिसमें प्रति आइटम एक कॉल लगती है और जो विश्वास के तरीकों में आम तौर पर सबसे अच्छा कैलिब्रेटेड होता है। कॉन्फ़िगरेशन हर कुंजी की सूची देता है, और कॉन्ट्रैक्ट बताता है कि हर कॉन्ट्रैक्ट क्या परखता है।

एनोटेशन पेज पर अनुरोध

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

आइटम के ऊपर एक छोटी टिप्पणी बताती है कि यह किस तरह का अनुरोध है, और कई प्रश्नों वाले पेज पर वह प्रश्न का नाम भी बताती है:

ब्लाइंड। टिप्पणी में लिखा होता है "Label this one yourself. Suggestions are off for this item."। सहेजने के बाद भी, पेज दोबारा लोड करने पर और Back पर, वह आइटम उस व्यक्ति के लिए ब्लाइंड रहता है।
सत्यापन। मशीन का उत्तर पहले से भरा होता है, और टिप्पणी कहती है कि सही हो तो उसे रहने दें और गलत हो तो बदल दें। पेज पहले से भरा उत्तर दर्ज करता है, ताकि आप माप सकें कि लोग उसे कितनी बार स्वीकार करते हैं। जब तक व्यक्ति कुछ करता नहीं, कुछ भी सहेजा नहीं जाता, इसलिए खुला छोड़ा गया पेज उसकी ओर से उत्तर नहीं देता। जिन स्कीमा के उत्तर पेज पहले से नहीं भर सकता (समय सेगमेंट, 3D ऑब्जेक्ट, एजेंट ट्रेस), वे इसके बजाय ब्लाइंड रूप में परोसी जाती हैं।
समाधान। कोई भी मशीन लेबल स्वीकार नहीं किया जा सका, इसलिए व्यक्ति का उत्तर ही लेबल है।

जो अनुरोध किसी के पास runtime.hold_minutes (डिफ़ॉल्ट रूप से 60) तक बिना उत्तर के पड़ा रहता है, वह वापस पूल में चला जाता है और उसके पेज से हट जाता है। जो आइटम इंजन ने किसी व्यक्ति को नहीं परोसा, उस पर उसका सहेजा गया लेबल किसी और का अनुरोध कभी बंद नहीं करता, और इंजन उसे एक ऑर्गेनिक लेबल के रूप में रखता है। जब कोई नया प्रमाणन मशीन लेबल स्वीकार करता है, तो इंजन उन आइटमों पर खुले सत्यापन और समाधान अनुरोध रद्द कर देता है जिन्हें वह अब कवर करता है। जो अनुरोध किसी व्यक्ति के पास पहले से हैं, वे उसी के पास रहते हैं, और उसका उत्तर मशीन लेबल की जगह ले लेता है।

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

Pocket Mode भी इंजन के अनुरोध परोसता है, एक बार में पूरा बैच, और "All caught up" कहने से पहले और अनुरोध माँगता है। Pocket Mode कभी मशीन उत्तर नहीं दिखाता, इसलिए वहाँ परोसा गया सत्यापन अनुरोध ब्लाइंड दर्ज होता है, जब तक कि डेस्कटॉप पेज उस व्यक्ति को पहले ही उत्तर न दिखा चुका हो। समाधान और न्यायनिर्णयन कार्डों पर वह वही टिप्पणी दिखाता है जो डेस्कटॉप पेज दिखाता है।

एडमिन पेज

जब इंजन चालू होता है, तो एडमिन डैशबोर्ड /admin/labeling-engine पर Labeling engine का लिंक देता है। पेज के हर चार्ट का एक तालिका रूप भी है। पेज दिखाता है:

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

एडमिन सत्र के बिना खोलने पर पेज डैशबोर्ड के कुंजी फ़ॉर्म पर जाता है। इंजन बंद हो, तो पेज यह बताता है और उस कुंजी का नाम देता है जो इसे चालू करती है।

आगे पढ़ें

लेबलिंग इंजन कॉन्ट्रैक्ट: छह तरह के कॉन्ट्रैक्ट और हर एक क्या परखता है
लेबलिंग इंजन कॉन्फ़िगरेशन: हर labeling_engine कुंजी
कमांड लाइन, REST API, MCP टूल और SDK
icl_labeling, judge_calibration और pre_annotation से लेबलिंग इंजन पर माइग्रेट करना
Solo Mode, जब एक विशेषज्ञ किसी LLM के साथ काम करता है
LLM प्री-एनोटेशन और LLM जज सहमति

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