मैं अपनी RAG पाइपलाइन को एक ब्लैक बॉक्स की तरह समझता था। एम्बेडिंग्स अंदर जाती थीं, जवाब बाहर आते थे, और इसी बीच मेरा क्लाउड बिल बढ़ता जाता था। मेरे द्वारा बात किए गए अधिकांश डेवलपर्स की तरह, मैंने मान लिया था कि डेंस वेक्टर मॉडल (dense vector models) ही असली विलेन हैं। वे महंगे लगते थे। हज़ार पन्नों को हाई-डायमेंशनल फ्लोट्स (high-dimensional floats) में बदलना भारी मैन्युफैक्चरिंग जैसा महसूस होता था, इसलिए मैं इसे बहुत सावधानी से ट्रीट करता था। मैंने विशेष रूप से उस डेटा को दोबारा एम्बेड करने से बचने के लिए एक कैशिंग लेयर (caching layer) भी बनाई थी जिसे मैं पहले ही प्रोसेस कर चुका था। मुझे उस ऑप्टिमाइज़ेशन पर गर्व था। फिर मैंने अपना इनवॉइस देखा और हिसाब लगाया।
मैं पूरी तरह से गलत चीज़ को ऑप्टिमाइज़ कर रहा था।
एम्बेडिंग का जाल
यहाँ वह आंकड़ा है जिसने मेरी धारणाओं को बदल दिया: 1,000 पन्नों के दस्तावेज़ को एम्बेड करने की लागत लगभग अठारह सेंट है। यह कोई टाइपो नहीं है। अधिकांश शहरों में एक कप कॉफी की कीमत से भी कम में, आप पूरी किताब को वेक्टर में बदल सकते हैं। इससे भी महत्वपूर्ण बात यह है कि यह लागत केवल एक बार लगती है, इंजेशन (ingestion) के समय। शुरुआती पास के बाद, वे वेक्टर्स स्टोरेज में रहते हैं और इंतज़ार करते हैं। जब कोई उपयोगकर्ता आपका एप्लिकेशन खोलता है, तो वे हर बार मीटर शुल्क (metered fees) नहीं बढ़ाते हैं। वे एक पूंजीगत व्यय (capital expense) हैं, न कि बार-बार होने वाला खर्च।
फिर भी यह मिथक बना हुआ है। भ्रम का एक हिस्सा संरचनात्मक है। इंजेशन पाइपलाइन वह जगह है जहाँ इंजीनियर अपनी शुरुआती ऊर्जा खर्च करते हैं। आप चंकर (chunker) लिखते हैं, टोकनाइज़र (tokenizer) के साथ संघर्ष करते हैं, और अपने टर्मिनल पर प्रोग्रेस बार को धीरे-धीरे चलते हुए देखते हैं। यह दृश्य प्रयास अनुपात का भ्रम पैदा करता है। यह महंगा हिस्सा लगता है क्योंकि यह श्रम-साध्य (labor-intensive) हिस्सा है। लेकिन श्रम और लागत एक समान नहीं हैं, और RAG में वे अक्सर विपरीत रूप से संबंधित होते हैं।
तीन बहुत अलग बिल
एक बार जब मैंने लागतों को एक साथ जोड़ने के बजाय चरणों के आधार पर अलग कर दिया, तो तस्वीर साफ हो गई। एक RAG सिस्टम तीन अलग-अलग आर्थिक मॉडलों पर चलता है, और यदि आप अपने बजट को नियंत्रण में रखना चाहते हैं तो अंतर को समझना आवश्यक है।
एम्बेडिंग्स एक बार की मैन्युफैक्चरिंग लागत है। आप दस्तावेज़ों को वेक्टर्स में बदलने के लिए भुगतान करते हैं, और फिर आपका काम हो जाता है। यदि आपके दस्तावेज़ स्थिर (static) हैं, तो यह मद आपके मासिक बिल में शायद ही कभी दिखाई देगी।
वेक्टर डेटाबेस इंफ्रास्ट्रक्चर का किराया है। आप सिस्टम को चौबीसों घंटे चालू रखने के लिए भुगतान करते हैं। आप उन SSDs के लिए भुगतान करते हैं जिनमें लाखों चंक्स (chunks) रखे होते हैं, उन CPU कोर्स के लिए जो इंडेक्स बनाए रखते हैं, और उस नेटवर्क के लिए जो सब-100-मिलीसेकंड सर्च प्रदान करता है। यह लागत वास्तविक है, और यह डेटा वॉल्यूम के साथ बढ़ती है, लेकिन यह आम तौर पर अनुमानित होती है। यह जिम की मेंबरशिप की तरह काम करती है। चाहे आप एक बार क्वेरी करें या दस हज़ार बार, बुनियादी इंफ्रास्ट्रक्चर लागत लगभग उतनी ही रहती है।
लार्ज लैंग्वेज मॉडल्स (LLMs) खपत कर (consumption taxes) की तरह हैं। उपयोगकर्ता का हर एक सवाल एक बिल ट्रिगर करता है। आपके रिट्रीवल लेयर से निकलने वाला और प्रॉम्प्ट (prompt) में जाने वाला हर टोकन पैसे खर्च करता है। हर रीजनिंग स्टेप, हर फॉर्मेटिंग निर्देश, हर साइटेशन जिसे आप मॉडल से जेनरेट करने के लिए कहते हैं, वह सूक्ष्म भार जोड़ता है। लेकिन ये सूक्ष्म शुल्क सत्रों (sessions) की संख्या से गुणा हो जाते हैं, और सत्रों की संख्या लगातार बढ़ती जाती है। यहीं पर लेटेंसी (latency) खर्च के साथ जुड़ जाती है। एक धीमी क्वेरी उपयोगकर्ता के लिए केवल परेशान करने वाली नहीं होती; यह उपयोगकर्ता के इंतज़ार करने के दौरान सक्रिय रूप से कैश जला रही होती है।
ये एक ही समस्या के अलग-अलग रूप नहीं हैं। ये तीन अलग-अलग समस्याएँ हैं। आप इंजेशन को सस्ता बनाकर क्वेरी-टाइम खर्च की समस्या को हल नहीं कर सकते। यह वैसा ही है जैसे पार्किंग पर पैसे बचाने के लिए अपनी कार के इंजन को ट्यून करना।
पैसा वास्तव में कहाँ जाता है
यदि आप एक प्रोडक्शन RAG एप्लिकेशन चला रहे हैं, तो अपना कॉस्ट एक्सप्लोरर (cost explorer) खोलें और उपयोग के प्रकार (usage type) के आधार पर फ़िल्टर करें। मैं शर्त लगा सकता हूँ कि आपका एम्बेडिंग जॉब दिन में एक बार एक सीधी रेखा की तरह होगा, जबकि आपका LLM एंडपॉइंट एक धड़कन (heartbeat) की तरह दिखेगा जो ट्रैफिक के साथ स्पाइक करता है। वह पैटर्न पूरी कहानी बताता है। आपके वेक्टर्स सोते हैं; आपका मॉडल हर बार जाग जाता है जब किसी उपयोगकर्ता के पास कोई सवाल होता है।
इस अहसास ने मेरे इंजीनियरिंग कार्यों की प्राथमिकता तय करने के तरीके को बदल दिया। मैंने यह पूछना बंद कर दिया कि इंजेशन को सस्ता कैसे बनाया जाए और यह पूछना शुरू कर दिया कि प्रत्येक प्रश्न को सस्ता कैसे बनाया जाए। यह बदलाव सुनने में स्पष्ट लगता है, लेकिन अधिकांश टीमें अभी भी केवल अंदाज़ों पर काम करती हैं। वे एम्बेडिंग चरण के लिए जटिल डिडुप्लिकेशन लॉजिक (deduplication logic) बनाते हैं और फिर बिना सोचे-समझे LLM को फूले हुए, बिना फोकस वाले कॉन्टेक्स्ट विंडोज़ (context windows) खिलाते हैं। वे छत से पानी टपकने के बावजूद फर्श को चमकाने में लगे हैं।
अपने पाइपलाइन को खराब किए बिना लागत कैसे कम करें
RAG सिस्टम में पैसे बचाने के लिए लागत मॉडल के अनुसार रणनीति चुनना आवश्यक है। यहाँ बताया गया है कि वास्तव में क्या काम करता है।
प्रोसेस करने से पहले डुप्लीकेट डेटा हटाएं (Deduplicate)
अधिकांश संगठनात्मक नॉलेज बेस (knowledge bases) धीमी गति से चलते हैं। नीतियां, हैंडबुक, रिसर्च PDF और आर्काइव की गई रिपोर्टें महीनों तक बिना छुए पड़ी रहती हैं। कई पाइपलाइनों में, लगभग अस्सी प्रतिशत सोर्स डॉक्यूमेंट्स (source documents) इनजेशन रन (ingestion runs) के बीच समान रहते हैं। इसके बावजूद, कई सिस्टम पूरे कॉर्पस (corpus) को हटा देते हैं और एक निर्धारित समय पर इंडेक्स को फिर से शुरू से बनाते हैं। ऐसा न करें। अपनी पाइपलाइन के प्रवेश द्वार पर एक गेट (gate) बनाएं। आने वाली फाइलों को हैश (hash) करें। 'last-modified' टाइमस्टैम्प की तुलना करें। यदि कोई डॉक्यूमेंट नहीं बदला है, तो उसे पूरी तरह से छोड़ दें। स्टैटिक फाइलों को फिर से प्रोसेस करना पूरी तरह से बर्बादी है। इससे कंप्यूट (compute) की लागत आती है, SSDs अनावश्यक रूप से घिसते हैं, और यह आपके इनजेशन लॉग्स (ingestion logs) को गलत गतिविधि से भर देता है।
व्यवहार में, एक हल्का मैनिफेस्ट (manifest) स्टोर करें जो फाइल पाथ (file paths) को चेकसम (checksums) से मैप करता हो। जब शेड्यूलर (scheduler) सक्रिय हो, तो उसे पहले मैनिफेस्ट की जांच करने दें। केवल बदले हुए फाइलों के अल्पसंख्यक हिस्से को ही चंकर (chunker) तक पहुँचना चाहिए।
डॉक्यूमेंट्स को पैच करें, उन्हें बदलें नहीं
जब कोई डॉक्यूमेंट बदलता है, तो उसे बिल्कुल नई फाइल मानने की प्रवृत्ति से बचें। पचास पन्नों के एक तकनीकी स्पेसिफिकेशन (technical spec) के चौथे सेक्शन में केवल दो पैराग्राफ का संशोधन हो सकता है। यदि आपकी पाइपलाइन पूरी फाइल को बदल देती है, तो आप बिना किसी कारण के उन उनतालीस पन्नों को फिर से चंक (re-chunk) और री-एम्बेड (re-embed) करेंगे जो बिल्कुल सही थे।
इसके बजाय, नए वर्जन की तुलना पुराने वर्जन से करें। अंतर (delta) की पहचान करें। फिर केवल उन्हीं सेक्शन को री-चंक और री-एम्बेड करें जो बदले हैं। सीमाओं को ट्रैक करने के लिए पेज नंबर, सेक्शन आईडी, हेडर एंकर या पैराग्राफ रेंज जैसे मेटाडेटा का उपयोग करें। यदि आपकी चंकिंग रणनीति डॉक्यूमेंट स्ट्रक्चर का सम्मान करती है, तो यह सीधा काम है। यदि नहीं, तो एक बड़ा इन्फरेंस क्लस्टर (inference cluster) खरीदने की तुलना में अपने चंकर को ठीक करना एक बेहतर निवेश है। एक 'diff-aware' पाइपलाइन बनाए रखने की इंजीनियरिंग लागत, आपके डॉक्यूमेंट की संख्या बढ़ने के बाद कुछ ही हफ्तों में वसूल हो जाती है।
आवर्ती लागतों (Recurring Costs) पर सीधा प्रहार करें
चूंकि हर क्वेरी पर LLM कॉल्स चलती हैं, इसलिए कुछ टोकन बचाना या कुछ रिस्पॉन्स को कैश (cache) करना भी बहुत बड़ा फायदा दे सकता है। प्रॉम्प्ट कैशिंग (prompt caching) से शुरुआत करें। यदि एक यूजर आपकी रिफंड पॉलिसी के बारे में पूछता है और दूसरा दस मिनट बाद वही सवाल पूछता है, तो मॉडल को दो बार हिट करने का कोई कारण नहीं है। सिमेंटिक सिमिलरिटी मैचिंग (semantic similarity matching) के साथ हाल के क्वेरी-रिस्पॉन्स पेयर्स को स्टोर करें। जब कोई नया सवाल कैश किए गए सवाल की सिमिलरिटी थ्रेशोल्ड (similarity threshold) के भीतर आता है, तो सीधे स्टोर किया गया उत्तर वापस कर दें। कोई टोकन खर्च नहीं होगा, कोई पैसा बर्बाद नहीं होगा।
इसके बाद, अपनी रिट्रीवल क्वालिटी (retrieval quality) पर ध्यान दें। एक खराब रिट्रीवर (retriever) LLM को सुई खोजने के लिए घास के ढेर को पढ़ने के लिए मजबूर करता है। यदि आप अपने top-k कटऑफ को बहुत ढीला रखते हैं और प्रॉम्प्ट में बीस अप्रासंगिक चंक्स (irrelevant chunks) भर देते हैं, तो आप मॉडल को शोर (noise) पढ़ने के लिए पैसे दे रहे हैं। अपने रिट्रीवल को सटीक बनाएं। अपने top-k को कम करें। उन्हें भेजने से पहले चंक्स को कंप्रेस (compress) करें। इनजेशन के दौरान बॉयलरप्लेट फुटर और हेडर को हटा दें ताकि वे कभी प्रॉम्प्ट तक न पहुँचें। कॉन्टेक्स्ट विंडो (context window) से आप जितने भी टोकन हटाते हैं, वह एक पैसे का भी छोटा हिस्सा बचाता है, और ये छोटे हिस्से हजारों दैनिक क्वेरीज़ में जमा होकर बड़ी बचत करते हैं।
बेहतर रिट्रीवल लेटेंसी (latency) में भी सुधार करता है, जो लागत का एक और रूप है। यूजर्स धीमे इंटरफेस को छोड़ देते हैं। तेज़ उत्तर देना सस्ता भी है और यूजर रिटेंशन (retention) के लिए भी बेहतर है।
असली निष्कर्ष
उस चीज़ को ऑप्टिमाइज़ करना बंद करें जो महंगी लगती है, और उस चीज़ को ऑप्टिमाइज़ करना शुरू करें जो आपका इनवॉइस (invoice) कहता है कि महंगी है। प्रत्येक चरण को स्वतंत्र रूप से मापें। आपको संभवतः पता चलेगा कि एम्बेडिंग्स (embeddings) सस्ता हिस्सा है, वेक्टर स्टोरेज (vector storage) स्थिर हिस्सा है, और LLM इन्फरेंस (inference) वह हिस्सा है जो सबसे ज्यादा खर्च कराता है। अपनी ऊर्जा क्वेरी-टाइम एफिशिएंसी (query-time efficiency), इंक्रीमेंटल अपडेट्स और सटीक डुप्लीकेशन हटाने (surgical deduplication) पर केंद्रित करें। पचासवें डॉक्यूमेंट अपलोड के लिए नहीं, बल्कि हजारवें यूजर के सवाल के लिए सिस्टम बनाएं। बॉटलनेक (bottleneck) शायद वहां नहीं है जहां आप सोचते हैं।
स्रोत: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
|GyaanSetu AI learning community में चर्चा में शामिल हों।|