जब आप पहली बार आर्टिफिशियल इंटेलिजेंस (AI) के साथ काम करना शुरू करते हैं, तो सबसे तेज़ आवाज़ें एक ही चीज़ की ओर इशारा करती हैं: मॉडल। वे कहते हैं कि सही मॉडल चुनें, और बाकी सब अपने आप ठीक हो जाएगा। अपने स्वयं के प्रयोगों के कुछ हफ्तों बाद, मैं आपको बता सकता हूँ कि यह सच नहीं है। उपलब्ध लार्ज लैंग्वेज मॉडल्स (LLMs) के बीच चुनाव करना मायने रखता है, लेकिन यह शायद काम का केवल बीस प्रतिशत है। बाकी सब सिस्टम का काम है। यह प्लंबिंग, शिल्प और निरंतर परीक्षण है। यह अहसास मुझे जल्दी हो गया, और इसने तब से मेरे हर प्रोजेक्ट के प्रति दृष्टिकोण को बदल दिया है।
मॉडल तो बस शुरुआत है
यह समझना आसान है कि शुरुआती लोग मॉडल्स को लेकर इतने जुनूनी क्यों होते हैं। रिलीज़ नोट्स बेहतर तर्क (reasoning), बड़े कॉन्टेक्स्ट विंडो और साफ़ आउटपुट का वादा करते हैं। वे सुधार वास्तविक हैं, लेकिन वे सामान्य उद्देश्य (general-purpose) के लिए हैं। एक अत्याधुनिक (state-of-the-art) मॉडल स्वचालित रूप से आपकी कंपनी की रिफंड पॉलिसी नहीं जान पाएगा। जब तक आप उसे न बताएं, वह आपके मोबाइल ऐप के लिए भरोसेमंद तरीके से रिस्पॉन्स फॉर्मेट नहीं करेगा। वह शून्य से लाइव इन्वेंट्री डेटा नहीं निकाल सकता।
मैंने यह सबक कठिन तरीके से सीखा। मेरे पहले प्रोटोटाइप ने एक सक्षम मॉडल का उपयोग किया और सुंदर, आत्मविश्वास से भरे पैराग्राफ तैयार किए जो कभी-कभी पूरी तरह से गलत होते थे। टेक्स्ट पेशेवर लगता था क्योंकि मॉडल ने टोन (tone) में महारत हासिल कर ली थी, लेकिन उसके पास वर्तमान जानकारी तक पहुंच नहीं थी। मैंने मॉडल बेंचमार्क की तुलना करने में कई दिन बिता दिए थे, जबकि मुझे डेटा पाइपलाइन और कॉन्टेक्स्ट इंजेक्शन (context injection) के बारे में सोचना चाहिए था। मॉडल खराब नहीं था। उसके आसपास का सिस्टम अधूरा था। जब आप डेमो से ऐसे सॉफ्टवेयर की ओर बढ़ते हैं जिस पर लोग वास्तव में भरोसा करते हैं, तो यही अंतर सब कुछ होता है।
प्रॉम्प्ट्स कोड हैं, सुझाव नहीं
किसी भी भरोसेमंद AI एप्लिकेशन के केंद्र में उच्च गुणवत्ता वाले प्रॉम्प्ट्स (prompts) होते हैं। शुरुआत में, मैंने प्रॉम्प्ट्स को सर्च क्वेरी की तरह माना—छोटे, अनौपचारिक और आशावादी। मैं मॉडल से "इसे सारांशित करें" या "मददगार बनें" जैसा कुछ कहता और सबसे अच्छे परिणाम की उम्मीद करता। परिणाम उपयोगी और अप्रासंगिक के बीच बहुत अधिक उतार-चढ़ाव करते थे, और मुझे पता ही नहीं था कि ऐसा क्यों हो रहा है।
अब मैं प्रॉम्प्ट्स को हल्के प्रोग्राम (lightweight programs) की तरह मानता हूँ। एक अच्छा प्रॉम्प्ट भूमिका (role) को परिभाषित करता है, आउटपुट फॉर्मेट निर्दिष्ट करता है, आवश्यकतानुसार उदाहरण शामिल करता है और सीमाएं तय करता है। यदि मुझे JSON चाहिए, तो मैं JSON मांगता हूँ और स्कीमा (schema) दिखाता हूँ। यदि मुझे संक्षिप्त उत्तर चाहिए, तो मैं स्पष्ट रूप से लंबाई को सीमित कर देता हूँ और प्रस्तावना (preamble) पर रोक लगा देता हूँ। बार-बार सुधार (iteration) करना महत्वपूर्ण है। मैं प्रॉम्प्ट्स और उनके आउटपुट का एक लॉग रखता हूँ, और एक बार में केवल एक वेरिएबल बदलता हूँ। प्रॉम्प्ट में एक अकेला अस्पष्ट विशेषण पूरे वर्कफ़्लो के व्यवहार को बदल सकता है। यह संवेदनशीलता कठोरता की मांग करती है, अनुमान की नहीं।
कचरा अंदर, कचरा बाहर (Garbage In, Garbage Out)
विश्वसनीय डेटा रिट्रीवल (data retrieval) वह जगह है जहाँ कई AI प्रोजेक्ट्स चुपचाप दम तोड़ देते हैं। मॉडल्स को निजी या वर्तमान डेटा तक पहुंच देने के लिए रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) एक मानक पैटर्न बन गया है। विचार सीधा है: प्रासंगिक दस्तावेज़ प्राप्त करें, उन्हें मॉडल के कॉन्टेक्स्ट विंडो में डालें, और मॉडल को तथ्यों पर तर्क करने दें। लेकिन इसका अभ्यास काफी पेचीदा है।
मैंने एक साधारण नॉलेज बेस को डीबग करने में काफी समय बिताया जो बार-बार असंबंधित परिणाम दे रहा था। मॉडल ठीक था। रिट्रीवल लेयर विफल हो रही थी। मेरे चंक्स (chunks) बहुत छोटे थे और उनमें कॉन्टेक्स्ट की कमी थी। मेरे एम्बेडिंग्स (embeddings) डुप्लिकेट हेडर को साफ किए बिना ही जेनरेट किए गए थे। सिमिलरिटी सर्च ने तकनीकी रूप से करीब वाला टेक्स्ट ढूंढ लिया जो गलत सवाल का जवाब दे रहा था। इसे ठीक करने का मतलब था चंकिंग रणनीति (chunking strategy) पर पुनर्विचार करना, मेटाडेटा फ़िल्टर जोड़ना और री-रैंकिंग स्टेप पेश करना। एक बार जब रिट्रीवल स्थिर हो गया, तो मॉडल के जवाब तुरंत बेहतर हो गए। सबक स्पष्ट था: आप बेहतर मॉडल के साथ खराब डेटा रिट्रीवल को ठीक नहीं कर सकते। आपको पाइपलाइन को सही ढंग से बनाना होगा।
आप उसे बेहतर नहीं बना सकते जिसे आप मापते नहीं हैं
निरंतर मूल्यांकन (evaluation) वह आदत है जो प्रयोगों को उत्पादों से अलग करती है। जब मैंने शुरुआत की थी, तो मैं केवल 'वाइब' (vibe) के आधार पर मूल्यांकन करता था। मैं पाँच आउटपुट पढ़ता, सहमति में सिर हिलाता और आगे बढ़ जाता। यह तब तक काम करता है जब तक कोई उपयोगकर्ता छठा सवाल नहीं पूछता और उसे कुछ अजीब मिलता है।
अब मैं हर फीचर के लिए छोटे मूल्यांकन सेट (evaluation sets) बनाता हूँ। मैं वास्तविक उपयोगकर्ता क्वेरी एकत्र करता हूँ, अपेक्षित व्यवहार को लेबल करता हूँ, और उनके विरुद्ध स्वचालित जाँच (automated checks) चलाता हूँ। मैं 'ड्रिफ्ट' (drift) पर नज़र रखता हूँ: एक प्रॉम्प्ट जो पिछले महीने काम कर रहा था, वह मॉडल अपडेट के बाद या बुनियादी डेटा बदलने के बाद खराब हो सकता है। मैं स्टाइल मूल्यांकन को तथ्यात्मक सटीकता से अलग रखता हूँ। पेशेवर दिखना अच्छा है; सही होना अनिवार्य है। इस लूप के बिना, आप केवल उम्मीद के भरोसे चीज़ें रिलीज़ कर रहे हैं, और उम्मीद कोई टेस्टिंग रणनीति नहीं है।
मशीन की सीमाओं को जानें
मॉडल की सीमाओं को समझने से मुझे ज़रूरत से ज़्यादा वादे करने और कम परिणाम देने से बचने में मदद मिली है। इन प्रणालियों की वास्तविक सीमाएँ होती हैं। कॉन्टेक्स्ट विंडो (Context windows) पहले की तुलना में बड़ी हो गई हैं, लेकिन उनकी भी एक सीमा है, और उन्हें पूरी तरह भरने से प्रदर्शन (performance) कम हो जाता है। मॉडल hallucinate करते हैं, विशेष रूप से उन विशिष्ट विषयों पर जहाँ ट्रेनिंग डेटा कम होता है। उन्हें सटीक अंकगणित और कुछ प्रकार के मल्टी-स्टेप लॉजिक (multi-step logic) में कठिनाई होती है। वे शब्दों के चयन (phrasing) के प्रति संवेदनशील होते हैं।
लागत और गति भी सीमाएँ हैं। एक मॉडल जो दस सेकंड में बेहतरीन गद्य (prose) तैयार करता है, वह रियल-टाइम चैट इंटरफ़ेस में अनुपयोगी हो सकता है। अब मैं शुरुआत में ही फीचर्स को लेटेंसी बजट (latency budgets) के साथ मैप करता हूँ। यदि किसी कार्य के लिए सब-सेकंड रिस्पॉन्स की आवश्यकता है, तो मैं उत्तरों को पहले से कंप्यूट (precompute) कर सकता हूँ, आक्रामक रूप से कैश (cache) कर सकता हूँ, या पहले ड्राफ्ट के लिए एक छोटे मॉडल और केवल सुधार (refinement) के लिए एक बड़े मॉडल का उपयोग कर सकता हूँ। सीमाओं के भीतर काम करना मानक इंजीनियरिंग है। AI भी इससे अलग नहीं है।
वास्तविक लोगों के लिए निर्माण
मैं वर्तमान में एक सरल लक्ष्य के साथ LLM एप्लिकेशन और सॉफ्टवेयर इंजीनियरिंग का अध्ययन कर रहा हूँ: ऐसे उपकरण बनाना जिनका लोग रोज़ाना उपयोग करें। यह सुनने में स्पष्ट लगता है, लेकिन एक शानदार प्रोटोटाइप और रोज़ाना इस्तेमाल होने वाले टूल के बीच का अंतर बहुत बड़ा है। एक डेमो में चालीस सेकंड का ठहराव और विस्तारपूर्ण उत्तर सहन किया जा सकता है। लेकिन मीटिंग से पहले काम पूरा करने की कोशिश कर रहे व्यक्ति के लिए यह संभव नहीं है।
रोज़ाना इस्तेमाल होने वाले टूल्स को एरर हैंडलिंग (error handling), फॉलबैक (fallbacks) और मॉडल के अनिश्चित होने पर स्पष्ट UI की आवश्यकता होती है। उन्हें नए वर्कफ़्लो थोपने के बजाय मौजूदा वर्कफ़्लो के साथ एकीकृत (integrate) होने की आवश्यकता है। अब मैं एज केस (edge cases) के बारे में सोचता हूँ: क्या होता है जब मॉडल उत्तर देने से मना कर देता है, जब कॉन्टेक्स्ट ओवरफ्लो हो जाता है, या जब API टाइम आउट हो जाता है? AI सॉफ्टवेयर लॉन्च करने का मतलब केवल आशावाद नहीं, बल्कि कोड के माध्यम से उन सवालों के जवाब देना है।
आइए जो हम सीखते हैं उसे साझा करें
मैं अन्य डेवलपर्स के साथ जुड़ना चाहता हूँ जो इसी रास्ते पर चल रहे हैं। यह क्षेत्र तेज़ी से बदल रहा है, और सर्वोत्तम प्रथाएँ (best practices) अभी भी लिखी जा रही हैं। किसी के पास भी सभी उत्तर नहीं हैं। चाहे आप प्रॉम्प्ट डिज़ाइन (prompt design) के साथ जूझ रहे हों, रिट्रीवल पाइपलाइन्स (retrieval pipelines) से लड़ रहे हों, या बड़े पैमाने पर आउटपुट का मूल्यांकन (evaluate outputs) कैसे किया जाए यह समझने की कोशिश कर रहे हों, समस्याओं को मिलकर बेहतर ढंग से हल किया जा सकता है।
आइए हम जो सीखते हैं उसे साझा करें। पॉलिश की हुई कॉन्फ्रेंस टॉक नहीं, बल्कि वह उलझा हुआ मध्य भाग (messy middle)। टूटी हुई पाइपलाइन्स, प्रॉम्प्ट में किए गए वे बदलाव जो अंततः काम कर गए, वे मूल्यांकन परीक्षण जिन्होंने लॉन्च से पहले बग को पकड़ लिया। वह सूक्ष्म और ईमानदार आदान-प्रदान ही व्यक्तिगत प्रयोगों को ज्ञान के साझा भंडार में बदल देता है।
असली निष्कर्ष
यदि आप AI डेवलपमेंट की शुरुआत कर रहे हैं, तो खोजने में कम समय बिताएं...