मी माझ्या RAG पाइपलाइनकडे एका 'ब्लॅक बॉक्स'प्रमाणे पाहायचो. एम्बेडिंग्स (Embeddings) आत जायचे, उत्तरे बाहेर यायची आणि त्या दरम्यान कुठेतरी माझा क्लाउड बिल वाढत जायचा. मी ज्या इतर डेव्हलपर्सशी बोललो, त्यांच्यासारखाच माझाही असा समज होता की डेंस वेक्टर मॉडेल्स (dense vector models) हे मुख्य खलनायक आहेत. ते खर्चिक वाटायचे. हजारो पानांचे रूपांतर हाय-डायमेंशनल फ्लोट्समध्ये (high-dimensional floats) करणे हे एखाद्या जड उत्पादन प्रक्रियेसारखे वाटायचे, म्हणून मी त्याकडे अत्यंत सावधगिरीने वागत होतो. मी आधीच प्रोसेस केलेल्या डेटाचे पुन्हा एम्बेडिंग टाळण्यासाठी खास एक कॅशिंग लेअर (caching layer) देखील तयार केला होता. मला त्या ऑप्टिमायझेशनचा अभिमान वाटत होता. मग मी इनव्हॉइस पाहिले आणि गणित मांडले.

मी पूर्णपणे चुकीच्या गोष्टीचे ऑप्टिमायझेशन करत होतो.

एम्बेडिंगचा सापळा (The Embedding Trap)

माझे गृहितक मोडीत काढणारा आकडा हा आहे: १००० पानांचे डॉक्युमेंट एम्बेड करण्यासाठी साधारणतः १८ सेंट्स खर्च येतो. ही कोणतीही टायपिंग चूक नाही. बहुतेक शहरांमध्ये एका कप कॉफीच्या किमतीपेक्षाही कमी खर्चात, तुम्ही संपूर्ण पुस्तक वेक्टरझाईस (vectorize) करू शकता. अधिक महत्त्वाचे म्हणजे, हा खर्च फक्त एकदाच, म्हणजे डेटा इनजेशनच्या (ingestion) वेळी येतो. सुरुवातीच्या प्रक्रियेनंतर, ते वेक्टर्स स्टोरेजमध्ये बसून राहतात. वापरकर्ता तुमचे ॲप्लिकेशन प्रत्येक वेळी उघडतो तेव्हा ते वारंवार शुल्क आकारत नाहीत. तो एक भांडवली खर्च (capital expense) आहे, वारंवार होणारा खर्च नाही.

तरीही हा गैरसमज कायम आहे. या गोंधळाचा एक भाग संरचनात्मक आहे. इंजिनिअर्स आपली सुरुवातीची ऊर्जा 'इनजेशन पाइपलाइन'वर खर्च करतात. तुम्ही चंकर (chunker) लिहिता, टोकेनायझरशी (tokenizer) झुंजता आणि तुमच्या टर्मिनलवर प्रोग्रेस बार हळूहळू पुढे जाताना पाहता. हा दृश्यमान प्रयत्न प्रमाणाचे एक भासमान चित्र निर्माण करतो. ते खर्चिक वाटते कारण ती प्रक्रिया श्रमसाध्य (labor-intensive) असते. परंतु श्रम आणि खर्च एकच नसतात आणि RAG मध्ये ते अनेकदा एकमेकांच्या व्यस्त प्रमाणात असतात.

तीन अत्यंत भिन्न बिले

एकदा मी खर्च एकत्र न ठेवता टप्प्यानुसार वेगळा केला, तेव्हा चित्र स्पष्ट झाले. एक RAG सिस्टम तीन वेगवेगळ्या आर्थिक मॉडेल्सवर चालते आणि जर तुम्हाला तुमचे बजेट नियंत्रणात ठेवायचे असेल, तर त्यातील फरक समजून घेणे आवश्यक आहे.

एम्बेडिंग्स हा एकदाच होणारा उत्पादन खर्च आहे. डॉक्युमेंट्सचे वेक्टर्समध्ये रूपांतर करण्यासाठी तुम्ही पैसे देता आणि त्यानंतर तुमचे काम संपते. जर तुमची डॉक्युमेंट्स स्थिर (static) असतील, तर तुमच्या मासिक बिलात ही नोंद क्वचितच दिसून येईल.

वेक्टर डेटाबेस हे इन्फ्रास्ट्रक्चरचे भाडे आहे. सिस्टम २४ तास चालू ठेवण्यासाठी तुम्ही पैसे देता. लाखो चंक्स (chunks) साठवून ठेवणाऱ्या SSDs साठी, इंडेक्स (indexes) राखणाऱ्या CPU कोअर्ससाठी आणि १०० मिलीसेकंदपेक्षा कमी वेळेत शोध देणाऱ्या नेटवर्कसाठी तुम्ही पैसे देता. हा खर्च वास्तविक आहे आणि तो डेटाच्या प्रमाणानुसार वाढतो, परंतु तो सामान्यतः अंदाजित असतो. हे जिमच्या सभासदत्वासारखे असते. तुम्ही एकदा क्वेरी करा किंवा दहा हजार वेळा, मूळ इन्फ्रास्ट्रक्चरचा खर्च साधारणपणे सारखाच राहतो.

लार्ज लँग्वेज मॉडेल्स (LLMs) हा वापरावरील कर आहे. प्रत्येक वापरकर्त्याचा प्रश्न एक नवीन बिल ट्रिगर करतो. तुमच्या रिट्रिव्हल लेअरमधून (retrieval layer) बाहेर पडणारा आणि प्रॉम्प्टमध्ये (prompt) जाणारा प्रत्येक टोकन पैसे खर्च करतो. प्रत्येक रिझनिंग स्टेप (reasoning step), प्रत्येक फॉरमॅटिंग सूचना, मॉडेलला जनरेट करायला सांगितलेले प्रत्येक सायटेशन (citation) सूक्ष्म भार वाढवते. परंतु हे सूक्ष्म शुल्क सेशनच्या संख्येने गुणले जातात आणि सेशनची संख्या सतत वाढत जाते. येथेच लॅटन्सी (latency) आणि खर्च यांचा संबंध येतो. संथ क्वेरी वापरकर्त्यासाठी केवळ त्रासदायक नसते; तर वापरकर्ता वाट पाहत असताना ती प्रत्यक्षात तुमचे पैसे जाळत असते.

हे एकाच समस्येचे वेगवेगळे प्रकार नाहीत. या तीन वेगवेगळ्या समस्या आहेत. इनजेशन स्वस्त करून तुम्ही क्वेरी-टाइम खर्च कमी करू शकत नाही. हे पार्किंगचे पैसे वाचवण्यासाठी तुमच्या कारचे इंजिन ट्यून करण्यासारखे आहे.

पैसा प्रत्यक्षात कुठे खर्च होतो

जर तुम्ही प्रोडक्शनमध्ये RAG ॲप्लिकेशन चालवत असाल, तर तुमचा 'कॉस्ट एक्सप्लोरर' (cost explorer) उघडा आणि वापराच्या प्रकारानुसार (usage type) फिल्टर करा. मी पैज लावू शकतो की तुमचे एम्बेडिंग जॉब दिवसातून एकदाच स्थिर रेषेत असेल, तर तुमचा LLM एंडपॉइंट ट्रॅफिकनुसार वाढणाऱ्या हार्टबीटसारखा दिसेल. तो पॅटर्न संपूर्ण गोष्ट सांगतो. तुमचे वेक्टर्स झोपलेले असतात; वापरकर्त्याला प्रश्न विचारताच तुमचे मॉडेल जागे होते.

या जाणीवेने मी इंजिनिअरिंग कामाला प्राधान्य देण्याची पद्धत बदलली. मी इनजेशन स्वस्त कसे करायचे हे विचारणे थांबवले आणि प्रत्येक प्रश्न स्वस्त कसा करायचा हे विचारण्यास सुरुवात केली. हे बदलणे साधे वाटते, परंतु बहुतेक टीम्स अजूनही केवळ अंदाजावर काम करत आहेत. ते एम्बेडिंग स्टेजसाठी क्लिष्ट ड्युप्लिकेशन काढण्याचे लॉजिक (deduplication logic) तयार करतात आणि नंतर कोणताही विचार न करता LLM ला फुगलेले आणि विखुरलेले कॉन्टेक्स्ट विंडोज (context windows) देतात. ते छप्पर गळत असताना फरशी पॉलिश करत आहेत.

तुमची पाइपलाइन न बिघडवता खर्च कसा कमी करावा

RAG सिस्टममध्ये पैसे वाचवण्यासाठी खर्चाच्या मॉडेलनुसार योग्य रणनीती निवडणे आवश्यक आहे. खालील गोष्टी खरोखर काम करतात.

प्रक्रिया करण्यापूर्वी ड्युप्लिकेट्स काढून टाका (Deduplicate Before You Process)

बहुतेक संस्थात्मक नॉलेज बेस (knowledge bases) संथ गतीने काम करतात. धोरणे (Policies), हँडबुक्स, रिसर्च PDFs आणि आर्काइव्ह केलेले रिपोर्ट्स कित्येक महिने न वापरता पडून राहतात. अनेक पाइपलाईन्समध्ये, इनजेशन रनच्या (ingestion runs) दरम्यान सुमारे ८० टक्के मूळ दस्तऐवज तंतोतंत सारखेच राहतात. असे असूनही, अनेक सिस्टम्स संपूर्ण कॉर्पस (corpus) काढून टाकतात आणि ठराविक वेळाने शून्यापासून इंडेक्स पुन्हा तयार करतात. असे करू नका. तुमच्या पाइपलाइनच्या प्रवेशद्वारावर एक गेट (gate) तयार करा. येणाऱ्या फाईल्सना हॅश (Hash) करा. 'last-modified' टाइमस्टॅम्पची तुलना करा. जर एखादा दस्तऐवज बदललेला नसेल, तर तो पूर्णपणे वगळा. स्टॅटिक फाईल्स पुन्हा प्रोसेस करणे म्हणजे निव्वळ वाया घालवणे आहे. यामुळे कम्प्युट (compute) खर्च होतो, SSDs अनावश्यकपणे झिजतात आणि तुमच्या इनजेशन लॉग्समध्ये (ingestion logs) खोट्या हालचालींमुळे वाढ होते.

व्यवहारात, फाईल पाथ्सना (file paths) चेकसम्सशी (checksums) मॅप करणारा एक हलका (lightweight) मॅनिफेस्ट (manifest) स्टोअर करा. जेव्हा शेड्युलर (scheduler) सुरू होईल, तेव्हा त्याला प्रथम मॅनिफेस्ट तपासू द्या. केवळ बदललेल्या फाईल्सचाच चंकरला (chunker) स्पर्श व्हायला हवा.

दस्तऐवज पॅच करा, ते बदलू नका (Replace करू नका)

जेव्हा एखादा दस्तऐवज बदलतो, तेव्हा त्याला पूर्णपणे नवीन फाईल मानण्याची प्रवृत्ती टाळा. पन्नास पानांच्या तांत्रिक स्पेसिफिकेशनमध्ये (technical spec) चौथ्या सेक्शनमध्ये केवळ दोन परिच्छेदांची सुधारणा (revision) असू शकते. जर तुमची पाइपलाइन संपूर्ण फाईल बदलत असेल, तर तुम्ही विनाकारण ४९ उत्तम पाने पुन्हा चंक (re-chunk) आणि पुन्हा एम्बेड (re-embed) कराल.

त्याऐवजी, नवीन आवृत्तीची जुन्या आवृत्तीशी तुलना करा. त्यातील फरक (delta) ओळखा. त्यानंतर केवळ बदललेले सेक्शनच पुन्हा चंक आणि एम्बेड करा. सीमा (boundaries) ट्रॅक करण्यासाठी पेज नंबर, सेक्शन आयडी (section IDs), हेडर अँकर्स (header anchors) किंवा पॅराग्राफ रेंज यांसारख्या मेटाडेटाचा वापर करा. जर तुमची चंकिंग स्ट्रॅटेजी (chunking strategy) दस्तऐवजाच्या रचनेचा आदर करत असेल, तर हे सोपे आहे. जर तसे नसेल, तर मोठा इन्फरन्स क्लस्टर (inference cluster) खरेदी करण्यापेक्षा तुमचा चंकर (chunker) सुधारणे ही अधिक चांगली गुंतवणूक आहे. एकदा का तुमच्या दस्तऐवजांची संख्या वाढली की, 'diff-aware' पाइपलाइन राखण्याचा इंजिनिअरिंग खर्च काही आठवड्यांतच वसूल होतो.

वारंवार येणाऱ्या खर्चावर थेट प्रहार करा

प्रत्येक क्वेरीवर LLM कॉल्स चालत असल्यामुळे, काही टोकन्स वाचवणे किंवा काही प्रतिसाद कॅश (cache) करणे खूप फायदेशीर ठरते. प्रॉम्प्ट कॅशिंगपासून (prompt caching) सुरुवात करा. जर एका वापरकर्त्याने तुमच्या रिफंड पॉलिसीबद्दल विचारले आणि दुसऱ्याने दहा मिनिटांनी तेच विचारले, तर मॉडेलला दोनदा हिट करण्याची गरज नाही. सिमेंटिक सिमिलॅरिटी मॅचिंगसह (semantic similarity matching) अलीकडील क्वेरी-रिस्पॉन्स जोड्या स्टोअर करा. जेव्हा एखादा नवीन प्रश्न कॅश केलेल्या प्रश्नाच्या सिमिलॅरिटी थ्रेशोल्डमध्ये (similarity threshold) येतो, तेव्हा स्टोअर केलेले उत्तर थेट परत करा. कोणतेही टोकन्स जनरेट होणार नाहीत आणि कोणतेही पैसे खर्च होणार नाहीत.

त्यानंतर, तुमच्या रिट्रिव्हल क्वालिटीवर (retrieval quality) लक्ष केंद्रित करा. एक निष्काळजी रिट्रिव्हर (retriever) सुई शोधण्यासाठी मॉडेलला गवताचा ढीग (haystack) वाचण्यास भाग पाडतो. जर तुमचा top-k कटऑफ खूप सैल असेल आणि तुम्ही प्रॉम्प्टमध्ये वीस असंबद्ध चंक्स भरले असतील, तर तुम्ही मॉडेलला केवळ 'नॉईज' (noise) वाचण्यासाठी पैसे मोजत आहात. तुमचे रिट्रिव्हल अधिक अचूक करा. तुमचा top-k कमी करा. चंक्स पाठवण्यापूर्वी ते कॉम्प्रेस (compress) करा. इनजेशन दरम्यान बॉयलरप्लेट फुटर आणि हेडर काढून टाका जेणेकरून ते कधीही प्रॉम्प्टपर्यंत पोहोचणार नाहीत. तुम्ही कॉन्टेक्स्ट विंडोमधून (context window) काढून टाकलेला प्रत्येक टोकन म्हणजे वाचलेला काही पैसा आहे, आणि दररोजच्या हजारो क्वेरीजमध्ये हे छोटे छोटे भाग जमा होऊन मोठी बचत करतात.

चांगले रिट्रिव्हल लेटन्सी (latency) देखील सुधारते, जो खर्चाचा दुसरा प्रकार आहे. वापरकर्ते संथ इंटरफेस सोडून जातात. जलद उत्तर तयार करणे स्वस्त असते आणि ते वापरकर्त्यांना टिकवून ठेवण्यासाठी (retention) देखील चांगले असते.

मुख्य निष्कर्ष

जे महाग वाटते त्याचे ऑप्टिमायझेशन करणे थांबवा आणि तुमच्या इनव्हॉइसमध्ये (invoice) जे महाग असल्याचे दिसते त्याचे ऑप्टिमायझेशन सुरू करा. प्रत्येक टप्पा स्वतंत्रपणे मोजा. तुम्हाला बहुधा असे आढळेल की एम्बेडिंग्स (embeddings) स्वस्त आहेत, वेक्टर स्टोरेज (vector storage) स्थिर आहे आणि LLM इन्फरन्स (LLM inference) हा असा भाग आहे जो तुमचा पैसा खर्च करतो. तुमची ऊर्जा क्वेरी-टाइम कार्यक्षमता (query-time efficiency), इंक्रीमेंटल अपडेट्स (incremental updates) आणि अचूक ड्युप्लिकेशन काढण्यावर (surgical deduplication) केंद्रित करा. पन्नाव्या दस्तऐवज अपलोडसाठी नाही, तर हजारव्या वापरकर्त्याच्या प्रश्नासाठी सिस्टम तयार करा. अडथळा (bottleneck) सहसा तिथे नसतो जिथे तुम्हाला वाटतं.

Source: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing

Join the discussion in the GyaanSetu AI learning community.