सैंडबॉक्स के बाहर AI एजेंट रिग्रेशन टेस्टिंग क्यों विफल हो जाती है

पिछले मंगलवार को ओखला औद्योगिक क्षेत्र के पास एक कार्यालय में, हमारी इंजीनियरिंग टीम ने एक अकेली अनपिन की गई डिपेंडेंसी के बोझ तले एक डिटर्मिनिस्टिक LLM मूल्यांकन हार्नेस को ढहते हुए देखा। हमने YAML सिनारियो पैक को बेहतर बनाने, सख्त अपेक्षित व्यवहारों को परिभाषित करने और बेहतरीन मूल्यांकन रूब्रिक लिखने में तीन सप्ताह बिताए। स्कोरिंग लॉजिक ने त्रुटिहीन रूप से काम किया। फिर भी, जज द्वारा पेलोड देखने से पहले ही हर एक टेस्ट रन विफल हो गया। सिंथेटिक बेंचमार्क से लेकर गंदे, प्रोडक्शन-ग्रेड एजेंट रिग्रेशन टेस्टिंग की ओर बढ़ने की यह क्रूर वास्तविकता है।

साफ़-सुथरे YAML स्कोरिंग का भ्रम

प्रारंभिक स्प्रिंट प्लानिंग के दौरान साफ-सुथरे टेस्ट स्पेसिफिकेशन लिखना हमेशा बेहद उत्पादक लगता है। आप उपयोगकर्ता के इरादों को मैप करते हैं, EvalForge में सिमुलेटेड इनपुट फीड करते हैं, और अपने LLM एजेंटों से पुनरुत्पादित आउटपुट की उम्मीद करते हैं। वह आरामदायक मानसिक मॉडल ठीक तब तक रहता है जब तक कि वितरित इंजीनियरिंग टीमों द्वारा बनाए गए वास्तविक, गंदे कोडबेस के खिलाफ फील्ड टेस्टिंग शुरू नहीं होती है।

रूब्रिक डिज़ाइन हमारे वर्कफ़्लो का वास्तविक बॉटलनैक नहीं था। हमारी प्राथमिक भूल यह मान लेना थी कि सिनारियो पैक एक अलग, सहकारी वैक्यूम में काम करता है। दिल्ली भर के स्थानीय सॉफ्टवेयर स्टार्टअप के लिए टेस्टिंग बुनियादी ढांचा बनाते समय, हमने जल्दी ही सीख लिया कि सैद्धांतिक पूर्णता कच्चे कार्यान्वयन की वास्तविकता और लीगेसी कोड पैटर्न के सामने बिखर जाती है।

📌 मुख्य बिंदु: आपके मूल्यांकन हार्नेस की जटिलता इस बात के व्युत्क्रमानुपाती होती है कि आपका लक्षित एजेंट अप्रत्याशित रनटाइम वातावरण को कितनी सफाई से संभालता है।

जब थर्ड-पार्टी डिपेंडेंसीज़ पलटवार करती हैं

वास्तविक दुनिया के एजेंट साफ-सुथरे आर्किटेक्चरल दिशानिर्देशों या पाठ्यपुस्तक के डिज़ाइन पैटर्न का पालन नहीं करते हैं। वे मॉड्यूल स्कोप पर ffmpeg जैसी भारी बाइनरी आयात करते हैं, डिप्रेकेटेड gpt-3.5-turbo एंडपॉइंट्स को हार्डकोड करते हैं, और निष्पादन शुरू होते ही सीधे प्रतिबंधित root पार्टिशन पर अस्थायी फाइलें लिखते हैं। जब आप रिग्रेशन टेस्ट ट्रिगर करते हैं, तो आपका हार्नेस केवल तार्किक तर्क का मूल्यांकन नहीं कर रहा होता है; यह शत्रुतापूर्ण कोड निष्पादन और अनियंत्रित साइड इफ़ेक्ट से बच रहा होता है।

• 1. स्वचालित बैच टेस्ट निष्पादन चक्रों के दौरान रनटाइम कंटेनरों को क्रैश करने वाली अनपिन की गई पायथन लाइब्रेरीज़।
• 2. वितरित वर्कर नोड्स में साझा ऑडिट लॉग में लीक होने वाली हार्डकोडेड API कुंजियाँ।
• 3. सिंगल टेस्ट एसरशन के चलने से पहले वैश्विक सिस्टम स्थिति को बदलने वाले मॉड्यूल-स्तरीय साइड इफ़ेक्ट।
• 4. रिमोट मॉडल कॉल के दौरान असंगत क्षेत्रीय बैंडविड्थ बाधाओं के कारण होने वाले नेटवर्क टाइमआउट।

"एक टेस्ट हार्नेस उतना ही ईमानदार होता है जितना कि आपके वैलिडेशन सूट को थर्ड-पार्टी ब्लैक बॉक्स से जोड़ने वाला नाजुक पुल।"

रेजिलिएंस के लिए टेस्टिंग हार्नेस को दोबारा तैयार करना

इस आर्किटेक्चरल कमी को ठीक करने का मतलब एक शुद्ध, हल्के टेस्टिंग फ्रेमवर्क के भ्रम को छोड़ना था। मूल्यांकन रूब्रिक आउटपुट का मूल्यांकन करने से बहुत पहले, हमें एजेंट आयात को सैंडबॉक्स करना पड़ा, कच्चे फ़ाइल सिस्टम राइट्स को रोकना पड़ा, और सख्त डिपेंडेंसी आइसोलेशन लागू करना पड़ा। वास्तविक रेजिलिएंस के लिए प्रत्येक बाहरी एजेंट को एक सहकारी API एंडपॉइंट के बजाय अविश्वसनीय, अस्थिर सॉफ्टवेयर के रूप में मानने की आवश्यकता थी।

तेज़-तर्रार इंजीनियरिंग वातावरण में विश्वसनीय मूल्यांकन पाइपलाइन बनाने के लिए पहले दिन से ही डिफेंसिव इंजीनियरिंग की आवश्यकता होती है। यदि आपका टेस्ट रनर परीक्षण के अधीन एजेंट से सहयोग की उम्मीद नहीं करता है, तो आपका रिग्रेशन सूट परिचालन वास्तविकता के बजाय इच्छाधारी सोच को माप रहा है।

खराब इंटीग्रेशन की छिपी हुई कीमत

स्वायत्त प्रणालियों का मूल्यांकन करने के लिए अंतिम प्रतिक्रिया स्ट्रिंग से आगे देखने की आवश्यकता होती है। जब आपका टेस्ट रनर क्रैश हो जाता है क्योंकि एक आयातित मॉड्यूल अनधिकृत डेटाबेस कनेक्शन का प्रयास करता है, तो विफलता का तरीका पूरी तरह से आर्किटेक्चरल होता है। इंजीनियरिंग लीड्स को निष्पादन लूप के चारों ओर गार्डरेल बनाने चाहिए। स्पष्ट प्रक्रिया सीमाओं के बिना, एक अकेला दुष्ट एजेंट कुछ ही सेकंड में आपके पूरे CI/CD टेस्टिंग क्लस्टर से समझौता कर सकता है।

मुख्य तथ्य

• 42 प्रतिशत शुरुआती टेस्ट रन स्कोरिंग लॉजिक त्रुटियों के बजाय अनपिन किए गए मॉड्यूल आयात के कारण विफल हुए।
• 3 सप्ताह हमारे फ्रेमवर्क में इंटीग्रेशन कमजोरियों का पता लगाने से पहले YAML सिनारियो पैक बनाने में बिताए गए।
• 12 हमारे नवीनतम प्रोडक्शन डिप्लॉयमेंट चक्र के दौरान साइड इफेक्ट्स के लिए ऑडिट की गई अलग-अलग थर्ड-पार्टी लाइब्रेरीज़।
• 500 मिलीसेकंड औसत विलंबता हमारे टेस्ट रनर वातावरण में फ़ाइल सिस्टम एक्सेस को सैंडबॉक्स करने से जुड़ी।

निष्कर्ष

जब हम जिस सॉफ्टवेयर का परीक्षण करते हैं वह सक्रिय रूप से आइसोलेशन का विरोध करता है, तो हम वास्तव में रेजिलिएंट मूल्यांकन उपकरण कैसे बनाते हैं? इसका उत्तर ऐसे हार्नेस को डिजाइन करने में है जो अनुपालन के बजाय अराजकता की उम्मीद करते हैं। अभी आपकी अपनी टेस्टिंग पाइपलाइन के भीतर कौन सी आर्किटेक्चरल कमियां छिपी हैं?