𝗜 𝗦𝗽𝗲𝗻𝘁 $𝟱𝟬𝟬 𝗼𝗻 𝗥𝗔𝗚 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗕𝗲𝗳𝗼𝗿𝗲 𝗙𝗶𝘅𝗶𝗻𝗴 𝗧𝗵𝗲𝘀𝗲 𝟳 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀
నేను ప్రైవేట్ డాక్యుమెంట్ సెర్చ్ కోసం ఒక RAG పైప్లైన్ను రూపొందించాను. దీని కోసం కంప్యూటింగ్ ఖర్చుగా $500 మరియు వారాల కొద్దీ డీబగ్గింగ్ పట్టింది. ఫలితాలు చాలా అధ్వాన్నంగా ఉన్నాయి. వినియోగదారులకు తప్పు సమాధానాలు వచ్చాయి మరియు క్వెరీల వేగం చాలా తక్కువగా ఉంది.
నేను ఆ పైప్లైన్ను ఆడిట్ చేశాను. అందులో 7 తప్పులను గుర్తించాను. వాటిని సరిదిద్దడం వల్ల అంతా మారిపోయింది.
- ఫిక్స్డ్ టోకెన్ చంకింగ్ (Fixed Token Chunking) నేను డాక్యుమెంట్లను 512 టోకెన్ల చొప్పున విడగొట్టాను. దీనివల్ల సందర్భం (context) దెబ్బతింది. ఒక API వివరణ మధ్యలోనే విడిపోతోంది. LLM ముక్కలు ముక్కలుగా సమాచారాన్ని అందుకుని, అర్థం లేని సమాధానాలను ఇచ్చింది. పరిష్కారం: సెమాంటిక్ చంకింగ్ (semantic chunking) ఉపయోగించండి.
- పేరాగ్రాఫ్లు లేదా హెడర్ల వంటి సహజమైన సరిహద్దుల ద్వారా విడగొట్టండి.
- పేరెంట్-డాక్యుమెంట్ రిట్రీవల్ (parent-document retrieval) ఉపయోగించండి.
- సెర్చ్ కోసం చిన్న చైల్డ్ చంక్లను (child chunks) సృష్టించండి.
- పూర్తి పేరెంట్ డాక్యుమెంట్ను LLMకి పంపండి.
- చంక్ల మధ్య 10-20% ఓవర్ల్యాప్ను జోడించండి.
- తప్పు హైబ్రిడ్ సెర్చ్ వెయిట్స్ (Bad Hybrid Search Weights) నేను వెక్టర్ మరియు కీవర్డ్ సెర్చ్ కోసం 50/50 నిష్పత్తిని ఉపయోగించాను. ఇది టెక్నికల్ డాక్యుమెంట్లకు పనికిరాదు. టెక్నికల్ వినియోగదారులకు ఖచ్చితమైన కీవర్డ్ మ్యాచింగ్ అవసరం. పరిష్కారం: డైనమిక్ వెయిట్స్ను (dynamic weights) ఉపయోగించండి.
- వాస్తవ సంబంధిత క్వెరీల కోసం (Factual queries): 35% వెక్టర్, 65% కీవర్డ్.
- సెమాంటిక్ క్వెరీల కోసం (Semantic queries): 75% వెక్టర్, 25% కీవర్డ్.
- సాధారణ క్వెరీల కోసం (General queries): 60% వెక్టర్, 40% కీవర్డ్.
- HNSW పారామీటర్లను అతిగా ట్యూన్ చేయడం (Over-tuning HNSW Parameters) నేను ef_constructionను గరిష్ట స్థాయికి సెట్ చేశాను. దీనివల్ల నా సర్వర్ క్రాష్ అయింది. ఇది అందుబాటులో ఉన్న మొత్తం RAMని ఉపయోగించుకుంది. పరిష్కారం: తగిన పారామీటర్లను ఉపయోగించండి.
- Mని 8 మరియు 32 మధ్య సెట్ చేయండి.
- ef_constructionను 200కి సెట్ చేయండి.
- ef_searchను 50కి సెట్ చేయండి. మెమరీ వినియోగం 70% తగ్గింది.
సాధారణ ఎంబెడ్డింగ్ మోడల్స్ (General Embedding Models) నేను వికీపీడియాపై శిక్షణ పొందిన మోడల్ను ఉపయోగించాను. కానీ నా డాక్యుమెంట్లు టెక్నికల్ ఇంజనీరింగ్ రన్బుక్స్ (engineering runbooks). ఆ మోడల్కు నా డొమైన్ గురించి అవగాహన లేదు. పరిష్కారం: టెక్నికల్ లేదా కోడ్ కంటెంట్ కోసం ఫైన్-ట్యూన్ చేసిన మోడల్ను ఉపయోగించండి.
క్వెరీ రీరైటింగ్ లేకపోవడం (No Query Rewriting) వినియోగదారులు సహజమైన ప్రశ్నలు అడుగుతారు. టెక్నికల్ డాక్యుమెంట్లు ఫార్మల్ పదాలను ఉపయోగిస్తాయి. ఇవి ఒకదానికొకటి సరిపోవు. పరిష్కారం: క్వెరీలను రీరైట్ చేయడానికి ఒక లైట్వెయిట్ LLM స్టెప్ను జోడించండి.
- వినియోగదారు అడిగేది: "why is my build slow"
- సిస్టమ్ రీరైట్ చేసేది: "CI pipeline performance optimization"
- ఇది రీకాల్ (recall)ను 40% మెరుగుపరిచింది.
అనవసరమైన ఫలితాలు (Redundant Results) టాప్-10 చంక్లను రిట్రీవ్ చేసినప్పుడు తరచుగా ఒకే పేరాగ్రాఫ్ మూడుసార్లు వచ్చేది. దీనివల్ల LLM ఒకే విషయాన్ని మళ్ళీ మళ్ళీ చెప్పేది. పరిష్కారం: ఫలితాలలో వైవిధ్యం (diversity) ఉండేలా చూడటానికి Maximal Marginal Relevance (MMR)ని ఉపయోగించండి.
తప్పు అంశాన్ని పరీక్షించడం (Testing the Wrong Thing) నేను మొత్తం పైప్లైన్ను ఒకేసారి పరీక్షించాను. సమస్య రిట్రీవల్లో ఉందో లేక LLMలో ఉందో నాకు తెలియలేదు. పరిష్కారం: రిట్రీవల్ ఎవాల్యుయేషన్ను (retrieval evaluation) విడిగా చేయండి.
- హిట్ రేట్ (hit rate)ను ట్రాక్ చేయండి.
- మీన్ రికిప్రోకల్ ర్యాంక్ (MRR)ను ట్రాక్ చేయండి.
- 100 క్వెరీ-డాక్యుమెంట్ జంటలతో ఒక టెస్ట్ సెట్ను రూపొందించండి.
సవరణల తర్వాత ఫలితాలు:
- సమాధానం యొక్క సంబంధితత: 45% నుండి 85%
- లాటెన్సీ: 3.2s నుండి 1.8s
- నెలవారీ ఖర్చు: $180 నుండి $95
మొదట chunking సరి చేయండి. తర్వాత weights. ఆపై embedding quality.