AI एजेंट डेमो के पीछे का काला सच
LinkedIn पर बाढ़ की तरह आ रहे अधिकांश AI-एजेंट डेमो असली एजेंट नहीं हैं। मैं अपना दिन शोध पत्र पढ़ने और उन इंजीनियरों से बात करने में बिताता हूँ जो उत्पाद (products) लॉन्च करते हैं, और मैं देख रहा हूँ कि शानदार दिखने वाले डेमो और प्रोडक्शन-रेडी सिस्टम के बीच की खाई बढ़ती जा रही है। जो डेवलपर्स केवल हाइप (hype) के पीछे भागते हैं, वे अंततः नाजुक और ओवर-इंजीनियर्ड टूल्स बनाते हैं।
हाइप क्यों मायने रखती है
"एजेंट" एक ऐसा बज़वर्ड बन गया है जिसे कोई भी किसी स्क्रिप्ट, चैटबॉट, या किसी बाहरी टूल को कॉल करने वाले साधारण फंक्शन के साथ जोड़ सकता है। परिणाम: ऐसे डेमो जो स्क्रीन पर प्रभावशाली दिखते हैं लेकिन उनमें एक स्वायत्त प्रणाली (autonomous system) के मुख्य गुणों की कमी होती है—जैसे एक स्पष्ट उद्देश्य, अगला कदम तय करने की क्षमता, और इन-बिल्ट विफलता प्रबंधन (failure handling)। जब टीमें एक पॉलिश किए हुए डेमो को तैयार समाधान समझ लेती हैं, तो वे या तो सरल कार्यों के लिए अनावश्यक ढांचा (scaffolding) बनाने में मेहनत बर्बाद करती हैं या जटिल वर्कफ़्लो के लिए नाजुक पाइपलाइनें तैयार करती हैं।
वह चेकलिस्ट जो असली को दिखावे से अलग करती है
यह विश्लेषण तीन त्वरित प्रश्न प्रस्तावित करता है जो एक डेवलपर को असली एजेंट की पहचान करने में मदद करते हैं:
क्या सिस्टम को हर कदम पर मार्गदर्शन के लिए इंसान की ज़रूरत होती है? यदि हाँ, तो यह केवल एक चैट इंटरफ़ेस है, स्वायत्त एजेंट नहीं।
क्या सिस्टम विफल टूल कॉल (failed tool call) से उबर सकता है? एक एजेंट को विफलता का पता लगाना चाहिए, यह तय करना चाहिए कि दोबारा प्रयास करना है, किसी वैकल्पिक तरीके पर जाना है, या शालीनता से प्रक्रिया को रोकना है।
क्या सिस्टम एक उच्च-स्तरीय लक्ष्य को उप-कार्यों (subtasks) में तोड़ता है? असली एजेंट एक निश्चित स्क्रिप्ट का पालन करने के बजाय उद्देश्यों को विभाजित करते हैं और कार्यों को शेड्यूल करते हैं।
सफल टीमें वास्तव में किस पर ध्यान केंद्रित करती हैं
मैंने देखा है कि उच्च प्रदर्शन करने वाले इंजीनियरिंग समूह नए मॉडल रिलीज़ को नज़रअंदाज़ करते हैं और तीन डिज़ाइन स्तंभों (design pillars) पर ज़ोर देते हैं:
टूल डिज़ाइन
एजेंट अच्छी तरह से परिभाषित इंटरफेस के माध्यम से बाहरी सेवाओं के साथ इंटरैक्ट करते हैं। एक साफ API सतह एजेंट के लिए इनपुट, आउटपुट और एरर कोड के बारे में तर्क करना आसान बनाती है। फ्रेमवर्क का चुनाव—LangChain, CrewAI, या कोई स्व-निर्मित लाइब्रेरी—नियतात्मक (deterministic), वर्शन किए गए एंडपॉइंट्स को उजागर करने के अनुशासन की तुलना में बहुत कम मायने रखता है।
विफलता प्रबंधन
हर बाहरी कॉल विफल हो सकती है। एक एजेंट के पास टाइमआउट, रिट्राइ (retries), सर्किट-ब्रेकिंग और फॉलबैक रणनीतियों के लिए नीतियां होनी चाहिए। इनके बिना, एक छोटी सी बाधा एक ऐसी बातचीत में बदल जाती है जो मॉडल की सीमा के बजाय सिस्टम की समस्या की तरह लगती है।
ऑब्जर्वेबिलिटी
जब एक एजेंट कोई निर्णय लेता है, तो डेवलपर्स को एक ऐसे ट्रेस (trace) की आवश्यकता होती है जो तर्क के चरण (reasoning step), कॉल किए गए टूल और परिणाम को दिखाए। स्ट्रक्चर्ड लॉग या इवेंट स्ट्रीम ऑपरेटरों को एक सत्र को फिर से चलाने, यह पता लगाने कि गलत उत्तर कहाँ से आया, और प्रॉम्प्टिंग या टूल कॉन्फ़िगरेशन में सुधार करने की अनुमति देते हैं।
वे पैटर्न जो किसी भी फ्रेमवर्क से अधिक लंबे समय तक टिकते हैं
फ्रेमवर्क तेज़ी से विकसित होते हैं—LangChain और CrewAI लगभग हर महीने बड़े बदलाव (breaking changes) लाते हैं। विश्लेषण का तर्क है कि ध्यान लाइब्रेरी पर नहीं, बल्कि पैटर्न पर होना चाहिए। नीचे वे आवर्ती संरचनाएं (recurring structures) दी गई हैं जो वर्शन अपग्रेड के बाद भी बनी रहती हैं:
पहले योजना बनाएं फिर क्रियान्वित करें (Plan-then-execute) तर्क चरण (जैसे, "मुझे आगे क्या करना चाहिए?") को क्रिया चरण (जैसे, "बिलिंग API को कॉल करें") से अलग करें। यह प्रॉम्प्ट की लंबाई को कम करता है और मॉडल के आउटपुट को नियतात्मक (deterministic) रखता है।
रिट्रीवल को रीजनिंग से अलग करें (Separate retrieval from reasoning) संदर्भ प्राप्त करना (नॉलेज बेस खोजना, दस्तावेज़ लोड करना) उस संदर्भ का उपयोग प्रश्न का उत्तर देने के लिए करने से एक अलग कार्य है। दोनों को मिलाने से प्रॉम्प्ट का आकार बढ़ जाता है और विफलताओं का निदान करना कठिन हो जाता है।
स्पष्ट हैंडऑफ (Explicit handoffs) जब एक एजेंट दूसरे को काम सौंपता है—मान लीजिए, एक प्लानर किसी डेटा-फेचर को उप-कार्य सौंपता है—तो एक स्ट्रक्चर्ड हैंडऑफ फॉर्मेट (JSON या एक परिभाषित स्कीमा) का उपयोग करें। प्राप्त करने वाला एजेंट कार्य करने से पहले पेलोड को वैलिडेट कर सकता है, जिससे मजबूती (robustness) बढ़ती है।
एक सामान्य गलती: RAG चंकिंग
रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) सिस्टम अक्सर तब भाषा मॉडल को दोष देते हैं जब उत्तर विषय से हटकर होते हैं। विश्लेषण बताता है कि असली अपराधी अक्सर चंकिंग रणनीति (chunking strategy) होती है। दस्तावेज़ को ऐसे टुकड़ों में विभाजित करना जो वाक्यों को काट देते हैं या अर्थ संबंधी सीमाओं को खो देते हैं, मॉडल को उस संदर्भ से वंचित कर देता है जिसकी उसे आवश्यकता होती है। मेटाडेटा टैग, ओवरलैप विंडो और चंक आकार को ठीक करने से आमतौर पर मॉडल को बदले बिना प्रदर्शन बहाल हो जाता है।
निष्कर्ष
यदि आप एक ऐसा AI सिस्टम बना रहे हैं जिसे अपने आप काम करने की आवश्यकता है, तो सफलता को इस आधार पर मापना बंद करें कि LinkedIn पर डेमो कितना शानदार दिखता है। सत्यापित करें कि आपका कोड लक्ष्यों को विभाजित कर सकता है, टूल की विफलताओं से बच सकता है, और डिबगिंग के लिए एक स्पष्ट निशान (breadcrumb trail) छोड़ सकता है। वे तीन इंजीनियरिंग आदतें—विचारशील टूल डिज़ाइन, अनुशासित विफलता प्रबंधन और फुल-स्टैक ऑब्जर्वेबिलिटी—एक शानदार प्रोटोटाइप को एक भरोसेमंद एजेंट में बदल देती हैं।