நான் எனது RAG pipeline-ஐ ஒரு black box போலக் கருதினேன். Embeddings உள்ளே சென்றன, பதில்கள் வெளியே வந்தன, ஆனால் இடையில் எங்கோ எனது கிளவுட் கட்டணம் (cloud bill) அதிகரித்துக் கொண்டே இருந்தது. நான் பேசிய பெரும்பாலான டெவலப்பர்களைப் போலவே, நானும் dense vector மாதிரிகள்தான் (dense vector models) இதற்குப் பொறுப்பு என்று நினைத்தேன். அவை அதிக செலவு தரக்கூடியவை என்று தோன்றியது. ஆயிரம் பக்கங்களை high-dimensional floats ஆக மாற்றுவது என்பது ஒரு கனரக உற்பத்திப் பணி போலத் தெரிந்தது, எனவே நான் அதை மிகுந்த எச்சரிக்கையுடன் கையாண்டேன். ஏற்கனவே செயலாக்கிய தரவை மீண்டும் embed செய்வதைத் தவிர்க்க ஒரு caching layer-ஐயும் நான் உருவாக்கினேன். அந்த மேம்படுத்தலை (optimization) நினைத்து நான் பெருமைப்பட்டேன். பின்னர் நான் இன்வாய்ஸைப் பார்த்து கணக்கிட்டேன்.

நான் முற்றிலும் தவறான விஷயத்தை மேம்படுத்திக் கொண்டிருந்தேன்.

Embedding எனும் பொறி

எனது அனுமானங்களை உடைத்த அந்தத் தகவல் இதோ: 1,000 பக்கங்கள் கொண்ட ஒரு ஆவணத்தை embed செய்வதற்கு சுமார் பதினெட்டு சென்ட் மட்டுமே செலவாகிறது. இது தட்டச்சுப் பிழை அல்ல. பெரும்பாலான நகரங்களில் ஒரு கப் காபியின் விலையை விடக் குறைவான விலையில், நீங்கள் ஒரு முழு புத்தகத்தையும் vectorize செய்யலாம். மிக முக்கியமாக, அந்தச் செலவு ஒருமுறை மட்டுமே, அதாவது தரவு உள்ளீட்டின் (ingestion) போது ஏற்படும். ஆரம்பப் passes முடிந்த பிறகு, அந்த vectors சேமிப்பகத்தில் காத்திருக்கும். ஒரு பயனர் உங்கள் செயலியைத் திறக்கும் ஒவ்வொரு முறையும் அவை கூடுதல் கட்டணத்தை ஏற்படுத்தாது. அவை ஒரு மூலதனச் செலவு (capital expense), தொடர்ச்சியான இழப்பு அல்ல.

இருப்பினும் அந்தத் தவறான கருத்து இன்னும் நீடிக்கிறது. குழப்பத்தின் ஒரு பகுதி அதன் கட்டமைப்பிலேயே உள்ளது. இன்ஜினியர்கள் தங்கள் ஆரம்ப ஆற்றலை Ingestion pipeline-லேயே செலவிடுகிறார்கள். நீங்கள் chunker-ஐ எழுதுகிறீர்கள், tokenizer-உடன் போராடுகிறீர்கள், உங்கள் terminal-இல் progress bars நகர்வதைப் பார்க்கிறீர்கள். அந்தத் தெரிக்கக்கூடிய முயற்சி ஒரு விகிதாச்சாரத் தோற்றத்தை (illusion of proportion) உருவாக்குகிறது. அது உழைப்பு அதிகம் தேவைப்படும் பகுதி என்பதால், அதுவே அதிக செலவு மிக்க பகுதி என்று தோன்றுகிறது. ஆனால் உழைப்பும் செலவும் ஒன்றல்ல, RAG முறையில் அவை பெரும்பாலும் தலைகீழ் விகிதத்தில் இருக்கும்.

மூன்று முற்றிலும் மாறுபட்ட கட்டணங்கள்

செலவுகளை ஒன்றாகக் கூட்டாமல், நிலைகளாகப் பிரித்துப் பார்த்தவுடன் படம் தெளிவாகத் தெரிந்தது. ஒரு RAG அமைப்பு மூன்று வெவ்வேறு பொருளாதார மாதிரிகளில் இயங்குகிறது, உங்கள் பட்ஜெட்டைச் சரியாகப் பராமரிக்க இந்த வேறுபாட்டைப் புரிந்துகொள்வது அவசியம்.

Embeddings என்பது ஒருமுறை மட்டுமே ஏற்படும் உற்பத்திச் செலவு. ஆவணங்களை vectors ஆக மாற்ற நீங்கள் பணம் செலுத்துகிறீர்கள், அவ்வளவுதான். உங்கள் ஆவணங்கள் நிலையானவை (static) என்றால், இந்தச் செலவு உங்கள் மாதாந்திரப் பட்டியலில் மிகக் குறைவாகவே இருக்கும்.

Vector databases என்பது உள்கட்டமைப்பு வாடகை. அமைப்பை 24 மணிநேரமும் இயங்க வைக்க நீங்கள் பணம் செலுத்துகிறீர்கள். மில்லியன் கணக்கான chunks-களைத் தாங்கும் SSD-களுக்காகவும், indexes-களைப் பராமரிக்கும் CPU cores-களுக்காகவும், மற்றும் 100 மில்லி விநாடிகளுக்கும் குறைவான வேகத்தில் தேடல்களை வழங்கும் network-க்காகவும் நீங்கள் பணம் செலுத்துகிறீர்கள். இந்தச் செலவு உண்மையானது, மேலும் இது தரவின் அளவைப் பொறுத்து அதிகரிக்கும், ஆனால் பொதுவாக இது கணிக்கக்கூடியது. இது ஒரு ஜிம் மெம்பர்ஷிப் போலச் செயல்படும். நீங்கள் ஒருமுறை வினவினாலும் அல்லது பத்தாயிரம் முறை வினவினாலும், அடிப்படை உள்கட்டமைப்புச் செலவு ஏறக்குறைய ஒரே மாதிரியாகவே இருக்கும்.

Large language models என்பது பயன்பாட்டு வரி (consumption taxes). ஒவ்வொரு பயனர் கேள்வியும் ஒரு கட்டணத்தைத் தூண்டுகிறது. உங்கள் retrieval layer-லிருந்து வெளியேறி prompt-க்குள் நுழையும் ஒவ்வொரு token-க்கும் பணம் செலவாகிறது. ஒவ்வொரு reasoning step, ஒவ்வொரு formatting instruction, மற்றும் நீங்கள் மாடலிடம் கேட்கும் ஒவ்வொரு citation-உம் நுணுக்கமான கூடுதல் எடையைச் சேர்க்கின்றன. ஆனால் அந்தச் சிறு கட்டணங்கள் session எண்ணிக்கையால் பெருக்கப்படுகின்றன, மேலும் session எண்ணிக்கையும் அதிகரித்துக்கொண்டே போகிறது. இங்குதான் latency மற்றும் செலவு இரண்டும் இணைந்து ஒரு பெரிய சுமையை உருவாக்குகின்றன. ஒரு மெதுவான வினவல் (query) பயனருக்கு எரிச்சலைத் தருவது மட்டுமல்ல; பயனர் காத்திருக்கும் நேரத்தில் அது உங்கள் பணத்தை நேரடியாக எரித்துக் கொண்டிருக்கிறது.

இவை ஒரே பிரச்சனையின் வெவ்வேறு வடிவங்கள் அல்ல. இவை மூன்று தனித்தனி பிரச்சனைகள். Ingestion செலவைக் குறைப்பதன் மூலம் வினவல் நேரச் செலவு (query-time spending) பிரச்சனையைத் தீர்க்க முடியாது. அது உங்கள் காரின் இன்ஜினைச் சரிசெய்வதன் மூலம் பார்க்கிங் கட்டணத்தைச் சேமிக்க முயற்சிப்பதைப் போன்றது.

பணம் உண்மையில் எங்கே செல்கிறது

நீங்கள் ஒரு production RAG செயலியை இயக்கிக் கொண்டிருந்தால், உங்கள் cost explorer-ஐத் திறந்து பயன்பாட்டு வகையின் (usage type) அடிப்படையில் வடிகட்டவும். உங்கள் embedding வேலை ஒரு நாளைக்கு ஒருமுறை மட்டும் ஒரு நேர்க்கோடாக இருக்கும் என்றும், ஆனால் உங்கள் LLM endpoint போக்குவரத்து அதிகரிக்கும் போது இதயத் துடிப்பைப் போலத் துடித்துக் கொண்டே இருக்கும் என்றும் நான் பந்தயம் கட்டத் தயார். அந்தப் பாணி முழு கதையையும் சொல்கிறது. உங்கள் vectors தூங்குகின்றன; பயனர் ஒரு கேள்வி கேட்கும் ஒவ்வொரு முறையும் உங்கள் மாடல் விழித்துக் கொள்கிறது.

இந்த உணர்தல் எனது பொறியியல் பணிகளுக்கு முன்னுரிமை அளிக்கும் முறையை மாற்றியது. Ingestion-ஐ எப்படி மலிவாக்குவது என்று கேட்பதை நிறுத்திவிட்டு, ஒவ்வொரு கேள்வியையும் எப்படி மலிவாக்குவது என்று கேட்கத் தொடங்கினேன். இந்த மாற்றம் இயல்பாகத் தோன்றலாம், ஆனால் பெரும்பாலான குழுக்கள் இன்னும் யூகங்களின் அடிப்படையிலேயே செயல்படுகிறார்கள். அவர்கள் embedding நிலைக்குத் தேவையில்லாத deduplication logic-களை உருவாக்குகிறார்கள், பின்னர் எந்தச் சிந்தனையும் இன்றி LLM-க்கு அதிகப்படியான, தெளிவற்ற context windows-களை வழங்குகிறார்கள். கூரை கசியும் போது அவர்கள் தரையைத் துடைத்துக் கொண்டிருக்கிறார்கள்.

உங்கள் Pipeline-ஐப் பாதிக்காமல் செலவைக் குறைப்பது எப்படி

ஒரு RAG அமைப்பில் பணத்தைச் சேமிக்க, செலவு மாதிரிக்கேற்ப தந்திரங்களைச் சரியாகப் பொருத்த வேண்டும். உண்மையில் வேலை செய்யும் முறைகள் இதோ:

செயலாக்குவதற்கு முன் Deduplicate செய்யுங்கள்

Most organizational knowledge bases move slowly. Policies, handbooks, research PDFs, and archived reports sit untouched for months. In many pipelines, about eighty percent of source documents stay identical between ingestion runs. Despite this, plenty of systems drop the entire corpus and rebuild the index from scratch on a schedule. Do not do that. Build a gate at the entry to your pipeline. Hash incoming files. Compare last-modified timestamps. If a document has not changed, skip it entirely. Re-processing static files is pure waste. It costs compute, it wears SSDs unnecessarily, and it balloons your ingestion logs with false activity.

In practice, store a lightweight manifest that maps file paths to checksums. When the scheduler wakes up, let it check the manifest first. Only the minority of changed files should ever see a chunker.

Patch Documents, Do Not Replace Them

When a document does change, resist the instinct to treat it as a brand-new file. A fifty-page technical spec might receive a two-paragraph revision in section four. If your pipeline replaces the entire file, you will re-chunk and re-embed forty-nine perfectly good pages for no reason.

Instead, compare the new version against the old one. Identify the delta. Then re-chunk and re-embed only the sections that changed. Use metadata like page numbers, section IDs, header anchors, or paragraph ranges to track boundaries. If your chunking strategy respects document structure, this is straightforward. If it does not, fixing your chunker is a better investment than buying a bigger inference cluster. The engineering cost of maintaining a diff-aware pipeline pays for itself within weeks once your document count scales.

Attack the Recurring Costs Head-On

Since LLM calls run on every query, shaving even a few tokens or caching a handful of responses creates outsized returns. Start with prompt caching. If one user asks about your refund policy and another asks the same thing ten minutes later, there is no reason to hit the model twice. Store recent query-response pairs with semantic similarity matching. When a new question lands within a similarity threshold of a cached one, return the stored answer directly. No tokens generated, no dollars spent.

Next, look hard at your retrieval quality. A sloppy retriever forces the LLM to read a haystack to find the needle. If you stuff the prompt with twenty irrelevant chunks because your top-k cutoff is too loose, you are paying the model to skim noise. Tighten your retrieval. Trim your top-k. Compress chunks before sending them. Remove boilerplate footers and headers during ingestion so they never reach the prompt. Every token you remove from the context window is a fraction of a cent saved, and those fractions accumulate across thousands of daily queries.

Better retrieval also improves latency, which is another form of cost. Users abandon slow interfaces. A faster answer is both cheaper to produce and better for retention.

The Real Takeaway

Stop optimizing what feels expensive and start optimizing what your invoice says is expensive. Measure each stage independently. You will likely find that embeddings are the cheap part, vector storage is the steady part, and LLM inference is the part that bleeds. Focus your energy on query-time efficiency, incremental updates, and surgical deduplication. Build for the thousandth user question, not the fiftieth document upload. The bottleneck is rarely where you think it is.

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

Join the discussion in the GyaanSetu AI learning community.