लेबलिंग इंजन कॉन्फ़िगरेशन
labeling_engine ब्लॉक की हर कुंजी: स्रोत और विश्वास के तरीके, मानव पूल, क्राउड पर खर्च, बजट, रनटाइम सीमाएँ, फ़ीचर, और वैलिडेशन किन चीज़ों को अस्वीकार करता है।
लेबलिंग इंजन जो कुछ भी करता है, वह एक ही labeling_engine ब्लॉक में सेट होता है। अमान्य ब्लॉक होने पर सर्वर स्टार्टअप पर ही रुक जाता है और सारी समस्याएँ एक साथ सूचीबद्ध करता है। एनोटेटरों को इंजन के अनुरोध परोसने के लिए assignment_strategy: engine भी सेट करें। चालू इंजन के बिना यह रणनीति सेट करना एक वैलिडेशन त्रुटि है।
ब्लॉक में ये खंड होते हैं, और हर एक को नीचे समझाया गया है:
assignment_strategy: engine
labeling_engine:
enabled: true
schemas: [sentiment] # default: every scheme a source can label
sources: []
cascade: [laya, gemma] # default: the first source alone
contracts: []
humans: {}
crowd: {}
budgets: {}
runtime: {}
features: {}
redaction: {}
distill: {}शीर्ष-स्तर की कुंजियाँ
पाँच कुंजियाँ सीधे labeling_engine के नीचे आती हैं:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
enabled | false | इंजन चालू करें। चालू इंजन के लिए कम से कम एक स्रोत चाहिए। |
schemas | सभी | वे एनोटेशन स्कीमा जिन पर इंजन लेबल लगाता है। assignment_strategy: engine के तहत, छोड़ी गई स्कीमा का उत्तर हर आइटम पर नहीं मिलता, केवल उन आइटमों पर मिलता है जिन्हें इंजन अपनी स्कीमा के लिए लोगों के पास भेजता है, और वैलिडेशन इसकी चेतावनी देता है। जिस स्कीमा पर कोई स्रोत लेबल नहीं लगा सकता (जैसे फ़्री टेक्स्ट), वह इंजन में नहीं हो सकती, इसलिए इस रणनीति के तहत उसका उत्तर कभी हर आइटम पर नहीं मिलता। अगर हर आइटम पर उत्तर ज़रूरी हो, तो कोई दूसरी असाइनमेंट रणनीति उपयोग करें। |
sources | [] | मॉडल। स्रोत देखें। |
cascade | पहला स्रोत | स्रोतों की id, उसी क्रम में जिसमें उन्हें आज़माया जाता है। आखिरी के बाद लोग आते हैं। |
contracts | [] | लेबलों को क्या शर्त पूरी करनी है। कॉन्ट्रैक्ट देखें। |
स्रोत
स्रोत एक मॉडल, या लेबलों का पहले से मौजूद एक सेट होता है, जो हर आइटम के लिए एक लेबल और एक विश्वास प्रस्तावित करता है। हर स्रोत की एक अनूठी id और एक kind होता है, और किसी स्रोत पर अज्ञात कुंजी एक त्रुटि है:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
id | अनिवार्य | cascade, कॉल लॉग और प्रमाणपत्र में उपयोग होने वाला नाम। |
kind | अनिवार्य | llm, vlm, decision, detector, judge, jury, trained, static, fixture, asr, lf, simulator में से एक। |
endpoint_type | llm, vlm, decision, judge के लिए अनिवार्य | AI एंडपॉइंट, जैसे vllm, openai, anthropic, gemini, ollama, openrouter, openai_vision, ollama_vision, laya या systemone। detector का डिफ़ॉल्ट yolo है। |
model | एंडपॉइंट का डिफ़ॉल्ट | मॉडल का नाम। |
base_url | कोई नहीं | सेल्फ़-होस्टेड या OpenAI-संगत एंडपॉइंट के लिए सर्वर URL। |
api_key | कोई नहीं | इसे कभी किसी संस्करण के हैश में नहीं डाला जाता और कभी एक्सपोर्ट नहीं किया जाता। ${ENV_VAR} का मान भर दिया जाता है। |
temperature | 0.0 | 0 से 2 तक। |
max_tokens | 256 | प्रति कॉल आउटपुट टोकन की सीमा। |
timeout | एंडपॉइंट का डिफ़ॉल्ट | प्रति कॉल सेकंड। |
prompt | स्कीमा से बनाया गया | प्रॉम्प्ट टेम्पलेट। इसे बदलने से स्रोत का नया संस्करण बनता है। |
confidence | {method: auto} | स्रोत अपना विश्वास कैसे बताता है। विश्वास के तरीके देखें। |
concurrency | runtime.concurrency | इस स्रोत पर समानांतर कॉल। |
schemas | इंजन की सभी स्कीमा | स्रोत को इन स्कीमा तक सीमित करें। |
options | {} | प्रकार-विशिष्ट विकल्प, जो नीचे सूचीबद्ध हैं। |
judge | {} | केवल judge के लिए। options वाले ही विकल्प, अपनी अलग कुंजी के तहत, और जहाँ दोनों एक ही विकल्प सेट करें, वहाँ options मान्य होता है। |
members | कोई नहीं | केवल jury के लिए। कम से कम दो दूसरे स्रोतों की id। |
aggregation | plurality | केवल jury के लिए। बहुलता (plurality) ही एकमात्र नियम है। |
field / predictions_file | कोई नहीं | केवल static के लिए। पहले से मौजूद लेबल कहाँ हैं। फ़ील्ड में {scheme: label} होता है, या जब स्रोत एक ही स्कीमा पर लेबल लगाता है तो केवल लेबल। अगर हर आइटम पर फ़ील्ड का आकार गलत हो, तो रन उस फ़ील्ड का नाम बताने वाले संदेश के साथ विफल होता है। |
error_rate, seed | कोई नहीं | केवल fixture के लिए। ज्ञात त्रुटि दर वाला एक कृत्रिम स्रोत, परीक्षणों के लिए। |
revision | कोई नहीं | संस्करण में दर्ज करने के लिए मॉडल रिविज़न, जैसे कोई चेकपॉइंट हैश। |
जो कुछ भी किसी उत्तर को बदल सकता है (मॉडल, प्रॉम्प्ट, टेम्परेचर, विकल्प), वह स्रोत के संस्करण हैश में जाता है। नया संस्करण उस स्रोत पर निर्भर हर कॉन्ट्रैक्ट को stale कर देता है।
जो उत्तर ऐसा मान नहीं है जो स्कीमा रख सकती है, जैसे उसकी सूची में न होने वाला लेबल, संख्या फ़ील्ड में संख्या के अलावा कुछ और, या N में से एक वाली स्कीमा पर एक सूची, उसे त्रुटि के रूप में दर्ज किया जाता है और लेबल के रूप में कभी नहीं, और रन का संदेश इन त्रुटियों को गिनता है। जिस आइटम की कॉल विफल होती हैं, उसे बाद के रन में फिर से पूछा जाता है, प्रति स्रोत संस्करण अधिकतम तीन बार, और उसके बाद वह बदले हुए स्रोत की प्रतीक्षा करता है (ठीक की गई कुंजी या प्रॉम्प्ट एक नया संस्करण है)। जिस रन में कोई एक स्रोत विफल होता है, उसमें बाकी स्तर नहीं रुकते। अगला स्तर हर आइटम पर लेबल लगाता है, और potato label run स्थिति 1 के साथ बाहर निकलता है और विफल स्रोत का नाम बताता है।
विश्वास के तरीके
इंजन के स्वीकृति नियम हर भविष्यवाणी के विश्वास पर थ्रेशोल्ड लगाते हैं, इसलिए कोई स्रोत अपना विश्वास कैसे बताता है, इससे तय होता है कि इंजन कितना स्वीकार कर सकता है। confidence.method पाँच में से एक मान लेता है:
confidence.method | किस पर लागू | क्या करता है |
|---|---|---|
verbalized | llm, vlm, judge | मॉडल अपने उत्तर में 0-100 बताता है। एक कॉल, और सबसे कम भरोसेमंद तरीका। |
k_sample | llm | sample_temperature (डिफ़ॉल्ट रूप से 0.7) पर samples उत्तर (डिफ़ॉल्ट रूप से 5)। लेबल सबसे आम उत्तर होता है और विश्वास उसका हिस्सा। k कॉल लगती हैं। |
logprob | llm | लेबलों को अक्षर दिए जाते हैं और मॉडल एक अक्षर से उत्तर देता है, और विश्वास पहले टोकन की प्रायिकताओं से पढ़ा जाता है। एक कॉल, आम तौर पर सबसे अच्छा कैलिब्रेटेड। इसके लिए ऐसा बैकएंड चाहिए जो logprobs लौटाए (vLLM, OpenAI-संगत) और अधिकतम 20 लेबल, और इससे ज़्यादा लेबल वाली स्कीमा एक वैलिडेशन त्रुटि है। |
native | decision, detector, trained | मॉडल की अपनी प्रायिकताएँ। llm स्रोत पर यह एक वैलिडेशन त्रुटि है। |
auto | सभी | जहाँ स्रोत के पास native हो वहाँ वह, वरना verbalized। |
प्रकार-विशिष्ट विकल्प
पाँच तरह के स्रोत अपने खुद के विकल्प पढ़ते हैं:
decisionइन-प्रोसेस Laya को, या किसी भी/v1/systemoneसर्वर को कवर करता है, जैसे होस्ट किया गया Jev या OpenJev। एक फ़ॉरवर्ड पास हर विकल्प की प्रायिकता लौटाता है, और यहradio,select,likertऔरsliderस्कीमा पर काम करता है।endpoint_typeकाlayaयाsystemoneहोना ज़रूरी है, औरsystemoneके लिएbase_urlचाहिए, यानी सर्वर रूट (/v1/systemoneपर खत्म होने वाला URL भी स्वीकार है)। दोनों मामलों में स्टेट{"text": ...}के रूप में भेजा जाता है, इसलिए एक ही चेकपॉइंट इन-प्रोसेस औरlaya-serveके पीछे एक जैसे उत्तर देता है, औरoptions: {state_key: ""}इसके बजाय केवल स्ट्रिंग भेजता है। रेटिंग स्केल (likert,slider) पर Laya के स्कोर मुश्किल से ही स्केल का पालन कर पाते हैं, इसलिए उस पर भरोसा करने से पहले कुछ आइटम जाँच लें। इन-प्रोसेसlayaएंडपॉइंट के लिएpip install 'potato-annotation[decision]'चाहिए।detectorimage_annotationस्कीमा पर किसी ऑब्जेक्ट डिटेक्टर से बॉक्स पढ़ता है।keep_threshold(0.35) वह स्कोर तय करता है जिस पर या जिससे ऊपर कोई बॉक्स भविष्यवाणी का हिस्सा होता है।candidate_threshold(0.05) औरkeep_thresholdके बीच के बॉक्स इमेज का विश्वास घटाते हैं।label_mapडिटेक्टर के वर्गों को स्कीमा के लेबलों से जोड़ता है, और जिन वर्गों का मैप नहीं है उन्हें अनदेखा किया जाता है।image_fieldउस आइटम फ़ील्ड का नाम बताता है जिसमें इमेज का पाथ या URL है। पाथ उसी तरह हल होते हैं जैसे एनोटेशन पेज उन्हें हल करता है:/media/x.jpgटास्क कीmedia_directoryके तहत, और सापेक्ष पाथtask_dirके तहत।judgerubric(डिफ़ॉल्ट रूप से स्कीमा का विवरण),fields(जज को दिखाए जाने वाले आइटम फ़ील्ड, क्रम से) औरswap_orderलेता है, जो लेबलों का क्रम उलटकर दो बार पूछता है और पलट जाने वाले फ़ैसले को परहेज़ (abstention) में बदल देता है। एजेंट-ट्रेस स्कीमा (process_reward,trajectory_eval, ...) पर जज हर चरण पर लेबल लगाता है।vlmएक विज़न एंडपॉइंट (openai_vision,anthropic_vision,ollama_vision) का उपयोग करता है। OpenAI-संगत सर्वर के पीछे सेल्फ़-होस्टेड मॉडल के लिएbase_urlके साथopenai_visionउपयोग करें।trainedartifact_dir,trainer(डिफ़ॉल्ट रूप सेsklearn-text) औरrun_idलेता है। यह स्रोत आम तौर पर डिस्टिलेशन बनाता है, न कि हाथ से लिखा कॉन्फ़िग।
humans
humans ब्लॉक तय करता है कि लेबल कौन लगाता है और इंजन उनका नमूना कैसे लेता है:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
pools | [team] | लेबल कौन लगाता है: team, crowd, solo। |
calibration_rate | auto | ब्लाइंड कैलिब्रेशन के लिए नमूने में चुने गए आइटमों का हिस्सा। auto कॉन्ट्रैक्ट के अनुमानों से एक दर चुनता है, इतनी कि हर वर्ग में परीक्षण लायक लेबल हों, छोटे अध्ययन में अधिकतम आधा और 1,000 से ज़्यादा आइटम वाले अध्ययन में अधिकतम पाँचवाँ हिस्सा। |
dev_fraction | 0.5 | कैलिब्रेशन लेबलों का वह हिस्सा जो थ्रेशोल्ड चुनने में लगता है। बाकी उन्हें परखते हैं। |
min_calibration_per_class | 10 | प्रति-वर्ग कॉन्ट्रैक्ट परखे जाने से पहले हर वर्ग की न्यूनतम सीमा। |
audit_rate | 0.02 | नए स्वीकार किए गए मशीन लेबलों का वह हिस्सा जो ड्रिफ़्ट पर नज़र रखने के लिए ब्लाइंड रूप में वापस लोगों के पास भेजा जाता है। |
overlap | 0.0 | कैलिब्रेशन आइटमों का वह हिस्सा जिस पर कई लोग लेबल लगाते हैं। |
overlap_k | 3 | हर ओवरलैप आइटम पर लोग। no_worse_than_human कॉन्ट्रैक्ट के लिए 3 चाहिए। |
distribution_k | 5 | distributional कॉन्ट्रैक्ट के लिए प्रति आइटम लोग। |
truth | majority | एक आइटम पर कई लोगों के लेबल कैसे वह लेबल बनते हैं जिस पर कॉन्ट्रैक्ट परखे जाते हैं, majority या dawid_skene। |
verify_visibility | shown | सत्यापन अनुरोध मशीन का उत्तर दिखाता है (shown) या नहीं (blind)। |
crowd
crowd ब्लॉक तब लागू होता है जब humans.pools में crowd हो, और Prolific ही एकमात्र क्राउड प्लेटफ़ॉर्म है जिसे इंजन चला सकता है:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
provider | prolific | क्राउड प्लेटफ़ॉर्म। |
study_id | कोई नहीं | वह Prolific अध्ययन जिसका आकार बदलना है। |
reward_usd | कोई नहीं | प्रति स्थान पारिश्रमिक, लागत के अनुमान के लिए। |
per_worker_quota | 20 | प्रति वर्कर अनुरोध। स्थान ceil(open requests / quota) होते हैं। |
क्राउड भर्ती डिफ़ॉल्ट रूप से एक ड्राई रन है, और प्लानर बताता है कि वह क्या करता। पैसा खर्च करने के लिए features.crowd_live_spend: true और एक budgets.human_usd सीमा चाहिए, और जो कॉन्फ़िग सीमा के बिना लाइव खर्च चालू करता है, उसे अस्वीकार कर दिया जाता है। Prolific अध्ययन खुद सेट करने का तरीका क्राउडसोर्सिंग में बताया गया है।
budgets
budgets ब्लॉक किसी सीमा के पार होने से पहले खर्च रोक देता है:
| कुंजी | अर्थ |
|---|---|
model_usd | इतना खर्च हो जाने पर कीमत वाले मॉडलों को कॉल करना बंद करें। हर कॉल पहले अपनी अनुमानित लागत आरक्षित करती है। बिना कीमत वाले मॉडल, और localhost पर सेल्फ़-होस्टेड मॉडल, इससे सीमित नहीं होते। |
human_usd | क्राउड पर खर्च की ऊपरी सीमा। क्राउड पर लाइव खर्च के लिए अनिवार्य। |
human_labels | लोगों से अधिकतम कितने अनुरोध इंजन खोल सकता है, हर अनुरोध खुलते समय गिना जाता है। |
runtime
runtime ब्लॉक बैचिंग, समवर्तिता और यह नियंत्रित करता है कि कोई व्यक्ति कितनी देर तक कोई अनुरोध अपने पास रख सकता है:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
batch_size | 32 | हर कमिट किए गए हिस्से में आइटम। बीच में रोका गया रन कॉल दोहराए बिना अगले हिस्से से फिर शुरू होता है। |
concurrency | 4 | प्रति स्रोत समानांतर कॉल, जिसे स्रोत का अपना concurrency बदल देता है। |
cache | true | एक ही स्रोत संस्करण के एक जैसे अनुरोधों के उत्तर दोबारा उपयोग करें। |
retries | 2 | टाइमआउट, कनेक्शन त्रुटि, 429 या 5xx के बाद अतिरिक्त प्रयास। हर प्रयास लॉग होता है। |
planner_interval | 30 | सर्वर में प्लानर के पासों के बीच सेकंड। |
hold_minutes | 60 | कितने मिनट तक कोई व्यक्ति बिना उत्तर दिए कोई अनुरोध अपने पास रख सकता है, जिसके बाद वह वापस पूल में चला जाता है। आइटम उसके पेज से भी हट जाता है, इसलिए खुला छोड़ा गया टैब बाद में उसका उत्तर नहीं दे सकता। |
features
drift को छोड़कर हर फ़ीचर डिफ़ॉल्ट रूप से बंद है:
| कुंजी | यह क्या चालू करता है |
|---|---|
drift | डिफ़ॉल्ट रूप से चालू। ऑडिट परिणामों पर कार्रवाई करता है। जब ऑडिट दिखाते हैं कि स्वीकार किए गए लेबलों की त्रुटि दर लक्ष्य से ऊपर है, तो कॉन्ट्रैक्ट violated दिखाता है, उस स्कीमा पर मशीन लेबल स्वीकार होना बंद हो जाते हैं, और नए कैलिब्रेशन लेबल लिए जाते हैं। हर प्रमाणन एक नया ऑडिट क्रम शुरू करता है, इसलिए सुधार के बाद दोबारा प्रमाणित करने से स्वीकृति बहाल हो जाती है। केवल उल्लंघन की रिपोर्ट के लिए इसे false पर सेट करें, तब कॉन्ट्रैक्ट "met, audits breached" दिखाता है। |
distill | अध्ययन के लेबलों पर एक मॉडल प्रशिक्षित करें और उसे कैस्केड में सबसे पहले रखें (distill देखें)। |
optimize | हर प्लानर पास में कैस्केड के हर उपसमुच्चय को dev लेबलों पर आँकें और GET /api/engine/v1/schemes/<name>/optimize पर वह सबसे सस्ता उपसमुच्चय बताएँ जो कॉन्ट्रैक्ट का कवरेज बनाए रखता है। कुछ भी लागू नहीं किया जाता, क्योंकि कोई कैस्केड अपनाना एक कॉन्फ़िग बदलाव और एक नया प्रमाणन है। |
crowd_recruit | प्लानर को Prolific अध्ययन का आकार तय करने दें, एक ड्राई रन के रूप में, जब तक crowd_live_spend चालू न हो। |
crowd_live_spend | Prolific अध्ययन को सच में बदलें। इसके लिए crowd पूल और budgets.human_usd चाहिए। |
pii_redaction | टेक्स्ट किसी थर्ड-पार्टी API पर जाने से पहले ईमेल, URL, IP पते, कार्ड नंबर, SSN, फ़ोन नंबर और @handle छिपाएँ। कॉल लॉग दर्ज करता है कि क्या छिपाया गया, श्रेणियों और हैश के रूप में, टेक्स्ट कभी नहीं। |
payload_capture | पूरे प्रॉम्प्ट और उत्तर <task_dir>/engine_payloads/ के तहत रखें। डिफ़ॉल्ट रूप से बंद, और कॉल लॉग केवल हैश रखता है। |
redaction
redaction.categories बताता है कि email, url, ip, card, ssn, phone और handle में से किन्हें छिपाना है, और इसका डिफ़ॉल्ट सभी हैं। छिपाना केवल features.pii_redaction के साथ, और केवल थर्ड-पार्टी API के लिए लागू होता है। सेल्फ़-होस्टेड एंडपॉइंट प्रकार (vllm, ollama, laya, yolo, ...) कहीं भी चलें, उनके लिए कुछ नहीं छिपाया जाता, और न ही ऐसे किसी एंडपॉइंट के लिए जिसका base_url उसी मशीन पर है।
distill
features.distill चालू होने पर, इंजन अध्ययन के लेबलों पर एक सस्ता मॉडल प्रशिक्षित करता है और उसे कैस्केड में सबसे पहले रखता है:
| कुंजी | डिफ़ॉल्ट | अर्थ |
|---|---|---|
trainer | sklearn-text | potato/training का एक ट्रेनर। |
min_labels | 200 | इतने लेबल हो जाने के बाद ही प्रशिक्षित करें। |
include_silver | true | उन मशीन लेबलों पर भी प्रशिक्षित करें जिन्हें किसी कॉन्ट्रैक्ट ने प्रमाणित किया, silver चिह्नित करके। |
every | 2.0 | लेबलों की संख्या इस गुणक से बढ़ने पर फिर से प्रशिक्षित करें। |
cert और ऑडिट स्प्लिट के आइटम कभी ट्रेनिंग सेट में नहीं जाते, इसलिए डिस्टिल्ड मॉडल को कभी उन लेबलों पर नहीं परखा जाता जिन पर वह प्रशिक्षित हुआ।
वैलिडेशन
potato validate config.yaml बाकी कॉन्फ़िग के साथ labeling_engine ब्लॉक की भी जाँच करता है, और हर त्रुटि अपनी कुंजी का नाम बताती है, जैसे labeling_engine.sources[1].kind must be one of ... या labeling_engine.contracts[0].error is required for selective_risk। वैलिडेशन इन्हें भी अस्वीकार करता है:
- कॉन्ट्रैक्ट की ऐसी कुंजी जिसे उस प्रकार का कॉन्ट्रैक्ट नहीं पढ़ता, जैसे
errorकी वर्तनी की गलती; - ऐसी स्कीमा पर कॉन्ट्रैक्ट जिस पर कैस्केड का कोई स्रोत लेबल नहीं लगा सकता, हर स्रोत के कारण के साथ;
- ऐसी स्कीमा पर कॉन्ट्रैक्ट जिसे इंजन आँक नहीं सकता (फ़्री टेक्स्ट, पेयरवाइज़);
- ऐसा
decisionस्रोत जिसकाendpoint_typeनिर्णय मॉडल नहीं है, और ऐसाllm,vlmयाjudgeस्रोत जिसकाendpoint_typeनिर्णय मॉडल है; और humans.overlap_kके 3 से कम होने परno_worse_than_human।
वैलिडेशन तब भी चेतावनी देता है जब budgets.human_labels इतना छोटा हो कि हर मशीन उत्तर सही होने पर भी किसी selective_risk कॉन्ट्रैक्ट को प्रमाणित न कर सके। जब तक वह चेतावनी न हटे, बजट बढ़ाएँ या error ढीला करें।
आगे पढ़ें
- लेबलिंग इंजन
- लेबलिंग इंजन कॉन्ट्रैक्ट
- कमांड लाइन, REST API, MCP टूल और SDK
- AI सहायता, उन एंडपॉइंट प्रकारों के लिए जिन्हें स्रोत Potato के बाकी हिस्सों के साथ साझा करते हैं
कार्यान्वयन विवरण के लिए, स्रोत दस्तावेज़ देखें।