आपने एक RAG सिस्टम भेज दिया है। यह काम करता है... अधिकतर। कभी-कभी उत्तर प्रभावशाली रूप से अच्छे होते हैं। कभी-कभी यह आत्मविश्वास से कुछ ऐसा कहता है जो पूरी तरह से गलत है, एक दस्तावेज़ का हवाला देते हुए जो यह नहीं कहता है कि मॉडल क्या दावा करता है। और कभी-कभी यह उत्तर पूरी तरह से चूक जाता है, भले ही सही दस्तावेज़ आपके ज्ञानकोष में वहीं बैठा हो।
यह उत्पादन RAG प्रणाली की सामान्य स्थिति है। सवाल यह नहीं है कि क्या आपके पास गुणवत्ता संबंधी समस्याएं हैं - आपके पास हैं - सवाल यह है कि क्या आपके पास उन्हें ढूंढने और ठीक करने का कोई व्यवस्थित तरीका है। RAG रेट्रोस्पेक्टिव इसी के लिए हैं: नियमित रूप से जांच करना कि आपकी पाइपलाइन कहां टूटती है और अनुमान लगाने के बजाय लक्षित सुधार करना।
क्यों RAG सिस्टम को अपने स्वयं के रेट्रोस्पेक्टिव की आवश्यकता है
RAG एक सिस्टम नहीं है. यह घटकों की एक श्रृंखला है, और प्रत्येक लिंक की गुणवत्ता अंतिम आउटपुट निर्धारित करती है। जब उत्तर ख़राब हो, तो विफलता कहीं भी हो सकती है:
- घूस: दस्तावेज़ों को गलत तरीके से पार्स किया गया था, टुकड़ों को गलत स्थानों पर विभाजित किया गया था, मेटाडेटा खो गया था
- बहाली: खोज क्वेरी सही दस्तावेज़ों से मेल नहीं खाती, एम्बेडिंग मॉडल सिमेंटिक कनेक्शन से चूक गया, आपका टॉप-के बहुत छोटा या बहुत बड़ा था
- प्रसंग संयोजन: पुनर्प्राप्त खंड व्यक्तिगत रूप से प्रासंगिक थे लेकिन एक-दूसरे का खंडन करते थे, या संदर्भ विंडो शोर से भरी हुई थी
- पीढ़ी: मॉडल अच्छे संदर्भ के बावजूद मतिभ्रम करता है, या इसने अपने पैरामीट्रिक ज्ञान के पक्ष में प्रासंगिक संदर्भ को नजरअंदाज कर दिया है
मानक सॉफ़्टवेयर रेट्रोस्पेक्टिव इन विफलता मोड को सुलझाने के लिए सुसज्जित नहीं हैं। आपको एक ऐसे प्रारूप की आवश्यकता है जो विफलता के वास्तविक बिंदु को खोजने के लिए पाइपलाइन के माध्यम से खराब आउटपुट का पता लगाता है। अन्यथा जब वास्तविक समस्या खंडित हो रही थी तो आप पुनर्प्राप्ति को "ठीक" कर रहे थे, या जब वास्तविक समस्या पुनर्प्राप्ति थी तब संकेतों को फिर से लिख रहे थे।
ट्रैकिंग के लायक मेट्रिक्स
RAG रेट्रोस्पेक्टिव चलाने से पहले, आपको डेटा की आवश्यकता है। सभी संभावित मेट्रिक्स नहीं - केवल सबसे सामान्य विफलता मोड का निदान करने के लिए पर्याप्त हैं।
पुनर्प्राप्ति गुणवत्ता
परिशुद्धता@के:पुनर्प्राप्त किए गए K दस्तावेज़ों में से कितने वास्तव में प्रासंगिक थे? यदि आप 10 टुकड़े वापस खींच रहे हैं और केवल 2 उपयोगी हैं, तो आप संदर्भ विंडो को शोर से भर रहे हैं।
स्मरण@K:आपके ज्ञानकोष में मौजूद सभी प्रासंगिक दस्तावेज़ों में से कितने आपके शीर्ष-K परिणामों में शामिल हुए? कम स्मरण का मतलब है कि सही उत्तर मौजूद हैं लेकिन आपकी पुनर्प्राप्ति उन्हें नहीं ढूंढ पा रही है।
एमआरआर (मीन रेसिप्रोकल रैंक):आपकी रैंकिंग में पहला प्रासंगिक परिणाम कहाँ दिखाई देता है? यदि सबसे अच्छा दस्तावेज़ लगातार स्थान 1 के बजाय 5 स्थान पर है, तो आपकी रैंकिंग को काम करने की ज़रूरत है, भले ही रिकॉल ठीक हो।
आपको अपने संपूर्ण ज्ञानकोष में इनकी गणना करने की आवश्यकता नहीं है। हाल के 50-100 प्रश्नों का नमूना लें, एक मानव न्यायाधीश से पूछें कि कौन से दस्तावेज़ प्रासंगिक थे, और वहां से गणना करें। ऐसा मासिक करें.
पीढ़ी की गुणवत्ता
वफ़ादारी:क्या उत्पन्न उत्तर वास्तव में दर्शाता है कि पुनर्प्राप्त दस्तावेज़ क्या कहते हैं? यह मतिभ्रम का प्रश्न है. आप प्रदान किए गए संदर्भ के विरुद्ध आउटपुट की तुलना करके इसकी स्पॉट-चेक कर सकते हैं।
उत्तर प्रासंगिकता:क्या प्रतिक्रिया वास्तव में उस प्रश्न का उत्तर देती है जो पूछा गया था? पुनर्प्राप्त दस्तावेज़ों का एक पूरी तरह से विश्वसनीय सारांश उत्पन्न करना संभव है जो उपयोगकर्ता के इरादे को पूरी तरह से अनदेखा कर देता है।
प्रसंग उपयोग:जब सही जानकारी पुनर्प्राप्त संदर्भ में होती है, तो क्या मॉडल वास्तव में इसका उपयोग करता है? यदि आप लगातार अच्छे दस्तावेज़ पुनर्प्राप्त कर रहे हैं और मॉडल उन्हें अनदेखा कर रहा है, तो यह एक पीढ़ी-पक्ष की समस्या है (आमतौर पर एक संकेत देने वाली समस्या)।
ऑपरेशनल मेट्रिक्स
विलंबता:पूरी पाइपलाइन को क्वेरी से प्रतिक्रिया तक कितना समय लगता है? इसे घटक के आधार पर तोड़ें ताकि आप जान सकें कि पुनर्प्राप्ति या उत्पादन बाधा है या नहीं।
प्रति क्वेरी लागत:टोकन उपयोग और एपीआई लागत को ट्रैक करें। कुछ गुणवत्ता सुधार (जैसे संदर्भ विंडो का विस्तार या पुनः रैंकिंग) लागत में उल्लेखनीय वृद्धि करते हैं।
रेट्रोस्पेक्टिव चलाना
तैयारी (बैठक से पहले)
किसी को "विफलता नमूना" तैयार करने के लिए नियुक्त करें - 10-15 हालिया प्रश्न जहां आउटपुट गलत था या खराब गुणवत्ता वाला था। प्रत्येक के लिए, संपूर्ण पाइपलाइन स्थिति कैप्चर करें: मूल क्वेरी, क्या पुनर्प्राप्त किया गया था, मॉडल को कौन सा संदर्भ भेजा गया था, और मॉडल ने क्या उत्पन्न किया था। यह निशान जरूरी है. इसके बिना, आप अंधे डिबगिंग कर रहे हैं।
अपने मीट्रिक रुझान भी तैयार करें. क्या पिछले रेट्रो के बाद से चीज़ें बेहतर या बदतर हो रही हैं? कोई तीव्र परिवर्तन?
बैठक (60 मिनट)
मीट्रिक समीक्षा (10 मिनट)।पुनर्प्राप्ति और पीढ़ी मेट्रिक्स के माध्यम से चलें। रुझानों और आश्चर्यों पर ध्यान दें, न कि संख्या-दर-संख्या सुनाने पर। "Precision@5 इस महीने 0.72 से गिरकर 0.58 हो गया" उपयोगी है। डैशबोर्ड से प्रत्येक मीट्रिक को पढ़ना आसान नहीं है।
विफलता विश्लेषण (35 मिनट)।यह रेट्रो का मूल है. विफलता का नमूना लें और प्रत्येक को इस आधार पर वर्गीकृत करें कि पाइपलाइन कहां टूटी:
- पुनर्प्राप्ति विफलता: सही दस्तावेज़ पुनर्प्राप्त नहीं किए गए। क्यों? प्रश्न-दस्तावेज़ बेमेल? एंबेडिंग मॉडल सीमा? मेटाडेटा फ़िल्टरिंग बहुत आक्रामक है?
- चंकिंग विफलता: सही दस्तावेज़ पुनर्प्राप्त किया गया था, लेकिन खंड सीमाओं ने उत्तर को दो खंडों में विभाजित कर दिया और केवल एक ही लौटाया गया। या वह हिस्सा बहुत बड़ा था और अप्रासंगिक सामग्री से पतला था।
- प्रसंग विफलता: अच्छे हिस्से पुनर्प्राप्त किए गए, लेकिन संदर्भ विंडो ऑर्डरिंग या ट्रंकेशन ने महत्वपूर्ण जानकारी खो दी। या परस्पर विरोधी टुकड़ों ने मॉडल को भ्रमित कर दिया।
- पीढ़ी की विफलता: अच्छा संदर्भ प्रदान किया गया था, लेकिन मॉडल ने फिर भी मतिभ्रम किया, संदर्भ को नजरअंदाज कर दिया, या दस्तावेज़ों में उपलब्ध विशिष्ट के बजाय अस्पष्ट उत्तर दिया।
प्रत्येक विफलता के लिए, पूछें: "सबसे सस्ता उपाय क्या है जो इसे पकड़ लेता या रोक देता?" कभी-कभी यह एक त्वरित बदलाव होता है। कभी-कभी यह किसी विशिष्ट दस्तावेज़ को पुनः खंडित कर रहा होता है। कभी-कभी यह एक प्रणालीगत परिवर्तन होता है।
प्राथमिकताएँ और कार्य आइटम (15 मिनट)।विफलताओं को मूल कारण के आधार पर समूहित करें। जिस पैटर्न के कारण सबसे अधिक विफलताएँ हुईं, उस पर सबसे अधिक ध्यान दिया जाता है। अगले रेट्रो से पहले लागू करने के लिए 2-3 सुधार चुनें।
सामान्य विफलता पैटर्न और सुधार
यहां वे पैटर्न दिए गए हैं जिन्हें आप अक्सर देखेंगे और प्रत्येक के लिए व्यावहारिक दृष्टिकोण:
"सही दस्तावेज़ हमारे ज्ञानकोष में है लेकिन पुनर्प्राप्ति से वह छूट जाता है।"यह आमतौर पर एक एम्बेडिंग समानता समस्या है। उपयोगकर्ता की क्वेरी स्रोत दस्तावेज़ से भिन्न शब्दावली का उपयोग करती है। सुधार: एक क्वेरी विस्तार चरण जोड़ें (उपयोगकर्ता की क्वेरी को कई वाक्यांशों में फिर से लिखें), हाइब्रिड खोज लागू करें (बीएम25 जैसे कीवर्ड मिलान के साथ सिमेंटिक एम्बेडिंग को संयोजित करें), या खोज स्थान को सीमित करने के लिए अपने मेटाडेटा फ़िल्टरिंग में सुधार करें।
"हम सही दस्तावेज़ तो हासिल कर लेते हैं लेकिन ग़लत हिस्सा।"आपकी तोड़-फोड़ की रणनीति अधिकांश टीमों की समझ से कहीं अधिक मायने रखती है। यदि आप निश्चित आकार के चंकिंग (उदाहरण के लिए, 500 टोकन) का उपयोग कर रहे हैं, तो आप लगभग निश्चित रूप से महत्वपूर्ण सामग्री को सीमाओं के पार विभाजित कर रहे हैं। सुधार: सिमेंटिक चंकिंग (विषय परिवर्तन के आधार पर विभाजन) का उपयोग करें, चंक ओवरलैप जोड़ें, पदानुक्रमित चंकिंग का प्रयास करें जहां बड़े मूल भाग छोटे बच्चे के खंड के लिए संदर्भ प्रदान करते हैं।
"मॉडल अच्छे संदर्भ को नजरअंदाज करता है और बातें बनाता है।"यह एक प्रेरक और मॉडल व्यवहार मुद्दा है। मॉडल का पैरामीट्रिक ज्ञान दिए गए संदर्भ के साथ विरोधाभासी है, और पैरामीट्रिक ज्ञान जीत रहा है। सुधार: मॉडल को केवल दिए गए संदर्भ का उपयोग करने के लिए स्पष्ट रूप से निर्देश देने के लिए अपने सिस्टम प्रॉम्प्ट को समायोजित करें, "यदि संदर्भ में उत्तर नहीं है, तो कहें" निर्देश जोड़ें, मॉडल के तापमान को कम करने पर विचार करें।
"उत्तर सही हैं लेकिन बहुत धीमे हैं।"विलंबता की समस्याएँ आमतौर पर तीन स्थानों में से एक से आती हैं: बहुत अधिक पुनर्प्राप्ति कॉल, बहुत बड़ी संदर्भ विंडो (अधिक टोकन = धीमी पीढ़ी), या पुन: रैंकिंग चरण जो प्रसंस्करण समय जोड़ते हैं। अपने पाइपलाइन घटक को घटक द्वारा प्रोफ़ाइल करें। समाधान इस बात पर निर्भर करता है कि समय कहां जा रहा है।
"गुणवत्ता असंगत है - कुछ विषयों के लिए बढ़िया, दूसरों के लिए भयानक।"इसका आम तौर पर मतलब यह है कि आपके ज्ञान आधार के कुछ हिस्से दूसरों की तुलना में बेहतर अनुक्रमित हैं। हो सकता है कि कुछ दस्तावेज़ों को ख़राब ढंग से पार्स किया गया हो, या कुछ विषयों में पर्याप्त कवरेज का अभाव हो। विषय क्षेत्र के आधार पर अपनी विफलताओं का मानचित्र बनाएं और आपको कमियाँ मिलेंगी।
सतत सुधार लूप का निर्माण
सबसे प्रभावी RAG टीमें अपने सिस्टम को एक प्रोजेक्ट की तरह नहीं, बल्कि एक उत्पाद की तरह मानती हैं। यह कभी भी "पूरा" नहीं हुआ। प्रत्येक ⟦रेट्रो⟧ में वृद्धिशील सुधार होना चाहिए, और उन सुधारों को अगले रेट्रो में मापने योग्य होना चाहिए।
एक व्यावहारिक ताल:
- साप्ताहिक: स्वचालित गुणवत्ता मेट्रिक्स की त्वरित समीक्षा (एसिंक हो सकती है, बस डैशबोर्ड की जांच करें)
- द्वि-साप्ताहिक या मासिक: विफलता विश्लेषण के साथ पूर्ण ⟦रेट्रो⟧
- त्रैमासिक: बड़े वास्तुशिल्प निर्णय - क्या हमें एम्बेडिंग मॉडल बदलना चाहिए, अपने ज्ञान आधार का पुनर्गठन करना चाहिए, एक नई चंकिंग रणनीति अपनानी चाहिए?
आपने क्या प्रयास किया है और इसका क्या प्रभाव पड़ा, इसका एक चालू दस्तावेज़ रखें। RAG अनुकूलन पुनरावृत्तीय और अरेखीय है - आप कभी-कभी उन दृष्टिकोणों पर दोबारा गौर करेंगे जो पहले काम नहीं करते थे क्योंकि बाकी पाइपलाइन इतनी बदल गई है कि वे अब काम करते हैं।
चमकदार वस्तु जाल से बचें
Every week there's a new paper or framework claiming to solve RAG quality. ब्लॉग पोस्ट के आधार पर अपनी पाइपलाइन को दोबारा व्यवस्थित करने की इच्छा का विरोध करें। इसके बजाय, अपनी वास्तविक सबसे बड़ी गुणवत्ता समस्या की पहचान करने और उस विशिष्ट समस्या को हल करने के लिए अपने रेट्रोस्पेक्टिव डेटा का उपयोग करें। शायद इसका उत्तर एक फैंसी नया री-रैंकिंग मॉडल है। More likely, it's fixing how you chunk your product documentation.
जो टीमें सबसे तेजी से सुधार करती हैं वे सबसे परिष्कृत वास्तुकला का उपयोग करने वाली टीमें नहीं हैं। वे "यह आउटपुट खराब था" और "यहां विशेष रूप से क्यों है, और यहां बताया गया है कि हमने क्या बदला है" के बीच सबसे मजबूत फीडबैक लूप वाले लोग हैं।
NextRetro निःशुल्क आज़माएँ- कॉलम के साथ RAG विफलता पैटर्न को वर्गीकृत करें और प्राथमिकता देने के लिए किस पाइपलाइन सुधार पर वोट करें।
आखरी अपडेट:फरवरी 2026
पढ़ने का समय:7 मिनट
