ब्लॉक होना विफल होना नहीं है: एजेंटों को बाउंड्री फीडबैक की आवश्यकता है
अधिकांश एजेंट सेटअप एक ब्लॉक की गई कार्रवाई (blocked action) को टूल की विफलता (tool failure) मानते हैं।
एक एजेंट एक टूल को कॉल करता है। अनुरोध (request) एक नियम तोड़ता है। सिस्टम एक सामान्य त्रुटि (generic error) लौटाता है। टूल कॉल विफल हो जाता है।
शुरुआत में यह ठीक लगता है। असुरक्षित कार्रवाई को रोक दिया गया था। लेकिन यह केवल आधी समस्या का समाधान करता है।
एक सामान्य त्रुटि एजेंट को उसकी सीमाओं के भीतर काम करने में मदद नहीं करती है। यह एक नीतिगत निर्णय (policy decision) को शोर (noise) में बदल देती है। एजेंट सुधार का अनुमान लगाने की कोशिश कर सकता है। वह वही गलती दोहरा सकता है या अलग पेलोड (payload) आज़मा सकता है। इससे बेकार के प्रयासों (retries) का एक लूप बन जाता है।
एक ब्लॉक की गई कार्रवाई एक संरचित निर्णय (structured decision) होनी चाहिए, न कि कोई अप्रत्याशित क्रैश (unexpected crash)।
जब कोई अनुरोध ब्लॉक किया जाता है, तो बाहरी सिस्टम में बदलाव नहीं होना चाहिए। हालाँकि, प्रतिक्रिया (response) को एजेंट को यह बताना चाहिए कि सुरक्षित रूप से कैसे आगे बढ़ना है।
एक साधारण त्रुटि के बजाय, एक संरचित प्रतिक्रिया (structured response) का उपयोग करें।
कल्पना कीजिए कि एक एजेंट ऐसी फ़ाइल में लिखने की कोशिश करता है जो उसकी योजना बनाने के दौरान बदल गई थी। एक सामान्य त्रुटि कहती है "failed"। एक संरचित प्रतिक्रिया कहती है:
- Decision status: conflict
- Outcome status: no impact
- Reason: stale state
- Next action: re-read target state
अब एजेंट जानता है कि लक्ष्य असंभव नहीं है। उसे केवल अपनी जानकारी अपडेट करने की आवश्यकता है। वह अनुमान लगाना बंद कर देता है और सही अगला कदम उठाता है।
यह कई परिदृश्यों (scenarios) में काम करता है:
- यदि कोई पथ दायरे से बाहर (out of scope) है, तो एक अनुमत पथ (allowed path) का सुझाव दें।
- यदि कोई प्रभाव पहले से मौजूद है, तो परिणाम का पुन: उपयोग करने का सुझाव दें।
- यदि प्रभाव बहुत अधिक है, तो मानवीय समीक्षा (human review) की प्रतीक्षा करने का सुझाव दें।
यह सीमा को नरम नहीं बनाता है। कार्रवाई ब्लॉक ही रहती है। सिस्टम सुरक्षित रहता है। आप बस एक बंद रास्ते (dead end) को एक निर्देशित पथ (guided path) में बदल रहे हैं।
आपको इसे सुरक्षा के साथ संतुलित करना होगा। सटीक फीडबैक एक खराब एजेंट को आपकी सीमाओं की जांच (probe) करने में मदद कर सकता है।
पुराने डेटा (stale data) या गलत इनपुट (malformed inputs) जैसे परिचालन घर्षण (operational friction) के लिए स्पष्ट कारण कोड (reason codes) का उपयोग करें। यदि एजेंट संदिग्ध व्यवहार दिखाता है या संकेतों को अनदेखा करता है, तो सामान्य अस्वीकृति (generic rejections) या मानवीय समीक्षा (human reviews) पर स्विच करें।
एजेंट फीडबैक को ऑडिट स्कोर से अलग रखें। एजेंट को यह जानने की आवश्यकता है कि अनुपालन (compliant) कैसे किया जाए। सिस्टम को यह जानने की आवश्यकता है कि क्या एजेंट खराब व्यवहार कर रहा है। इन दोनों कार्यों को न मिलाएं।
सीमाएं इसलिए मौजूद हैं क्योंकि एजेंट वास्तविक सिस्टम पर कार्य करने के लिए पर्याप्त उपयोगी होते जा रहे हैं। वास्तविक कार्य के नियम और सीमाएं होती हैं।
एक सीमा जो केवल विफलता लौटाती है, वह एक दीवार है। एक सीमा जो मार्गदर्शन प्रदान करती है, वह एक उपकरण (tool) है।
Blocked का अर्थ होना चाहिए:
- अपेक्षित प्रभाव नहीं हुआ।
- कारण ज्ञात है।
- अगला सुरक्षित कदम स्पष्ट है।
स्रोत: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi