लेबलिंग इंजन पर माइग्रेट करना
potato label migrate-config से icl_labeling, judge_calibration, pre_annotation और Solo Mode कॉन्फ़िग को लेबलिंग इंजन पर ले जाइए, और देखिए कि ऐसा करने के बाद क्या बदलता है।
Potato की पुरानी मशीन-लेबलिंग सुविधाएँ 2.11 में काम करती रहती हैं, और जब तक आप labeling_engine ब्लॉक नहीं जोड़ते, किसी का व्यवहार नहीं बदलता। तीन कुंजियाँ अब स्टार्टअप पर एक सूचना वाली टिप्पणी दिखाती हैं जिसमें लेबलिंग इंजन में उनके समकक्ष का नाम होता है, और उन्हें 3.0 में हटाने की योजना है। ये टिप्पणियाँ stderr पर जाती हैं, NOTE: से शुरू होती हैं और चेतावनियाँ नहीं हैं, इसलिए potato validate --strict उनकी वजह से विफल नहीं होता।
तालिका तीनों कुंजियाँ और यह बताती है कि हर एक क्या बनती है:
| पुरानी कुंजी | इंजन में समकक्ष |
|---|---|
icl_labeling | एक llm स्रोत, पुराने नियम के लिए threshold_legacy कॉन्ट्रैक्ट और उसके साथ एक selective_risk कॉन्ट्रैक्ट |
judge_calibration | k_sample विश्वास वाले judge स्रोत, जिनका ब्लाइंड नमूना कैलिब्रेशन अनुरोध बन जाता है |
pre_annotation | एक static स्रोत |
Solo Mode, जज अलाइनमेंट और इंटरैक्टिव AI सहायक (ai_support) अप्रचलित (deprecated) नहीं हैं। Solo Mode में एक विशेषज्ञ अपने अलग इंटरफ़ेस के ज़रिए एक LLM के साथ काम करता है, और जज अलाइनमेंट एक रिपोर्ट है। इंजन चालू होने पर, दोनों अपनी मॉडल भविष्यवाणियाँ इंजन के स्टोर में भी लिखते हैं, ताकि इंजन उन्हें कैलिब्रेट और प्रमाणित कर सके।
potato label migrate-config
potato label migrate-config पुरानी कुंजियों को एक labeling_engine ब्लॉक में बदलता है:
potato label migrate-config config.yaml --out config-engine.yamlकमांड कोई डेटा लोड किए बिना YAML पढ़ती है, एक समकक्ष labeling_engine ब्लॉक जोड़ती है, और परिणाम को टिप्पणियों वाले एक हेडर के साथ लिखती है जो हर रूपांतरण को समझाता है। यह ब्लॉक को enabled: false के साथ लिखती है, इसलिए जब तक आप इंजन चालू नहीं करते, रूपांतरित कॉन्फ़िग मूल कॉन्फ़िग जैसा ही व्यवहार करता है। टिप्पणियाँ पढ़ें, स्रोत और कॉन्ट्रैक्ट जाँचें, फिर enabled: true और assignment_strategy: engine सेट करें। जब कॉन्फ़िग में पहले से labeling_engine ब्लॉक हो, या रूपांतरित करने को कुछ न हो, तो कमांड त्रुटि के साथ बाहर निकलती है।
रूपांतरण तालिका
हर पुराना ब्लॉक इस तरह इंजन के स्रोतों, कॉन्ट्रैक्ट और मानव सेटिंग्स में बदलता है:
| पुराना ब्लॉक | स्रोत | कॉन्ट्रैक्ट | मानव |
|---|---|---|---|
confidence_routing.tiers के साथ solo_mode | हर स्तर के लिए एक स्रोत, स्तरों के क्रम में | N में से एक वाली हर स्कीमा के लिए selective_risk, error: 1 - end_human_annotation_agreement | pools: [solo] |
labeling_models के साथ solo_mode | हर मॉडल के लिए एक स्रोत, और पहला कैस्केड होता है | ऊपर की तरह | pools: [solo] |
solo_mode.jury | हर ज्यूरर के लिए एक स्रोत, साथ में कैस्केड के रूप में एक jury स्रोत | ऊपर की तरह | |
icl_labeling | llm स्रोत के रूप में ai_support एंडपॉइंट | पुराने confidence_threshold पर threshold_legacy, और 10% पर selective_risk | calibration_rate = पुराना सत्यापन sample_rate |
judge_alignment | judge स्रोत के रूप में जज एंडपॉइंट (एक ही स्कीमा हो तो रूब्रिक के साथ) | हर जाँची गई स्कीमा के लिए no_worse_than_human, epsilon: 0.15 | overlap: 0.3 |
judge_calibration | k_sample विश्वास वाले judge स्रोत के रूप में हर मॉडल | sampling.sample_size → budgets.human_labels | |
field या predictions_file के साथ pre_annotation | एक static स्रोत, कैस्केड में पहला | ||
active_learning.llm | एक llm स्रोत | ||
ai_budget.cap_usd | budgets.model_usd |
माइग्रेशन के बाद व्यवहार में बदलाव
इंजन मानव लेबलों के साथ पुरानी सुविधाओं से अलग बर्ताव करता है, और रूपांतरित कॉन्फ़िग की टिप्पणियाँ बताती हैं कि कहाँ। चार बदलावों की उम्मीद रखें:
- तय थ्रेशोल्ड परखे हुए थ्रेशोल्ड बन जाते हैं। Solo Mode के रूटिंग थ्रेशोल्ड और
icl_labelingका विश्वास थ्रेशोल्ड एक तय संख्या से ऊपर के मशीन लेबल स्वीकार करते थे।selective_riskdev लेबलों पर थ्रेशोल्ड चुनता है और केवल वही स्वीकार करता है जो अलग रखे गए लेबलों पर परीक्षण पास करता है, इसलिए शुरू में कम लेबल स्वीकार होने की उम्मीद रखें, और जो स्वीकार होते हैं उन पर त्रुटि की एक घोषित सीमा होगी। - सत्यापन नमूने समान (uniform) हो जाते हैं।
icl_labelingसबसे कम विश्वास वाली भविष्यवाणियों को पहले सत्यापित करता था, जिससे त्रुटियाँ जल्दी मिलती हैं, लेकिन सटीकता का अनुमान पक्षपाती होता है। इंजन के कैलिब्रेशन अनुरोध एक यादृच्छिक नमूना हैं, जिनकी चुने जाने की प्रायिकताएँ दर्ज होती हैं। - इनलाइन जजिंग ब्लाइंड हो जाती है।
judge_alignment.inlineलोगों के लेबल लगाते समय जज का फ़ैसला दिखाता था, इसलिए सहमति ऐसे लेबलों पर मापी जाती थी जो उस फ़ैसले से प्रभावित थे। इंजन के कैलिब्रेशन अनुरोध कभी मशीन उत्तर नहीं दिखाते। - प्री-एनोटेशन पर भरोसा करने से पहले उन्हें परखा जाता है। किसी
staticस्रोत के लेबल केवल वहीं स्वीकार होते हैं जहाँ कोई कॉन्ट्रैक्ट उन्हें प्रमाणित करता है, और बाकी जगह लोग उन्हें सत्यापन अनुरोधों में देखते हैं।
आगे पढ़ें
कार्यान्वयन विवरण के लिए, स्रोत दस्तावेज़ देखें।