ब्लॉक होणे म्हणजे अपयश नाही: एजंट्सना बाउंड्री फीडबॅकची गरज आहे

बहुतेक एजंट सेटअप्समध्ये ब्लॉक केलेल्या कृतीला टूल फेल्युअर (tool failure) मानले जाते.

एक एजंट टूल कॉल करतो. ती विनंती (request) एखादा नियम मोडते. सिस्टम एक सामान्य एरर (generic error) देते. टूल कॉल अयशस्वी ठरते.

हे सुरुवातीला ठीक वाटते. असुरक्षित कृती थांबवली गेली. पण यामुळे केवळ अर्ध्या समस्येचे निराकरण होते.

एक सामान्य एरर एजंटला त्याच्या मर्यादेत काम करण्यास मदत करत नाही. यामुळे पॉलिसीचा निर्णय केवळ गोंधळात (noise) रूपांतरित होतो. एजंट कदाचित उपाय शोधण्याचा अंदाज लावण्याचा प्रयत्न करेल. तो तीच चूक पुन्हा करू शकतो किंवा वेगळा पेलोड (payload) वापरून पाहू शकतो. यामुळे निरर्थक प्रयत्नांचे (retries) एक चक्र तयार होते.

ब्लॉक केलेली कृती ही एक स्ट्रक्चर्ड डिसीजन (structured decision) असायला हवी, अनपेक्षित क्रॅश (unexpected crash) नाही.

जेव्हा एखादी विनंती ब्लॉक केली जाते, तेव्हा बाह्य सिस्टममध्ये बदल होऊ नये. मात्र, प्रतिसादाने (response) एजंटला सुरक्षितपणे पुढे कसे जायचे हे सांगणे आवश्यक आहे.

साध्या एररऐवजी, स्ट्रक्चर्ड रिस्पॉन्स (structured response) वापरा.

कल्पना करा की एखादा एजंट अशा फाईलमध्ये लिहिण्याचा प्रयत्न करत आहे जी त्याच्या नियोजनादरम्यान बदलली आहे. एक सामान्य एरर "failed" असे सांगते. एक स्ट्रक्चर्ड रिस्पॉन्स असे सांगतो:

  • Decision status: conflict (निर्णय स्थिती: संघर्ष)
  • Outcome status: no impact (परिणाम स्थिती: कोणताही परिणाम नाही)
  • Reason: stale state (कारण: जुनी स्थिती/stale state)
  • Next action: re-read target state (पुढील कृती: लक्ष्य स्थिती पुन्हा वाचा)

आता एजंटला समजते की ध्येय अशक्य नाही. त्याला फक्त आपली माहिती अपडेट करण्याची गरज आहे. तो अंदाज लावणे थांबवतो आणि योग्य पुढचे पाऊल उचलतो.

हे अनेक परिस्थितींमध्ये उपयुक्त ठरते:

  • जर एखादा मार्ग स्कोपच्या बाहेर असेल, तर परवानगी असलेला मार्ग सुचवा.
  • जर एखादा परिणाम आधीच अस्तित्वात असेल, तर तोच परिणाम पुन्हा वापरण्याचा सल्ला द्या.
  • जर परिणाम खूप जास्त असेल, तर मानवी पुनरावलोकनासाठी (human review) थांबण्याचा सल्ला द्या.

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

तुम्हाला याचा सुरक्षेशी समतोल साधावा लागेल. अचूक फीडबॅकमुळे एखादा वाईट एजंट तुमच्या मर्यादा तपासण्यास (probe) मदत करू शकतो.

जुना डेटा (stale data) किंवा चुकीचे इनपुट (malformed inputs) यांसारख्या ऑपरेशनल अडथळ्यांसाठी स्पष्ट 'reason codes' वापरा. जर एजंट संशयास्पद वर्तन करत असेल किंवा सूचनांकडे दुर्लक्ष करत असेल, तर सामान्य नकार (generic rejections) किंवा मानवी पुनरावलोकनाकडे (human reviews) वळा.

एजंट फीडबॅक आणि ऑडिट स्कोअर (audit scores) वेगळे ठेवा. एजंटला नियमांचे पालन (compliant) कसे करायचे हे माहित असणे आवश्यक आहे. एजंटचे वर्तन खराब आहे की नाही हे सिस्टमला माहित असणे आवश्यक आहे. या दोन कामांची गल्लत करू नका.

बाउंड्रीज (Boundaries) अस्तित्वात आहेत कारण एजंट्स आता रिअल सिस्टम्सवर काम करण्यासाठी पुरेसे उपयुक्त होत आहेत. वास्तविक कामामध्ये नियम आणि मर्यादा असतात.

जी बाउंड्री केवळ 'फेल्युअर' (failure) देते ती एक भिंत आहे. जी बाउंड्री मार्गदर्शन करते ती एक साधन (tool) आहे.

'Blocked' चा अर्थ असा असावा:

  • अपेक्षित परिणाम झाला नाही.
  • कारण माहित आहे.
  • पुढील सुरक्षित कृती स्पष्ट आहे.

स्रोत: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

ऐच्छिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi