AI ऐप्लिकेशन्स को सुरक्षित करनामध्यमपाठ 1396 मिनट का पाठ

RAG को सुरक्षित बनाना: रिट्रीव किए गए डॉक्यूमेंट्स के लिए परमिशन्स

रिट्रीवल तय करता है कि मॉडल क्या देखेगा। अगर रिट्रीवल इस बात पर ध्यान नहीं देता कि यूज़र कौन है, तो मॉडल खुशी-खुशी उन डॉक्यूमेंट्स से जवाब दे देगा जिन्हें यूज़र को कभी नहीं पढ़ना चाहिए।

✦ ट्यूटर से पूछें🧪 लैब · 30 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

RAG को सुरक्षित बनाना: रिट्रीव किए गए डॉक्यूमेंट्स के लिए परमिशन्स

रिट्रीवल तय करता है कि मॉडल क्या देखेगा। अगर रिट्रीवल इस बात पर ध्यान नहीं देता कि यूज़र कौन है, तो मॉडल खुशी-खुशी उन डॉक्यूमेंट्स से जवाब दे देगा जिन्हें यूज़र को कभी नहीं पढ़ना…

1/5
आसान शब्दों में
एक लाइब्रेरियन आपके लिए किताबें लाता है। अगर आप स्कूल के नियमों के बारे में पूछें और वह प्रिंसिपल की पर्सनल डायरी ले आए क्योंकि वह आपके शब्दों से मेल खाती थी, तो गड़बड़ी लाइब्रेरियन की है, आपके सवाल की नहीं।
RAG (retrieval-augmented generation) आपके डॉक्यूमेंट्स में खोजता है, सबसे अच्छे मेल खाने वाले चंक्स (chunks) को प्रॉम्प्ट में डालता है, और मॉडल को उनसे जवाब देने देता है। मॉडल को जो कुछ भी दिया जाता है, वह उसका इस्तेमाल कर लेता है। उसे यह नहीं पता होता कि किसे क्या पढ़ने की परमिशन है। इसलिए परमिशन की जांच रिट्रीवल के समय ही होनी चाहिए, इससे पहले कि मॉडल टेक्स्ट को देखे।

मूल नियम: क्वेरी के समय ही फिल्टर करें

  1. 1

    यूज़र साइन इन करता है

    आपके ऐप को सेशन से पता चल जाता है कि वे कौन हैं: user id, tenant, groups।
  2. 2

    कोड में फिल्टर बनाएं

    टेनेंट और एक्सेस ग्रुप्स सेशन से आते हैं, मॉडल या चैट से कभी नहीं।
  3. 3

    फिल्टर के साथ सर्च करें

    वेक्टर या कीवर्ड सर्च केवल उन्हीं चंक्स पर ध्यान देती है जिन्हें यह यूज़र पढ़ सकता है।
  4. 4

    रैंक करें और भेजें

    मॉडल तक केवल वही चंक्स पहुंचते हैं जिनकी अनुमति है, साथ ही साइटेशन के लिए उनकी सोर्स आईडी भी होती है।
  5. 5

    सोर्स का रिकॉर्ड रखें

    रिकॉर्ड रखें कि हर जवाब के लिए कौन सी डॉक्यूमेंट आईडी का इस्तेमाल किया गया था।
Python: permission filter inside the search (generic)python
def retrieve(query_vector, session, k=5):
    user = session.user                      # from login
    return vector_db.search(
        vector=query_vector,
        top_k=k,
        # Filter syntax differs between databases. The idea does not:
        # tenant is always required, and groups come from the session.
        filter={
            "tenant_id": user.tenant_id,
            "allowed_groups": {"any_of": user.groups},
        },
    )
आम गलतियां
  • मॉडल से यह कहना कि "सिर्फ उन्हीं डॉक्यूमेंट्स का इस्तेमाल करो जिन्हें यह यूज़र देख सकता है"
  • सभी कस्टमर्स के लिए एक ही शेयर्ड इंडेक्स, जिसे "ज़रूरत पड़ने पर" फिल्टर किया जाता है
  • इंडेक्सिंग के समय परमिशन्स कॉपी करना और उन्हें कभी अपडेट न करना
  • एक ऐसा आंसर कैश (answer cache) जिसकी 'key' केवल सवाल के टेक्स्ट पर आधारित हो
बेहतर तरीका
  • सर्च क्वेरी में ही फिल्टर लगाना, जिसे कोड द्वारा लागू किया गया हो
  • हर क्वेरी पर टेनेंट फिल्टर, या हर टेनेंट के लिए एक अलग इंडेक्स
  • परमिशन में बदलावों और हटाए गए एक्सेस को तुरंत सिंक करना
  • ऐसी कैश कीज़ (cache keys) जिनमें यूज़र का परमिशन स्कोप शामिल हो, या कोई शेयर्ड कैश न हो

मल्टी-टेनेंट अलगाव (Multi-tenant separation)

एक आईटी सर्विसेज कंपनी कई क्लाइंट प्रोजेक्ट्स के लिए एक नॉलेज असिस्टेंट बना सकती है। क्लाइंट A के डॉक्यूमेंट्स क्लाइंट B के जवाब में कभी नहीं दिखने चाहिए। आपके पास कुछ विकल्प हैं:
तरीकाखूबीलागत
हर टेनेंट के लिए अलग इंडेक्स या डेटाबेससबसे मज़बूत अलगाव; फिल्टर की कोई गड़बड़ी (bug) टेनेंट्स का डेटा आपस में नहीं मिला सकतीचलाने और पैसे चुकाने के हिसाब से ज़्यादा महंगा
हर टेनेंट के लिए अलग नेमस्पेस (namespace) या कलेक्शनअच्छा अलगाव, बशर्ते एक्सेस कीज़ (access keys) भी अलग होंप्रोडक्ट के फीचर्स पर निर्भर करता है
एक ज़रूरी (mandatory) टेनेंट फिल्टर के साथ शेयर्ड इंडेक्सचलाने में सबसे सस्ता और सबसे आसानएक भी फिल्टर छूटा तो सब कुछ लीक हो जाएगा; मज़बूत टेस्ट्स की ज़रूरत होती है

ज़हरीले (Poisoned) डॉक्यूमेंट्स

कोई भी व्यक्ति जो किसी इंडेक्स किए गए सोर्स में लिख सकता है, वह निर्देश प्लांट कर सकता है: एक विकी पेज, एक अपलोड की गई PDF, एक सपोर्ट टिकट, एक प्रोडक्ट रिव्यू, या क्रॉल की गई वेबसाइट। जब वह चंक रिट्रीव होता है, तो वह indirect prompt injection बन जाता है, और प्लांट किया गया कंटेंट data poisoning का भी एक रूप है।
  • हर उस सोर्स को जानें जिसे आप इंडेक्स करते हैं, और यह भी कि उसमें कौन लिख सकता है।
  • अविश्वसनीय पब्लिक कंटेंट (रिव्यूज़, अपलोड्स) को भरोसेमंद पॉलिसी डॉक्यूमेंट्स से अलग रखें, और हर चंक के ट्रस्ट लेवल पर लेबल लगाएं।
  • रिट्रीव किए गए टेक्स्ट को पढ़ने के बाद मॉडल क्या कर सकता है, उसे सीमित करें: कम टूल्स दें, जोखिम भरे कामों के लिए मंज़ूरी (approvals) तय करें।
  • ज़्यादा भरोसेमंद सोर्स में होने वाले बदलावों की समीक्षा करें, और अपलोड में छिपे हुए टेक्स्ट पर नज़र रखें, जैसे सफ़ेद बैकग्राउंड पर सफ़ेद टेक्स्ट या बहुत छोटा फॉन्ट।

साइटेशन (Citations) और नयापन

दिखाएं कि कोई जवाब किन डॉक्यूमेंट्स से आया है, ताकि यूज़र्स उसकी जांच कर सकें। हर चंक के साथ एक डॉक्यूमेंट आईडी, वर्ज़न और तारीख स्टोर करें। जब कोई डॉक्यूमेंट डिलीट हो जाता है, बदल दिया जाता है या एक्सपायर हो जाता है, तो उसके चंक्स को तुरंत हटा दें। वरना HR द्वारा बदली जाने के बहुत बाद तक भी पिछले साल की लीव पॉलिसी सवालों के जवाब देती रहेगी।
सावधान रहें
डॉक्यूमेंट न दिखाए जाने पर भी जवाबों से जानकारी लीक हो सकती है। कोई टाइटल, समरी, या "मुझे छंटनी की योजना के बारे में 3 डॉक्यूमेंट्स मिले हैं लेकिन मैं उन्हें दिखा नहीं सकता" यूज़र को पहले ही कुछ न कुछ बता देता है। पहले फिल्टर करें, ताकि जिन डॉक्यूमेंट्स की अनुमति नहीं है, वे कभी भी सर्च रिज़ल्ट का हिस्सा ही न बनें।
इसे आज़माएं। अपने किसी परिचित RAG ऐप में देखें कि सर्च क्वेरी कहां बनती है। क्या tenant या user id सेशन से आती है? अगर वह फ़ील्ड खाली हो तो क्या होता है?

और देखें और पढ़ें

लैब

कामकाजी परमिशन फिल्टर और पास होने वाले टेस्ट्स के साथ एक टॉय (toy) रिट्रीवल फंक्शन।

~30 min

समस्या

अपने कंप्यूटर पर स्टार्टर कोड चलाएं। यह आसान शब्द मिलान (word matching) के साथ पांच नकली डॉक्यूमेंट्स पर एक टॉय "सर्च" है। अभी यह किसी को भी डॉक्यूमेंट्स लौटा देता है।

  1. retrieve को बदलें ताकि यह केवल यूज़र के tenant और कम से कम एक मैचिंग ग्रुप वाले डॉक्यूमेंट्स पर ही विचार करे।
  2. इसे fail closed बनाएं: अगर यूज़र का कोई टेनेंट नहीं है, तो एरर (error) दें।
  3. टेस्ट्स को तब तक चलाएं जब तक वे सभी पास न हो जाएं।
  4. अपना खुद का एक टेस्ट जोड़ें: सही टेनेंट लेकिन गलत ग्रुप वाला यूज़र।

प्रैक्टिस लैब

कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।

आउटपुट

कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1आपका फिल्टर चैट पाथ में काम करता है। RAG प्रोडक्ट में दो ऐसे अन्य कोड पाथ्स के नाम बताएं जहां इसी फिल्टर को अक्सर भुला दिया जाता है।दिखाएं

आम उदाहरण: बैकग्राउंड जॉब्स जो डॉक्यूमेंट्स की समरी बनाते हैं या उन्हें टैग करते हैं, "संबंधित डॉक्यूमेंट्स" या ऑटो-कम्प्लीट फीचर्स, आंसर कैश, लोकप्रिय सवाल और जवाब दिखाने वाले एनालिटिक्स डैशबोर्ड, एडमिन या डिबग सर्च टूल्स, और इवैल्यूएशन स्क्रिप्ट्स जो प्रोडक्शन डेटा की कॉपी बनाती हैं। इंडेक्स को पढ़ने वाले हर पाथ को उसी फिल्टर की ज़रूरत होती है, बेहतर होगा कि यह एक शेयर्ड फंक्शन के ज़रिए हो।

Q2हर टेनेंट के लिए एक अलग इंडेक्स रखना कभी-कभी अतिरिक्त लागत के लायक क्यों होता है?दिखाएं

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

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या हम रिट्रीवल के बाद रिज़ल्ट्स को फिल्टर नहीं कर सकते?

आप कर सकते हैं, बशर्ते हटाए गए चंक्स को कोई और न देखे। लेकिन पोस्ट-फिल्टरिंग से अक्सर बहुत कम रिज़ल्ट मिलते हैं और इसे किसी एक कोड पाथ (code path) में भूल जाना आसान होता है, जैसे कि कोई समरी जॉब या कैश में। क्वेरी के अंदर ही फिल्टर करना ज़्यादा सुरक्षित है और इससे बेहतर जवाब मिलते हैं।

क्या अपने डॉक्यूमेंट्स पर मॉडल को fine-tune करने से यह समस्या हल हो जाती है?

नहीं, यह स्थिति को और बिगाड़ देता है। मॉडल वेट्स (model weights) में समाए ज्ञान को प्रति-यूज़र के हिसाब से फिल्टर नहीं किया जा सकता। जो कोई भी मॉडल का इस्तेमाल कर सकता है, वह इसे निकाल पाने में सक्षम हो सकता है। परमिशन वाले डेटा को रिट्रीवल में ही रखें, जहां आप उसे फिल्टर कर सकते हैं।

क्या हो अगर खाली टेनेंट फिल्टर हर चीज़ से मेल खा जाए?

यह एक वास्तविक और आम बग है। कोड को fail closed बनाएं: अगर टेनेंट या ग्रुप्स गायब हैं, तो सर्च करने से मना कर दें। ठीक इसी मामले के लिए एक टेस्ट लिखें।

परमिशन में बदलाव कितनी तेज़ी से इंडेक्स तक पहुंचने चाहिए?

उतनी ही तेज़ी से जितना कि जोखिम के हिसाब से ज़रूरी हो। जब कोई व्यक्ति किसी प्रोजेक्ट को छोड़ता है, तो उसके डॉक्यूमेंट्स तक उसका एक्सेस तुरंत खत्म हो जाना चाहिए। कई टीमें एक तय शेड्यूल पर और किसी ग्रुप से हटाए जाने जैसे ज़रूरी मौकों पर भी परमिशन्स को सिंक करती हैं।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें