𝗜 𝗦𝗽𝗲𝗻𝘁 $𝟱𝟬𝟬 𝗼𝗻 𝗥𝗔𝗚 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗕𝗲𝗳𝗼𝗿𝗲 𝗠𝗮𝗸𝗶𝗻𝗴 𝟳 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀

నేను ప్రైవేట్ డాక్యుమెంట్ సెర్చ్ కోసం ఒక RAG పైప్‌లైన్‌ను రూపొందించాను. దీని కోసం కంప్యూటింగ్ ఖర్చుగా $500 మరియు వారాల కొద్దీ డీబగ్గింగ్ పట్టింది. ఫలితాలు చాలా అధ్వాన్నంగా ఉన్నాయి. వినియోగదారులకు సంబంధం లేని సమాధానాలు వచ్చేవి మరియు క్వెరీల వేగం చాలా తక్కువగా ఉండేది.

నేను ఆ పైప్‌లైన్‌ను ఆడిట్ చేసి 7 సాధారణ తప్పులను గుర్తించాను. వాటిని సరిదిద్దడం వల్ల అంతా మారిపోయింది.

  1. ఫిక్స్‌డ్ టోకెన్ చంకింగ్ (Fixed Token Chunking) నేను డాక్యుమెంట్లను నిర్ణీత టోకెన్ల సంఖ్య ఆధారంగా విభజించాను. దీనివల్ల సందర్భం (context) దెబ్బతింది. ఒక వాక్యం మధ్యలోనే విడిపోవడం జరిగేది. LLM ముక్కలు ముక్కలుగా ఉన్న డేటాను అందుకుని, తప్పుడు సమాధానాలు ఇచ్చేది.
  • పరిష్కారం: పేరెంట్-డాక్యుమెంట్ రిట్రీవల్‌తో సెమాంటిక్ చంకింగ్‌ను (semantic chunking) ఉపయోగించండి.
  • పేరాగ్రాఫ్‌లు లేదా హెడర్‌ల వంటి సహజమైన సరిహద్దుల ద్వారా విభజించండి.
  • సెర్చ్ కోసం చిన్న చైల్డ్ చంక్‌లను (child chunks) సృష్టించండి.
  • మ్యాచ్ అయినప్పుడు పూర్తి పేరెంట్ డాక్యుమెంట్‌ను LLMకి పంపండి.
  • చంక్‌ల మధ్య 10-20% ఓవర్‌లాప్‌ను జోడించండి.
  1. డిఫాల్ట్ సెర్చ్ వెయిట్స్ (Default Search Weights) నేను వెక్టర్ మరియు కీవర్డ్ సెర్చ్ కోసం 50/50 నిష్పత్తిని ఉపయోగించాను. సాంకేతిక డాక్యుమెంట్ల విషయంలో, ఖచ్చితమైన కీవర్డ్‌లు చాలా ముఖ్యం.
  • పరిష్కారం: డైనమిక్ వెయిట్స్‌ను ఉపయోగించండి.
  • వాస్తవ సంబంధిత క్వెరీల కోసం (Factual queries): 35% వెక్టర్, 65% కీవర్డ్.
  • సెమాంటిక్ క్వెరీల కోసం (Semantic queries): 75% వెక్టర్, 25% కీవర్డ్.
  1. HNSW పారామితులను అతిగా ఆప్టిమైజ్ చేయడం నేను ef_constructionను గరిష్ట విలువకు సెట్ చేశాను. పెద్ద ఇండెక్స్ ఉన్నప్పుడు, ఇది నా సర్వర్‌ను క్రాష్ చేసి, మొత్తం RAMని వాడేసింది.
  • పరిష్కారం: తగిన HNSW సెట్టింగ్‌లను ఉపయోగించండి.
  • M విలువను 8 మరియు 32 మధ్య ఉంచండి.
  • ef_constructionను 200కి సెట్ చేయండి.
  • ef_searchను 50కి సెట్ చేయండి.
  1. తప్పు ఎంబెడ్డింగ్ మోడల్స్ (Wrong Embedding Models) నేను వెబ్ టెక్స్ట్ ఆధారంగా శిక్షణ పొందిన సాధారణ మోడల్‌ను ఉపయోగించాను. అది నా సాంకేతిక ఇంజనీరింగ్ డాక్యుమెంట్లను అర్థం చేసుకోలేకపోయింది.
  • పరిష్కారం: సాంకేతిక లేదా కోడ్ కంటెంట్ కోసం ఫైన్-ట్యూన్ చేయబడిన మోడల్‌కు మారండి.
  1. నేచురల్ లాంగ్వేజ్ మిస్‌మ్యాచ్ (Natural Language Mismatch) వినియోగదారులు "నా బిల్డ్ ఎందుకు నెమ్మదిగా ఉంది?" వంటి ప్రశ్నలు అడుగుతారు. కానీ డాక్యుమెంటేషన్‌లో "CI pipeline optimization" వంటి పదాలు ఉంటాయి. వీటి మధ్య ఎటువంటి సంబంధం లేదు.
  • పరిష్కారం: LLM క్వెరీ రీరైట్ (query rewrite) దశను జోడించండి.
  • సెర్చ్ చేసే ముందు వినియోగదారు క్వెరీని సాంకేతిక పదాలలోకి మార్చండి.
  1. అనవసరమైన సందర్భం (Redundant Context) టాప్ 10 చంక్‌లను రిట్రీవ్ చేయడం అంటే తరచుగా ఒకే పేరాగ్రాఫ్ మూడుసార్లు రావడం. దీనివల్ల హాలూసినేషన్స్ (hallucinations) ఏర్పడ్డాయి.
  • పరిష్కారం: ఫలితాలలో వైవిధ్యాన్ని (diversity) నిర్ధారించడానికి Maximal Marginal Relevance (MMR)ని ఉపయోగించండి.
  1. కేవలం ఎండ్-టు-ఎండ్ ఎవాల్యుయేషన్ మాత్రమే చేయడం నేను కేవలం చివరి సమాధానాన్ని మాత్రమే తనిఖీ చేశాను. సమస్య రిట్రీవల్‌లో ఉందా లేదా LLMలో ఉందా అనేది నాకు తెలియలేదు.
  • పరిష్కారం: రిట్రీవల్‌ను విడిగా ఎవాల్యుయేట్ చేయండి.
  • హిట్ రేట్ (hit rate) మరియు మీన్ రొసిప్రోకల్ ర్యాంక్ (MRR)ను ట్రాక్ చేయండి.
  • 100 క్వెరీ-డాక్యుమెంట్ జంటలతో ఒక టెస్ట్ సెట్‌ను రూపొందించండి.

పరిష్కారాల తర్వాత ఫలితాలు: • సమాధానం యొక్క సంబంధితత (Answer relevance): 45% నుండి 85% వరకు • క్వెరీ లాటెన్సీ (Query latency): 3.2s నుండి 1.8s వరకు • నెలవారీ ఖర్చు: $180 నుండి $95 వరకు

మొదట chunking సరిచేయండి. తర్వాత weights. ఆ తర్వాత embedding quality.

RAG విషయంలో మీకు ఎదురవుతున్న అతిపెద్ద సమస్య ఏమిటి? కామెంట్లలో తెలియజేయండి.

మూలం: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph

ఐచ్ఛిక అభ్యాస సమూహం: https://t.me/GyaanSetuAi