భారీ స్థాయిలో ప్రొడక్షన్ RAG: రోజువారీ 10,000+ లిస్టింగ్ల నుండి నేర్చుకున్న పాఠాలు
నేను ఒక జాబ్ బోర్డ్ కోసం RAG పైప్లైన్ను రూపొందించాను. ఇది స్టేజింగ్లో బాగా పనిచేసింది కానీ రియల్ లోడ్ (real load) కింద ఇబ్బంది పడింది. రోజువారీ వేలాది లిస్టింగ్లను ప్రాసెస్ చేయడానికి కేవలం ఒక మంచి వెక్టర్ స్టోర్ మాత్రమే సరిపోదు. సిస్టమ్ ఎక్కడ విఫలమవుతుందో మీరు అర్థం చేసుకోవాలి.
చంకింగ్ (chunking), ఎంబెడ్డింగ్స్ (embeddings), ఖర్చులు మరియు అబ్జర్వబిలిటీ (observability) గురించి నా పాఠాలు ఇక్కడ ఉన్నాయి.
1. మీ చంకింగ్ వ్యూహాన్ని ఊహించకండి
చాలా ట్యుటోరియల్స్ చంకింగ్ను ఒక సాధారణ సెట్టింగ్గా పరిగణిస్తాయి. కానీ ప్రొడక్షన్లో, మీ వ్యూహమే ఖచ్చితత్వాన్ని మరియు ఖర్చును నిర్ణయిస్తుంది.
జాబ్ లిస్టింగ్ల కోసం నేను మూడు పద్ధతులను పరీక్షించాను:
- Fixed-size chunks: ఇవి విఫలమయ్యాయి. ఇవి "requirements" మరియు "benefits" వంటి విభాగాలను యాదృచ్ఛికంగా (random points) విడగొట్టాయి. దీనివల్ల రిట్రీవల్ (retrieval) లో తప్పులు వచ్చే అవకాశం ఉంది.
- Semantic chunking: ఇది మెరుగ్గా ఉంది కానీ స్థిరంగా లేదు. కొన్ని చంక్స్ చాలా పొడవుగా, మరికొన్ని చాలా తక్కువగా ఉన్నాయి.
- Recursive character splitting with overlap: ఇది బాగా పనిచేసింది. నేను కొత్త లైన్లు (newlines) మరియు వాక్యాల ఆధారంగా విడగొట్టాను. నేను 400 టోకెన్ సైజు మరియు 50 టోకెన్ ఓవర్లాప్ను ఉపయోగించాను. దీనివల్ల రెండు చంక్స్లో విస్తరించి ఉన్న వాక్యాలు విడిపోకుండా కలిసి ఉంటాయి.
ప్రో టిప్ (Pro tip): చంకింగ్ చేసే ముందు మీ డేటాను నార్మలైజ్ (Normalize) చేయండి. Greenhouse లేదా Lever వంటి వివిధ మూలాలు (sources) వేర్వేరు ఫార్మాట్లను అందిస్తాయి. మీ చంకర్ ఒక స్థిరమైన నిర్మాణాన్ని చూసేలా ముందుగా టెక్స్ట్ను క్లీన్ చేయండి.
2. ఎంబెడ్డింగ్స్: ఖర్చు vs. ఖచ్చితత్వం
నేను Ollama ద్వారా Llama 3.1 ని OpenAI text-embedding-3-small తో పోల్చి పరీక్షించాను. లోకల్ మోడల్ ఉచితం కానీ "equity compensation" వంటి డొమైన్-స్పెసిఫిక్ పదాలతో ఇబ్బంది పడింది. ఇది తప్పుడు ఫలితాలను ఇచ్చింది. OpenAI ఖర్చుతో కూడుకున్నది కానీ ఖచ్చితమైన ఫలితాలను ఇచ్చింది. తప్పుడు రిట్రీవల్ వల్ల తర్వాత LLM కాల్స్లో ఎక్కువ ఖర్చు అవుతుంది కాబట్టి నేను OpenAIని ఎంచుకున్నాను.
సమయాన్ని ఆదా చేయడానికి, నేను నా రిక్వెస్ట్లను బ్యాచ్ (batch) చేస్తాను. నేను ఒకే కాల్లో 100 చంక్స్ వరకు పంపిస్తాను. ఇది లేటెన్సీని (latency) తగ్గిస్తుంది మరియు పైప్లైన్ను వేగంగా ఉంచుతుంది.
3. వెక్టర్ స్టోర్ ట్రేడ్-ఆఫ్ (Trade-off)
ప్రోటోటైపింగ్ కోసం నేను Pinecone ఉపయోగించాను ఎందుకంటే దానిని సెటప్ చేయడం వేగంగా ఉంటుంది. అయితే, భారీ స్థాయిలో (at scale), ఖర్చులు చాలా పెరిగిపోయాయి.
నేను PostgreSQL లోని pgvector కి మారాను.
- దీనిని సెటప్ చేయడం కొంచెం కష్టమైన పని.
- ఇది భారీ మొత్తంలో డబ్బును ఆదా చేసింది.
- ఇది ట్రాన్సాక్షనల్ కన్సిస్టెన్సీని (transactional consistency) అందించింది.
ఎంబెడ్డింగ్స్ మరియు జాబ్ డేటా రెండూ ఒకే డేటాబేస్లో ఉండటం వల్ల, మీకు ఒకే 'సోర్స్ ఆఫ్ ట్రూత్' (source of truth) ఉంటుంది. మీరు రెండు వేర్వేరు సిస్టమ్లను సింక్ (sync) చేయాల్సిన అవసరం లేదు.
4. LLM ఖర్చులను నియంత్రించడం
ప్రతి లిస్టింగ్ను GPT-4o తో స్కోరింగ్ చేయడం ఖర్చుతో కూడుకున్నది. ఖర్చులను తగ్గించడానికి నేను మూడు పద్ధతులను ఉపయోగించాను:
- OpenAI Batch API: నేను స్కోరింగ్ పనులను రాత్రిపూట ప్రాసెస్ చేస్తాను. ఇది పెద్ద మొత్తంలో డిస్కౌంట్ను అందిస్తుంది.
- Caching: పునరావృతమయ్యే అభ్యర్థి ప్రొఫైల్స్ కోసం నేను ఫలితాలను క్యాష్ (cache) చేస్తాను.
- Model tiering: "Sales Representative" వంటి సాధారణ పాత్రల కోసం నేను GPT-4o-miniని ఉపయోగిస్తాను. ఖచ్చితత్వం చాలా ముఖ్యమైన నిచ్ (niche) పాత్రల కోసం మాత్రమే నేను GPT-4oని ఉపయోగిస్తాను.
5. మొదట అబ్జర్వబిలిటీని (Observability) నిర్మించండి
నా పైప్లైన్ ఒకసారి ఎటువంటి ఎర్రర్ చూపకుండానే విఫలమైంది. తప్పుగా ఉన్న డేటా (malformed data) వల్ల ఖాళీ చంక్స్ ఏర్పడ్డాయి, వాటిని సిస్టమ్ ఎర్రర్ లేకుండానే స్కిప్ చేసింది.
దీనిని నేను ఒక కోరిలేషన్ ఐడి (correlation ID) తో స్ట్రక్చర్డ్ లాగింగ్ను జోడించడం ద్వారా పరిష్కరించాను. ఇది ఒక లిస్టింగ్ను ఇంగెషన్ (ingestion) నుండి స్కోరింగ్ వరకు ట్రాస్ చేయడానికి నాకు అనుమతించింది. ఏ డేటా సోర్స్ల వల్ల వైఫల్యాలు వస్తున్నాయో నేను చివరకు చూడగలిగాను.
అతిపెద్ద పాఠం: చాలా సమస్యలు AI వల్ల కాకుండా, అస్తవ్యస్తమైన డేటా (messy data) వల్ల వస్తాయి. ముందుగా మీ డేటా ప్లంబింగ్ను (data plumbing) సరిచేయండి.
Optional learning community: https://t.me/GyaanSetuAi