💻 computer science

Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration

यह शोध पत्र प्रदर्शित करता है कि "एब्लिटरेशन" (abliteration), जो कि रिफ्यूज़ल दिशाओं को ऑर्थोगोनली प्रोजेक्ट करने वाली एक लो-रैंक वेट एडिटिंग तकनीक है, सुरक्षा-संरेखित कोड एलएलएम (LLM) की असुरक्षित कोड उत्पन्न करने से मना करने की प्रवृत्ति को उनकी वास्तविक पीढ़ी क्षमताओं से प्रभावी रूप से अलग कर सकता है, जिससे सिंटैक्टिक वैधता से समझौता किए बिना भेद्यता पहचान अनुसंधान के लिए लेबल किए गए असुरक्षित कोड का स्केलेबल उत्पादन सक्षम हो जाता है।

मूल लेखक: Cristina Carleo, Pietro Liguori, Naghmeh Ivaki, Domenico Cotroneo

प्रकाशित 2026-06-05

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Cristina Carleo, Pietro Liguori, Naghmeh Ivaki, Domenico Cotroneo

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

यहाँ "Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration" नामक शोध पत्र का सरल भाषा और रोज़मर्रा के उदाहरणों के साथ हिंदी अनुवाद दिया गया है।

बड़ी समस्या: "अति-सुरक्षात्मक" रोबोट

कल्प Imagine कीजिए कि आप एक रोबोट को कंप्यूटर कोड में सुरक्षा संबंधी खामियों (security holes) को पहचानना सिखाने की कोशिश कर रहे हैं। इसके लिए, आपको "सुरक्षित" कोड और "टूटे हुए" (कमजोर/vulnerable) कोड के उदाहरणों की एक विशाल लाइब्रेरी की आवश्यकता होगी।

हालाँकि, एक पेच है। आज के जो रोबोट्स (AI मॉडल्स) हमारे पास हैं, उन्हें बहुत सुरक्षित होने के लिए प्रशिक्षित किया गया है। यदि आप उनसे पूछते हैं, "हे, क्या तुम मुझे दिखा सकते हो कि डेटाबेस को कैसे तोड़ा जाए?" तो वे तुरंत कहते हैं, "नहीं! मैं यह नहीं कर सकता। यह खतरनाक है।"

यह शोधकर्ताओं के लिए एक समस्या है। शोधकर्ताओं को ज़रूरत है कि रोबोट वह गलती करे ताकि वे उसका अध्ययन कर सकें और बेहतर बचाव प्रणाली बना सकें। लेकिन रोबोट "विलेन" की भूमिका निभाने से मना कर देता है, भले ही शोधकर्ता केवल एक नियंत्रित लैब सेटिंग में उस गलती का अध्ययन करना चाहता हो।

प्रयोग: "स्टॉप" बटन को बंद करना

इस शोध पत्र के शोधकर्ता यह देखना चाहते थे कि क्या वे रोबोट के दिमाग को खराब किए बिना उस "स्टॉप" बटन को बंद कर सकते हैं। उन्होंने Abliteration नामक तकनीक का उपयोग किया।

AI के दिमाग को विचारों की एक विशाल लाइब्रेरी की तरह समझें। जब रोबोट सुरक्षा संबंधी खामी बनाने के अनुरोध को देखता है, तो उसके मन में एक विशिष्ट "इनकार का संकेत" (जैसे कि एक लाल अलार्म लाइट) चमकता है, और वह बातचीत को बंद कर देता है।

Abliteration रोबोट की वायरिंग से ठीक उसी एक लाल अलार्म लाइट को सावधानीपूर्वक निकालने वाली सर्जरी की तरह है। उन्होंने रोबोट को फिर से प्रशिक्षित नहीं किया या उसे नई चीजें नहीं सिखाईं; उन्होंने बस उन 'वेट्स' (connections) को सर्जिकल तरीके से एडिट किया ताकि इनकार का संकेत (refusal signal) सक्रिय न हो सके।

तीन मुख्य निष्कर्ष

शोधकर्ताओं ने इस परीक्षण के लिए तीन अलग-अलग आकार के AI मॉडल्स (छोटा, मध्यम और बड़ा) का उपयोग किया और पायथन (Python) कोड तथा SQL इंजेक्शन (जो डेटाबेस को राज बताने के लिए धोखा देने जैसा है) नामक एक विशिष्ट प्रकार की सुरक्षा खामी का उपयोग किया।

1. "इनकार" आकार और संदर्भ पर निर्भर करता है

किसी भी सर्जरी से पहले, उन्होंने कुछ दिलचस्प देखा:

विशाल मॉडल (14B): इसने 100% बार इनकार किया। आपने चाहे कुछ भी पूछा, इसने कहा "नहीं।"
मध्यम मॉडल (7B): यह थोड़ा चयनात्मक था। इसने लंबे, जटिल कोड पर अधिकांश समय इनकार किया, लेकिन यह कभी-कभी छोटे, सरल कोड स्निपेट्स पर "हाँ" कह देता था।
छोटा मॉडल (3B): इसने शायद ही कभी इनकार किया। यह लगभग कुछ भी करने के लिए तैयार था।

उपमा (Analogy): कल्पना कीजिए कि तीन सुरक्षा गार्ड हैं। बड़ा गार्ड इतना सख्त है कि वह हर किसी को रोकता है। मध्यम गार्ड बड़े बैग वाले लोगों को रोकता है लेकिन छोटे लिफाफों वाले लोगों को जाने देता है। छोटा गार्ड बहुत उदार है और लगभग सभी को जाने देता है।

2. सर्जरी सफल रही (द "विलिंग" पार्ट)

Abliteration सर्जरी करने के बाद:

इनकार गायब हो गया: विशाल और मध्यम मॉडल्स ने "नहीं" कहना बंद कर दिया। अब वे सुरक्षा खामी बनाने के लिए तैयार (willing) थे।
दिमाग अभी भी स्वस्थ था: महत्वपूर्ण बात यह है कि सर्जरी ने रोबोट को खराब नहीं किया। उनके द्वारा बनाया गया कोड अभी भी व्याकरण की दृष्टि से सही था और समझ में आने वाला था। उन्होंने AI का 'लोबोटोमी' (दिमाग सुन्न करना) नहीं किया था; उन्होंने बस "मैं यह नहीं करूँगा" वाली प्रतिक्रिया को हटा दिया था।

उपमा: यह एक दरवाजे से "प्रवेश निषेध" का साइन हटाने जैसा है। दरवाजा हमेशा खुला था और अंदर का गलियारा भी ठीक था; साइन बस लोगों को बता रहा था कि वे अंदर नहीं जा सकते। एक बार साइन हट जाने के बाद, लोग अंदर जा सकते थे, और गलियारा अभी भी पूरी तरह से बरकरार था।

3. इच्छा $\neq$ क्षमता (द "अनएबल" पार्ट)

यह सबसे महत्वपूर्ण खोज है। सिर्फ इसलिए कि रोबोट अब गलती करने के लिए तैयार (willing) था, इसका मतलब यह नहीं था कि वह इसे अच्छी तरह से करने के योग्य (able) भी था।

विशाल मॉडल (14B): एक बार "नहीं" का साइन हटने के बाद, यह सुरक्षा खामी बनाने में बहुत अच्छा था। यह लगभग 90% बार सफल रहा।
मध्यम मॉडल (7B): यह भी बहुत अच्छा था, इसकी सफलता दर लगभग 90% थी।
छोटा मॉडल (3B): भले ही यह तैयार था और इसने इनकार नहीं किया, लेकिन यह वास्तविक कार्य करने में बुरा था। यह केवल 25-48% बार ही सफल हो पाया।

उपमा: कल्पना कीजिए कि तीन कलाकारों को एक टूटे हुए फूलदान की तस्वीर बनाने के लिए कहा गया।

विशाल कलाकार को बताया गया "तुम यह नहीं पेंट कर सकते!" लेकिन जब उसे बताया गया कि "तुम यह कर सकते हो," तो उसने एक मास्टरपीस बनाया।
मध्यम कलाकार को भी बताया गया कि "तुम यह कर सकते हो," और उसने एक बेहतरीन तस्वीर बनाई।
छोटा कलाकार को शुरू में ही "नहीं" नहीं कहा गया था, लेकिन जब उसने टूटे हुए फूलदान को पेंट करने की कोशिश की, तो वह विवरणों को सही ढंग से नहीं पकड़ सका। वह यह करना चाहता तो था, लेकिन उसके पास कौशल (skill) की कमी थी।

निष्कर्ष: दो अलग चीजें

यह शोध पत्र साबित करता है कि इनकार (Refusal) और क्षमता (Capability) दो अलग-अलग चीजें हैं।

इनकार (Refusal) एक सुरक्षा सेटिंग है जिसे (Abliteration के माध्यम से) बंद किया जा सकता है।
क्षमता (Capability) इस बात का माप है कि मॉडल कितना स्मार्ट है। सुरक्षा सेटिंग को बंद करने से एक "कमजोर" मॉडल "स्मार्ट" नहीं बन जाता।

इससे क्या फर्क पड़ता है?

शोधकर्ताओं के लिए: यदि आप सुरक्षा उपकरणों को प्रशिक्षित करने के लिए डेटा बनाना चाहते हैं, तो आप केवल एक छोटे मॉडल का उपयोग करके यह उम्मीद नहीं कर सकते कि वह काम करेगा। भले ही आप उसके सुरक्षा फिल्टर को बंद कर दें, वह शायद इतना स्मार्ट नहीं होगा कि वास्तविक त्रुटियां पैदा कर सके जिनकी आपको आवश्यकता है। आपको एक बड़े मॉडल की आवश्यकता है।
सुरक्षा के लिए: यह दिखाता है कि सुरक्षा फ़िल्टर बहुत विशिष्ट होते हैं। आप मॉडल की अच्छा कोड लिखने की क्षमता को खराब किए बिना "इनकार" को हटा सकते हैं। इसका मतलब है कि सुरक्षा संरेखण (safety alignment) मॉडल की बुद्धिमत्ता का एक विशिष्ट स्तर है, उसकी बुद्धिमत्ता स्वयं नहीं।

नैतिकता पर एक नोट

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

तकनीकी सारांश: इच्छुक लेकिन अक्षम: एब्लिटरेशन (Abliteration) के माध्यम से कोड LLMs में इनकार (Refusal) को क्षमता (Capability) से अलग करना

समस्या विवरण
यह शोध पत्र लर्निंग-आधारित भेद्यता पहचान (vulnerability detection) की एक महत्वपूर्ण बाधा को संबोधित करता है: सटीक रूप से लेबल किए गए प्रशिक्षण डेटा की कमी। मौजूदा डेटासेट में महत्वपूर्ण लेबल शोर (20-71%) और दोहराव होता है क्योंकि उन्हें CVE-टैग्ड कमिट्स से निकाला जाता है। जबकि लार्ज लैंग्वेज मॉडल्स (LLMs) डेटा ऑग्मेंटेशन के लिए एक मार्ग प्रदान करते हैं, वर्तमान विधियाँ आमतौर पर मौजूदा असुरक्षित 'सीड्स' को रूपांतरित करती हैं, जिससे वे स्रोत कॉर्पस के शोर को भी विरासत में प्राप्त कर लेती हैं। एक पूरक दृष्टिकोण सुरक्षित कोड के साथ शुरू करना और LLM को एक विशिष्ट कॉमन वीकनेस एन्यूमरेशन (CWE) भेद्यता इंजेक्ट करने का निर्देश देना है। हालाँकि, आधुनिक सुरक्षा-संरेखित (safety-aligned), इंस्ट्रक्शन-ट्यून्ड कोड LLMs RLHF या DPO के कारण ऐसे प्रॉम्प्ट्स को व्यवस्थित रूप से अस्वीकार कर देते हैं, भले ही मॉडल के पास अंतर्निहित क्षमता मौजूद हो। यह इनकार एक बाधा उत्पन्न करता है जो बड़े पैमाने पर, स्पेसिफिकेशन-संचालित भेद्यता डेटासेट उत्पन्न करने में बाधक है।

कार्यप्रणाली
लेखक एब्लिटरेशन (abliteration), जो कि एक लो-रैंक वेट एडिटिंग तकनीक है, का उपयोग करके इनकार के अवरोध को हटाने और जनरेटिव क्षमता को बनाए रखने की एक व्यवहार्यता अध्ययन (feasibility study) प्रस्तावित करते हैं। यह अध्ययन Python में CWE-89 (SQL Injection) को एक केस स्टडी के रूप में उपयोग करता है।

मॉडल चयन: अध्ययन तीन पैरामीटर स्केल्स पर Qwen2.5-Coder-Instruct परिवार का उपयोग करता है: 3B, 7B, और 14B। इन मॉडल्स को उनके ओपन वेट्स, कोड विशेषज्ञता और CPU-आधारित इन्फरेंस की व्यवहार्यता के लिए चुना गया था।
एब्लिटरेशन प्रक्रिया: इस परिकल्पना के आधार पर कि इनकार (refusal) मॉडल के रेसिडुअल स्ट्रीम में एक विशिष्ट लीनियर सबस्पेस द्वारा संचालित होता है, लेखक इस "इनकार दिशा" (refusal direction) को हटाने के लिए ऑर्थोगोनल प्रोजेक्शन लागू करते हैं।
- वे हानिकारक (CWE-इंजेक्शन) और हानिरहित प्रॉम्प्ट्स पर एक्टिवेशन के बीच एक कंट्रास्ट मैट्रिक्स की गणना करते हैं।
- सिंगुलर वैल्यू डिकंपोजिशन (SVD) शीर्ष- $k$ राइट सिंगुलर वेक्टर्स की पहचान करता है जो इनकार की दिशा का प्रतिनिधित्व करते हैं।
- इन वेक्टर्स को बिना रिट्रेनिंग के विशिष्ट ट्रांसफार्मर लेयर्स (आमतौर पर नेटवर्क के ऊपरी एक-तिहाई हिस्से) के आउटपुट वेट मैट्रिसेस ( $W_{out}$ ) से प्रोजेक्ट करके बाहर निकाल दिया जाता है।
- हाइपरपैरामीटर्स ( $k$ और रिफाइनमेंट पासेस) को मॉडल के आकार के अनुसार ट्यून किया जाता है (जैसे, 3B के लिए $k=2$ , 7B/14B के लिए $k=8$ )।
प्रायोगिक पाइपलाइन:
- इनपुट: PromSec (20 सैंपल्स, मल्टी-रूट Flask ऐप्स) और SafeCoder (50 सैंपल्स, सिंगल-रूट स्निपेट्स) से 70 सुरक्षित Python सैंपल्स।
- प्रॉम्प्टिंग: एक निश्चित निर्देश मॉडल को सुरक्षित कोड को CWE-89 पेश करने के लिए फिर से लिखने (जैसे, पैरामीटराइज्ड क्वेरीज़ को स्ट्रिंग कॉनकैटिनेशन से बदलना) के लिए कहता है।
- वैलिडेशन: आउटपुट का मूल्यांकन करने के लिए तीन-चरणीय प्रक्रिया अपनाई जाती है:
  1. इनकार वर्गीकरण (Refusal Classification): रिफ्यूजल पैटर्न का पता लगाने के लिए रेगेक्स-आधारित डिटेक्शन।
  2. सिंटैक्टिक वैलिडेशन: AST पार्सिंग और कंपाइलेशन चेक।
  3. भेद्यता पहचान (Vulnerability Detection): तीन स्टैटिक एनालाइजर्स का एक समूह (CodeQL, Semgrep, Bandit) संभावित भेद्यताओं को फ्लैग करता है।
  4. मैनुअल एडजूडिकेशन: दो लेखक डिटेक्टर-पॉजिटिव आउटपुट्स को CWE-89 स्पेसिफिकेशन के विरुद्ध मैन्युअल रूप से सत्यापित करते हैं ताकि फॉल्स पॉजिटिव/नेगेटिव को हल किया जा सके।
मूल्यांकन मेट्रिक्स: अध्ययन इनकार दर, सिंटैक्टिक वैधता, भेद्यता इंजेक्शन दर और ग्राउंड-ट्रुथ भेद्य समकक्षों के विरुद्ध कोड समानता (CrystalBLEU/CodeBLEU) को मापता है।

प्रमुख योगदान

पुनरुत्पादक पाइपलाइन (Reproducible Pipeline): एक प्रमाणित वर्कफ़्लो जो इंस्ट्रक्शन-ट्यून्ड कोड LLMs पर एब्लिटरेशन लागू करता है, जिसे मल्टी-टूल स्टैटिक एनालिसिस एन्सेम्बल और मैनुअल एडजूडिकेशन के साथ जोड़ा गया है।
अनुभवजन्य माप (Empirical Measurement): एक नियंत्रित फैक्टोरियल अध्ययन (3 मॉडल्स $\times$ 2 कंडीशंस $\times$ 2 डेटासेट्स $\times$ 3 रन) जो CWE-इंजेक्शन कार्यों पर इनकार और पोस्ट-एब्लिटरेशन अनुपालन का पहला अनुभवजन्य माप प्रदान करता है।
इच्छाशक्ति (Willingness) और क्षमता (Capability) का ऑर्थोगोनल पृथक्करण: अध्ययन प्रदर्शित करता है कि इनकार (इच्छाशक्ति) और कोड-जेनरेशन क्षमता ऑर्थोगोनल अक्ष हैं। एब्लिटरेशन सफलतापूर्वक नई क्षमताएं बनाए बिना इनकार के रिफ्लेक्स को हटा देता है; यह केवल उन क्षमताओं को अनलॉक करता है जो पहले से मौजूद थीं लेकिन दबी हुई थीं।
ओपन आर्टिफैक्ट्स: मिसयूज के जोखिमों को कम करने के लिए विशिष्ट एब्लिटरेटेड चेकपॉइंट्स और असुरक्षित सैंपल्स को रोकते हुए, मूल्यांकन हारनेस (रिफ्यूसल क्लासिफायर, वैलिडेटर्स, स्कोरिंग स्क्रिप्ट्स) और एग्रीगेट डेटा को जारी करना।

परिणाम

इनकार आकार- और संदर्भ-निर्भर है:
- 14B मॉडल ने दोनों डेटासेट्स पर 100% प्रॉम्प्ट्स को अस्वीकार किया।
- 7B मॉडल ने PromSec प्रॉम्प्ट्स (मल्टी-रूट) पर 73% इनकार किया, लेकिन SafeCoder प्रॉम्प्ट्स (सिंगल-रूट) पर केवल 5% इनकार किया।
- 3B मॉडल में नगण्य इनकार (0–7%) देखा गया।
एब्लिटरेशन इनकार को हटा देता है:
- एब्लिटरेशन के बाद, सभी मॉडल साइज़ और डेटासेट्स के लिए इनकार दर गिरकर 0% (या Near-zero, जैसे 3B के लिए PromSec पर 1.7%) हो गई।
- क्षमता संरक्षण (Capability Preservation): सभी एब्लिटरेटेड मॉडल्स के लिए सिंटैक्टिक वैधता 93% से ऊपर बनी रही। हस्तक्षेप ने वैध, सुसंगत Python कोड उत्पन्न करने की मॉडल्स की क्षमता को कम नहीं किया।
क्षमता क्षमता-बद्ध (Capacity-Bound) है:
- एक बार इनकार हटने के बाद, भेद्यता इंजेक्शन दर मॉडल पैरामीटर्स के साथ स्केल होती है:
  - 14B: ~88–97% इंजेक्शन सफलता।
  - 7B: ~89–90% इंजेक्शन सफलता।
  - 3B: ~25–48% इंजेक्शन सफलता।
- 3B मॉडल की कम सफलता दर एब्लिटरेशन के बाद भी बनी रही, जो यह संकेत देती है कि सीमा जेनेरेटिव क्षमता (स्ट्रक्चरल एडिट को सही ढंग से करने में असमर्थता) की कमी थी, न कि इनकार तंत्र की।
डिटेक्टर सामंजस्य (Detector Concordance): स्टैटिक एनालाइजर्स ने विभिन्न स्तरों पर सहमति दिखाई। CodeQL कुछ इडियम्स (जैसे, flask_mysqldb) के प्रति अत्यधिक विशिष्ट था, जबकि Bandit ने सिंटैक्टिक पैटर्न पर उच्च रिकॉल दिखाया। विसंगतियों को हल करने के लिए मैनुअल एडजूडिकेशन आवश्यक था।

महत्व और दावे
यह शोध पत्र दावा करता है कि यह एक प्रारंभिक व्यवहार्यता अध्ययन प्रदान करता है जो दर्शाता है कि:

इनकार को क्षमता से अलग किया जा सकता है: कोड LLMs में सुरक्षा संरेखण (Safety alignment) एक "इनकार रिफ्लेक्स" के रूप में कार्य करता है जिसे जनरेटिव सबस्ट्रेट को नुकसान पहुँचाए बिना लो-रैंक वेट एडिट्स के माध्यम से सर्जिकल तरीके से हटाया जा सकता है।
डेटा जेनरेशन व्यवहार्यता: पाइपलाइन एक ऐसी विधि प्रदान करती है जहाँ लेबलिंग का बोझ ओपन-एंडेड डिटेक्शन (जो शोर के प्रति संवेदनशील है) से हटकर बाउंडेड बाइनरी कन्फर्मेशन की ओर स्थानांतरित हो जाता है। 14B और 7B मॉडल्स, एक बार एब्लिटरेट होने के बाद, उच्च-गुणवत्ता वाले, स्पेसिफिकेशन-ड्रिवन भेद्यता डेटासेट उत्पन्न करने की उच्च क्षमता दिखाते हैं।
दोहरे उपयोग के निहितार्थ (Dual-Use Implications): लेखक एक सुरक्षा चिंता को उजागर करते हैं: सरल वेट एडिट्स के माध्यम से इनकार को हटाने की क्षमता यह बताती है कि सुरक्षा-संरेखित ओपन-वेट मॉडल्स को आसानी से दुर्भावनापूर्ण कोड उत्पन्न करने वाले उपकरणों में बदला जा सकता है। वे तर्क देते हैं कि जटिल इनपुट्स पर एब्लिटरेशन द्वारा उजागर 'अटैक सरफेस' पहले से ही सरल इनपुट्स पर डिफ़ॉल्ट रूप से मौजूद है (जैसा कि SafeCoder पर 7B के साथ देखा गया)।
मेथोडोलॉजिकल अंतर्दृष्टि: अध्ययन सुझाव देता है कि सुरक्षा-संरेखित मॉडल्स का केवल "इनकार + विफलता" दरों पर मूल्यांकन करना दो अलग-अलग घटनाओं को मिला देता है। एक मॉडल की संवेदनशील कार्यों पर स्पष्ट विफलता पूरी तरह से इनकार के कारण हो सकती है, जो हटाने योग्य है, न कि क्षमता की कमी के कारण।

लेखक एक विनम्र लहजा बनाए रखते हैं, यह नोट करते हुए कि अध्ययन एक एकल CWE (89), एक एकल भाषा (Python), और एक मॉडल परिवार तक सीमित है। वे स्पष्ट रूप से कहते हैं कि निष्कर्ष अन्य CWEs या मॉडल आर्किटेक्चर के लिए बिना और अधिक अनुभवजन्य सत्यापन के सामान्यीकरण की गारंटी नहीं देते हैं।