𝗧𝗵𝗲 𝗠𝗼𝗱𝗲𝗹 𝗜𝘀 𝗡𝗼𝘁 𝘁𝗵𝗲 𝗣𝗿𝗼𝗱𝘂𝗰𝘁. 𝗛𝗲𝗿𝗲'𝘀 𝗪𝗵𝗮𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗜𝘀.
मी माझा वेळ AI विकसित करणाऱ्या आणि ते प्रत्यक्षात आणणाऱ्या इंजिनिअर्ससोबत काम करण्यात आणि त्यांच्याशी संवाद साधण्यात घालवतो. डेमो (demos) आणि प्रत्यक्ष प्रोडक्शन सिस्टम्स (production systems) यामध्ये एक मोठी दरी आहे. अनेक लोक या दरीबद्दल प्रामाणिक नाहीत.
प्रत्येकजण प्रत्येक गोष्टीला 'एजंट' (agent) म्हणतो. लूप असलेला एक स्क्रिप्ट म्हणजे एजंट. मेमरी असलेला चॅटबॉट म्हणजे एजंट. यामुळे इंजिनिअरिंगमध्ये चुका होतात. तुम्ही साध्या कामांसाठी गरजेपेक्षा जास्त इंजिनिअरिंग (over-engineer) करता आणि जटिल कामांसाठी अपुरे इंजिनिअरिंग (under-engineer) करता.
एका एजंटला एक उद्दिष्ट (objective) असणे आवश्यक आहे. तो फक्त सूचनांचे पालन करत नाही. एजंट पुढे काय करायचे हे स्वतः ठरवतो. तो अपयशाचे (failure) व्यवस्थापन करतो. त्याचे काम कधी संपले आहे हे त्याला समजते.
- जर एखादा माणूस तुमच्या सिस्टमला प्रत्येक पायरी सांगत असेल, तर ती एक चॅट इंटरफेस (chat interface) आहे.
- जर तुमची सिस्टम एखाद्या अयशस्वी टूल कॉल मधून (failed tool call) सावरत असेल, तर तुम्ही एक एजंट तयार करत आहात.
- जर तुमची सिस्टम एका ध्येयाचे उप-कार्यांमध्ये (subtasks) विभाजन करत असेल, तर तो एक खरा एजंट आहे.
खऱ्या एजंट डिप्लॉयमेंट्सचा (deployments) व्याप्ती मर्यादित असते. ते डॉक्युमेंट एक्स्ट्रॅक्शन (document extraction) किंवा कोड रिव्ह्यू (code review) सारखी एक गोष्ट उत्तम प्रकारे करतात. यशस्वी टीम्स नवीन मॉडेल्सच्या मागे धावत नाहीत. त्या या तीन क्षेत्रांवर लक्ष केंद्रित करतात:
- टूल डिझाइन (Tool design): इंटरफेस किती सुटसुटीत आहे?
- फेल्युअर हँडलिंग (Failure handling): जेव्हा एखादे टूल काहीही परत करत नाही, तेव्हा काय होते?
- ऑब्झर्व्हेबिलिटी (Observability): एजंटने एखादा निर्णय का घेतला, याचा मागोवा (trace) तुम्ही घेऊ शकता का?
LangChain किंवा CrewAI सारखे फ्रेमवर्क्स (frameworks) पॅटर्नपेक्षा कमी महत्त्वाचे आहेत. फ्रेमवर्क हे केवळ मचान (scaffolding) आहे, तर आर्किटेक्चर (architecture) ही प्रत्यक्ष इमारत आहे.
या पॅटर्नचा वापर करा:
- आधी नियोजन करा आणि मग अंमलबजावणी करा (Plan then execute). नियोजनासाठी एक पायरी आणि अंमलबजावणीसाठी वेगळी पायरी वापरा.
- रिट्रिव्हल (retrieval) आणि रिझनिंग (reasoning) वेगळे ठेवा. कॉन्टेक्स्ट मिळवणे (fetching context) आणि कॉन्टेक्स्टचा वापर करणे ही दोन वेगळी कामे आहेत.
- स्पष्ट हँडऑफ (Explicit handoffs). जेव्हा एक एजंट दुसऱ्या एजंटकडे काम सोपवतो, तेव्हा तो हँडऑफ व्यवस्थित स्ट्रक्चर करा.
RAG हे मानक (standard) आहे, परंतु चंकिंग (chunking) अनेकदा चुकीचे असते. जर तुम्ही डॉक्युमेंट्सचे चुकीच्या पद्धतीने विभाजन केले, तर मॉडेल कॉन्टेक्स्ट गमावते आणि हॅल्युसिनेट (hallucinates) करते. जर तुमचे RAG रिझल्ट्स निरुपयोगी असतील, तर तुमचे चंकिंग आणि मेटाडेटा (metadata) सुधारा. एम्बेडिंग मॉडेलला (embedding model) दोष देऊ नका.
मॉडेल्स अधिक चांगले होतील. कॉन्टेक्स्ट विंडोज (context windows) वाढतील. खर्च कमी होईल. परंतु यामुळे इंजिनिअरिंगमधील आव्हान बदलणार नाही. तुम्ही अशा सिस्टम्स तयार केल्या पाहिजेत ज्यावर तुम्ही लक्ष नसतानाही विश्वास ठेवता येईल.
गव्हर्नन्स (governance), ऑब्झर्व्हेबिलिटी (observability) आणि टूल वापराकडे लक्ष द्या. जे इंजिनिअर्स केवळ प्रॉम्प्ट इंजिनिअरिंगमध्ये (prompt engineering) नाही, तर सिस्टम डिझाइनमध्ये (systems design) मास्टर असतील, तेच खऱ्या अर्थाने महत्त्वाचे ठरतील.
Source: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5