इन 7 गलतियों को सुधारने से पहले मैंने RAG इंफ्रास्ट्रक्चर पर $500 खर्च किए
मैंने प्राइवेट डॉक्यूमेंट सर्च के लिए एक RAG पाइपलाइन बनाई। इसमें कंप्यूटिंग पर $500 और डिबगिंग में हफ्तों का समय लगा। परिणाम खराब थे। यूजर्स को गलत जवाब मिल रहे थे और क्वेरीज़ धीमी थीं।
मैंने पाइपलाइन का ऑडिट किया। मुझे 7 गलतियाँ मिलीं। उन्हें सुधारने से सब कुछ बदल गया।
- फिक्स्ड टोकन चंकिंग (Fixed Token Chunking) मैंने डॉक्यूमेंट्स को 512 टोकन के आधार पर विभाजित किया। इससे कॉन्टेक्स्ट (context) खत्म हो गया। एक API का स्पष्टीकरण वाक्य के बीच में ही कट जाता था। LLM को केवल टुकड़े मिलते थे और वह बेकार जवाब देता था। समाधान: Semantic chunking का उपयोग करें।
- पैराग्राफ या हेडर जैसी प्राकृतिक सीमाओं के आधार पर विभाजित करें।
- Parent-document retrieval का उपयोग करें।
- सर्च के लिए छोटे child chunks बनाएं।
- LLM को पूरा parent document वापस करें।
- चंक्स के बीच 10-20% ओवरलैप रखें।
- खराब हाइब्रिड सर्च वेट्स (Bad Hybrid Search Weights) मैंने वेक्टर और कीवर्ड सर्च के लिए 50/50 का अनुपात इस्तेमाल किया। तकनीकी डॉक्यूमेंट्स के लिए यह विफल रहा। तकनीकी यूजर्स को सटीक कीवर्ड मैच की आवश्यकता होती है। समाधान: डायनामिक वेट्स (dynamic weights) का उपयोग करें।
- तथ्यात्मक (Factual) क्वेरीज़: 35% वेक्टर, 65% कीवर्ड।
- सिमेंटिक (Semantic) क्वेरीज़: 75% वेक्टर, 25% कीवर्ड।
- सामान्य (General) क्वेरीज़: 60% वेक्टर, 40% कीवर्ड।
- HNSW पैरामीटर्स की ओवर-ट्यूनिंग (Over-tuning HNSW Parameters)
मैंने
ef_constructionको अधिकतम पर सेट कर दिया था। इससे मेरा सर्वर क्रैश हो गया। इसने उपलब्ध सारी RAM का उपयोग कर लिया। समाधान: उचित पैरामीटर्स का उपयोग करें।
- M को 8 और 32 के बीच सेट करें।
ef_constructionको 200 पर सेट करें।ef_searchको 50 पर सेट करें। मेमोरी का उपयोग 70% कम हो गया।
सामान्य एम्बेडिंग मॉडल्स (General Embedding Models) मैंने Wikipedia पर प्रशिक्षित मॉडल का उपयोग किया। मेरे डॉक्यूमेंट्स तकनीकी इंजीनियरिंग रनबुक्स (runbooks) थे। मॉडल मेरे डोमेन को नहीं समझ पा रहा था। समाधान: तकनीकी या कोड कंटेंट के लिए फाइन-ट्यून किए गए मॉडल का उपयोग करें।
क्वेरी रीराइटिंग (Query Rewriting) का न होना यूजर्स स्वाभाविक (natural) सवाल पूछते हैं। तकनीकी डॉक्यूमेंट्स में औपचारिक (formal) शब्दों का उपयोग होता है। वे आपस में मेल नहीं खाते। समाधान: क्वेरीज़ को रीराइट करने के लिए एक लाइटवेट LLM स्टेप जोड़ें।
- यूजर पूछता है: "why is my build slow"
- सिस्टम इसे रीराइट करता है: "CI pipeline performance optimization"
- इससे रिकॉल (recall) में 40% का सुधार हुआ।
अनावश्यक परिणाम (Redundant Results) टॉप-10 चंक्स को रिट्रीव करने पर अक्सर एक ही पैराग्राफ तीन बार मिल जाता था। LLM अपनी बात दोहरा रहा था। समाधान: परिणामों में विविधता सुनिश्चित करने के लिए Maximal Marginal Relevance (MMR) का उपयोग करें।
गलत चीज़ का परीक्षण करना (Testing the Wrong Thing) मैंने पूरी पाइपलाइन का एक साथ परीक्षण किया। मुझे यह पता नहीं चल पा रहा था कि समस्या रिट्रीवल (retrieval) में थी या LLM में। समाधान: रिट्रीवल इवैल्यूएशन (retrieval evaluation) को अलग करें।
- हिट रेट (hit rate) को ट्रैक करें।
- Mean Reciprocal Rank (MRR) को ट्रैक करें।
- 100 क्वेरी-डॉक्यूमेंट पेयर्स का एक टेस्ट सेट बनाएं।
सुधारों के बाद के परिणाम:
- उत्तर की प्रासंगिकता: 45% से 85%
- लेटेंसी: 3.2s से 1.8s
- मासिक लागत: $180 से $95
सबसे पहले chunking ठीक करें। फिर weights। फिर embedding quality।