प्रोडक्शन से पहले एक AI एजेंट प्लेग्राउंड बनाना

एक कोडिंग एजेंट ने एक बार एक क्लीनअप स्क्रिप्ट चलाई, जिसे उसने स्टेजिंग डेटाबेस समझा था। वास्तव में वह प्रोडक्शन डेटाबेस था। एजेंट ने चार महीने के ग्राहकों के ऑर्डर डिलीट कर दिए क्योंकि उसने गलत क्रेडेंशियल्स के साथ ठीक वही किया जो उसे बताया गया था।

यह विफलता एजेंटों से बचने का कारण नहीं है। यह एक प्लेग्राउंड बनाने का कारण है।

आप किसी नए इंजीनियर को उसके पहले दिन ही प्रोडक्शन डेटाबेस का एक्सेस नहीं देंगे। आप उन्हें एक स्टेजिंग एनवायरनमेंट, रीड-ओनली एक्सेस और सुपरवाइज्ड टास्क देते हैं। एजेंटों को भी इसी तरह के ऑनबोर्डिंग की आवश्यकता होती है। वे एक मिनट में हज़ार एक्शन ले सकते हैं, इसलिए प्लेग्राउंड को छोड़ने की कीमत हज़ार गुना अधिक हो सकती है।

एक वास्तविक प्लेग्राउंड को तीन काम करने चाहिए:

• एजेंट को अपना पूरा डिसीजन लूप (decision loop) चलाने दें।
• सभी साइड इफेक्ट्स को वास्तविक सिस्टम तक पहुँचने से रोकें।
• निरीक्षण (inspection) के लिए सब कुछ रिकॉर्ड करें।

केवल प्रॉम्प्ट का परीक्षण न करें। प्रॉम्प्ट का परीक्षण करने का अर्थ है एक प्रश्न पूछना और उत्तर पढ़ना। एक एजेंट का व्यवहार टूल कॉल्स (tool calls) का एक क्रम होता है। वास्तविक विफलताएं लूप के बीच में तब होती हैं जब कोई टूल अप्रत्याशित डेटा लौटाता है।

आपको मॉडल को सैंडबॉक्स करने की आवश्यकता नहीं है। आपको एक्जीक्यूटर (executor) को सैंडबॉक्स करने की आवश्यकता है।

जहाँ टूल कॉल्स एक्शन में बदलते हैं, वहाँ एक सीम (seam) बनाएँ। लाइव एक्जीक्यूटर के बजाय मॉक्स (mocks) का उपयोग करने वाले प्लेग्राउंड एक्जीक्यूटर का उपयोग करें। एजेंट लूप को इस अंतर का पता नहीं चलना चाहिए। यदि आपका एजेंट सीधे डेटाबेस क्लाइंट को कॉल करता है, तो आपके पास न तो कोई सीम है और न ही कोई सुरक्षा।

तीन विशिष्ट क्षेत्रों का परीक्षण करें:

• व्यवहार (Behavior): क्या एजेंट सही क्रम में सही टूल चुनता है?
• टूल कॉल्स (Tool calls): क्या आर्गुमेंट्स सही हैं और सुरक्षित सीमाओं के भीतर हैं?
• विफलता मोड (Failure modes): क्या होता है जब कोई API टाइम आउट हो जाता है या कचरा (garbage) डेटा लौटाता है?

एक मॉक जो हमेशा सफल होता है, वह एजेंट को कुछ नहीं सिखाता। आपके प्लेग्राउंड को नेटवर्क टाइमआउट या खराब डेटा (malformed data) जैसी विफलताओं को इंजेक्ट करने की अनुमति देनी चाहिए। इसी तरह आप देख सकते हैं कि क्या एजेंट समझदारी से दोबारा प्रयास करता है या मतिभ्रम (hallucinating) करने लगता है।

यदि आपका एजेंट कोड चलाता है, तो आपको मजबूत आइसोलेशन (isolation) की आवश्यकता है। अविश्वसनीय कोड के लिए microVMs का उपयोग करें। केवल इसलिए सरल कंटेनरों से शुरुआत न करें क्योंकि वे आसान हैं। एक आसान सेटअप एक बड़ी सुरक्षा घटना (security incident) का कारण बन सकता है।

याद रखें कि एजेंट नॉन-डिटरमिनिस्टिक (non-deterministic) होते हैं। एक बार पास होने वाला टेस्ट यह नहीं दर्शाता कि एजेंट विश्वसनीय है। आपको एक ही कार्य को कई बार चलाना चाहिए। यदि कोई एजेंट 10 में से 7 बार पास होता है, तो यह आपके लगभग 30% वास्तविक उपयोगकर्ताओं के लिए विफल हो जाएगा। निरंतरता (Consistency) आपका सबसे महत्वपूर्ण मीट्रिक है।

अंत में, एडवर्सरियल टूल आउटपुट (adversarial tool outputs) से सुरक्षा करें। एक एजेंट टूल डेटा को निर्देशों के रूप में मानता है। एक दुर्भावनापूर्ण उपयोगकर्ता एजेंट को नियंत्रित करने के लिए प्रॉम्प्ट इंजेक्शन के साथ डेटाबेस में डेटा डाल सकता है। प्लेग्राउंड में एजेंट को शत्रुतापूर्ण पेलोड (hostile payloads) देकर उसका परीक्षण करें।

लॉंच बटन नहीं, बल्कि एक ग्रेजुएशन पाथ (graduation path) बनाएँ:

• मॉक्स और पूर्ण सैंडबॉक्सिंग के साथ शुरुआत करें।
• कई रन के माध्यम से निरंतरता का परीक्षण करें।
• एडवर्सरियल इनपुट के खिलाफ परीक्षण करें।
• प्रोडक्शन-नुमा डेटा के खिलाफ ड्राई-रन मोड पर जाएँ।
• उसके बाद ही सीमित (scoped), गेटेड और मॉनिटर किया गया एक्सेस दें।

अपने एजेंट को कम लागत में गलत होने की जगह दें। फिर वह वहां सही हो सकता है जहां इसकी वास्तव में आवश्यकता है।

Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh

Optional learning community: https://t.me/GyaanSetuAi