मी एकदा एका AI ला ब्रँड वेबसाइट बनवायला सांगितली. पहिल्या नजरेत ती पटण्यासारखी वाटली, पण प्रत्यक्षात ती महत्त्वाच्या बाबतीत पूर्णपणे बिघडलेली होती. हेडरमध्ये फक्त दोनच लिंक्स दिसत होत्या. कुठेही "About" पेज नव्हते. बॅकएंडला एक ॲडमिन पॅनेल अस्तित्वात होते, तरीही फ्रंटएंडवर असा कोणताही बटण किंवा रूट नव्हता ज्याद्वारे तिथे पोहोचता येईल. सर्व्हर साईड व्यवस्थित चालत होते, पण युजर साईड नाही.
जेव्हा लोक अशा परिस्थितीचा सामना करतात, तेव्हा त्यांना वाटते की AI आळशी झाले आहे किंवा टोकन लिमिट संपली आहे. पण तसे घडत नाहीये. ही समस्या स्ट्रक्चरल (संरचनात्मक) आहे. AI कोडिंग टूल्स अंतर्गत सुसंगतता (internal consistency) तपासण्यासाठी बनवलेली असतात. ती विचारतात: "मी जे काही घोषित केले आहे ते एकमेकांशी जुळते का?" पण ती हे विचारत नाहीत की: "या प्रकारच्या डिलिव्हरेबलमध्ये (deliverable) सर्व आवश्यक गोष्टी आहेत का?" जर तुम्ही तुमच्या ब्रँड साइटसाठी दोन पेजेसचा उल्लेख केला, तर मॉडेल फक्त हे तपासते की ती दोन पेजेस एकमेकांशी लिंक आहेत की नाही. एकदा लिंक्स जोडल्या गेल्या की, ते काम पूर्ण झाले असे मानते. ब्रँड साइटला 'About' पेज, ट्रस्ट सिग्नल्स किंवा कॉन्टॅक्ट पाथची आवश्यकता असते, याची त्याला उपजत कल्पना नसते. त्याच्या डोक्यात कोणताही मानक (standard) नसतो.
मी या उपायाला Completeness Baseline असे म्हणतो.
'Completeness baseline' म्हणजे एखाद्या डिलिव्हरेबलमध्ये नेमक्या कोणत्या गोष्टी असणे आवश्यक आहेत, याची एक मानक चेकलिस्ट. तुम्ही आर्टिफॅक्ट (artifact) तयार करता आणि त्यानंतर, टूलच्या "काम झाले" या अंतर्गत भावनेवर विश्वास ठेवण्याऐवजी, या बाह्य मानकाचा वापर करून प्रत्यक्ष आउटपुट तपासता.
तीन स्तरांवर तपासणी करणे
सर्व गहाळ गोष्टी तितक्याच स्पष्ट नसतात. एक उपयुक्त बेसलाईन तीन वेगळ्या स्तरांची तपासणी करते.
Existence (अस्तित्व). तो भाग खरोखर अस्तित्वात आहे का? हे ऐकायला साधे वाटते, पण AI आनंदाने असा नेव्हिगेशन रॅपर (navigation wrapper) तयार करेल जो डॅशबोर्ड पेजचा संदर्भ देतो, पण स्वतः डॅशबोर्ड पेज कधीच तयार करत नाही. संदर्भ अस्तित्वात असतो, पण लक्ष्य (target) नसते.
Reachability (पोहोचण्यायोग्यता). एखादा वास्तविक वापरकर्ता खरोखर तिथे पोहोचू शकतो का? लपवलेले ॲडमिन पॅनेल्स हे याचे क्लासिक उदाहरण आहे. रूट आणि कंपोनंट दोन्ही कोडबेसमध्ये असू शकतात, तरीही इंटरफेसवर कोणताही मेनू आयटम, बटण किंवा रिडायरेक्ट त्यांना समोर आणत नाही. जर वापरकर्त्याला सामान्य वापरादरम्यान ते सहज सापडत नसेल, तर ते खरोखर तिथे नाही असे समजावे.
Substantiation (पुष्टीकरण). पृष्ठभागाच्या मागे वास्तविक डेटा किंवा संरचना आहे का? असे पेज जे लोड होते पण त्यात फक्त प्लेसहोल्डर मजकूर आहे आणि इमेज अपलोड करण्यासाठी जागा नाही, ते केवळ एक पोकळ सांगाडा आहे. इमेज स्लॉट किंवा एडिट करण्यायोग्य मजकूर फील्ड नसलेले 'About' पेज पूर्ण मानले जाऊ शकत नाही, जरी त्याचे HTML व्यवस्थित रेंडर होत असले तरीही.
हे तीन स्तर विविध प्रकारच्या त्रुटी शोधून काढतात. 'Existence' गहाळ झालेला जोडा शोधते. 'Reachability' कपाटात बंद असलेला जोडा शोधते. 'Substantiation' तळ नसलेला जोडा शोधते.
प्रकारानुसार बेसलाईन्स
एकच बेसलाईन प्रत्येक प्रकल्पासाठी लागू पडणार नाही. तुम्हाला तुम्ही काय बनवत आहात याचे वर्गीकरण करावे लागेल आणि त्या श्रेणीसाठी कोणत्या गोष्टी अनिवार्य आहेत ते ठरवावे लागेल.
Brand sites साठी विशिष्ट विभाग आणि पोहोचण्यायोग्य पेजेसची आवश्यकता असते. यामध्ये About, Contact, प्रायव्हसी लिंक्स आणि नेव्हिगेशनचा विचार करा, जे खरोखरच प्रत्येक महत्त्वाचा व्ह्यू (view) समोर आणतील.
APIs साठी डॉक्युमेंटेशन, सर्वसमावेशक एरर कोड्स (error codes) आणि रेट लिमिट्सची (rate limits) आवश्यकता असते. एक कार्यरत एंडपॉइंट जो यशासाठी 200 OK आणि इतर सर्व गोष्टींसाठी सामान्य 500 एरर देतो, तो पूर्ण झालेला API नाही. तो एक धोका आहे.
Automations साठी लॉग्स (logs) आणि फेल्युअर अलर्ट्सची (failure alerts) आवश्यकता असते. जर एखादी वर्कफ्लो रात्री २ वाजता बिघडली आणि मानवाने रन हिस्ट्री तपासल्याशिवाय कोणालाही त्याची कल्पना आली नाही, तर ती ऑटोमेशन अपूर्ण आहे. ऑब्झर्व्हेबिलिटी (Observability) ही एखादी अतिरिक्त सुविधा नाही, तर ती डिलिव्हरेबलचाच एक भाग आहे.
एकदा तुम्ही श्रेणी ठरवली की, बेसलाईन आपोआप तयार होते. कठीण भाग म्हणजे कोड तयार झाल्यानंतर त्याची अंमलबजावणी करणे.
टिकून राहणारे डिझाइन नियम
मी माझ्या स्वतःच्या वर्कफ्लोला याच कल्पनेभोवती पुन्हा तयार केले आणि तीन व्यावहारिक नियम ठरवले, ज्यामुळे प्रकल्प हळूहळू विस्कळीत होण्यापासून वाचतात.
Capability-gated design (क्षमता-आधारित डिझाइन). एखाद्या टूलला किंवा जनरेट केलेल्या मॉड्यूलला पूर्णपणे स्वीकारण्यापूर्वी, ते प्रत्यक्षात काय करू शकते हे तपासा. जर एखाद्या कंपोनंट लायब्ररीमध्ये नेटिव्ह मोबाईल ड्रॉवर सपोर्ट नसेल, तर AI ला असा पूर्ण नेव्हिगेशन स्कीम तयार करू देऊ नका ज्यामध्ये तो सपोर्ट आहे असे गृहीत धरले आहे. एखादी क्षमता उपलब्ध नसल्यास सिस्टम पूर्णपणे तुटण्याऐवजी, ती व्यवस्थितपणे (gracefully) काम करणे थांबवली पाहिजे. आधी मर्यादा जाणून घ्या. त्या मर्यादेच्या आत डिझाइन करा.
Public engine, private values (सार्वजनिक इंजिन, खाजगी मूल्ये). जड कामांसाठी (heavy lifting) पब्लिक इंजिन वापरा, परंतु तुमचे खाजगी डेटा, कॉन्फिग्स आणि कन्व्हेन्शन्स (conventions) रनटाइमला इंजेक्ट करा. यामुळे तुमची वैयक्तिक किंवा कंपनीची पद्धत सुरक्षित राहते आणि जनरेट केलेल्या साचापासून (scaffold) वेगळी राहते. AI फक्त साचा तयार करते. तुम्ही त्यात काच बसवता. यामुळे मॉडेल अशा गृहितकांचे हार्ड-कोडिंग करत नाही जे तुमच्या वास्तविक मानदांचे उल्लंघन करतात किंवा संवेदनशील पॅटर्न सार्वजनिक ट्रेनिंग संदर्भात लीक करतात.
प्रस्ताव द्या, आपोआप पुढे जाऊ नका. AI ला पुढची पायरी सुचवू द्या, पण निवड करण्यासाठी माणसाला भाग पाडा. अंमलबजावणीचा प्रवाह स्वयंचलित करा, पण निर्णय प्रक्रिया कधीही नाही. जेव्हा एखादे मॉडेल एकाच वेळी डेटाबेस मायग्रेशन, ऑथ स्कीम आणि पेमेंट हुक स्वयंचलितपणे तयार करते, तेव्हा तुम्हाला देखरेखीच्या किंमतीवर सोय मिळते. साधनाला योजना सादर करू द्या. डेव्हलपरला बटण दाबू द्या.
कामासाठी योग्य मॉडेल निवडणे
मी विविध मॉडेल्सवर याची चाचणी घेतली आणि मूल्यामध्ये स्पष्ट फरक आढळला. स्वस्त मॉडेल्स यांत्रिक कामे आश्चर्यकारकपणे चांगल्या प्रकारे हाताळतात. तुम्ही टाईप करण्याच्या वेगापेक्षाही वेगाने ते बॉयलरप्लेट (boilerplate), पुनरावृत्ती होणारे घटक आणि स्ट्रक्चरल स्टब्स तयार करतात. महागडी मॉडेल्स तेव्हाच त्यांच्या किमतीची सार्थकता सिद्ध करतात जेव्हा ते संयम दाखवतात. जेव्हा एखादे मॉडेल बनावट उपाय शोधण्यास नकार देते आणि त्याऐवजी खऱ्या त्रुटीकडे लक्ष वेधते, तेव्हा तुम्हाला प्रीमियम पर्यायाची गरज असते. एखादे मॉडेल जे गहाळ API एंडपॉइंटसाठी चुकीचा उपाय (hallucinate) सुचवते, ते धोकादायक आहे. एखादे मॉडेल जे थांबते आणि म्हणते, "या वर्कफ्लोसाठी वेबहुक टार्गेट आवश्यक आहे जे परिभाषित केलेले नाही," ते खरोखरच किमतीला पात्र आहे. केवळ प्रमाणासाठी नाही, तर विवेकबुद्धीसाठी पैसे द्या.
सिस्टिम्स तयार करा, जादूच्या मागे लागू नका
मोठी मॉडेल्स किंवा अधिक प्रॉम्प्टिंग ट्रिक्स वापरून AI मधील त्रुटी सुधारण्याचा प्रयत्न करू नका. त्या एका बेसलाईनने सुधारा. ही त्रुटी क्षमतेची समस्या नाही, तर ती अपेक्षांची समस्या आहे.
गहाळ ब्लॉक्स रोखण्यासाठी, तीन गोष्टी करा.
कोणताही कोड लिहिण्यापूर्वी सिस्टमला पूर्णतेची एक बेसलाईन द्या. ती कामाच्या जवळ असलेली एक प्रत्यक्ष चेकलिस्ट बनवा.
तुमचे नियम (conventions) पुन्हा वापरण्यायोग्य भागांमध्ये समाविष्ट करा. जर तुम्ही टेम्प्लेट्स, लिंट रूल्स (lint rules) किंवा प्री-बिल्ट स्कॅफोल्ड्सद्वारे तुमची बेसलाईन लागू केली, तर AI तुमच्या मानकामाचा अंदाज लावण्याची आशा करण्याऐवजी अचूकतेच्या स्थितीपासून सुरुवात करते.
निर्णय घेण्याचे नियंत्रण मानवाकडे ठेवून प्रवाह स्वयंचलित करा. यंत्रांना पुनरावृत्तीची कामे करू द्या. निर्णय घेण्याचे काम संदर्भाची समज असलेल्या लोकांसाठी राखून ठेवा.
माझ्या कामाची पद्धत बदलणारी ही एक शेवटची सवय आहे. जर तुम्ही सात वेळा एकच डिझाइन निर्णय घेत असाल, तर त्याला केवळ एक तात्पुरता निर्णय मानणे थांबवा. ती पुनरावृत्ती नाही, तो एक नियम आहे. त्याला नाव द्या. त्याचे रूपांतर नियमात करा. त्याचे दस्तऐवजीकरण करा. जेव्हा तुम्ही त्या पॅटर्नचे संहिताबद्धीकरण (codify) करता, तेव्हा आठव्या वेळी AI त्यापासून विचलित होण्याची शक्यता तुम्ही कमी करता.
या फ्रेमवर्कचा स्रोत आणि मूळ शोध येथे मिळू शकतो.
जर तुम्हाला समान समस्यांवर काम करणाऱ्या इतरांशी चर्चा करायची असेल, तर तुम्ही GyaanSetu learning community मध्ये सामील होऊ शकता.