AI एजंट ऑर्केस्ट्रेशनच्या सर्वोत्तम पद्धती: अपयश, मंजुरी आणि रिट्राय हाताळणे

हे मार्गदर्शक AI एजंट ऑर्केस्ट्रेशन कसे कार्य करते हे स्पष्ट करते, केंद्रीकृत, विकेंद्रीकृत आणि श्रेणीबद्ध आर्किटेक्चरची तुलना करते आणि प्रोडक्शनमधील अपयश, मंजुरी आणि रिट्राय हाताळण्याच्या सात सर्वोत्तम पद्धतींची माहिती देते.

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

एकाच प्रोजेक्टवर अनेक एजंट्स काम करत असणे अत्यंत कार्यक्षम वाटते. एक कामाचे नियोजन करतो, दुसरा डिझाइन हाताळतो आणि तिसरा कोड लिहितो. सगळे सुरळीत चालते — जोपर्यंत काही बिघडत नाही. आणि असे बिघाड तुम्हाला वाटते त्यापेक्षा जास्त वेळा होतात.

असे बिघाड टाळण्यासाठी काळजीपूर्वक वर्कफ्लो इंजिनिअरिंग आवश्यक असते. चला तर मग, ऑर्केस्ट्रेटेड वर्कफ्लो अविश्वसनीय कशामुळे होतात ते समजून घेऊ आणि प्रोडक्शनमधील विश्वसनीयतेसाठी ऑर्केस्ट्रेशनच्या सर्वोत्तम पद्धती जाणून घेऊ.

AI एजंट ऑर्केस्ट्रेशन म्हणजे काय?

AI एजंट ऑर्केस्ट्रेशन एखादे बहु-टप्पी कार्य पूर्ण करण्यासाठी अनेक AI एजंट्स, मॉडेल्स आणि टूल्स यांचा समन्वय साधते. पण कोणता एजंट आधी चालेल, त्याला कोणती माहिती मिळेल आणि त्याचे काम संपल्यानंतर काय होईल, हे कोणीतरी — किंवा कशानेतरी — ठरवावे लागते. हीच ऑर्केस्ट्रेटरची भूमिका असते — व्यवस्थापक म्हणून काम करणारा AI एजंट किंवा सॉफ्टवेअर-नियंत्रित एक्झिक्युशन लेयर.

सोप्या शब्दांत, ऑर्केस्ट्रेशन लेयर एखाद्या उद्दिष्टाचे लहान कार्यांमध्ये विभाजन करतो, अवलंबित्वांचा मागोवा घेतो, योग्य एजंट्सकडे अंमलबजावणी सोपवतो, सामायिक संदर्भ व्यवस्थापित करतो आणि आउटपुट्स एकत्र आणतो.

AI एजंट ऑर्केस्ट्रेशन कसे कार्य करते: एक्झिक्युशन इंजिनच्या आत

ऑर्केस्ट्रेटरला एखादे कार्य दिल्यानंतर काय होते ते पाहूया.

Perplexity च्या Computer कार्यशाळेतील एक उदाहरण पाहा: Salesforce, Snowflake, ईमेल, कॅलेंडर आणि अलीकडील बातम्यांमधील माहिती वापरून अकाउंट इंटेलिजन्स डॅशबोर्ड तयार करणे.

  1. उद्दिष्ट समजून घ्या आणि कामाचे नियोजन करा. ऑर्केस्ट्रेटर अपेक्षित परिणामापासून सुरुवात करतो आणि स्पष्ट अवलंबित्वांसह त्याचे कार्यांमध्ये विभाजन करतो. आमच्या डॅशबोर्डच्या उदाहरणात, यामध्ये विविध स्रोतांकडून माहिती गोळा करणे आणि तिचे तयार डिलिव्हरेबलमध्ये रूपांतर करणे समाविष्ट आहे. कोणत्या पायऱ्या इतरांवर अवलंबून आहेत आणि कोणत्या स्वतंत्रपणे चालू शकतात, हे प्लॅनर निश्चित करतो.
  2. कार्ये योग्य एजंट्सकडे राउट करा. ज्या कार्यांची अवलंबित्वे पूर्ण झाली आहेत ती ऑर्केस्ट्रेटर ओळखतो आणि विशेष एजंट्स किंवा मॉडेल्सकडे काम सोपवतो. अवलंबून असलेली कार्ये त्यांच्या पूर्वअटी पूर्ण होण्याची वाट पाहतात. Perplexity Computer अनेक फ्रंटियर मॉडेल्स वापरतो आणि वर्कफ्लोचे वेगवेगळे भाग त्या कार्यांसाठी योग्य असलेल्या सिस्टम्सकडे राउट करतो. यामुळे स्वतंत्र काम समांतरपणे चालवणेही शक्य होते.
  3. नियंत्रित वातावरणात टूल कॉल्सची अंमलबजावणी करा. एजंट्स वेब सर्च, APIs, कनेक्ट केलेली ॲप्लिकेशन्स, फाइल ऑपरेशन्स किंवा कोड एक्झिक्युशन यांसारख्या टूल्सद्वारे त्यांच्या वातावरणाशी संवाद साधतात. एक्झिक्युशन लेयर या क्रिया चालवतो आणि निकाल एजंट्सकडे परत पाठवतो.
  4. एजंट्सदरम्यान निकाल आणि संदर्भ पुढे पाठवा. एखाद्या एजंटने त्याचे कार्य पूर्ण केल्यावर, पुढील डाउनस्ट्रीम एजंटला काम सुरू ठेवण्यासाठी संबंधित आउटपुट आवश्यक असते. हँडऑफ रेकॉर्डमध्ये कार्य ID, आउटपुट संदर्भ, स्कीमा आवृत्ती आणि स्रोत मेटाडेटा असू शकतो. पुढील पायऱ्यांसाठी आवश्यक संदर्भ कायम ठेवत ऑर्केस्ट्रेटर या हँडऑफ्सचा समन्वय करतो. महत्त्वाचे म्हणजे, एजंट्सना इतर प्रत्येक एजंटच्या कामाचा संपूर्ण इतिहास त्यांच्या स्वतःच्या कॉन्टेक्स्ट विंडोमध्ये बाळगावा लागत नाही.
  5. एक्झिक्युशन स्थिती एजंटच्या संदर्भापासून वेगळी नोंदवा. एजंट्स कार्ये सुरू करतात, पूर्ण करतात किंवा त्यात अयशस्वी होतात, तसतसे एक्झिक्युशन इंजिन कार्यांच्या स्थिती, अंमलबजावणीचे प्रयत्न, आउटपुट संदर्भ आणि उर्वरित काम यांसह कायमस्वरूपी वर्कफ्लो रेकॉर्ड अपडेट करते. या रेकॉर्डमुळे ऑर्केस्ट्रेटरला प्रगतीचा मागोवा घेता येतो आणि संभाषणाच्या इतिहासातून वर्कफ्लोची पुनर्रचना करण्यासाठी LLM वर अवलंबून न राहता व्यत्ययानंतर काम पुन्हा सुरू करता येते.
  6. निकालांचे प्रमाणीकरण करा आणि पुढे काय करायचे ते ठरवा. एखादे कार्य परत आल्यावर, त्याचे आउटपुट अपेक्षित कॉन्ट्रॅक्टनुसार आहे का आणि पुढील कार्याची अवलंबित्वे पूर्ण झाली आहेत का, हे ऑर्केस्ट्रेशन लेयर तपासतो. एखादी समस्या आढळल्यास, वर्कफ्लो दुरुस्तीसाठी आधीच्या पायरीवर परत जाऊ शकतो किंवा थांबवला जाऊ शकतो. अन्यथा, तो पूर्णत्वाकडे पुढे जातो.

सोप्या वाटणाऱ्या AI एजंट ऑर्केस्ट्रेशनमागे अनेक गोष्टी एकाच वेळी घडत असतात. तुम्ही एजंट्सच्या समन्वयाची रचना कशी करता यावर एक्झिक्युशनवर तुमचे किती नियंत्रण असेल हे ठरते. आणि अर्थातच, या सर्व समन्वयामुळे अतिरिक्त ओव्हरहेड वाढतो. त्यामुळे ते नेहमीच फायदेशीर ठरत नाही.

AI एजंट ऑर्केस्ट्रेशन कधी वापरावे?

कार्याच्या वेगवेगळ्या भागांसाठी वेगवेगळ्या तज्ज्ञतेची आवश्यकता असेल, स्वतंत्र काम समांतरपणे चालू शकत असेल किंवा पुढची पायरी आधीच ठरवता येत नसेल, तेव्हा मल्टी-एजंट ऑर्केस्ट्रेशनचा विचार करा.

म्हणूनच, ऑर्केस्ट्रेशन तीन परिस्थितींमध्ये उपयुक्त ठरते:

  • कार्यांसाठी वेगवेगळ्या विशेषज्ञतांची आवश्यकता असते. उदाहरणार्थ, कोडिंग प्रोजेक्टला नियोजन, डिझाइन, डेव्हलपमेंट आणि रिव्ह्यूसाठी स्वतंत्र एजंट्सचा फायदा होऊ शकतो.
  • स्वतंत्र कार्ये समांतरपणे चालू शकतात. एकाच एजंटने सर्व काही क्रमाने पूर्ण करण्याऐवजी, अनेक एजंट्स एकाच वेळी काम करू शकतात आणि त्यांचे निकाल ऑर्केस्ट्रेटरकडे परत पाठवू शकतात.
  • समस्या मुक्त स्वरूपाची असते. पूर्वनिर्धारित क्रमाचे पालन करण्याऐवजी एजंट्सना वेगवेगळे दृष्टिकोन तपासून पाहावे लागू शकतात, निर्णय घ्यावे लागू शकतात आणि सहकार्य करावे लागू शकते.

याखेरीज, ऑर्केस्ट्रेशन हा केवळ एक महागडा ट्रेंड आहे. जास्त एजंट्स म्हणजे जास्त समन्वय आणि संभाव्यतः जास्त टोकन खर्च.

“मी सहसा सर्वात सोप्या पर्यायापासून सुरुवात करतो आणि तिथून पुढे वाढवत जातो. जर आपल्याला पायऱ्या माहीत असतील आणि त्या पुन्हा पुन्हा करता येण्याजोग्या असतील, तर तो बहुधा वर्कफ्लो असतो. एजंट्सच्या जबाबदाऱ्या, परवानग्या किंवा वापरकर्ते वेगवेगळे असतील तेव्हाच मला अनेक एजंट्स आणण्याचे कारण दिसते,” असे Josh Spilker म्हणतात, जे AirOps मध्ये सर्च मार्केटिंग प्रमुख आहेत.

तरीही, अतिरिक्त मॉडेल कॉल्स, हँडऑफ्स, लेटन्सी आणि बिघाडाच्या संभाव्य ठिकाणांच्या तुलनेत फायद्यांचे मूल्यमापन करा.

AI एजंट ऑर्केस्ट्रेशन आर्किटेक्चर्स आणि त्यांचे फायदे-तोटे

एजंट्सच्या समन्वयाची रचना करण्याच्या तीन सामान्य पद्धती आहेत — केंद्रीकृत, विकेंद्रित आणि श्रेणीबद्ध ऑर्केस्ट्रेशन. योग्य आर्किटेक्चर निवडणे एका प्रश्नावर अवलंबून असते: कामावर नियंत्रण कोणाचे आहे आणि एजंट्स एकमेकांशी समन्वय कसा साधतात?

केंद्रीकृत ऑर्केस्ट्रेशन

केंद्रीकृत ऑर्केस्ट्रेशनमध्ये, एकच ऑर्केस्ट्रेटर प्रक्रिया व्यवस्थापित करतो. तो कार्याचे विभाजन करतो, तज्ज्ञ एजंट्सकडे काम सोपवतो, त्यांच्या प्रगतीचा मागोवा घेतो आणि त्यांचे निकाल एकत्र आणतो.

फायदे-तोटे: केंद्रीकृत समन्वयामुळे एक्झिक्युशनचा मागोवा घेणे आणि एकाच नियंत्रण बिंदूवर समान नियम लागू करणे सोपे होते. मात्र, ऑर्केस्ट्रेटर अडथळा ठरू शकतो आणि सिस्टम रिकव्हरीला सपोर्ट करत नसल्यास, त्याच्या बिघाडामुळे संपूर्ण वर्कफ्लो खंडित होऊ शकतो.

विकेंद्रित ऑर्केस्ट्रेशन

विकेंद्रित ऑर्केस्ट्रेशनमध्ये, प्रत्येक निर्णयासाठी एकाच व्यवस्थापकावर अवलंबून राहण्याऐवजी एजंट्स अधिक थेटपणे समन्वय साधतात. ते संदेशांची देवाणघेवाण करू शकतात, सामायिक स्थिती वाचू शकतात आणि आपल्या पुढील पायऱ्या स्वतंत्रपणे ठरवू शकतात.

फायदे-तोटे: एजंट्स केंद्रीय प्लॅनरची वाट न पाहता काम करू शकतात, त्यामुळे हा दृष्टिकोन शोधात्मक कामासाठी आणि स्वतंत्र योगदानासाठी उपयुक्त ठरतो. पण एजंट्समध्ये मतभेद झाल्यास, ते सामायिक माहिती अपडेट करत असल्यास किंवा त्यांना सुसंगत निकालापर्यंत पोहोचायचे असल्यास समन्वय अधिक कठीण होतो.

श्रेणीबद्ध ऑर्केस्ट्रेशन

श्रेणीबद्ध ऑर्केस्ट्रेशन व्यवस्थापकाच्या पद्धतीचा अनेक स्तरांवर विस्तार करते. सर्वोच्च स्तरावरील ऑर्केस्ट्रेटर दुय्यम ऑर्केस्ट्रेटर्सकडे जबाबदारी सोपवतो, जे त्यांच्या स्वतःच्या तज्ज्ञ एजंट्सच्या गटांचा समन्वय करतात.

विक्री, वित्त आणि कायदेशीर टीम्सचा समावेश असलेल्या एंटरप्राइझ वर्कफ्लोचा विचार करा. सर्वोच्च स्तरावरील ऑर्केस्ट्रेटर प्रत्येक कार्यप्रवाह क्षेत्र-विशिष्ट समन्वयकाकडे सोपवू शकतो. त्यानंतर ते समन्वयक त्यांच्या स्वतःच्या तज्ज्ञ एजंट्सचे व्यवस्थापन करतील आणि एकत्रित निकाल कळवतील.

वर्कफ्लो इतके व्यापक असतात की एकाच ऑर्केस्ट्रेटरला ते प्रभावीपणे व्यवस्थापित करता येत नाहीत, तेव्हा ही रचना उपयुक्त ठरू शकते.

फायदे-तोटे: श्रेणीरचनांमुळे टीम्सना समन्वयाच्या जबाबदाऱ्या विभागता येतात आणि संभाव्यतः वैयक्तिक शाखांमध्येच बिघाड हाताळता येतात. मात्र, त्यांमुळे अतिरिक्त हँडऑफ्स, अधिक गुंतागुंतीचे स्थिती व्यवस्थापन आणि जास्त ऑपरेशनल ओव्हरहेड निर्माण होतो. स्थानिक रिकव्हरी ही चेकपॉइंट्स आणि एक्झिक्युशन स्थिती कशा प्रकारे अंमलात आणल्या जातात यावरही अवलंबून असते.

या आर्किटेक्चर्सची तुलना:

निकष

केंद्रीकृत

विकेंद्रित

श्रेणीबद्ध

एक्झिक्युशनची मालकी

एकच ऑर्केस्ट्रेटर कामाचे वाटप नियंत्रित करतो

एजंट्स सहकारी एजंट्स किंवा सामायिक स्थितीद्वारे समन्वय साधतात

जबाबदारी ऑर्केस्ट्रेशनच्या विविध स्तरांमध्ये विभागलेली असते

स्थितीची सुसंगतता

एकाच नियंत्रण बिंदूद्वारे समन्वय साधणे सोपे

स्पष्ट सिंक्रोनाइझेशन आणि संघर्ष हाताळणी आवश्यक

शाखांमध्ये आणि शाखांदरम्यान समन्वय आवश्यक

बिघाडाचे विलगीकरण

केंद्रीय नियंत्रक महत्त्वाचे अवलंबित्व बनू शकतो

वैयक्तिक एजंट्स स्वतंत्रपणे अयशस्वी होऊ शकतात, परंतु सामायिक इन्फ्रास्ट्रक्चर महत्त्वाचे राहते

रिकव्हरीसाठी डिझाइन केलेले असल्यास बिघाड शाखांपुरते मर्यादित ठेवता येऊ शकतात

धोरण अंमलबजावणी

सामान्य नियंत्रणे केंद्रीय पातळीवर लागू केली जाऊ शकतात

सर्व सहभागींमध्ये धोरणे सातत्याने लागू करणे आवश्यक आहे

नियंत्रणे जागतिक आणि डोमेन स्तरांवर लागू केली जाऊ शकतात

परिचालन गुंतागुंत

सामान्यतः कमी

समन्वयाची अधिक गुंतागुंत

अनेक ऑर्केस्ट्रेशन स्तरांमुळे अधिक गुंतागुंत

अनुक्रमिक, समांतर आणि हस्तांतरण-आधारित अंमलबजावणी

आणखी एक फरक समजून घेण्यासारखा आहे. एजंटचे समन्वय कोण करते, हे आर्किटेक्चर ठरवते. त्यांची कार्ये कशी पुढे सरकतात, हे अंमलबजावणी पॅटर्न ठरवतो.

अंमलबजावणीचे हे तीन पॅटर्न आहेत:

  • अनुक्रमिक वर्कफ्लो: एजंट पूर्वनिर्धारित क्रमाने काम करतात आणि एका एजंटचा निकाल दुसऱ्या एजंटचे इनपुट बनतो.
  • समांतर अंमलबजावणी: स्वतंत्र एजंट एकाच वेळी काम करतात.
  • हस्तांतरण-आधारित अंमलबजावणी: कार्य जसजसे पुढे जाते, तसतसे नियंत्रण एका विशेषज्ञ एजंटकडून दुसऱ्याकडे जाते. पुढची पायरी हाताळण्यासाठी दुसरा एजंट अधिक सक्षम असतो तेव्हा हे उपयुक्त ठरते, मात्र प्रत्येक हस्तांतरणात काम पुढे सुरू ठेवण्यासाठी आवश्यक माहिती जपली गेली पाहिजे.

हे पॅटर्न परस्परांना वगळणारे नाहीत आणि ते ऑर्केस्ट्रेशन आर्किटेक्चरशी एकास-एक जुळत नाहीत. तुमच्या वर्कफ्लोची अवलंबित्वे, समन्वयाच्या गरजा आणि स्वीकारार्ह परिचालन ओव्हरहेड यांना पूरक ठरणारी सर्वात सोपी रचना निवडणे हे उद्दिष्ट आहे.

AI एजंट ऑर्केस्ट्रेशनमधील सामान्य अपयश

ऑर्केस्ट्रेशनमध्ये साध्या दुर्लक्षापासून गुंतागुंतीच्या अडथळ्यांपर्यंत काहीही चुकू शकते. कधी कधी एखादा एजंट आपले काम योग्यरीत्या करत असल्याचे दिसते, तरीही संपूर्ण वर्कफ्लो अयशस्वी होतो. प्रत्यक्ष काम करणाऱ्या तज्ज्ञांच्या अनुभवांच्या आधारे आम्ही अविश्वसनीय ऑर्केस्ट्रेटेड वर्कफ्लोमागील काही सामान्य चुका एकत्र केल्या आहेत — त्यांच्यावर लक्ष ठेवा:

  • माहिती गमावणारे एजंट हस्तांतरण. ऑर्केस्ट्रेटर विशेषज्ञ एजंटकडे योजनेचा सारांश पाठवतो, पण त्या सारांशातून मर्यादा, अवलंबित्वे किंवा अंमलबजावणीचे तपशील गळून पडतात.
  • अकाली फॅन-इन अंमलबजावणी. सर्व अपस्ट्रीम कार्ये पूर्ण होण्यापूर्वीच डाउनस्ट्रीम एजंट निकाल एकत्रित करण्यास सुरुवात करतो.
  • अनिर्धारित (non-deterministic) सामायिक-स्थिती अपडेट्स. समांतर एजंट सुस्पष्ट मर्ज सिमँटिक्सशिवाय एकाच स्टेट कीजमध्ये लिहितात. फ्रेमवर्क अपडेट्स कसे हाताळते यावर अवलंबून, यामुळे लेखन गमावले जाणे, डुप्लिकेट डेटा, क्रमावर अवलंबून असलेले आउटपुट किंवा परस्परविरोधी बदल होऊ शकतात.
  • चेकपॉइंट आणि साइड इफेक्ट यांतील विसंगती. एखादे कार्य बाह्य ऑपरेशन करते, पण वर्कर अयशस्वी होण्यापूर्वी त्याची यशस्वी अंमलबजावणी टिकाऊ पद्धतीने नोंदवली जात नाही. पुनर्प्राप्तीच्या वेळी ऑर्केस्ट्रेटरला अपूर्ण कार्य दिसते आणि तो ते पुन्हा चालवतो.
  • मानवी मंजुरीनंतर पुन्हा सुरू करताना होणाऱ्या रेस कंडिशन. अंमलबजावणी थांबवणे आणि पुन्हा सुरू करणे यामुळे स्वतःच्या सिंक्रोनायझेशन समस्या निर्माण होतात.
  • डेलिगेशन लूप आणि पुनर्प्रयत्नांचे प्रवर्धन. जबाबदाऱ्या एकमेकांवर आच्छादित असल्यामुळे, अवलंबित्वे वर्तुळाकार असल्यामुळे किंवा पूर्णत्वाच्या अटी संदिग्ध असल्यामुळे एजंट वारंवार एकमेकांकडे काम सोपवत राहतात.
  • सूचना-स्तरावरील नियंत्रणांना अंमलबजावणी सुरक्षा समजणे. ऑर्केस्ट्रेटर एजंटना विशिष्ट संसाधने ॲक्सेस न करण्यास किंवा संवेदनशील कृती न करण्यास सांगू शकतो, पण मॉडेलच्या सूचना ऑपरेटिंग-सिस्टम परवानग्या, नेटवर्क निर्बंध किंवा अधिकृतता सीमा लागू करत नाहीत. दुर्भावनापूर्ण सूचना नसतानाही वैध उद्दिष्टांचा पाठपुरावा करताना एजंट सुरक्षा सीमा का ओलांडू शकतात, हे Perplexity चे सुरक्षा अभियांत्रिकी संशोधन अधोरेखित करते

हे अपयश किती वेगवेगळे आहेत याकडे लक्ष द्या. शेड्युलरचे अकाली संक्रमण किंवा संदिग्ध बाह्य लेखन — दोन्हींमुळे चुकीचा परिणाम येऊ शकतो, पण त्यांचा उगम अंमलबजावणी जीवनचक्राच्या वेगवेगळ्या भागांत असतो. म्हणूनच विश्वसनीय ऑर्केस्ट्रेशनसाठी प्रॉम्प्ट सुधारणे किंवा पुनर्प्रयत्न जोडणे यापेक्षा अधिक काही आवश्यक असते.

प्रोडक्शनमधील विश्वसनीयतेसाठी AI एजंट ऑर्केस्ट्रेशनच्या 7 सर्वोत्तम पद्धती

1. स्पष्ट कार्य करार, स्वीकृती निकष आणि थांबण्याच्या अटी निश्चित करा

अस्पष्ट उद्दिष्टे आणि काम पूर्ण झाल्याची व्याख्या स्पष्ट नसणे यामुळे एजंटने तयार केलेले निकाल अनेकदा निराशाजनक ठरतात. यावर उपाय म्हणजे प्रॉम्प्ट करार (एजंटसाठी कामाची व्याप्ती): अंमलबजावणी सुरू होण्याच्या आधी उद्दिष्ट, मर्यादा, आउटपुट फॉरमॅट आणि अपयशाच्या अटींवर सहमती निश्चित करा.

उदाहरणार्थ, अधूनमधून अयशस्वी होणारी इंटिग्रेशन चाचणी दुरुस्त करण्याची जबाबदारी असलेल्या एजंटसाठी तुम्ही असा करार निश्चित करू शकता:

  • उद्दिष्ट: चेकआउट API च्या अस्थिर (flaky) इंटिग्रेशन चाचणीचे कारण ओळखा आणि ते दुरुस्त करा.
  • इनपुट: चाचणीचा सोर्स कोड, CI अपयश लॉग, अलीकडील कमिट आणि संबंधित ॲप्लिकेशन कोड.
  • मर्यादा: चाचण्या अक्षम करू नका, असर्शन्स शिथिल करू नका किंवा असंबंधित ॲप्लिकेशन वर्तन बदलू नका.
  • अपेक्षित आउटपुट: कोड पॅच, मूळ कारणाचे स्पष्टीकरण आणि चाचणी अंमलबजावणीचे निकाल.
  • स्वीकृती निकष: आधी अयशस्वी होणारी चाचणी सलग 10 रनमध्ये उत्तीर्ण होते आणि संबंधित रिग्रेशन संच उत्तीर्ण होतो.
  • अपयशाच्या अटी: मूळ कारण निश्चित करता येत नाही, दुरुस्तीमुळे रिग्रेशन निर्माण होतात किंवा आवश्यक चाचणी वातावरण उपलब्ध नाही.

पण आणखी एक महत्त्वाचा भाग आहे: एजंटने केव्हा थांबावे?

समाधानकारक निकाल मिळाला नाही म्हणून एजंटने अनिश्चित काळ पुनरावृत्ती करत राहू नये. यशस्वी पूर्णता म्हणजे काय, अंशतः पूर्ण झालेले कार्य केव्हा परत करायचे आणि एखादी आवश्यकता पूर्ण करता येत नसल्यामुळे केव्हा थांबायचे, हे निश्चित करा. डेलिगेशनची कमाल खोली आणि पुनरावृत्ती मर्यादा किंवा अंमलबजावणी बजेट सेट करा, जेणेकरून न सुटलेली कार्ये कधीही न संपणारे लूप बनणार नाहीत.

आपल्या CI उदाहरणाकडे परत येऊ. तुम्ही पुढील थांबण्याच्या अटी निश्चित करू शकता:

  • यश: दुरुस्ती सलग 10 चाचणी रनमध्ये आणि संबंधित रिग्रेशन संचात उत्तीर्ण होते.
  • पुनरावृत्ती मर्यादा: एजंट जास्तीत जास्त दोन संभाव्य दुरुस्त्यांचा प्रयत्न करू शकतो.
  • अंमलबजावणी बजेट: समस्या सुटली नाही तरीही एजंटने 60 मिनिटांनंतर थांबणे आवश्यक आहे.
  • डेलिगेशन मर्यादा: एजंट एका विशेषज्ञ एजंटकडे काम सोपवू शकतो; त्यापुढे कोणत्याही उप-एजंटकडे काम सोपवता येणार नाही.
  • अंशतः पूर्णता: दोन्ही प्रयत्न अयशस्वी झाल्यास किंवा वेळेची मर्यादा संपल्यास, एजंट त्याचे निष्कर्ष, प्रयत्न केलेले बदल आणि चाचणी निकाल परत करतो.
  • अडथळलेली अंमलबजावणी: चाचणी वातावरण उपलब्ध नसल्यास, एजंट यश मिळाल्याचा दावा करण्याऐवजी थांबतो आणि अडथळ्याची माहिती देतो.

2. ऑर्केस्ट्रेटर हलके ठेवा आणि संरचित हस्तांतरण लागू करा

कधी कधी डेव्हलपर ऑर्केस्ट्रेटरवर खूप जास्त जबाबदाऱ्या टाकतात आणि विशेषज्ञ एजंटचे समन्वय करण्याऐवजी तो स्वतःच कोड लिहू लागतो, डीबगिंग करू लागतो किंवा तपशीलवार पुनरावलोकने करू लागतो. यामुळे अडथळा निर्माण होतो: ऑर्केस्ट्रेटर आपले कॉन्टेक्स्ट बजेट अंमलबजावणीच्या तपशिलांवर खर्च करतो, डेलिगेशनला विलंब करतो आणि निकालांची जबाबदारी अस्पष्ट करतो.

म्हणून ऑर्केस्ट्रेटरना त्यांचे काम करू द्या आणि ठोस आर्टिफॅक्टचा संदर्भ देऊन हस्तांतरण लागू करा: मूळ कार्य, संबंधित इनपुट, आउटपुट आर्टिफॅक्ट, अंमलबजावणीची स्थिती आणि कोणत्याही न सुटलेल्या समस्या.

हे उदाहरण पाहा: status: completed हे एजंटला सोपवलेल्या कामाचा संदर्भ देते, संपूर्ण वर्कफ्लोचा नाही. चाचण्या अजूनही pending असल्यामुळे ऑर्केस्ट्रेटरने अंतिम निकाल मंजूर करू नये.

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. वर्कफ्लोची स्थिती जतन करा आणि कॉन्टेक्स्टची वाढ नियंत्रित करा

एजंटचा संभाषण इतिहास हा वर्कफ्लोच्या प्रगतीची विश्वसनीय नोंद नसतो. त्याची कॉन्टेक्स्ट विंडो भरल्यावर, स्वयंचलित कॉम्पॅक्शनमुळे महत्त्वाचे तपशील गळू शकतात. आणि एखादा वर्कर क्रॅश झाल्यास, कोणत्या पायऱ्या प्रत्यक्षात पूर्ण झाल्या हे पुढच्या एजंटला माहीत असणे आवश्यक असते.

उदाहरणार्थ, कोडिंग एजंटने पॅच तयार केला आणि नंतर तो क्रॅश झाला, तर पुढच्या वर्करने जतन केलेला आर्टिफॅक्ट मिळवून नोंदवलेल्या वर्कफ्लो स्थितीपासून काम पुढे सुरू ठेवले पाहिजे. पण एजंटने बाह्य CI रनही सुरू केला असेल, तर ती कृती पुन्हा करण्यापूर्वी ऑर्केस्ट्रेटरने त्या रनची स्वतंत्रपणे पडताळणी करून स्थिती जुळवून घेणे आवश्यक आहे

म्हणून अंमलबजावणीची स्थिती एजंटच्या कार्यरत कॉन्टेक्स्टपासून वेगळी ठेवा. कार्यांच्या स्थिती, अंमलबजावणीचे प्रयत्न, पूर्ण झालेल्या पायऱ्या आणि आर्टिफॅक्ट संदर्भ टिकाऊ स्टोरेजमध्ये जतन करा. त्याच वेळी, संपूर्ण अंमलबजावणी इतिहास एजंटच्या कॉन्टेक्स्ट विंडोमध्ये कोंबण्याऐवजी, केवळ त्याच्या सध्याच्या कार्याशी संबंधित सूचना, इनपुट आणि निकालच लोड करा.

4. अपयशांची जाणीव ठेवणारे पुनर्प्रयत्न आणि पुनर्प्राप्त करता येणारी टूल अंमलबजावणी डिझाइन करा

समजा तुमचा CI एजंट चाचणी रन सुरू करतो, पण API विनंतीचा टाइमआउट होतो. चाचणी रन सुरूच झाला नाही, की CI सेवेने तो रांगेत टाकला आणि प्रतिसाद हरवला?

टाइमआउट झाला म्हणजे ऑपरेशन अयशस्वी झाले असेच नाही. म्हणूनच पुढे काय करायचे हे ठरवण्यापूर्वी तुम्हाला त्रुटींमध्ये फरक करणे आवश्यक आहे:

  • तात्पुरत्या त्रुटी (429, 503): मर्यादित एक्सपोनेन्शियल बॅकऑफ आणि जिटरसह पुन्हा प्रयत्न करा आणि Retry-After दिलेले असल्यास त्याचे पालन करा.
  • पडताळणी किंवा परवानगी त्रुटी (400, 403): तीच विनंती पुन्हा पाठवण्याऐवजी थांबा किंवा मूळ समस्या दुरुस्त करा.
  • संदिग्ध परिणाम (संभाव्य लेखनानंतर टाइमआउट): ऑपरेशन पुन्हा करण्याचा प्रयत्न करण्यापूर्वी ते यशस्वी झाले का, हे तपासा.

टीप: पुन्हा प्रयत्न करता येणाऱ्या त्रुटींनाही मर्यादा आवश्यक असतात. प्रत्येक टूल कॉलसाठी टाइमआउट सेट करा, पुनर्प्रयत्नांची संख्या आणि एकूण पुनर्प्रयत्न वेळ मर्यादित करा आणि वर्कफ्लोची एकूण अंतिम मुदत लागू करा, जेणेकरून नेस्टेड एजंट तेच ऑपरेशन वारंवार पुन्हा सुरू करू शकणार नाहीत. एखादे अवलंबित्व वारंवार अयशस्वी होत असल्यास, विनंत्या तात्पुरत्या थांबवण्यासाठी सर्किट ब्रेकर वापरा.

बाह्य साइड इफेक्ट असलेल्या ऑपरेशनसाठी, प्रत्येक तार्किक कृतीला स्थिर आयडेम्पोटन्सी की द्या आणि सर्व पुनर्प्रयत्नांमध्ये तीच पुन्हा वापरा. API सर्व्हर-साइड डीडुप्लिकेशनला समर्थन देत असल्यास, ते कृती दोनदा न करता पुनरावृत्त विनंत्या ओळखू शकते. तसे नसल्यास, कोरिलेशन ID किंवा इतर अधिकृत संदर्भ वापरून बाह्य सिस्टमला क्वेरी करा.

काय घडले हे निश्चित करता येत नसल्यास, थांबा आणि प्रकरण वरिष्ठ स्तरावर पाठवा.

आमच्या CI एजंटसाठी पुनर्प्रयत्न लॉजिकचे स्यूडोकोड स्वरूपातील उदाहरण:

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

कोड टीप: हे उदाहरण असे गृहीत धरते की CI API विनंती ID द्वारे रन शोधण्यास समर्थन देते. request_id केवळ तेव्हाच डुप्लिकेट टाळतो, जेव्हा प्रदाता स्पष्टपणे आयडेम्पोटन्सीची हमी देतो. bounded_retry() हा केवळ स्पष्टीकरणासाठीचा स्यूडोकोड आहे. प्रोडक्शनमध्ये, पुनर्प्रयत्न हे प्रति-ऑपरेशन पुनर्प्रयत्न बजेट (कमाल प्रयत्न किंवा उलटून गेलेला वेळ) आणि वर्कफ्लोची एकूण अंतिम मुदत या दोन्हींनी मर्यादित असले पाहिजेत.

अनेक सेवांमध्ये पसरलेल्या दीर्घ वर्कफ्लोसाठी, नंतरच्या पायऱ्या अयशस्वी झाल्यास भरपाई कृतींचे समन्वय करण्यासाठी Saga पॅटर्न वापरण्याचा विचार करा. फक्त लक्षात ठेवा की भरपाई म्हणजे नेहमीच पूर्ण रोलबॅक नसतो. तुम्ही डेटाबेस अपडेट उलटवू शकता, पण पाठवलेला ईमेल परत घेऊ शकत नाही.

5. स्पष्ट संसाधन बजेटसह कामाचे रूटिंग आणि समांतरीकरण करा

येथे दोन गोष्टींचा समतोल साधायचा आहे: प्रत्येक कार्याला किती मॉडेल क्षमता हवी आहे आणि तुम्ही एकाच वेळी किती कार्ये चालवू शकता. यापैकी कोणतीही गोष्ट चुकली, तर एजंट सामायिक API कोट्यासाठी स्पर्धा करण्याचा किंवा केवळ महागड्या कारणमीमांसा मॉडेलवर अवलंबून राहण्याचा धोका असतो.

जेव्हा मॉडेल निवडीचा प्रश्न येतो, तेव्हा मॉडेलची क्षमता आणि कारणमीमांसेचा प्रयत्न कार्याच्या गुंतागुंतीशी जुळवा — हे सोपे आहे, पण बऱ्याचदा दुर्लक्षित राहते. लक्षात घ्या की तुम्ही रूटिंग नियम कॉन्फिगर करून मॉडेलचे मूल्यमापन स्वतः करू शकता, किंवा तुमच्यासाठी मॉडेल निवड हाताळणारा ऑर्केस्ट्रेशन प्लॅटफॉर्म वापरू शकता.

उदाहरणार्थ, Perplexity Computer चा Effort Mode तुम्हाला मॉडेल मॅन्युअली न निवडता एखाद्या कार्याला किती प्रयत्न द्यायचे ते निवडू देतो. Light, Standard, High किंवा Ultra निवडा, आणि Perplexity आपोआप ऑर्केस्ट्रेटिंग मॉडेल आणि त्याचा कारणमीमांसा स्तर निवडते. त्यानंतर तो ऑर्केस्ट्रेटर उप-कार्ये सहाय्यक एजंटकडे सोपवतो, जे वेगवेगळ्या प्रदात्यांची मॉडेल वापरू शकतात.

Perplexity गुणवत्ता आणि खर्च यांच्या दृष्टीने मॉडेल कॉन्फिगरेशनचे मूल्यमापन करते आणि तुलनात्मक निकाल देणाऱ्या कमी खर्चिक पर्यायांना प्राधान्य देते. तुम्हाला मॉडेल आणि कारणमीमांसा स्तर स्वतः निवडायचा असल्यास, तुम्ही Custom नियंत्रणेही वापरू शकता.

समांतरतेसाठी, मर्यादा तुमच्या इन्फ्रास्ट्रक्चर आणि बाह्य अवलंबित्वांवरून ठरली पाहिजे. सामायिक API च्या विनंती आणि टोकन दर मर्यादा तपासा, नंतर वाढत्या समवर्तितेसह तुमच्या वर्कफ्लोची लोड-टेस्ट करा. थ्रूपुट सुधारतो का, की विनंत्या रांगेत अडकू लागतात, मंदावतात किंवा 429 त्रुटी परत करू लागतात, यावर लक्ष ठेवा.

संसाधनांचा वापर अंदाज करता येण्याजोगा ठेवण्यासाठी, संसाधन मर्यादा आणि शेड्युलिंग नियंत्रणे लागू करा:

  • समवर्तिता आणि विनंती दर नियंत्रित करा: प्रत्येक सेवेसाठी एकाच वेळी सुरू असलेल्या कॉलची संख्या मर्यादित करा आणि जादा काम रांगेत ठेवा. लक्षात ठेवा की केवळ समवर्तिता मर्यादेमुळे प्रति मिनिट विनंत्या किंवा प्रति मिनिट टोकन मर्यादा लागू होणार नाहीत.
  • टोकन आणि खर्च बजेटचा मागोवा घ्या: उप-एजंटसह संपूर्ण वर्कफ्लोमधील वापराचा हिशेब ठेवा आणि उर्वरित बजेट अपुरे असताना नवीन काम सुरू करणे थांबवा.
  • अंमलबजावणीच्या अंतिम मुदती लागू करा: कार्य आणि वर्कफ्लोसाठी वेळ मर्यादा सेट करा आणि जिथे समर्थित असेल तिथे चालू असलेल्या एजंटपर्यंत रद्दीकरण पोहोचवा.
  • अवलंबित्वांचा आदर करा: प्रत्येक एजंट एकाच वेळी सुरू करण्याऐवजी, डाउनस्ट्रीम कार्ये केवळ त्यांचे आवश्यक इनपुट उपलब्ध झाल्यावरच सुरू करा.

6. मंजुरी लागू करा आणि एजंटची अंमलबजावणी विलग करा

मॉडेलला त्याच्या स्वतःच्या कृती सुरक्षित आहेत की नाहीत हे ठरवायला कधीही सांगू नका. त्याऐवजी, एजंटना किमान-विशेषाधिकार परवानग्या द्या आणि ॲप्लिकेशन कोडमध्ये जोखमीवर आधारित मंजुरी नियम लागू करा. एजंट कोड चालवत असल्यास, ती अंमलबजावणी तुमच्या होस्ट वातावरणापासून विलग करा आणि फाइल्स, नेटवर्क आणि क्रेडेन्शियल्सचा ॲक्सेस प्रतिबंधित करा. यामुळे एजंटने चूक केल्यास किंवा असुरक्षित कोड चालवल्यास होणारे नुकसान मर्यादित राहते.

“मी अती गुंतागुंतीच्या मल्टी-एजंट सिस्टमबद्दल साशंक आहे, विशेषतः जेव्हा एजंट एकमेकांच्या कामाचे पुनरावलोकन करून ते मंजूर करतात. अशा वेळी अनेक एजंट आत्मविश्वासाने तीच चूक पुढे पाठवत राहतात आणि प्रत्यक्षात ती कोणीच पकडत नाही,” असा इशारा Spilker देतात.

मानवी मंजुरी आवश्यक असलेल्या कृतींसाठी, अंमलबजावणी थांबवा आणि नेमके प्रस्तावित ऑपरेशन जतन करा:

  • त्याचे पॅरामीटर
  • त्याचे लक्ष्य संसाधन
  • त्याचा कमिट किंवा स्थिती आवृत्ती
  • पुनरावलोकनकर्त्याचा निर्णय

तसेच, मंजुरी नाकारली गेल्यास, कालबाह्य झाल्यास किंवा प्रकरण वरिष्ठ स्तरावर पाठवण्याची गरज असल्यास काय होते हे निश्चित करा. पुन्हा सुरू करता येणाऱ्या फ्रेमवर्कसाठी हे अत्यावश्यक आहे, कारण व्यत्यय आलेला नोड पुन्हा सुरू केल्यावर त्या नोडच्या सुरुवातीपासून कोड पुन्हा चालवला जातो. व्यत्ययापूर्वीचे कोणतेही साइड इफेक्ट पुन्हा घडू शकतात.

म्हणून मंजुरी नाकारली गेल्यास किंवा कालबाह्य झाल्यास, विनंती बंद होते. अंमलबजावणीपूर्वी लक्ष्य कमिट, पॅरामीटर किंवा परवानग्या बदलल्यास, ती मंजुरी अवैध ठरवा आणि नवीन मंजुरीची विनंती करा.

पूर्णपणे स्वायत्त, एंड-टू-एंड एजंट हेच ध्येय मानण्याच्या कल्पनेलाही Spilker पाठिंबा देत नाहीत. “माझ्या मते, स्पष्ट जबाबदाऱ्या, निश्चित परवानग्या आणि योग्य टप्प्यांवर मानवी पुनरावलोकन असलेले काही केंद्रित एजंट तयार करणे हा अधिक चांगला दृष्टिकोन आहे. यामुळे पूर्ण नियंत्रण न गमावता तुम्हाला कार्यक्षमता मिळते,” असा निष्कर्ष ते काढतात.

7. आउटपुटची स्वतंत्रपणे पडताळणी करा आणि पुनर्प्राप्ती वर्तनाची चाचणी घ्या

प्रत्यक्षात अयशस्वी झालेले असताना एखाद्या एजंटने Success नोंदवल्याचा अनुभव तुम्हाला कधी आला आहे का? हे संतापजनक नसले तरी त्रासदायक नक्कीच असते, आणि त्यावर झटपट उपाय नसतो, कारण नेमके कुठे चुकले हे एजंटचा अंतिम संदेश सांगेलच असे नाही.

तपास करण्यासाठी, अंमलबजावणीदरम्यान काय घडले याचा मागोवा घ्या आणि निकालांची स्वतंत्रपणे पडताळणी करा. चला तर मग, समस्या वेगळी करून सोडवण्यासाठी थोडा वेळ देऊ.

काय चुकले हे ओळखण्यासाठी वर्कफ्लोचा मागोवा घ्या

एजंटच्या प्रॉम्प्टचे डीबगिंग करण्यापूर्वी, संपूर्ण अंमलबजावणी मार्ग कॅप्चर करा. तुम्हाला असा ट्रेस हवा आहे जो एकाच वर्कफ्लो रनअंतर्गत एजंट इन्व्होकेशन, टूल कॉल, त्रुटी आणि पुनर्प्रयत्न जोडतो.

OpenTelemetry चे GenAI semantic conventions या ऑपरेशन्सचे वर्णन करण्याची प्रमाणित पद्धत देतात. उदाहरणार्थ, invoke_workflow वर्कफ्लो अंमलबजावणी ओळखते, invoke_agent एजंट इन्व्होकेशन आणि execute_tool टूल कॉल ओळखते. प्रत्येक ऑपरेशन त्याची वेळ, स्थिती आणि संबंधित मेटाडेटासह span म्हणून नोंदवले जाऊ शकते.

या पायरीमुळे तुम्हाला अंमलबजावणी मार्गाचा ट्रेस मिळतो, त्यामुळे एजंट कुठे अडखळला हे तुम्ही ओळखू शकता.

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

अंमलबजावणी ट्रेसचे एक उदाहरण.

आउटपुटचे स्वतंत्रपणे पुनरावलोकन करा

शक्य असेल तिथे प्रोग्रॅमॅटिक तपासण्या वापरा. JSON स्कीमानुसार आउटपुटची पडताळणी करा, युनिट आणि इंटिग्रेशन चाचण्या चालवा, आवश्यक आर्टिफॅक्ट अस्तित्वात असल्याची खात्री करा आणि कृती खरोखर यशस्वी झाल्या आहेत याची पुष्टी करण्यासाठी बाह्य सिस्टमला क्वेरी करा.

व्यक्तिनिष्ठ निर्णयाची आवश्यकता असलेल्या आउटपुटसाठी — ज्यांचे मूल्यमापन प्रोग्रॅमॅटिक तपासण्यांद्वारे करता येत नाही — एक स्वतंत्र पुनरावलोकनकर्ता एजंट समाविष्ट करा. यासाठी एक दृष्टिकोन म्हणजे अंमलबजावणीकर्ता–पुनरावलोकनकर्ता–निराकरणकर्ता लूप, ज्यात एक एजंट आर्टिफॅक्ट तयार करतो, नव्या कॉन्टेक्स्टसह काम करणारा पुनरावलोकनकर्ता समस्या ओळखतो आणि पडताळणी पुन्हा चालवण्यापूर्वी निराकरणकर्ता त्या सोडवतो.

शक्य असेल तिथे पुनरावलोकनकर्त्याच्या निष्कर्षांची पडताळणी करणे तरीही आवश्यक आहे, आणि वारंवार मूल्यमापनांसाठी तुम्ही LLM-आधारित ग्रेडर वापरत असल्यास, मानवी पुनरावलोकन झालेल्या उदाहरणांशी तुलना करून त्यांच्या निर्णयांचे कॅलिब्रेशन करा.

पुनर्प्राप्तीची चाचणी घेण्यासाठी जाणूनबुजून अपयश निर्माण करा

आतापर्यंत तुम्ही एजंटनी काय कार्यान्वित केले याचा मागोवा घेतला आणि त्यांचे आउटपुट योग्य होते की नाही हे तपासले. पण एखादे कार्य अर्धवट असताना वर्कर क्रॅश झाला किंवा विनंती स्वीकारल्यानंतर API टाइम आउट झाले तर काय होते? आश्चर्याची गोष्ट म्हणजे, तुमचा वर्कफ्लो सामान्य परिस्थितीत उत्तम प्रकारे काम करू शकतो, पण रिकव्हरीदरम्यान अयशस्वी होऊ शकतो.

हे तपासण्यासाठी, चाचणी वातावरणात जाणीवपूर्वक फॉल्ट्स निर्माण करा:

  • API टाइमआउट सिम्युलेट करा
  • बाह्य राइट्स आणि चेकपॉइंट्सच्या दरम्यान वर्कर्स क्रॅश करा
  • चुकीच्या स्वरूपातील टूल आउटपुट परत करा
  • मंजुरींची मुदत संपवा

प्रत्येक चाचणीनंतर, कोणत्या पायऱ्या चालल्या, वर्कफ्लो कुठून पुन्हा सुरू झाला आणि कोणत्याही क्रिया पुन्हा केल्या गेल्या किंवा वगळल्या गेल्या का, हे पाहण्यासाठी एक्झिक्युशन ट्रेस तपासा. त्यानंतर प्रत्यक्ष परिणामांचे पुनरावलोकन करा.

समजा तुमचा CI एजंट टेस्ट रन सुरू करण्यासाठी विनंती पाठवतो, पण API प्रतिसाद टाइम आउट होतो. एजंट पुन्हा प्रयत्न करतो, त्याला यशस्वी प्रतिसाद मिळतो आणि तो Success असा अहवाल देतो. तुम्ही CI सेवा तपासेपर्यंत सर्व काही ठीक दिसते, पण तपासल्यावर लक्षात येते की एकाऐवजी दोन टेस्ट रन तयार झाले आहेत.

म्हणूनच तुम्ही वर्कफ्लोची नोंदवलेली स्टेट आणि बाह्य सिस्टममधील प्रत्यक्ष बदल या दोन्हींची पडताळणी करावी. वर्कफ्लो कोणत्याही अनपेक्षित दुष्परिणामांशिवाय अपेक्षित स्टेटपर्यंत पोहोचला तरच रिकव्हरी चाचणी उत्तीर्ण व्हावी.

तुम्हाला आढळलेली अपयशे तुमच्या रिग्रेशन चाचण्यांमध्ये जोडा, जेणेकरून भविष्यातील बदलांमुळे ती पुन्हा उद्भवणार नाहीत.

शेवटी, यश म्हणजे वर्कफ्लोने आवश्यक तपासण्या उत्तीर्ण केल्या आणि त्याच्या बाह्य परिणामांची पडताळणी झाली.

AI एजंट ऑर्केस्ट्रेशनबद्दल वारंवार विचारले जाणारे प्रश्न

एकमेकांपासून वेगळे काम करणारे AI एजंट एंटरप्राइझ स्तरावर का अपयशी ठरतात?

एकमेकांपासून वेगळे काम करणारे एजंट आपापली कार्ये योग्यरित्या पूर्ण करू शकतात, पण एकत्रितपणे विसंगत परिणाम देऊ शकतात. कल्पना करा की एक सेल्स एजंट 10:00 वाजता ग्राहकाच्या अटी मिळवतो, एक प्राइसिंग एजंट 10:05 वाजता अपडेट केलेल्या किमती वापरून कोटेशन तयार करतो आणि एक लीगल एजंट 10:07 वाजता बदललेला करार तपासतो. प्रत्येक एजंट व्यवसायाच्या वेगवेगळ्या स्नॅपशॉटसह काम करतो, त्यामुळे त्यांचे आउटपुट एकमेकांशी विसंगत असू शकतात.

एंटरप्राइझ स्तरावर ही समस्या अधिक तीव्र होते, कारण एजंट स्वतंत्रपणे अपडेट होणाऱ्या अनेक सिस्टमशी संवाद साधतात, वेगवेगळ्या परवानग्यांसह कार्य करतात आणि ते संदर्भ किंवा एक्झिक्युशन स्टेट शेअर करतीलच असे नाही.

AI एजंटमध्ये अनंत रिट्राय लूप कसे टाळावेत?

अनेक स्तरांवर मर्यादा ठेवा: टूल कॉलचे कमाल रिट्राय, एजंटची कमाल इटरेशन्स, डेलिगेशनची खोली आणि संपूर्ण वर्कफ्लोसाठी एकूण अंतिम मुदत. पुन्हा प्रयत्न करण्यापूर्वी अपयशांचे वर्गीकरण करा. तात्पुरत्या 429 प्रतिसादांसाठी, Retry-After दिलेले असल्यास त्याचे पालन करा. अन्यथा, जिटरसह मर्यादित एक्सपोनेन्शियल बॅकऑफ वापरा.

व्हॅलिडेशन किंवा परवानगी त्रुटींनंतर न बदललेल्या विनंत्यांसाठी पुन्हा प्रयत्न करणे थांबवा. एखादी डाउनस्ट्रीम सेवा वारंवार अयशस्वी होत असल्यास, सर्किट ब्रेकर एजंटना अतिरिक्त लोड निर्माण करण्यापासून रोखू शकतो.

क्रॅश झाल्यानंतर AI एजंट वर्कफ्लो पुन्हा कसा सुरू करावा?

रिकव्हरीची यंत्रणा तुमच्या रनटाइमवर अवलंबून असते. LangGraph मध्ये, PostgresSaver सारखा पर्सिस्टंट चेकपॉइंटर ग्राफ स्टेट thread_id अंतर्गत संग्रहित करतो, ज्यामुळे जतन केलेल्या स्टेटपासून एक्झिक्युशन पुढे सुरू ठेवता येते. Temporal मध्ये, दुसरा वर्कर वर्कफ्लोची इव्हेंट हिस्टरी रिप्ले करून त्याची पुनर्रचना करू शकतो. रिप्लेदरम्यान, तो आधी नोंदवलेले अ‍ॅक्टिव्हिटी परिणाम पुन्हा वापरतो.

वर्कफ्लो अजूनही चालू असताना ॲप्लिकेशन पुन्हा डिप्लॉय केले गेल्यास, जतन केलेली स्टेट आणि एक्झिक्युशन हिस्टरी कदाचित सुसंगत राहणार नाहीत. Temporal ही समस्या Worker Versioning आणि वर्कफ्लो पॅचिंगद्वारे हाताळते. चेकपॉइंट-आधारित सिस्टमसाठी, विसंगत बदल रोल आउट करण्यापूर्वी स्कीमा मायग्रेशनचे नियोजन करा आणि विद्यमान जतन केलेल्या स्टेट्सवर रिकव्हरीची चाचणी घ्या.

AI एजंट ऑर्केस्ट्रेशनच्या विश्वसनीयतेची चाचणी कशी करावी?

तीच प्रातिनिधिक कार्ये अनेक वेळा चालवा आणि pass@k (k प्रयत्नांपैकी किमान एक यशस्वी होतो का) आणि pass^k (सर्व k प्रयत्न यशस्वी होतात का) यांच्यातील फरक ओळखा

एकाच एकत्रित यश दरावर अवलंबून न राहता, कार्याच्या श्रेणीनुसार आणि वर्कफ्लो आवृत्तीनुसार परिणाम मोजा. पहिल्या प्रयत्नातील यश, वारंवार केलेल्या रनमधील सातत्य, p95 लेटन्सी, पूर्ण झालेल्या प्रत्येक कार्याचा खर्च आणि मानवी हस्तक्षेपाची आवश्यकता असलेल्या कार्यांचे प्रमाण यांचा मागोवा घ्या. यश दरांसाठी सॅम्पल साइज आणि अनिश्चितता अंतराल नोंदवा.