प्रोडक्शनपूर्वी AI Agent Playground तयार करणे
एका कोडिंग एजंटने (coding agent) स्टॅजिंग डेटाबेस (staging database) समजून एका क्लीनअप स्क्रिप्टचा वापर केला. पण तो प्रत्यक्षात प्रोडक्शन (production) डेटाबेस होता. चुकीच्या क्रेडेंशल्समुळे (credentials) एजंटला जे सांगितले होते ते त्याने तंतोतंत केले आणि परिणामी चार महिन्यांचे ग्राहकांचे ऑर्डर्स डिलीट झाले.
ही अपयशाची घटना एजंट्स टाळण्याचे कारण नाही, तर एक 'प्लेग्राउंड' (playground) तयार करण्याचे कारण आहे.
तुम्ही एखाद्या नवीन इंजिनिअरला त्याच्या पहिल्याच दिवशी प्रोडक्शन डेटाबेसचा ॲक्सेस देत नाही. तुम्ही त्याला स्टॅजिंग एन्व्हायरमेंट (staging environment), रीड-ओन्ली ॲक्सेस (read-only access) आणि देखरेखीखालील कामे देता. एजंट्सनाही अशाच प्रकारच्या ऑनबोर्डिंगची (onboarding) गरज असते. ते एका मिनिटात हजारो कृती करू शकतात, त्यामुळे प्लेग्राउंड वगळल्यास होणारे नुकसान हजार पटीने जास्त असू शकते.
एका खऱ्या प्लेग्राउंडने तीन गोष्टी केल्या पाहिजेत:
- एजंटला त्याच्या पूर्ण 'डिसिजन लूप'मध्ये (decision loop) काम करू देणे.
- सर्व 'साइड इफेक्ट्स' (side effects) प्रत्यक्ष सिस्टिम्सपर्यंत पोहोचण्यापासून रोखणे.
- तपासणीसाठी सर्व काही रेकॉर्ड करणे.
फक्त प्रॉम्प्टची (prompt) चाचणी करू नका. प्रॉम्प्टची चाचणी म्हणजे केवळ एक प्रश्न विचारणे आणि उत्तर वाचणे होय. एजंटचे वर्तन हे 'टूल कॉल्स'ची (tool calls) एक मालिका असते. खरी अपयशाची परिस्थिती लूपच्या मध्यभागी उद्भवते, जेव्हा एखादे टूल अनपेक्षित डेटा परत करते.
तुम्हाला मॉडेलला सँडबॉक्स (sandbox) करण्याची गरज नाही. तुम्हाला 'एक्झिक्युटरला' (executor) सँडबॉक्स करण्याची गरज आहे.
जिथे टूल कॉल्स कृतींमध्ये (actions) रूपांतरित होतात, तिथे एक 'सीम' (seam) तयार करा. लाईव्ह एक्झिक्युटरऐवजी 'मॉक्स' (mocks) वापरणारा प्लेग्राउंड एक्झिक्युटर वापरा. एजंट लूपला यातील फरक समजता कामा नये. जर तुमचा एजंट थेट डेटाबेस क्लायंटला कॉल करत असेल, तर तुमच्याकडे कोणतीही 'सीम' किंवा सुरक्षा नसेल.
तीन विशिष्ट क्षेत्रांची चाचणी घ्या:
- वर्तन (Behavior): एजंट योग्य क्रमाने योग्य टूल निवडतो का?
- टूल कॉल्स (Tool calls): आर्गुमेंट्स (arguments) योग्य आहेत का आणि ते सुरक्षित मर्यादेत आहेत का?
- फेल्युअर मोड्स (Failure modes): जेव्हा एखादे API टाइमआउट होते किंवा चुकीचा (garbage) डेटा देते, तेव्हा काय होते?
नेहमी यशस्वी होणारा 'मॉक' (mock) एजंटला काहीही शिकवू शकत नाही. तुमच्या प्लेग्राउंडमध्ये नेटवर्क टाइमआउट किंवा चुकीचा (malformed) डेटा यांसारखे दोष (failures) समाविष्ट करण्याची सुविधा असावी. यामुळेच तुम्हाला समजेल की एजंट समंजसपणे पुन्हा प्रयत्न (retry) करतो की 'हॅल्युसिनेट' (hallucinate) करू लागतो.
जर तुमचा एजंट कोड चालवत असेल, तर तुम्हाला मजबूत आयसोलेशनची (isolation) गरज आहे. अविश्वसनीय कोडसाठी microVMs वापरा. केवळ सोपे आहेत म्हणून साध्या कंटेनर्सपासून (containers) सुरुवात करू नका. सोपी सेटअप व्यवस्था मोठ्या सुरक्षा घटनेला (security incident) निमंत्रण देऊ शकते.
लक्षात ठेवा की एजंट्स 'नॉन-डिटरमिनिस्टिक' (non-deterministic) असतात. एकदा यशस्वी झालेली चाचणी म्हणजे एजंट विश्वासार्ह आहे असा होत नाही. तुम्हाला तीच टास्क अनेक वेळा चालवावी लागेल. जर एखादा एजंट १० पैकी ७ वेळा यशस्वी झाला, तर तो तुमच्या अंदाजे ३०% वास्तविक वापरकर्त्यांसाठी अपयशी ठरेल. सुसंगतता (Consistency) हे तुमचे सर्वात महत्त्वाचे मोजमाप आहे.
शेवटी, 'ॲडव्हर्सरिअल टूल आउटपुट्स' (adversarial tool outputs) पासून संरक्षण करा. एजंट टूल डेटाला सूचना मानतो. एखादा दुष्ट वापरकर्ता (malicious user) एजंटला दिशाभूल करण्यासाठी 'प्रॉम्प्ट इंजेक्शन'द्वारे (prompt injection) डेटाबेसमध्ये चुकीची माहिती भरू शकतो. प्लेग्राउंडमध्ये एजंटला 'हॉस्टाईल पेलोड्स' (hostile payloads) देऊन त्याची चाचणी घ्या.
लाँच बटण नाही, तर 'ग्रॅज्युएशन पाथ' (graduation path) तयार करा:
- मॉक्स (mocks) आणि पूर्ण सँडबॉक्सिंगपासून सुरुवात करा.
- अनेक वेळा चालवून सुसंगततेची (consistency) चाचणी घ्या.
- ॲडव्हर्सरिअल इनपुट्सच्या (adversarial inputs) विरोधात चाचणी घ्या.
- प्रोडक्शनसारख्या डेटावर 'ड्राय-रन' (dry-run) मोडमध्ये चाचणी करा.
- त्यानंतरच मर्यादित (scoped), गेटेड (gated) आणि मॉनिटर केलेला ॲक्सेस द्या.
तुमच्या एजंटला कमी खर्चात चुका करण्याची जागा द्या. जेणेकरून जेव्हा गरज असेल, तेव्हा तो अचूक काम करू शकेल.
Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh
Optional learning community: https://t.me/GyaanSetuAi