AI संभाषणातील हरवलेला घटक
प्रत्येकजण AI एजंट्सबद्दल बोलत आहे. कोणत्याही टेक फीडमध्ये स्क्रोल केल्यास तुम्हाला अशा डझनान्न डेमो मिळतील, ज्यामध्ये एखादे Large Language Model (LLM) एकाच, थक्क करणाऱ्या संभाषणात विमाने बुक करणे, कोड लिहिणे किंवा सपोर्ट तिकीटर्सना उत्तरे देणे दाखवते. त्यामागचा संदेश स्पष्ट वाटतो: जर तुम्ही वापरकर्त्याला LLM शी जोडले, तर जादू घडते.
हा भ्रम पाच मिनिटांच्या डेमोसाठी उत्तम काम करतो. पण जेव्हा वास्तविक वापरकर्ते, वास्तविक डेटा आणि वास्तविक पैसा येतो, तेव्हा हा भ्रम मोडीत निघतो. प्रोडक्शनमध्ये (Production), संबंध कधीही केवळ User ↔ LLM असा नसतो. तो User ↔ एक जटिल प्रणाली असतो ज्यामध्ये LLM समाविष्ट असते. त्या प्रणालीचा असा भाग ज्याबद्दल कोणीही बोलत नाही, तो म्हणजे 'harness'—असे स्कॅफोल्डिंग (scaffolding) जे मॉडेलच्या सभोवतालच्या सर्व गोष्टी निवडते, मार्गक्रमण (route) करते, संरक्षण करते आणि त्यांचे नियोजन (orchestrate) करते. याशिवाय, तुमच्याकडे उत्पादन (product) नसते; तुमच्याकडे केवळ एक प्रोटोटाइप (prototype) असतो.
साधा लूप का मोडतो?
डेमो हे एक नियंत्रित वातावरण असते. त्यातील प्रश्न छोटे असतात, संदर्भ मर्यादित असतो आणि जोखीम कमी असते. डेव्हलपर एक सिंगल API कॉल करतो, एक ओघवती प्रतिक्रिया मिळवतो आणि प्रेक्षक टाळ्या वाजवतात. पण प्रोडक्शनमध्ये गोंधळ असतो. वापरकर्ते संदिग्ध फॉलो-अप प्रश्न विचारतात. थर्ड-पार्टी APIs टाईमआउट होतात. काल जे मॉडेल परफेक्ट JSON तयार करत होते, ते अचानक मार्कडाउन (markdown) देऊ लागते. कॉन्टेक्स्ट विंडोज (Context windows) भरून जातात. सर्वात वाईट वेळी रेट लिमिट्स (Rate limits) लागू होतात.
एका साध्या प्रॉम्प्ट-रिस्पॉन्स लूपकडे यापैकी कशाचेही उत्तर नसते. दिलेल्या कामासाठी मॉडेलचे कोणते व्हेरिएंट (variant) वापरावे, हे त्याला माहित नसते. तीन टप्पे आधी काय झाले होते, हे त्याला आठवत नाही. ते अयशस्वी कॉल पुन्हा प्रयत्न (retry) करू शकत नाही, खर्च वाढल्यावर विनंत्यांचे प्रमाण (throttle) नियंत्रित करू शकत नाही किंवा डेटाबेसमध्ये जाण्यापूर्वी आउटपुट सॅनिटाइज (sanitize) करू शकत नाही. या केवळ 'edge cases' नाहीत; हे वास्तविक जगातील सॉफ्टवेअरचे मुख्य वैशिष्ट्य आहेत. त्यांचे व्यवस्थापन करणे हे 'harness' चे काम आहे.
Harness प्रत्यक्षात काय करते?
harness ला एक असे इंजिनिअरिंग लेअर समजा, जे लँग्वेज मॉडेलला केवळ एक हुशार टेक्स्ट जनरेटर न ठेवता एक विश्वसनीय सर्व्हिस कंपोनंटमध्ये रूपांतरित करते. त्याच्या जबाबदाऱ्या ठोस आणि कमी ग्लॅमरस आहेत, आणि म्हणूनच त्याकडे दुर्लक्ष केले जाते.
दिलेल्या कामासाठी मॉडेलची निवड. प्रत्येक संवादासाठी उपलब्ध असलेल्या सर्वात शक्तिशाली फाउंडेशन मॉडेलची गरज नसते. काही कामांसाठी प्रखर तर्कशक्ती (reasoning power) लागते; तर काहींना फक्त वेग आणि कमी खर्चाची गरज असते. एक सुव्यवस्थित harness विनंत्यांचे हुशारीने मार्गक्रमण करते. उदाहरणार्थ, कस्टमर सपोर्ट एजंट येणाऱ्या संदेशाचा हेतू (intent) ओळखण्यासाठी—जसे की रिफंड विनंती की शिपिंग संबंधी प्रश्न—एका जलद आणि स्वस्त मॉडेलचा वापर करू शकतो. जर हेतू एखाद्या जटिल धोरणात्मक वादाचा असेल, तर harness हे काम अधिक सक्षम तर्कशक्ती असलेल्या मॉडेलकडे सोपवते. जर वापरकर्त्याला फक्त ट्रॅकिंग लिंक हवी असेल, तर हलके मॉडेल लगेच उत्तर देते आणि तुमचा खर्च (burn rate) नियंत्रणात राहतो.
डेटा फ्लोचे व्यवस्थापन. वास्तविक ॲप्लिकेशन्स रिकाम्या पोकळीत काम करत नाहीत. एका AI एजंटला अनेकदा वेक्टर स्टोअरमधून (vector store) कागदपत्रे मिळवणे, CRM ला क्वेरी करणे, वापरकर्त्याची अलीकडील क्रिया वाचणे आणि त्यानंतर त्या सर्वांचे एकत्रितपणे सुसंगत उत्तर तयार करणे आवश्यक असते. harness हे सर्व इनजेशन (ingestion) व्यवस्थापित करते. ते योग्य कॉन्टेक्स्ट चंक्स (context chunks) मिळवते, ते संदर्भ न गमावता टोकन मर्यादेत बसतात की नाही हे तपासते, मॉडेलसाठी त्यांची रचना करते आणि resulting आउटपुट साखळीतील पुढच्या सिस्टमकडे पाठवते. या ऑर्केस्ट्रेशनशिवाय (orchestration), मॉडेलकडे एकतर पुरेसा संदर्भ नसतो किंवा ते अनावश्यक माहितीमध्ये अडकून पडते.
त्रुटींचे (Errors) व्यवस्थापन. पारंपारिक सेवांपेक्षा LLMs वेगळ्या प्रकारे अपयशी ठरतात. ते स्ट्रक्चर्ड आउटपुटमध्ये 'हॅलुसिनेशन' (hallucinate) करतात. ते रिकामी उत्तरे देतात. मूळ मॉडेल व्हर्जनमध्ये थोडासा बदल झाला तरी ते फॉरमॅटिंग सूचनांचे उल्लंघन करतात. harness या त्रुटींना आश्चर्याऐवजी अपेक्षित वर्तन म्हणून हाताळते. ते स्कीमा (schemas) प्रमाणित करते, चुकीच्या फॉरमॅटमधील प्रतिसाद पकडते, 'exponential backoff' सह 'retry logic' लागू करते आणि मुख्य एंडपॉइंटमध्ये अडथळा आल्यास दुय्यम प्रदाता किंवा कॅश केलेल्या (cached) निकालाचा वापर करते. जेव्हा इतर सर्व प्रयत्न अपयशी ठरतात, तेव्हा ते पैसे देणाऱ्या ग्राहकाला निरर्थक माहिती देण्याऐवजी मानवी ऑपरेटरकडे (human operator) प्रकरण सोपवते.
सिस्टमची विश्वासार्हता सुनिश्चित करणे. प्रोडक्शन म्हणजे एकाच वेळी अनेक वापरकर्ते, खर्चाची मर्यादा आणि अनपेक्षित लॅटन्सी (latency). harness रेट लिमिट्स लागू करते, कनेक्शन पूलिंग व्यवस्थापित करते आणि 'circuit breakers' कार्यान्वित करते जेणेकरून एखादा संथ मॉडेल प्रदाता तुमचा संपूर्ण ॲप्लिकेशन गोठवू (freeze) शकणार नाही. ते प्रत्येक संवादाची नोंद (log) ठेवते जेणेकरून एखादे सत्र का विस्कळीत झाले याचा मागोवा तुम्ही घेऊ शकाल, आणि ते तुमच्या प्रॉम्प्ट्सचे व्हर्जनिंग करते जेणेकरून नवीन डिप्लॉयमेंटमुळे ऑडिट ट्रेलशिवाय तुमच्या एजंटचे व्यक्तिमत्व चुकून बदलणार नाही.
तेच मॉडेल, पूर्णपणे वेगळे परिणाम
हे एका अशा घटनेचे स्पष्टीकरण देते ज्याने अनेक प्रॉडक्ट टीम्स गोंधळात पडल्या आहेत. दोन कंपन्या अगदी एकच फाउंडेशन मॉडेल—समान weights, समान context window, आणि समान training cutoff—ने सुरुवात करू शकतात आणि तरीही त्यांचे अनुभव एकमेकांपासून पूर्णपणे वेगळे असू शकतात. एक अनुभव ठिसूळ, संथ आणि विचित्रपणे विसरभोळा वाटतो. दुसरा अनुभव वेगवान, सुसंगत आणि विश्वासार्ह वाटतो.
फरक कधीही मॉडेलमध्ये नसतो. तो मॉडेलभोवती असलेल्या सिस्टममध्ये असतो. एका टीमने मॉडेलला संपूर्ण प्रॉडक्ट मानले. दुसऱ्या टीमने त्याला एका शिस्तबद्ध आर्किटेक्चरमधील एक घटक (component) मानले. ही शिस्त त्या 'हार्नेस'मध्ये (harness) असते.
प्रॉम्प्ट्सकडून आर्किटेक्चरकडे होणारे संक्रमण
सुरुवातीच्या AI विकासात प्रॉम्प्ट इंजिनीअरिंगला केंद्रस्थानी ठेवले होते. शब्दावलीमध्ये बदल करणे, उदाहरणे जोडणे आणि रोल-प्ले सूचनांचा वापर करणे यामुळे आउटपुटची गुणवत्ता लक्षणीयरीत्या सुधारू शकत होती. हे कौशल्य अजूनही महत्त्वाचे आहे, परंतु स्पर्धात्मक फायद्याच्या (competitive moat) दृष्टीने त्याचे महत्त्व आता कमी होत चालले आहे. जर तुमच्याकडे योग्य 'रिट्राय पॉलिसी' (retry policy) नसेल किंवा डेटा पाइपलाइनमध्ये त्रुटी असेल ज्यामुळे खाजगी माहिती सार्वजनिक प्रतिसादात लीक होत असेल, तर केवळ प्रॉम्प्ट्स वापरून तुम्ही ती समस्या सोडवू शकत नाही.
सध्या जे खरे परिवर्तन घडत आहे, ते सॉफ्टवेअर आर्किटेक्चरकडे वळण्याचे आहे. इंजिनिअर्स आता स्टेट मशीन्स (state machines) डिझाइन करत आहेत, मॉडेल लेयर आणि ॲप्लिकेशन लॉजिकमध्ये कडक इंटरफेस (interfaces) परिभाषित करत आहेत आणि नॉन-डिटरमिनिझमला (non-determinism) एक महत्त्वाचा इंजिनीअरिंग विषय मानत आहेत. ते डिस्ट्रिब्युटेड सिस्टम्सशी संबंधित प्रश्न विचारत आहेत: एका बहु-स्तरीय संभाषणात (multi-turn conversation) स्टेट कशी टिकून राहते? जेव्हा एखादे डाउनस्ट्रीम टूल उपलब्ध नसते तेव्हा काय होते? ज्या सिस्टमचा मुख्य घटक संभाव्यतेवर (probabilistic) आधारित आहे, तिची चाचणी कशी करावी? हे ते प्रश्न आहेत जे एका खेळण्याला (toy) खऱ्या उपकरणापासून (tool) वेगळे करतात.
प्रोडक्शनसाठी निर्मिती: ऑब्झर्व्हेबिलिटी आणि कंट्रोल
जर तुम्ही प्रॉडक्ट लाँच करण्याबाबत गंभीर असाल, तर हार्नेसमध्ये दोन गोष्टींना सर्वोपरि महत्त्व आहे: ऑब्झर्व्हेबिलिटी (observability) आणि ऑर्केस्ट्रेशन (orchestration).
ऑब्झर्व्हेबिलिटी म्हणजे मॉडेलला काय मिळाले, त्याने काय परत केले आणि प्रत्येक पायरीसाठी किती वेळ लागला हे तुम्ही पाहू शकता. याचा अर्थ असा की, एखाद्या एजंटच्या निर्णय प्रक्रियेचा (decision loop) चौदा टूल कॉल्सपर्यंत मागोवा घेणे आणि तो नेमका कुठे चक्राकार (looping) फिरू लागला किंवा मूळ उद्दिष्टापासून भरकटला हे शोधणे. या दृश्यतेशिवाय (visibility), AI सिस्टममधील त्रुटी शोधणे (debugging) म्हणजे अंधारात कारचे इंजिन दुरुस्त करण्यासारखे आहे.
ऑर्केस्ट्रेशन म्हणजे तुमचे बिझनेस लॉजिक तुमच्या मॉडेल इंटरअॅक्शन लेयरपासून वेगळे राहणे. याचा अर्थ असा की, तुम्ही प्रॉम्प्ट्सचे व्हर्जनिंग (versioning) अगदी कोडप्रमाणे करणे, जेणेकरून नवीन डिप्लॉयमेंटमुळे वर्तणुकीत नकळत बदल होणार नाहीत. याचा अर्थ असा की, अपयशाच्या शक्यतांची (failure modes) जाणीवपूर्वक चाचणी घेणे—उदा. विनंतीच्या मध्यंतरी API बंद करणे, चुकीचे टूल रिझल्ट्स देणे, कॉन्टेक्स्ट विंडो ओव्हरफ्लो सिम्युलेट करणे—जेणेकरून तुमची सिस्टम स्थिर राहते की नाही हे तपासता येईल. फ्रेमवर्क्स येत आणि जात राहतात, आणि तुम्ही एखादे तयार ऑर्केस्ट्रेशन लायब्ररी वापरा किंवा स्वतःचे तयार करा, त्यामध्ये ब्रँड नेमपेक्षा शिस्त (discipline) अधिक महत्त्वाची आहे.
मुख्य निष्कर्ष
फाउंडेशन मॉडेल्समध्ये सतत सुधारणा होत राहतील. ते अधिक वेगवान, स्वस्त आणि अधिक सक्षम होतील. परंतु, अधिक शक्तिशाली इंजिनमुळे तुटलेले चेसिस (chassis) दुरुस्त होत नाही. येत्या काही वर्षांत जे यशस्वी होतील, ते केवळ सर्वोत्तम मॉडेल वापरणारे नसेल; तर ते असे असतील ज्यांनी एक विश्वासार्ह, ऑब्झर्व्हेबल आणि सुव्यवस्थित ऑर्केस्ट्रेटेड हार्नेस तयार केला आहे. ते त्यांचे ॲप्लिकेशन्स पुन्हा न लिहिता मॉडेल्स बदलू शकतील. ते खर्च नियंत्रित करू शकतील कारण हार्नेस प्रत्येक टोकनवर नियंत्रण ठेवतो. ते शांतपणे झोपू शकतील कारण त्यांच्या सिस्टम्स अपयशाच्या वेळीही व्यवस्थित (gracefully) काम करतात.
केवळ मॉडेलवर लक्ष केंद्रित करणे थांबवा. ते चालवणाऱ्या सिस्टमवर लक्ष केंद्रित करायला सुरुवात करा. भविष्य त्या इंजिनिअर्सचे आहे जे स्मार्ट मॉडेल्सभोवती स्मार्ट सिस्टम्स तयार करतात.
This article draws on ideas originally discussed by Abdulaziz Zos in "Beyond The Model".
For more discussions on AI engineering and system design, check out the GyaanSetu learning community.