Workflows कम्पाइलर

Workflows कम्पाइलर Workflow Definition को निष्पादन योग्य computation graph में कैसे बदलता है।

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

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

यह दस्तावेज़ निष्पादन इंजन के डिज़ाइन को कवर करता है v1 (जो वर्तमान स्थिर संस्करण है)। कृपया संस्करण-प्रबंधन के बारे में जानकारी को स्वीकार करें, ताकि आप निष्पादन इंजन के विकास चक्र को समझ सकें।

कंपाइलेशन के चरण

वर्कफ़्लो कंपाइलेशन में कई चरण शामिल होते हैं, जिनमें शामिल हैं:

1. उपलब्ध ब्लॉक्स लोड करना: निष्पादन परिवेश के कॉन्फ़िगरेशन के आधार पर उन सभी ब्लॉक्स को इकट्ठा करना जिन्हें वर्कफ़्लो में उपयोग किया जा सकता है

2. डायनेमिक ब्लॉक्स को कंपाइल करना: डायनेमिक ब्लॉक्स परिभाषाओं को मानक वर्कफ़्लो ब्लॉक्स में बदलना

3. वर्कफ़्लो परिभाषा का पार्स करना: वर्कफ़्लो को परिभाषित करने वाले JSON दस्तावेज़ को पढ़ना और उसकी व्याख्या करना, तथा सिंटैक्स त्रुटियों का पता लगाना

4. वर्कफ़्लो निष्पादन ग्राफ़ बनाना: ऐसा ग्राफ़ बनाना जो परिभाषित करता है कि निष्पादन के दौरान डेटा वर्कफ़्लो में कैसे प्रवाहित होगा, और वर्कफ़्लो की अखंडता की जाँच करना

5. ब्लॉक्स से वर्कफ़्लो चरणों को आरंभ करना: उपलब्ध ब्लॉक्स, चरण परिभाषाओं और निष्पादन परिवेश के कॉन्फ़िगरेशन के आधार पर अलग-अलग वर्कफ़्लो चरणों को सेट करना।

यदि परिभाषा में roboflow_core/inner_workflow@v1 चरण सबसे पहले सहेजे गए-वर्कफ़्लो संदर्भों को हल करता है, नेस्टेड संयोजन (गहराई, कुल संख्या, चक्रीयता रहितता) को मान्य करता है, और इनलाइन करता है बाल-चरणों को अभिभावक पहले में पार्सिंग और निष्पादन ग्राफ़ बनाने की प्रक्रिया। देखें आंतरिक workflows (nested definitions) पूर्ण पाइपलाइन के लिए, parameter_bindingsऔर परिवेश सीमाएँ।

आइए वर्कफ़्लो कंपाइलेशन के प्रत्येक चरण पर थोड़ा और नज़दीक से नज़र डालें।

वर्कफ़्लोज़ ब्लॉक्स लोड करना

जैसा कि ब्लॉक्स बंडलिंग गाइडमें बताया गया है, वर्कफ़्लो ब्लॉक्स के एक समूह को वर्कफ़्लो प्लगइन में पैकेज किया जा सकता है। प्लगइन मूलतः एक मानक Python लाइब्रेरी होती है, जिसके मुख्य मॉड्यूल में विशिष्ट फ़ंक्शन एक्सपोज़ किए जाते हैं जो वर्कफ़्लो ब्लॉक्स को गतिशील रूप से लोड करने की अनुमति देते हैं।

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

Roboflow प्रदान करता है roboflow_core प्लगइन, जिसमें मूलभूत वर्कफ़्लो ब्लॉक्स का एक सेट शामिल है जो हमेशा कंपाइलर द्वारा लोड किए जाते हैं, क्योंकि कंपाइलर और ये ब्लॉक्स दोनों inference पैकेज में बंडल किए गए हैं।

कस्टम प्लगइन्स के लिए, एक बार जब वे Python परिवेश में इंस्टॉल हो जाते हैं, तो उन्हें WORKFLOWS_PLUGINSनामक एक पर्यावरण चर का उपयोग करके संदर्भित करना होता है। इस चर में उन Python पैकेजों के नाम होने चाहिए जिनमें प्लगइन्स शामिल हैं, और वे कॉमा से अलग किए जाने चाहिए।

उदाहरण के लिए, यदि आपके पास दो कस्टम प्लगइन्स हैं, numpy_plugin और pandas_pluginतो आप उन्हें यह सेट करके अपने वर्कफ़्लोज़ परिवेश में सक्षम कर सकते हैं:

export WORKFLOWS_PLUGINS="numpy_plugin,pandas_plugin"

दोनों numpy_plugin और pandas_plugin लाइब्रेरी रिपॉज़िटरीज़ के पथ नहीं हैं, बल्कि उन लाइब्रेरीज़ के मुख्य मॉड्यूलों के नाम हैं जो प्लगइन्स प्रदान करती हैं (import numpy_plugin को आपके Python परिवेश में काम करना चाहिए ताकि प्लगइन को लोड किया जा सके)।

एक बार कंपाइलर सभी प्लगइन्स लोड कर लेता है, तो वह कंपाइलेशन के अगले चरण के लिए तैयार हो जाता है।

डायनेमिक ब्लॉक्स का कंपाइलेशन

का विषय डायनेमिक Python ब्लॉक्स एक अलग दस्तावेज़ पृष्ठ में कवर किया गया है। इस अनुभाग की सामग्री को समझने के लिए आपको केवल इतना जानना आवश्यक है कि वर्कफ़्लो परिभाषा में, उसी स्थान पर वर्कफ़्लो ब्लॉक्स को परिभाषित करने का एक तरीका है — JSON दस्तावेज़ में ब्लॉक मैनिफ़ेस्ट और Python कोड दोनों निर्दिष्ट करके। यह कार्यक्षमता केवल तब काम करती है जब आप वर्कफ़्लोज़ निष्पादन इंजन को अपने हार्डवेयर पर चलाते हैं, और Roboflow होस्टेड प्लेटफ़ॉर्म पर अक्षम है।

वर्कफ़्लोज़ कंपाइलर, वर्कफ़्लो परिभाषा में सीधे परिभाषित डायनेमिक Python ब्लॉक्स को रनटाइम पर पूर्ण-विशेषताओं वाले वर्कफ़्लो ब्लॉक्स में बदल सकता है। कंपाइलर इन ब्लॉक क्लासों को ब्लॉक की परिभाषा के आधार पर गतिशील रूप से जनरेट करता है, जिससे डेवलपर्स को उन्हें मैन्युअल रूप से बनाने की आवश्यकता नहीं रहती, जैसा कि वे किसी प्लगइन में करते।

एक बार यह प्रक्रिया पूरी हो जाने पर, डायनेमिक ब्लॉक्स उपलब्ध वर्कफ़्लो ब्लॉक्स के पूल में जोड़ दिए जाते हैं। इन ब्लॉक्स को फिर आपकी वर्कफ़्लो परिभाषा के steps अनुभाग में, किसी अन्य मानक ब्लॉक की तरह उपयोग किया जा सकता है।

वर्कफ़्लो परिभाषा का पार्स करना

एक बार सभी वर्कफ़्लो ब्लॉक्स लोड हो जाने के बाद, कंपाइलर प्रत्येक ब्लॉक के लिए मैनिफ़ेस्ट क्लासों को पुनः प्राप्त करता है। ये मैनिफ़ेस्ट pydantic डेटा क्लासेस होती हैं जो परिभाषा में चरण प्रविष्टियों की संरचना को परिभाषित करती हैं। पार्सिंग चरण में, वर्कफ़्लोज़ परिभाषा से संबंधित त्रुटियों को सूचित किया जाता है, उदाहरण के लिए:

• गैर-मौजूद ब्लॉक्स का उपयोग

• चरणों का अमान्य कॉन्फ़िगरेशन

• चरणों के लिए आवश्यक पैरामीटरों का अभाव

की बदौलत pydanticवर्कफ़्लोज़ कंपाइलर को अपना अलग पार्सर नहीं चाहिए। इसके अलावा, ब्लॉक निर्माता ब्लॉक मैनिफ़ेस्ट परिभाषित करने के लिए मानक Python लाइब्रेरी का उपयोग करते हैं।

वर्कफ़्लो निष्पादन ग्राफ़ बनाना

वर्कफ़्लो निष्पादन ग्राफ़ बनाना वर्कफ़्लो कंपाइलेशन का सबसे महत्वपूर्ण चरण है। यह इस प्रकार काम करता है:

वर्टिसिज़ जोड़ना

सबसे पहले, प्रत्येक इनपुट, चरण और आउटपुट को ग्राफ़ में वर्टेक्स के रूप में जोड़ा जाता है, और भविष्य में पहचान के लिए प्रत्येक वर्टेक्स को एक विशेष लेबल दिया जाता है। इन वर्टिसिज़ में मेटाडेटा भी शामिल होता है, जैसे डेटा लाइनिज़ ट्रैकिंग के लिए इनपुट वर्टिसिज़ को सीड्स से चिह्नित करना (इस पर आगे और)।

एजेस जोड़ना

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

• एक चरण से ऐसा आउटपुट काइंड प्रदान करना जो अगले चरण के अपेक्षित इनपुट काइंड से मेल नहीं खाता।

• ग़ैर-मौजूद चरणों या इनपुट्स का संदर्भ देना।

प्रत्येक एज में यह दर्शाने वाला मेटाडेटा भी होता है कि आउटपुट डेटा द्वारा किस इनपुट गुण को फ़ीड किया जा रहा है, जो कंपाइलेशन के बाद के चरणों और निष्पादन के दौरान सहायक होता है

सामान्यतः, चरण इनपुट चरण आउटपुट से डेटा "माँगते" हैं, जिससे चरण B की प्रोसेसिंग के दौरान चरण A के आउटपुट से चरण B के इनपुट तक एक एज बनता है। हालाँकि, कंट्रोल-फ़्लो ब्लॉक्स एक अपवाद हैं, क्योंकि वे डेटा स्वीकार भी करते हैं और मैनिफ़ेस्ट में अन्य चरणों की घोषणा भी करते हैं, जिससे ग्राफ़ में एक विशेष फ़्लो-कंट्रोल एज बनता है।

संरचनात्मक सत्यापन

एक बार ग्राफ़ बन जाने के बाद, कंपाइलर चक्रीयता जैसी संरचनात्मक समस्याओं की जाँच करता है ताकि यह सुनिश्चित हो सके कि ग्राफ़ को सही ढंग से निष्पादित किया जा सके।

डेटा लाइनिज़ सत्यापन

अंत में, डेटा लाइनिज़ गुण इनपुट नोड्स से भरे जाते हैं और ग्राफ़ में आगे तक ले जाए जाते हैं। तो, डेटा लाइनिज़ क्या है? लाइनिज़ पहचानकर्ताओं की एक सूची है जो चरणों के माध्यम से बैचों के निर्माण और नेस्टिंग को ट्रैक करती है, और यह निर्धारित करती है:

• डेटा का स्रोत पथ

• आयामीय स्तर का डेटा

• विभिन्न डेटा-खंडों की संगतता जिन्हें किसी चरण द्वारा संदर्भित किया जा सकता है — यह सुनिश्चित करते हुए कि चरण केवल कई स्रोतों से संबंधित बैच तत्वों को ही लेगा (इस प्रकार कि बैच तत्व सूचकांक उदाहरण: (1, 2) तब उसी डेटा-खंड को संदर्भित करता है जब दो बैच-उन्मुख इनपुट उस चरण से जुड़े हों, न कि किसी यादृच्छिक रूप से दिए गए, अलग लाइनिज़ वाले बैचों को, जिन्हें साथ में प्रोसेस करना अर्थपूर्ण नहीं होगा)

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

डेटा लाइनिज़ का मूलभूत अनुमान यह है कि सभी बैच-उन्मुख इनपुट्स को समान लाइनिज़ पहचानकर्ता दिया जाता है — इसलिए यह परोक्ष रूप से सभी इनपुट बैचों पर यह लागू करता है कि उन्हें ऐसे डेटा से भरा जाए जिसमें बैचों में संबंधित स्थितियों पर संबंधित डेटा-बिंदु हों। उदाहरण के लिए, यदि आपका वर्कफ़्लो image_1 को image_2 (और आप उन दोनों इनपुट्स को वर्कफ़्लो परिभाषा में घोषित करते हैं), तो कंपाइलर यह मानता है कि image_1[3] का संबंध image_2[3].

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

लाइनिज़ बेमेल का उदाहरण

कल्पना करें कि निम्नलिखित परिदृश्य है:

• आप अपने वर्कफ़्लो में एकल इमेज इनपुट घोषित करते हैं

• सबसे पहले आप दो अलग-अलग मॉडलों का उपयोग करके ऑब्जेक्ट डिटेक्शन करते हैं

• आप दो डायनेमिक क्रॉप चरणों का उपयोग करते हैं — क्रमशः पहले और दूसरे मॉडल की भविष्यवाणियों के आधार पर क्रॉप करने के लिए

• अब आप एक ब्लॉक का उपयोग करके दो छवियों की विशेषताओं की तुलना करना चाहते हैं (क्लासिकल कंप्यूटर विज़न विधियों का उपयोग करके)

जब आप उन दो क्रॉप चरणों से इनपुट्स को तुलना ब्लॉक में जोड़ेंगे, तो आपको क्या होने की अपेक्षा होगी?

• बिना लाइनिज़ को ट्रैक किए आप उन दो बैचों को "फ़्लैटन" और "ज़िप" कर देंगे और छवियों के जोड़ों को तुलना ब्लॉक में पास कर देंगे — समस्या यह है कि इस स्थिति में आप यह निर्धारित नहीं कर सकते कि उन तत्वों के बीच की तुलना वास्तव में अर्थपूर्ण है या नहीं — संभवतः नहीं!

• साथ लाइनिज़ ट्रैकिंग के — कंपाइलर जानता है कि आप दो ऐसे बैचों को फ़ीड करने का प्रयास कर रहे हैं जिनकी लाइनिज़ अंतिम नेस्टिंग स्तर के संबंध में मेल नहीं खाती, और वह कंपाइलेशन त्रुटि उठाता है।

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

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

यह ध्यान देना महत्वपूर्ण है कि ब्लॉक्स डाइमेंशनलिटी आवश्यकताओं को सापेक्ष शब्दों में परिभाषित करते हैं, निरपेक्ष रूप से नहीं। इसका अर्थ है कि एक ब्लॉक अपने इनपुट्स और आउटपुट्स के बीच डाइमेंशनलिटी के अंतर (या ऑफ़सेट) को निर्दिष्ट करता है। यह दृष्टिकोण ब्लॉक्स को किसी भी डाइमेंशनलिटी स्तर पर लचीले ढंग से काम करने की अनुमति देता है।

संस्करण 1 में, वर्कफ़्लोज़ कंपाइलर केवल ऐसे ब्लॉक्स का समर्थन करता है जो दो अलग-अलग आयामीता स्तरोंपर काम करते हैं। यह डिज़ाइन को सरल बनाए रखने के लिए किया गया था। यदि ऐसे ब्लॉक्स की आवश्यकता हो जो अधिक आयामीता स्तरों को भविष्य में संभालें, तो हम इस समर्थन को बढ़ाने पर विचार करेंगे।

फ़्लो-कंट्रोल को दर्शाना

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

यह सुनिश्चित करने के लिए कि वर्कफ़्लो संरचना सही है, कंपाइलर फ़्लो-कंट्रोल चरणों के लिए डेटा लाइनिज़ की जाँच उसी तरह करता है जैसा कि अनुभाग में वर्णित है डेटा-लाइनिज़ सत्यापन.

कंपाइलर मानता है कि फ़्लो-कंट्रोल चरण अन्य चरणों को प्रभावित कर सकते हैं यदि:

• फ़्लो-कंट्रोल चरण गैर-बैच-उन्मुख इनपुट्स पर काम करता है — इस स्थिति में, फ़्लो-कंट्रोल चरण जुड़े हुए चरण (और संबंधित चरणों) को पूरी तरह चलने की अनुमति दे सकता है या उसे रोक सकता है, भले ही इनपुट डेटा का एक बैच हो — सभी बैच तत्व प्रभावित होते हैं।

• फ़्लो-कंट्रोल चरण संगत लाइनिज़ वाले बैच-उन्मुख इनपुट्स पर काम करता है — यहाँ, फ़्लो-कंट्रोल चरण बैच के प्रत्येक तत्व के लिए अलग-अलग निर्णय ले सकता है कि कौन से आगे बढ़ेंगे और कौन से रोके जाएँगे।

बैच-उन्मुख संगतता

जैसा कि रेखांकित किया गया है, वर्कफ़्लोज़ बैच-उन्मुख डेटा और स्केलरपरिभाषित करते हैं। वर्कफ़्लोज़ में डेटा की प्रकृति के वर्णनसे, आप यह भी निष्कर्ष निकाल सकते हैं कि बैच-उन्मुख डेटा के विरुद्ध निष्पादित होने वाले ऑपरेशन्स के चलने के दो लगभग समकक्ष तरीके होते हैं:

• एक साथ: डेटा के पूरे बैच लेना और उन्हें प्रोसेस करना

• एक-एक करके: बैच तत्वों पर लूप चलाना और परिणाम क्रमिक रूप से प्राप्त करना

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

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

संभावित भविष्य के सुधार

इस समय, हमें यह निश्चित नहीं है कि ऊपर वर्णित व्यवहार वर्कफ़्लोज़ इकोसिस्टम की संभावनाओं को सीमित कर रहा है या नहीं। यदि आपको लगता है कि वर्णित तंत्र के परिणामस्वरूप हुई त्रुटियों के कारण आपके वर्कफ़्लोज़ नहीं चल पा रहे हैं - तो कृपया हमें GitHub issues.

ब्लॉक्स से वर्कफ़्लो चरणों को आरंभ करना

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

प्रोग्रामिंग में, हम सामान्यतः किसी क्लास का इंस्टेंस एक कंस्ट्रक्टर का उपयोग करके बनाते हैं, जिसके लिए आमतौर पर आरंभिक पैरामीटरों की आवश्यकता होती है। इसी तरह, वर्कफ़्लो ब्लॉक्स को वर्कफ़्लोज़ कंपाइलर द्वारा तब आरंभ किया जाता है जब वर्कफ़्लो में कोई चरण उस ब्लॉक का संदर्भ देता है। कुछ ब्लॉक्स को विशिष्ट आरंभिक पैरामीटरों की आवश्यकता हो सकती है, जबकि कुछ को नहीं।

जब किसी ब्लॉक को आरंभिक पैरामीटरों की आवश्यकता होती है:

• ब्लॉक को अपने आवश्यक पैरामीटर घोषित करने चाहिए, जैसा कि विस्तार से बताया गया है ब्लॉक्स विकास गाइड

• इन पैरामीटरों के मान उस परिवेश से प्रदान किए जाने चाहिए जहाँ वर्कफ़्लो निष्पादित हो रहा है।

• इन पैरामीटरों के मान उस परिवेश से प्रदान किए जाने चाहिए जहाँ वर्कफ़्लो निष्पादित हो रहा है।

यह दूसरा भाग थोड़ा कठिन लग सकता है, इसलिए आइए एक उदाहरण देखते हैं। उपयोगकर्ता गाइड मेंके अंतर्गत, उस अनुभाग में जो यह दिखाता है कि inference Python पैकेज का उपयोग करके वर्कफ़्लोज़ के साथ कैसे एकीकृत किया जाए, आपको ऐसा कोड मिल सकता है:

[...]
# ब्लॉक्स के लिए उदाहरण init पैरामीटर - ब्लॉक्स के सेट पर निर्भर
# आपके वर्कफ़्लो में उपयोग किए गए
workflow_init_parameters = {
    "workflows_core.model_manager": model_manager,
    "workflows_core.api_key": "<YOUR-API-KEY>,
    "workflows_core.step_execution_mode": StepExecutionMode.LOCAL,
}

# निष्पादन इंजन का इंस्टेंस - init(...) मेथड का आह्वान ट्रिगर करता है
# कंपाइलेशन प्रक्रिया
execution_engine = ExecutionEngine.init(
    ...,
    init_parameters=workflow_init_parameters,
    ...,
)
[...]

इस उदाहरण में, workflow_init_parameters में वे मान शामिल हैं जिन्हें ब्लॉक अनुरोधों के आधार पर वर्कफ़्लो चरणों को आरंभ करते समय कंपाइलर उपयोग करता है।

आरंभिक पैरामीटर (अक्सर "init parameters" कहलाते हैं) कंपाइलर को दो तरीकों से दिए जा सकते हैं:

• स्पष्ट रूप से: आप विशिष्ट मान प्रदान करते हैं (संख्याएँ, स्ट्रिंग्स, ऑब्जेक्ट्स, आदि)।

• अप्रत्यक्ष रूप से: डिफ़ॉल्ट मान वर्कफ़्लोज़ प्लगइन के भीतर परिभाषित होते हैं, जो या तो विशिष्ट मान हो सकते हैं या फ़ंक्शन (जिनमें कोई पैरामीटर नहीं होते) जो गतिशील रूप से मान उत्पन्न करते हैं, जैसे कि पर्यावरण चर से।

डिक्शनरी workflow_init_parameters स्पष्ट रूप से दिए गए init पैरामीटर दिखाती है। कुंजियों की संरचना महत्वपूर्ण है: {plugin_name}.{init_parameter_name}. आप केवल यह भी निर्दिष्ट कर सकते हैं {init_parameter_name}लेकिन इससे पैरामीटरों के हल होने का तरीका बदल जाता है।

पैरामीटर कैसे हल किए जाते हैं?

जब कंपाइलर किसी ब्लॉक के आवश्यक init पैरामीटर की खोज करता है, तो वह इस प्रक्रिया का पालन करता है:

1. सटीक मिलान: सबसे पहले यह स्पष्ट रूप से दिए गए पैरामीटरों में {plugin_name}.{init_parameter_name}.

2. डिफ़ॉल्ट पैरामीटर: यदि कोई मिलान नहीं मिलता, तो यह प्लगइन के डिफ़ॉल्ट पैरामीटरों की जाँच करता है।

3. सामान्य मिलान: अंत में, यह स्पष्ट रूप से दिए गए पैरामीटरों में केवल {init_parameter_name} के साथ एक सामान्य मिलान खोजता है।

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