वेक्टर पॉइज़निंग डिटेक्शन: एजेंटों के कार्य करने से पहले रिट्रीवल-भ्रष्टाचार कैसे पकड़ें

ज़हरीला वेक्टर स्टोर केवल ख़राब सर्च गुणवत्ता नहीं है। यह स्थायी स्मृति-भ्रष्टाचार है। जैसे ही दुर्भावनापूर्ण चंक रिट्रीवल पर हावी होते हैं, एजेंट मूल ingest घटना के भुला दिए जाने के बहुत बाद तक ग़लत निर्णय लेता रह सकता है।

यह क्यों मायने रखता है

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

इसीलिए वेक्टर-स्टोर पॉइज़निंग उसी ख़तरा-परिवार में आती है जिसमें मेमोरी पॉइज़निंग। रिट्रीवल परत भी स्मृति ही है — बस markdown या JSON के बजाय सघन (dense) रूप में।

सबसे तेज़ डिटेक्टर जो फिर भी ईमानदार है

सस्ता संस्करण ही सही शुरुआती बिंदु भी है। किसी बैच को प्रोडक्शन स्मृति में पदोन्नत करने से पहले दो व्याख्या-योग्य संकेत देखें: सेंट्रॉइड ड्रिफ़्ट और hubness विसंगतियाँ।

ये दोनों जाँचें आम भद्दे मामलों को पकड़ लेती हैं, बिना यह दिखावा किए कि पहले ही दिन आपको मॉडल पुनर्प्रशिक्षण या कोई विशाल विसंगति-प्लेटफ़ॉर्म चाहिए।

सेंट्रॉइड ड्रिफ़्ट क्या पकड़ता है

यदि किसी namespace में सँकरी, भरोसेमंद सामग्री ही होनी चाहिए, तो कोई दुर्भावनापूर्ण या विषय-बाहरी बैच उस एम्बेडिंग-बादल के केंद्र को बहुत दूर नहीं ले जाना चाहिए। बड़े खिसकाव अक्सर तीन में से एक बात दर्शाते हैं: हमलावर-नियंत्रित चंक थोक में डाले गए, बेतरतीब कचरा एम्बेड हुआ, या namespace ने चुपचाप ऐसा स्रोत सोख लिया जो वहाँ का है ही नहीं।

यह संकेत तब और मज़बूत होता है जब आप खिसकाव के आकार की तुलना कच्ची दूरी-सीमा के बजाय भरोसेमंद कॉर्पस की सामान्य त्रिज्या से करें। बात गणितीय सौंदर्य की नहीं है। बात यह पूछने की है कि क्या यह बैच इस कमरे का लगता है।

Hubness क्या पकड़ता है

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

यही वह विफलता-मोड है जिसकी रक्षकों को परवाह होनी चाहिए, क्योंकि मॉडल सामान्य दिख सकता है जबकि संदर्भ-चयन परत पहले ही भेद ली जा चुकी हो।

वह परिचालन नियम जो सबसे अधिक मायने रखता है

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

अच्छा कैसा दिखता है

एक समझदार ingest पथ commit से पहले विसंगति-संकेत मापता है, ऑडिट ट्रेल को केवल-जोड़ने योग्य (append-only) रखता है, और जब ऑपरेटर जानबूझकर बैकफ़िल या मॉडल माइग्रेशन चलाते हैं तो उन्हें साफ़ ओवरराइड पथ देता है। स्थैतिक जाँचें यह सत्यापित कर सकती हैं कि ये बचाव मौजूद हैं, पर रनटाइम मापन वेक्टर लेखन-पथ के पास ही होना चाहिए।

महत्वपूर्ण हिस्सा है व्याख्या-योग्य बने रहना। सुरक्षा टीमों को यह जानना चाहिए कि क्यों किसी बैच को रोका गया — केवल यह नहीं कि किसी ब्लैक बॉक्स को वह पसंद नहीं आया।

KENSAI का निष्कर्ष

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