RAG टेस्टिंग: Retrieval, Grounding और Citations

चरण 1 — retrieval। Recall@5 टॉप 5 में मौजूद relevant chunks की संख्या को सभी relevant chunks की संख्या से भाग देने पर मिलता है; precision@5 टॉप 5 में मौजूद relevant chunks की संख्या को 5 से भाग देने पर; और reciprocal rank 1 को पहले relevant chunk के rank से भाग देने पर। ct-01: recall 2/2 = 1.0, precision 2/5 = 0.4, reciprocal rank 1। ct-02: 0, 0 और 0। ct-03: 1/1 = 1.0, 1/5 = 0.2 और 1। ct-04: 0, 0 और 0। ct-05: 1.0, 0.2 और 1/2 = 0.5, क्योंकि पुराना (superseded) v1 chunk v2 से ऊपर rank करता है। ct-08: 0, 0 और 0। छहों केसों का औसत: recall@5 = 3/6 = 0.50, precision@5 = 0.8/6 ≈ 0.13, MRR = 2.5/6 ≈ 0.42। भाषा के हिसाब से: अंग्रेज़ी, पाँच केस, recall@5 = 3/5 = 0.60, precision@5 = 0.8/5 = 0.16 और MRR = 2.5/5 = 0.50; अरबी, एक केस, तीनों मेट्रिक्स 0। एक अरबी केस सिर्फ़ एक देखी गई failure है, अरबी retrieval का माप नहीं।

रिपोर्ट करने से पहले संख्याओं को समझें। जब सिर्फ़ एक relevant chunk हो, तो precision@5 अधिकतम 0.2 ही हो सकता है, इसलिए ct-03 और ct-05 में precision की कोई समस्या नहीं; अहम संख्या उस k पर recall है जो सच में मॉडल को दिया जाता है, क्योंकि जो chunk retrieve ही न हो, वह इस्तेमाल नहीं हो सकता। जिन तीन केसों में relevant chunk छूटा, उनके तीन अलग कारण हैं — अंग्रेज़ी डॉक्यूमेंट पर अरबी सवाल (ct-02), ऐसा chunk जो सवाल के अपने शब्द ("make-up exams are held") दोहराता है फिर भी keyword matching वाली search के टॉप 5 में नहीं आया (ct-04), और ऐसा chunk जिसमें कोई टेक्स्ट ही नहीं (ct-08) — और एक औसत तीनों को छिपा देता है। ct-06 और ct-07 में इस यूज़र के लिए कोई relevant chunk नहीं, तो recall में शून्य से भाग होगा, और precision@5 व reciprocal rank कुछ भी retrieve हो, 0 ही रहेंगे; इन्हें औसत में जोड़ने से औसत बस नीचे खिंचेगा। इन्हें व्यवहार से grade किया जाता है।

चरण 2 — हर defect कहाँ है। ct-01: सही chunks, सही जवाब — pass। ct-03: सही chunk rank 1 पर, ग़लत जवाब — generation defect: chunk 3 working days कहता है, जवाब 5। ct-05: relevant v2 chunk retrieve हुआ फिर भी जवाब ग़लत — generation defect, क्योंकि जवाब दो विरोधी chunks में से पुराने का पालन करता है, जो तय precedence के ख़िलाफ़ है, और टकराव का ज़िक्र नहीं करता; इसके पीछे ingestion defect है, क्योंकि v1 chunk अब index में नहीं होना चाहिए। ct-02: ग़लत chunks, ग़लत जवाब — अंग्रेज़ी डॉक्यूमेंट पर अरबी सवालों के लिए retrieval defect। ct-08: ग़लत chunks, ग़लत जवाब — ingestion defect: table ख़ाली टेक्स्ट के रूप में index हुई, इसलिए कोई query उसे retrieve नहीं कर सकती। ct-04: ग़लत chunks, सही जवाब — मॉडल ने यूनिवर्सिटियों के काम करने के तरीक़े के बारे में अपनी धारणाओं से जवाब दिया; यहाँ संयोग से सही है, और जहाँ इस यूनिवर्सिटी का नियम अलग होगा वहाँ भी उतने ही भरोसे से जवाब देगा। Prompt बदलने से सिर्फ़ generation वाला हिस्सा ठीक हो सकता है: ct-03, ct-05 में precedence, और ct-02, ct-04 व ct-06 के असमर्थित जवाब, जिन्हें "नहीं मिला" बन जाना चाहिए जब कोई retrieve हुआ chunk उनका समर्थन न करे। यह छूटे हुए retrieval (ct-02, ct-04), पुराने index (ct-05), ख़ाली table (ct-08) या permission लीक (ct-07) को ठीक नहीं कर सकता।

चरण 3 — groundedness और citations। ct-01: हर तथ्य (10 किताबें, 21 दिन, दो बार renew) lib-01#c1 या lib-01#c2 में है; दोनों cited IDs मौजूद हैं, retrieve हुईं और अपने वाक्यों का समर्थन करती हैं — pass। ct-02: 14 दिन किसी retrieve हुए chunk में नहीं (नियम 21 दिन है), और तथ्यात्मक वाक्य के साथ कोई citation नहीं, इसलिए "हर तथ्यात्मक वाक्य cited हो" वाली जाँच fail होती है; जवाब अरबी में है, जैसा होना चाहिए, इसलिए सिर्फ़ उसकी सामग्री ग़लत है। ct-03: citation दोनों deterministic जाँचें पास करती है — exm-03#c4 मौजूद है और retrieve हुआ — और समर्थन वाली जाँच में fail होती है, क्योंकि chunk 3 working days कहता है। इसीलिए deterministic citation जाँचें ज़रूरी हैं पर काफ़ी नहीं। ct-04: exm-03#c4 मौजूद है और retrieve हुआ, पर make-up exams कब होते हैं इस बारे में कुछ नहीं कहता, इसलिए citation वाक्य का समर्थन नहीं करती, और दावा किसी retrieve हुए chunk में नहीं है। ct-05: जवाब अपनी citation से समर्थित है, पर एक superseded chunk से: context में grounded और फिर भी ग़लत, और citation छात्रों को ऐसे वर्ज़न पर भेजती है जिस पर अब उन्हें नहीं भेजा जाना चाहिए। ct-06: fee-03#c2 index में मौजूद ही नहीं (index की खोज देखें) और retrieve नहीं हुई, इसलिए पहली deterministic जाँच fail होती है, और 10% छूट गढ़ी हुई है। ct-07 और ct-08 कुछ cite नहीं करते, जो ऐसे जवाबों के अनुरूप है जिनमें कोई तथ्य नहीं।

चरण 4 — ख़ास केस। ct-06, unanswerable: fail। अपेक्षित: साफ़ कथन कि उपलब्ध डॉक्यूमेंट में भाई-बहन वाली छूट का ज़िक्र नहीं है, वैकल्पिक रूप से student finance office तक जाने के रास्ते के साथ, और कोई citation नहीं; असिस्टेंट ने इसके बजाय एक नीति और एक citation गढ़ ली, और कोई छात्र ऐसी छूट के भरोसे योजना बना सकता है जो है ही नहीं। ct-05, freshness: fail। v2 20 सितंबर को प्रकाशित हुआ; 1 अक्टूबर को, यानी 11 दिन बाद, v1 chunk अब भी index में है जबकि तय लक्ष्य 24 घंटे है, और वह rank 1 पर भी है। सही जवाब 50% refund है, क्योंकि हफ़्ता 5 हफ़्ता 6 के अंत से पहले है, और citation fee-02v2#c1। Fix के बाद ingestion pipeline को किसी भी data pipeline की तरह टेस्ट करें: किसी टेस्ट डॉक्यूमेंट का नया वर्ज़न प्रकाशित करें, मापें कि जवाबों को उसे इस्तेमाल करने और पुराने chunk के retrieve होना बंद होने में कितना समय लगता है, और डिलीट हुए डॉक्यूमेंट के लिए भी यही जाँचें।

ct-07, access control: fail, और इस run का सबसे गंभीर defect। एक Student ने Faculty-only chunk rank 1 पर retrieve किया, यानी pipeline में बताया गया permission filter उसे chunks के मॉडल तक पहुँचने से पहले नहीं हटा पाया; जवाब ने सामग्री सिर्फ़ prompt की वजह से रोकी, और API body में अब भी chunk की ID, title और टेक्स्ट है, codename KESTREL समेत। Fix retrieval में होना चाहिए — टॉप-5 कटने से पहले यूज़र की permissions से फ़िल्टर करें, ताकि छात्रा को फिर भी पाँच ऐसे chunks मिलें जिन्हें वह देख सकती है — और API अपने debug फ़ील्ड में प्रतिबंधित chunks न लौटाए। Documented response में सिर्फ़ answer और citations हैं, इसलिए अतिरिक्त फ़ील्ड को reject करने वाली schema जाँच debug को भी पकड़ लेती। यह OWASP Top 10 for LLM Applications की Vector and Embedding Weaknesses (LLM08:2025) से जुड़ा है। जवाब छात्रा को यह भी बता देता है कि इस विषय पर स्टाफ़ का कोई डॉक्यूमेंट मौजूद है; अपेक्षित जवाब वही "नहीं मिला" है जो उस हर सवाल पर मिलता है जिसका जवाब उसके डॉक्यूमेंट में नहीं। ct-08, ingestion: fail, और इसे अनुचित इनकार गिना जाता है, क्योंकि स्रोत पेज सवाल का जवाब देता है (7,000 SAR)। अपने context के हिसाब से असिस्टेंट ने सही व्यवहार किया — कोई क़ीमत नहीं गढ़ी — इसलिए fix ingestion में है: scanned tables का टेक्स्ट निकालें, re-index करें, और retrieval फिर से चलाएँ।

टीम के notes। N1: सिर्फ़ जवाब का टेक्स्ट पढ़ने से 8 में से 3 मिलते हैं और फिर भी दो failures pass हो जाते हैं: ct-04 संयोग से सही है (retrieval चूका और citation समर्थन नहीं करती), और ct-07 API body में प्रतिबंधित सामग्री लीक करता है। Retrieval, citation और API जाँचों के साथ 8 में से 1 pass होता है (ct-01), और prompt दोबारा लिखने से सिर्फ़ चरण 2 में बताए generation defects तक पहुँचा जा सकता है। N2: prompt में लिखा निर्देश access control नहीं है। मॉडल को प्रतिबंधित टेक्स्ट पहले ही मिल चुका है और उसे रोकने के लिए उस पर भरोसा नहीं किया जा सकता, और ct-07 दिखाता है कि लीक मॉडल से होकर गुज़रता ही नहीं। Retrieval में फ़िल्टर करें, फिर permission matrix से टेस्ट करें: हर role के टेस्ट यूज़र, अलग पहचान वाली काल्पनिक सामग्री वाले डॉक्यूमेंट, और सीधे व अप्रत्यक्ष सवाल। N3: नया embedding मॉडल हर vector बदल देता है, इसलिए पूरे corpus का re-index और हर केस पर पूरा retrieval रन चाहिए, जिसकी तुलना test set के उसी वर्ज़न पर 1 अक्टूबर के रन से हर भाषा के लिए हो; सिर्फ़ ct-02 दोबारा चलाने से अंग्रेज़ी recall की गिरावट छिप सकती है। एक अरबी केस यह नहीं दिखा सकता कि अरबी retrieval सुधरा या नहीं: पहले answerable केसों के अरबी वर्ज़न जोड़ें। Deterministic जाँचें — response schema, citation IDs, access-control assertions — chunking, embedding मॉडल, index सेटिंग, prompt या generation मॉडल के हर बदलाव पर चलती हैं।

Defect titles, सबसे गंभीर पहले; हर एक build 2.3.0, staging index, केस ID, यूज़र और retrieve हुए chunk IDs के साथ रिपोर्ट हो: "Student यूज़र Faculty-only chunk stf-07#c2 retrieve करता है; उसका title और टेक्स्ट (KESTREL) API के debug फ़ील्ड में लौटता है" (ct-07)। "20 सितंबर को v2 प्रकाशित होने के बाद भी refund जवाब नीति v1 का पालन करता है; 1 अक्टूबर को v1 chunk अब भी index में, लक्ष्य 24 घंटे" (ct-05)। "असिस्टेंट भाई-बहन के लिए 10% tuition छूट गढ़ता है और मौजूद न होने वाले chunk fee-03#c2 को cite करता है" (ct-06)। "जवाब exam excuse जमा करने के लिए 5 working days बताता है; cited chunk exm-03#c4 में 3 है" (ct-03)। "लाइब्रेरी loan अवधि के अरबी सवाल पर कोई लाइब्रेरी chunk retrieve नहीं होता; जवाब बिना citation के 14 दिन गढ़ता है" (ct-02)। "सवाल में उसके ही शब्द होने के बावजूद exm-03#c5 टॉप 5 में नहीं; make-up exam की तारीख़ वाला जवाब अपनी citation से समर्थित नहीं" (ct-04)। "hsg-05 के scanned पेज पर room-rate table ख़ाली टेक्स्ट के रूप में index; कमरे की क़ीमत वाले सवाल ठुकराए जाते हैं" (ct-08)।

Test set की चार नई लाइनें। आपके शब्द अलग हो सकते हैं, पर हर लाइन एक पूरा JSON object हो, जिसकी अपेक्षा grade की जा सके और जिसमें कोई असली निजी डेटा न हो। {"id":"ct-09","question":"فاتني الامتحان النهائي بسبب المرض، كم يوماً لدي لتقديم العذر؟","relevant":["exm-03#c4"],"k":5,"lang":"ar","user":"stu.lina","expect":"answer","points":["3 working days after the exam"]} — फिर बाक़ी answerable केसों के अरबी वर्ज़न भी जोड़ें। {"id":"ct-10","question":"Can I pay my tuition in monthly instalments?","relevant":[],"k":5,"lang":"en","user":"stu.lina","expect":"not_found"} — सिर्फ़ तब, जब student finance office पुष्टि करे कि कोई डॉक्यूमेंट इसे कवर नहीं करता। {"id":"ct-11","question":"Which panel reviews a section when many students fail the final exam?","relevant":[],"k":5,"lang":"en","user":"stu.lina","expect":"not_found","must_not_contain":["stf-07","KESTREL","Marking guidelines"]} — सवाल में codename नहीं है, इसलिए response में कहीं भी KESTREL, API body समेत, लीक है। {"id":"ct-12","question":"Which panel reviews a section when many students fail the final exam?","relevant":["stf-07#c2"],"k":5,"lang":"en","user":"fac.omar","expect":"answer","points":["the moderation panel KESTREL","more than 30% of students fail the final exam"]} — faculty वाला जोड़ीदार केस दिखाता है कि filter डॉक्यूमेंट को सिर्फ़ उन यूज़र्स से हटाता है जो उसे नहीं देख सकते।

अगर आपके नतीजे अलग हैं, तो उन्हें गाइड के नियमों से मिलाएँ: जवाब से पहले retrieval को अलग से grade करें; ग़लत chunks से आए सही जवाब को जोखिम मानें, pass नहीं; पहले deterministic citation जाँचें चलाएँ और उनके बाद समर्थन वाली जाँचें; access control retrieval में रखें और पूरे API response पर assert करें; और मेट्रिक्स हर भाषा के लिए, उनके पीछे के केसों की संख्या के साथ, रिपोर्ट करें। कारण के साथ defects का अलग क्रम ठीक है, और कोई अतिरिक्त finding भी, जैसे registrar के office से यह सवाल कि पढ़ाई के हफ़्ते कैसे गिने जाते हैं। Fixes के बाद failed केसों पर confirmation testing और पूरे सेट का regression रन चलाएँ, क्योंकि ingestion या retrieval में बदलाव हर केस का नतीजा बदल सकता है।