AI एजंट डेमोमागचे गडद सत्य
LinkedIn वर सध्या जे AI-एजंट डेमो दिसत आहेत, त्यातील बहुतेक खरे एजंट नाहीत. मी दिवसभर रिसर्च पेपर्स वाचतो आणि प्रत्यक्ष उत्पादने तयार करणाऱ्या इंजिनिअर्सशी बोलतो, आणि मला असे दिसते की चकाकणारे डेमो आणि प्रोडक्शन-रेडी सिस्टिम्स यांच्यातील अंतर वाढत चालले आहे. केवळ हायपच्या (hype) मागे धावणारे डेव्हलपर्स शेवटी ठिसूळ आणि ओव्हर-इंजिनिअर्ड टूल्स तयार करतात.
हायप का महत्त्वाचा आहे
"एजंट" हा असा एक प्रचलित शब्द (buzzword) बनला आहे जो कोणीही एखाद्या स्क्रिप्टला, चॅटबॉटला किंवा बाह्य टूल कॉल करणाऱ्या साध्या फंक्शनला जोडू शकतो. परिणामी: असे डेमो जे स्क्रीनवर प्रभावी दिसतात पण स्वायत्त प्रणालीचे (autonomous system) मुख्य गुणधर्म—जसे की स्पष्ट उद्दिष्ट, पुढचे पाऊल ठरवण्याची क्षमता आणि अंगभूत फेल्युअर हँडलिंग (failure handling)—त्यांच्याकडे नसतात. जेव्हा टीम्स एखाद्या पॉलिश केलेल्या डेमोला तयार उपाय (ready-made solution) समजतात, तेव्हा एकतर त्या साध्या कामांसाठी अनावश्यक स्कॅफोल्डिंग तयार करण्यात वेळ वाया घालवतात किंवा जटिल वर्कफ्लोसाठी ठिसूळ पाइपलाईन्स तयार करतात.
खरे आणि दिखाऊ यांच्यातील फरक ओळखणारी चेकलिस्ट
हे विश्लेषण तीन जलद प्रश्न सुचवते ज्याद्वारे डेव्हलपर खरा एजंट ओळखू शकतो:
सिस्टिमला प्रत्येक पायरीसाठी मानवी मार्गदर्शनाची गरज आहे का? जर हो असेल, तर ते केवळ एक चॅट इंटरफेस आहे, स्वायत्त एजंट नाही.
सिस्टिम एखाद्या अयशस्वी टूल कॉल मधून सावरू शकते का? एजंटने त्रुटी (failure) शोधली पाहिजे, पुन्हा प्रयत्न करायचा की पर्यायी मार्ग वापरायचा किंवा प्रक्रिया सन्मानपूर्वक थांबवायची (abort gracefully) याचा निर्णय घेतला पाहिजे.
सिस्टिम उच्च-स्तरीय उद्दिष्टांचे उप-कार्यांमध्ये (subtasks) विभाजन करते का? खरे एजंट केवळ ठराविक स्क्रिप्ट फॉलो करण्याऐवजी उद्दिष्टांचे विभाजन करतात आणि कामाचे नियोजन करतात.
यशस्वी टीम्स प्रत्यक्षात कशावर लक्ष केंद्रित करतात
मी असे निरीक्षण केले आहे की, उच्च कामगिरी करणाऱ्या इंजिनिअरिंग ग्रुप्स नवीन मॉडेल रिलीजकडे दुर्लक्ष करतात आणि तीन डिझाइन स्तंभांवर (design pillars) अधिक लक्ष केंद्रित करतात:
टूल डिझाइन
एजंट्स चांगल्या प्रकारे परिभाषित केलेल्या इंटरफेसद्वारे बाह्य सेवांशी संवाद साधतात. एक स्वच्छ API सरफेस एजंटला इनपुट्स, आउटपुट्स आणि एरर कोड्स समजून घेणे सोपे करते. फ्रेमवर्कची निवड—LangChain, CrewAI किंवा स्वतः तयार केलेली लायब्ररी—यापेक्षा डिटरमिनिस्टिक (deterministic) आणि व्हर्जन केलेले एंडपॉइंट्स उपलब्ध करून देण्याच्या शिस्तीला जास्त महत्त्व आहे.
फेल्युअर हँडलिंग
प्रत्येक बाह्य कॉल अयशस्वी होऊ शकतो. एजंटकडे टाइमआउट्स, रिट्रायज (retries), सर्किट-ब्रेकिंग आणि फॉलबॅक स्ट्रॅटेजीजसाठी धोरणे असणे आवश्यक आहे. याशिवाय, एक छोटीशी अडचण देखील संभाषणाचा शेवट करू शकते, ज्यामुळे ती मॉडेलची मर्यादा वाटू लागते, प्रत्यक्षात ती सिस्टिमची समस्या असते.
ऑब्झर्व्हेबिलिटी
जेव्हा एखादा एजंट निर्णय घेतो, तेव्हा डेव्हलपर्सना एक 'ट्रेस' (trace) आवश्यक असतो जो तर्क करण्याची पायरी (reasoning step), वापरलेले टूल आणि निकाल दर्शवेल. स्ट्रक्चर्ड लॉग्स किंवा इव्हेंट स्ट्रीम्समुळे ऑपरेटर्स एखादे सेशन पुन्हा प्ले करू शकतात, चुकीचे उत्तर कोठून आले ते शोधू शकतात आणि प्रॉम्प्टिंग किंवा टूल कॉन्फिगरेशनमध्ये सुधारणा करू शकतात.
कोणतेही फ्रेमवर्क टिकून राहणारे पॅटर्न
फ्रेमवर्क्स वेगाने विकसित होतात—LangChain आणि CrewAI दर महिन्याला जवळपास ब्रेकिंग चेंजेस रिलीज करतात. हे विश्लेषण असे सुचवते की लायब्ररीपेक्षा पॅटर्नवर लक्ष केंद्रित केले पाहिजे. खालील काही पुनरावृत्ती होणारे स्ट्रक्चर्स आहेत जे व्हर्जन अपग्रेडमध्येही टिकून राहतात:
प्लॅन-देन-एक्झिक्युट (Plan-then-execute) तर्क करण्याची प्रक्रिया (उदा. "मी पुढे काय केले पाहिजे?") आणि कृतीची प्रक्रिया (उदा. "billing API कॉल करा") वेगळी करा. यामुळे प्रॉम्प्टची लांबी कमी होते आणि मॉडेलचे आउटपुट डिटरमिनिस्टिक राहते.
रिट्रिव्हल आणि रिझनिंग वेगळे करा (Separate retrieval from reasoning) संदर्भ मिळवणे (knowledge base शोधणे, दस्तऐवज लोड करणे) ही माहिती वापरून प्रश्नाचे उत्तर देण्याच्या प्रक्रियेपेक्षा वेगळी गोष्ट आहे. या दोन्ही गोष्टी एकत्र केल्यामुळे प्रॉम्प्टचा आकार वाढतो आणि त्रुटी शोधणे कठीण होते.
स्पष्ट हँडऑफ्स (Explicit handoffs) जेव्हा एक एजंट दुसऱ्या एजंटकडे काम सोपवतो—समजा, एक प्लॅनर उप-कार्य डेटा-फेचरकडे सोपवतो—तेव्हा स्ट्रक्चर्ड हँडऑफ फॉरमॅट (JSON किंवा परिभाषित स्कीमा) वापरा. प्राप्त करणारा एजंट कृती करण्यापूर्वी डेटाची पडताळणी करू शकतो, ज्यामुळे सिस्टिम अधिक मजबूत होते.
एक सामान्य चूक: RAG चंकिंग
रिट्रिव्हल-ऑगमेंटेड जनरेशन (RAG) सिस्टिम्समध्ये जेव्हा उत्तरे विषयांतर करतात, तेव्हा अनेकदा लँग्वेज मॉडेलला दोष दिला जातो. पण हे विश्लेषण असे सांगते की खरा दोषी अनेकदा 'चंकिंग स्ट्रॅटेजी' (chunking strategy) असते. दस्तऐवजाचे असे तुकडे करणे ज्यामुळे वाक्ये कापली जातात किंवा अर्थाची सीमा हरवते, यामुळे मॉडेलला आवश्यक असलेला संदर्भ मिळत नाही. मेटाडेटा टॅग्स, ओव्हरलॅप विंडोज आणि चंक साइजमध्ये सुधारणा केल्यास मॉडेल न बदलता कामगिरी सुधारता येते.
निष्कर्ष
जर तुम्ही अशी AI सिस्टिम बनवत असाल जी स्वतःहून काम करू शकते, तर LinkedIn वर तुमचा डेमो किती चकाकणारा दिसतो यावरून यश मोजणे थांबवा. तुमचा कोड उद्दिष्टांचे विभाजन करू शकतो का, टूल फेल्युअरमध्ये टिकून राहू शकतो का आणि डीबगिंगसाठी स्पष्ट मार्ग (breadcrumb trail) सोडतो का, याची खात्री करा. हे तीन इंजिनिअरिंग सवयी—विचारपूर्वक टूल डिझाइन, शिस्तबद्ध फेल्युअर हँडलिंग आणि फुल-स्टॅक ऑब्झर्व्हेबिलिटी—एका चकाकणाऱ्या प्रोटोटाइपला एक विश्वासार्ह एजंटमध्ये बदलतात.