रग. रग. रग. व्यावसायिक प्रक्रियाओं और उत्पादों में कृत्रिम बुद्धिमत्ता को लागू करने की दौड़ में, एक परेशान करने वाली प्रवृत्ति रही है: रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) के प्रति जुनून। जबकि RAG - एक ऐसी विधि जो बाहरी ज्ञान पुनर्प्राप्ति के साथ बड़े भाषा मॉडल (LLM) को मिश्रित करती है - ने निस्संदेह ज्ञान के साथ बातचीत करने के लिए नए रास्ते खोले हैं, बहुत से व्यवसायी इसके साथ संघर्ष कर रहे हैं। अब समय आ गया है कि हम एआई कार्यान्वयन के बारे में बातचीत को नए सिरे से शुरू करें, आरएजी पर अत्यधिक निर्भरता के नुकसान को स्वीकार करें, तथा वैकल्पिक तरीकों को खोजें जो अधिक उपयुक्त, लागत प्रभावी और सुंदर हो सकते हैं। RAG उन्माद: कई उपयोग मामलों के लिए अतिशयोक्ति RAG कई AI इंजीनियरों के लिए एक पसंदीदा तकनीक बन गई है जो बाहरी संदर्भ प्रदान करके भाषा मॉडल की सटीकता में सुधार करना चाहते हैं। आधार काफी सरल है: वेक्टर स्टोर में बड़ी मात्रा में टेक्स्ट अपलोड करके, ये AI सिस्टम प्रासंगिक दस्तावेज़ों को देख सकते हैं, डेटा को पुनः प्राप्त कर सकते हैं, और इसे भाषा मॉडल की जनरेटिव क्षमताओं के साथ जोड़कर अधिक सटीक उत्तर दे सकते हैं। हालांकि, RAG के प्रति उत्साह ने ऐसे कार्यान्वयनों की बाढ़ ला दी है जो इसकी उपयोगिता को बढ़ा-चढ़ाकर आंकते हैं। यह देखना असामान्य नहीं है कि इंजीनियर लाखों दस्तावेज़ों को वेक्टर स्टोर में डाल देते हैं, जिससे क्लाउड स्टोरेज और प्रोसेसिंग लागत बढ़ जाती है, बिना यह समझे कि उपयोग के मामले में ऐसी जटिलता की आवश्यकता है भी या नहीं। कई लोग यह विचार करने में विफल रहते हैं कि क्या कोई सरल समाधान पर्याप्त हो सकता है या क्या RAG उनकी विशिष्ट समस्या के लिए आवश्यक भी है। सरल RAG कार्यान्वयन के नुकसान इससे भी बुरी बात यह है कि अधिकांश इंजीनियर RAG कार्यान्वयन को एक भोली मानसिकता के साथ देखते हैं, जो दीर्घकालिक लागतों और रखरखाव के बोझ को अनदेखा करते हैं। उनका मानना है कि हर टेक्स्ट को वेक्टर स्टोर में अपलोड करने से किसी तरह AI अधिक स्मार्ट बन जाएगा। लेकिन अक्सर ऐसा होता है कि यह अभ्यास इसके विपरीत होता है। वेक्टर स्टोर में अनावश्यक और अनावश्यक दस्तावेजों की भरमार होने के कारण, LLM ऐसे डेटा को पुनः प्राप्त करने में व्यस्त हो जाते हैं जो मूल्य नहीं जोड़ता। इसके परिणामस्वरूप धीमी प्रतिक्रिया समय, उच्च लागत और कम प्रभावी समाधान होते हैं। RAG तब सबसे अच्छा काम करता है जब इसका उपयोग और ज्ञान को बढ़ाने के लिए किया जाता है, न कि तब जब इसे किसी भी उपलब्ध दस्तावेज़ डंप के लिए कैच-ऑल के रूप में नियोजित किया जाता है। RAG के माध्यम से ओवरइंजीनियरिंग से अन्य प्रमुख AI क्षमताओं का कम उपयोग होता है और पुनर्प्राप्ति पर अत्यधिक ध्यान केंद्रित होता है, जबकि कई समस्याओं को सरल तर्क और संरचना के साथ हल किया जा सकता है। सटीक प्रासंगिक हर समस्या को RAG की जरूरत नहीं होती सच्चाई यह है: सभी उपयोग मामलों में RAG सेटअप की आवश्यकता नहीं होती है। यदि कार्य संकीर्ण और अच्छी तरह से परिभाषित है - जैसे FAQ, ग्राहक सहायता प्रश्नों का उत्तर देना, या संरचित संवाद में शामिल होना - तो एक साधारण लुकअप टेबल या ज्ञान ग्राफ़ पर्याप्त हो सकता है। जब समाधान को नियम-आधारित सिस्टम या यहां तक कि एजेंट फ्रेमवर्क का उपयोग करके बनाया जा सकता है, तो एक विशाल वेक्टर स्टोर और मल्टी-मिलियन पैरामीटर मॉडल चलाने के ओवरहेड को वहन करने की कोई आवश्यकता नहीं है। RAG का उपयोग करने का उत्साह इस विचार से उपजा है कि अधिक डेटा का मतलब बेहतर प्रदर्शन है। लेकिन कई मामलों में, गुणवत्ता मात्रा से अधिक महत्वपूर्ण है। लक्षित ज्ञान के साथ एक सुव्यवस्थित मॉडल, या यहां तक कि नियम-आधारित क्षमताओं के साथ एक ज्ञान-जागरूक चैटबॉट, RAG पाइपलाइन को छुए बिना बेहतर प्रदर्शन कर सकता है। RAG को लागू करने का निर्णय कार्य की जटिलता के आधार पर तय किया जाना चाहिए, न कि AI उत्साही लोगों के बीच इसकी लोकप्रियता के आधार पर। सीमित ज्ञान वाले छोटे एजेंटों का मामला फूले हुए RAG सिस्टम का विकल्प अक्सर अधिक सुंदर और प्रभावी होता है: सीमित लेकिन सटीक ज्ञान वाले छोटे, विशेष एजेंट। जब इन एजेंटों का एक साथ उपयोग किया जाता है, तो वे टेराबाइट्स टेक्स्ट से लदे एक बड़े मॉडल से बेहतर प्रदर्शन कर सकते हैं। प्रत्येक एजेंट को वर्कफ़्लो के विशिष्ट भागों को संभालने या कुछ प्रकार के प्रश्नों का जवाब देने के लिए डिज़ाइन किया जा सकता है, जिससे मॉड्यूलर और लचीले AI सिस्टम की अनुमति मिलती है। इससे न केवल लागत कम होती है बल्कि पूरे सिस्टम को बनाए रखना और स्केल करना भी आसान हो जाता है। एक परिदृश्य की कल्पना करें जहां एक एजेंट शेड्यूलिंग के लिए जिम्मेदार है, दूसरा सारांश के लिए, और तीसरा वेब खोज करने के लिए। इनमें से प्रत्येक एजेंट एक साथ काम कर सकता है, केवल उस ज्ञान का लाभ उठा सकता है जिसकी उन्हें आवश्यकता है, बिना किसी मोनोलिथिक सिस्टम के ओवरहेड के। कई छोटे मॉडल या तर्क-आधारित एजेंटों को तैनात करके, व्यवसाय प्रसंस्करण और भंडारण लागतों में काफी कटौती करते हुए अधिक सटीक और तेज़ आउटपुट प्राप्त कर सकते हैं। एलएलएम का अति प्रयोग: जब सरल तर्क ही काम आएगा अंत में, ऐसे परिदृश्यों में LLM का अत्यधिक उपयोग होता है जहाँ सरल तर्क काम कर सकता है। LLM प्राकृतिक भाषा को समझने और उत्पन्न करने में उल्लेखनीय रूप से अच्छे हैं, लेकिन इसका मतलब यह नहीं है कि उन्हें स्वचालन के सभी रूपों को प्रतिस्थापित करना चाहिए। कई कार्य - जैसे डेटा सत्यापन, फ़ॉर्म भरना, या संरचित रिपोर्ट जनरेशन - बुनियादी स्क्रिप्ट, नियम इंजन या नियतात्मक प्रणालियों के साथ तेज़ी से और अधिक विश्वसनीय रूप से किए जा सकते हैं। इसका एक प्रमुख उदाहरण अंकगणितीय कार्य या सॉर्टिंग समस्या के लिए LLM का उपयोग करना है। यह अक्षम और अनावश्यक है। यह न केवल कम्प्यूटेशनल संसाधनों को बर्बाद करता है, बल्कि उन मामलों में त्रुटियों की संभावना भी बढ़ाता है जहां एक सरल फ़ंक्शन या एल्गोरिदम अधिक सटीक होगा। हर चीज के लिए LLM को लागू करने की उत्सुकता "LLM हथौड़ा कील की तलाश में" सिंड्रोम में बदल गई है। इस दुरुपयोग से उम्मीदें बढ़ जाती हैं और अंततः निराशा होती है जब मॉडल उन कार्यों में अपेक्षित प्रदर्शन नहीं करते हैं जिन्हें संभालने के लिए उन्हें डिज़ाइन नहीं किया गया था। एआई इंजीनियरिंग पर पुनर्विचार अब समय आ गया है कि हम AI इंजीनियरिंग पर पुनर्विचार करें और सनक से आगे बढ़ें। टूलकिट में RAG का अपना स्थान है, लेकिन यह रामबाण नहीं है। भविष्य सही कार्यों के लिए सही मॉडल तैनात करने में निहित है - कभी-कभी इसका मतलब RAG होता है, लेकिन अक्सर ऐसा नहीं होता। AI क्षमताओं की सूक्ष्म समझ के साथ, इंजीनियर ऐसी प्रणालियाँ डिज़ाइन कर सकते हैं जो अधिक प्रभावी, कुशल और रखरखाव में आसान हों। मेरे बारे में: डेटा, एआई, जोखिम प्रबंधन, रणनीति और शिक्षा को मिलाकर 20+ साल का अनुभव। 4 बार हैकथॉन विजेता और डेटा एडवोकेट से सामाजिक प्रभाव। वर्तमान में फिलीपींस में एआई कार्यबल को बढ़ावा देने के लिए काम कर रहा हूँ। मेरे बारे में यहाँ और जानें: https://docligot.com
