एक मीडियम साइज़ के इंश्योरेंस ब्रोकर के साथ काम का तीसरा दिन है, और क्लेम ऑपरेशन्स के हेड एक ऐसे चैट टूल की मांग कर रहे हैं जो एडजस्टर को तेज़ी से जवाब दे सके। वे चाहते हैं कि यह टूल लेटेस्ट पॉलिसी नियमों का हवाला दे, अपवादों (exceptions) को समझाए, और सही हैंडबुक में सटीक पेज नंबर बताए। उसी मीटिंग में, लीगल टीम एक और शर्त जोड़ती है। टूल को क्लाइंट कॉन्ट्रैक्ट का कंटेंट तब तक नहीं दिखाना चाहिए जब तक कि एडजस्टर उस अकाउंट के लिए असाइन न किया गया हो।
यहीं पर फॉरवर्ड डिप्लॉयड वर्क (FDE) में कस्टमर-स्पेसिफिक रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) काम आता है। कस्टमर-स्पेसिफिक RAG एक ऐसा सेटअप है जिसमें AI सिस्टम पहले उस कस्टमर के अपने सोर्स से फैक्ट्स निकालता है, और फिर उन फैक्ट्स का इस्तेमाल करके जवाब लिखता है। यह कस्टमर-स्पेसिफिक इसलिए है क्योंकि सोर्स समय के साथ बदलते रहते हैं और क्योंकि कस्टमर ही तय करता है कि कौन सा जवाब सही माना जाएगा, हम नहीं।
असल में, हम कोई आम चैटबॉट नहीं बना रहे हैं। हम एक ऐसा जवाब देने वाला वर्कफ़्लो बना रहे हैं जो असली डॉक्यूमेंट्स, असली परमिशन और असली बिज़नेस नतीजों से जुड़ा हो। ब्रोकर के लिए, “सही” जवाब का मतलब है कि जवाब मौजूदा हैंडबुक वर्शन से मेल खाता हो, उसका हवाला देता हो, और अकाउंट-लेवल एक्सेस नियमों का पालन करता हो, भले ही सवाल अस्पष्ट हो।
FDE का मुख्य कदम RAG को एक फ़ीचर के बजाय एक एंड-टू-एंड सिस्टम के तौर पर देखना है। अगर हम सिर्फ़ मॉडल प्रॉम्प्ट के बारे में सोचते हैं, तो हम उन हिस्सों को नज़रअंदाज़ कर देते हैं जो इसे प्रोडक्शन में सुरक्षित और भरोसेमंद बनाते हैं। इस लेसन का बाकी हिस्सा इसी ब्रोकर केस पर आधारित है, क्योंकि आपका हर फ़ैसला उस चीज़ से जुड़ा होगा जो एडजस्टर को जवाब की ज़रूरत के समय दिखाई देती है।
RAG में प्रोडक्शन फेलियर शायद ही कभी बहुत बड़े या नाटकीय होते हैं। वे आमतौर पर चुपचाप होते हैं, सही लगते हैं, और महंगे साबित होते हैं। एडजस्टर को ऐसा जवाब मिलता है जो सही लगता है, वह उस पर कार्रवाई करता है, और बाद में किसी को पता चलता है कि क्लेम गलत नियम के तहत हैंडल किया गया था।
इस स्थिति पर विचार करें। ब्रोकर सोमवार को “Water Damage Exceptions” (पानी से होने वाले नुकसान के अपवाद) का बुलेटिन अपलोड करता है। बुधवार तक, चैट टूल अभी भी पिछले महीने की हैंडबुक का इस्तेमाल करके जवाब दे रहा होता है क्योंकि कंटेंट पाइपलाइन ने नई फ़ाइल को दोबारा प्रोसेस नहीं किया होता है। कोई एरर नहीं आता, और सिस्टम असली पेज नंबर भी बता सकता है। बस वह मौजूदा पॉलिसी सेट के हिसाब से गलत पेज नंबर होता है।
एक और आम समस्या एक्सेस बाउंड्रीज़ (पहुँच की सीमा) की होती है। अगर रिट्रीवल स्टेप किसी डॉक्यूमेंट को देख सकता है, तो AI सिस्टम उसका सारांश (summary) बना सकता है, भले ही एंड यूज़र को उसे देखने की इजाज़त न हो। इसीलिए RAG में परमिशन सिर्फ़ UI की कोई छोटी-मोटी बात नहीं होती। ये रिट्रीवल डिज़ाइन का हिस्सा हैं, और मॉडल को कोई भी टेक्स्ट देने से पहले इन्हें लागू किया जाना चाहिए।
‘साइलेंट मिस’ (यानी ऐसी चूक जिनका तुरंत पता नहीं चलता) एक और बड़ी समस्या है। जैसे, “क्या हम 2k से कम के नुकसान के मामले में इंस्पेक्शन से छूट दे सकते हैं?” - इस तरह के सवाल के लिए शायद किसी खास अपवाद वाले नियम की ज़रूरत हो। अगर रिट्रीवल सिस्टम इसे नहीं ढूंढ पाता है, तो भी मॉडल अक्सर मदद करने की कोशिश करेगा और किसी आम नियम से उस कमी को पूरा कर देगा। अगर इसे मापा न जाए, तो जब तक बिज़नेस की तरफ से शिकायत नहीं आती, तब तक आपको इस बदलाव का पता नहीं चलेगा।
आइए जानें कि ये कमियां बिज़नेस पर किस तरह असर डालती हैं।
बदलाव मानकर चलें, क्वालिटी साबित करें अगर आप समय के साथ क्वालिटी को ट्रैक नहीं कर रहे हैं, तो क्वालिटी पहले से ही बदल रही है और आप उसे अभी देख नहीं पा रहे हैं।
ये फेलियर मोड (काम न करने के तरीके) असली FDE सवाल खड़ा करते हैं। हमें क्या और किस क्रम में तय करना होगा, ताकि डॉक्यूमेंट, यूज़र और नियमों के बदलने पर भी यह सिस्टम सही बना रहे?
कस्टमर-स्पेसिफिक RAG का काम फैसलों की एक चेन है, जहाँ हर कड़ी यह बदल देती है कि अगली कड़ी सुरक्षित रूप से क्या कर सकती है। अगर हम सीधे एम्बेडिंग या चंक साइज़ पर चले जाते हैं, तो बाद में हमें सिस्टम को फिर से लिखना पड़ता है, क्योंकि तब कोई ऐसा बिज़नेस नियम सामने आता है जिसे शुरू में ही ज़रूरी ज़रूरत के तौर पर शामिल किया जाना चाहिए था।
ऐसी ज़रूरतों से शुरुआत करें जिन्हें टेस्ट किया जा सके। ब्रोकर के लिए, हम ऐसे एक्सेप्टेंस क्राइटेरिया (स्वीकृति के मानक) लिखते हैं जैसे “हैंडबुक के सटीक सेक्शन का हवाला देना ज़रूरी है” और “यूज़र के पास एक्सेस न होने पर मना करना ज़रूरी है।” ये अस्पष्ट लक्ष्य नहीं हैं। ये पास-फेल चेक हैं जिन्हें हम इवैल्यूएशन सेट में बदल सकते हैं।
अगला है डेटा। हम उन सोर्स को मैप करते हैं जो रिट्रीवल (डेटा खोजने की प्रक्रिया) को डेटा देंगे और देखते हैं कि वे कैसे बदलते हैं। SharePoint में हैंडबुक, ईमेल से बुलेटिन, CRM एक्सपोर्ट में अकाउंट कॉन्ट्रैक्ट। हम यह भी मैप करते हैं कि किसे क्या देखने की इजाज़त है, क्योंकि वह परमिशन मॉडल ही इंडेक्सिंग और क्वेरी के समय फ़िल्टरिंग को तय करेगा।
फिर आता है रिट्रीवल डिज़ाइन। रिट्रीवल वह तरीका है जिससे सिस्टम यह चुनता है कि मॉडल को कौन से डॉक्यूमेंट स्निपेट (छोटे हिस्से) दिखाने हैं। बड़ा फ़ैसला यह है कि क्या हम क्वेरी के समय परमिशन के आधार पर फ़िल्टर कर सकते हैं, या डेटा लीक से बचने के लिए हमें हर सेगमेंट के लिए अलग इंडेक्स की ज़रूरत है। ब्रोकर के मामले में, अकाउंट कॉन्ट्रैक्ट अक्सर आपको सख्त फ़िल्टरिंग की ओर ले जाते हैं, क्योंकि एक भी गलती गंभीर घटना हो सकती है।
ग्राउंडिंग वह प्रक्रिया है जिससे हम मॉडल को रिट्रीव किए गए टेक्स्ट से जोड़े रखते हैं। ग्राउंडिंग में आमतौर पर ऐसे नियम शामिल होते हैं जैसे “सिर्फ़ दिए गए कॉन्टेक्स्ट से जवाब दें” और “साइटेशन (हवाला) शामिल करें।” इसमें यह भी शामिल है कि कॉन्टेक्स्ट न होने पर सिस्टम को क्या करना चाहिए, जैसे स्पष्टीकरण के लिए सवाल पूछना या यह जवाब देना कि “मुझे मौजूदा पॉलिसी डॉक्यूमेंट में यह नहीं मिल रहा है।”
इवैल्यूएशन वह चरण है जहाँ हम भरोसेमंदता को मापने लायक बनाते हैं। इवैल्यूएशन टेस्ट सवालों का एक ऐसा सेट है जिसे बार-बार दोहराया जा सकता है और जिसमें अपेक्षित व्यवहार तय होते हैं; इसे बदलावों से पहले और बाद में चलाया जाता है। इस ब्रोकर के लिए, हम साइटेशन की सटीकता, प्रतिबंधित डॉक्यूमेंट के लिए मना करने की सही प्रक्रिया और ज़्यादा जोखिम वाले क्लेम सिनेरियो को कवर करने पर ध्यान देते हैं।
डिप्लॉयमेंट के फ़ैसले इस सब को एक ऑपरेटिंग सिस्टम में बदल देते हैं। हम तय करते हैं कि इंजेक्शन (डेटा डालने की प्रक्रिया) कैसे चलेगी, इंडेक्स कितनी बार रिफ्रेश होंगे, हम रिक्वेस्ट को सुरक्षित रूप से कैसे लॉग करेंगे और अपडेट कैसे रोल आउट करेंगे। इसके बाद इटरेशन (दोहराव) एक ऐसा लूप बन जाता है जिसमें सुरक्षा के नियम (गार्डरेल) होते हैं। जब एडजस्टर किसी चूक की रिपोर्ट करते हैं, तो हम तय करते हैं कि यह डेटा की कमी थी, रिट्रीवल की कमी थी या निर्देशों की कमी थी, और हम सही लेयर को ठीक करते हैं।
इन चरणों को विकल्पों की एक जुड़ी हुई प्रणाली के रूप में देखें।