एलएलएम को तोड़ने से बचते हुए डेटा की सुरक्षा कैसे करें: गार्डरेल्स फिल्टर के अंदर की कार्यप्रणाली
OpenAI
Anthropic
यह लेख गार्डरेल्स फिल्टर बनाने की इंजीनियरिंग चुनौतियों का विवरण देता है, जो एलएलएम अनुरोधों के लिए एक डेटा सुरक्षा परत है। यह स्ट्रीमिंग प्रतिक्रियाओं में व्यक्तिगत डेटा को मास्क करने और अनमास्क करने, टूल कॉल को संभालने और कई एपीआई प्रारूपों का समर्थन करने की जटिलताओं पर प्रकाश डालता है। लेखक चैट कम्प्लीशन और मैसेजेस एपीआई दोनों के लिए फिल्टर लागू करने से अंतर्दृष्टि साझा करता है।
यह लेख एक गार्डरेल्स फ़िल्टर के विकास की चर्चा करता है जिसको बड़े भाषा मॉडल के साथ इंटरैक्शन में व्यक्तिगत डेटा की सुरक्षा के लिए डिज़ाइन किया गया है। जबकि नियमित अभिव्यक्तियों (regular expressions) का उपयोग करके व्यक्तिगत डेटा का पता लगाना सीधा है, वास्तविक चुनौती एप्लिकेशन और मॉडल के बीच फ़िल्टर को एकीकृत करने में है बिना इंटरैक्शन को बाधित किए। फ़िल्टर को सामान्य अनुरोधों, स्ट्रीमिंग, टूल कॉलिंग को संभालना होगा, संदेश संरचना बनाए रखनी होगी और मेटाडेटा को संरक्षित करना होगा। एक ही डेटा प्रकार के कई उदाहरणों को संभालने के लिए, फ़िल्टर एक मैपिंग टेबल का उपयोग करता है, प्रत्येक अलग मान को <PHONE_1> जैसे अद्वितीय प्लेसहोल्डर असाइन करता है। चूँकि LLM स्थितिहीन होते हैं, फ़िल्टर को प्रत्येक अनुरोध के साथ पूरी वार्तालाप इतिहास को फिर से संसाधित करना होता है। स्ट्रीमिंग मोड में, प्रतिक्रियाएं टुकड़ों में आती हैं, और प्लेसहोल्डर टुकड़ों में विभाजित हो सकते हैं; फ़िल्टर डिमास्किंग का प्रयास करने से पहले पर्याप्त डेटा एकत्र करने के लिए एक बफ़र का उपयोग करता है। यह प्रतिक्रियाओं के विभिन्न फ़ील्ड्स को भी संभालता है, जिनमें सामग्री, तर्क और टूल कॉल तर्क शामिल हैं, जिससे यह सुनिश्चित होता है कि सभी में डेटा सही तरीके से पुनर्स्थापित हो। अकेले चैट कम्पलीशंस में स्ट्रीमिंग के लिए यह कार्यान्वयन लगभग 1,500 लाइनों का कोड हो गया। इसके अतिरिक्त, मैसेजेस API को इसके इवेंट-आधारित प्रारूप के कारण एक अलग कार्यान्वयन का समर्थन करना पड़ा, जिससे कुल परीक्षण कोड 4,000 से अधिक लाइन हो गए।
स्रोत: Habr — хаб ИИ —
मूल
