विस्तृत विश्लेषण · लगभग 8 मिनट पढ़ना
123 लाइब्रेरी पर Claude का प्रमाण अध्ययन सॉफ़्टवेयर की गारंटी का दायरा स्पष्ट करता है, उसे सार्वभौमिक नहीं बनाता
Anthropic और Theorem ने 123 लाइब्रेरी के 239 फ़ज़िंग प्रवेश बिंदुओं के लिए प्रमाण बनाने की सूचना दी है। नतीजे मशीन संबंधी स्पष्ट मान्यताओं और गारंटी की सीमाओं के साथ पढ़े जाने चाहिए।
- यहाँ प्रकाशित
- स्रोत की तारीख
- स्रोत जाँचा गया
22 अक्टूबर के एक शोध लेख में Anthropic ने Theorem के साथ किए गए काम का वर्णन किया है, जिसमें Claude सॉफ़्टवेयर के ऐसे प्रमाण बनाता है जिन्हें मशीन जाँचती है। उपयोगी नतीजा एक परिभाषित मॉडल के अंतर्गत चुने हुए निष्पादन योग्य प्रोग्रामों के बारे में गारंटी है। यह पूरी लाइब्रेरी या हर तैनाती के सुरक्षित होने का प्रमाणपत्र नहीं है।
समाचार सुनें
यह लेख सुनें या समाचार लगातार चलाएँ।
पढ़ने की तैयारी हो रही है…
डिवाइस की आवाज़
वाक् प्रक्रिया आपके ब्राउज़र या डिवाइस में होती है। AISubHub पाठ किसी ऑडियो API को नहीं भेजता। आवाज़ों और लॉक स्क्रीन पर चलने की सुविधा डिवाइस पर निर्भर है।
जारी करने पर छोटा वाक्यांश दोहराया जा सकता है।
मुख्य बातें
- शोधकर्ताओं के अनुसार, जहाँ आवश्यक था वहाँ मिले बग सुधारने के बाद उन्होंने बताई गई मान्यताओं के अंतर्गत 64 MB से छोटे इनपुट के लिए 123 OSS-Fuzz लाइब्रेरी के 239 प्रवेश बिंदुओं के क्रैश न होने के प्रमाण पूरे किए।
- मुख्य प्रयोग एकल-थ्रेड वाले, musl के साथ स्थिर रूप से लिंक किए गए RISC-V प्रोग्रामों और मॉडल किए गए Linux व्यवहार तक सीमित है। यह सामान्य x86 या ARM तैनातियों पर अपने आप लागू नहीं होता।
- अलग छोटे-कार्य प्रयोगों में मॉडल की टोकन ज़रूरत और प्रमाण साझा करने की तुलना की गई। बताई गई बचत उन्हीं प्रयोगों की है; वह कीमत या प्रदर्शन की सामान्य गारंटी नहीं है।
एक प्रमाण एक परिभाषित मशीन में एक प्रवेश बिंदु को समेटता है
कवरेज की इकाई समझना ज़रूरी है। OSS-Fuzz प्रवेश बिंदु डेवलपर द्वारा दिया गया ऐसा परीक्षण मार्ग है जिससे प्रोग्राम को इनपुट मिलता है और विफलता सामने आती है। Anthropic के अनुसार, कई हफ़्तों में 123 लाइब्रेरी के ऐसे 239 प्रवेश बिंदुओं के प्रमाण पूरे किए गए। इसका अर्थ न तो 239 लाइब्रेरी का पूरा सत्यापन है, न ही 123 लाइब्रेरी के भीतर हर संभव रास्ते का सत्यापन। इस परियोजना से Rocq प्रमाण कोड की लगभग 180,000,000 पंक्तियाँ बनीं; एक सामान्य प्रमाण लगभग 600,000 पंक्तियों का था, जबकि बाइनरी में RISC-V निर्देशों की मध्यिका 18,000 थी।
दावा मॉडल किए गए निष्पादन तक बँधा है: 64 MB से छोटे इनपुट, निश्चित मेमोरी बजट, एक थ्रेड, musl के साथ स्थिर रूप से लिंक किया गया RISC-V निष्पादन योग्य प्रोग्राम, तथा तय Linux प्रतिक्रियाएँ और मेमोरी विन्यास। यही शर्तें उस गणितीय कथन को परिभाषित करती हैं जिसका प्रमाण दिया जाता है। AISubHub का विश्लेषण है कि इस नतीजे का मूल्यांकन करते समय केवल प्रमाण की प्रभावशाली कुल पंक्तियाँ देखने से अधिक उपयोगी यह देखना है कि कवरेज किस कुल दायरे के मुकाबले है और बिल्ड का विन्यास क्या है।
फ़ज़िंग को छोटे सत्यापन कर्नेल से जाँचे जाने वाले दावे में बदलना
फ़ज़िंग बहुत से जनित इनपुट आज़माती है और प्रतिउदाहरण खोज सकती है, लेकिन इन परीक्षणों में सफल होना पूरे इनपुट-क्षेत्र को जाँच लेना नहीं है। यहाँ शोधकर्ता मौजूदा फ़ज़ परीक्षण और उसके संकलित निष्पादन योग्य प्रोग्राम को औपचारिक विनिर्देश में बदलते हैं। Claude यह तर्क बनाता है कि कोई भी अनुमत इनपुट चुने हुए परीक्षण को क्रैश नहीं करा सकता। परीक्षण में पहले से मौजूद अभिकथन उपयोगी गुण भी व्यक्त कर सकते हैं, जैसे संपीड़न और फिर विसंपीड़न के बाद मूल डेटा वापस मिलना।
मॉडल अपने प्रमाण को स्वयं सही घोषित नहीं कर सकता। Rocq कथन के विरुद्ध प्रमाण की जाँच करता है। इसलिए भरोसा सटीक कथन, RISC-V और Linux की अर्थविज्ञान-संबंधी परिभाषाओं, तथा जाँचकर्ता और उसके आधारभूत हार्डवेयर व सॉफ़्टवेयर पर केंद्रित होता है। यह जनित कोड की लाखों पंक्तियाँ पढ़ने के मुकाबले समीक्षा का छोटा दायरा है, लेकिन इस पर निर्भरता वास्तविक बनी रहती है। वैध प्रमाण यह सिद्ध नहीं कर सकता कि मशीन का कोई गलत मॉडल वास्तविक उत्पादन प्रणाली को सही ढंग से दर्शाता है।
असफल प्रमाण-प्रयास से भी उपयोगी पैच क्यों मिल सकता है
शोधकर्ताओं के अनुसार, प्रमाण बनाने के प्रयासों में बग सामने आए। इनमें एक विसंपीड़क की समस्या थी, जिसके लिए असामान्य ढंग से व्यवस्थित लगभग 20 MB इनपुट चाहिए था, और एक इमेज डिकोडर की विफलता थी, जिसके लिए 64 MB इनपुट तथा 2 GB से अधिक मेमोरी चाहिए थी। ये उदाहरण बताते हैं कि छोटे इनपुट पर केंद्रित खोज कुछ महत्वपूर्ण व्यवहार क्यों चूक सकती है। ये मूल स्रोत में बताई गई खोजें हैं, AISubHub द्वारा स्वतंत्र रूप से पुनरुत्पादित कमज़ोरियाँ नहीं।
पाइपलाइन प्रोग्राम में पैच कर सकती थी, उसका विनिर्देश दोबारा बना सकती थी और फिर सुधारे गए आर्टिफैक्ट का प्रमाण दे सकती थी। नए आर्टिफैक्ट का प्रमाण मूल, बिना बदलाव वाली रिलीज़ का प्रमाण बताकर पेश नहीं किया जाना चाहिए। शॉर्टकट का जोखिम भी है: एजेंट उपयोगी व्यवहार हटा सकता है ताकि क्रैश न होने का कथन आसानी से सही हो जाए। लेखक पैच लगाने पर दंड, किन इनपुटों का व्यवहार बदला है इसका वर्णन करने के प्रोत्साहन, और पैच ऑडिट का उल्लेख करते हैं। ये उपाय विफलता के एक तरीके से निपटते हैं; वे यह समीक्षा करने की ज़रूरत नहीं हटाते कि सुधार ने अपेक्षित व्यवहार बचाए रखा या नहीं।
टोकन की बचत दो अलग प्रयोगों से आती है
36 छोटे सत्यापन कार्यों के एक अलग समूह में लेख के अनुसार Opus 5.5 ने आधे कार्य सिद्ध करने के लिए Opus 5 से लगभग 40% कम टोकन इस्तेमाल किए। हर कार्य के लिए एकल एजेंट के तीन स्वतंत्र प्रयास मिले, और प्रत्येक प्रयास का बजट 5,000,000 टोकन था। चार्ट में पहली सफल कोशिश पूरी होने पर कार्य को पूरा गिना गया। यह निश्चित कार्य-समूह और बजट की तुलना है। लेख बड़े 123-लाइब्रेरी प्रयास में इस्तेमाल हुए सभी मॉडलों की पहचान नहीं बताता, इसलिए पूरे प्रयास को Opus 5.5 का नतीजा नहीं कहा जाना चाहिए।
साझा कार्यक्षेत्र वाले प्रयोग में एजेंट एक-दूसरे के प्रमाण दोबारा इस्तेमाल कर सकते थे और अलग-अलग काम करने की अपेक्षा 17% कम टोकन लगने की सूचना दी गई। उसके 36 प्रमाणों के चार्ट में, एकल एजेंट द्वारा पूरे किए गए 34 तुलनात्मक मामलों में से 30 में साझा तरीके ने कम टोकन इस्तेमाल किए; अलग काम कर रहे एजेंट दो कार्य पूरे नहीं कर सके। रनटाइम आरंभीकरण और सैनिटाइज़र के प्रमाणों का पुनः उपयोग बचत का ठोस तरीका दिखाता है। दोनों में से कोई प्रतिशत डॉलर में सामान्य लागत, बीते समय में सुधार या स्वतंत्र रूप से मापे गए तैनाती लाभ की गारंटी नहीं देता।
अन्य केस अध्ययन सहीपन के अलग प्रकार मापते हैं
लेख RFC से निकाले गए विनिर्देश और x86 अर्थविज्ञान का उपयोग करके किए गए zlib प्रयोग का भी वर्णन करता है। यह अलग केस अध्ययन है, इस बात का सबूत नहीं कि बड़े पैमाने के RISC-V नतीजे पहले से सभी x86 सॉफ़्टवेयर पर लागू होते हैं। Python के बड़े उपसमुच्चय के लिए बने Rust इंटरप्रेटर को Verus से मॉडल किए गए CPython अर्थविज्ञान के विरुद्ध जाँचा गया, फिर 1,700,000 से अधिक यादृच्छिक रूप से जनित प्रोग्रामों पर CPython से अनुभवजन्य तुलना की गई।
बताई गई 99.95% व्यवहार-समानता इसी अनुभवजन्य तुलना का हिस्सा है। यह हर Python प्रोग्राम के साथ संगतता का प्रमाण नहीं है। अंतर महत्वपूर्ण है: प्रमाण किसी विशेष औपचारिक कथन को स्थापित करता है, जबकि परीक्षण का प्रतिशत एक नमूना-आधारित प्रयोग का वर्णन करता है। इन नतीजों को मॉडल की एक सामान्य सटीकता दर में जोड़ देने से अलग विनिर्देशों, औज़ारों और बाकी बचे सीमांत मामलों के अंतर छिप जाएँगे।
इंजीनियरिंग का लाभ गारंटी की सीमा अधिक स्पष्ट करने में है
लेखक स्पष्ट रूप से कमियाँ स्वीकार करते हैं। AddressSanitizer कुछ मेमोरी त्रुटियाँ नहीं पकड़ता; परियोजना ने हर प्रवेश बिंदु को नहीं समेटा; और सभी फ़ज़िंग प्रवेश बिंदु समेट लेने पर भी लाइब्रेरी का पूरा व्यवहार या निष्पादित न होने वाला कोड नहीं समेटा जाएगा। कॉल करने वाला प्रोग्राम सत्यापित मान्यताओं के बाहर लाइब्रेरी का गलत उपयोग भी कर सकता है। सामान्य तैनातियों में डायनेमिक लिंकिंग, glibc, x86 या ARM होते हैं, जो मुख्य प्रयोग से अलग हैं। बिना सुधारे बग उजागर न हों, इसलिए कुछ प्रमाण जारी नहीं किए गए हैं, और व्यापक पारिस्थितिकी तंत्र के लिए लेख में दिया रोडमैप अभी प्रस्ताव ही है।
AISubHub विश्लेषण: व्यावहारिक अगला कदम यह है कि हर गारंटी को सटीक बिल्ड, परीक्षण प्रवेश बिंदु, इनपुट सीमा और भरोसेमंद मशीन मॉडल से जोड़ा जाए, फिर इनमें बदलाव आने पर उसका दोबारा मूल्यांकन हो। यह परीक्षण और समीक्षा का पूरक बन सकता है, पूरे प्रोजेक्ट से उन्हें हटा देने का आधार नहीं। हमने लेख और उसके आवश्यक चित्र पढ़े हैं, लेकिन प्रमाण दोबारा नहीं चलाए, बाहरी परिशिष्ट या जारी रिपॉज़िटरी का ऑडिट नहीं किया, पैच की सुरक्षा नहीं जाँची और टोकन बचत पुनरुत्पादित नहीं की। नतीजे और भविष्य की अपेक्षाएँ शोधकर्ताओं के कथन के रूप में ही प्रस्तुत हैं।
यह क्यों अहम है
AISubHub विश्लेषण: जनित प्रमाण किसी सीमित, समीक्षा-योग्य सॉफ़्टवेयर गुण को स्थापित करने और फिर इस्तेमाल करने की लागत घटा सकते हैं। काम में लेने योग्य नतीजा उसकी मान्यताओं समेत सटीक सत्यापित आर्टिफैक्ट और कथन है, यह सामान्य दावा नहीं कि AI ने सॉफ़्टवेयर को बग-मुक्त कर दिया है।
सीमाएँ और उपलब्धता
यह शोधकर्ताओं के प्रकाशित विवरण का विश्लेषण है, स्वतंत्र सुरक्षा ऑडिट या पुनरुत्पादन नहीं। मुख्य प्रयोग की इनपुट, आर्किटेक्चर, लिंकिंग, मेमोरी और प्रवेश-बिंदु संबंधी सीमाएँ अनिवार्य बनी रहती हैं; बाहरी परिशिष्ट और रिपॉज़िटरी की सामग्री का ऑडिट नहीं किया गया है।
स्रोत और प्रमाण
स्रोत की तारीख: · स्रोत जाँचा गया:
AI की सहायता से लिखे लेखों को दिए गए प्राथमिक स्रोतों से जाँचा जाता है। प्रदाता के दावों का श्रेय स्पष्ट है; सूची में होना समर्थन नहीं है।