मैंने 7 गलतियाँ करने से पहले RAG इंफ्रास्ट्रक्चर पर $500 खर्च किए

मैंने प्राइवेट डॉक्यूमेंट सर्च के लिए एक RAG पाइपलाइन बनाई। इसमें कंप्यूटिंग पर $500 और डिबगिंग में हफ्तों का समय लगा। परिणाम खराब थे। यूजर्स को अप्रासंगिक (irrelevant) जवाब मिल रहे थे और क्वेरीज़ धीमी थीं।

मैंने पाइपलाइन का ऑडिट किया और 7 सामान्य गलतियाँ पाईं। उन्हें ठीक करने से सब कुछ बदल गया।

  1. फिक्स्ड टोकन चंकिंग (Fixed Token Chunking) मैंने फिक्स्ड टोकन काउंट के आधार पर डॉक्यूमेंट्स को विभाजित (split) किया। इससे कॉन्टेक्स्ट (context) खत्म हो गया। एक वाक्य बीच में से ही कट जाता था। LLM को खंडित (fragmented) डेटा मिलता था और वह खराब जवाब देता था।
  • समाधान: parent-document retrieval के साथ semantic chunking का उपयोग करें।
  • पैराग्राफ या हेडर जैसी प्राकृतिक सीमाओं (natural boundaries) के आधार पर विभाजित करें।
  • सर्च के लिए छोटे child chunks बनाएं।
  • मैच होने पर LLM को पूरा parent document वापस करें।
  • चंक्स के बीच 10-20% ओवरलैप रखें।
  1. डिफॉल्ट सर्च वेट्स (Default Search Weights) मैंने vector और keyword सर्च के लिए 50/50 का स्प्लिट इस्तेमाल किया। टेक्निकल डॉक्यूमेंट्स के लिए, सटीक कीवर्ड्स (exact keywords) अधिक महत्वपूर्ण होते हैं।
  • समाधान: डायनामिक वेट्स (dynamic weights) का उपयोग करें।
  • तथ्यात्मक (Factual) क्वेरीज़: 35% vector, 65% keyword.
  • सिमेंटिक (Semantic) क्वेरीज़: 75% vector, 25% keyword.
  1. HNSW पैरामीटर्स को ओवर-ऑप्टिमाइज़ करना मैंने ef_construction को अधिकतम वैल्यू पर सेट कर दिया था। एक बड़े इंडेक्स पर, इससे मेरा सर्वर क्रैश हो गया और मेरी पूरी RAM इस्तेमाल हो गई।
  • समाधान: उचित HNSW सेटिंग्स का उपयोग करें।
  • M को 8 और 32 के बीच रखें।
  • ef_construction को 200 पर सेट करें।
  • ef_search को 50 पर सेट करें।
  1. गलत एम्बेडिंग मॉडल्स (Wrong Embedding Models) मैंने वेब टेक्स्ट पर प्रशिक्षित (trained) एक जनरल मॉडल का उपयोग किया। वह मेरे टेक्निकल इंजीनियरिंग डॉक्यूमेंट्स को नहीं समझ पा रहा था।
  • समाधान: टेक्निकल या कोड कंटेंट के लिए फाइन-ट्यून (fine-tuned) किए गए मॉडल पर स्विच करें।
  1. नेचुरल लैंग्वेज मिसमैच (Natural Language Mismatch) यूजर्स "why is my build slow" जैसे सवाल पूछते हैं। जबकि डॉक्यूमेंटेशन में "CI pipeline optimization" जैसे शब्दों का उपयोग होता है। दोनों के बीच कोई समानता नहीं थी।
  • समाधान: एक LLM क्वेरी रीराइट (query rewrite) स्टेप जोड़ें।
  • सर्च करने से पहले यूजर की क्वेरी को टेक्निकल शब्दों में बदलें (rewrite करें)।
  1. अनावश्यक कॉन्टेक्स्ट (Redundant Context) टॉप 10 चंक्स को रिट्रीव करने का मतलब अक्सर एक ही पैराग्राफ को तीन बार प्राप्त करना होता था। इससे हैलुसिनेशन (hallucinations) की समस्या हुई।
  • समाधान: परिणामों में विविधता सुनिश्चित करने के लिए Maximal Marginal Relevance (MMR) का उपयोग करें।
  1. केवल एंड-टू-एंड इवैल्यूएशन (End-to-End Evaluation Only) मैंने केवल अंतिम उत्तर की जाँच की। मुझे यह पता नहीं था कि समस्या रिट्रीवल (retrieval) में थी या LLM में।
  • समाधान: रिट्रीवल का अलग से मूल्यांकन (evaluate) करें।
  • हिट रेट (hit rate) और Mean Reciprocal Rank (MRR) को ट्रैक करें।
  • 100 क्वेरी-डॉक्यूमेंट पेयर्स का एक टेस्ट सेट बनाएं।

सुधार के बाद के परिणाम: • उत्तर की प्रासंगिकता (Answer relevance): 45% से 85% • क्वेरी लेटेंसी (Query latency): 3.2s से 1.8s • मासिक लागत (Monthly cost): $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