तुमच्या टीमला या आठवड्यात चांगल्या AI मॉडेलची गरज नाही
नवीन AI मॉडेल्स शोधणे थांबवा. तुम्हाला ज्या खऱ्या अपग्रेडची गरज आहे, ती म्हणजे तुमचा वर्कफ्लो (workflow).
बहुतेक टीम्स कोणते मॉडेल अधिक हुशार वाटते यावर लक्ष केंद्रित करतात. ते नवीन रिलीझचे बेंचमार्क तपासतात आणि बुद्धिमत्तेबद्दल वाद घालतात. पण जर तुम्ही LLMs सोबत काम करत असाल, तर तुम्हाला खरी अडचण माहित आहे. समस्या खराब कोडची नाहीये. समस्या खराब अंमलबजावणीची (execution) आहे.
तुम्हाला या समस्या दिसून येतात:
- एजंट लूप्स (Agent loops) जे कामाच्या अर्धवट टप्प्यावर थांबतात.
- अप्रूव्हल प्रॉम्प्ट्स (Approval prompts) जे लोकांना गोंधळात टाकतात.
- रिट्राय (retries) दरम्यान तुटणारे कॉन्टेक्स्ट चेन्स (Context chains).
- ऑटोमेशनची स्थिती (state) गमावल्यामुळे मानवांना काम दुरुस्त करावे लागते.
बुद्धिमत्ता वाढत आहे, पण ऑपरेशनल कंट्रोल (operational control) मागे पडत आहे. आपण 'ऑर्केस्ट्रेशन टॅक्स'च्या (orchestration tax) युगात प्रवेश करत आहोत. जर तुम्ही यासाठी नियोजन केले नाही, तर तुम्हाला सिस्टम आउटेज (outages) आणि शांत अपयशांच्या (silent failures) स्वरूपात त्याची किंमत चुकवावी लागेल.
AI आउटपुट हे क्वचितच अंतिम उत्पादन असते. ते एका मोठ्या सिस्टममधील एक मध्यवर्ती टप्पा आहे. तुम्हाला या प्रश्नांची उत्तरे शोधणे आवश्यक आहे:
- टाइमआउट (timeout) नंतर काम पुन्हा सुरू होऊ शकते का?
- आपण प्रत्येक अप्रूव्हलचे ऑडिट करू शकतो का?
- ड्युप्लिकेट कृतींशिवाय आपण स्टेप्स पुन्हा रन करू शकतो का?
- काम सुरू असताना एखादा माणूस ते ताब्यात घेऊ शकतो का?
सिनियर इंजिनिअर्सनी पेमेंट आणि बॅकग्राउंड जॉब्समध्ये ही समस्या अनेक वर्षांपूर्वीच सोडवली होती. आम्ही आयडेम्पोटन्सी कीज (idempotency keys), चेकपॉइंट्स (checkpoints) आणि ट्रान्झॅक्शन लॉग्सचा (transaction logs) वापर केला होता. AI ने या समस्या शोधल्या नाहीत; त्याने फक्त त्या अधिक वेगाने घडवून आणल्या आहेत.
तुमच्या एक्झिक्यूशन कॉन्ट्रॅक्टची (execution contract) निवड करण्यापूर्वी मॉडेल निवडू नका. हे ब्रेक नसलेल्या कारसाठी रेसिंग इंजिन निवडण्यासारखे आहे.
या स्टेप्स वापरून एक विश्वसनीय वर्कफ्लो तयार करा:
AI चे काम लहान स्टेप्समध्ये विभागून घ्या एक मोठा प्रॉम्प्ट वापरू नका. त्याचे विभाजन करा: कॉन्टेक्स्ट गोळा करणे, बदलाचा प्रस्ताव मांडणे, तपासणी करणे, मंजुरी मागणे आणि बदल लागू करणे.
ड्युरेबल स्टोरेज (durable storage) वापरा स्टेटस, स्टेप्स आणि प्रयत्नांची संख्या ट्रॅक करण्यासाठी डेटाबेस वापरा. जर एखादा वर्कर क्रॅश झाला, तर तुम्ही मेमरीऐवजी 'स्टेट' (state) मधून रिकव्हरी करू शकता.
आयडेम्पोटन्सी (idempotency) लागू करा डेटा बदलणाऱ्या प्रत्येक कृतीसाठी एक स्थिर की (stable key) आवश्यक आहे. जर एखादी स्टेप दोनदा रन झाली, तर निकाल तोच राहिला पाहिजे.
टियर्स (tiers) वापरून परवानग्या व्यवस्थापित करा सतत मंजुरी मागणे थांबवा. खालीलप्रमाणे टियर्स तयार करा:
- टियर 0: फक्त वाचण्यासाठीची कामे (स्वयंचलित मंजुरी).
- टियर 1: कमी जोखमीचे राइट्स (बॅचमध्ये मंजुरी).
- टियर 2: उच्च-प्रभाव असलेली कामे (मानवी चेकपॉइंट).
- ऑपरेशनल मेट्रिक्स (operational metrics) ट्रॅक करा फक्त लेटन्सी (latency) आणि खर्चाकडे पाहणे थांबवा. टाइमआउट रेट्स, रिट्राय सक्सेस आणि रोलबॅक फ्रिक्वेन्सी ट्रॅक करा.
सर्वोत्तम AI टीम्स 'मॅजिक प्रॉम्प्ट्स'बद्दल बढाई मारणार नाहीत. त्या कंटाळवाणे, ड्युरेबल आणि ऑब्झर्व्हेबल (observable) पाईपलाईन्स चालवतील. त्यांचा फायदा मॉडेलमध्ये नसून शिस्तबद्ध सिस्टम्स इंजिनिअरिंगमध्ये (systems engineering) आहे.
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-29l4
Optional learning community: https://t.me/GyaanSetuAi