నేను నా RAG పైప్లైన్ను ఒక బ్లాక్ బాక్స్లా చూసేవాడిని. ఎంబెడ్డింగ్స్ (Embeddings) లోపలికి వెళ్లేవి, సమాధానాలు బయటకు వచ్చేవి, ఆ మధ్యలో ఎక్కడో నా క్లౌడ్ బిల్లు పెరుగుతూ ఉండేది. నేను కలిసిన మెజారిటీ డెవలపర్ల లాగే, నేను కూడా డెన్స్ వెక్టర్ మోడల్స్ (dense vector models) మాత్రమే దీనికి కారణమని అనుకున్నాను. అవి చాలా ఖరీదైనవిగా అనిపించేవి. వెయ్యి పేజీల డేటాను హై-డైమెన్షనల్ ఫ్లోట్స్గా (high-dimensional floats) మార్చడం అనేది ఏదో భారీ తయారీ ప్రక్రియలా అనిపించేది, అందుకే నేను చాలా జాగ్రత్తగా ఉండేవాడిని. ఇప్పటికే ప్రాసెస్ చేసిన డేటాను మళ్ళీ ఎంబెడ్ చేయకుండా ఉండటానికి నేను ప్రత్యేకంగా ఒక క్యాషింగ్ లేయర్ (caching layer) కూడా నిర్మించాను. ఆ ఆప్టిమైజేషన్ గురించి నేను గర్వపడేవాడిని. కానీ, ఒకసారి ఇన్వాయిస్ చూసి లెక్కలు వేసిన తర్వాత నా ఆలోచన మారిపోయింది.
నేను పూర్తిగా తప్పు అంశాన్ని ఆప్టిమైజ్ చేస్తున్నాను.
ఎంబెడ్డింగ్ ఉచ్చు (The Embedding Trap)
నా అంచనాలను తలకిందులు చేసిన ఆ సంఖ్య ఇది: 1,000 పేజీల డాక్యుమెంట్ను ఎంబెడ్ చేయడానికి సుమారు పద్దెనిమిది సెంట్లు మాత్రమే ఖర్చవుతుంది. ఇది టైపింగ్ తప్పు కాదు. చాలా నగరాల్లో ఒక కప్పు కాఫీ ధర కంటే తక్కువ ఖర్చుతో, మీరు ఒక పూర్తి పుస్తకాన్ని వెక్టరైజ్ చేయవచ్చు. అంతకంటే ముఖ్యమైన విషయం ఏమిటంటే, ఈ ఖర్చు డేటా ఇంజెషన్ (ingestion) సమయంలో ఒక్కసారి మాత్రమే అవుతుంది. మొదటిసారి ప్రాసెస్ చేసిన తర్వాత, ఆ వెక్టర్లు స్టోరేజ్లో ఉంటాయి. ప్రతిసారి ఒక యూజర్ మీ అప్లికేషన్ను ఓపెన్ చేసినప్పుడు అవి అదనపు ఫీజులను వసూలు చేయవు. ఇవి ఒకసారి చేసే పెట్టుబడి వంటివి (capital expense), ప్రతిరోజూ అయ్యే ఖర్చు (recurring drain) కాదు.
అయినప్పటికీ, ఈ అపోహ ఇంకా కొనసాగుతూనే ఉంది. ఈ గందరగోళానికి కారణం నిర్మాణాత్మకమైనది. ఇంజనీర్లు తమ ప్రాథమిక శక్తిని ఇంజెషన్ పైప్లైన్ (ingestion pipeline) పైనే ఖర్చు చేస్తారు. మీరు చంకర్ (chunker) రాస్తారు, టోకనైజర్ (tokenizer) తో పోరాడుతారు, టెర్మినల్లో ప్రోగ్రెస్ బార్ కదులుతుంటే చూస్తూ ఉంటారు. ఈ కంటికి కనిపించే శ్రమ వల్ల అది చాలా ఖరీదైన ప్రక్రియ అనే భ్రమ కలుగుతుంది. కానీ శ్రమకు మరియు ఖర్చుకు తేడా ఉంది, RAG విషయంలో ఇవి తరచుగా విరుద్ధంగా ఉంటాయి.
మూడు విభిన్నమైన బిల్లులు
నేను ఖర్చులను కలిపి చూడకుండా, దశలవారీగా విడదీసి చూసినప్పుడు చిత్రం స్పష్టంగా అర్థమైంది. ఒక RAG సిస్టమ్ మూడు విభిన్న ఆర్థిక నమూనాలపై నడుస్తుంది. మీ బడ్జెట్ను అదుపులో ఉంచుకోవాలంటే ఈ తేడాలను అర్థం చేసుకోవడం చాలా ముఖ్యం.
ఎంబెడ్డింగ్స్ అనేది ఒకసారి మాత్రమే అయ్యే తయారీ ఖర్చు. డాక్యుమెంట్లను వెక్టర్లుగా మార్చడానికి మీరు ఒకసారి చెల్లిస్తారు, అంతే. మీ డాక్యుమెంట్లు స్థిరంగా (static) ఉంటే, ఈ ఖర్చు మీ నెలవారీ బిల్లులో కనిపిస్తుంది కూడా.
వెక్టర్ డేటాబేస్లు ఇన్ఫ్రాస్ట్రక్చర్ అద్దె వంటివి. సిస్టమ్ను 24/7 నడపడానికి మీరు దీనికి చెల్లిస్తారు. లక్షలాది చంక్స్ (chunks) ని నిల్వ చేసే SSDల కోసం, ఇండెక్స్లను నిర్వహించే CPU కోర్ల కోసం, మరియు 100 మిల్లీసెకన్ల కంటే తక్కువ సమయంలో సెర్చ్ రిజల్ట్స్ ఇచ్చే నెట్వర్క్ కోసం మీరు చెల్లిస్తారు. ఈ ఖర్చు నిజమైనది మరియు డేటా పరిమాణంతో పెరుగుతుంది, కానీ ఇది సాధారణంగా ఊహించదగినది. ఇది జిమ్ మెంబర్షిప్ లాంటిది. మీరు ఒకసారి క్వెరీ చేసినా లేదా పదివేల సార్లు చేసినా, ప్రాథమిక ఇన్ఫ్రాస్ట్రక్చర్ ఖర్చు దాదాపు ఒకేలా ఉంటుంది.
లార్జ్ లాంగ్వేజ్ మోడల్స్ (LLMs) వినియోగ పన్ను వంటివి. ప్రతి యూజర్ ప్రశ్న ఒక బిల్లును ప్రేరేపిస్తుంది. మీ రిట్రీవల్ లేయర్ (retrieval layer) నుండి బయటకు వచ్చి ప్రాంప్ట్ (prompt) లోకి వెళ్లే ప్రతి టోకెన్ కూడా డబ్బును ఖర్చు చేస్తుంది. ప్రతి రీజనింగ్ స్టెప్, ప్రతి ఫార్మాటింగ్ ఇన్స్ట్రక్షన్, మోడల్ జనరేట్ చేయమని మీరు అడిగే ప్రతి సైటేషన్ (citation) కూడా ఖర్చును పెంచుతాయి. ఈ చిన్న చిన్న ఖర్చులు సెషన్ల సంఖ్యతో గుణించబడతాయి, మరియు సెషన్ల సంఖ్య నిరంతరం పెరుగుతూనే ఉంటుంది. ఇక్కడే లేటెన్సీ (latency) మరియు ఖర్చు రెండూ కలిసి పెరిగిపోతాయి. నెమ్మదైన క్వెరీ అనేది యూజర్కు ఇబ్బంది మాత్రమే కాదు; యూజర్ వేచి ఉన్నంత సేపు అది మీ డబ్బును ఖర్చు చేస్తూనే ఉంటుంది.
ఇవి ఒకే సమస్య యొక్క వివిధ రూపాలు కావు. ఇవి మూడు వేర్వేరు సమస్యలు. ఇంజెషన్ను చౌకగా చేయడం ద్వారా క్వెరీ సమయంలో అయ్యే ఖర్చును తగ్గించలేరు. అది పార్కింగ్ ఖర్చు తగ్గించుకోవడానికి కారు ఇంజిన్ను ట్యూన్ చేయడం వంటిది.
డబ్బు నిజంగా ఎక్కడ ఖర్చవుతోంది
మీరు ప్రొడక్షన్ RAG అప్లికేషన్ను నడుపుతుంటే, మీ కాస్ట్ ఎక్స్ప్లోరర్ (cost explorer) ఓపెన్ చేసి యూసేజ్ టైప్ (usage type) ద్వారా ఫిల్టర్ చేయండి. మీ ఎంబెడ్డింగ్ జాబ్ రోజుకు ఒకసారి స్థిరంగా ఉండవచ్చు, కానీ మీ LLM ఎండ్పాయింట్ (endpoint) ట్రాఫిక్తో పాటు హెచ్చుతగ్గులకు లోనవుతుందని నేను ఖచ్చితంగా చెప్పగలను. ఆ ప్యాటర్న్ మొత్తం కథను చెబుతుంది. మీ వెక్టర్లు నిద్రపోతాయి; కానీ యూజర్ ప్రతిసారి ప్రశ్న అడిగినప్పుడు మీ మోడల్ మేల్కొంటుంది.
ఈ అవగాహన నా ఇంజనీరింగ్ పనుల ప్రాధాన్యతలను మార్చేసింది. ఇంజెషన్ను ఎలా చౌకగా చేయాలి అని అడగడం మానేసి, ప్రతి ప్రశ్నను ఎలా చౌకగా చేయాలి అని అడగడం ప్రారంభించాను. ఈ మార్పు చాలా స్పష్టంగా అనిపించినప్పటికీ, చాలా టీమ్లు ఇంకా ఊహల ఆధారంగానే పనిచేస్తున్నాయి. వారు ఎంబెడ్డింగ్ దశ కోసం సంక్లిష్టమైన డూప్లికేషన్ లాజిక్ను (deduplication logic) నిర్మిస్తారు, కానీ ఆ తర్వాత LLMకి అనవసరమైన, అస్పష్టమైన కాంటెక్స్ట్ విండోలను (context windows) ఎటువంటి ఆలోచన లేకుండా పంపిస్తారు. పైకప్పు నుండి నీరు కారుతున్నా, వారు నేలను మెరుగుపరుస్తున్నట్లుగా ఉంది ఇది.
మీ పైప్లైన్ను దెబ్బతీయకుండా ఖర్చులను ఎలా తగ్గించాలి
RAG సిస్టమ్లో డబ్బు ఆదా చేయాలంటే, ఖర్చు నమూనాకు అనుగుణంగా వ్యూహాలను అమలు చేయాలి. నిజంగా పనిచేసే పద్ధతులు ఇక్కడ ఉన్నాయి.
ప్రాసెస్ చేసే ముందే డూప్లికేట్లను తొలగించండి
చాలా సంస్థల నాలెడ్జ్ బేస్లు (knowledge bases) నెమ్మదిగా మారుతుంటాయి. పాలసీలు, హ్యాండ్బుక్లు, పరిశోధన PDFలు మరియు ఆర్కైవ్ చేయబడిన నివేదికలు నెలల తరబడి మార్పు లేకుండా అలాగే ఉంటాయి. అనేక పైప్లైన్లలో, ఇంగెషన్ (ingestion) రన్ల మధ్య దాదాపు ఎనభై శాతం మూల పత్రాలు (source documents) ఒకేలా ఉంటాయి. అయినప్పటికీ, చాలా వ్యవస్థలు మొత్తం కార్పస్ (corpus)ను తొలగించి, షెడ్యూల్ ప్రకారం ఇండెక్స్ను మొదటి నుండి మళ్ళీ నిర్మిస్తాయి. అలా చేయకండి. మీ పైప్లైన్ ప్రవేశ ద్వారం వద్ద ఒక గేట్ను నిర్మించండి. వచ్చే ఫైళ్లను హాష్ (hash) చేయండి. చివరిసారి మార్చబడిన టైమ్స్టాంప్లను (timestamps) పోల్చండి. ఒక పత్రం మారకపోతే, దానిని పూర్తిగా వదిలేయండి. స్థిరమైన ఫైళ్లను (static files) మళ్ళీ ప్రాసెస్ చేయడం వల్ల కేవలం వృధా మాత్రమే జరుగుతుంది. ఇది కంప్యూట్ (compute) ఖర్చును పెంచుతుంది, అనవసరంగా SSDలను అరిగిస్తుంది మరియు మీ ఇంగెషన్ లాగ్లను (ingestion logs) తప్పుడు కార్యకలాపాలతో నింపుతుంది.
ఆచరణలో, ఫైల్ పాత్లను (file paths) చెక్సమ్స్తో (checksums) అనుసంధానించే ఒక తేలికపాటి మేనిఫెస్ట్ను (manifest) నిల్వ చేయండి. షెడ్యూలర్ రన్ అయినప్పుడు, మొదట మేనిఫెస్ట్ను తనిఖీ చేయనివ్వండి. మారిన తక్కువ సంఖ్యలో ఉన్న ఫైళ్లను మాత్రమే చంకర్ (chunker) ద్వారా పంపాలి.
పత్రాలను ప్యాచ్ చేయండి, వాటిని పూర్తిగా మార్చకండి
ఒక పత్రం మారినప్పుడు, దానిని కొత్త ఫైల్గా పరిగణించాలనే ఆలోచనను నివారించండి. యాభై పేజీల సాంకేతిక స్పెసిఫికేషన్ (technical spec)లో నాలుగవ విభాగంలో కేవలం రెండు పేరాగ్రాఫ్ల సవరణ మాత్రమే జరిగి ఉండవచ్చు. మీ పైప్లైన్ మొత్తం ఫైల్ను రీప్లేస్ చేస్తే, మీరు అనవసరంగా నలభై తొమ్మిది పేజీలను మళ్ళీ చంక్ (re-chunk) చేసి, రీ-ఎంబెడ్ (re-embed) చేయాల్సి వస్తుంది.
దానికి బదులుగా, కొత్త వెర్షన్ను పాత వెర్షన్తో పోల్చండి. మార్పులను (delta) గుర్తించండి. ఆ తర్వాత మారిన విభాగాలను మాత్రమే మళ్ళీ చంక్ చేసి, రీ-ఎంబెడ్ చేయండి. సరిహద్దులను (boundaries) గుర్తించడానికి పేజీ నంబర్లు, సెక్షన్ ఐడిలు (section IDs), హెడర్ యాంకర్లు (header anchors) లేదా పేరాగ్రాఫ్ రేంజ్ల వంటి మెటాడేటాను ఉపయోగించండి. మీ చంకింగ్ వ్యూహం (chunking strategy) పత్రం యొక్క నిర్మాణాన్ని గౌరవిస్తే, ఇది చాలా సులభం. ఒకవేళ అలా కాకపోతే, పెద్ద ఇన్ఫరెన్స్ క్లస్టర్ను (inference cluster) కొనుగోలు చేయడం కంటే మీ చంకర్ (chunker)ను సరిచేయడమే మంచి పెట్టుబడి. మీ పత్రాల సంఖ్య పెరిగే కొద్దీ, డిఫ్-అవేర్ (diff-aware) పైప్లైన్ను నిర్వహించడానికి అయ్యే ఇంజనీరింగ్ ఖర్చు కొన్ని వారాల్లోనే తిరిగి లాభదాయకంగా మారుతుంది.
పునరావృతమయ్యే ఖర్చులను నేరుగా ఎదుర్కోండి
ప్రతి క్వెరీ (query) వద్ద LLM కాల్స్ జరుగుతాయి కాబట్టి, కొన్ని టోకెన్లను (tokens) తగ్గించినా లేదా కొన్ని ప్రతిస్పందనలను (responses) క్యాష్ (cache) చేసినా భారీ లాభాలు ఉంటాయి. ప్రాంప్ట్ క్యాషింగ్తో (prompt caching) ప్రారంభించండి. ఒక వినియోగదారు మీ రీఫండ్ పాలసీ గురించి అడిగి, మరొకరు పది నిమిషాల తర్వాత అదే ప్రశ్న అడిగితే, మోడల్ను రెండుసార్లు పిలవాల్సిన అవసరం లేదు. సెమాంటిక్ సిమిలారిటీ మ్యాచింగ్ (semantic similarity matching) ద్వారా ఇటీవలి క్వెరీ-రెస్పాన్స్ జంటలను నిల్వ చేయండి. కొత్త ప్రశ్న క్యాష్ చేయబడిన ప్రశ్నకు దగ్గరగా (similarity threshold లోపల) ఉన్నప్పుడు, నిల్వ చేసిన సమాధానాన్ని నేరుగా అందించండి. దీనివల్ల టోకెన్లు ఖర్చు అవ్వవు, డాలర్లు వృధా కావు.
తర్వాత, మీ రిట్రీవల్ క్వాలిటీ (retrieval quality)ని జాగ్రత్తగా పరిశీలించండి. సరిగ్గా లేని రిట్రీవర్ (retriever), ఒక సూది కోసం గడ్డి కుప్పను వెతకమని LLMని బలవంతం చేసినట్లు అవుతుంది. మీ top-k కటాఫ్ (cutoff) చాలా ఎక్కువగా ఉండి, ప్రాంప్ట్లో ఇరవై అనవసరమైన చంక్స్ను నింపితే, మీరు అనవసరమైన సమాచారాన్ని (noise) చదవడానికి మోడల్కు డబ్బు చెల్లిస్తున్నట్లే. మీ రిట్రీవల్ను కచ్చితంగా చేయండి. మీ top-kని తగ్గించండి. చంక్స్ను పంపే ముందు వాటిని కంప్రెస్ (compress) చేయండి. ఇంగెషన్ సమయంలో బాయిలర్ప్లేట్ ఫుటర్లు (boilerplate footers) మరియు హెడర్లను తొలగించండి, తద్వారా అవి ప్రాంప్ట్కు చేరుకోవు. కాంటెక్స్ట్ విండో (context window) నుండి మీరు తొలగించే ప్రతి టోకెన్ కొద్దిపాటి ఖర్చును ఆదా చేస్తుంది, మరియు రోజువారీ వేలకొద్దీ క్వెరీల ద్వారా ఆ చిన్న మొత్తాలు కూడా పెద్ద మొత్తంగా మారుతాయి.
మెరుగైన రిట్రీవల్ వల్ల లేటెన్సీ (latency) కూడా తగ్గుతుంది, ఇది మరొక రకమైన ఖర్చు. నెమ్మదిగా ఉండే ఇంటర్ఫేస్లను వినియోగదారులు వదిలేస్తారు. వేగవంతమైన సమాధానం తక్కువ ఖర్చుతో కూడుకున్నది మరియు వినియోగదారులను నిలుపుకోవడానికి (retention) కూడా మంచిది.
అసలైన సారాంశం
ఖరీదైనదిగా అనిపించే వాటిని ఆప్టిమైజ్ చేయడం ఆపి, మీ ఇన్వాయిస్ (invoice) ప్రకారం ఖరీదైనవిగా ఉన్న వాటిని ఆప్టిమైజ్ చేయడం ప్రారంభించండి. ప్రతి దశను స్వతంత్రంగా కొలవండి. ఎంబెడ్డింగ్స్ (embeddings) తక్కువ ఖర్చుతో కూడుకున్నవి, వెక్టర్ స్టోరేజ్ (vector storage) స్థిరమైనది, మరియు 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.