आपका RAG पाइपलाइन एक मानक लोड टेस्ट (load test) को शानदार तरीके से पास कर लेता है। p95 लेटेंसी (latency) स्वस्थ दिखती है। एरर रेट (error rate) शून्य के करीब है। फिर भी, उपयोगकर्ता ऐसी प्रतिक्रियाओं की रिपोर्ट करते हैं जो सवाल से बचती हैं, ऐसे दस्तावेज़ों का हवाला देती हैं जो मौजूद नहीं हैं, या छह महीने पहले अपलोड किए गए किसी व्हाइट पेपर से अप्रासंगिक पैराग्राफ निकाल लाती हैं। डैशबोर्ड कहता है कि सब कुछ ठीक है। अनुभव कहता है कि यह टूटा हुआ है।

यह विसंगति इसलिए है क्योंकि पारंपरिक प्रदर्शन परीक्षण (performance testing) रिक्वेस्ट-रिस्पॉन्स सिस्टम के लिए बनाए गए थे, न कि उन सिस्टम के लिए जो सोचते हैं। जब आप एक REST एंडपॉइंट पर एक हज़ार समानांतर (parallel) रिक्वेस्ट भेजते हैं, तो आपको यह पता चलता है कि आपके सर्वर टिके रहते हैं या नहीं। आपको इस बारे में कुछ नहीं पता चलता कि आपका रिट्रीवल लेयर (retrieval layer) सही चंक्स (chunks) लाता है या नहीं, क्या आपका प्रॉम्प्ट टेम्पलेट कॉन्टेक्स्ट (context) को बनाए रखता है, या क्या वेक्टर स्टोर खाली होने पर मॉडल खुद से स्रोत (sources) बना लेता है। मानक लोड टेस्टिंग गति को मापती है। RAG एप्लिकेशन मांग करते हैं कि आप समझ (understanding) को मापें।

स्टेटस कोड 200 से परे

एक विशिष्ट API लोड टेस्ट तीन चीजों की जांच करता है: उपलब्धता (availability), लेटेंसी (latency), और थ्रूपुट (throughput)। यह पूछता है कि क्या सर्वर ने उत्तर दिया, इसमें कितना समय लगा, और यह कितने समवर्ती उपयोगकर्ताओं (concurrent users) का भार सह सका। एक RAG एप्लिकेशन के लिए, वे संख्याएँ पूर्व-आवश्यकताएँ (prerequisites) हैं, निष्कर्ष नहीं। एक तेज़ गलत उत्तर अभी भी एक गलत उत्तर ही है, और बड़े पैमाने पर गलत उत्तरों की लागत धीमी प्रतिक्रियाओं से कहीं अधिक होती है।

RAG हर रिक्वेस्ट में दो अलग-अलग चरण जोड़ता है। पहला, सिस्टम उपयोगकर्ता के प्रश्न को एक एम्बेडिंग (embedding) में बदलता है, वेक्टर स्टोर को क्वेरी करता है, और कॉन्टेक्स्ट चंक्स का एक सेट वापस लाता है। दूसरा, यह उन चंक्स को एक प्रॉम्प्ट में भरता है, सब कुछ एक लैंग्वेज मॉडल को भेजता है, और एक पूर्णता (completion) स्ट्रीम करता है। पारंपरिक परीक्षण अक्सर इन्हें एक एकल "रिस्पॉन्स टाइम" मीट्रिक में समेट देते हैं। वे रिट्रीवल इंजन और जनरेटर को एक ही ब्लैक बॉक्स की तरह मानते हैं।

आपको उस बॉक्स को खोलना होगा। यदि आपका वेक्टर डेटाबेस लोड के तहत धीमा हो जाता है, तो रिट्रीवल लेटेंसी बढ़ जाती है। LLM अभी भी तेज़ी से जवाब दे सकता है, लेकिन वह जल्दबाजी में लाए गए कचरा कॉन्टेक्स्ट (garbage context) के आधार पर जवाब दे रहा होता है। इसके विपरीत, वेक्टर सर्च तेज़ बनी रहती है जबकि LLM क्यू (queue) भर जाती है, जिससे 'टाइम-टू-फर्स्ट-टोकन' (time-to-first-token) बढ़ जाता है और उपयोगकर्ता ब्लिंक करते कर्सर को देखते रह जाते हैं। एक एकल एंड-टू-एंड टाइमर दोनों विफलताओं को छिपा देता है।

केवल डेटाबेस नहीं, रिट्रीवल का परीक्षण करें

अधिकांश टीमें एक त्वरित वेक्टर सर्च बेंचमार्क चलाती हैं और रिट्रीवल लेयर के परीक्षण का दावा करती हैं। वह बेंचमार्क आमतौर पर यह मापता है कि डेटाबेस एक चुनिंदा क्वेरी के लिए कितनी तेज़ी से 'निएरेस्ट नेबर्स' (nearest neighbors) लौटाता है। यह शायद ही कभी यह मापता है कि क्या उन नेबर्स में वास्तव में उत्तर है।

लोड के साथ रिट्रीवल की गुणवत्ता सूक्ष्म तरीकों से बदल जाती है। समवर्ती दबाव (concurrent pressure) के तहत, 'एप्रोक्सिमेट निएरेस्ट नेबर' (approximate nearest neighbor) इंडेक्स अलग-अलग व्यवहार कर सकते हैं जैसा कि वे आइसोलेशन में करते हैं। चंकिंग रणनीतियाँ (chunking strategies) जो नोटबुक में एकदम सही लग रही थीं, वे तब कॉन्टेक्स्ट को सीमाओं के पार फैलाना शुरू कर देती हैं जब दस हज़ार दस्तावेज़ एक ही एम्बेडिंग स्पेस के लिए प्रतिस्पर्धा करते हैं। एक क्वेरी जो शांत वातावरण में आदर्श पैराग्राफ लौटाती है, वह तब एक भ्रामक मार्केटिंग स्लाइड दिखा सकती है जब इंडेक्स फिर से बन रहा हो या जब रिक्वेस्ट के दबाव में मेटाडेटा फ़िल्टरिंग हट जाती हो।

इसे ठीक से परखने के लिए, आपको एक 'ग्राउंड-ट्रुथ' (ground-truth) डेटासेट की आवश्यकता है। ऐसे प्रश्नों को तैयार करें जिनके बारे में आप पहले से जानते हैं कि कौन से स्रोत दस्तावेज़ दिखने चाहिए। उन प्रश्नों को विभिन्न समवर्ती स्तरों (concurrency levels) पर चलाएं और जांचें कि क्या अपेक्षित चंक्स 'टॉप-के' (top-k) परिणामों में आते हैं। केवल क्वेरी अवधि (query duration) ही नहीं, बल्कि हिट रेट (hit rate) को भी ट्रैक करें। यदि आपके शीर्ष पांच चंक्स महत्वपूर्ण स्रोत को पूरी तरह से छोड़ देते हैं, तो आपका रिट्रीवल पाइपलाइन LLM के जागने से पहले ही विफल हो गया था।

आपको किनारों (edges) का भी स्ट्रेस-टेस्ट (stress-test) करना चाहिए। ऐसी क्वेरी सबमिट करें जिनका कॉर्पस (corpus) में कोई उत्तर न हो। ऐसे अस्पष्ट प्रश्न सबमिट करें जो कई डोमेन से संबंधित हो सकते हैं। ऐसे लंबे प्रश्न सबमिट करें जो आपके एम्बेडिंग मॉडल की टोकन सीमा से अधिक हों और चुपचाप काट (truncate) दिए जाएं। देखें कि रिट्रीवल लेयर क्या वापस देती है। प्रत्येक मामले में, बीते हुए मिलीसेकंड की तुलना में विफलता का तरीका (failure mode) अधिक महत्वपूर्ण होता है।

जब मॉडल चुपचाप घुटने लगता है

एक बार जब चंक्स LLM तक पहुँच जाते हैं, तो मानक लोड टेस्टिंग झूठ बोलती रहती है