ब्राउज़र में सौ चरणों वाले एक काल्पनिक काम पर विचार करें. मान लें कि हर चरण बाकी चरणों से स्वतंत्र रूप से 99% बार सफल होता है. हर चरण के सफल होने की संभावना 0.99^100, यानी लगभग 36.6% है.
निन्यानवे प्रतिशत बहुत अच्छा लगता है. छत्तीस प्रतिशत नहीं.
ब्राउज़र के लेन-देन वाले काम पर स्रोत चर्चा इस गणना से एक सीमित बात समझाती है: ग्राहक को लाभ तब मिलता है जब काम पूरा होता है, जबकि हर चरण पर लागत और विफलता का जोखिम बढ़ता है. यह एक धारणा पर आधारित गणित है, किसी ब्राउज़र एजेंट या Tajo सिंक की प्रकाशित सफलता दर नहीं. वास्तविक त्रुटियां एक-दूसरे पर निर्भर हो सकती हैं. एक समाप्त हो चुका लॉग इन आगे के कई कार्य एक साथ रोक सकता है.
इसलिए उपयोगी सवाल “मॉडल का पिछला क्लिक कितना सही था?” नहीं है. सवाल है, “क्या उपयोगकर्ता ने जो स्थिति मांगी थी, वह बनी?”
महत्वपूर्ण इकाई पूरा लेन-देन है
कल्पना करें कि एजेंट बीमा पोर्टल खोलता है, दस्तावेज़ खोजता है, उसे डाउनलोड करता है और पुष्टि करता है कि वह सही अकाउंट का है. वह 99 स्क्रीन पर सही जा सकता है, फिर भी सौवीं स्क्रीन पर गलत फ़ाइल डाउनलोड कर सकता है. सफल क्लिकों से भरा कॉल लॉग परिणाम को नहीं सुधारता.
यही अंतर इंटीग्रेशन पर भी लागू होता है. एजेंट API ढूंढ सकता है, फ़ील्ड मैपिंग सुझा सकता है और ड्राफ़्ट सहेज सकता है. इनमें से कोई कार्य यह नहीं बताता कि डेस्टिनेशन के संपर्क रिकॉर्ड में अब इच्छित सहमति की स्थिति है. काम तभी पूरा है जब स्वीकृत कार्य चल चुका हो और उसकी संबंधित अंतिम स्थिति जांच ली गई हो.
यह गतिविधि और पूर्णता का अंतर है. गतिविधि गिनना आसान है. पूर्णता की परिभाषा चाहिए.
फ़ाइल डाउनलोड के लिए यह अनुरोध से मेल खाते अकाउंट नंबर वाला आर्टिफ़ैक्ट हो सकता है. संपर्क सिंक के लिए सही पहचान, फ़ील्ड और अनुमति वाली संदेश स्थिति का डेस्टिनेशन रिकॉर्ड हो सकता है. जांच को उस चीज़ को देखना चाहिए जिसकी उपयोगकर्ता को परवाह थी. पिछले कॉल का हरा जवाब केवल यह दिखाता है कि कॉल ने जवाब दिया. यह ज़रूरी नहीं कि डेस्टिनेशन अपेक्षित ढंग से बदला हो.
Tajo की बिज़नेस टूल जोड़ने की गाइड हर डेटा ऑब्जेक्ट के वर्कफ़्लो और सत्य के स्रोत से शुरू होती है. ये चुनाव अंतिम जांच को अर्थ देते हैं. अगर दो सिस्टम दोनों किसी फ़ील्ड का स्वामी होने का दावा करते हैं, तो पूरी तरह निष्पादित लिखने से भी लंबे समय में गलत स्थिति बन सकती है.
एक और निर्णय की लागत
उसी काल्पनिक 99% धारणा पर दस स्वतंत्र निर्णय पूरी श्रृंखला को लगभग 90.4% बार सफल बनाते हैं. पचास निर्णयों पर यह लगभग 60.5% और सौ पर लगभग 36.6% है.
पूरी श्रृंखला की सफलता की संभावना (%)
स्वतंत्र चरणों की संख्या
- हर चरण पर कल्पित 99% सफलता
गणना किए गए मान देखें
| चरण | पूरी श्रृंखला की सफलता (%) |
|---|---|
| 0 | 100.0 |
| 10 | 90.4 |
| 25 | 77.8 |
| 50 | 60.5 |
| 75 | 47.1 |
| 100 | 36.6 |
वक्र तेज़ी से गिरता है, क्योंकि अच्छे औसत से गुणा नरम नहीं पड़ता. हर अतिरिक्त निर्णय को अपनी जगह का औचित्य दिखाना चाहिए.
इसका मतलब सभी API कॉल को एक विशाल कार्य में समेटना नहीं है. कुछ कॉल निर्धारक हैं: ज्ञात कर्सर से पेज लाना, पहचानकर्ता मिलाना या स्वीकृत मैपिंग के अनुसार फ़ील्ड लिखना. मॉडल को हर रिकॉर्ड के लिए इन पर फिर निर्णय लेने की ज़रूरत नहीं. अन्य कॉल में असली अस्पष्टता है: नया विक्रेता फ़ील्ड, बदला हुआ त्रुटि संदेश या ऐसा अनुरोध जिसका स्वामी स्पष्ट नहीं. वहां निर्णय चाहिए हो सकता है.
व्यावहारिक विभाजन यह है कि निर्णय से नियम बनाया या सुधारा जाए और स्थिर नियम को सामान्य कोड लागू करे. रिवर्स ETL दोहराए जाने वाले डेटा स्थानांतरण का उदाहरण है: हर नियमित पंक्ति का काम बातचीत नहीं, पाइपलाइन को करना चाहिए. एजेंट तब भी पाइपलाइन का नियम तय करने में मदद कर सकता है.
यह सीमा है, नारा नहीं. विक्रेता किसी फ़ील्ड का अर्थ बदल दे तो निर्धारक नियम गलत काम को भी पूरी नियमितता से दोहरा सकता है. सिस्टम को अपनी बदली हुई धारणाएं पहचानने और मामले को समीक्षा में लौटाने का तरीका चाहिए.
एक बड़ा टूल ही उत्तर क्यों नहीं है
उचित आपत्ति है: “लंबी श्रृंखलाएं विफल होती हैं तो पूरा काम एक टूल कॉल में डाल दें.” टूल स्पष्ट रूप से परिभाषित लेन-देन हो और परिणाम जांचा जा सके, तब मदद मिलती है. टूल लंबे, अनिश्चित काम को सिर्फ छिपाए तो विफल रहता है.
मान लें syncCustomer() अपडेट भेजकर success: true लौटाता है. अगर डेस्टिनेशन अपडेट बाद में लागू करता है, तो कॉल अभी अंतिम संपर्क स्थिति साबित नहीं कर सकता. टूल ने दिखने वाले चरण घटाए हैं, अनिश्चितता नहीं.
बेहतर इंटरफ़ेस महत्वपूर्ण स्थिति दिखाता है: स्वीकार हुआ, लागू हुआ, जांचा गया या विफल हुआ. इन शब्दों के पीछे प्रमाण होना चाहिए. कम प्रभाव वाले प्रीव्यू के लिए लिखने का अनुरोध स्वीकार होना पर्याप्त हो सकता है. कैम्पेन ऑडियंस या सहमति बदलने पर पूरा कहने से पहले डेस्टिनेशन जांच ज़रूरी है.
Tajo के इस प्रस्तावित दृश्य में अनुरोध स्वीकार होना और अपडेट लागू होना, डेस्टिनेशन सत्यापन से अलग हैं. अंतिम जाँच अभी बाकी है. अगला कदम साफ़ है: देखें कि डेस्टिनेशन ने क्या सेव किया. एक और सफल टूल कॉल गिनने से मूल सवाल नहीं सुलझता.
पूरा हुआ राइट भी सबूत माँगता है
क्या ग्राहक सिंक पूरा हुआ?
राइट लागू हुआ. सत्यापन बाकी है.
डेस्टिनेशन की स्थिति अभी जाँची नहीं गई है.
सिंक गतिविधि
- अनुरोध स्वीकार हुआ
- अपडेट लागू हुआ
- डेस्टिनेशन की जाँच बाकी
उदाहरण रन · 14:32 UTC
हम क्या जानते हैं
- प्रदाता का जवाब
- स्वीकार हुआ
- राइट का परिणाम
- लागू हुआ
- डेस्टिनेशन से दोबारा पढ़ना
- बाकी
सफल कॉल अंतिम स्थिति साबित नहीं करती.
यह प्रस्तावित लेआउट Tajo की गतिविधि फ़ीड पर आधारित है. चित्र में सत्यापन की स्थिति जोड़ी गई है; यह दावा नहीं करता कि डेस्टिनेशन से दोबारा पढ़ना पहले से लागू है.
माप भी बदलता है. प्रयासों की संख्या लागत की जांच में मदद करती है तो दर्ज करें. बीच की त्रुटियां टूटा चरण दिखाती हैं तो दर्ज करें. लेकिन वर्कफ़्लो को सत्यापित पूरे हुए लेन-देन से आंकें और संख्या के साथ सत्यापन विधि लिखें. “99% कॉल सफल हुए” बताने वाली टीम ने यह नहीं बताया कि ग्राहक का काम हुआ या नहीं.
MCP सर्वर परिचय दिखाता है कि टूल असिस्टेंट को दूसरे सिस्टम में कॉल करने देते हैं. टूल तक पहुंच केवल शुरुआत है. वास्तविक अनुबंध पीछे छूटी स्थिति है.
सौ अच्छे क्लिकों के बाद भी कुछ हासिल न हो सकता है. परिणाम गिनें.
अक्सर पूछे जाने वाले प्रश्न
अधिकतर सही चरणों वाला लंबा वर्कफ़्लो क्यों विफल होता है?
अगर हर चरण स्वतंत्र रूप से p संभावना से सफल होता है, तो n चरणों वाली श्रृंखला की सफलता p की घात n होती है. हर चरण के लिए कल्पित 99% सफलता पर सौ चरणों की पूरी श्रृंखला लगभग 36.6% बार पूरी होगी. वास्तविक विफलताएं आपस में जुड़ी हो सकती हैं, इसलिए यह गणना उदाहरण है, किसी एजेंट की मापी गई सफलता दर नहीं.
क्या टूल कॉल घटाने से विश्वसनीयता की गारंटी मिलती है?
नहीं. कम कॉल तभी मदद करते हैं जब संयुक्त कार्य में सही जांच और रिकवरी बिंदु दिखते रहें. एक अपारदर्शी कॉल विफल लिखने को उसी तरह छिपा सकता है जैसे लंबी श्रृंखला अपना स्थान खो सकती है.
टीम को एजेंट वर्कफ़्लो में क्या मापना चाहिए?
केवल सफल मॉडल कॉल नहीं, उपयोगकर्ता के लेन-देन की सत्यापित पूर्णता मापें. वह आर्टिफ़ैक्ट या डेस्टिनेशन स्थिति तय करें जो काम पूरा होने को साबित करे, फिर पूरी प्रक्रिया के बाद उसके मिलने की दर दर्ज करें.