Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code
यह शोध पत्र मूल्यांकन पूर्वाग्रहों को सुधारकर, कई मॉडलों और भाषाओं में सात इन्फरेंस-टाइम (inference-time) रक्षा प्रणालियों का व्यवस्थित रूप से आकलन करके, और यह प्रदर्शित करके कि जहाँ ग्रीडी डिकोडिंग (Greedy decoding) सर्वोत्तम उपयोगिता संतुलन प्रदान करती है, वहीं प्रतिकूल प्रॉम्प्ट्स (adversarial prompts) के विरुद्ध मजबूत सुरक्षा के लिए RAG और सेल्फ-रिफाइन (Self-Refine) आवश्यक हैं, LLM-जनित कोड द्वारा गैर-मौजूद सॉफ़्टवेयर पैकेज को मतिभ्रम (hallucinate) के रूप में प्रस्तुत करने के महत्वपूर्ण मुद्दे को संबोधित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
सॉफ्टवेयर विकास की आधुनिक दुनिया में, प्रोग्रामर अक्सर कोड लिखने के लिए आर्टिफिशियल इंटेलिजेंस सहायकों पर भरोसा करते हैं। ये सिस्टम, जिन्हें लार्ज लैंग्वेज मॉडल्स के रूप में जाना जाता है, अथक साथियों के रूप में कार्य करते हैं जो पूरे फंक्शन का सुझाव दे सकते हैं या सेकंडों में त्रुटियों को ठीक कर सकते हैं। अपने सुझावों को काम करने योग्य बनाने के लिए, ये मॉडल अक्सर बाहरी सॉफ्टवेयर पैकेज जोड़ने की सिफारिश करते हैं—जो कोड के पूर्व-लिखित संग्रह हैं जो डेटाबेस से जुड़ने या ग्राफ बनाने जैसे विशिष्ट कार्यों को संभालते हैं। समस्या तब उत्पन्न होती है जब आर्टिफिशियल इंटेलिजेंस एक ऐसे पैकेज का नाम बना देता है जो सुनने में पूरी तरह वास्तविक लगता है लेकिन वास्तव में किसी भी आधिकारिक सॉफ्टवेयर लाइब्रेरी में मौजूद नहीं होता है। इस घटना को 'पैकेज हेलुसिनेशन' (package hallucination) कहा जाता है। यदि कोई डेवलपर आँख मूंदकर सुझाव पर भरोसा करता है और इस गैर-मौजूद पैकेज को इंस्टॉल करने की कोशिश करता है, तो वे अनजाने में एक हैकर द्वारा बनाए गए दुर्भावनापूर्ण फ़ाइल को डाउनलोड कर सकते हैं जिसने उस नकली नाम को पंजीकृत किया हो। यह सॉफ्टवेयर सप्लाई चेन में एक खतरनाक बैकडोर बनाता है, जिससे हमलावरों को उन अनुप्रयोगों में हानिकारक कोड डालने की अनुमति मिलती है जिनका उपयोग लाखों लोग कर सकते हैं।
शोधकर्ताओं की एक टीम यह समझने के लिए आगे बढ़ी कि ये हेलुसिनेशन कितनी बार होते हैं और क्या विशिष्ट तकनीकें उन्हें कोड पूरा होने से पहले ही रोक सकती हैं। उन्होंने छोटे, ओपन-सोर्स आर्टिफिशियल इंटेलिजेंस मॉडल्स पर ध्यान केंद्रित किया, जिनका व्यापक रूप से उपयोग किया जाता है क्योंकि उन्हें चलाना कम खर्चीला है, भले ही वे अपने बड़े समकक्षों की तुलना में गलतियाँ करने के प्रति अधिक प्रवृत्त हों। शोधकर्ताओं ने इन मॉडल्स का चार अलग-अलग प्रोग्रामिंग भाषाओं: पायथन, जावास्क्रिप्ट, रूबी और रस्ट में परीक्षण किया। उन्होंने पाया कि इन त्रुटियों को मापने के पिछले तरीके दोषपूर्ण थे। कई पिछले अध्ययनों ने मानक, अंतर्निहित उपकरणों को—जो किसी प्रोग्रामिंग भाषा के साथ आते हैं—हेलुसिनेशन के रूप में गिना क्योंकि वे बाहरी पैकेज लाइब्रेरी में सूचीबद्ध नहीं हैं। इस गणना त्रुटि को सुधारते हुए, टीम ने पाया कि पायथन के लिए हेलुसिनेशन की दर पहले की तुलना में कम थी, हालांकि फिर भी महत्वपूर्ण थी।
उनके कार्य के मूल में सात अलग-अलग रणनीतियों का परीक्षण करना शामिल था यह देखने के लिए कि क्या वे मॉडल्स द्वारा उत्पन्न किए गए नकली पैकेज नामों की संख्या को कम कर सकती हैं। इनमें से कुछ रणनीतियों में मॉडल के अपने अगले शब्द को चुनने का तरीका बदलना शामिल था, जबकि अन्य ने मॉडल को अपने काम की जाँच करने या जवाब देने से पहले एक सत्यापित डेटाबेस में जानकारी खोजने के लिए कहा। शोधकर्ताओं ने पाया कि कोई भी एकल विधि हर स्थिति में सबसे अच्छी नहीं थी। 'रिट्रीवल-ऑगमेंटेड जनरेशन' (Retrieval-Augmented Generation) नामक एक तकनीक, जो मॉडल को बोलने से पहले मौजूदा पैकेजों के वास्तविक डेटाबेस से परामर्श करने के लिए मजबूर करती है, अधिकांश भाषाओं के लिए अत्यधिक प्रभावी साबित हुई, जिससे त्रुटि दर में काफी कमी आई। हालाँकि, इसी तकनीक ने जावास्क्रिप्ट के लिए कभी-कभी चीज़ों को बदतर बना दिया, जो यह सुझाव देता है कि समाधान विशेष रूप से उपयोग की जाने वाली प्रोग्रामिंग भाषा पर निर्भर करता है। एक अन्य दृष्टिकोण, जहाँ मॉडल को अपने स्वयं के सुझावों की आलोचना करने और उन्हें फिर से लिखने के लिए कहा जाता है, बड़े मॉडल्स के लिए अच्छा काम करता है लेकिन सबसे छोटे मॉडल्स के लिए विफल रहा, जो अक्सर अपनी गलतियों को पहचान नहीं पाते।
टीम ने यह मापने का एक नया तरीका भी पेश किया कि मॉडल के सुझाव वास्तव में उपयोगी हैं या नहीं, न कि केवल सही। उन्होंने पाया कि कुछ रणनीतियाँ जिन्होंने हेलुसिनेशन को सफलतापूर्वक रोका, उन्होंने मॉडल को कोई भी पैकेज सुझाने से भी रोक दिया, जिससे डेवलपर के पास उपयोग के लिए कुछ भी नहीं बचा। सबसे संतुलित दृष्टिकोण, जिसने त्रुटियों को कम किया और साथ ही सहायक सुझाव भी प्रदान किए, एक सीधा तरीका था जहाँ मॉडल हर बार केवल सबसे संभावित अगले शब्द को चुनता है, बजाय कम संभावित विकल्पों पर दांव लगाने के। यह "ग्रीडी" (greedy) दृष्टिकोण उनके द्वारा परीक्षण किए गए मॉडल्स के लिए सुरक्षा और उपयोगिता के बीच सबसे अच्छा संतुलन प्रदान करता था।
शायद सबसे चौंकाने वाला निष्कर्ष तब सामने आया जब शोधकर्ताओं ने इन रक्षा प्रणालियों का एक शत्रुतापूर्ण वातावरण के विरुद्ध परीक्षण किया। उन्होंने ऐसे प्रॉम्प्ट्स बनाए जो मॉडल्स को नकली पैकेजों की सिफारिश करने के लिए जानबूझकर लुभाने की कोशिश करते थे, जिसमें निर्देशों में सीधे नकली नामों को शामिल किया गया था। इन प्रतिकूल परिस्थितियों में, त्रुटि दर आसमान छू गई, जो सामान्य अनुरोधों की तुलना में 45 प्रतिशत अंक तक बढ़ गई। इस शत्रुतापूर्ण सेटिंग में, मॉडल के शब्दों को चुनने के तरीके को बदलने वाली सरल तरकीबें पूरी तरह से विफल रहीं। केवल वे तरीके जो वास्तविक डेटाबेस के विरुद्ध जाँच करने या मॉडल को अपने स्वयं के तर्क की कड़ाई से जाँच करने के लिए मजबूर करने पर निर्भर थे, ही हमले का प्रतिरोध कर सके। शोधकर्ताओं ने निष्कर्ष निकाला कि जबकि सामान्य उपयोग में सरल समायोजन मदद कर सकते हैं, सॉफ्टवेयर को दृढ़ हमलावरों से बचाने के लिए एक ऐसी प्रणाली की आवश्यकता होती है जो बाहरी दुनिया के विरुद्ध तथ्यों को सत्यापित कर सके या अपने स्वयं के तर्क की कठोरता से जाँच कर सके। यह अध्ययन इस बात पर प्रकाश डालता है कि सबसे अच्छा बचाव 'एक आकार सभी के लिए उपयुक्त' (one-size-fits-all) समाधान नहीं है, बल्कि एक ऐसा विकल्प है जिसे विशिष्ट खतरे और प्रोग्रामिंग भाषा के साथ सावधानीपूर्वक मिलाया गया हो।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।