Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits
यह शोध पत्र तर्क देता है कि एआई (AI) मॉडलों के लिए विक्षोभ-आधारित (perturbation-based) रचना-वैधता ऑडिट (construct-validity audits) नाजुक हैं और मौन कार्यान्वयन विफलताओं के प्रति संवेदनशील हैं, जो गैर-पुष्टिपरक साक्ष्य को रोकने के लिए एक छह-बिंदु ड्यू-डिलिजेंस गेट का प्रस्ताव करता है और साथ ही यह प्रदर्शित करता है कि सुरक्षा बेंचमार्क और ओपन-वेट मॉडलों का एक विशिष्ट केस स्टडी ऑडिट विफलता के पांच मोड के इस नए वर्गीकरण के तहत पुष्टि मानकों को पूरा करने में विफल रहता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक खाद्य सुरक्षा निरीक्षक (food safety inspector) हैं। आपका काम यह जांचना है कि क्या किसी रेस्टोरेंट का "हेल्दी मेनू" वास्तव में स्वस्थ है। इसे करने के लिए, आप केवल भोजन का स्वाद नहीं चखते; बल्कि आप एक विशेष परीक्षण चलाते हैं जहाँ आप सामग्रियों को आपस में बदलते हैं (जैसे चीनी को नमक से बदलना) यह देखने के लिए कि क्या पोषण लेबल सही ढंग से बदलता है। यदि चीनी को नमक से बदलने पर भी लेबल समान रहता है, तो आप जान जाते हैं कि परीक्षण खराब हो गया है।
यह पेपर "ऑडिटर्स का ऑडिट करने" (auditing the auditors) के बारे में है। लेखक तर्क देते हैं कि जिन उपकरणों और चेकलिस्ट का हम AI सुरक्षा को सत्यापित करने के लिए उपयोग करते हैं, वे स्वयं नाजुक हैं। उन्हें सूक्ष्म तरीकों से तोड़ा जा सकता है जिससे परिणाम एकदम सही दिखाई देते हैं, भले ही पूरी प्रक्रिया ही दोषपूर्ण हो।
यहाँ उनके निष्कर्षों का विवरण दिया गया, जो सरल उपमाओं (analogies) का उपयोग करता है:
मुख्य समस्या: "टूटा हुआ रूलर" (The "Broken Ruler")
लेखक कहते हैं कि जब कंपनियाँ या शोधकर्ता AI मॉडल का परीक्षण करते हैं, तो वे "परटर्बेशन ऑडिट" (perturbation audits) का उपयोग करते हैं। इसका अर्थ है कि वे प्रश्नों में बदलाव (परटर्बेशन) करते हैं ताकि यह देखा जा सके कि क्या AI का उत्तर उस तरह से बदलता है जैसा उसे बदलना चाहिए।
- दावा: ये ऑडिट रबर से बने रूलर की तरह हैं। कभी-कभी, रबर इस तरह खिंचता या टूटता है कि माप सही दिखता है, लेकिन वास्तव में वह झूठ बोल रहा होता है।
- खतरा: एक नियामक (जैसे कोई सरकारी एजेंसी) अंतिम संख्या (जैसे, "95% सुरक्षित!") को देख सकती है और उस पर भरोसा कर सकती है, यह जाने बिना कि उस संख्या को प्राप्त करने के लिए उपयोग किया गया "रूलर" वास्तव में टूटा हुआ था।
ऑडिट विफल होने के 5 तरीके (The "Five Failure Modes")
लेखकों ने पाया कि इन ऑडिट पाइपलाइनों में पांच विशिष्ट तरीके हैं जिनसे वे चुपचाप विफल हो सकते हैं। उन्होंने उन्हें दो समूहों में विभाजित किया है: सॉफ्टवेयर ग्लिच (मशीन खराब है) और मेजरमेंट ग्लिच (तर्क गलत है)।
समूह 1: सॉफ्टवेयर ग्लिच (मशीन खराब है)
ये ऐसे बग्स हैं जहाँ कंप्यूटर कोड वह नहीं करता जो उसे करना चाहिए।
- "घोस्ट एडिट" (F1): कल्पना कीजिए कि आपने शेफ को निर्देश दिया, "नमक को चीनी से बदल दें।" लेकिन शेफ ने नोट को अनदेखा कर दिया और नमक को वैसा ही रखा। ऑडिट सोचता है कि बदलाव हो गया है, लेकिन AI ने वास्तव में उसे देखा ही नहीं। परीक्षण चलता है, लेकिन AI पुराने प्रश्न का उत्तर दे रहा है। परिणाम एक परफेक्ट स्कोर की तरह दिखता है, लेकिन यह एक झूठ है क्योंकि AI का वास्तव में परीक्षण ही नहीं किया गया।
- "खराब अनुवादक" (F2): कल्पना कीजिए कि AI एक लंबा, अव्यवस्थित वाक्य लिखता है, और एक रोबोट उसे पढ़ने की कोशिश करता है। यदि रोबोट केवल उन वाक्यों को समझता है जो "The" से शुरू होते हैं, और AI "It is..." लिखता है, तो रोबोट पढ़ने में विफल रहता है। यदि AI अपनी लिखने की शैली थोड़ी बदल देता है, तो रोबोट अचानक उसे बेहतर समझ सकता है। ऑडिट सोचता है कि AI का व्यवहार बदल गया है, लेकिन वास्तव में, रोबोट बस पढ़ने में बेहतर हो गया है।
- "टूटा हुआ पेयरिंग" (F4): कल्पना कीजिए कि आप परीक्षण कर रहे हैं कि क्या एक कार नए ट्रैक पर तेज़ है। आप पुराने ट्रैक पर कार का समय नोट करते हैं, फिर नए ट्रैक पर उसका समय नोट करते हैं। लेकिन यदि आप दूसरे रन के लिए एक अलग कार का उपयोग करते हैं, तो आपकी तुलना बेकार है। ऑडिट में, यदि वे सटीक "प्रश्न" को उसके "बदले हुए संस्करण" के साथ पेयर नहीं करते हैं, तो गणित गड़बड़ा जाता है और सुरक्षा मार्जिन नकली दिखने लगता है।
समूह 2: मेजरमेंट ग्लिच (तर्क गलत है)
ये ऐसे बग्स हैं जहाँ कोड तो काम करता है, लेकिन जिस तरह से वे परिणामों की व्याख्या करते हैं, वह त्रुटिपूर्ण है।
- "भ्रमित स्कोरकीपर" (F3): यह उन त्रुटियों का एक परिवार है जहाँ स्कोर रखने वाला व्यक्ति (या कोड) गलत चीज़ देख रहा होता है।
- इनवर्टेड कन्वेंशन (Inverted Convention): कल्पना कीजिए कि एक खेल है जहाँ "1" का अर्थ "अच्छा" है और "0" का अर्थ "बुरा" है। स्कोरकीपर गलती से सोच लेता है कि "1" का अर्थ "बुरा" है। वे रिपोर्ट करते हैं कि AI बहुत बुरा है जबकि वह वास्तव में बहुत अच्छा है।
- ऑर्डर बायस (Order Bias): कल्पना कीजिए कि एक बहुविकल्पीय परीक्षा है जहाँ सही उत्तर हमेशा पहला विकल्प होता है। AI हर बार बस पहला विकल्प चुन लेता है। स्कोरकीपर कहता है, "वाह, 100% सटीकता!" लेकिन AI केवल पहले बटन को चुन रहा है।
- द "ट्रंकेशन" बग (The "Truncation" Bug): लेखकों ने पाया कि उन्होंने एक बग को ठीक करते समय खुद एक बग पेश कर दिया था। उन्होंने AI को शीर्ष 50 उत्तर चुनने के लिए कहा, लेकिन सही उत्तर #51 था। AI उसे देख ही नहीं सका, इसलिए उसने सबसे सामान्य उत्तर का अनुमान लगाया। ऑडिट ने एक फ्लैट लाइन (शून्य परिवर्तन) दिखाई, जिससे ऐसा लगा जैसे AI इस परीक्षण के प्रति प्रतिरोधी है, जबकि वास्तव में, परीक्षण वास्तव में AI के असली उत्तर को देख ही नहीं पाया।
- "काम के लिए गलत उपकरण" (F5): कल्पना लीजिए कि आप हाथी के लिए बने तराजू का उपयोग करके एक पंख का "वजन" मापने की कोशिश कर रहे हैं। तराजू "0" दिखाता है, जो तकनीकी रूप से सही है, लेकिन वह उपकरण इस काम के लिए बेकार है। कुछ सुरक्षा बेंचमार्क यह देखने के लिए डिज़ाइन किए गए हैं कि क्या AI अपना मन बदलता है (डायग्नोस्टिक)। अन्य यह देखने के लिए हैं कि क्या AI स्थिर रहता है (इनवेरिएंस)। यदि आप "इनवेरिएंस" बेंचमार्क पर "चेंज" टेस्ट का उपयोग करते हैं, तो गणित टूटा हुआ लगेगा, भले ही AI एकदम सही हो।
समाधान: "सिक्स-पॉइंट गेट" (The "Six-Point Gate")
लेखक एक नया चेकलिस्ट (एक "गेट") प्रस्तावित करते हैं जिसे किसी भी ऑडिट को विश्वसनीय होने के लिए पास करना चाहिए। इसे एक सुरक्षा चेकपॉइंट की तरह समझें।
- गेट: इससे पहले कि आप कह सकें कि "यह AI सुरक्षित है," आपको 6 जाँचों (G1–G6) को पास करना होगा।
- क्या एडिट वास्तव में AI तक पहुँचा?
- क्या स्कोर एक बुनियादी बेसलाइन से ऊपर है?
- क्या गणित सांख्यिकीय रूप से सुदृढ़ है?
- क्या हमने "भ्रमित स्कोरकीपर" बग्स की जाँच की?
- क्या हमने खुलासा किया कि हम किस प्रकार का परीक्षण चला रहे हैं?
- क्या हमने उन बग्स की जाँच की जो हमने अन्य बग्स को ठीक करते समय अनजाने में पेश किए थे?
परिणाम: एक वास्तविकता की जाँच (A Reality Check)
लेखकों ने अपने स्वयं के ऑडिट पर यह "सिक्स-पॉइंट गेट" चलाया (10 अलग-अलग AI टेस्ट का उपयोग करके, 2 मॉडल और 5 बेंचमार्क के साथ)।
चौंकाने वाला परिणाम: शून्य में से 10 टेस्ट ने "कन्फर्मेटरी" (पूरी तरह भरोसेमंद) होने के लिए गेट को पास किया।
- 3 इनलिजिबल (Ineligible) थे (परीक्षण शुरू से ही टूटा हुआ था)।
- 3 अनवैलिडेटेड (Unvalidated) थे (हमें स्कोरकीपर पर भरोसा नहीं है)।
- 2 गणित की जाँच में विफल रहे।
- 2 एक्सप्लोरेटरी (Exploratory) थे (दिलचस्प, लेकिन अभी मुख्यधारा के लिए तैयार नहीं)।
मुख्य निष्कर्ष
लेखक यह नहीं कह रहे हैं कि "AI असुरक्षित है।" वे कह रहे हैं, "हम अभी तक उन रिपोर्टों पर भरोसा नहीं कर सकते जो कहती हैं कि AI सुरक्षित है (या असुरक्षित है)।"
उनका तर्क है कि किसी बेंचमार्क नंबर पर भरोसा करने से पहले, परीक्षण चलाने वाले लोगों को एक "सेल्फ-ऑडिट क्रोनोलॉजी" (Self-Audit Chronology) प्रकाशित करनी चाहिए। यह एक मैकेनिक की लॉगबुक की तरह है:
- "यहाँ वह बग है जो हमें मिला।"
- "यहाँ बताया गया है कि हमने इसे कैसे ठीक किया।"
- "यहाँ बताया गया है कि उस पहले बग को ठीक करने से पहले और बाद में नंबर कैसे बदला।"
- "यहाँ वह बग है जो हमने पहले वाले को ठीक करते समय अनजाने में पेश किया।"
निचोड़ (The Bottom Line): यदि आप किसी AI ऑडिट से एक साफ, परफेक्ट नंबर देखते हैं जिसमें उन सभी बग्स और सुधारों का एक अस्त-व्यस्त, ईमानदार लॉग नहीं है जो उस नंबर तक पहुँचने के लिए हुए थे, तो उस पर भरोसा न करें। वह नंबर केवल एक "साइलेंट नो-ऑप" (silent no-op) हो सकता है—एक घोस्ट एडिट जहाँ वास्तव में कुछ भी नहीं हुआ।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।