तुमचा RAG पाइपलाइन स्टँडर्ड लोड टेस्टमध्ये उत्तम कामगिरी करतो. p95 लॅटन्सी (latency) चांगली दिसते. एरर रेट्स (error rates) शून्याच्या जवळ आहेत. तरीही वापरकर्ते असे प्रतिसाद देतात जे प्रश्नावर टाळाटाळ करतात, अस्तित्वात नसलेल्या कागदपत्रांचा संदर्भ देतात किंवा सहा महिन्यांपूर्वी अपलोड केलेल्या व्हाईट पेपरमधील अप्रासंगिक परिच्छेद बाहेर काढतात. डॅशबोर्ड म्हणतो की सर्व काही ठीक आहे, पण अनुभव सांगतो की ते तुटलेले आहे.
हा विसंगतीचा संबंध असा आहे की पारंपारिक परफॉर्मन्स टेस्टिंग हे 'रिक्वेस्ट-रिस्पॉन्स' सिस्टमसाठी बनवले गेले होते, 'विचार करणाऱ्या' सिस्टमसाठी नाही. जेव्हा तुम्ही एका REST एंडपॉइंटवर हजारो समांतर रिक्वेस्ट पाठवता, तेव्हा तुम्हाला तुमचे सर्व्हर्स टिकून राहतात की नाही हे समजते. परंतु तुमचे रिट्रिव्हल लेयर (retrieval layer) योग्य चंक्स (chunks) शोधते का, तुमचे प्रॉम्प्ट टेम्पलेट (prompt template) संदर्भ (context) जपते का, किंवा वेक्टर स्टोअर रिकामे असल्यास मॉडेल स्वतःहून स्रोत शोधून काढते का, याबद्दल तुम्हाला काहीही समजत नाही. स्टँडर्ड लोड टेस्टिंग वेगाचे मोजमाप करते. RAG ॲप्लिकेशन्ससाठी तुम्हाला 'समजून घेण्याच्या क्षमतेचे' (understanding) मोजमाप करणे आवश्यक आहे.
स्टेटस कोड 200 च्या पलीकडे
एक सामान्य API लोड टेस्ट तीन गोष्टी तपासते: उपलब्धता (availability), लॅटन्सी (latency) आणि थ्रूपुट (throughput). सर्व्हरने उत्तर दिले का, त्याला किती वेळ लागला आणि तो किती समवर्ती वापरकर्त्यांना (concurrent users) हाताळू शकला, हे ती तपासते. RAG ॲप्लिकेशनसाठी, हे आकडे पूर्वअटी आहेत, निष्कर्ष नाहीत. वेगाने मिळालेले चुकीचे उत्तर हे चुकीचे उत्तरच असते, आणि मोठ्या प्रमाणावर (at scale) मिळणारी चुकीची उत्तरे संथ उत्तरांपेक्षा जास्त महाग पडतात.
RAG प्रत्येक रिक्वेस्टमध्ये दोन वेगळ्या टप्प्यांची भर घालते. पहिले म्हणजे, सिस्टम वापरकर्त्याच्या प्रश्नाचे एम्बेडिंगमध्ये (embedding) रूपांतर करते, वेक्टर स्टोअरमध्ये क्वेरी करते आणि संदर्भाचे काही चंक्स (context chunks) परत मिळवते. दुसरे म्हणजे, ते चंक्स एका प्रॉम्प्टमध्ये भरते, सर्व काही लँग्वेज मॉडेलकडे पाठवते आणि पूर्ण झालेला प्रतिसाद स्ट्रीम करते. पारंपारिक चाचण्या अनेकदा या सर्वांना एकाच "रिस्पॉन्स टाइम" (response time) मेट्रिकमध्ये एकत्रित करतात. ते रिट्रिव्हल इंजिन आणि जनरेटरला एक 'ब्लॅक बॉक्स' मानतात.
तुम्हाला तो बॉक्स उघडावा लागेल. जर तुमच्या वेक्टर डेटाबेसचा वेग लोडमुळे कमी झाला, तर रिट्रिव्हल लॅटन्सी वाढते. LLM कदाचित अजूनही वेगाने प्रतिसाद देईल, पण तो घाईघाईने मिळवलेल्या चुकीच्या संदर्भावर (garbage context) आधारित असेल. पर्यायीरित्या, वेक्टर सर्च जलद राहू शकतो पण LLM क्यू (queue) मागे पडू शकते, ज्यामुळे 'टाइम-टू-फर्स्ट-टोकन' (time-to-first-token) वाढतो आणि वापरकर्ते फक्त चमकणाऱ्या कर्सरकडे पाहत राहतात. एकच एंड-टू-एंड टाइमर या दोन्ही त्रुटी लपवून ठेवतो.
फक्त डेटाबेस नाही, तर रिट्रिव्हलची चाचणी घ्या
बहुतेक टीम्स एक जलद वेक्टर सर्च बेंचमार्क चालवतात आणि रिट्रिव्हल लेयरची चाचणी झाली असे मानतात. तो बेंचमार्क सहसा एखादी निवडलेली क्वेरीसाठी डेटाबेस किती वेगाने 'निअरस्ट नेबर्स' (nearest neighbors) परत करतो, याचे मोजमाप करतो. परंतु त्या नेबर्समध्ये प्रत्यक्षात उत्तर आहे की नाही, याचे मोजमाप तो क्वचितच करतो.
लोडनुसार रिट्रिव्हलची गुणवत्ता सूक्ष्म पद्धतीने बदलते. समवर्ती दबावाखाली (concurrent pressure), 'अप्रोक्सिमेट निअरस्ट नेबर' (approximate nearest neighbor) इंडेक्स एकाकी स्थितीत कसे काम करतात त्यापेक्षा वेगळ्या प्रकारे वागू शकतात. नोटबुकमध्ये उत्तम वाटणाऱ्या 'चंकिंग स्ट्रॅटेजीज' (chunking strategies) तेव्हा संदर्भाच्या सीमा ओलांडू लागतात जेव्हा दहा हजार दस्तऐवज एकाच एम्बेडिंग स्पेससाठी स्पर्धा करतात. शांत वातावरणात आदर्श परिच्छेद देणारी क्वेरी, जेव्हा इंडेक्स पुन्हा तयार होत असतो किंवा रिक्वेस्टच्या दबावाखाली मेटाडेटा फिल्टरिंग कमी होते, तेव्हा चुकीची मार्केटिंग स्लाईड समोर आणू शकते.
याची योग्य प्रकारे चाचणी घेण्यासाठी, तुम्हाला 'ग्राउंड-ट्रुथ डेटासेट' (ground-truth dataset) आवश्यक आहे. असे प्रश्न तयार करा ज्यांचे मूळ दस्तऐवज कोणते असावेत हे तुम्हाला आधीच माहित आहे. हे प्रश्न विविध समवर्ती स्तरांवर (concurrency levels) चालवा आणि अपेक्षित चंक्स 'top-k' निकालांमध्ये येतात का ते तपासा. केवळ क्वेरीचा कालावधी नाही, तर 'हिट रेट' (hit rate) ट्रॅक करा. जर तुमचे पहिले पाच चंक्स महत्त्वाचा स्रोत पूर्णपणे चुकवत असतील, तर LLM जागृत होण्यापूर्वीच तुमचा रिट्रिव्हल पाइपलाइन अपयशी ठरला आहे.
तुम्ही कडांची (edges) देखील स्ट्रेस-टेस्ट (stress-test) केली पाहिजे. कॉर्पसमध्ये (corpus) उत्तर नसलेल्या क्वेरी सबमिट करा. एकापेक्षा जास्त डोमेन्सना लागू पडू शकणारे संदिग्ध प्रश्न सबमिट करा. तुमच्या एम्बेडिंग मॉडेलच्या टोकन मर्यादेपेक्षा जास्त असलेले लांब प्रश्न सबमिट करा जे शांतपणे कापले (truncated) जातात. रिट्रिव्हल लेयर काय परत देते ते पहा. प्रत्येक बाबतीत, किती मिलीसेकंद लागले यापेक्षा 'फेल्युअर मोड' (failure mode) अधिक महत्त्वाचा असतो.
जेव्हा मॉडेल शांतपणे अडखळते
एकदा चंक्स LLM पर्यंत पोहोचले की, स्टँडर्ड लोड टेस्टिंग खोटे सांगत राहते