विश्वसनीय RAG का निर्माण कैसे करें: 7 विफलता बिंदुओं और मूल्यांकन ढांचे की गहराई से जांच

पुनर्प्राप्ति-अग्रिम पीढ़ी (RAG) आधुनिक AI वास्तुकला के लिए महत्वपूर्ण है, जो संदर्भ-जागरूक एजेंटों के निर्माण के लिए एक आवश्यक ढांचे के रूप में कार्य करता है।

लेकिन एक बुनियादी प्रोटोटाइप से एक उत्पादन-तैयार प्रणाली में जाने में डेटा पुनर्प्राप्ति, संदर्भ समेकन और प्रतिक्रिया संश्लेषण में महत्वपूर्ण बाधाओं का सामना करना पड़ता है।

यह लेख सात आम RAG विफलता बिंदुओं और व्यावहारिक कोडिंग उदाहरणों के साथ मूल्यांकन मेट्रिक्स में गहराई से जांच प्रदान करता है।

RAG विफलता का अनатомी – 7 विफलता बिंदु (FPs)

शोधकर्ता बार्नेट एट अल के अनुसार, पुनर्प्राप्ति-अग्रिम पीढ़ी (RAG) प्रणाली पाइपलाइन में सात विशिष्ट विफलता बिंदु (FPs) का सामना करती हैं।

नीचे दिए गए चित्र में इन चरणों का चित्रण किया गया है:

चित्र ए. पुनर्प्राप्ति और प्रश्न प्रक्रियाओं के लिए सूचकांक, जो एक RAG प्रणाली बनाने के लिए आवश्यक हैं। सूचकांक प्रक्रिया विकास समय में की जाती है और प्रश्न रनटाइम में किए जाते हैं। इस अध्ययन में पहचाने गए विफलता बिंदु लाल बक्से में दिखाए गए हैं (स्रोत)

आइए प्रत्येक FP का अन्वेषण करें, जो पाइपलाइन क्रम के अनुसार व्यवस्थित हैं:

FP1. सामग्री की कमी

सामग्री की कमी तब होती है जब प्रणाली को एक प्रश्न पूछा जाता है जिसका उत्तर देना संभव नहीं है क्योंकि संबंधित जानकारी पहले स्थान पर उपलब्ध वेक्टर स्टोर में नहीं है।

विफलता तब होती है जब एक LLM एक उचित ध्वनि वाला लेकिन गलत प्रतिक्रिया प्रदान करता है, इसके बजाय यह कहता है कि यह नहीं जानता।

FP2. शीर्ष-रैंक वाले दस्तावेज़ को याद किया

यह एक ऐसी स्थिति है जहां एक सही दस्तावेज़ वेक्टर स्टोर में मौजूद है, लेकिन पुनर्प्राप्तिकर्ता इसे शीर्ष-k दस्तावेज़ों में शामिल करने के लिए पर्याप्त रूप से रैंक नहीं देता है जो एक LLM को संदर्भ के रूप में दिया जाता है।

परिणामस्वरूप, सही जानकारी LLM तक कभी नहीं पहुंचती है।

FP3. संदर्भ में नहीं (समेकन रणनीति सीमाएं)

यह एक ऐसी स्थिति है जहां एक सही दस्तावेज़ मौजूद है और वेक्टर स्टोर से पुनर्प्राप्त किया जाता है, लेकिन समेकन प्रक्रिया के दौरान बाहर रखा जाता है।

यह तब होता है जब बहुत सारे दस्तावेज़ वापस आ जाते हैं और प्रणाली को उन्हें LLM की संदर्भ विंडो के भीतर फिट होने के लिए फिल्टर करना होता है, टोकन सीमाओं या दर सीमाओं के कारण।

FP4. निकाला नहीं गया

यह एक ऐसी स्थिति है जहां एक LLM संदर्भ में सही जानकारी की पहचान करने में विफल रहता है, भले ही सही जानकारी वेक्टर स्टोर में मौजूद थी और सफलतापूर्वक पुनर्प्राप्त/समेकित की गई थी।

यह तब होता है जब संदर्भ बहुत शोरदार होता है या विरोधाभासी जानकारी होती है जो LLM को भ्रमित करती है।

FP5. गलत प्रारूप

यह एक ऐसी स्थिति है जहां भंडारण, पुनर्प्राप्ति, समेकन और LLM व्याख्या सभी सफलतापूर्वक संभाले जाते हैं, लेकिन LLM प्रॉम्प्ट में दिए गए विशिष्ट प्रारूप निर्देशों का पालन करने में विफल रहता है, जैसे कि एक तालिका, एक बुलेटेड सूची या एक JSON स्कीमा।

FP6. गलत विशिष्टता

एक LLM का आउटपुट तकनीकी रूप से मौजूद है, लेकिन या तो बहुत सामान्य या उपयोगकर्ता की आवश्यकताओं की तुलना में बहुत जटिल है।

उदाहरण के लिए, एक LLM एक जटिल पेशेवर लक्ष्य वाले उपयोगकर्ता प्रश्न के लिए सरल उत्तर उत्पन्न करता है।

FP7. अधूरे उत्तर

यह एक ऐसी स्थिति है जहां एक LLM एक आउटपुट उत्पन्न करता है जो गलत नहीं है, लेकिन संदर्भ में उपलब्ध महत्वपूर्ण जानकारी के टुकड़े गायब हैं।

उदाहरण के लिए, जब एक उपयोगकर्ता एक जटिल प्रश्न पूछता है जैसे “दस्तावेज़ A, B, और C में कुंजी बिंदु क्या हैं?”, LLM केवल एक या दो स्रोतों को संबोधित करता है।

FPs RAG पाइपलाइन प्रदर्शन को कैसे समझौता करते हैं

प्रत्येक FPs RAG पाइपलाइन के प्रदर्शन को प्रभावित करता है:

डेटा अखंडता और विश्वास विफलता

जब गलत या अनुपस्थित जानकारी मौजूद होती है, तो प्रणाली जानकारी का एक विश्वसनीय स्रोत नहीं है। प्राथमिक FPs में शामिल हैं:

• FP1 (सामग्री की कमी): उत्तर पहले स्थान पर दस्तावेज़ में नहीं है।
• FP4 (निकाला नहीं गया): LLM दस्तावेज़ में सही उत्तर को नजरअंदाज करने का फैसला करता है।
• FP7 (अधूरा): LLM आधे सच्चे उत्तर देता है, महत्वपूर्ण टुकड़े गायब हैं।

पुनर्प्राप्ति और दक्षता बोतलनेक

RAG पाइपलाइन पुनर्प्राप्ति और समेकन चरणों में महत्वपूर्ण जानकारी को याद करने पर अक्षम हो सकती है। प्राथमिक FPs में शामिल हैं:

• FP2 (शीर्ष-रैंक वाले दस्तावेज़ को याद किया): एम्बेडिंग मॉडल शीर्ष-k एम्बेडिंग का चयन करने में विफल रहता है।
• FP3 (समेकन रणनीति): स्क्रिप्ट LLM सीमाओं के भीतर फिट होने के लिए दस्तावेजों को ट्रिम करने के लिए सबसे महत्वपूर्ण हिस्सों को छोड़ देता है।

उपयोगकर्ता अनुभव और प्रारूप त्रुटियां

हालांकि सही है, एक खराब पठनीयता या गलत प्रारूप वाला आउटपुट उपयोगकर्ता अनुभव को समझौता कर सकता है। प्राथमिक FPs में शामिल हैं:

• FP5 (गलत प्रारूप): LLM विशिष्ट आउटपुट प्रारूप का पालन करने में विफल रहता है, जैसे कि JSON।
• FP6 (गलत विशिष्टता): LLM एक सरल हां/ना प्रश्न के लिए एक विस्तृत आउटपुट या एक जटिल प्रश्न के लिए एक बहुत ही संक्षिप्त उत्तर उत्पन्न करता है।

मूल्यांकन स्टैक: FPs को कम करने के लिए ढांचे

मूल्यांकन मेट्रिक्स इन FPs को कम करने के लिए डिज़ाइन किए गए हैं।

इस अनुभाग में प्रमुख RAG मूल्यांकन मेट्रिक्स का अन्वेषण किया जाता है:

प्रमुख RAG मूल्यांकन मेट्रिक्स:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – तैनाती से पहले इकाई परीक्षण

DeepEval मानदंड के आधार पर एक भारित स्कोर की गणना करता है।

एक LLM-जज (जैसे कि GPT-4o) प्रत्येक मानदंड का मूल्यांकन LLM के आउटपुट के खिलाफ करता है:

DeepEval G-eval का लाभ उठाता है, एक चेन-ऑफ-थॉट (CoT) ढांचा जो आउटपुट का मूल्यांकन करने के लिए एक बहु-चरण दृष्टिकोण लेता है:

1. मानदंड को परिभाषित करें जिसका मूल्यांकन किया जाना है (जैसे कि “सुसंगतता”, “प्रवाह” या “प्रासंगिकता”)।
2. मूल्यांकन कदम (एक मूल्यांकनकर्ता LLM का उपयोग करके) उत्पन्न करें।
3. मूल्यांकन चरण का पालन करें और इनपुट और LLM के आउटपुट का विश्लेषण करें।
4. प्रत्येक मानदंड के स्कोर का एक अपेक्षित भारित योग गणना करें।

सामान्य परिदृश्य अभ्यास में

• स्थिति: एक जटिल सॉफ्टवेयर उत्पाद के लिए एक तकनीकी दस्तावेज सहायक (बॉट) प्रतीत होता है कि हर बार इंजीनियर टीम कोडबेस को अपडेट करती है।
• समस्या: कोई मात्रात्मक प्रमाण नहीं है कि बॉट अभी भी उपयोगकर्ता प्रश्न का उत्तर दे सकता है (आप सिर्फ “सोचते” हैं कि यह काम कर रहा है …)।
• समाधान: एक पायथन परीक्षण फ़ंक्शन को एक सीआई/सीडी प्रतिगामी सूट के रूप में एकीकृत करें जहां DeepEval G-Eval और अन्य मेट्रिक्स को एक परीक्षण मामले पर चलाता है:

• अपेक्षित परिणाम: यदि किसी भी मेट्रिक्स का स्कोर थ्रेशोल्ड (0.85) से नीचे गिर जाता है, तो पायथन परीक्षण AssertionError उठाता है – सीआई बिल्ड को तुरंत विफल कर देता है, उत्पादन में पहुंचने से पहले शांत प्रतिगामी को रोकता है।

पेशेवरों

• विशेषज्ञता और विषमता जांच सहित 50+ मेट्रिक्स उपलब्ध हैं।
• मौजूदा सीआई/सीडी पाइपलाइनों के साथ सहजता से एकीकृत होता है।
• किसी संदर्भ की आवश्यकता नहीं है। केवल प्रॉम्प्ट और प्रदान किए गए संदर्भ के आधार पर आउटपुट का मूल्यांकन करें।

विपक्ष

• मूल्यांकन की गुणवत्ता न्यायाधीश LLM की क्षमताओं पर बहुत अधिक निर्भर करती है।
• एक उच्च-अंत वाले न्यायाधीश LLM के साथ गणनात्मक रूप से महंगा है।

डेवलपर नोट – DeepEval के लिए परीक्षण मामला
LLMTestCase वस्तुओं का एक सेट परिभाषित करता है जो DeepEval चलाता है।

अभ्यास में, इस परीक्षण मामले में अधिकांश महत्वपूर्ण उपयोगकर्ता प्रश्न और लेबल वाले आउटपुट शामिल होने चाहिए जो पुनर्प्राप्त संदर्भ के साथ हैं।

वे एक JSON या CSV फ़ाइल से पुनर्प्राप्त किए जा सकते हैं।

RAGAS – सुई इन हे स्टैक ऑप्टिमाइज़र

पुनर्प्राप्ति-अग्रिम पीढ़ी मूल्यांकन (Ragas) मानव-संकेत दatasets के बिना RAG का मूल्यांकन करने के लिए सिंथेटिक परीक्षण सेट उत्पन्न करके लक्ष्य रखता है।

फिर, यह प्रमुख मेट्रिक्स की गणना करता है:

चित्र बी. प्रश्न, संदर्भ और उत्तर के माध्यम से सटीकता, रिकॉल, वफादारी और प्रासंगिकता मेट्रिक्स के माध्यम से RAGAS मूल्यांकन त्रिकोण चित्र (कुरिको IWAI द्वारा बनाया गया)

प्रमुख मेट्रिक्स को तीन समूहों में वर्गीकृत किया जाता है:

• पुनर्प्राप्ति पाइपलाइन (काला ठोस रेखा, चित्र बी): संदर्भ सटीकता, संदर्भ रिकॉल।
• पीढ़ी पाइपलाइन (काला बिंदीदार रेखा, चित्र बी): वफादारी, उत्तर प्रासंगिकता।
• मूल सत्य (लाल बॉक्स, चित्र बी): उत्तर सेमेंटिक समानता, उत्तर सहीपना।

सामान्य परिदृश्य अभ्यास में

• स्थिति: कानूनी अनुबंधों के लिए RAG प्रणाली मुख्य खंड गुम है। आप अनिश्चित हैं कि क्या समस्या खोज (पुनर्प्राप्ति) या पढ़ने (जेनरेटर) में है।
• समस्या: कोई विचार नहीं है कि शीर्ष-k (पुनर्प्राप्त चंक्स) का अनुकूल मूल्य क्या है।
• समाधान: RAGAS का उपयोग करके 100 जोड़े प्रश्न और साक्ष्य के साथ एक सिंथेटिक परीक्षण सेट बनाएं। फिर, RAG पाइपलाइन को परीक्षण सेट पर चलाएं ताकि संदर्भ रिकॉल और संदर्भ सटीकता की गणना की जा सके:
• अपेक्षित परिणाम: मेट्रिक्स के परिणामों के आधार पर, कार्रवाई योजना निम्नलिखित हो सकती है:

टेबल 1. RAGAS निदान कार्रवाई योजना – स्कोर को सिस्टम समायोजन में मैपिंग।

पेशेवरों

• एक प्रारंभिक परियोजना के लिए उत्कृष्ट है जिसमें मूल-सत्य डेटासेट नहीं है (जैसा कि हमने कोड स्निपेट में देखा, RAGAS एक सिंथेटिक परीक्षण सेट बना सकता है)।

विपक्ष

• सिंथेटिक परीक्षण सेट विस्तृत तथ्यात्मक त्रुटियों को याद कर सकता है।
• उत्तरों को व्यक्तिगत दावों में तोड़ने के लिए एक मजबूत निकालने वाले मॉडल की आवश्यकता होती है (मैंने उदाहरण में gpt-4o का उपयोग किया था)।

TruLens – फीडबैक लूप विशेषज्ञ

TruLens RAG प्रक्रिया के आंतरिक तंत्र पर ध्यान केंद्रित करता है, न कि केवल अंतिम आउटपुट पर, फीडबैक फ़ंक्शन का उपयोग करके।

यह एक LLM-आधारित स्कोर का भी उपयोग करता है जो यह दर्शाता है कि प्रतिक्रिया प्रश्न के इरादे को कितनी अच्छी तरह से संतुष्ट करती है, 0-3 के 4-बिंदु लिकर्ट स्केल का उपयोग करके, जो विभिन्न खोज परिणामों की गुणवत्ता को रैंक करने के लिए उत्कृष्ट है।

सामान्य परिदृश्य अभ्यास में

• स्थिति: एक चिकित्सा सलाहकार बॉट उपयोगकर्ता के प्रश्न का सही उत्तर देता है लेकिन एक प्रो-टिप जोड़ता है जो जांचे गए पीडीएफ बेस में नहीं है।
• समस्या: जोड़ा गया प्रो-टिप उपयोगी हो सकता है, लेकिन आधारित नहीं है।
• समाधान: TruLens का उपयोग करके एक जमीनी फीडबैक फ़ंक्शन को स्कोर > 0.8 जैसे थ्रेशोल्ड के साथ लागू करें।

• अपेक्षित परिणाम: जब LLM एक प्रतिक्रिया उत्पन्न करता है जिसमें पुनर्प्राप्त चंक्स में मौजूद जानकारी नहीं है, TruLens आपके डैशबोर्ड में रिकॉर्ड को फ्लैग करता है।

पेशेवरों

• सटीकता से यह पहचानने में मदद करता है कि एजेंट कहां से भटक गया है।
• हॉलुसिनेशन को पकड़ने के लिए निर्मित जमीनी समर्थन प्रदान करता है।

विपक्ष

• कस्टम फीडबैक फ़ंक्शन को परिभाषित करने में सीखने की अवस्था है।
• साधारण स्क्रिप्ट के लिए डैशबोर्ड भारी महसूस हो सकता है।

Arize Phoenix – शांत विफलता मानचित्र

Arize Phoenix एक मुक्त स्रोत दृश्यता और मूल्यांकन उपकरण है जो LLM आउटपुट का मूल्यांकन करने के लिए है, जिसमें जटिल RAG प्रणालियां भी शामिल हैं।

Arize AI द्वारा OpenTelemetry पर निर्मित, यह दृश्यता पर ध्यान केंद्रित करता है, LLM मूल्यांकन को MLOps के एक उपसेट के रूप में मानता है।

RAG मूल्यांकन के संदर्भ में, फीनिक्स एम्बेडिंग विश्लेषण में उत्कृष्ट है, जो उच्च-आयामी वेक्टर एम्बेडिंग को 2D/3D स्पेस में यूनिफ़ॉर्म मैनिफोल्ड अनुमान और प्रोजेक्शन (UMAP) का उपयोग करके कम करता है।

यह एम्बेडिंग विश्लेषण गणितीय रूप से यह प्रकट करता है कि क्या विफल प्रश्न सेमैंटिक रूप से एक साथ समूहीकृत हैं, जो वेक्टर डेटाबेस में एक अंतराल का संकेत देता है।

सामान्य परिदृश्य अभ्यास में

• स्थिति: एक ग्राहक सहायता बॉट रिफंड के लिए बहुत अच्छा काम करता है, लेकिन वारंटी दावों के लिए अर्थहीन उत्तर देता है।
• समस्या: डेटा छेद वेक्टर डेटाबेस में (लॉग में नहीं मिल सकता है)।
• समाधान: Arize Phoenix का उपयोग करके एक Umap एम्बेडिंग विज़ुअलाइज़ेशन (UEV), एक 3D मैप को वेक्टर डेटाबेस के लिए – उपयोगकर्ता प्रश्नों को दस्तावेज़ चंक्स पर ओवरले करने के लिए उत्पन्न करें।
• अपेक्षित परिणाम: देखें कि उपयोगकर्ता प्रश्नों का एक समूह एक ऐसे क्षेत्र में उतरता है जहां कोई दस्तावेज़ मौजूद नहीं हैं, यह दर्शाता है कि कुछ दस्तावेज़ वेक्टर स्टोर में अपलोड करने में भूल हो गई हैं।

पेशेवरों

• मौजूदा उद्यम निगरानी स्टैक के साथ एकीकृत होने के लिए OpenTelemetry-मूल है।
• वेक्टर स्टोर की अंधी जगहों को दृश्य化 करने के लिए सर्वोत्तम उपकरण है।

विपक्ष

• स्कोरिंग पर कम केंद्रित, अधिक देखने पर।
• छोटे पैमाने पर अनुप्रयोगों या एकल-एजेंट टूल के लिए अत्यधिक हो सकता है।

Braintrust – प्रॉम्प्ट प्रतिगामी सुरक्षा जाल

Braintrust उच्च-आवृत्ति पुनरावृत्ति चक्रों के लिए डिज़ाइन किया गया है, क्रॉस-मॉडल तुलना का उपयोग करके।

सामान्य परिदृश्य में अभ्यास

• स्थिति: एक इंजीनियर टीम प्रॉम्प्ट को “प्रश्न का उत्तर दें” (मामला ए) से एक अधिक जटिल 500-शब्द प्रणाली निर्देश (मामला बी) में अपग्रेड करती है।
• समस्या: मामले बी के लिए प्रॉम्प्ट में सुधार मामले ए को तोड़ सकता है।
• समाधान: Braintrust का उपयोग करके एक स्वर्ण डेटासेट बनाएं जिसमें N पूर्ण उदाहरण (जैसे N = 50) शामिल हों। प्रॉम्प्ट में एक शब्द को अपडेट करते समय Braintrust को साइड-बाय-साइड (SxS) तुलना चलाएं:

• अपेक्षित परिणाम: एक अंतर रिपोर्ट जो दिखाता है कि प्रत्येक स्वर्ण डेटासेट (N = 50) के लिए कौन से मामले बेहतर या बदतर हो गए हैं।

पेशेवरों

• तैनाती से पहले परीक्षण करने के लिए बेहद तेज़ है।
• गैर-तकनीकी हितधारकों के लिए आउटपुट की समीक्षा और ग्रेडिंग के लिए एक महान UI है।

विपक्ष

• स्वामित्व/सास-फोकस्ड (हालांकि वे खुले स्रोत घटकों के साथ हैं)।
• DeepEval या Ragas की तुलना में निर्मित गहरी तकनीक मेट्रिक्स कम हैं।

निष्कर्ष

जब उचित मूल्यांकन ढांचे के साथ संभाला जाता है, तो RAG एक प्रतिस्पर्धी उपकरण हो सकता है जो उपयोगकर्ता के प्रश्न के लिए सबसे प्रासंगिक संदर्भ प्रदान करता है।

कार्यान्वयन रणनीति: मेट्रिक्स को विफलता बिंदुओं में मैपिंग

हालांकि एक-फिट-ऑल समाधान नहीं है, टेबल 2 दिखाता है कि प्रत्येक FP के लिए कौन से मूल्यांकन मेट्रिक्स लागू किए जाने चाहिए जिन्हें इस लेख में शामिल किया गया है:

टेबल 2. विफलता बिंदु शमन मैट्रिक्स – जो उपकरण किस FP को हल करता है?

DeepEval और RAGAS डेटा अखंडता विफलताओं (FP1, FP4, FP7) को मापने के लिए अपने वफादारी मेट्रिक्स का लाभ उठा सकते हैं।

TruLens अपनी संदर्भ सटीकता / रिकॉल का लाभ उठाकर FP2 का मूल्यांकन करने में उत्कृष्ट है।

Arize Phoenix पुनर्प्राप्ति प्रक्रिया का एक दृश्य निशान प्रदान करता है, जिससे यह देखना आसान हो जाता है कि क्या पुनर्प्राप्त दस्तावेज़ (FP3) को समेकन के दौरान खो दिया गया था।

उपयोगकर्ता अनुभव विफलताओं के लिए, DeepEval उपयोगकर्ता अनुभव विफलताओं का मूल्यांकन करने के लिए कस्टम मेट्रिक्स बनाता है, जबकि Braintrust मैदानी सत्य डेटासेट तुलना में उत्कृष्ट है।